Update to Kubernetes 1.32.3

Author: kelseyhightower

README.md

@@ -19,10 +19,10 @@ Kubernetes The Hard Way guides you through bootstrapping a basic Kubernetes clus
 
 Component versions:
 
-* [kubernetes](https://github.com/kubernetes/kubernetes) v1.31.x
-* [containerd](https://github.com/containerd/containerd) v2.0.x
+* [kubernetes](https://github.com/kubernetes/kubernetes) v1.32.x
+* [containerd](https://github.com/containerd/containerd) v2.1.x
 * [cni](https://github.com/containernetworking/cni) v1.6.x
-* [etcd](https://github.com/etcd-io/etcd) v3.4.x
+* [etcd](https://github.com/etcd-io/etcd) v3.6.x
 
 ## Labs
 

ca.conf

@@ -124,7 +124,7 @@ extendedKeyUsage     = clientAuth, serverAuth
 keyUsage             = critical, digitalSignature, keyEncipherment
 nsCertType           = client
 nsComment            = "Kube Controller Manager Certificate"
-subjectAltName       = DNS:kube-proxy, IP:127.0.0.1
+subjectAltName       = DNS:kube-controller-manager, IP:127.0.0.1
 subjectKeyIdentifier = hash
 
 [kube-controller-manager_distinguished_name]
@@ -175,7 +175,7 @@ basicConstraints     = CA:FALSE
 extendedKeyUsage     = clientAuth, serverAuth
 keyUsage             = critical, digitalSignature, keyEncipherment
 nsCertType           = client
-nsComment            = "Kube Scheduler Certificate"
+nsComment            = "Kube API Server Certificate"
 subjectAltName       = @kube-api-server_alt_names
 subjectKeyIdentifier = hash
 
@@ -203,4 +203,4 @@ extendedKeyUsage     = clientAuth
 keyUsage             = critical, digitalSignature, keyEncipherment
 nsCertType           = client
 nsComment            = "Admin Client Certificate"
-subjectKeyIdentifier = hash
+subjectKeyIdentifier = hash

configs/encryption-config.yaml

@@ -1,5 +1,5 @@
-kind: EncryptionConfig
-apiVersion: v1
+kind: EncryptionConfiguration
+apiVersion: apiserver.config.k8s.io/v1
 resources:
   - resources:
       - secrets

configs/kubelet-config.yaml

@@ -1,5 +1,6 @@
 kind: KubeletConfiguration
 apiVersion: kubelet.config.k8s.io/v1beta1
+address: "0.0.0.0"
 authentication:
   anonymous:
     enabled: false
@@ -9,13 +10,16 @@ authentication:
     clientCAFile: "/var/lib/kubelet/ca.crt"
 authorization:
   mode: Webhook
-clusterDomain: "cluster.local"
-clusterDNS:
-  - "10.32.0.10"
 cgroupDriver: systemd
 containerRuntimeEndpoint: "unix:///var/run/containerd/containerd.sock"
-podCIDR: "SUBNET"
+enableServer: true
+failSwapOn: false
+maxPods: 16
+memorySwap:
+  swapBehavior: NoSwap
+port: 10250
 resolvConf: "/etc/resolv.conf"
+registerNode: true
 runtimeRequestTimeout: "15m"
 tlsCertFile: "/var/lib/kubelet/kubelet.crt"
-tlsPrivateKeyFile: "/var/lib/kubelet/kubelet.key"
+tlsPrivateKeyFile: "/var/lib/kubelet/kubelet.key"

docs/01-prerequisites.md

@@ -4,7 +4,7 @@ In this lab you will review the machine requirements necessary to follow this tu
 
 ## Virtual or Physical Machines
 
-This tutorial requires four (4) virtual or physical ARM64 machines running Debian 12 (bookworm). The following table list the four machines and thier CPU, memory, and storage requirements.
+This tutorial requires four (4) virtual or physical ARM64 machines running Debian 12 (bookworm). The following table lists the four machines and their CPU, memory, and storage requirements.
 
 | Name    | Description            | CPU | RAM   | Storage |
 |---------|------------------------|-----|-------|---------|
@@ -13,9 +13,9 @@ This tutorial requires four (4) virtual or physical ARM64 machines running Debia
 | node-0  | Kubernetes worker node | 1   | 2GB   | 20GB    |
 | node-1  | Kubernetes worker node | 1   | 2GB   | 20GB    |
 
-How you provision the machines is up to you, the only requirement is that each machine meet the above system requirements including the machine specs and OS version. Once you have all four machine provisioned, verify the system requirements by running the `uname` command on each machine:
+How you provision the machines is up to you, the only requirement is that each machine meet the above system requirements including the machine specs and OS version. Once you have all four machines provisioned, verify the system requirements by running the `uname` command on each machine:
 
-```bash 
+```bash
 uname -mov
 ```
 
@@ -25,6 +25,6 @@ After running the `uname` command you should see the following output:
 #1 SMP Debian 6.1.115-1 (2024-11-01) aarch64 GNU/Linux
 ```
 
-You maybe surprised to see `aarch64` here, but that is the official name for the Arm Architecture 64-bit instruction set. You will often see `arm64` used by Apple, and the maintainers of the Linux kernel, when referring to support for `aarch64`. This tutorial will use `arm64` consistently throughout to avoid confusion.
+You may be surprised to see `aarch64` here, but that is the official name for the Arm Architecture 64-bit instruction set. You will often see `arm64` used by Apple, and the maintainers of the Linux kernel, when referring to support for `aarch64`. This tutorial will use `arm64` consistently throughout to avoid confusion.
 
 Next: [setting-up-the-jumpbox](02-jumpbox.md)

docs/02-jumpbox.md

@@ -1,8 +1,8 @@
 # Set Up The Jumpbox
 
-In this lab you will set up one of the four machines to be a `jumpbox`. This machine will be used to run commands in this tutorial. While a dedicated machine is being used to ensure consistency, these commands can also be run from just about any machine including your personal workstation running macOS or Linux.
+In this lab you will set up one of the four machines to be a `jumpbox`. This machine will be used to run commands throughout this tutorial. While a dedicated machine is being used to ensure consistency, these commands can also be run from just about any machine including your personal workstation running macOS or Linux.
 
-Think of the `jumpbox` as the administration machine that you will use as a home base when setting up your Kubernetes cluster from the ground up. One thing we need to do before we get started is install a few command line utilities and clone the Kubernetes The Hard Way git repository, which contains some additional configuration files that will be used to configure various Kubernetes components throughout this tutorial. 
+Think of the `jumpbox` as the administration machine that you will use as a home base when setting up your Kubernetes cluster from the ground up. Before we get started we need to install a few command line utilities and clone the Kubernetes The Hard Way git repository, which contains some additional configuration files that will be used to configure various Kubernetes components throughout this tutorial.
 
 Log in to the `jumpbox`:
 
@@ -14,10 +14,13 @@ All commands will be run as the `root` user. This is being done for the sake of
 
 ### Install Command Line Utilities
 
-Now that you are logged into the `jumpbox` machine as the `root` user, you will install the command line utilities that will be used to preform various tasks throughout the tutorial. 
+Now that you are logged into the `jumpbox` machine as the `root` user, you will install the command line utilities that will be used to preform various tasks throughout the tutorial.
 
 ```bash
-apt-get -y install wget curl vim openssl git
+{
+  apt-get update
+  apt-get -y install wget curl vim openssl git
+}
 ```
 
 ### Sync GitHub Repository
@@ -65,30 +68,30 @@ wget -q --show-progress \
   -i downloads.txt
 ```
 
-Depending on your internet connection speed it may take a while to download the `584` megabytes of binaries, and once the download is complete, you can list them using the `ls` command:
+Depending on your internet connection speed it may take a while to download over `500` megabytes of binaries, and once the download is complete, you can list them using the `ls` command:
 
 ```bash
-ls -loh downloads
+ls -oh downloads
 ```
 
 ```text
-total 510M
--rw-r--r-- 1 root 48M Oct 15 02:37 cni-plugins-linux-arm64-v1.6.0.tgz
--rw-r--r-- 1 root 32M Nov  5 11:37 containerd-2.0.0-linux-arm64.tar.gz
--rw-r--r-- 1 root 17M Aug 13 03:48 crictl-v1.31.1-linux-arm64.tar.gz
--rw-r--r-- 1 root 16M Sep 11 11:28 etcd-v3.4.34-linux-arm64.tar.gz
--rw-r--r-- 1 root 84M Oct 22 21:41 kube-apiserver
--rw-r--r-- 1 root 79M Oct 22 21:41 kube-controller-manager
--rw-r--r-- 1 root 53M Oct 22 21:41 kubectl
--rw-r--r-- 1 root 72M Oct 22 21:41 kubelet
--rw-r--r-- 1 root 61M Oct 22 21:41 kube-proxy
--rw-r--r-- 1 root 60M Oct 22 21:41 kube-scheduler
--rw-r--r-- 1 root 11M Nov  1 15:23 runc.arm64
+total 544M
+-rw-r--r-- 1 root 48M Jan  6 08:13 cni-plugins-linux-arm64-v1.6.2.tgz
+-rw-r--r-- 1 root 34M Mar 17 19:33 containerd-2.1.0-beta.0-linux-arm64.tar.gz
+-rw-r--r-- 1 root 17M Dec  9 01:16 crictl-v1.32.0-linux-arm64.tar.gz
+-rw-r--r-- 1 root 21M Mar 27 16:15 etcd-v3.6.0-rc.3-linux-arm64.tar.gz
+-rw-r--r-- 1 root 87M Mar 11 20:31 kube-apiserver
+-rw-r--r-- 1 root 80M Mar 11 20:31 kube-controller-manager
+-rw-r--r-- 1 root 54M Mar 11 20:31 kubectl
+-rw-r--r-- 1 root 72M Mar 11 20:31 kubelet
+-rw-r--r-- 1 root 63M Mar 11 20:31 kube-proxy
+-rw-r--r-- 1 root 62M Mar 11 20:31 kube-scheduler
+-rw-r--r-- 1 root 11M Mar  4 04:14 runc.arm64
 ```
 
 ### Install kubectl
 
-In this section you will install the `kubectl`, the official Kubernetes client command line tool, on the `jumpbox` machine. `kubectl will be used to interact with the Kubernetes control once your cluster is provisioned later in this tutorial.
+In this section you will install the `kubectl`, the official Kubernetes client command line tool, on the `jumpbox` machine. `kubectl` will be used to interact with the Kubernetes control plane once your cluster is provisioned later in this tutorial.
 
 Use the `chmod` command to make the `kubectl` binary executable and move it to the `/usr/local/bin/` directory:
 
@@ -106,8 +109,8 @@ kubectl version --client
 ```
 
 ```text
-Client Version: v1.31.2
-Kustomize Version: v5.4.2
+Client Version: v1.32.3
+Kustomize Version: v5.5.0
 ```
 
 At this point the `jumpbox` has been set up with all the command line tools and utilities necessary to complete the labs in this tutorial.

docs/03-compute-resources.md

@@ -10,7 +10,7 @@ This tutorial will leverage a text file, which will serve as a machine database,
 IPV4_ADDRESS FQDN HOSTNAME POD_SUBNET
 ```
 
-Each of the columns corresponds to a machine IP address `IPV4_ADDRESS`, fully qualified domain name `FQDN`, host name `HOSTNAME`, and the IP subnet `POD_SUBNET`. Kubernetes assigns one IP address per `pod` and the `POD_SUBNET` represents the unique IP address range assigned to each machine in the cluster for doing so.  
+Each of the columns corresponds to a machine IP address `IPV4_ADDRESS`, fully qualified domain name `FQDN`, host name `HOSTNAME`, and the IP subnet `POD_SUBNET`. Kubernetes assigns one IP address per `pod` and the `POD_SUBNET` represents the unique IP address range assigned to each machine in the cluster for doing so.
 
 Here is an example machine database similar to the one used when creating this tutorial. Notice the IP addresses have been masked out. Your machines can be assigned any IP address as long as each machine is reachable from each other and the `jumpbox`.
 
@@ -19,12 +19,12 @@ cat machines.txt
 ```
 
 ```text
-XXX.XXX.XXX.XXX server.kubernetes.local server  
+XXX.XXX.XXX.XXX server.kubernetes.local server
 XXX.XXX.XXX.XXX node-0.kubernetes.local node-0 10.200.0.0/24
 XXX.XXX.XXX.XXX node-1.kubernetes.local node-1 10.200.1.0/24
 ```
 
-Now it's your turn to create a `machines.txt` file with the details for the three machines you will be using to create your Kubernetes cluster. Use the example machine database from above and add the details for your machines. 
+Now it's your turn to create a `machines.txt` file with the details for the three machines you will be using to create your Kubernetes cluster. Use the example machine database from above and add the details for your machines.
 
 ## Configuring SSH Access
 
@@ -44,7 +44,7 @@ Edit the `/etc/ssh/sshd_config` SSH daemon configuration file and set the `Permi
 
 ```bash
 sed -i \
-  's/^#PermitRootLogin.*/PermitRootLogin yes/' \
+  's/^#*PermitRootLogin.*/PermitRootLogin yes/' \
   /etc/ssh/sshd_config
 ```
 
@@ -66,25 +66,25 @@ ssh-keygen
 
 ```text
 Generating public/private rsa key pair.
-Enter file in which to save the key (/root/.ssh/id_rsa): 
-Enter passphrase (empty for no passphrase): 
-Enter same passphrase again: 
+Enter file in which to save the key (/root/.ssh/id_rsa):
+Enter passphrase (empty for no passphrase):
+Enter same passphrase again:
 Your identification has been saved in /root/.ssh/id_rsa
 Your public key has been saved in /root/.ssh/id_rsa.pub
 ```
 
 Copy the SSH public key to each machine:
 
 ```bash
-while read IP FQDN HOST SUBNET; do 
+while read IP FQDN HOST SUBNET; do
   ssh-copy-id root@${IP}
 done < machines.txt
 ```
 
 Once each key is added, verify SSH public key access is working:
 
 ```bash
-while read IP FQDN HOST SUBNET; do 
+while read IP FQDN HOST SUBNET; do
   ssh -n root@${IP} uname -o -m
 done < machines.txt
 ```
@@ -104,8 +104,8 @@ To configure the hostname for each machine, run the following commands on the `j
 Set the hostname on each machine listed in the `machines.txt` file:
 
 ```bash
-while read IP FQDN HOST SUBNET; do 
-    CMD="sed -i 's/^127.0.1.1.*/127.0.1.1\t${FQDN} ${HOST}/' /etc/hosts"
+while read IP FQDN HOST SUBNET; do
+    CMD="sed -i 's/^127.0.0.1.*/127.0.0.1\t${FQDN} ${HOST} localhost/' /etc/hosts"
     ssh -n root@${IP} "$CMD"
     ssh -n root@${IP} hostnamectl hostname ${HOST}
 done < machines.txt
@@ -127,7 +127,7 @@ node-1.kubernetes.local
 
 ## Host Lookup Table
 
-In this section you will generate a `hosts` file which will be appended to `/etc/hosts` file on `jumpbox` and to the `/etc/hosts` files on all three cluster members used for this tutorial. This will allow each machine to be reachable using a hostname such as `server`, `node-0`, or `node-1`.
+In this section you will generate a `hosts` file which will be appended to `/etc/hosts` file on the `jumpbox` and to the `/etc/hosts` files on all three cluster members used for this tutorial. This will allow each machine to be reachable using a hostname such as `server`, `node-0`, or `node-1`.
 
 Create a new `hosts` file and add a header to identify the machines being added:
 
@@ -139,7 +139,7 @@ echo "# Kubernetes The Hard Way" >> hosts
 Generate a host entry for each machine in the `machines.txt` file and append it to the `hosts` file:
 
 ```bash
-while read IP FQDN HOST SUBNET; do 
+while read IP FQDN HOST SUBNET; do
     ENTRY="${IP} ${FQDN} ${HOST}"
     echo $ENTRY >> hosts
 done < machines.txt
@@ -184,8 +184,6 @@ cat /etc/hosts
 ff02::1 ip6-allnodes
 ff02::2 ip6-allrouters
 
-
-
 # Kubernetes The Hard Way
 XXX.XXX.XXX.XXX server.kubernetes.local server
 XXX.XXX.XXX.XXX node-0.kubernetes.local node-0
@@ -220,6 +218,6 @@ while read IP FQDN HOST SUBNET; do
 done < machines.txt
 ```
 
-At this point hostnames can be used when connecting to machines from your `jumpbox` machine, or any of the three machines in the Kubernetes cluster. Instead of using IP addresses you can now connect to machines using a hostname such as `server`, `node-0`, or `node-1`.
+At this point, hostnames can be used when connecting to machines from your `jumpbox` machine, or any of the three machines in the Kubernetes cluster. Instead of using IP addresses you can now connect to machines using a hostname such as `server`, `node-0`, or `node-1`.
 
 Next: [Provisioning a CA and Generating TLS Certificates](04-certificate-authority.md)

docs/04-certificate-authority.md

@@ -4,7 +4,7 @@ In this lab you will provision a [PKI Infrastructure](https://en.wikipedia.org/w
 
 ## Certificate Authority
 
-In this section you will provision a Certificate Authority that can be used to generate additional TLS certificates for the other Kubernetes components. Setting up CA and generating certificates using `openssl` can be time-consuming, especially when doing it for the first time. To streamline this lab, I've included an openssl configuration file `ca.conf`, which defines all the details needed to generate certificates for each Kubernetes component. 
+In this section you will provision a Certificate Authority that can be used to generate additional TLS certificates for the other Kubernetes components. Setting up CA and generating certificates using `openssl` can be time-consuming, especially when doing it for the first time. To streamline this lab, I've included an openssl configuration file `ca.conf`, which defines all the details needed to generate certificates for each Kubernetes component.
 
 Take a moment to review the `ca.conf` configuration file:
 
@@ -57,7 +57,7 @@ for i in ${certs[*]}; do
   openssl req -new -key "${i}.key" -sha256 \
     -config "ca.conf" -section ${i} \
     -out "${i}.csr"
-  
+
   openssl x509 -req -days 3653 -in "${i}.csr" \
     -copy_extensions copyall \
     -sha256 -CA "ca.crt" \
@@ -81,15 +81,15 @@ Copy the appropriate certificates and private keys to the `node-0` and `node-1`
 
 ```bash
 for host in node-0 node-1; do
-  ssh root@$host mkdir /var/lib/kubelet/
-  
-  scp ca.crt root@$host:/var/lib/kubelet/
-    
-  scp $host.crt \
-    root@$host:/var/lib/kubelet/kubelet.crt
-    
-  scp $host.key \
-    root@$host:/var/lib/kubelet/kubelet.key
+  ssh root@${host} mkdir /var/lib/kubelet/
+
+  scp ca.crt root@${host}:/var/lib/kubelet/
+
+  scp ${host}.crt \
+    root@${host}:/var/lib/kubelet/kubelet.crt
+
+  scp ${host}.key \
+    root@${host}:/var/lib/kubelet/kubelet.key
 done
 ```
 

docs/05-kubernetes-configuration-files.md

@@ -8,11 +8,11 @@ In this section you will generate kubeconfig files for the `kubelet` and the `ad
 
 ### The kubelet Kubernetes Configuration File
 
-When generating kubeconfig files for Kubelets the client certificate matching the Kubelet's node name must be used. This will ensure Kubelets are properly authorized by the Kubernetes [Node Authorizer](https://kubernetes.io/docs/admin/authorization/node/).
+When generating kubeconfig files for Kubelets the client certificate matching the Kubelet's node name must be used. This will ensure Kubelets are properly authorized by the Kubernetes [Node Authorizer](https://kubernetes.io/docs/reference/access-authn-authz/node/).
 
 > The following commands must be run in the same directory used to generate the SSL certificates during the [Generating TLS Certificates](04-certificate-authority.md) lab.
 
-Generate a kubeconfig file for the node-0 worker node:
+Generate a kubeconfig file for the `node-0` and `node-1` worker nodes:
 
 ```bash
 for host in node-0 node-1; do
@@ -184,21 +184,21 @@ admin.kubeconfig
 
 ## Distribute the Kubernetes Configuration Files
 
-Copy the `kubelet` and `kube-proxy` kubeconfig files to the node-0 instance:
+Copy the `kubelet` and `kube-proxy` kubeconfig files to the `node-0` and `node-1` machines:
 
 ```bash
 for host in node-0 node-1; do
-  ssh root@$host "mkdir /var/lib/{kube-proxy,kubelet}"
-  
+  ssh root@${host} "mkdir -p /var/lib/{kube-proxy,kubelet}"
+
   scp kube-proxy.kubeconfig \
-    root@$host:/var/lib/kube-proxy/kubeconfig \
-  
+    root@${host}:/var/lib/kube-proxy/kubeconfig \
+
   scp ${host}.kubeconfig \
-    root@$host:/var/lib/kubelet/kubeconfig
+    root@${host}:/var/lib/kubelet/kubeconfig
 done
 ```
 
-Copy the `kube-controller-manager` and `kube-scheduler` kubeconfig files to the controller instance:
+Copy the `kube-controller-manager` and `kube-scheduler` kubeconfig files to the `server` machine:
 
 ```bash
 scp admin.kubeconfig \