We had a port collision on 3997; change the default memberlist ports
to avoid the collision (we haven't shipped a release with this in it).
Also create a go file so that we can use constants to keep track of
our port numbers, rather than magic values.
As of k8s 1.16, the node-role label is protected for security reasons.
We will introduce a controller to set those labels generically.
However, we need these labels to run the controller (only) on master
nodes.
To solve this bootstrapping problem, we use protokube to apply the
master role node labels to the master node only. This isn't a
security problem because we assume that protokube on the master is
highly trusted - we are still administering labels centrally.
Then kops-controller can use this label to target the master nodes,
and run a central label controller.
Again unlikely to matter since master nodes aren't expected to run out of
capacity, done mostly for completeness (all pods should usually have a
priority defined if the cluster is running with PodPriority enabled).
When we have multiple writers racing to write /etc/hosts, we could
have file corruption where we see a mix of both files.
We can't use a traditional atomic file write, because we are bind-mounting /etc/hosts.
Instead we write to /etc/hosts, pause, then re-read the contents. If
the contents don't match, we repeat. This will not result in fair
queuing, but will avoid corruption.
* Add a mutex around /etc/hosts updates (for a little extra safety)
* Don't write unchanged files
* Recover from out-of-sequence guard lines
* Add tests
Thanks to granular-ryanbonham for the suggestions & finding the issue!
We don't call klog.InitFlags yet, because that will cause a flag
redefinition error until we get everyone to stop using glog. That
will happen when we update to k8s 1.13.
In 1.12 (kops & kubenetes):
* We default etcd-manager on
* We default to etcd3
* We default to full TLS for etcd (client and peer)
* We stop allowing external access to etcd
We were doing this implicitly previously by creating the etcd records.
As etcd-manager doesn't need to create gossip records, we instead
create a zone explicilty.
The etcd-manager will (ideally) take over etcd management. To provide a
nice migration path, and because we want etcd backups, we're creating a
standalone image that just backs up etcd in the etcd-manager format.
This isn't really ready for actual usage, but should be harmless because
it runs as a sidecar container.
Fix up the local IP address discovery logic, to recognize new
en-interfaces, and to better log what it is doing. Plug it in for
baremetal installations.
The current kube manifest redirect all the logs into host located log files, this PR uses the tee command to pipe into both local logs (retaining the current) and docker stdout (which will be picked up by the journald or which every logging your using. Note also permits as to now need the logs via the kubectl command.
- renamed some of the files to make things cleaner
- redirecting the logs from the kubernetes components into local file and stdout
- cleaned up any vetting or linting error i came across
Automatic merge from submit-queue. .
ETCD container mount /etc/hosts file
This PR just volume mounts the /etc/hosts file from the masters into the etcd-server containers. I'm not 100% sure if this is the right approach to fixing this problem, but I was running into the issue of the etcd servers no longer being able to discover each other after performing a rolling-update. I'm running this version of protokube locally and it's fixed my issues of the etcd containers not being able to discover each other after an update.
I saw that the kube-proxy manifest was already volume mounting the /etc/hosts file, so I figured this was kosher.
- removing the StorageType on the etcd cluster spec (sticking with the Version field only)
- changed the protokube flag back to -etcd-image
- users have to explicitly set the etcd version now; the latest version in gcr.io is 3.0.17
- reverted the ordering on the populate spec
The current implementation is running v2.2.1 which is two year old and end of life. This PR add the ability to use etcd and set the versions if required. Note at the moment the image is still using the gcr.io registry image. As note, much like TLS their presently is not 'automated' migration path from v2 to v3.
- the feature is gated behine the storageType of the etcd cluster, bot clusters events and main must use the same storage type
- the version for v2 is unchanged and pinned at v2.2.1 with v2 using v3.0.17
- @question: we shoudl consider allowing the use to override the images though I think this should be addresses more generically, than one offs here and then. I know chris is working on a asset registry??
- added the master option back the protokube, updating the nodeup model and protokube code
- removed any comments no related to the PR as suggested
- reverted the ordering of the mutex in the AWSVolumes in protokube
The current implementation does not put any transport security on the etcd cluster. The PR provides and optional flag to enable TLS the etcd cluster
- cleaned up and fixed any formatting issues on the journey
- added two new certificates (server/client) for etcd peers and a client certificate for kubeapi and others perhaps (perhaps calico?)
- disabled the protokube service for nodes completely is not required; note this was first raised in https://github.com/kubernetes/kops/pull/3091, but figured it would be easier to place in here given the relation
- updated protokube codebase to reflect the changes, removing the master option as its no longer required
- added additional integretion tests for the protokube manifests;
- note, still need to add documentation, but opening the PR to get feedback
- one outstanding issue is the migration from http -> https for preexisting clusters, i'm gonna hit the coreos board to ask for the best options