End-to-End Kubernetes with Rancher, RKE2, K3s, Fleet, Longhorn, and NeuVector

Creating a Deployment

The next step is to create a deployment for our todo-app. In Kubernetes, creating containers is done by placing them inside Pods.

ℹ️ A Pod is the smallest deployable unit in a cluster and represents a single instance of a running process. A Pod can contain one or more containers.

In our case, we will have only one container for the todo-app in each Pod. We can deploy multiple Pods to scale the application horizontally. In our example, we will deploy 3 Pod instances. In all cases, to deploy a Pod, we need to create a Deployment. This is what happens when you create a Deployment:

• A ReplicaSet is created to manage the Pods after the Deployment is created.
• Pod(s) is (are) created based on the container image specified in the Deployment.
• The ReplicaSet ensures that the desired number of Pod(s) is running at all times.

ℹ️ A Deployment is a higher-level concept that manages ReplicaSets and Pods. It configures different aspects of the Pods, such as the number of replicas, the container image, the resource limits, the health checks, etc.

To create a Deployment for our application, follow these steps:

• Navigate to the Rancher UI and select Cluster Management.
• Click on the Explore button next to the rke2-cluster cluster.
• Click on Workloads and then Deployments.
• Click on the Create button to create a new Deployment.
• Choose todo-app-namespace as the namespace.
• Choose a name for the Deployment, for example, todo-app-deployment.

• Change Replicas to 3.

• In the Container section, fill in the following details:

• Container Name: todo-app-container.
• Image: harbor.$WORKSPACE_PUBLIC_IP.sslip.io/todo-app/todo-app:latest. Make sure to replace $WORKSPACE_PUBLIC_IP with the actual IP address of the workspace machine.
• Pull Secrets: todo-app-registry.

ℹ️ In a production setup, using the latest tag has no guarantee that the image will be the same across all deployments and that the image is really the latest one. It's a good practice to use a specific tag (e.g., v1.0.0) to ensure that the same image is used across all deployments.

In the Health Check section of the container, we can define a health check for the container. There are three types of health checks:

• Readiness Probe: This is used to determine if the container is ready to accept traffic. If the readiness probe fails, the container will be removed from the endpoints of all services that match the selector.
• Liveness Probe: This is used to determine if the container is still running. If the liveness probe fails, the container will be restarted.
• Startup Probe: This is used to determine if the container has finished starting up. If the startup probe succeeds, the container is considered started and the liveness probe is enabled. This is useful for containers that take a long or variable time to start up.

For each of these probes, you can define the check methods:

• HTTP request: This sends an HTTP request to the container (e.g., GET /health).
• Command: This runs a command inside the container (e.g., curl -f http://localhost:5000/health).
• TCP socket: This opens a TCP connection to the container (e.g., tcp://localhost:5000).

For our todo-app, we will use a readiness probe that uses an HTTP request to check the health of the container. To do this, follow these steps: