The node-count check gets confused when there are more nodes that we
launched, which is normal with KUBE_USE_EXISTING_MASTER.
This fix just suppresses the error message in that case.
Fix#23390
E2e shows occasional kubectl failures here, so add some retries. We may want
to make this more general, but I think we should try it out in small scope
first.
Also clean up the retry loop so it doesn't process errors as successful runs
(discovered in testing).
Also simplify a bit of go template syntax.
Testing: I made kubectl randomly fail 50% of the time ($RANDOM%2 ==0) and
iterated until this gave me more helpful results. Still not perfect, but
better.
When using this flag, this error is shown:
Flag --api-version has been deprecated, flag is no longer respected and will be deleted in the next release
Stop using the flag in the validate-cluster.sh script and avoid the warning.
separated from the apiserver running locally on the master node so that it
can be optionally enabled or disabled as needed.
Also, fix the healthchecking configuration for the master components, which
was previously only working by coincidence:
If a kubelet doesn't register with a master, it never bothers to figure out
what its local address is. In which case it ends up constructing a URL like
http://:8080/healthz for the http probe. This happens to work on the master
because all of the pods are using host networking and explicitly binding to
127.0.0.1. Once the kubelet is registered with the master and it determines
the local node address, it tries to healthcheck on an address where the pod
isn't listening and the kubelet periodically restarts each master component
when the liveness probe fails.
- Changed check_for_ppa to be parameterized
- Added bash strictmode
- refactored the package_status method to consume variables and be a bit
nicer to future re-use of the method.
- Cut out extra echo -n statements in favor of tr -d or native awk
- Refactored branching logic paths to leverage double brackets
- normalized local variable annotation
- Updated globals to be all CAPS
- remainder of filbrandens feedback in validate-cluster.sh
This feature adds Juju provisioning to the kube-up script. It currently
parses out the pre-requisits on debian/ubuntu based systems and installs
them if they are missing.
From there we followed the integration path that was found in the
libvirt-coreos path, implementing the methods found in the boilerplate
and calling juju service calls. There are a few "arbitrary sleeps" in
the code to allow the cloud provider to settle and properly deploy.
These are work-around cases from the script executing faster than juju
was able to communicate from the state server to subsequent nodes. I
left comments inline at these points.
To exercise this:
export KUBERNETES_PROVIDER=juju
cluster/kube-up.sh
It will spin up a ref arch with 1 Kubernetes Master, 2 minions, and run
the cluster validation checks against the deployment. Bridging the gap
between the juju specific bits and the upstream recommended guides for
getting started with Juju.
To note, if you do not have a "current environment" set in Juju, it will
spin up the quickstart integration wizard in interactive mode, allowing
you to configure juju, and add the proper provider/use it. Otherwise it
assumes you're in the provider you wish to use, and will deploy there.
libvirt-coreos is a cluster provider for kubernetes that starts local VMs and
runs kubernetes on it.
Its goal is to provide a multi-machines environment to develop and test kubernetes.
The purpose is mostly the same as the vagrant provider but with a big focus on
efficiency. The vagrant cluster takes a long time to boot and consumes a huge
amount of disk space. libvirt-coreos aims at being cheaper. As a consequence,
libvirt-coreos allows to start bigger clusters with more minions than vagrant.
* Have a single config file that mirrors other cluster providers
* Warn users not to use 'vagrant up' directly
* Allow 'extra' parameters to the docker daemon. Fixes#2685
* Renumbers things so that they are more sane. Master/minions are 10.245.1.x, container subnets are 10.246.x.1/24, portal is 10.247.0.0/16
