From 09b356335c141c00e7b6bbbbafb0416e37dbfdc0 Mon Sep 17 00:00:00 2001 From: sspencerwire Date: Wed, 5 Mar 2025 12:31:51 -0600 Subject: [PATCH] Starting again to fix the issues (#2625) - edit all lab files - All files + replace passive voice with active + replace contractions with words + replace we with you --- .../kubernetes-the-hard-way/lab0-README.md | 5 +-- .../lab1-prerequisites.md | 5 +-- .../lab10-configuring-kubectl.md | 12 +++--- .../lab11-pod-network-routes.md | 10 ++--- .../lab12-smoke-test.md | 23 +++++------- .../kubernetes-the-hard-way/lab13-cleanup.md | 8 ++-- .../kubernetes-the-hard-way/lab2-jumpbox.md | 6 +-- .../lab3-compute-resources.md | 3 +- .../lab4-certificate-authority.md | 25 +++++++++---- .../lab5-kubernetes-configuration-files.md | 13 +++---- .../lab6-data-encryption-keys.md | 14 +++---- .../lab7-bootstrapping-etcd.md | 29 ++++++++------- ...b8-bootstrapping-kubernetes-controllers.md | 24 ++++++------ .../lab9-bootstrapping-kubernetes-workers.md | 37 +++++++++---------- 14 files changed, 103 insertions(+), 111 deletions(-) diff --git a/docs/labs/kubernetes-the-hard-way/lab0-README.md b/docs/labs/kubernetes-the-hard-way/lab0-README.md index 28cd78d52..b549d37e4 100644 --- a/docs/labs/kubernetes-the-hard-way/lab0-README.md +++ b/docs/labs/kubernetes-the-hard-way/lab0-README.md @@ -4,11 +4,10 @@ author: Wale Soyinka contributors: Steven Spencer --- -This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). -Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. - # Kubernetes The Hard Way (Rocky Linux) +> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. + This tutorial walks you through setting up Kubernetes the hard way. This guide is not for someone looking for a fully automated tool to bring up a Kubernetes cluster. Kubernetes The Hard Way, designed for learning, means taking the long route to ensure you understand each task required to bootstrap a Kubernetes cluster. Do not view the results of this tutorial as production ready, and it might not receive support from the community, but do not let that stop you from learning! diff --git a/docs/labs/kubernetes-the-hard-way/lab1-prerequisites.md b/docs/labs/kubernetes-the-hard-way/lab1-prerequisites.md index ea840e2d7..f74d58e5b 100644 --- a/docs/labs/kubernetes-the-hard-way/lab1-prerequisites.md +++ b/docs/labs/kubernetes-the-hard-way/lab1-prerequisites.md @@ -7,11 +7,10 @@ tags: - lab exercise --- -This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). -Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. - # Lab 1: Prerequisites +> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. + In this lab you will review the machine requirements necessary to follow this tutorial. ## Virtual or Physical Machines diff --git a/docs/labs/kubernetes-the-hard-way/lab10-configuring-kubectl.md b/docs/labs/kubernetes-the-hard-way/lab10-configuring-kubectl.md index 3c011d3fe..4dc461410 100644 --- a/docs/labs/kubernetes-the-hard-way/lab10-configuring-kubectl.md +++ b/docs/labs/kubernetes-the-hard-way/lab10-configuring-kubectl.md @@ -11,11 +11,9 @@ tags: - kubectl --- -This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). -Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. +# Lab 10: Configuring `kubectl` for Remote Access - -# Lab 10: Configuring kubectl for Remote Access +> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. In this lab you will generate a kubeconfig file for the `kubectl` command line utility based on the `admin` user credentials. @@ -25,7 +23,7 @@ In this lab you will generate a kubeconfig file for the `kubectl` command line u Each kubeconfig requires a Kubernetes API Server to connect to. -You should be able to ping `server.kubernetes.local` based on the `/etc/hosts` DNS entry from a previous lap. +You should be able to ping `server.kubernetes.local` based on the `/etc/hosts` DNS entry from an earlier lab. ```bash curl -k --cacert ca.crt \ @@ -64,8 +62,8 @@ Generate a kubeconfig file suitable for authenticating as the `admin` user: kubectl config use-context kubernetes-the-hard-way ``` -The results of running the command above should create a kubeconfig file in the default location `~/.kube/config` used by the `kubectl` commandline tool. This also means you can run the `kubectl` command without specifying a config. +The results of running the command above should create a kubeconfig file in the default location `~/.kube/config` used by the `kubectl` command line tool. This also means you can run the `kubectl` command without specifying a config. ## Verification @@ -87,7 +85,7 @@ List the nodes in the remote Kubernetes cluster: kubectl get nodes ``` -``` +```text NAME STATUS ROLES AGE VERSION node-0 Ready 30m v1.31.2 node-1 Ready 35m v1.31.2 diff --git a/docs/labs/kubernetes-the-hard-way/lab11-pod-network-routes.md b/docs/labs/kubernetes-the-hard-way/lab11-pod-network-routes.md index 2b0f07441..ec45afae4 100644 --- a/docs/labs/kubernetes-the-hard-way/lab11-pod-network-routes.md +++ b/docs/labs/kubernetes-the-hard-way/lab11-pod-network-routes.md @@ -11,12 +11,11 @@ tags: - kubectl --- -This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). -Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. - # Lab 11: Provisioning Pod Network Routes -Pods scheduled to a node receive an IP address from the node's Pod CIDR range. At this point pods can not communicate with other pods running on different nodes due to missing network [routes](https://cloud.google.com/compute/docs/vpc/routes). +> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. + +Pods scheduled to a node receive an IP address from the node's Pod CIDR range. At this point pods cannot communicate with other pods running on different nodes due to missing network [routes](https://cloud.google.com/compute/docs/vpc/routes). In this lab you will create a route for each worker node that maps the node's Pod CIDR range to the node's internal IP address. @@ -57,7 +56,7 @@ ssh root@node-1 < This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. + In this lab you will complete a series of tasks to ensure your Kubernetes cluster is functioning correctly. ## Data Encryption @@ -29,7 +28,7 @@ kubectl create secret generic kubernetes-the-hard-way \ --from-literal="mykey=mydata" ``` -Print a hexdump of the `kubernetes-the-hard-way` secret stored in etcd: +Print a hexdump of the `kubernetes-the-hard-way` secret stored in `etcd`: ```bash ssh root@server \ @@ -62,7 +61,7 @@ ssh root@server \ 0000015a ``` -The etcd key should be prefixed with `k8s:enc:aescbc:v1:key1`, which indicates the `aescbc` provider was used to encrypt the data with the `key1` encryption key. +You need to prefix the `etcd` key with `k8s:enc:aescbc:v1:key1`, which indicates using the `aescbc` provider to encrypt the data with the `key1` encryption key. ## Deployments @@ -108,7 +107,7 @@ Forwarding from 127.0.0.1:8080 -> 80 Forwarding from [::1]:8080 -> 80 ``` -In a new terminal make an HTTP request using the forwarding address: +In a new terminal make an HTTP request with the forwarding address: ```bash curl --head http://127.0.0.1:8080 @@ -126,7 +125,7 @@ ETag: "67a34638-267" Accept-Ranges: bytes ``` -Switch back to the previous terminal and stop the port forwarding to the `nginx` pod by typing `[CTRL]` + `[C]`: +Switch back to the previous terminal and stop the port forwarding to the `nginx` pod by typing ++ctrl+c++: ```text Forwarding from 127.0.0.1:8080 -> 80 @@ -154,7 +153,7 @@ kubectl logs $POD_NAME In this section you will verify the ability to [execute commands in a container](https://kubernetes.io/docs/tasks/debug-application-cluster/get-shell-running-container/#running-individual-commands-in-a-container). -Print the nginx version by executing the `nginx -v` command in the `nginx` container: +Print the `nginx` version by executing the `nginx -v` command in the `nginx` container: ```bash kubectl exec -ti $POD_NAME -- nginx -v @@ -166,7 +165,7 @@ nginx version: nginx/1.27.4 ## Services -In this section you will verify the ability to expose applications using a [Service](https://kubernetes.io/docs/concepts/services-networking/service/). +In this section you will verify the ability to expose applications with a [Service](https://kubernetes.io/docs/concepts/services-networking/service/). Expose the `nginx` deployment using a [NodePort](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport) service: @@ -175,7 +174,7 @@ kubectl expose deployment nginx \ --port 80 --type NodePort ``` -> The LoadBalancer service type can not be used because your cluster is not configured with [cloud provider integration](https://kubernetes.io/docs/getting-started-guides/scratch/#cloud-provider). Setting up cloud provider integration is out of scope for this tutorial. +> You cannot use the LoadBalancer service type because your cluster is not configured with [cloud provider integration](https://kubernetes.io/docs/getting-started-guides/scratch/#cloud-provider). Setting up cloud provider integration is out of scope for this tutorial. Retrieve the node port assigned to the `nginx` service: @@ -184,9 +183,7 @@ NODE_PORT=$(kubectl get svc nginx \ --output=jsonpath='{range .spec.ports[0]}{.nodePort}') ``` - - -Make an HTTP request using the IP address and the `nginx` node port: +Make an HTTP request with the IP address and the `nginx` node port: ```bash curl -I http://node-0:${NODE_PORT} diff --git a/docs/labs/kubernetes-the-hard-way/lab13-cleanup.md b/docs/labs/kubernetes-the-hard-way/lab13-cleanup.md index ad3b3b787..e9434b72d 100644 --- a/docs/labs/kubernetes-the-hard-way/lab13-cleanup.md +++ b/docs/labs/kubernetes-the-hard-way/lab13-cleanup.md @@ -7,17 +7,15 @@ tags: - lab exercise --- -This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). -Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. - - # Lab 13: Cleaning Up +> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. + In this lab you will delete the compute resources created during this tutorial. ## Compute Instances -Previous versions of this guide made use of GCP resources for various aspects of compute and networking. The current version is agnostic, and all configuration is performed on the `jumpbox`, `server`, or nodes. +Previous versions of this guide made use of GCP resources for various aspects of compute and networking. The current version is agnostic, and you perform all configurations on the `jumpbox`, `server`, or nodes. Clean up is as simple as deleting all virtual machines you created for this exercise. diff --git a/docs/labs/kubernetes-the-hard-way/lab2-jumpbox.md b/docs/labs/kubernetes-the-hard-way/lab2-jumpbox.md index f3fd2ca5b..5d72354bc 100644 --- a/docs/labs/kubernetes-the-hard-way/lab2-jumpbox.md +++ b/docs/labs/kubernetes-the-hard-way/lab2-jumpbox.md @@ -1,12 +1,12 @@ --- author: Wale Soyinka +contributors: Steven Spencer tags: - kubernetes - k8s - lab exercise --- - # Lab 2: Set Up The Jumpbox In this lab you will set up one of the four machines to be a `jumpbox`. You will use this machine to run commands in this tutorial. While the use of a dedicated machine is to ensure consistency, you can run these commands from just about any machine, including your personal workstation running macOS or Linux. @@ -56,7 +56,7 @@ pwd ## Download Binaries -Here you will download the binaries for the various Kubernetes components. Store these binaries in the `Downloads` directory on the `jumpbox`. This will reduce the amount of internet bandwidth required to complete this tutorial as you avoid downloading the binaries multiple times for each machine in our Kubernetes cluster. +Here you will download the binaries for the various Kubernetes components. Store these binaries in the `Downloads` directory on the `jumpbox`. This will reduce the amount of internet bandwidth required to complete this tutorial as you avoid downloading the binaries many times for each machine in our Kubernetes cluster. The `download.txt` file lists the binaries you will download, which you can review using the `cat` command: @@ -95,7 +95,7 @@ total 557M -rw-r--r--. 1 root 11M Feb 13 20:19 runc.amd64 ``` -## Install kubectl +## Install `kubectl` In this section you will install the `kubectl`, the official Kubernetes client command line tool, on the `jumpbox` machine. You will use `kubectl` to interact with the Kubernetes control plane after provisioning of your cluster completes later in this tutorial. diff --git a/docs/labs/kubernetes-the-hard-way/lab3-compute-resources.md b/docs/labs/kubernetes-the-hard-way/lab3-compute-resources.md index 62fe8ebb8..a6a0a5c77 100644 --- a/docs/labs/kubernetes-the-hard-way/lab3-compute-resources.md +++ b/docs/labs/kubernetes-the-hard-way/lab3-compute-resources.md @@ -1,5 +1,6 @@ --- author: Wale Soyinka +contributors: Steven Spencer tags: - kubernetes - k8s @@ -42,7 +43,7 @@ You will use SSH to configure the machines in the cluster. Verify that you have If you have `root` SSH access for each of your machines you can skip this section. -By default, a new `Rocky Linux` install disables SSH access for the `root` user. This is for security reasons, as the `root` user has total administrative control of unix-like systems. Weak passwords are very bad for internet connected machines. As mentioned earlier, you are going to enable `root` access over SSH to streamline the steps in this tutorial. Security is a trade-off, and in this case, you are optimizing for convenience. +By default, a new `Rocky Linux` install disables SSH access for the `root` user. This is for security reasons, as the `root` user has total administrative control of unix-like systems. Weak passwords are very bad for internet connected machines. As mentioned earlier, you are going to enable `root` access over SSH to streamline the steps in this tutorial. Security is a trade-off, and in this case, you are optimizing for convenience. Log on to each machine using SSH and your user account, then switch to the `root` user with the `su` command: diff --git a/docs/labs/kubernetes-the-hard-way/lab4-certificate-authority.md b/docs/labs/kubernetes-the-hard-way/lab4-certificate-authority.md index 20c7fa9fa..00811269c 100644 --- a/docs/labs/kubernetes-the-hard-way/lab4-certificate-authority.md +++ b/docs/labs/kubernetes-the-hard-way/lab4-certificate-authority.md @@ -1,19 +1,27 @@ --- author: Wale Soyinka +contributors: Steven Spencer tags: - kubernetes - k8s - lab exercise --- - # Lab 4: Provisioning a CA and Generating TLS Certificates -In this lab you will provision a [PKI Infrastructure](https://en.wikipedia.org/wiki/Public_key_infrastructure) using openssl to bootstrap a Certificate Authority, and generate TLS certificates for the following components: kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, and kube-proxy. The commands in this section should be run from the `jumpbox`. +In this lab you will provision a [PKI Infrastructure](https://en.wikipedia.org/wiki/Public_key_infrastructure) using openssl to bootstrap a Certificate Authority, and generate TLS certificates for the following components: + +* kube-apiserver +* kube-controller-manager +* kube-scheduler +* kubelet +* kube-proxy + +Run commands in this section from the `jumpbox`. ## 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 you will use to generate additional TLS certificates for the other Kubernetes components. Setting up CA and generating certificates with `openssl` can be time-consuming, especially when doing it for the first time. To streamline this lab, the inclusion of an `openssl` configuration file, `ca.conf`, defines all the details needed to generate certificates for each Kubernetes component. Take a moment to review the `ca.conf` configuration file: @@ -21,9 +29,9 @@ Take a moment to review the `ca.conf` configuration file: cat ca.conf ``` -You don't need to understand everything in the `ca.conf` file to complete this tutorial, but you should consider it a starting point for learning `openssl` and the configuration that goes into managing certificates at a high level. +You do not need to understand everything in the `ca.conf` file to complete this tutorial, but you should consider it a starting point for learning `openssl` and the configuration that goes into managing certificates at a high level. -Every certificate authority starts with a private key and root certificate. In this section we are going to create a self-signed certificate authority, and while that's all we need for this tutorial, this shouldn't be considered something you would do in a real-world production environment. +Every certificate authority starts with a private key and root certificate. In this section you are going to create a self-signed certificate authority, and while that is all you need for this tutorial, this is something you should not consider in a real-world production environment. Generate the CA configuration file, certificate, and private key: @@ -41,7 +49,8 @@ Results: ca.crt ca.key ``` -!!! Tip: +!!! Tip + To view the details encoded in the generated certificate file (ca.crt), you can use this openssl command `openssl x509 -in ca.crt -text -noout | less`. ## Create Client and Server Certificates @@ -85,7 +94,7 @@ ls -1 *.crt *.key *.csr ## Distribute the Client and Server Certificates -In this section you will copy the various certificates to every machine at a path where each Kubernetes component will search for its certificate pair. In a real-world environment these certificates should be treated like a set of sensitive secrets as they are used as credentials by the Kubernetes components to authenticate to each other. +In this section you will copy the various certificates to every machine at a path where each Kubernetes component will search for its certificate pair. In a real-world environment, you would treat these certificates as a set of sensitive secrets, because Kubernetes uses these components as credentials to authenticate to each other. Copy the appropriate certificates and private keys to the `node-0` and `node-1` machines: @@ -113,6 +122,6 @@ scp \ root@server:~/ ``` -> The `kube-proxy`, `kube-controller-manager`, `kube-scheduler`, and `kubelet` client certificates will be used to generate client authentication configuration files in the next lab. +> You will use the `kube-proxy`, `kube-controller-manager`, `kube-scheduler`, and `kubelet` client certificates to generate client authentication configuration files in the next lab. Next: [Generating Kubernetes Configuration Files for Authentication](lab5-kubernetes-configuration-files.md) diff --git a/docs/labs/kubernetes-the-hard-way/lab5-kubernetes-configuration-files.md b/docs/labs/kubernetes-the-hard-way/lab5-kubernetes-configuration-files.md index f49dd58d3..f1a06958c 100644 --- a/docs/labs/kubernetes-the-hard-way/lab5-kubernetes-configuration-files.md +++ b/docs/labs/kubernetes-the-hard-way/lab5-kubernetes-configuration-files.md @@ -7,12 +7,10 @@ tags: - lab exercise --- -This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). -Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. - - # Lab 5: Generating Kubernetes Configuration Files for Authentication +> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian (or similar) distributions for ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. + In this lab you will generate [Kubernetes client configuration files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/), typically called kubeconfigs, which configure Kubernetes clients to connect and authenticate to Kubernetes API Servers. ## Client Authentication Configs @@ -21,9 +19,9 @@ 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 you must match the client certificate to the Kubelet's node name. This will ensure Kubelets are properly authorized by the Kubernetes [Node Authorizer](https://kubernetes.io/docs/admin/authorization/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. +> The following commands must be run in the same directory used to generate the SSL certificates during the [Generating TLS Certificates](lab4-certificate-authority.md) lab. Generate a kubeconfig file for the node-0 and node-1 worker nodes: @@ -122,7 +120,6 @@ Results: kube-controller-manager.kubeconfig ``` - ### The kube-scheduler Kubernetes Configuration File Generate a kubeconfig file for the `kube-scheduler` service: @@ -189,7 +186,7 @@ admin.kubeconfig ## Distribute the Kubernetes Configuration Files -Copy the `kubelet` and `kube-proxy` kubeconfig files to the node-0 and node-1 instances: +Copy the `kubelet` and `kube-proxy` kubeconfig files to the `node-0` and `node-1` instances: ```bash for host in node-0 node-1; do diff --git a/docs/labs/kubernetes-the-hard-way/lab6-data-encryption-keys.md b/docs/labs/kubernetes-the-hard-way/lab6-data-encryption-keys.md index 9fbea3257..ff5e24eb6 100644 --- a/docs/labs/kubernetes-the-hard-way/lab6-data-encryption-keys.md +++ b/docs/labs/kubernetes-the-hard-way/lab6-data-encryption-keys.md @@ -7,15 +7,13 @@ tags: - lab exercise --- -This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). -Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. +# Lab 6: Generating the Data Encryption Configuration and Key - -# Lab 6: Generating the Data Encryption Config and Key +>This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. Kubernetes stores a variety of data including cluster state, application configurations, and secrets. Kubernetes supports the ability to [encrypt](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data) cluster data at rest. -In this lab you will generate an encryption key and an [encryption config](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#understanding-the-encryption-at-rest-configuration) suitable for encrypting Kubernetes Secrets. +In this lab you will generate an encryption key and an [encryption configuration](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#understanding-the-encryption-at-rest-configuration) suitable for encrypting Kubernetes Secrets. ## The Encryption Key @@ -25,16 +23,16 @@ Generate an encryption key: export ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64) ``` -## The Encryption Config File +## The Encryption Configuration File -Create the `encryption-config.yaml` encryption config file: +Create the `encryption-config.yaml` encryption configuration file: ```bash envsubst < configs/encryption-config.yaml \ > encryption-config.yaml ``` -Copy the `encryption-config.yaml` encryption config file to each controller instance: +Copy the `encryption-config.yaml` encryption configuration file to each controller instance: ```bash scp encryption-config.yaml root@server:~/ diff --git a/docs/labs/kubernetes-the-hard-way/lab7-bootstrapping-etcd.md b/docs/labs/kubernetes-the-hard-way/lab7-bootstrapping-etcd.md index 22c824afe..a2ae5999f 100644 --- a/docs/labs/kubernetes-the-hard-way/lab7-bootstrapping-etcd.md +++ b/docs/labs/kubernetes-the-hard-way/lab7-bootstrapping-etcd.md @@ -7,16 +7,15 @@ tags: - lab exercise --- -This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). -Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. +# Lab 7: Bootstrapping the `etcd` Cluster -# Lab 7: Bootstrapping the etcd Cluster +> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower).Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. -Kubernetes components are stateless and store cluster state in [etcd](https://github.com/etcd-io/etcd). In this lab you will bootstrap a three node etcd cluster and configure it for high availability and secure remote access. +Kubernetes components are stateless and store cluster state in [etcd](https://github.com/etcd-io/etcd). In this lab you will bootstrap a three node `etcd` cluster and configure it for high availability and secure remote access. ## Prerequisites -Copy `etcd` binaries and systemd unit files to the `server` instance: +Copy `etcd` binaries and `systemd` unit files to the `server` instance: ```bash scp \ @@ -25,7 +24,7 @@ scp \ root@server:~/ ``` -The commands in the following sections of this lab must be run on the `server` machine. Login to the `server` machine using the `ssh` command. Example: +Run the commands in the following sections of this lab on the `server` machine. Login to the `server` machine with the `ssh` command. Example: ```bash ssh root@server @@ -35,7 +34,7 @@ ssh root@server ### Install the etcd Binaries -If you don't already have it installed, first install the `tar` utility using `dnf`. And then extract and install the `etcd` server and the `etcdctl` command line utility: +If you do not already have it installed, first install the `tar` utility with `dnf`. And then extract and install the `etcd` server and the `etcdctl` command line utility: ```bash dnf -y install tar @@ -52,9 +51,9 @@ If you don't already have it installed, first install the `tar` utility using `d /etc/etcd/ ``` -Each etcd member must have a unique name within an etcd cluster. Set the etcd name to match the hostname of the current compute instance: +Each `etcd` member must have a unique name within an `etcd` cluster. Set the `etcd` name to match the hostname of the current compute instance: -Create the `etcd.service` systemd unit file: +Create the `etcd.service` `systemd` unit file: ```bash mv etcd.service /etc/systemd/system/ @@ -62,15 +61,17 @@ chmod 644 /etc/systemd/system/etcd.service ``` !!! Note - Although considered bad security form, you might have to temporarily or permanently disable SELinux if you run into any issues starting the etcd systemd service. The proper fix is to investigate and create the needed policy files using tools such as ausearch, audit2allow and so on. - The commands get SELinux out of the way and disable it is by running the following: - + + Although considered bad security form, you might have to temporarily or permanently disable SELinux if you run into any issues starting the `etcd` `systemd` service. The proper fix is to investigate and create the needed policy files with tools such as `ausearch`, `audit2allow` and others. + + The commands get SELinux out of the way and disable it is by running the following: + ```bash sudo sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config setenforce 0 ``` -### Start the etcd Server +### Start the `etcd` Server ```bash systemctl daemon-reload @@ -80,7 +81,7 @@ chmod 644 /etc/systemd/system/etcd.service ## Verification -List the etcd cluster members: +List the `etcd` cluster members: ```bash etcdctl member list diff --git a/docs/labs/kubernetes-the-hard-way/lab8-bootstrapping-kubernetes-controllers.md b/docs/labs/kubernetes-the-hard-way/lab8-bootstrapping-kubernetes-controllers.md index e5eb1bc15..6d12a5b16 100644 --- a/docs/labs/kubernetes-the-hard-way/lab8-bootstrapping-kubernetes-controllers.md +++ b/docs/labs/kubernetes-the-hard-way/lab8-bootstrapping-kubernetes-controllers.md @@ -10,16 +10,15 @@ tags: - runc --- -This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). -Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. - # Lab 8: Bootstrapping the Kubernetes Control Plane -In this lab you will bootstrap the Kubernetes control plane. The following components will be installed on the controller machine: Kubernetes API Server, Scheduler, and Controller Manager. +> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. + +In this lab you will bootstrap the Kubernetes control plane. You will install the following components on the controller machine: Kubernetes API Server, Scheduler, and Controller Manager. ## Prerequisites -Connect to the `jumpbox` and copy Kubernetes binaries and systemd unit files to the `server` instance: +Connect to the `jumpbox` and copy Kubernetes binaries and `systemd` unit files to the `server` instance: ```bash scp \ @@ -35,7 +34,7 @@ scp \ root@server:~/ ``` -The commands in the following sections of this lab must be run on the `server` machine. Login to the controller instance using the `ssh` command. Example: +You must run the commands in the following sections of this lab on the `server` machine. Login to the controller instance with the `ssh` command. Example: ```bash ssh root@server @@ -76,7 +75,7 @@ Install the Kubernetes binaries: /var/lib/kubernetes/ ``` -Create the `kube-apiserver.service` systemd unit file: +Create the `kube-apiserver.service` `systemd` unit file: ```bash mv kube-apiserver.service /etc/systemd/system/kube-apiserver.service @@ -90,7 +89,7 @@ Move the `kube-controller-manager` kubeconfig into place: mv kube-controller-manager.kubeconfig /var/lib/kubernetes/ ``` -Create the `kube-controller-manager.service` systemd unit file: +Create the `kube-controller-manager.service` `systemd` unit file: ```bash mv kube-controller-manager.service /etc/systemd/system/ @@ -130,7 +129,6 @@ mv kube-scheduler.service /etc/systemd/system/ > Allow up to 10 seconds for the Kubernetes API Server to fully initialize. - ### Verification ```bash @@ -145,9 +143,9 @@ Kubernetes control plane is running at https://127.0.0.1:6443 In this section you will configure RBAC permissions to allow the Kubernetes API Server to access the Kubelet API on each worker node. Access to the Kubelet API is required for retrieving metrics, logs, and executing commands in pods. -> This tutorial sets the Kubelet `--authorization-mode` flag to `Webhook`. Webhook mode uses the [SubjectAccessReview](https://kubernetes.io/docs/admin/authorization/#checking-api-access) API to determine authorization. +> This tutorial sets the Kubelet `--authorization-mode` flag to `Webhook`. `Webhook` mode uses the [SubjectAccessReview](https://kubernetes.io/docs/admin/authorization/#checking-api-access) API to determine authorization. -The commands in this section will affect the entire cluster and only need to be run on the controller node. +Run the commands in this section on the controller node, which will affect the entire cluster. ```bash ssh root@server @@ -160,9 +158,9 @@ kubectl apply -f kube-apiserver-to-kubelet.yaml \ --kubeconfig admin.kubeconfig ``` -### Verification +### RBAC Verification -At this point the Kubernetes control plane is up and running. Run the following commands from the `jumpbox` machine to verify it's working: +At this point the Kubernetes control plane is up and running. Run the following commands from the `jumpbox` machine to verify it is working: Make a HTTP request for the Kubernetes version info: diff --git a/docs/labs/kubernetes-the-hard-way/lab9-bootstrapping-kubernetes-workers.md b/docs/labs/kubernetes-the-hard-way/lab9-bootstrapping-kubernetes-workers.md index 358745178..d1722c6ee 100644 --- a/docs/labs/kubernetes-the-hard-way/lab9-bootstrapping-kubernetes-workers.md +++ b/docs/labs/kubernetes-the-hard-way/lab9-bootstrapping-kubernetes-workers.md @@ -11,16 +11,15 @@ tags: - kubectl --- -This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). -Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. - # Lab 9: Bootstrapping the Kubernetes Worker Nodes -In this lab you will bootstrap two Kubernetes worker nodes. The following components will be installed: [runc](https://github.com/opencontainers/runc), [container networking plugins](https://github.com/containernetworking/cni), [containerd](https://github.com/containerd/containerd), [kubelet](https://kubernetes.io/docs/admin/kubelet), and [kube-proxy](https://kubernetes.io/docs/concepts/cluster-administration/proxies). +> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture. + +In this lab you will bootstrap two Kubernetes worker nodes. You will install the following components: [runc](https://github.com/opencontainers/runc), [container networking plugins](https://github.com/containernetworking/cni), [containerd](https://github.com/containerd/containerd), [kubelet](https://kubernetes.io/docs/admin/kubelet), and [kube-proxy](https://kubernetes.io/docs/concepts/cluster-administration/proxies). ## Prerequisites -From the `jumpbox`, copy Kubernetes binaries and systemd unit files to each worker instance: +From the `jumpbox`, copy Kubernetes binaries and `systemd` unit files to each worker instance: ```bash for host in node-0 node-1; do @@ -57,9 +56,9 @@ for host in node-0 node-1; do done ``` -The commands in this lab must be separately run on each worker instance: `node-0`, `node-1`. We'll only show the required steps and commands for node-0. You'll need to repeat the exact steps and commands on node-1. +The commands in this lab must be separately run on each worker instance: `node-0`, `node-1`. The steps for `node-0` are the only ones shown. You will need to repeat the exact steps and commands on `node-1`. -Login to the worker node-0 instance using the `ssh` command. +Login to the worker `node-0` instance with the `ssh` command. ```bash ssh root@node-0 @@ -67,26 +66,26 @@ ssh root@node-0 ## Provisioning a Kubernetes Worker Node -Install the OS dependencies: +Install the operating system dependencies: ```bash dnf -y update dnf -y install socat conntrack ipset tar ``` -> The socat binary enables support for the `kubectl port-forward` command. +> The `socat` binary enables support for the `kubectl port-forward` command. ### Disable Swap -By default, the kubelet will fail to start if [swap](https://help.ubuntu.com/community/SwapFaq) is enabled. It is [recommended](https://github.com/kubernetes/kubernetes/issues/7294) that swap be disabled to ensure Kubernetes can provide proper resource allocation and quality of service. +If you have [swap](https://help.ubuntu.com/community/SwapFaq) enabled, the kubelet will fail to start. The [recommendation is to disable swap](https://github.com/kubernetes/kubernetes/issues/7294) to ensure Kubernetes provides proper resource allocation and quality of service. -Verify if swap is enabled: +Verify if swap is on: ```bash swapon --show ``` -If output is empty then swap is not enabled. If swap is enabled run the following command to disable swap immediately: +If output is empty then swap is not enabled. If the output is not empty, run the following command to disable swap immediately: ```bash swapoff -a @@ -131,7 +130,7 @@ Create the `bridge` network configuration file: mv 10-bridge.conf 99-loopback.conf /etc/cni/net.d/ ``` -### Configure containerd +### Configure `containerd` Install the `containerd` configuration files: @@ -158,8 +157,10 @@ Create the `kubelet-config.yaml` configuration file: ``` !!! Note - Although considered bad security form, you might have to temporarily or permanently disable SELinux if you run into any issues starting the needed systemd services. The proper fix is to investigate and create the needed policy files using tools such as ausearch, audit2allow and so on. - The fix for getting SELinux out of the way and disabling it is by running the following: + + Although considered bad security form, you might have to temporarily or permanently disable SELinux if you run into any issues starting the needed systemd services. The proper fix is to investigate and create the needed policy files using tools such as ausearch, audit2allow and so on. + + The fix for getting SELinux out of the way and disabling it is by running the following: ```bash sudo sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config @@ -184,19 +185,17 @@ List the registered Kubernetes nodes: ssh root@server "kubectl get nodes --kubeconfig admin.kubeconfig" ``` -``` +```text NAME STATUS ROLES AGE VERSION node-0 Ready 1m v1.32.0 ``` After completing all the previous steps in this lab on both `node-0` and `node-1` the output of the `kubectl get nodes` command should show: -``` +```text NAME STATUS ROLES AGE VERSION node-0 Ready 1m v1.32.0 node-1 Ready 10s v1.32.0 ``` - - Next: [Configuring kubectl for Remote Access](lab10-configuring-kubectl.md)