If the ephemeral volume is present and mounted, don't try to reinitialize
them.
Don't block the boot if the ephemeral volume is corrupt / missing -
this enables us to cope with a stop/start & presumably also corruption.
In this case, we'll reformat the ephemeral storage.
Fix#21157
This is so we have the same behaviour as on GCE.
This also lets us change the bootstrap script or the config, which is
nice. Instance data is immutable on AWS once it is booted.
Fix#21150
This is good because it removes an obstacle to using the
cluster/ubuntu scripting to install Kubernetes into a restricted
environment where the machines can not open connections to arbitrary
external locations.
Also add debuggability to make-ca-cert.sh
Resolves#21037Resolves#21092
We were assuming the PROJECT env var was set, which the e2e tests do.
But PROJECT is normally not set on AWS (it is set on GCE); this broke as
part of the harmonization.
Revert to the pre-existing behaviour here, where we use "aws_" as the
prefix.
Fix#21141
This change corrects how we determine the log level. Moreover, it explicitly redirects kubelet log to /var/log/kubelet.log, as we noticed it may miss sometimes.
This change moves the code of running and monitoring addon pods in a daemon type upstart job, so that addon manifest monitoring can be restarted automatically upon failure. Second, it updates the usage of "kube-ui" to "dashboard" to match the change in PR #20330.
Package manager "dnf" does not work correctly with Salt
(cf https://github.com/saltstack/salt/issues/31001)
It causes Salt to consider that some packages (python, git, curl, etc.) are not
installed, which breaks the Vagrant Kubernetes setup.
Updating dnf and dnf-plugins-core to their latest version solves the issue.
Additionally, I've added the "fastestmirror" to dnf, which is useful if a
RPM mirror is broken or very slow. (In my case, dnf used a broken mirror which
froze the Kubernetes setup).
Fix script for case when neeed to setup cluster
in an existen VPC and subnet with ip mask example: 10.0.0.0/8.
Fixed bug to detect ip of master if provided MASTER_RESERVED_IP.
For some reason detecting master ip was moved to volumes and only when MASTER_RESERVED_IP=auto.
If specify IPv4 for MASTER_RESERVED_IP like `52.1.1.1`, than we could
not detect ip even during last steps of setuping cluster.
step the KUBE_MASTER_IP is reseted because there are no tag for the
volume.
