Over the past few months I’ve been trying to learn everything there is to know about Kubernetes. Kubernetes is an amazing technology for deploying and scaling containers though it comes with a cost. It’s an incredibly complex piece of software and there are a ton of bells and whistles to become familiar with. One way that I’ve found for coming up to speed is Joe Beda’s weekly TGIK live broadcast. This occurs each Friday at 4PM EST and is CHOCK full of fantastic information. In episode six Joe talks about kubeadm. You can watch it here:
Here are some of my takeways from the episode:
Heptio opensourced Ark which allows you to backup & recover a Kubernetes cluster.
Heptio opensourced sonobuoy which allows you to perform cluster conformance tests. Super cool!
AWS IAM roles can be attached to instances and updated. There was a bit of confusion on this point.
At the time this video was shot kubeadm didn’t support HA. It looks like kubeadm can build HA clusters now.
Kubeadm cluster installation process
Install docker on each host
Install Kubernetes repo on each host
Install kubernetes on each node
kubeadm init can be used to initialize the control plane
Join the workers to the control place with kubeadm join
Install a networking solution
Kubeadm enables the node and RBAC authorizers by default.
When a node joins the cluster it presents a bootstrap token to the API server’s authenticator service. These tokens can be configured to expire at periodic intervals as of Kubernetes 1.8.
Kubeadm configures all of the client and server certificates. It also utilizes the built-in CA.
You can talk to the API server from inside the cluster using it’s well known ClusterIP (Uses x.x.x.1).
Kubeadm assigns one certificate to each service to improve security.
The API server “-apiserver-cert-extra-sans” option allows you to extend the list of names your API server can be known as. This will add the additional names to the Subject Alternate Name section of the certificate.
Kubeadm runs all of the control plane services (api server, schduler and controller) as Kubernetes pods. There are pros and cons to this.
The kubelet has two modes of operation:
Kubelet reaches out to the API server to get its instructions.
Kubelet uses files on disk to control what it will run (static pods).
The only service managed by systemd on a kubeadm cluster is the kubelet that starts the other services from static files.
Kubeadm adds the kube-proxy and kube-dns server add-ons.
Two interesting projects
bootkube is a tool for launching self-hosted Kubernetes clusters.
Kubelet checkpointing is a way for the kubelet to save the current state for future restarts.
You can retrieve boostrap tokens with kubeadm:
$ kubeadm token list
To join a node to the cluster you can use the kubeadm join option:
$ kubeadm join --token xxxx.xxxxxxx APISERVERIP:6443
ConfigMap in kube-public cotnains the cluster information needed to bootstrap a worker. Uses the token to verify the information is from a trusted location.
Kubeadm uses the Kubernetes certificate API on each worker to create a CSR and to get a signed certificate so it can talk to the API server.
Certificate rotation is coming in to a Kubernetes release near you.
To view the cluster configuration kubeadm will use you can retrieve it from the kube-public namespace with curl:
$ curl https://api_server_ip/api/v1/namedpsaces/kube-public/configmaps/cluster-info