* Units which fail due to unmet dependencies are not restarted.
Upstream issue: github.com/systemd/systemd/issues/1312
* Avoid depending on flanneld. Instead, check and fail if unmet
to force a restart (retry)
* Remove unneeded k8s-assets dependency on kubelet. The k8s-assets
script itself just checks for the Kubernetes API to be up anyway
* Kubelet must be able to resolve DNS names which are
known to the host
* Fixes a bug in which only IP's could be used for
k8s_controller_endpoint metadata
* Upstream systemd issue: github.com/systemd/systemd/issues/1312
* Units which fail due to unmet dependencies are not restarted
as they would be upon failure. Kubelet should keep trying until
flanneld is active.
* Apply the recommended work-around by adding an ExecStart
which checks for a Wanted dependency and purposefully fails
when unmet in order to force a restart to keep trying.
* Upgrade the self-hosted Kubernetes cluster example to
use bootkube v0.1.1 which supports apiserver checkpointing
in order to tolerate apiserver downtime (e.g. controller
reboot)
* Bumps Kubernetes version to v1.3.0-beta.2
* Re-enable CoreOS auto-updates
* scp kubeconfig to hosts rather than insecurely distributing
credentials within Ignition configs. This is also easier than
copy-pasting k8s secrets into machine metadata (slow).
* Self-hosted Kubernetes machine configurations can be versioned
without containing Kubernetes credentials
* Use path-based activiation for the host kubelet
* Update from Kubernetes v1.2.2 to v1.3.0-alpha.5_coreos.0.
* Update host kubelet flags accordingly
* Examples which install CoreOS to disk should reference
a CoreOS install image from bootcfg assets to speed up
installs and improve the offline use-case
* Update scripts/get-coreos to download and verify the
CoreOS install image
* Update CoreOS version to get rkt 1.2.1->1.6.0 improvements
for running the kubelet wrapper in Kubernetes clusters
* Update CoreOS version for other clusters so users only need
to download one cached version of assets to run examples
* Rendering an Ignition config or cloud-config template
with machine group metadata will error and log if a metadata
value is missing.
* Previously, the default missing value was "no value"
* Match machines by MAC address in examples
* Re-use the MAC address to assign static networkd configs
where needed.
* UUID is useful to uniquely identify a machine (unlike MAC)
but many users had difficulty finding the network device name
to use in static networkd configs. Selecting by MAC reduces
the potential for user error here.
* bootkube clusters work with bootkube 5c1efe3ac61e270
* Copy bootkube generated assets and executable to any master
* Change hosts to use kubelet client certificate instead of token
* Update bootkube deployment documentation
* Users try to use the latest reference example clusters with
a bootcfg v0.3.0 deployment, which did not yet support Ignition
2.0.0. Wait until closer to v0.4.0 to bump Ignition configs.
* Profiles should use only the user-provided DNS endpoint.
Adding 8.8.8.8 can cause inconsistent resolution and in some
setups, 8.8.8.8 is not routable.
* Setting k8s_version via metadata gives the impression
it can be bumped and the cluster will operate with the
desired version. In reality, the k8s profiles change in
minor but important ways which we validate between k8s
releases. It should be part of the k8s profile Ignition.
* In the k8s-install example, the k8s-certs@.service checks for
the wrong file and always attempts to curl TLS assets from bootcfg.
After restarts or auto-updates, if bootcfg is not running, the certs
are present on disk so the kubelet and k8s cluster operate normally,
while k8s-certs services fail (mostly harmless).
* Fixes k8s-certs@service failures after restarts when bootcfg is
unavailable. Provisioned nodes should not have a hard dependency on
bootcfg service.
