RKE2 the Hard Way on Support Tools

RKE2 the Hard Way: Part 1 – Introduction and Prerequisites for Building a Kubernetes Cluster

Tue, 01 Apr 2025 00:00:00 +0000

Introduction

Welcome to the “RKE2 the Hard Way” training series! In this series, we’ll embark on a journey to build a Kubernetes cluster from scratch—mimicking the robust features of Rancher Kubernetes Engine 2 (RKE2)—without relying on any distribution-specific tools or installers.

It’s called the “hard way” because we’ll manually configure and set up each component of the Kubernetes cluster. This approach is designed to provide a deep understanding of how Kubernetes works under the hood and to highlight the automation and simplification RKE2 provides.

RKE2 the Hard Way: Part 10 – Installing Ingress Nginx

Tue, 01 Apr 2025 00:00:00 +0000

Part 10 – Installing Ingress Nginx

In this part of the “RKE2 the Hard Way” training series, we will install and configure Ingress Nginx for external access to services in our Kubernetes cluster. Ingress Nginx is a popular ingress controller for Kubernetes that uses NGINX as a reverse proxy and load balancer.

An ingress controller is essential because it:

Provides a single entry point to multiple services in your cluster
Handles SSL/TLS termination for your services
Enables host-based and path-based routing to backend services
Allows you to expose applications to the outside world without creating a LoadBalancer service for each one

At this point in our series, we have:

RKE2 the Hard Way: Part 11 – Cluster Verification and Access

Tue, 01 Apr 2025 00:00:00 +0000

Part 11 – Cluster Verification and Access

Congratulations! You’ve reached the final part of the “RKE2 the Hard Way” training series. At this point, we have:

Set up containerd and kubelet on all nodes
Generated all the necessary TLS certificates
Deployed etcd, kube-apiserver, kube-controller-manager, and kube-scheduler as static pods
Configured kubelet and kube-proxy on worker nodes
Installed Cilium CNI for pod networking
Deployed CoreDNS for cluster DNS resolution
Installed Ingress Nginx for external access

Now, let’s verify that everything is working correctly and set up kubectl for convenient cluster access.

RKE2 the Hard Way: Part 2 – Certificate Authority and TLS Certificates

Tue, 01 Apr 2025 00:00:00 +0000

Part 2 – Certificate Authority and TLS Certificates

In this part of the “RKE2 the Hard Way” training series, we will set up our own Certificate Authority (CA) and generate the necessary TLS certificates for securing our Kubernetes cluster. Kubernetes components communicate over TLS, and properly configured certificates are crucial for cluster security.

We’ll use cfssl, Cloudflare’s TLS toolkit, to create our CA and generate certificates.

✅ Assumption: All commands in this guide are run from node01, which is a Linux box.

RKE2 the Hard Way: Part 3 – Setting up containerd and kubelet

Tue, 01 Apr 2025 00:00:00 +0000

Part 3 – Setting up containerd and kubelet

In this part of the “RKE2 the Hard Way” training series, we will install and configure containerd (the container runtime) and kubelet (the Kubernetes node agent) on all our nodes. These components form the foundation of our Kubernetes cluster.

One of the key design decisions in RKE2 is to run the Kubernetes control plane components (etcd, kube-apiserver, kube-controller-manager, and kube-scheduler) as static pods managed by kubelet, rather than as systemd services. This approach simplifies deployment and maintenance, as kubelet manages the lifecycle of these critical components.

RKE2 the Hard Way: Part 4 – Setting up etcd Cluster as Static Pods

Tue, 01 Apr 2025 00:00:00 +0000

Part 4 – Setting up etcd Cluster as Static Pods

In this part of the “RKE2 the Hard Way” training series, we will set up etcd as a clustered key-value store using static pods managed by kubelet. etcd is a consistent and highly-available key-value store used by Kubernetes to store all cluster data, including the state of the cluster, configuration data, and metadata.

In RKE2, etcd is deployed as a static pod managed by kubelet, instead of running directly as a systemd service. This makes it easier to manage, as kubelet handles lifecycle operations, restarts, and monitoring.

RKE2 the Hard Way: Part 5 – Setting up kube-apiserver as Static Pods

Tue, 01 Apr 2025 00:00:00 +0000

Part 5 – Setting up kube-apiserver as Static Pods

In this part of the “RKE2 the Hard Way” training series, we will set up the Kubernetes API Server (kube-apiserver) as static pods managed by kubelet on each of our nodes. The API server is the central component of the Kubernetes control plane that exposes the Kubernetes API.

Using static pods for the API server is a key design principle in RKE2. This approach simplifies deployment and management, as kubelet will automatically start the API server and ensure it stays running. If an API server instance fails, kubelet will automatically restart it.

RKE2 the Hard Way: Part 6 – Setting up kube-controller-manager and kube-scheduler as Static Pods

Tue, 01 Apr 2025 00:00:00 +0000

Part 6 – Setting up kube-controller-manager and kube-scheduler as Static Pods

In this part of the “RKE2 the Hard Way” training series, we will set up the Kubernetes Controller Manager (kube-controller-manager) and Scheduler (kube-scheduler) as static pods managed by kubelet on each of our nodes.

The Controller Manager runs controller processes that regulate the state of the cluster (such as replication controllers, node controllers, and service account controllers)
The Scheduler is responsible for watching for newly created pods and assigning them to nodes

Using static pods for these components is a key design principle in RKE2, just like we did for etcd and kube-apiserver. This approach ensures high availability and automatic recovery in case of failures.

RKE2 the Hard Way: Part 7 – Setting up kubelet and kube-proxy on Worker Nodes

Tue, 01 Apr 2025 00:00:00 +0000

Part 7 – Setting up kubelet and kube-proxy on Worker Nodes

In this part of the “RKE2 the Hard Way” training series, we will configure kubelet to register with the Kubernetes API server and set up kube-proxy on our nodes. We already installed containerd and kubelet in Part 3, but now we need to finalize their configuration to connect to our Kubernetes control plane.

kubelet is the primary node agent that runs on each node. It ensures containers are running in a Pod and healthy.
kube-proxy maintains network rules on nodes. These network rules allow network communication to your Pods from inside or outside of your cluster.

✅ Note: In our setup, all nodes (node01, node02, node03) are both control plane and worker nodes. This is common for smaller clusters and provides high availability without needing separate worker nodes.

RKE2 the Hard Way: Part 8 – Installing Cilium CNI

Tue, 01 Apr 2025 00:00:00 +0000

Part 8 – Installing Cilium CNI

In this part of the “RKE2 the Hard Way” training series, we will install and configure the Cilium CNI (Container Network Interface). Cilium is a powerful, open-source CNI solution that provides advanced networking, security, and observability features for Kubernetes clusters.

At this point in our tutorial series, we have:

Set up all the core Kubernetes components (etcd, kube-apiserver, kube-controller-manager, kube-scheduler)
Configured kubelet and kube-proxy on our nodes

However, our cluster network is not yet functional for pod-to-pod communication. The CNI plugin is essential for implementing the Kubernetes networking model, which requires that:

RKE2 the Hard Way: Part 9 – Installing CoreDNS

Tue, 01 Apr 2025 00:00:00 +0000

Part 9 – Installing CoreDNS

In this part of the “RKE2 the Hard Way” training series, we will install and configure CoreDNS for Kubernetes cluster DNS resolution. CoreDNS is a flexible, extensible DNS server that serves as the cluster DNS provider in Kubernetes, allowing service discovery by DNS name.

DNS resolution is critical in a Kubernetes cluster because:

It enables services to be discovered by their names rather than IP addresses
It allows pods to find and communicate with other pods and services
It provides a stable naming scheme even when IPs change due to pod rescheduling

✅ Note: We already configured kubelet in Part 7 to use 10.43.0.10 as the DNS server, which is the IP we’ll use for the CoreDNS service.