Kubernetes CKAD — Chhota shortcut — pod, replicaset and deployment — Part 1

10 min readApr 26, 2024

“Power resides where men believe it resides. No more and no less.”

15 Kubernetes concepts you should be familiar with:

Pods: The smallest deployable units in Kubernetes that you can create and manage. In AKS, pods are the basic building blocks of your application workloads, and Terraform can be used to manage pod configurations through Kubernetes provider resources.
ReplicaSets: Ensure that a specified number of pod replicas are running at any given time. This is crucial for maintaining the desired state and availability of applications. Terraform can deploy and manage these through resource configurations.
Deployments: Manage the deployment of ReplicaSets and provide declarative updates to applications. You can use Terraform to define deployments to roll out updates or rollbacks in AKS.
Services: An abstraction that defines a logical set of Pods and a policy by which to access them. This can include internal cluster communication and external-facing load balancing. Terraform can be used to define and manage Kubernetes services in AKS.
Ingress: Manages external access to the services in a cluster, typically HTTP. Ingress can be configured with Terraform to control access routes in AKS environments.
ConfigMaps and Secrets: Used to store non-confidential and confidential data, respectively. Terraform can manage these objects to inject configuration data and secrets into AKS pods.
Volumes: Attach disk storage to containers running in pods, which is essential for stateful applications. Terraform allows you to define and attach storage volumes in AKS.
Namespaces: Support multiple virtual clusters within a single physical cluster. Namespaces are useful in Terraform for managing resource quotas and segregating cluster resources within AKS.
StatefulSets: Designed for applications that require persistent storage and unique, stable network identifiers. Terraform can be used to manage lifecycle of stateful applications on AKS.
DaemonSets: Ensure that each node in the cluster runs a copy of a specific pod, useful for deploying system-wide services like log collectors. These can be defined and managed via Terraform in AKS.
Jobs and CronJobs: Manage tasks that run to completion and recurring tasks, respectively. Terraform can define these workloads in AKS for task automation and scheduled operations.
Resource Quotas: Define constraints on resources usage per Namespace, vital for multi-tenant clusters. Terraform can apply these quotas in AKS to manage cluster resource consumption effectively.
Horizontal Pod Autoscaler (HPA): Automatically scales the number of pods in a deployment or replicaset based on observed CPU utilization or other selected metrics. Terraform can configure HPA in AKS to ensure performance and cost management.
Network Policies: Specify how groups of pods are allowed to communicate with each other and other network endpoints. Terraform can help define and apply these policies in AKS to enhance security.
RBAC (Role-Based Access Control): Controls authorization, determining who can perform actions on specific resources. It’s important in AKS to manage access and permissions securely, and Terraform can manage RBAC policies effectively.

Pods

“If you think this has a happy ending, you haven’t been paying attention.”

Imagine you’re building a LEGO set. Each piece of LEGO can be thought of as a “Pod” in Kubernetes. A Pod is the smallest and simplest unit in the Kubernetes ecosystem that you can create and manage. It contains one or more containers (think of these containers as small homes for your applications). For example, a Pod might contain a container running your web application and another container running a logging agent.

In Azure Kubernetes Service (AKS), these Pods are like little soldiers carrying out the tasks your application needs to function properly. They live and die in your Kubernetes cluster, working together to keep your application running smoothly.

Here’s a meme-worthy way to remember Pods: “Pods are like bees in a hive; small, busy, and they work together to make the system thrive!”

Using Terraform, you can manage these Pods directly by defining Kubernetes provider resources in your configuration files. This might look something like this in a basic Terraform configuration:

resource "kubernetes_pod" "example" {
  metadata {
    name = "example-pod"
  }

  spec {
    container {
      image = "nginx:1.14.2"
      name  = "example-container"
    }
  }
}

In this example, you’re telling Terraform to ensure there’s a Pod running with an NGINX server inside.

ReplicaSets

“A lion doesn’t concern himself with the opinions of a sheep.”

A ReplicaSet is like a nanny for your Pods. Its main job is to ensure that a specified number of Pod replicas are running at any given time. If a Pod crashes, the ReplicaSet notices and launches another one to maintain the desired count. This is key for ensuring your application is available and can handle incoming traffic.

Think of it like this: “If one LEGO piece falls under the couch, quickly replace it to keep your LEGO set complete.”

With Terraform, managing a ReplicaSet involves defining the desired state of your system within your configuration, like so:

resource "kubernetes_replication_controller" "example" {
  metadata {
    name = "example-replicaset"
  }

  spec {
    replicas = 3

    selector {
      app = "MyApp"
    }

    template {
      container {
        image = "nginx"
        name  = "nginx-container"
      }
    }
  }
}

In this Terraform snippet, you are ensuring that three replicas of the NGINX server are always running.

Deployments

“The night is dark and full of terrors.”

Deployments are the generals of your Kubernetes army. They manage the deployment of ReplicaSets and Pods, handling updates, rollbacks, and scaling of your application. A Deployment ensures that your desired state (defined by you) is matched in the cluster, managing the process of updating Pods and ReplicaSets.

For example, if you decide to update your application to a new version, the Deployment helps roll out this change in a controlled way, potentially replacing old versions of Pods with new ones smoothly and systematically.

Here’s how you might think of it: “Deployments are like a software update wizard for your Pods.”

Using Terraform to manage Deployments might look something like this:

resource "kubernetes_deployment" "example" {
  metadata {
    name = "example-deployment"
  }

  spec {
    replicas = 3
    selector {
      match_labels {
        app = "MyApp"
    }

    template {
      metadata {
        labels {
          app = "MyApp"
        }
      }

      spec {
        container {
          image = "nginx:1.17.4"
          name  = "nginx-container"
        }
      }
    }
  }
}

This configuration tells Terraform to deploy a set of Pods under a Deployment banner, managing three replicas of your app using the specified NGINX image.

These examples and analogies should give you a foundational understanding of how Pods, ReplicaSets, and Deployments work in Kubernetes and how they can be managed using Terraform, helping you start your journey as a junior cloud engineer with a solid footing.

21 kubectl commands to live by

“Chaos isn’t a pit. Chaos is a ladder.”

 Kubernetes environment:

Create a Pod:


kubectl run nginx-pod --image=nginx

Get all Pods:


kubectl get pods

Describe a Pod:


kubectl describe pod nginx-pod

Delete a Pod:


kubectl delete pod nginx-pod

Create a ReplicaSet from a file:


kubectl create -f replicaset-definition.yml

List ReplicaSets:


kubectl get replicasets

Delete a ReplicaSet:


kubectl delete replicaset my-replicaset

Scale a ReplicaSet manually:


kubectl scale replicaset my-replicaset --replicas=5

Edit a ReplicaSet:


kubectl edit replicaset my-replicaset

Create a Deployment:


kubectl create deployment nginx-deployment --image=nginx

Get all Deployments:


kubectl get deployments
Delete a Deployment:


kubectl delete deployment nginx-deployment

Scale a Deployment:


kubectl scale deployment nginx-deployment --replicas=10

Update the image of a Deployment:


kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1

Rollback a Deployment:


kubectl rollout undo deployment nginx-deployment

View the rollout status of a Deployment:


kubectl rollout status deployment nginx-deployment

Pause a Deployment:


kubectl rollout pause deployment nginx-deployment

Resume a Deployment:


kubectl rollout resume deployment nginx-deployment

Watch the deployment as it updates:


kubectl get pods --watch

Get detailed information on cluster events:


kubectl get events

View the Kubernetes logs for a specific Pod:


kubectl logs nginx-pod

Here comes the pain

“There is only one thing we say to Death: ‘Not today’.”

1. Terraform Example for a Pod with Environment Variables and Volume Mounts

resource "kubernetes_pod" "example" {
  metadata {
    name = "nginx-pod"
  }

  spec {
    container {
      image = "nginx:1.17.4"
      name  = "nginx-container"

      env {
        name  = "ENV_VAR"
        value = "production"
      }

      volume_mount {
        mount_path = "/usr/share/nginx/html"
        name       = "config-volume"
      }
    }

    volume {
      name = "config-volume"

      config_map {
        name = "nginx-config-map"
      }
    }
  }
}

2. Terraform Example for a ReplicaSet with Liveness and Readiness Probes

resource "kubernetes_replication_controller" "example" {
  metadata {
    name = "nginx-replicaset"
  }

  spec {
    replicas = 3

    selector {
      app = "nginx"
    }

    template {
      container {
        image = "nginx:1.17.4"
        name  = "nginx"

        readiness_probe {
          http_get {
            path = "/"
            port = 80
          }
          initial_delay_seconds = 5
          timeout_seconds        = 5
        }

        liveness_probe {
          http_get {
            path = "/"
            port = 80
          }
          initial_delay_seconds = 15
          period_seconds        = 20
        }
      }

      metadata {
        labels {
          app = "nginx"
        }
      }
    }
  }
}

3. Terraform Deployment Example with Resource Requests and Limits

resource "kubernetes_deployment" "example" {
  metadata {
    name = "nginx-deployment"
  }

  spec {
    replicas = 2

    selector {
      match_labels {
        app = "nginx"
      }
    }

    template {
      metadata {
        labels {
          app = "nginx"
        }
      }

      spec {
        container {
          image = "nginx:1.17.4"
          name  = "nginx"

          resources {
            requests {
              cpu    = "100m"
              memory = "256Mi"
            }

            limits {
              cpu    = "200m"
              memory = "512Mi"
            }
          }
        }
      }
    }
  }
}

4. Advanced Deployment with Auto-Scaling

resource "kubernetes_deployment" "example" {
  metadata {
    name = "apache-deployment"
  }

  spec {
    replicas = 3

    selector {
      match_labels {
        app = "apache"
      }
    }

    template {
      metadata {
        labels {
          app = "apache"
        }
      }

      spec {
        container {
          image = "httpd:2.4"
          name  = "apache"

          resources {
            requests {
              cpu    = "100m"
              memory = "256Mi"
            }

            limits {
              cpu    = "500m"
              memory = "512Mi"
            }
          }
        }
      }
    }
  }
}

resource "kubernetes_horizontal_pod_autoscaler" "example" {
  metadata {
    name = "apache-hpa"
  }

  spec {
    scale_target_ref {
      api_version = "apps/v1"
      kind        = "Deployment"
      name        = "apache-deployment"
    }

    min_replicas = 1
    max_replicas = 10

    target_cpu_utilization_percentage = 50
  }
}

5. Deployment Using ConfigMap and Secrets

resource "kubernetes_config_map" "app-config" {
  metadata {
    name = "app-config"
  }

  data = {
    "app.properties" = "color=blue"
  }
}

resource "kubernetes_secret" "app-secret" {
  metadata {
    name = "app-secret"
  }

  data = {
    "username" = "YWRtaW4="
    "password" = "c2VjcmV0"
  }
}

resource "kubernetes_deployment" "example" {
  metadata {
    name = "app-deployment"
  }

  spec {
    selector {
      match_labels {
        app = "app"
      }
    }

    template {
      metadata {
        labels {
          app = "app"
        }
      }

      spec {
        container {
          image = "myapp:latest"
          name  = "app"

          env_from {
            config_map_ref {
              name = kubernetes_config_map.app-config.metadata[0].name
            }
          }

          env {
            name  = "SECRET_USERNAME"
            value_from {
              secret_key_ref {
                name = kubernetes_secret.app-secret.metadata[0].name
                key  = "username"
              }
            }
          }

          env {
            name  = "SECRET_PASSWORD"
            value_from {
              secret_key_ref {
                name = kubernetes_secret.app-secret.metadata[0].name
                key  = "password"
              }
            }
          }
        }
      }
    }
  }
}

“A mind needs books as a sword needs a whetstone, if it is to keep its edge.”

Conclusion

Pods: The Scouts of Winterfell

Think of a Pod as Jon Snow when he first joined the Night’s Watch: small but vital. In Kubernetes, a Pod is the smallest deployable unit that can be created and managed. It’s like a scout sent beyond the Wall, capable of running one or several closely related containers (think Jon and Ghost).

Pods are ephemeral, much like the ever-changing loyalties in Westeros. They can be dispatched and replaced quickly, ensuring that your application adapts and responds as fast as Arya Stark changes faces. Terraform, acting as your Master of Coin, efficiently manages these resources, provisioning and deploying as needed without manual interference.

ReplicaSets: The Unsullied Army

A ReplicaSet is akin to Daenerys’s loyal Unsullied: it ensures that a specified number of identical Pod replicas (like Grey Worm and his soldiers) are running at any given time. This is crucial for maintaining the desired state and availability of your applications, as consistent as the Unsullied’s formation in battle.

Just as Daenerys relies on her Unsullied to maintain control over her conquered cities, you rely on ReplicaSets to maintain the necessary scale of your deployment, automatically handling the replication and scaling based on the defined state. Use Terraform to command these forces, specifying how many replicas you need as effortlessly as Daenerys commands her dragons.

Deployments: The High Lords of Westeros

Deployments in Kubernetes are like the great lords of Westeros, overseeing and controlling the larger strategic picture. A Deployment manages the deployment and scaling of a set of Pods and ensures that your deployed applications are updated seamlessly, much like Tyrion Lannister strategizes his moves in the game of thrones.

With a Deployment, you can declare the desired state of your system, and Kubernetes acts as your Hand of the King, ensuring that the state is achieved and maintained. Want to roll out a new release? Deployments handle this with the precision of Littlefinger’s plots, rolling out updates and rolling back failures with minimal disruption.

To summarize, in the realm of Kubernetes:

Pods are your scouts, the first line of your application’s defense, small yet critical.
ReplicaSets are your disciplined army, ensuring your forces are always at the ready, never fewer than needed.
Deployments are the master strategists of your infrastructure, overseeing the deployment and management of your applications with the wisdom of the Old Maesters.

Remember, just as in Game of Thrones, the key to surviving and thriving in the Kubernetes landscape is understanding how to leverage your resources and strategies to maintain control over your domain. Terraform is your Master of Coin, facilitating these deployments without the need for constant attention, allowing you to focus on the bigger picture — the Iron Throne of your application’s success.