- new property is only used when KubernetesVersion is 1.6 or greater
- taints are passed to kubelet via --register-with-taints flag
- Set a default NoSchedule taint on masters
- Set --register-schedule=true when --register-with-taints is used
- Changed the log message in taints.go to be less alarming if taints are
found - since they are expected on 1.6.0+ clusters
- Added Taints section to the InstanceGroup docs
- Only default taints are allowed in the spec pre-1.6
- Custom taint validation happens as soon as IG specs are edited.
We move everything to the models. We feature-flag it, because we
probably want to change the names etc, and we aren't going to be able to
offer smooth upgrades until that is done.
* Change protokube to do `systemctl start kubelet` every sync round
** .. which takes a change to the systemd unit for protokube to mount in D-Bus
* Don't start kubelet in nodeup
If the instance restarted but lost the volume mount, there might be a
short or indefinite delay before protokube can mount the volume again.
But the etcd manifest would probably still be in
/etc/kubernetes/manifests from the previous run.
To ensure that kubelet doesn't run etcd until the volume is actually
mounted, we use a symlink to a directory on the volume itself. Thus
kubelet can't start etcd until we put the volume there. We can also
delete the symlink before mounting, so we have full control.
Issue #73
Adds changes to support clustered etcd:
* Configure node names in DNS
* Parse annotations on the volume to infer the etcd configuration
Using annotations on the volumes to control what manifests launch feels
pretty powerful. Though we could also just write the manifest to a
central location (e.g. S3) and then sync them into the kubelet
directory.
This also means we no longer have to directly spawn kubelet - we can now
just write the manifests.
Working towards self-hosting of k8s, we will likely have to add some
features to kubelet, such as independent mounting of disks or copying of
resources from S3. protokube lets us develop those features prior to
moving them into kubelet.
In particular, today we need to mount an EBS volume on the master prior
to starting kubelet, if we want to run the master in an ASG.
protokube is a service that runs on boot, and it tries to mount the
master volume. Once it mounts the master volume, it runs kubelet.
Currently it runs kubelet by looking at a directory
/etc/kubernetes/bootstrap; the intention is that we could actually have
multiple versions of kubelet in here (or other services) and then we
could automatically roll-back from a failed update.