DEV Community: Lloyd Rivers

CKA Full Course 2024: Day 15/40 Kubernetes Node Affinity Explained

Lloyd Rivers — Fri, 15 Nov 2024 20:51:37 +0000

Here we go with another video and fresh labs we need to do. But before we get going, let’s discuss the differences between Node Affinity and Taints and Tolerations because I’ve got to keep it real, I was (more than) a bit confused.

The key difference between Node Affinity and Taints and Tolerations lies in how they control pod placement on nodes:

Node Affinity: Specifies where pods can be scheduled based on node labels. It uses "required" or "preferred" criteria to influence pod placement.
Taints and Tolerations: Used to prevent pods from being scheduled on certain nodes unless they explicitly "tolerate" the node’s taint. Taints are applied to nodes, and tolerations are applied to pods to allow them to be scheduled on tainted nodes.

Exercises

1. Create a Pod with Node Affinity

Create a pod with nginx as the image.
Add a Node Affinity rule with the property requiredDuringSchedulingIgnoredDuringExecution, setting the condition disktype = ssd.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd

2. Check Pod Status

Check the status of the pod to understand why it’s not being scheduled.

Command:

kubectl get pods -o wide

Output:

NAME    READY   STATUS    RESTARTS   AGE     IP       NODE     NOMINATED NODE   READINESS GATES
nginx   0/1     Pending   0          3m55s   <none>   <none>   <none>           <none>

Explanation:

The issue is that we haven't labeled any nodes with disktype=ssd.

3. Add Node Label

Add the label disktype=ssd to the node kind-cka-cluster-worker.
Verify the pod status again to ensure it has been scheduled on worker01.

Command to Add the Label:

kubectl label nodes kind-cka-cluster-worker disktype=ssd

Recheck Pod Status:

To verify the change, run:

kubectl get pods -o wide

You should see the nginx pod in the Running state, with the NODE column showing kind-cka-cluster-worker.

4. Create a Second Pod with Node Affinity

Create a new pod configuration with redis as the image.
Add a Node Affinity rule with the property requiredDuringSchedulingIgnoredDuringExecution, setting disktype as the condition without specifying a value.

To accomplish this:

   cat pod.yml > redis.yml

Edit the redis.yml file:

Change the name to redis.
Update the image to redis.
Modify the nodeAffinity rule by removing the values section and changing the operator to Exists.

The final configuration should look like this:

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: Exists

Do not deploy this pod yet—we will first ensure that the cluster is prepared for this configuration.

Add the Label disktype (with no value) to worker02 Node:

To add a label with just the key disktype and no value to the node kind-cka-cluster-worker2, run the following command:

   kubectl label nodes kind-cka-cluster-worker2 disktype=

Verify the Node Labels:

Check if the label has been successfully added to the node:

   kubectl get nodes --show-labels

Look for the disktype label under LABELS for kind-cka-cluster-worker2.

Deploy the Redis Pod:

Ensure that the redis.yml file is configured with the nodeAffinity rule that requires the disktype key to exist.

Deploy the pod:

   kubectl apply -f redis.yml

Check Pod Scheduling:

Verify that the redis pod is now scheduled on worker02:

   kubectl get pods -o wide

The output should show kind-cka-cluster-worker2 in the NODE column for the redis pod.

Tags and Mentions

@piyushsachdeva
Day 15: Video Tutorial

CKA Full Course 2024: Day 14/40 Taints and Tolerations in Kubernetes

Lloyd Rivers — Sun, 10 Nov 2024 13:54:02 +0000

So, if you're following along, you might notice I'm experimenting with the format of these posts (sorry, lol). In this one, we'll tackle all the exercises Piyush has asked for right at the beginning. This way, if anyone needs help or gets stuck, they can find guidance here without having to go through a lot of details first.

Before you answer the first question, you need to have the cluster up and running. You should be really REALLY familiar with this by now, but just in case you're here randomly, here’s the contents of my config.yml:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: cka-cluster
nodes:
  - role: control-plane
    extraPortMappings:
      - containerPort: 30001
        hostPort: 30001
        listenAddress: "0.0.0.0"
        protocol: tcp
  - role: worker
  - role: worker

Now, you need to run the following command to create the cluster:

kind create cluster --name kind-cka-cluster --config config.yml

Exercises

1. Taint both Worker Nodes

To apply taints to the worker nodes, use the following kubectl taint commands:

kubectl taint nodes kind-cka-cluster-worker gpu=true:NoSchedule
kubectl taint nodes kind-cka-cluster-worker2 gpu=false:NoSchedule

2. Create a new pod with the image nginx and see why it's not getting scheduled on worker nodes and control plane nodes.

To create a new pod with the nginx image, run the following command:

kubectl run nginx --image=nginx

This will create the pod, but since it doesn't have a toleration for the taints applied to the worker nodes (gpu=true:NoSchedule and gpu=false:NoSchedule), the pod won't be scheduled on them.

To verify that the pod is not scheduled, use:

kubectl get pods

You should see that the pod is stuck in a Pending state due to the lack of tolerations for the taints.

3. Add Toleration to the Pod to Match the Taint on worker01

To add a toleration to the pod for the taint, we're going to take a bit of a roundabout approach. The reason is that I tried to update the YAML directly, but it got tricky with indentation. So, for that reason, I am deleting the pod and creating a new one.

First, delete the existing pod with the following command:

kubectl delete pod nginx

Then, create a new pod with the updated toleration by applying a YAML file. Below is the YAML configuration for the pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"

This configuration ensures that the pod will tolerate the taint gpu=true:NoSchedule and should be scheduled on worker01.

Finally, apply the YAML file:

kubectl apply -f pod.yml

To verify that the pod is scheduled on the correct worker node, you can check the pod’s status and the node it is running on:

kubectl get pods -o wide

4. Remove Taint from Control Plane Node

First, we need to check the taints applied to the control plane node. To do this, run the following command:

kubectl describe node kind-cka-cluster-control-plane

If you search (command + F on Mac) for the word taint, you'll see output similar to this:

Taints:node-role.kubernetes.io/control-plane:NoSchedule

This indicates that the control plane node currently has the taint node-role.kubernetes.io/control-plane:NoSchedule.

To remove this taint, use the following command:

kubectl taint nodes kind-cka-cluster-control-plane node-role.kubernetes.io/control-plane:NoSchedule-

The - at the end of the taint command signifies that you're removing the taint, not adding a new one.

After running the command, you can verify that the taint has been successfully removed by describing the node again:

kubectl describe node kind-cka-cluster-control-plane

You should see that the Taints section is now empty or no longer includes the node-role.kubernetes.io/control-plane:NoSchedule taint.

This chunk of code and the explanation are directly "borrowed" from the docs. I won't lie, sometimes I find it better to do the exercises without watching the video. I find I am retaining more info.

Create a New Pod Without Toleration

Create a new file named redis.yml, and add the following configuration:

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis

This configuration defines a simple pod named redis with a container running the redis image.

Deploy the Pod:

To deploy the pod using the YAML file, run:

kubectl apply -f redis.yml

Verify Pod Placement:

Once the pod is created, let’s verify that it’s running on the control plane node. Use the following command:

kubectl get pods -o wide

The output will show which node the redis pod is running on. Under the "NODE" column, you should see that it’s been scheduled on the control plane node, as it lacks the required tolerations to run on the tainted worker nodes.

Reapply Taint to Control Plane Node

To reapply the previously removed taint on the control plane node, run the following command:

kubectl taint nodes kind-cka-cluster-control-plane node-role.kubernetes.io/control-plane:NoSchedule

This command re-establishes the NoSchedule taint on the control plane node, preventing pods without a matching toleration from being scheduled on it.

Tags and Mentions

@piyushsachdeva
Day 14: Video Tutorial

VS Code YAML Plugin Setup for Kubernetes Beginners

Lloyd Rivers — Mon, 04 Nov 2024 11:10:18 +0000

Goal

Setting up the YAML plugin for VS Code to get autocompletion and schema support when working with Kubernetes YAML files.

Overview

Setting up YAML files for Kubernetes can be tricky, especially when you're just getting started. Here’s how to configure the Red Hat YAML plugin in VS Code to make life easier with autocomplete and an outline view.

Steps

1. Install the YAML Plugin

In VS Code:

Go to the Extensions view by clicking on the Extensions icon in the Activity Bar (or press Ctrl+Shift+X).
Search for "YAML" by Red Hat.
Install YAML (v1.15.0) by Red Hat.

2. Configure the YAML Plugin

Once the plugin is installed, follow these steps:

Go to Settings (click on the gear icon at the bottom left corner).
In the search bar at the top of the Settings panel, type YAML: Schemas.
Under YAML: Schemas, click Edit in settings.json to open your settings.json file.

3. Add Kubernetes Schema

In settings.json, add the Kubernetes schema for YAML files so the editor recognizes and autocompletes your Kubernetes configurations:

"yaml.schemas": {
    "kubernetes": "*.yaml"
}

This configuration associates the Kubernetes schema with any YAML file (*.yaml) in the current workspace.

4. Reload VS Code

Once you’ve saved settings.json, reload VS Code for the changes to take effect.

5. Using Autocomplete and Outline Features

With the YAML plugin configured, you’ll notice a few helpful features:

Autocomplete: As you start typing Kubernetes resources, VS Code will suggest options based on the schema, making it easier to write accurate YAML configurations. You can also press control spacebar in mac and get suggestions.

Outline View: Under the Outline section in the Explorer pane, you can view the structure of your YAML file, which is especially useful for navigating larger configurations.

Final Thoughts

This setup enhances your productivity by giving you real-time YAML assistance and structured navigation. It’s an ideal tool for beginners getting started with Kubernetes configurations in VS Code!

CKA Full Course 2024: Day 13/40 Static Pods, Manual Scheduling, Labels, and Selectors in Kubernetes

Lloyd Rivers — Sun, 03 Nov 2024 20:42:05 +0000

Task: Schedule a Pod Manually Without the Scheduler

In this task, we’ll be exploring how to bypass the Kubernetes scheduler by directly assigning a pod to a specific node in a cluster. This can be a useful approach for specific scenarios where you need a pod to run on a particular node without going through the usual scheduling process.

Prerequisites

We assume you have a Kubernetes cluster running, created with a KIND (Kubernetes in Docker) configuration similar to the one described in previous posts. Here, we’ve created a cluster named kind-cka-cluster:

kind create cluster --name kind-cka-cluster --config config.yml

Since we’ve already covered cluster creation with KIND in earlier posts, we won’t go into those details again.

Step 1: Verify the Cluster Nodes

To see the nodes available in this new cluster, run:

kubectl get nodes

You should see output similar to this:

NAME                           STATUS   ROLES           AGE   VERSION
kind-cka-cluster-control-plane Ready    control-plane   7m   v1.31.0

For this task, we’ll be scheduling our pod on kind-cka-cluster-control-plane.

Step 2: Define the Pod Manifest (pod.yml)

Now, let’s create a pod manifest in YAML format. Using the nodeName field in our pod configuration, we can specify the exact node for the pod, bypassing the Kubernetes scheduler entirely.

pod.yml:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: kind-cka-cluster-control-plane

In this manifest:

We set nodeName to kind-cka-cluster-control-plane, which means the scheduler will skip assigning a node, and the Kubelet on this specific node will handle placement instead.

This approach is a direct method for node selection, overriding other methods like nodeSelector or affinity rules.

According to Kubernetes documentation:

"nodeName is a more direct form of node selection than affinity or nodeSelector. nodeName is a field in the Pod spec. If the nodeName field is not empty, the scheduler ignores the Pod and the kubelet on the named node tries to place the Pod on that node. Using nodeName overrules using nodeSelector or affinity and anti-affinity rules."

For more details, refer to the Kubernetes documentation on node assignment.

Step 3: Apply the Pod Manifest

With our manifest ready, apply it to the cluster:

kubectl apply -f pod.yml

This command creates the nginx pod and assigns it directly to the kind-cka-cluster-control-plane node.

Step 4: Verify Pod Placement

Finally, check that the pod is running on the specified node:

kubectl get pods -o wide

The output should confirm that the nginx pod is indeed running on kind-cka-cluster-control-plane:

NAME    READY   STATUS    RESTARTS   AGE   IP           NODE                             NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          28s   10.244.0.5   kind-cka-cluster-control-plane   <none>           <none>

This verifies that by setting the nodeName field, we successfully bypassed the Kubernetes scheduler and directly scheduled our pod on the control plane node.

Task: Login to the control plane node and go to the directory of default static pod manifests and try to restart the control plane components.

To access the control plane node of our newly created cluster, use the following command:

docker exec -it kind-cka-cluster-control-plane bash

Navigate to the directory containing the static pod manifests:

cd /etc/kubernetes/manifests

Verify the current manifests:

ls

To restart the kube-controller-manager, move its manifest file temporarily:

mv kube-controller-manager.yaml /tmp

After confirming the restart, return the manifest file to its original location:

mv /tmp/kube-controller-manager.yaml /etc/kubernetes/manifests/

With these steps, we successfully demonstrated how to access the control plane and manipulate the static pod manifests to manage the lifecycle of control plane components.

Confirming the Restart of kube-controller-manager

After temporarily moving the kube-controller-manager.yaml manifest file to /tmp, we can verify that the kube-controller-manager has restarted. As mentioned in previous posts, I am using k9s, which does clearly show the restart, but for readers without k9s, try the following command

Inspect Events:
To gather more information, use:

   kubectl describe pod kube-controller-manager-kind-cka-cluster-control-plane -n kube-system

Look for events at the end of the output. A successful restart will show events similar to:

   Events:
     Type    Reason   Age                    From     Message
     ----    ------   ----                   ----     -------
     Normal  Killing  4m12s (x2 over 8m32s)  kubelet  Stopping container kube-controller-manager
     Normal  Pulled   3m6s (x2 over 7m36s)   kubelet  Container image "registry.k8s.io/kube-controller-manager:v1.31.0" already present on machine
     Normal  Created  3m6s (x2 over 7m36s)   kubelet  Created container kube-controller-manager
     Normal  Started  3m6s (x2 over 7m36s)   kubelet  Started container kube-controller-manager

The presence of "Killing," "Created," and "Started" events indicates that the kube-controller-manager was stopped and then restarted successfully.

Cleanup

Once you have completed your tasks and confirmed the behavior of your pods, it is important to clean up any resources that are no longer needed. This helps maintain a tidy environment and frees up resources in your cluster.

List Pods:
First, you can check the current pods running in your cluster:

   kubectl get pods

You might see output like this:

   NAME    READY   STATUS    RESTARTS   AGE
   nginx   1/1     Running   0          35m

Describe Pod:
To get more information about a specific pod, use the describe command:

   kubectl describe pod nginx

This will give you details about the pod, such as its name, namespace, node, and other configurations:

   Name:             nginx
   Namespace:        default
   Priority:         0
   Service Account:  default
   Node:             kind-cka-cluster-control-plane/172.19.0.3

Delete the Pod:
If you find that the pod is no longer needed, you can safely delete it with the following command:

   kubectl delete pod nginx

Verify Deletion:
After executing the delete command, you can verify that the pod has been removed by listing the pods again:

   kubectl get pods

Ensure that the nginx pod no longer appears in the list.

By performing these cleanup steps, you help ensure that your Kubernetes cluster remains organized and efficient.

Creating Multiple Pods with Specific Labels

In this section, we will create three pods based on the nginx image, each with a unique name and specific labels indicating different environments: env:test, env:dev, and env:prod.

Step 1: Create the Script

First, we'll create a script that contains the commands to generate the pods. I am using a script for 2 reasons:

I want to learn bash,
If I need to create 3 nodes again I only have to run the file instead of type it all out again.

Use the following command to create the script file:

vi create-pods.sh

Next, paste the following code into the file:

#!/bin/bash

# Create pod1 with label env=test
kubectl run pod1 --image=nginx --labels=env=test

# Create pod2 with label env=dev
kubectl run pod2 --image=nginx --labels=env=dev

# Create pod3 with label env=prod
kubectl run pod3 --image=nginx --labels=env=prod

# Wait for a few seconds to allow the pods to start
sleep 5

# Verify the created pods and their labels
echo "Verifying created pods and their labels:"
kubectl get pods --show-labels

Step 2: Make the Script Executable

After saving the file, make the script executable with the following command:

chmod +x create-pods.sh

Step 3: Execute the Script

Run the script to create the pods:

./create-pods.sh

You should see output indicating the creation of the pods:

pod/pod1 created
pod/pod2 created
pod/pod3 created

Step 4: Verify the Created Pods

The script will then display the status of the created pods:

Verifying created pods and their labels:
NAME   READY   STATUS              RESTARTS   AGE   LABELS
pod1   0/1     ContainerCreating   0          5s    env=test
pod2   0/1     ContainerCreating   0          5s    env=dev
pod3   0/1     ContainerCreating   0          5s    env=prod

At this point, you can filter the pods based on their labels. For example, to find the pod with the env=dev label, use the following command:

kubectl get po -l env=dev

You should see output confirming the pod is running:

NAME   READY   STATUS    RESTARTS   AGE
pod2   1/1     Running   0          4m9s

Tags and Mentions

@piyushsachdeva
Day 13: Video Tutorial

CKA Full Course 2024: Day 12/40 Daemonsets, Job and Cronjob in Kubernetes

Lloyd Rivers — Thu, 31 Oct 2024 20:41:48 +0000

Since this post is all about deploying an Nginx frontend and gathering metrics from our cluster, let’s start with a brief overview of what we’re building and the tools involved.

Note: Originally, I wasn’t planning to include another introduction, but given the complexity of today’s setup, a recap will ensure everyone has a solid understanding before diving in.

Project Overview

In this tutorial, we’re deploying a simple Nginx server that serves as our frontend. This setup will serve the default Nginx homepage, which you can access via your browser once it’s running. We’ll also configure a health-checking system using a CronJob, which will periodically check if our Nginx server is up and running, returning a status code as confirmation.

Additionally, we’ll be setting up a DaemonSet to run a Node Exporter on every node in our cluster. This Node Exporter will gather metrics, giving us insights into the performance and resource usage of our app and cluster.

Key Concepts

To make sure we're all on the same page, here’s a breakdown of the main components we’re working with:

Nginx: Nginx is a web server that can serve static content (like HTML) or be configured as a reverse proxy or load balancer. Here, we’re using it to serve the default Nginx homepage, which acts as our app’s frontend.
CronJob: In Kubernetes, a CronJob allows you to run a job at specific intervals, just like scheduled tasks. Here, we’re using a CronJob to regularly check the health of our Nginx server. If the Nginx server is up and running, it will return a status code that confirms it’s reachable.
DaemonSet: A DaemonSet ensures that a specific pod runs on every node in your Kubernetes cluster. In this setup, we’re using it to run a Node Exporter on each node, collecting metrics like CPU and memory usage, which is crucial for monitoring app health and resource consumption.

With this structure in mind, we’ll dive into the YAML files needed to set up each component.

Prerequisites

Before we start, ensure you have a configuration file to create the Kubernetes cluster. Refer to the Kind Quick Start guide for detailed instructions on setting up your Kind cluster.

Cluster Configuration (config.yml)

Create a file named config.yml with the following content to define your Kind cluster:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: cka-cluster  
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 30001  
    hostPort: 30001
    listenAddress: "0.0.0.0" 
    protocol: tcp
- role: worker  
- role: worker

Run the following command to create the cluster:

kind create cluster --name kind-cka-cluster --config config.yml

Use the following command to set the context to the new cluster:

kubectl config use-context kind-kind-cka-cluster

Tasks

Here’s the amended section with a focus on what you are doing and encouraging the reader to explore the documentation further:

Create a DaemonSet

The task here is to create a DaemonSet in Kubernetes. A DaemonSet ensures that all nodes in the cluster run a copy of the specified pod. For this example, I am setting up the Prometheus Node Exporter, which will allow for monitoring metrics from each node. While I demonstrated this based on the video, I encourage the reader to visit the Kubernetes documentation to read more about DaemonSets and their configurations for a deeper understanding.

Solution

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: prometheus-node-exporter
  namespace: kube-system
  labels:
    app: prometheus-node-exporter
spec:
  selector:
    matchLabels:
      app: prometheus-node-exporter
  template:
    metadata:
      name: prometheus-node-exporter
      labels:
        app: prometheus-node-exporter
    spec:
      containers:
      - image: prom/node-exporter:v0.16.0
        imagePullPolicy: IfNotPresent
        name: prometheus-node-exporter
        ports:
        - name: prom-node-exp
          #^ must be an IANA_SVC_NAME (at most 15 characters, ..)
          containerPort: 9100
          hostPort: 9100
      tolerations:
      - key: "node-role.kubernetes.io/master"
        effect: "NoSchedule"
      hostNetwork: true
      hostPID: true
      hostIPC: true
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/app-metrics: 'true'
    prometheus.io/app-metrics-path: '/metrics'
  name: prometheus-node-exporter
  namespace: kube-system
  labels:
    app: prometheus-node-exporter
spec:
  clusterIP: None
  ports:
    - name: prometheus-node-exporter
      port: 9100
      protocol: TCP
  selector:
    app: prometheus-node-exporter
  type: ClusterIP

Create a CronJob

This task involves creating a CronJob that runs every 5 minutes. I chose not to follow the video tutorial here. This CronJob checks if the app is up by returning a 200 status code and the HTML content if successful

Solution

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nginx-app-health-check
spec:
  schedule: "*/5 * * * *"  # Runs every 5 minutes
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: check-web-server
              image: appropriate/curl
              command:
                - /bin/sh
                - -c
                - |
                  status_code=$(curl -s -o /dev/null -w '%{http_code}' http://nginx-app-svc.default.svc.cluster.local)
                  homepage_content=$(curl -s http://nginx-app-svc.default.svc.cluster.local)
                  echo "Status Code: $status_code"
                  echo "Homepage Content: $homepage_content"
          restartPolicy: OnFailure

This configuration ensures the CronJob runs every 5 minutes to check the health of the Nginx app. Let me know if any additional clarifications would help here!

Putting It All Together

In this section, we combine our Kubernetes resources to deploy the Nginx application effectively. Below are the configurations for both the Deployment and Service.

Nginx Deployment

This Deployment ensures that we have 3 replicas of our Nginx application running:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: nginx-app
spec:
  replicas: 3  
  selector:
    matchLabels:
      app: nginx-app
  template:
    metadata:
      labels:
        app: nginx-app
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.4-alpine
        ports:
        - containerPort: 80

Nginx Service

The following Service exposes the Nginx application, allowing external traffic to access it via a specified node port:

apiVersion: v1
kind: Service
metadata:
  name: nginx-app-svc
spec:
  selector:
    app: nginx-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30001
  type: NodePort

Common Gotchas

Label Consistency: Ensure that the labels in the Deployment and Service match correctly. In this case, both resources use app: nginx-app to ensure that the Service can route traffic to the right pods.
NodePort Configuration: When using NodePort, make sure the specified node port (e.g., 30001) does not conflict with other services running on the same node.
Replica Count: The replica count in the Deployment affects availability. In this example, we specified 3 replicas to ensure high availability of the Nginx app.
Container Port: Confirm that the container port in the Deployment matches the target port specified in the Service to ensure proper routing of traffic.

Final thoughts...

Today, I focused on building components in Kubernetes, specifically DaemonSets, Jobs, and CronJobs. Here are my key takeaways:

Understanding DaemonSets: DaemonSets ensure that a specific pod runs on all or selected nodes in a Kubernetes cluster. This is particularly useful for monitoring and logging applications that need to be deployed across every node.
Utilizing Jobs and CronJobs: Jobs are great for executing tasks that run to completion, while CronJobs allow for scheduling tasks at specified intervals. This functionality is essential for automating routine tasks, such as health checks or backups.
Leveraging Documentation: I realized the importance of the Kubernetes documentation as a crucial resource when building applications. It's empowering to have access to comprehensive guides and examples, which enhance my ability to troubleshoot and implement features effectively.
Deep Learning through Hands-On Practice: Engaging in building applications from scratch aligns perfectly with my desire for deep learning. I find that struggling through challenges helps me develop a stronger grasp of concepts, solidifying my knowledge and skills.
Experimentation and Exploration: Taking the initiative to explore beyond tutorials fosters a sense of ownership over the learning process. It’s fulfilling to construct solutions independently, reinforcing my understanding of Kubernetes.

Tags and Mentions

@piyushsachdeva
Day 12: Video Tutorial

CKA Full Course 2024: Day 11/40 Multi Container Pod Kubernetes - Sidecar vs Init Container

Lloyd Rivers — Tue, 29 Oct 2024 09:19:11 +0000

A Note from Me

In this project, I wanted to apply Kubernetes concepts like init containers and sidecar containers, but I didn’t want to just follow along with a tutorial.

My goal was to build something memorable.

After some brainstorming, I present to you the Get Me App!

What Get Me App Does

The Get Me App is designed to dynamically fetch and display content from various GitHub repositories. The application runs within a Kubernetes pod and comprises two primary components:

Nginx Container: This serves as the main application, hosting the dynamically fetched content. It's lightweight and efficient, making it ideal for serving static web pages.
Sidecar Container: This runs alongside the primary nginx container. It is responsible for refreshing the content every 5 seconds by fetching the latest HTML from a randomly selected GitHub page. This ensures that the content served by Nginx is always up to date.
Init Container: This initializes the environment before the main containers start. It checks for the availability of the Get Me App Service by resolving its DNS entry. This step ensures that the application is ready to interact with the service once it starts running. Read more here (I had to)

The nginx container then serves the updated HTML webpage, making it accessible through a browser via a NodePort service.

Prerequisites

Before we start, ensure you have a configuration file to create the Kubernetes cluster. Refer to the Kind Quick Start guide for detailed instructions on setting up your Kind cluster.

Cluster Configuration (config.yml)

Create a file named config.yml with the following content to define your Kind cluster:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: cka-cluster  
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 30001  # Change this to match the NodePort
    hostPort: 30001
    listenAddress: "0.0.0.0" 
    protocol: tcp
- role: worker  
- role: worker

Run the following command to create the cluster:

kind create cluster --name kind-cka-cluster --config config.yml

Use the following command to set the context to the new cluster:

kubectl config use-context kind-kind-cka-cluster

Step 1: Create the Project Directory and File

First, set up the directory and file structure for the project.

mkdir get-me-app
cd get-me-app
nano get-me-app.yml

Step 2: Define the Kubernetes Pod Specification

In the get-me-app.yml file, we’ll define a Kubernetes pod that includes the nginx container, a sidecar container for content refreshing, and an init container for initial data fetch.

apiVersion: v1
kind: Pod
metadata:
  name: get-me-app
  labels:
    app: get-me-app
spec:
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup get-me-app-service.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for get-me-app-service; sleep 2; done"]

  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html

  - name: content-refresher
    image: busybox
    command: ["sh", "-c", "while true; do url=$(shuf -n 1 -e https://github.com/piyushsachdeva/CKA-2024 https://github.com/kubernetes https://github.com/jenkinsci https://github.com/techiescamp/kubernetes-learning-path https://github.com/NotHarshhaa/kubernetes-learning-path); wget -O /work-dir/index.html \"$url\"; sleep 5; done"]
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"

  volumes:
  - name: workdir
    emptyDir: {}

What Each Part of This Pod Specification Does

nginx container: This is the primary container, serving content on port 80. The volumeMount makes the /usr/share/nginx/html directory available in the pod’s workdir volume.
Sidecar container (content-refresher): This container runs a while true loop, downloading the latest version of the webpage every 5 seconds. This ensures that the content in the workdir volume stays updated.
Init container (init-myservice): This waits for the get-me-app-service to become available by continuously performing a DNS lookup. It runs only once during initialization and does not restart after completion.
Volumes: The workdir volume (an emptyDir type) is shared among the containers, allowing the init container, sidecar, and nginx to access and serve the same content.

Step 3: Test Locally with NodePort (Optional)

To make the app accessible through a browser on your local machine, configure a NodePort service to expose the pod’s port 80.

Add this service definition in get-me-app-service.yml:

apiVersion: v1
kind: Service
metadata:
  name: get-me-app-service
spec:
  type: NodePort
  selector:
    app: get-me-app
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30001

Deploy the setup with:

kubectl apply -f get-me-app.yml

kubectl apply -f get-me-app-service.yml

Access it by visiting http://localhost:30001 in your browser, and you should the github page. Refresh the page after 5 seconds and you should see a different github page.

Key Takeaways

This project helped me understand how init containers can initialize shared resources and how sidecar containers keep those resources updated for the main application. It's an engaging way to experiment with and learn about real-time data handling in Kubernetes.

Here’s the formatted content for the section you provided:

Tags and Mentions

@piyushsachdeva
Day 8: Video Tutorial

End Notes: Please remember that this project is not part of the video tutorials. I wanted to build something on my own using the concepts from the tutorial as general guidance.

CKA Full Course 2024: Day 10/40 Kubernetes Namespace Explained

Lloyd Rivers — Mon, 28 Oct 2024 12:42:36 +0000

Note to the Reader

In this post, I'm experimenting with a more concise format. The highly detailed posts are taking 2-3 days to complete, so in this one, I’ll focus on describing Kubernetes Namespaces and their components before moving directly into exercises.

If you saw the content of the post move around a little, it is because I was getting errors trying to post it and what I had written had not been saved.

Kubernetes Namespaces

Namespaces are a way to divide cluster resources between multiple users or applications. They help organize objects in Kubernetes and manage access, often in scenarios where different environments (e.g., development, staging, and production) coexist within the same cluster. With namespaces, we can isolate resources while ensuring that different teams or applications can share the same infrastructure.

Namespaces are ideal when you need logical separation but want to avoid the complexity of multiple clusters.

Create Two Namespaces: `ns1` and `ns2`

Create the first namespace:

kubectl create namespace ns1

Create the second namespace:

kubectl create namespace ns2

Note: At this point, it may be easier to work in two terminal windows. In the first terminal, connect to the ns1 namespace. In the second terminal, connect to the ns2 namespace using the following commands:

For the first terminal:

   kubectl config set-context --current --namespace=ns1

For the second terminal:

   kubectl config set-context --current --namespace=ns2

Create a deployment with a single replica in each of these namespaces with the image as nginx and names as deploy-ns1 and deploy-ns2, respectively

Deployment for ns1 – Save this configuration as ns1-deployment.yml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-ns1
  namespace: ns1
  labels:
    app: nginx
spec:
  replicas: 1  
  selector:
    matchLabels:
      app: deploy-ns1
  template:
    metadata:
      labels:
        app: deploy-ns1
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.4-alpine
        ports:
        - containerPort: 80

Deployment for ns2 – Save this configuration as ns2-deployment.yml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-ns2
  namespace: ns2
  labels:
    app: nginx
spec:
  replicas: 1  
  selector:
    matchLabels:
      app: deploy-ns2
  template:
    metadata:
      labels:
        app: deploy-ns2
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.4-alpine
        ports:
        - containerPort: 80

Apply each YAML configuration to create the deployments

kubectl apply -f ns1-deployment.yml

kubectl apply -f ns2-deployment.yml

Get the IP address of each of the pods

Namespace ns1

   kubectl get pods -o wide -n ns1

Example Output:

   NAME                          READY   STATUS    RESTARTS   AGE   IP           NODE                 NOMINATED NODE   READINESS GATES
   deploy-ns1-68b96c55c4-db4b9   1/1     Running   0          13m   10.244.2.8   cka-cluster-worker   <none>           <none>

Namespace ns2

   kubectl get pods -o wide -n ns2

Example Output:

   NAME                          READY   STATUS    RESTARTS   AGE   IP            NODE                  NOMINATED NODE   READINESS GATES
   deploy-ns2-7c6646cf97-76xcz   1/1     Running   0          14m   10.244.1.10   cka-cluster-worker2   <none>           <none>

Exec into the pod of `deploy-ns1` and try to curl the IP address of the pod running on `deploy-ns2`

kubectl exec -it deploy-ns1-68b96c55c4-db4b9 -n ns1 -- curl 10.244.1.10

Upon successful execution, you should see an HTML response indicating that the deploy-ns1 pod can successfully connect to the deploy-ns2 pod, confirming that the NGINX server is up and running:

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to nginx!</title>
    <style>
        html { color-scheme: light dark; }
        body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; }
    </style>
</head>
<body>
    <h1>Welcome to nginx!</h1>
    <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p>
    <p>For online documentation and support, please refer to <a href="http://nginx.org/">nginx.org</a>.<br/>
    Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p>
    <p><em>Thank you for using nginx.</em></p>
</body>
</html>

Scale both deployments from 1 to 3 replicas

Note: I chose to scale through the YAML file for source control purposes.

Update the replicas field in each deployment YAML file:

ns1-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-ns1
  namespace: ns1
  labels:
    app: nginx
spec:
  replicas: 3  # Updated to 3 replicas
  selector:
    matchLabels:
      app: deploy-ns1
  template:
    metadata:
      labels:
        app: deploy-ns1
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.4-alpine
        ports:
        - containerPort: 80

ns2-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-ns2
  namespace: ns2
  labels:
    app: nginx
spec:
  replicas: 3  # Updated to 3 replicas
  selector:
    matchLabels:
      app: deploy-ns2
  template:
    metadata:
      labels:
        app: deploy-ns2
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.4-alpine
        ports:
        - containerPort: 80

Create two services to expose both of your deployments and name them svc-ns1 and svc-ns2

apiVersion: v1
kind: Service
metadata:
  name: svc-ns1
  namespace: ns1  
spec:
  selector:
    app: deploy-ns1  
  ports:
    - protocol: TCP
      port: 80         
      targetPort: 80   
  type: ClusterIP

apiVersion: v1
kind: Service
metadata:
  name: svc-ns2
  namespace: ns2  
spec:
  selector:
    app: deploy-ns2  
  ports:
    - protocol: TCP
      port: 80         
      targetPort: 80   
  type: ClusterIP

Apply the Service Definitions

Once you’ve created both YAML files (let's say svc-ns1.yml and svc-ns2.yml), you can apply them using the following commands:

kubectl apply -f svc-ns1.yml

kubectl apply -f svc-ns2.yml

Step 5: Verify the Services

After applying, you can verify that your services are up and running by executing:

kubectl get services -n ns1

kubectl get services -n ns2

This should show you the `svc-ns1` and `svc-ns2` services, along with their cluster IPs and ports.

Exec into each pod and try to curl the IP address of the service running on the other namespace.

kubectl exec -it <pod-name> -n ns1 -- curl <ip-address>

This curl should work (it did).

Now try curling the service name instead of IP

You will notice that you are getting an error and cannot resolve the host.

kubectl exec -it deploy-ns1-68b96c55c4-db4b9 -n ns1 -- curl svc-ns2

Now use the FQDN of the service and try to curl again

This should work:

kubectl exec -it deploy-ns1-68b96c55c4-db4b9 -n ns1 -- curl svc-ns2.ns2

In the end, delete both the namespaces

This should delete the services and deployments underneath them:

kubectl delete namespace ns1
kubectl delete namespace ns2

Summary of Learning on Kubernetes Namespaces and Services

In this blog post, we explored the concept of Kubernetes namespaces and their role in organizing cluster resources. We went through a series of exercises to solidify our understanding of namespaces, deployments, and services. Here’s a recap of what we covered:

Understanding Kubernetes Namespaces

Definition: Namespaces provide a mechanism to divide cluster resources between multiple users or applications, allowing for logical separation without the complexity of managing multiple clusters.
Use Cases: They are particularly useful in scenarios where different environments (development, staging, and production) coexist within the same cluster, enabling teams to share infrastructure while isolating resources.

Creating Namespaces

We created two namespaces, ns1 and ns2, using the following commands:

  kubectl create namespace ns1
  kubectl create namespace ns2

Deployments in Namespaces

We deployed a single replica of Nginx in each namespace:
- Deployment in ns1: Configuration saved as ns1-deployment.yml.
- Deployment in ns2: Configuration saved as ns2-deployment.yml.

We used the kubectl apply command to create these deployments.

Scaling Deployments

We scaled both deployments from 1 to 3 replicas using the YAML configuration files for source control, ensuring that our changes were tracked.

Exposing Deployments with Services

We created two services to expose our deployments:
- Service for ns1: Configuration saved as ns1-service.yml.
- Service for ns2: Configuration saved as ns2-service.yml.

This step enabled external access to our Nginx deployments.

Pod-to-Pod Communication

We executed commands to curl the IP addresses of the services from within the pods:

  kubectl exec -it <pod-name> -n ns1 -- curl <ip-address>

We then attempted to curl the service name directly, which resulted in a resolution error, demonstrating the importance of DNS in Kubernetes.

Fully Qualified Domain Name (FQDN) Usage

By using the FQDN of the service, we successfully accessed the services across namespaces:

  kubectl exec -it deploy-ns1-68b96c55c4-db4b9 -n ns1 -- curl svc-ns2.ns2

Cleanup

To maintain a tidy workspace, we deleted both namespaces, which also removed the associated services and deployments:

  kubectl delete namespace ns1
  kubectl delete namespace ns2

Key Takeaways

Namespaces are essential for organizing resources and managing access in a Kubernetes cluster.
Deployments and Services work hand-in-hand to provide scalable applications and expose them for external access.
FQDN is critical for cross-namespace communication, emphasizing the importance of DNS within Kubernetes.
Maintaining cleanliness in our cluster by deleting unnecessary namespaces and resources is crucial for efficient management.

Tags and Mentions

@piyushsachdeva
Day 8 video

CKA Full Course 2024: Day 9/40 Kubernetes Services Explained: ClusterIP vs NodePort vs Loadbalancer vs External

Lloyd Rivers — Sun, 27 Oct 2024 09:45:50 +0000

Kubernetes Services Overview

Services in Kubernetes provide a way for applications to communicate with each other or with external clients. They allow for stable endpoints that remain constant, even if the underlying pods change.

Types of Kubernetes Services

ClusterIP: The default service type, exposing the service within the Kubernetes cluster only. It's useful for internal communication between services or pods.
NodePort: Exposes the service on a static port on each node’s IP, enabling access from outside the cluster via <NodeIP>:<NodePort>. Often used in development for simple external access but can have security risks in production.
LoadBalancer: Integrates with cloud providers to automatically create an external load balancer, which routes traffic to your services. This type is most common for exposing services to the internet in production environments on managed Kubernetes clusters.
ExternalName: Maps a service to an external DNS name by returning a CNAME record. Useful when pointing to external services outside of the Kubernetes environment, without complex configurations.

Prerequisites

Before we begin, ensure you have the following configuration for your KIND cluster:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: cka-cluster  
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 30001  # Change this to match the NodePort
    hostPort: 30001
    listenAddress: "0.0.0.0" 
    protocol: tcp
- role: worker  
- role: worker

This YAML file sets up a Kubernetes cluster named cka-cluster with one control plane node and two worker nodes. The extraPortMappings section maps port 30001 to allow external access to the NodePort service.

1. Create a Service named `myapp` of type ClusterIP

Goal: This creates an internal network endpoint accessible only within the Kubernetes cluster, allowing internal traffic routing to your application.
Details: The ClusterIP type will not be accessible outside the cluster, so it’s used here to facilitate communication between Pods and other resources internally. The Service will map port 80 to the target port 80 on the Pods.

Steps:

Create the KIND cluster (if you haven’t already):

   kind create cluster --name kind-cka-cluster --config <kind.yml>

Switch context to your new KIND cluster (if required):

   kubectl config use-context kind-kind-cka-cluster

Create the Service manifest:
Open a new YAML file using your preferred editor:

   nano service.yml

Define the Service:
Copy the following YAML configuration into service.yml:

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  type: ClusterIP
  selector:
    app: MyApp  # Change this to match your pod labels. I copied this of the k8s docs
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80

Apply the Service configuration:

   kubectl apply -f service.yml

Verify the Service is running:

   kubectl get services

This will create the myapp Service, of type ClusterIP, mapping port 80 on the Service to port 80 on the target Pods.

2. Create a Deployment named `myapp`

Goal: The Deployment manages Pod replicas for nginx (in this case, version 1.23.4-alpine), ensuring they’re running and available.
Details: By setting up a Deployment, you gain automatic scalability, rolling updates, and easier management. You expose the container’s port 80, which the Service will use to route traffic.

Steps:

Create the Deployment manifest:
Open a new YAML file using your preferred editor:

nano deployment.yml

Define the Deployment:
Copy the following YAML configuration into deployment.yml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: nginx
spec:
  replicas: 1  
  selector:
    matchLabels:
      app: MyApp
  template:
    metadata:
      labels:
        app: MyApp
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.4-alpine
        ports:
        - containerPort: 80

Apply the Deployment configuration:
Run the following command to create the Deployment:

kubectl apply -f deployment.yml

Verify the Deployment is running:
Check the status by running:

kubectl get deployments

3. Scale the Deployment to 2 replicas

Goal: This tests the load-balancing functionality of the Service, as it should distribute traffic across the two Pod instances.
Details: You can scale the Deployment either by updating the manifest to set replicas: 2 or by using a kubectl command.

Steps:

Update the Deployment manifest: If you want to change the number of replicas in the YAML, edit the replicas field:

replicas: 2  # Update to 2 for scaling

Alternatively, use kubectl to scale the Deployment: Run the following command to scale the Deployment:

kubectl scale deployment myapp --replicas=2

Verify the scaling: Run the following command to check that the new Pods are created and ready:

kubectl get pods

4. Create a Temporary Pod Using busybox and Run `wget` Against the Service IP

Goal: This verifies that the Service is reachable from within the cluster.
Details: You’ll launch a temporary busybox Pod and run wget to check if it can access the myapp Service over its ClusterIP. This step assumes you’re comfortable finding the Service’s ClusterIP (accessible via kubectl get svc).

Important Labeling Warning: Ensure that the labels in the Service selector match the Deployment's matchLabels exactly. Misalignment will prevent the Service from routing traffic to the correct Pods.

Steps:

Find the Service IP:
Run the following command to retrieve the ClusterIP of myapp:

   kubectl get services

Example output:

   NAME       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
   myapp      ClusterIP   10.96.87.231   <none>        80/TCP    10h

Create the Temporary Pod:
Use the following command to create a busybox Pod and run wget to test connectivity:

   kubectl run busybox --image=busybox -it --rm --restart=Never -- wget myapp:80

Command Breakdown:

--image=busybox: Specifies busybox as the image to pull.
-it: Interactive terminal, which allows you to access the command line inside the Pod.
--rm: Cleans up and removes the Pod after the command completes.
--restart=Never: Ensures Kubernetes does not attempt to restart the Pod after it finishes.
wget myapp:80: Sends a request to the myapp Service at port 80, confirming connectivity.

Expected Output:
You should see output similar to the following upon a successful connection:

   Connecting to myapp:80 (10.96.87.231:80)
   saving to 'index.html'
   index.html           100% |********************************|   615  0:00:00 ETA
   'index.html' saved
   pod "busybox" deleted

This output confirms that the Service is accessible within the cluster and can successfully handle requests from other Pods.

5. Run a `wget` Command Against the Service from Outside the Cluster

Goal: This tests if external traffic can reach the Service (spoiler: it won’t, as it’s still a ClusterIP type).
Steps: From an external machine or terminal, try reaching the Service IP. You won’t get a response because ClusterIP restricts access to within the cluster.

Find the Service IP:
Run the following command to retrieve the ClusterIP of myapp:

kubectl get services

Example output:

NAME       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
myapp      ClusterIP   10.96.87.231   <none>        80/TCP    10h

Next, attempt to use wget to access the Service:

wget myapp:80

Output:

--2024-10-27 06:49:46--  http://myapp/
Resolving myapp (myapp)... failed: nodename nor servname provided, or not known.
wget: unable to resolve host address ‘myapp’

6. Change the Service Type for External Access

Goal: Now, we want to change the Service type so it’s accessible externally.
Details: Changing the Service type to NodePort or LoadBalancer enables external traffic. Use NodePort if you want to access it through a specific node’s IP and port, or LoadBalancer if your cloud provider’s load balancer will handle it.

Rationale: Instead of executing commands directly in the terminal, we should leverage YAML files for defining our configurations. This approach not only facilitates source control but also ensures that our infrastructure as code (IaC) practices are consistent and reproducible.

Steps:
Remove the existing service configuration:

   rm service.yml

Create a new service definition using your preferred text editor:

   nano service.yml

Copy the following YAML configuration (adapted from the Kubernetes documentation) into service.yml:

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  type: NodePort
  selector:
    app: MyApp
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30001  # Optional: Define the node port if desired

Deploy the new service configuration:

   kubectl apply -f service.yml

For more information, you can refer to the Kubernetes documentation.

7. Access the Service in Your Browser or Using `curl`

Goal: This confirms external access to the Service once exposed.
Details: You can visit the nginx homepage in your browser or use curl to see the response from the service.
Command:
```
 curl http://localhost:30001
```

Discussion Points

Exposing Pods without a Deployment:
- Can it be done? Yes, it’s possible to create a Service that directly exposes individual Pods by using spec.selector to match the Pods' labels.
- Why (or why not)? However, Deployments provide benefits like auto-scaling, rolling updates, and ensuring a specified number of Pods are always running, which wouldn’t be handled automatically if only using a Service.
Choosing Service Types:
- ClusterIP: Use it for internal traffic only, where the Service should only be accessible within the cluster. Great for microservices that need to communicate with each other.
- NodePort: This makes the Service accessible on each Node's IP at a specific port, allowing limited external access. Often used for development or testing but not ideal for production as it doesn’t offer load balancing.
- LoadBalancer: Ideal for production in cloud environments, as it distributes incoming traffic across multiple nodes or Pods and abstracts the complexity of handling traffic.
- ExternalName: This type creates an alias for an external hostname, allowing Pods to access external services using Kubernetes DNS. Suitable for situations where in-cluster services need access to an external service, but it’s limited to simple DNS resolution.

Tags and Mentions

@piyushsachdeva
Day 8 video

CKA Full Course 2024: Day 8/40 Deployment, Replication Controller and ReplicaSet Explained

Lloyd Rivers — Fri, 25 Oct 2024 18:52:03 +0000

Before we dive into the steps, a quick word on ReplicaSets. Initially, I was confused by seeing both ReplicationControllers and ReplicaSets mentioned, but after some research, I realized that ReplicaSets are the modern, recommended approach. According to Kubernetes documentation, the ReplicationController is:

"Legacy API for managing workloads that can scale horizontally. Superseded by the Deployment and ReplicaSet APIs."

For this reason, I'll only be using ReplicaSets in this example.

ReplicaSet (from the docs)

A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods. Typically, you would define a Deployment and let that Deployment manage ReplicaSets automatically.

Step-by-Step: Creating and Managing a ReplicaSet

1. Creating the ReplicaSet YAML file

First, I created a directory to store my YAML file:

mkdir day-08
cd day-08
nano rs.yaml

Inside rs.yaml, I defined the ReplicaSet configuration to create 3 replicas of an nginx pod:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Some important keys in this ReplicaSet YAML configuration:

apiVersion: Specifies the API version used, which here is apps/v1, suitable for ReplicaSets in Kubernetes.
kind: Defines the resource type, which is ReplicaSet.
metadata:
- name: Sets a unique name for the ReplicaSet (in this case, "nginx").
spec:
- replicas: Indicates the desired number of pod replicas to run, set here to 3.
- selector: Uses matchLabels to match pods with the label app: nginx, identifying the pods that this ReplicaSet will manage.
- template:
- metadata:
  - labels: Defines labels for pods created by this ReplicaSet. These labels must match the selector labels to ensure proper management.
- spec:
  - containers: Lists container details for each pod, in this case, a single container:
  - name: Name of the container (also "nginx").
  - image: Specifies the container image to use (nginx).
  - ports: Configures the container's ports, with containerPort set to expose port 80.

After saving and exiting the editor, I applied the ReplicaSet to the cluster:

kubectl apply -f rs.yaml

To confirm that the 3 replicas were up and running, I used k9s (or you can use kubectl get rs and kubectl get pods for a quick check).

2. Scaling the ReplicaSet

I then wanted to increase the number of replicas:

Scaling replicas to 6 from the command line: To dynamically scale up to 6 replicas without modifying the YAML file:

   kubectl scale --replicas=6 rs/nginx

I then verified the new count with k9s

Deployments (from the docs)

A Deployment manages a set of Pods to run an application workload, usually one that doesn't maintain state. A Deployment provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate..

Deployments, ReplicaSets, and Pods: How They Work Together

In Kubernetes, a Deployment is a higher-level abstraction that adds functionality on top of a ReplicaSet. Here’s how they work together:

Deployment: A Deployment manages and oversees the ReplicaSets. When you create a Deployment, it automatically generates and manages one or more ReplicaSets, which in turn manage the actual Pods. This structure enables powerful features like rolling updates, rollbacks, and scaling.
ReplicaSet: The ReplicaSet ensures that the desired number of Pods are running at all times. It serves as an intermediary, managing the pods based on the Deployment’s instructions.
Pods: The smallest deployable unit in Kubernetes, Pods contain your containerized application. They are created, maintained, and monitored by the ReplicaSet under the Deployment’s guidance.

In essence, the Deployment acts as the top-level controller, managing the ReplicaSet layer, which then directly handles the Pods. This layered approach provides a robust way to handle containerized applications in production, making scaling and updating more efficient.

Creating a Deployment

To create a Deployment using the nginx image with 3 replicas, follow these steps:

Create the YAML file: Open a terminal and move into the directory we created earlier:

   cd day-08

Now, create a new YAML file for the Deployment:

   nano deployment.yml

Write the Deployment configuration: Inside the nano editor, paste the following configuration (watch out for correct indentation if you are copying it from here):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: v1
      tier: backend
  template:
    metadata:
      labels:
        app: v1
        tier: backend
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.0
        ports:
        - containerPort: 80

Save and exit the editor by pressing CTRL + X, then Y, and finally ENTER.

Apply the Deployment: Run the following command to apply the configuration and create the Deployment:

   kubectl apply -f deployment.yml

After running the apply command, you should see your Deployment created successfully. To confirm, use the following command:

kubectl get deployments

In k9s, the deployment should appear as shown below:

This command lists all deployments in your current context, allowing you to verify that nginx-deployment is active and correctly configured.

Updating the Deployment Image and Annotating the Change Cause in Kubernetes

In Kubernetes, managing updates to Deployments effectively involves more than just changing an image version. Documenting these changes is important for maintaining an organized rollout history and providing context for each deployment update.

Step 1: Update the Image

First, we’ll update the nginx container image in our nginx-deployment Deployment. Here, we set the version to 1.16.0:

kubectl set image deploy/nginx-deployment nginx=nginx:1.23.4

Kubernetes will initiate a rolling update across all replicas of the nginx-deployment. This ensures that each replica gradually switches to the specified image version, minimizing downtime.

Step 2: Verify the Rollout

After setting the image, it’s important to check that the update has been applied to all replicas:

kubectl describe deployment nginx-deployment | grep Image

Or, to list the Pods and their images:

kubectl get pods -o wide

These commands help confirm that the Deployment’s replicas are now running the correct image version.

Step 3: Annotate the Deployment with the Change Cause

Since the --record flag is deprecated, we’ll use the kubectl annotate command to document the reason for this deployment update manually. This adds context to the change, allowing it to appear in the rollout history:

kubectl annotate deployment nginx-deployment kubernetes.io/change-cause="Pick up patch version" --overwrite=true

The --overwrite=true flag is included to ensure the annotation is updated if there’s already an existing annotation for change-cause.

Step 4: Check the Rollout History

Finally, let’s view the rollout history to confirm that our annotation has been recorded. This step also helps validate that our deployment is tracking each update effectively:

kubectl rollout history deployment/nginx-deployment

This command shows each revision, including the change cause for each update. Proper annotation is invaluable for future reference, as it makes rollback decisions easier and provides insight into the deployment history.

Scaling, Viewing Deployment History, and Rolling Back Changes

After updating and annotating the image version, it’s crucial to know how to manage the Deployment’s scale, view the history of updates, and roll back if necessary. This section will walk through these final tasks:

Step 5: Scale the Deployment to 5 Replicas

Scaling up a Deployment adjusts the number of Pods to meet the demand. Here’s how to scale nginx-deployment to 5 replicas:

kubectl scale deployment nginx-deployment --replicas=5

This command increases the number of Pods under nginx-deployment to five, ensuring more instances of your application are available.

Step 6: Roll Back to a Previous Revision

If needed, you can roll back to a specific revision. To revert to revision 1, for example, use:

kubectl rollout undo deployment/nginx-deployment --to-revision=1

This command rolls the Deployment back to the specified version, ideal for cases where a previous configuration is preferable.

Step 7: Confirm the Image Version for All Pods

Finally, verify that all Pods are running the correct image version (nginx:1.23.0):

kubectl describe deployment nginx-deployment | grep Image
kubectl get pods -o wide

These commands help confirm that each replica in the nginx-deployment Deployment is using the specified image version.

These steps wrap up the complete process of deploying, updating, scaling, and managing a Deployment in Kubernetes.

If you are still with me at this point, thank you for reading.

I appreciate it.

Tags and Mentions

@piyushsachdeva
Day 8 video

CKA Full Course 2024: Day 7/40 Pod in Kubernetes Explained

Lloyd Rivers — Thu, 24 Oct 2024 08:00:09 +0000

At the core of Kubernetes is the Pod. Think of a Pod as a wrapper for one or more containers, where these containers share the same network and storage. Pods represent the smallest, most basic deployable objects in Kubernetes, and they typically run a single instance of an application. However, a Pod can contain multiple tightly coupled containers.

Two Ways to Create Pods: Imperative vs Declarative

In Kubernetes, there are two main approaches to creating and managing resources: Imperative and Declarative.

Imperative: This method allows you to directly instruct the Kubernetes cluster to perform an action immediately using the kubectl command. It’s quick but may not be suitable for managing large clusters, as it does not retain a record of your infrastructure.
Example: Create an nginx Pod with an imperative command:
```
kubectl run nginx-pod --image=nginx:latest
```

Declarative: This method is more sustainable for large-scale environments. You define your desired state in a YAML file, and Kubernetes works to ensure that the cluster matches that state. This approach is beneficial for version control and team collaboration.

Example: Create the same nginx Pod using a YAML file.

First, create a YAML configuration file like this:

# The names in this configuration are case-sensitive. 
# Be sure to use the exact casing as shown.
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest

Then, apply it to the cluster with:

kubectl apply -f nginx-pod.yaml

Creating and Managing Pods with YAML

For larger teams or more complex applications, we use declarative YAML files. YAML allows us to define the desired state of our Pods and other Kubernetes resources in a clean, human-readable format. Let's break down the example YAML file mentioned earlier:

apiVersion: Specifies the API version (in this case, v1).
kind: Defines the type of resource (here, a Pod).
metadata: Contains information about the object, such as the name of the Pod.
spec: Describes the desired state of the object, including the containers, images, and more.

To create a Pod from this YAML file, save it as mypod.yaml and run:

kubectl apply -f mypod.yaml

To view the status of the Pod:

kubectl get pods

If you need to delete the Pod:

kubectl delete -f mypod.yaml

If you need to see the details of the Pod:

kubectl explain pod

YAML Tutorial for Beginners

If you’re new to YAML, don’t worry—it’s a simple, human-readable format used to define objects in Kubernetes. Here’s a breakdown of what you need to know:

Indentation matters: YAML relies on spaces (not tabs) to structure data.
Key-Value pairs: Similar to JSON but more readable.
Lists: Defined using a hyphen (-) followed by the value.

Example:

list_of_fruits:
  - apple
  - banana
  - orange

In Kubernetes, YAML allows you to define objects like Pods, Services, and more.

Summary

In today's post, we covered:

What Pods are in Kubernetes and why they are important.
The difference between imperative and declarative methods of managing Pods.
How to create and manage Pods using both imperative commands and declarative YAML files.

Top 3 kubectl Commands from Today's Post

kubectl run nginx-pod --image=nginx:latest – Create a Pod imperatively.
kubectl apply -f nginx-pod.yaml – Apply a YAML configuration to create a Pod.
kubectl get pods – View all running Pods in the cluster.

Tags and Mentions

@piyushsachdeva
Day 6 video

CKA Full Course 2024: Day 6/40 Multi-Node Cluster Setup: Step by Step

Lloyd Rivers — Tue, 22 Oct 2024 19:54:56 +0000

Setting up a Kubernetes cluster is a foundational step for managing containerized applications at scale. In this post, we’ll guide you through installing kubectl, creating a Kubernetes cluster using kind, and configuring a multi-node setup with a step-by-step approach. We’ll also highlight five essential kubectl commands that will give you a solid start in managing your Kubernetes cluster.

What You’ll Learn:

Installing kubectl
Installing and configuring kind
Creating and managing a Kubernetes cluster
Understanding and using key kubectl commands

Let’s dive in!

Step 1: Installing `kubectl`

kubectl is the command-line tool that allows you to interact with your Kubernetes cluster. You’ll need this to manage and configure the cluster once it’s up and running.

How to Install `kubectl`:

On macOS:

   brew install kubectl

For more installation options and in-depth instructions, refer to the official Kubernetes documentation.

Step 2: Installing `kind`

kind is a tool for running local Kubernetes clusters using Docker. It’s great for development, testing, and learning Kubernetes concepts before moving to a production environment.

How to Install `kind`:

On macOS & Linux:

   brew install kind

On Windows (using Chocolatey):

   choco install kind

For more detailed installation instructions, refer to the official kind documentation.

Step 3: Creating a Kubernetes Cluster

With both kubectl and kind installed, you can now create your Kubernetes cluster.

Basic Cluster Creation:

To create a basic single-node cluster, use the following command:

kind create cluster

Understanding the Cluster Creation Process:

kind will bootstrap a Kubernetes cluster using a pre-built node image. These images are hosted at kindest/node.
By default, the cluster will use the latest stable image for the Kubernetes version. If you want a different version, specify it using the --image flag like this:

kind create cluster --image=kindest/node:v1.22.2

Check the kind release notes to find images for specific Kubernetes versions. You can also build your own custom images if needed (this is more advanced, but worth exploring).

Multi-Node Cluster Configuration:

To create a multi-node cluster, you’ll need a configuration YAML file. Here’s a sample configuration:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker

Save this configuration to a file, for example kind-config.yaml, and then create your multi-node cluster:

kind create cluster --config=kind-config.yaml

This command will create a cluster with one control-plane node and two worker nodes.

Check Your Cluster Status:

Once your cluster is created, you can check its status with the following kubectl command:

kubectl cluster-info --context kind-<cluster-name>

Replace <cluster-name> with the name of your cluster (e.g., kind-kind if you used the default).

Step 4: Key `kubectl` Commands

Here are some essential kubectl commands to help you manage your cluster effectively:

Check the Nodes:

   kubectl get nodes

This command lists all nodes (control-plane and worker nodes) in your cluster.

List All Pods:

   kubectl get pods --all-namespaces

This shows the status of all pods running in all namespaces in your cluster.

Get Detailed Information About a Pod:

   kubectl describe pod <pod-name>

Replace <pod-name> with the name of your pod to get detailed information about it.

Create a Resource from a YAML File:

   kubectl apply -f <your-app.yaml>

Use this to deploy an application from a YAML configuration file.

Delete a Resource:

   kubectl delete <resource-type> <resource-name>

This command deletes a specific resource, like a pod or deployment.

For more commands, check out the official Kubernetes Cheat Sheet.

Changing the Cluster Context

To ensure that you are interacting with the correct cluster, use the following command:

kubectl config use-context kind-<cluster-name>

Replace <cluster-name> with the name of your cluster (e.g., kind-kind).

Coming Soon: A Peek at K9s

While kubectl gives you control over your Kubernetes clusters, there's an amazing tool that takes cluster management to the next level — K9s. We won’t unpack it fully here, but here's a teaser: imagine navigating and managing your cluster with a slick, terminal-based UI. Stay tuned for more details, and we’ll dive deeper into the awesomeness of K9s in an upcoming post!

Conclusion

In this guide, we’ve walked through the process of setting up a multi-node Kubernetes cluster using kind, configuring kubectl, and managing your cluster with essential commands. By following these steps, you’re well on your way to understanding and managing Kubernetes clusters effectively.

Tags and Mentions

@piyushsachdeva
Day 6 video

CKA Full Course 2024: Day 5/40 Kubernetes Architecture

Lloyd Rivers — Tue, 22 Oct 2024 06:58:15 +0000

Apologies if you saw this blog earlier and it was just a random drawing! I accidentally hit publish before writing anything 😅. I'm still figuring out a smooth workflow between Canva, dev.to, and Eraser.io—so bear with me while I get things right.

Kubernetes Architecture - Master Node and Worker Node Components

In today’s post, I’m going to walk through the basic architecture of Kubernetes, focusing on the two main components: the Master Node and the Worker Node.

Master Node

The Master Node is where the control magic happens. It’s responsible for managing the cluster and coordinating everything between the nodes. Here are the key components of the Master Node:

API Server: This is the entry point for all the administrative tasks. Think of it as the main communication hub between the users, nodes, and even the external components.
Scheduler: As the name suggests, it’s responsible for scheduling your applications (pods) to run on the Worker Nodes based on available resources.
Controller Manager: Responsible for monitoring and maintaining the desired state of the cluster, ensuring that everything is operating smoothly and as expected.
etcd: An open-source, distributed key-value store that holds and replicates all the critical data for the cluster, such as configurations, state information, and metadata essential for maintaining the system's desired state.

Worker Node

On the other side, you have the Worker Nodes. These are where your containers (applications) actually run. Here's a breakdown:

Pods: A Pod is the smallest deployable unit in Kubernetes. Each Pod encapsulates one or more containers.
kubelet: It ensures the containers in the Pods are running and reports back to the Master Node.
Container Runtime: This is the software that actually runs the containers.
kube-proxy: It manages the network rules that allow the Pods to communicate with each other and with the outside world.

Putting It All Together

The communication between the Master and Worker Nodes is key to keeping the system running smoothly. The API Server communicates with the kubelet on each Worker Node to make sure the containers are running as expected, while the Scheduler decides which Pods go where based on resources.

I hope this gives you a clear picture of how Kubernetes architecture is organized. If you're learning Kubernetes like me, drawing these diagrams and breaking things down really helps solidify the concepts.

Tags and Mentions

@piyushsachdeva
Day 5 video

DEV Community: Lloyd Rivers

CKA Full Course 2024: Day 15/40 Kubernetes Node Affinity Explained

Exercises

1. Create a Pod with Node Affinity

2. Check Pod Status

Command:

Output:

Explanation:

3. Add Node Label

Command to Add the Label:

Recheck Pod Status:

4. Create a Second Pod with Node Affinity

Tags and Mentions

CKA Full Course 2024: Day 14/40 Taints and Tolerations in Kubernetes

Exercises

1. Taint both Worker Nodes

2. Create a new pod with the image nginx and see why it's not getting scheduled on worker nodes and control plane nodes.

3. Add Toleration to the Pod to Match the Taint on worker01

4. Remove Taint from Control Plane Node

Create a New Pod Without Toleration

Reapply Taint to Control Plane Node

Tags and Mentions

VS Code YAML Plugin Setup for Kubernetes Beginners

Goal

Overview

Steps

1. Install the YAML Plugin

2. Configure the YAML Plugin

3. Add Kubernetes Schema

4. Reload VS Code

5. Using Autocomplete and Outline Features

Final Thoughts

CKA Full Course 2024: Day 13/40 Static Pods, Manual Scheduling, Labels, and Selectors in Kubernetes

Task: Schedule a Pod Manually Without the Scheduler

Prerequisites

Step 1: Verify the Cluster Nodes

Step 2: Define the Pod Manifest (pod.yml)

Step 3: Apply the Pod Manifest

Step 4: Verify Pod Placement

Task: Login to the control plane node and go to the directory of default static pod manifests and try to restart the control plane components.

Confirming the Restart of kube-controller-manager

Cleanup

Creating Multiple Pods with Specific Labels

Tags and Mentions

CKA Full Course 2024: Day 12/40 Daemonsets, Job and Cronjob in Kubernetes

Project Overview

Key Concepts

Prerequisites

Cluster Configuration (config.yml)

Tasks

Create a DaemonSet

Solution

Solution

Putting It All Together

Nginx Deployment

Nginx Service

Common Gotchas

Final thoughts...

Tags and Mentions

CKA Full Course 2024: Day 11/40 Multi Container Pod Kubernetes - Sidecar vs Init Container

A Note from Me

What Get Me App Does

Prerequisites

Cluster Configuration (config.yml)

Step 1: Create the Project Directory and File

Step 2: Define the Kubernetes Pod Specification

What Each Part of This Pod Specification Does

Step 3: Test Locally with NodePort (Optional)

Key Takeaways

Tags and Mentions

CKA Full Course 2024: Day 10/40 Kubernetes Namespace Explained

Note to the Reader

Kubernetes Namespaces

Create Two Namespaces: ns1 and ns2

Create a deployment with a single replica in each of these namespaces with the image as nginx and names as deploy-ns1 and deploy-ns2, respectively

Apply each YAML configuration to create the deployments

Get the IP address of each of the pods

Exec into the pod of deploy-ns1 and try to curl the IP address of the pod running on deploy-ns2

Scale both deployments from 1 to 3 replicas

Create two services to expose both of your deployments and name them svc-ns1 and svc-ns2

Create Two Namespaces: `ns1` and `ns2`

Exec into the pod of `deploy-ns1` and try to curl the IP address of the pod running on `deploy-ns2`

This should show you the `svc-ns1` and `svc-ns2` services, along with their cluster IPs and ports.

1. Create a Service named `myapp` of type ClusterIP

2. Create a Deployment named `myapp`

4. Create a Temporary Pod Using busybox and Run `wget` Against the Service IP

5. Run a `wget` Command Against the Service from Outside the Cluster

7. Access the Service in Your Browser or Using `curl`

Step 1: Installing `kubectl`

How to Install `kubectl`:

Step 2: Installing `kind`

How to Install `kind`:

Step 4: Key `kubectl` Commands