Notes from episode 11 of TGIK: Upgrading to 1.8 with kubeadm

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 eleven Joe talks about upgrading with kubeadm. You can watch it here:

Here are some of my takeways from the episode:

• The release notes describe new features and gotchas related to the upgrade process.
• APIs can change and move over time. Important to review the release notes and test before upgrading.
• Kubernetes versions their APIs with three tags:
  • Alpha level - Work in progress w/o any guarantees.
  • Beta level - Well tested, features won’t be dropped but details may change.
  • Stable level - Production ready and will be available for the known future.
• Newer releases of Kubernetes will expire the bootrap tokens after 24-hours.
• Self hosting is the term used when Kubernetes manages Kubernetes.
• The kubeadm deployment manifests are stored in /etc/kubernetes/manifests.
• The kubelet picks up changes to files in /etc/kubernetes/manifests and uses these to bootstrap the control plane. The API server isn’t contacted when static pod defintions are used.
• Kubelet checkpointing (once it’s released) will allow the current cluster state to be saved. If a cluster goes dark and comes back these checkpoints will be used to restore the cluster to a known state.
• You can find the control plane versions from the image tags:
  $ kubectl get pods -n kube-system kube-controller-manager-kub1 -o yaml | grep image:
• Here is the actual upgrade process:
  • Review the release notes for Kubernetes and your network solution.
  • Plan the upgrade with kubeadm upgrade plan.
  • Perform the upgrade with kubeadm upgrade apply VERSION_TO_UPGRADE_2.
  • Upgrade kubelet on each worker.
  • Upgrade the kubectl utility.
• The kubectl version command shows the API server version:
  $ kubectl version --short
• SIG cluster lifecycle is where kubeadm changes are discussed.
• If you are upgrading from an older version you may need to pass the flags you passed to kubeadm init to the upgrade command. Newer releases store this information in a ConfigMap.
• You can view the upgrade ConfigMap with kubectl:
  $ kubectl get configmaps -n kube-system kubeadm-config -o yaml
• The kube-proxy runs as a DaemonSet across all of your nodes.
• Docker is split out into three pieces:
  • dockerd is the daemon resposible for managing images and containers.
  • docker-containerd provides the actual abstractions to manage containers and container networking.
  • docker-containerd-shim provides the actual runtime (typically via runc) to run a container.

Things I need to larn more about:

• Play with kubeadm HA.
• Keep reading through the API documentation.
• Read the container runtime specification.

This article was posted by Matty on 2018-02-16 16:00:00 -0500 -0500