Writing to a hostPath from a non-root container requires file
ownership changes, which is difficult to roll out today. See
discussion in #8454
We were primarily using the logfile for e2e diagnostics, so we're
going to look into collecting the information via other means instead.
We also haven't yet shipped this logfile in a released version (though
we have shipped it in beta releases)
The migration was first made in 1.16.0-alpha.1, so that means 2 releases have been out that set the replicas to zero.
This removal negatively impacts anyone that created a cluster from kops HEAD between 1.15.0 and 1.16.0-alpha.1, and then upgraded kops directly to the 1.16.0 release that includes this commit, without having first upgraded to either of the alphas.
That seems like a reasonably small enough audience that this is safe to remove now.
Perhaps we mention in the release notes that anyone using HEAD or one of the alpha releases needs to `kubectl delete -n kube-system deployment kops-controller`
This makes it easier to get the kops-controller logs from e2e tests since it they only dump log files from systemd services and /var/log files [0]
[0] ec0fe6bd36/kubetest/dump.go (L50-L74)
When booting a cluster with `--networking=cni`, `dns-controller` will
not start due to the master node being _tainted_ as "network unreachable".
This adds an extra step when managing your own CNI setup, having to SSH
into a master and publish the CNI manifests from there.
This commit adds tolerance and configuration that allows `dns-controller`
pod to start when running with `--networking=cni`, properly creating the
DNS records so the operator can remotely publish the CNI and extra
manifests to have a full working cluster.
This also removes the dependency on `kube-proxy`, by adding the
`KUBERNETES_SERVICE_HOST` environment variable, bypassing `kube-proxy`
when disabled.
Presumably, as a side-effect, this change also allows for
"host network only" clusters to work.
Signed-off-by: Rodrigo Chacon <rochacon@gmail.com>
Do not use ports less than that given as source for outbound DNS queries. Dnsmasq picks random ports as source for outbound queries: when this option is given, the ports used will always to larger than that specified. Useful for systems behind firewalls.
Seeing an odd error from the apply, likely from an empty object:
`error validating data: [apiVersion not set, kind not set]; if you choose to ignore these errors, turn validation off with --validate=false`
Ciprian Hacman