With etcd-manager the DNS names should only be used by the
etcd-manager pod itself, so we don't need to share /etc/hosts with the
host.
By not sharing we avoid:
(1) the temptation to address etcd directly
(2) problems of concurrent updates to /etc/hosts being hard from within a container (because locking is difficult across bind mounts)
Introducing with kubernetes 1.17 to avoid changing behavior of existing versions.
Primarily for DigitalOcean support
Changes:
* fix issues in pr#253
* Update rules-docker to 0.12
* [DO-7442] Fix logic for Digital Ocean volume tag
* Update release process to use shipbot
* Move to go modules
* Update golang to 1.13.3
* travis: Test newer bazel versions
* Fix unit tests
* Test everything, not just //test
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.
Previously when setting the external cloud controller manager
configuration the core components `kubelet`, `apiserver` and
`kubecontroller-manager` were configured to use the external cloud
controller manager. Without setting the feature flag
EnableExternalCloudController this lead to a cluster in which the
masters had the cloud controller taint
`node.cloudprovider.kubernetes.io/uninitialized` which prevents
essential pods, like dns-controller to not be scheduled and leaves a
cluster where worker nodes can't connect to the api server because they
cannot resolve its hostname.
Image names from 1.16 on include an architecture suffix,
e.g. "-amd64"; the generic alias continues to work when pulling, but
when loading from a tarball (i.e. running in CI) we must use the
per-architecture name.
Refactor to start to centralize the env-var configuration for system
components, also start to add test coverage so we can be sure we
haven't broken things!
Relnotes are at https://github.com/kopeio/etcd-manager/blob/master/docs/relnotes/3.0.20190801.md
Highlights:
* etcd-manager-ctl is now available in the image, and for download from github
* etcd 3.3.13 is included
* etcd-manager will now run a compatible version of etcd if it is available (for example, etcd 3.3.13 instead of 3.3.11), to better import backups or support migration
* listen-metrics-urls can now be specified and will be passed through to etcd
* improved docs around internals
Should prevent the scenario where etcd-manager can't come up because of a different version.
Can be bypassed with the SkipEtcdVersionCheck feature flag.
update template
Update notes for digital ocean
Update TTL to 60 seconds and version upgrade to 0.1.15 for DO Cloud Controller Manager
Update review comments
Format go code
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).
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
https://github.com/lyft/cni-ipvlan-vpc-k8s
This cni solution is slightly different in that it doesn't require running a daemonset
It requires:
* a config file in /etc/cni/net.d
* the binaries in /opt/cni/bin
* adding the --node-ip param to the kubelet
This code is modeled after the AmazonVPC cni bits.
I've left the setup of the required subnets as an exercise to the reader.
This currently just turns off validation of the kubelet cluster dns
flag, which should allow for experimenting with more complicated DNS
configurations such as local proxies, which may address shortcomings
of DNS retries with UDP.
Issue #5584
- switching to using code rather than a template for the systemd unit creation as requested in review
- as part of the review, changing the name of the ca from tls-ca to tls-client-ca
- changing the api from DisableAddressCheck to EnableAddressCheck and defaulting to true if no set
- fixing up the test for node-authorizer and shifting the parsing of the certificates as suggested in reviews to a method
a) The current implementation use's a static kubelet which doesn't not conform to the Node authorization mode (i.e. system:nodes:<nodename>)
b) As present the kubeconfig is static and reused across all the masters and nodes
The PR firstly introduces the ability for users to use bootstrap tokens and secondly when enabled ensure the kubelets for the masters as have unique usernames. Note, this PR does not attempt to address the distribution of the bootstrap tokens themselves, that's for cluster admins. One solution for this would be a daemonset on the masters running on hostNetwork and reuse dns-controller to annotated the pods and give as the DNS
Notes:
- the master node do not use bootstrap tokens, instead given they have access to the ca anyhow, we generate certificates for each.
- when bootstrap token is not enabled the behaviour will stay the same; i.e. a kubelet configuration brought down from the store.
- when bootstrap tokens are enabled, the Nodes sit in a timeout loop waiting for the configuration to appear (by third party).
- given the nodeup docker and manifests builders are executed before the kubelet builder, the assumption here is a unit file kicks of a custom container to bootstrap the rest.
- the current firewalls on between the master and nodes are fairly open so no need to open ports between the two
- much of the work was ported from @justinsb PR [here](https://github.com/kubernetes/kops/pull/4134/)
- we add a very presumptuous server and client certificates for use with an authorizer (node-bootstrap-internal.dns_zone)
I do have an additional PR which performs the entire thing. The process being a node_authorizer which runs on the master nodes via a daemonset, the service implements a series of authorizers (i.e. alwaysallow, aws, gce etc). For aws, the process is similar to how vault authorizes nodes [here](https://www.vaultproject.io/docs/auth/aws.html). Nodeup no then calls out to the node_authorizer on bootstrap and provisions the kubelet.
We also have to stop passing the flag on ContainerOS, because it's set
in /etc/docker/default.json and it's now an error to pass the flag.
That in turn means we move those options to code, which are the last of
those legacy config options. (We still have a few tasks declaratively
defined though)
Kubernetes 1.9 changed the default for etcd-quorum-read flag value to
true, in the hope of fixing some of the edge-case controller issues.
However, while this is cheap on etcd3, that fix was not backported to
etcd2, and performance there of quorum reads is poor.
For non-HA clusters with etcd2, it still goes through raft, but does not
need to - we set etcd-quorum-read to false, as this is just a missed
optimization in etcd2.
For HA clusters with etcd2, it's trickier, but at least for now we're
going to avoid the (crippling) performance regression. kops 1.10 should
have etcd-manager (allowing upgrades to etcd3), and the ability to
configure IOPS on the etcd volume, so we can revisit this in 1.10 /
1.11.
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.
File assets and the SHA files are uploaded to the new location. Files
when are users uses s3 are upload public read only. The copyfile task
uses only the existing SHA value.
This PR include major refactoring of the use of URLs. Strings are no
longer categnated, but converted into a URL struct and path.Join is
utlilized.
A new values.go file is included so that we can start refactoring more
code out of the "fi" package.
A
Automatic merge from submit-queue.
Let a user set a hostnameOverride when the cloud provider is aws.
Let a user use the hostname or set a hostnameOverride when the cloud provider is aws. This would allow for a more descriptive name to be used. The name of the hosts when using @hostname can be set by using a hook or some other method.
Automatic merge from submit-queue.
Initial aggregation work
Create the keypairs, which are supposed to be signed by a different CA.
Set the `--requestheader-...` flags on apiserver.
Fix#3152Fix#2691
Ciprian Hacman