Takeaway: installing Kubernetes "the hard way" is hard because of the constant evolving of the project.
Here, we do bunch of "claims". Claims are documentation told somewhere. Then, "errors" are what actually should be done as of March, 2019.
- claim: use kube-dns
- error: as of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dns
- claim: use Kubernetes version from quay.io/coreos/hyperkube
- error: versions beyond 1.9.6 are not available, use gcr.io/google-containers/hyperkube-amd64 instead, to do this, you need to specify --insecure-options=image flag to rkt, which looks like this
- claim: use --api-servers flag with kubelet
- error: --api-servers is deprecated, use --kubeconfig flag instead, which maps to a file like this
- assumption: removing --register-schedulable flag will make the master schedulable
- error: commenting it out has no effect, the node has to be patched instead
- assumption: dropping the self-signed TLS assets would start working after running
sudo systemctl daemon-reload - error: you still get "Unable to connect to the server: x509: certificate signed by unknown authority" error on kubelet-wrapper logs
- therapy: add
--client-ca-fileto kube-apiserver and kubelet, thenopenssl s_client -connect ${master-host}:443will still show that tsl is not applied -> you need to restart the host :)
- claim: for advanced config, use etcd with discovery
- error: as the nodes are reachable in LAN, then it simpler to use named initial cluster
- assumption: containers can reach google.com
- error: not with my router (and seemingly others), add upstreamNameservers to CoreDNS configuration to avoid issues
- claim: according to CoreOS documentation, the worker kube-proxy configuration takes in master host without protocol prefix
- error: CoreOS documentation is wrong, you must specify https protocol prefix, like this
- claim: kube-apiserver network interfaces are configured correctly on installation
- error:
no route to hostwill appear on pod-to-pod and pod-to-apiserver connections - therapy: flannel default configuration creates a conflicting
cni0anddocker0interfaces on the control-plane node, of which thedocker0interface should be reconfigured by using a service file
bonuses:
- assumption: computers run on the same time
- error: Arch Linux runs 1 minute in the future, causing etcd consensus to fail
- therapy: install and enable NTP client on Arch Linux