DEV Community: Jensen Jose

Understanding Storage in Kubernetes: A Deep Dive into Persistent Volumes and Persistent Volume Claims

Jensen Jose — Wed, 07 Aug 2024 08:38:31 +0000

Welcome to the 29th installment of our CK2024 blog series! In this article, we'll be exploring the crucial topic of storage within Kubernetes, focusing on Persistent Volumes (PV), Persistent Volume Claims (PVC), and Storage Classes. If you’re familiar with Docker storage concepts, you’ll find this discussion particularly relevant as we bridge the gap between Docker and Kubernetes storage mechanisms.

Introduction to Storage in Kubernetes

Storage in Kubernetes is fundamental to ensuring that your applications can manage and persist data effectively. Unlike Docker, where storage is tied to individual containers, Kubernetes abstracts storage through the concepts of Persistent Volumes (PV) and Persistent Volume Claims (PVC). Understanding these components is key to managing stateful applications within Kubernetes.

Persistent Volumes (PV) and Persistent Volume Claims (PVC)

Persistent Volume (PV): A PV is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It represents a storage resource that can be used by Pods.
Persistent Volume Claim (PVC): A PVC is a request for storage by a user. It specifies the amount of storage, access modes (e.g., read-write or read-only), and other requirements. The Kubernetes scheduler binds PVCs to PVs based on these requirements.

How PV and PVC Work Together

Provisioning a PV:
An administrator creates a PV with a defined storage capacity, access modes, and other attributes. For example, a PV could have 100 GiB of storage with read-write permissions.
Creating a PVC:
A user creates a PVC specifying their storage needs, such as 10 GiB of storage. Kubernetes matches this PVC with a suitable PV based on the requested capacity and access mode.
Binding PVC to PV:
Once a match is found, the PVC is bound to the PV. The PV’s available capacity is reduced by the amount allocated to the PVC. For instance, if a PV initially had 100 GiB and a PVC requests 10 GiB, the PV’s remaining capacity becomes 90 GiB.
Usage by Pods:
The PVC is then used by Pods to mount the storage, allowing applications to read from and write to the mounted volume.

Practical Example: Using PV and PVC in a Pod

Let’s walk through a practical example of how to use PV and PVC in a Kubernetes Pod:

Define the Persistent Volume (PV):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

Create the Persistent Volume Claim (PVC):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

Use the PVC in a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - mountPath: "/usr/share/nginx/html"
      name: my-storage
  volumes:
  - name: my-storage
    persistentVolumeClaim:
      claimName: my-pvc

In this example, the my-pod Pod mounts storage from the my-pvc PVC, which is bound to the my-pv PV. This allows the Pod’s container to use the storage defined by the PVC.

Storage Classes

Storage Classes provide a way to define different types of storage with varying performance and cost characteristics. They abstract the provisioning of storage and enable dynamic volume provisioning.

A Storage Class defines the storage types and parameters used for provisioning PVs. It allows users to request specific types of storage based on their application requirements.

Example of a Storage Class:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2

In this example, the fast-storage Storage Class uses AWS EBS (Elastic Block Store) with the gp2 type for high-performance storage.

Conclusion

Understanding and properly implementing PVs, PVCs, and Storage Classes are essential for managing stateful applications in Kubernetes. These components help ensure that your applications can handle persistent data across Pod restarts and scaling events.

Stay tuned for the next article in our CK2024 series, where we’ll dive into more advanced Kubernetes topics.

For further reference, check out the detailed YouTube video here:

CK 2024 Blog Series: Understanding Docker Storage

Jensen Jose — Thu, 01 Aug 2024 10:53:42 +0000

Welcome back to the CK 2024 blog series! Today we're diving into Docker storage, this topic is essential for understanding how storage works in Docker and how to make it persistent, which is crucial before we move on to discussing Kubernetes storage in the next post.

Introduction to Docker Storage

Docker storage is fundamental for managing data within containers. In this post, we will cover the basics of Docker storage, how to use it, and how to make storage persistent. Understanding these concepts will set the stage for our upcoming discussion on Kubernetes storage.

Cloning a Repository and Creating a Docker File

To start, let's clone a GitHub repository. You can use any project, but for this example, we'll use a simple to-do app that we used in our Day 2 video. Here are the steps:

Clone the repository:

git clone https://github.com/your-repo/todo-app.git
cd todo-app

Create a Dockerfile with the following instructions:

FROM node:18-alpine
WORKDIR /app
COPY . .
RUN yarn install
EXPOSE 3000
CMD ["yarn", "start"]

Build the Docker image:

docker build -t todo-app .

Understanding Docker Image Layers

When you build a Docker image, it is composed of multiple layers. Each instruction in the Dockerfile creates a new layer. These layers are read-only and form the base of your container. Changes to the container are made in a writable layer on top of these read-only layers.

For example:

node:18-alpine creates a base layer of about 6.48 MB.
Additional layers are created for the WORKDIR, COPY, and RUN instructions. If you make changes to the Dockerfile and rebuild the image, Docker will only rebuild the layers that have changed, using a cache for the unchanged layers. This efficiency is a key benefit of Docker's layered architecture.

Making Data Persistent with Volumes

By default, data within a Docker container is ephemeral. Once the container stops or is removed, any data written to it is lost. To make data persistent, we use Docker volumes. Volumes store data outside the container's writable layer, allowing it to persist across container restarts and removals.

Create a volume:

docker volume create data-volume

Run a container with the volume:

docker run -d -p 3000:3000 --name todo-app -v data-volume:/app todo-app

Verify the volume:

docker volume ls

Storage Drivers

Docker uses storage drivers to manage how data is stored. The most common storage drivers are overlay2 for Linux, aufs, and device mapper, although aufs and device mapper are deprecated. These drivers manage the read-only layers and the writable container layer.

Persistent Data with Bind Mounts

Another way to persist data is by using bind mounts, which map a directory on the host machine to a directory in the container.

Run a container with a bind mount

docker run -d -p 3000:3000 --name todo-app -v /path/on/host:/app todo-app

This binds the host directory /path/on/host to the container directory /app, ensuring data is stored on the host machine.

Conclusion

Understanding Docker storage and making data persistent are critical skills for managing containerized applications. By using Docker volumes and bind mounts, you can ensure your data is safe and available even if containers are stopped or removed.

In the next post, we'll dive into Kubernetes storage, including persistent volumes and persistent volume claims. Stay tuned and happy coding!

For further reference, check out the detailed YouTube video here:

CK 2024 Blog Series: Understanding and Implementing Network Policies

Jensen Jose — Tue, 30 Jul 2024 14:19:07 +0000

Hello everyone, welcome back to my blog series CK 2024 and today, we are diving into an essential topic in Kubernetes: Network Policies. This is the 26th entry in our series, and I truly appreciate your support thus far. In this post, we'll explore what Network Policies are, how to implement them, and why they are critical for securing your Kubernetes clusters.

Why Network Policies?

Before we delve into the specifics of Network Policies, let's understand the network flow and why we need such policies. Imagine a three-tier web application with a web tier, application tier, and database tier. The web tier handles user requests over ports 80 (HTTP) and 443 (HTTPS). The application tier processes business logic, and the database tier runs a database server, such as MySQL, on port 3306.

In Kubernetes, by default, all pods can communicate with each other. This open communication can lead to security vulnerabilities. For instance, the front-end application should not directly access the database tier; only the back-end should have this privilege. To enforce these rules and restrict unnecessary access, we implement Network Policies.

Network Policies in Kubernetes

Network Policies in Kubernetes are rules that define how pods communicate with each other and other network endpoints. They provide a way to control traffic flow at the IP address or port level. These policies are crucial for securing your application by ensuring that only authorized pods can communicate with each other.

Implementing Network Policies

Let's consider a scenario where we have a Kubernetes cluster with three deployments: front-end, back-end, and database, each exposed through services. Here’s a step-by-step guide to implementing Network Policies:

Set Up Your Cluster First, ensure your cluster is running with a CNI (Container Network Interface) plugin that supports Network Policies. For this example, we'll use Weave as our CNI plugin.

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

Create the cluster with the following command:

kind create cluster --config kind-config.yaml

Install Weave CNI:

kubectl apply -f "https://cloud.weave.works/k8s/v1.8/net.yaml"

Deploy Applications Deploy the front-end, back-end, and database applications along with their services.

apiVersion: v1
kind: Pod
metadata:
  name: frontend
  labels:
    app: frontend
spec:
  containers:
    - name: frontend
      image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  ports:
    - port: 80
  selector:
    app: frontend
---
apiVersion: v1
kind: Pod
metadata:
  name: backend
  labels:
    app: backend
spec:
  containers:
    - name: backend
      image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  ports:
    - port: 80
  selector:
    app: backend
---
apiVersion: v1
kind: Pod
metadata:
  name: database
  labels:
    app: database
spec:
  containers:
    - name: database
      image: mysql
      env:
        - name: MYSQL_ROOT_PASSWORD
          value: password
---
apiVersion: v1
kind: Service
metadata:
  name: database
spec:
  ports:
    - port: 3306
  selector:
    app: database

Apply these manifests:

kubectl apply -f manifests.yaml

Create Network Policies Now, let's create a Network Policy to restrict access so that only the back-end can communicate with the database.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-to-database
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend

Apply the Network Policy:

kubectl apply -f network-policy.yaml

Verifying Network Policies

To verify the Network Policies, you can exec into the front-end pod and attempt to connect to the database. This connection should be denied:

kubectl exec -it frontend -- /bin/bash
curl database:3306

Similarly, the back-end should be able to connect to the database:

kubectl exec -it backend -- /bin/bash
curl database:3306

Conclusion

In this blog post, we discussed the importance of network policies in Kubernetes and how they help secure your applications. We also provided a step-by-step guide to implementing them. Network Policies are vital for maintaining a secure and controlled communication flow within your Kubernetes clusters.

Stay tuned for our next topic on storage. Until next time, happy coding!

For further reference, check out the detailed YouTube video here:

Understanding Deployments and Replica Sets in Kubernetes

Jensen Jose — Tue, 23 Jul 2024 14:56:15 +0000

Welcome to the next instalment of our CK 2024 blog series, where we dive deep into Kubernetes concepts and practices. In this post, we'll be focusing on Deployments and Replica Sets, which are fundamental to managing applications in a Kubernetes cluster.

What are Deployments?

A Deployment in Kubernetes is a higher-level concept that manages Replica Sets and provides declarative updates to Pods and Replica Sets. It's a powerful mechanism that ensures your application is always up and running, even in the face of failures.

Key Features of Deployments:

Declarative Updates: Define the desired state of your application, and Kubernetes will ensure it matches this state.
Rollback Support: Easily revert to a previous state in case of a faulty update.
Scaling: Automatically adjust the number of replicas to handle varying loads.
Self-healing: Automatically replace failed or unresponsive Pods.

Creating a Deployment

To create a Deployment, you need to define a Deployment manifest file in YAML format. Here’s an example:

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

In this manifest:

apiVersion and kind specify the type of Kubernetes object.
metadata provides metadata about the Deployment.
spec defines the desired state, including the number of replicas, selector criteria, and the Pod template.

Understanding Replica Sets

Replica Sets are responsible for maintaining a stable set of replica Pods running at any given time. They ensure that the specified number of replicas is always running.

Key Features of Replica Sets:

Self-healing: Automatically replaces failed Pods.
Selector-based Pod Matching: Uses selectors to identify the Pods it should manage.

Creating a Replica Set

Here's an example of a Replica Set manifest:

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

Deployments vs. Replica Sets

While Replica Sets manage the number of Pod replicas, Deployments provide additional functionality, such as rolling updates and rollbacks. Deployments use Replica Sets under the hood to manage Pods.

Rolling Updates with Deployments

One of the significant advantages of using Deployments is the ability to perform rolling updates. This ensures that updates are applied gradually, with minimal impact on the application’s availability.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

In the strategy section:

type: RollingUpdate specifies the update strategy.
maxUnavailable indicates the maximum number of Pods that can be unavailable during the update.
maxSurge specifies the maximum number of Pods that can be created above the desired number of replicas during the update.

Conclusion

Deployments and Replica Sets are essential components in Kubernetes that help you manage and scale your applications effectively. By understanding and utilizing these resources, you can ensure high availability, reliability, and seamless updates for your applications.

Stay tuned for the next post in our CK 2024 blog series, where we will explore Services in Kubernetes and how they enable communication between different parts of your application.

For further reference, check out the detailed YouTube video here:

Understanding SSL/TLS in Kubernetes

Jensen Jose — Mon, 22 Jul 2024 15:06:24 +0000

Welcome back to the CK2024 series! In this 21st instalment, we delve into the crucial topic of SSL/TLS within Kubernetes. Building on our previous discussion about SSL/TLS basics, this blog will explore how these security protocols are implemented in Kubernetes environments, focusing on certificate creation, signing requests, and overall security mechanisms.

Recap of SSL/TLS Basics

Before diving into Kubernetes specifics, let's briefly revisit the fundamental concepts of SSL/TLS. SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are cryptographic protocols designed to secure communications over a network. They use a combination of symmetric and asymmetric encryption to ensure the confidentiality and integrity of data.

In a typical SSL/TLS setup:

Client Certificates: Issued by clients to authenticate themselves to the server.
Server Certificates: Issued to servers to encrypt communication and authenticate themselves to clients.
Certificate Authority (CA): The entity that issues and signs certificates. It validates the identity of the certificate requester before issuing a certificate.

SSL/TLS in Kubernetes

Kubernetes, as a container orchestration platform, also relies on SSL/TLS for securing communications between its various components. Here’s a breakdown of how SSL/TLS operates within a Kubernetes cluster:

Components Involved:

Master Node: Manages the Kubernetes cluster and contains components like the API server, controller manager, and scheduler.
Worker Nodes: Host the containerized applications.
Clients: Users or tools like kubectl that interact with the Kubernetes API server.

Certificate Types:

Client Certificates: Used by users or clients to authenticate with the Kubernetes API server.
Server Certificates: Used by the API server and other components to secure communication.
Root Certificates: Issued by the CA and used to verify the authenticity of certificates issued to clients and servers.

Certificate Workflow:

Client to API Server: When a client (like kubectl) communicates with the API server, both the client and the server need certificates to establish a secure connection.
Master Node to Worker Node: Communication between the master node and worker nodes also needs to be encrypted, requiring certificates for both ends.
Component-to-Component Communication: Internal communications, such as between the API server and etcd (the key-value store), or between various controllers and schedulers, must also be secured with appropriate certificates.

Creating and Using Certificates in Kubernetes

Generating Certificates:

Use tools like OpenSSL to generate private keys and certificate signing requests (CSRs).
Example command to generate a private key

openssl genrsa -out adam.key 2048

Example command to create a CSR

openssl req -new -key adam.key -out adam.csr

Creating a Certificate Signing Request (CSR) in Kubernetes:

Define a CSR in YAML format to submit to the Kubernetes API server.
Example YAML for a CSR:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: adam
spec:
  request: <base64-encoded-csr>
  usages:
    - digital signature
    - key encipherment
    - server auth

Apply the CSR using kubectl:

kubectl apply -f csr.yaml

Approving the CSR:

As an administrator, approve the CSR using:

kubectl certificate approve adam

Distributing Certificates:

Once approved, you can retrieve the issued certificate and share it with the user. Decode the certificate if needed:

kubectl get csr adam -o yaml

Summary

In this blog, we’ve covered the essentials of SSL/TLS in Kubernetes, including how to generate and manage certificates for securing communications between various components of a Kubernetes cluster. Understanding these concepts is crucial for maintaining the security of your Kubernetes environments.

Thank you for following along with Day 21 of CK2024. Stay tuned for more in-depth coverage of Kubernetes concepts and practices. Happy learning, and see you in the next post!

For further reference, check out the detailed YouTube video here:

Understanding SSL/TLS - How It Works End-to-End

Jensen Jose — Thu, 18 Jul 2024 14:32:56 +0000

Hello everyone, welcome back to the CK 2024 blog series! This is the 20th entry in our series. Before diving into our next topic on certificates in Kubernetes, I wanted to ensure we have a solid understanding of how SSL/TLS works. If you're already familiar with this topic, feel free to skip to the next blog in the series if not, let's get started!

What is SSL/TLS?

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are protocols that provide a secure communication channel between a client (user) and a server over the internet. They are essential for protecting data transmitted over the web, ensuring that sensitive information such as usernames, passwords, and credit card details are encrypted and secure from eavesdropping and tampering.

The Basics: HTTP vs. HTTPS

When a user sends a request to a server (for example, accessing a website), this communication can happen over HTTP (HyperText Transfer Protocol) or HTTPS (HTTP Secure). HTTP is not secure, meaning data sent over it can be intercepted and read by anyone who has access to the data flow. HTTPS, on the other hand, encrypts the data using SSL/TLS, making it secure.

Understanding SSL/TLS with an Example

Let's break down how SSL/TLS works with a simple example. Imagine a user trying to access a web server. Here are the steps involved:

Client Requests Access: The user sends an HTTP request to the server.
Server Requests Authentication: The server asks for the user's authentication details (username and password).
Client Sends Credentials: The user sends their credentials to the server.
Server Authenticates and Responds: The server authenticates the user and sends back the requested data.

However, this process over HTTP is vulnerable to attacks. A hacker can intercept the data (credentials) and misuse it. This is where SSL/TLS comes into play.

Introducing Encryption

To secure this communication, we use encryption. There are two main types of encryption:

Symmetric Encryption: The same key is used for both encryption and decryption. While simple, it has a significant vulnerability: if a hacker intercepts the key, they can decrypt all data.
Asymmetric Encryption: This uses a pair of keys - a public key for encryption and a private key for decryption. This method enhances security as the private key is never shared.

How SSL/TLS Uses Asymmetric Encryption

Here’s how SSL/TLS uses asymmetric encryption to secure communication:

Server Generates Keys: The server generates a public and private key pair using tools like OpenSSL.
Client Requests Access: The user sends an HTTP request to the server.
Server Sends Public Key: The server responds with its public key.
Client Encrypts Data: The client encrypts their data (e.g., a symmetric key for further communication) using the server’s public key.
Data Sent to Server: The encrypted data is sent to the server.
Server Decrypts Data: The server uses its private key to decrypt the data.

Certificates and Certificate Authorities (CA)

To further enhance security, SSL/TLS uses certificates issued by Certificate Authorities (CA). These certificates validate that the public key truly belongs to the server and not an imposter. Here's how it works:

Server Creates a CSR: The server generates a Certificate Signing Request (CSR).
CA Validates CSR: The CA validates the CSR, ensuring the server's identity.
CA Issues Certificate: The CA issues a certificate containing the server’s public key and other identity details.
Client Validates Certificate: When the client receives the server’s certificate, it validates the certificate against the CA’s public certificates stored in the client’s browser.

The Importance of SSL/TLS

Using SSL/TLS ensures that:

Data integrity is maintained.
Communication is secure and encrypted.
Users can trust that they are communicating with the intended server.

Conclusion

Understanding SSL/TLS is crucial for ensuring secure communication over the internet. In our next post, we'll dive deeper into how certificates are used specifically in Kubernetes, how to create a certificate signing request, and more.

Stay tuned, and if you have any questions or need further clarification, feel free to reach out. See you in the next post!

For further reference, check out the detailed YouTube video here:

Happy Learning!!

ConfigMaps and Secrets in Kubernetes

Jensen Jose — Wed, 17 Jul 2024 15:08:50 +0000

Hello everyone, welcome back to my blog series CK 2024! Today we’ll be diving into the concepts of ConfigMaps and Secrets in Kubernetes. Although we touched on these topics briefly in earlier posts, I realized we haven’t given them the full attention they deserve. So, let's rectify that today with an in-depth look and a hands-on demo.

Understanding ConfigMaps and Secrets

In Kubernetes, ConfigMaps and Secrets allow you to decouple configuration artifacts from image content to keep your containerized applications portable. ConfigMaps are used to store non-confidential data in key-value pairs, while Secrets are intended for confidential data such as passwords, OAuth tokens, and SSH keys.

Why Use ConfigMaps?

In one of our earlier discussions (Day 11), we saw how environment variables could be directly defined in the Pod's YAML file. However, as the number of environment variables grows, maintaining them directly in the Pod definition becomes impractical, especially if these variables are shared across multiple Pods. ConfigMaps help by centralizing this configuration data, making it easier to manage and reuse.

Creating a ConfigMap

Let's walk through creating a ConfigMap. We’ll start with an example where we need to define an environment variable in a Pod. Here’s a basic Pod definition:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mycontainer
      image: busybox
      command: ['sh', '-c', 'echo The app is running! && sleep 3600']
      env:
        - name: MY_VAR
          value: "my_value"

Instead of defining MY_VAR directly in the Pod, we’ll use a ConfigMap.

1. Imperative Approach:

kubectl create configmap myconfigmap --from-literal=MY_VAR=my_value

2. Declarative Approach:

Create a configmap.yaml file:

apiVersion: v1
kind: ConfigMap
metadata:
  name: myconfigmap
data:
  MY_VAR: my_value

Apply this file:

kubectl apply -f configmap.yaml

Injecting ConfigMap into a Pod

Now, let's modify our Pod to use the ConfigMap:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mycontainer
      image: busybox
      command: ['sh', '-c', 'echo The app is running! && sleep 3600']
      envFrom:
        - configMapRef:
            name: myconfigmap

Here, envFrom is used to import all key-value pairs from the ConfigMap into the Pod’s environment.

Conclusion

ConfigMaps and Secrets are essential tools in Kubernetes for managing application configuration and sensitive data. They help maintain clean and efficient Pod definitions and enhance security practices

Feel free to reach out in the comments section- if you have any questions or need further assistance.

For further reference, check out the detailed YouTube video here:

Understanding Health Probes in Kubernetes

Jensen Jose — Tue, 16 Jul 2024 15:52:35 +0000

Hello everyone, welcome back to the CK2024 blog series! This is blog number 18 and we’ll dive into health probes in Kubernetes: liveness probes, readiness probes, and startup probes. We’ll explore these concepts in detail with hands-on practice.

What Are Health Probes?

Before we get into the demo, let’s understand what health probes are in Kubernetes. Health probes are mechanisms used to monitor and manage the health of your applications running in Kubernetes. There are three main types of probes:

Liveness Probes: Ensure your application is running. If the liveness probe fails, Kubernetes will restart the container.
Readiness Probes: Ensure your application is ready to serve traffic. If the readiness probe fails, Kubernetes will stop sending traffic to the container.
Startup Probes: Used for slow-starting applications. Ensures that the application has started successfully before running liveness or readiness probes. These probes help in maintaining the health and availability of your applications by automatically recovering from failures.

Liveness Probes

Liveness probes monitor your application and restart the container if it fails. This is useful when your application crashes due to intermittent issues that can be resolved with a restart.

Here's an example of a liveness probe using a command:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

In this example, the liveness probe runs a command to check if a file exists. If the file doesn’t exist, the probe fails, and Kubernetes restarts the container.

Readiness Probes

Readiness probes ensure your application is ready to serve traffic. If the readiness probe fails, the container is removed from the service’s endpoints, stopping it from receiving traffic until it is ready again.

Here's an example of a readiness probe using an HTTP GET request:

apiVersion: v1
kind: Pod
metadata:
  name: readiness-http
spec:
  containers:
  - name: readiness
    image: my-app
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

In this example, the readiness probe sends an HTTP GET request to /healthz. If the response is not successful, the probe fails, and the container stops receiving traffic.

Startup Probes

Startup probes are used for applications that take a long time to start. This probe ensures the application starts successfully before the liveness and readiness probes are activated.

Here’s an example of a startup probe:

apiVersion: v1
kind: Pod
metadata:
  name: startup-probe
spec:
  containers:
  - name: startup
    image: my-app
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 10

In this example, the startup probe sends an HTTP GET request to /healthz. It will wait for the initial delay before performing the first check and continue at specified intervals. If the probe fails, the container will be restarted.

Hands-On Practice

To reinforce your understanding, we’ll do a demo and configure these probes in a Kubernetes cluster. Follow along in the video to see the implementation in action.

Liveness Probe Demo

We’ll create a pod with a liveness probe that checks if a file exists:

Create a YAML file for the pod configuration:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

Apply the configuration:

kubectl apply -f liveness-exec.yaml

Observe the pod behavior:

kubectl get pods -w

You’ll see that the pod restarts when the file is removed, indicating the liveness probe failure.

Readiness Probe Demo

We’ll create a pod with a readiness probe that checks an HTTP endpoint:

Create a YAML file for the pod configuration:

apiVersion: v1
kind: Pod
metadata:
  name: readiness-http
spec:
  containers:
  - name: readiness
    image: my-app
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

Apply the configuration:

kubectl apply -f readiness-http.yaml

Observe the pod behavior:

kubectl get pods -w

The pod will only start receiving traffic once the readiness probe passes.

Startup Probe Demo

We’ll create a pod with a startup probe:

Create a YAML file for the pod configuration:

apiVersion: v1
kind: Pod
metadata:
  name: startup-probe
spec:
  containers:
  - name: startup
    image: my-app
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 10

Apply the configuration:

kubectl apply -f startup-probe.yaml

Observe the pod behavior:

kubectl get pods -w

The startup probe ensures the application is fully started before the liveness and readiness probes are activated.

Conclusion

In this blog, we’ve explored health probes in Kubernetes, including liveness, readiness, and startup probes. These probes help maintain the health and availability of your applications by automatically recovering from failures.

For further reference, check out the detailed YouTube video here:

Happy learning!

Understanding Auto Scaling in Kubernetes

Jensen Jose — Mon, 15 Jul 2024 14:29:49 +0000

Welcome back to the CK2024 blog series! I'm excited to dive into the concept of auto-scaling in Kubernetes which is a crucial aspect of managing Kubernetes clusters efficiently, especially for beginners and those looking to deepen their understanding.

What is Scaling?

Scaling refers to adjusting your servers or workloads to meet demand. This adjustment can be done manually or automatically. Scaling ensures that your applications can handle increased traffic or resource utilization without manual intervention.

In Kubernetes, we often talk about scaling in terms of Deployments and ReplicaSets. Deployments allow us to manage multiple replicas of a single pod, ensuring that our applications can handle varying loads.

Manual vs. Automatic Scaling

In a traditional setup, scaling might involve manually updating the number of replicas in a Deployment or ReplicaSet. This approach can be inefficient and impractical for large-scale applications running in production environments. Automatic scaling, on the other hand, adjusts the number of pods based on current demand and resource utilization, ensuring optimal performance and resource usage.

Types of Auto Scaling in Kubernetes

Horizontal Pod Autoscaling (HPA)
Horizontal Pod Autoscaling automatically adds or removes pod replicas based on CPU and memory utilization. For example, if the average CPU utilization exceeds a specified threshold, HPA will add more pods to handle the increased load.
Vertical Pod Autoscaling (VPA)
Vertical Pod Autoscaling adjusts the resource requests and limits of a pod, effectively resizing it to meet the demand. This approach can result in pod restarts, so it's suitable for non-mission-critical applications that can tolerate downtime.

Practical Example: Horizontal Pod Autoscaling

Let's walk through a practical example to illustrate how HPA works.

Prerequisites: Ensure that the metrics server is running in your cluster. The metrics server provides the necessary metrics for HPA to make scaling decisions.

kubectl get pods -n kube-system
# Ensure metrics-server is running

Create Deployment and Service: We'll create a deployment and expose it via a service.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      app: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        app: php-apache
    spec:
      containers:
      - name: php-apache
        image: k8s.gcr.io/hpa-example
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 200m
          limits:
            cpu: 500m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
spec:
  selector:
    app: php-apache
  ports:
  - port: 80
    targetPort: 80

Apply the YAML file:

kubectl apply -f deployment.yaml

Create HPA: Now, we create an HPA object to scale our deployment based on CPU utilization.

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

Generate Load: To see HPA in action, we'll generate load on the deployment.

kubectl run -i --tty load-generator --image=busybox /bin/sh
# Inside the pod, run the following command to generate load
while true; do wget -q -O- http://php-apache; done

Monitor HPA: Monitor the HPA to see how it scales the deployment.

kubectl get hpa -w

As the load increases, HPA will add more replicas to handle the demand. Once the load decreases, HPA will scale down the replicas to the minimum specified.

Conclusion

Understanding and implementing auto-scaling is essential for managing Kubernetes clusters efficiently. Horizontal and vertical scaling ensures that your applications can handle varying loads while optimizing resource usage. While HPA is built into Kubernetes, VPA and other advanced scaling features may require additional setup or managed cloud services.

In the next post, we'll explore liveness and readiness probes in Kubernetes, which are crucial for ensuring that your applications are running smoothly and are available to serve requests. Happy learning!

For further reference, check out the detailed YouTube video here:

Understanding Resource Requests and Limits in Kubernetes

Jensen Jose — Thu, 11 Jul 2024 16:42:38 +0000

Welcome back to the CK 2024 blog series! In this post, we’ll delve into the critical concept of resource requests and limits in Kubernetes, a mechanism the scheduler uses to allocate pods to nodes efficiently. If you missed any of the previous posts in this series, I recommend checking those out to build a strong foundation.

Recap

In the previous blog in this series, we explored how Kubernetes uses resource requests and limits to manage pod scheduling and ensure optimal resource utilization across nodes. Let’s break down this concept and see it in action through examples and exercises.

Why Resource Requests and Limits Matter

In Kubernetes, each pod requires a certain amount of CPU and memory to run. Without proper resource allocation, a pod can monopolize node resources, leading to performance issues and potential crashes. This is where resource requests and limits come into play:

Resource Requests: The minimum amount of CPU and memory guaranteed to the pod.
Resource Limits: The maximum amount of CPU and memory the pod can use.

How It Works

Node Specifications:

Node 1: 4 CPUs, 4 GB of memory.
Node 2: 4 CPUs, 4 GB of memory.

Pod Scheduling:

Each pod requests 1 CPU and 1 GB of memory.
The scheduler checks if the node has sufficient resources.
If the node has enough resources, the pod is scheduled.
Once the node is full, the scheduler moves to the next node.
If no nodes have sufficient resources, the pod remains unscheduled.

Example Scenario

Let’s consider a node with 4 CPUs and 4 GB of memory. We have a pod that requires 1 CPU and 1 GB of memory. Initially, the pod is allocated the requested resources. However, if the load increases, the pod might try to consume all available resources, leading to potential crashes. To prevent this, we set resource limits.

Setting Resource Requests and Limits

Here’s a YAML configuration for a pod with resource requests and limits:

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "100Mi"
      limits:
        memory: "200Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

Requests: 100 Mi of memory.
Limits: 200 Mi of memory.
Command: The pod will use 150 Mi of memory, staying within the defined limits.

Demonstration

Apply the YAML:

kubectl apply -f memory-demo.yaml

Check the Pod:

kubectl get pods

Verify that the pod is running within the specified limits.

Stress Testing:

Increase the pod’s memory usage beyond the limit to observe behavior.
The pod will be terminated with an Out of Memory (OOM) error if it exceeds the limit.

Conclusion

Resource requests and limits are essential for maintaining the stability and performance of your Kubernetes cluster. By defining these boundaries, you ensure that pods do not consume more resources than allowed, preventing potential node failures and ensuring a smooth operation.

Remember to practice these configurations and refer to the Kubernetes documentation for further details. In the next post, we’ll explore autoscaling and how it leverages these metrics for efficient resource management.

For further reference, check out the detailed YouTube video here:

Understanding Node Affinity in Kubernetes

Jensen Jose — Wed, 10 Jul 2024 16:39:34 +0000

Welcome back to our Kubernetes series! In this instalment, we delve into an essential scheduling concept: Node Affinity. Node Affinity allows Kubernetes to schedule pods based on node labels, ensuring specific workloads run on designated nodes.

Recap: Taints and Tolerations

Previously, we explored Taints and Tolerations, which allow nodes to repel or accept pods based on certain conditions like hardware constraints or other node attributes. However, Taints and Tolerations have limitations when it comes to specifying multiple conditions or ensuring pods are scheduled on specific nodes.

Introducing Node Affinity

Node Affinity addresses these limitations by enabling Kubernetes to schedule pods onto nodes that match specified labels. Let's break down how Node Affinity works:

Matching Pods with Node Labels

Consider a scenario with three nodes labeled based on their disk types:

Node 1: disk=HDD
Node 2: disk=SSD
Node 3: disk=SSD

We want to ensure:

HDD-intensive workloads run only on Node 1.
SSD-intensive workloads are scheduled on Node 2 or Node 3.

Affinity Rules

Node Affinity uses rules like requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution to define scheduling behaviours:

requiredDuringSchedulingIgnoredDuringExecution: Ensures a pod is only scheduled if a matching node label is found during scheduling.
preferredDuringSchedulingIgnoredDuringExecution: Prefers to schedule a pod on a node with matching labels but can schedule on other nodes if no match is found.

Example: YAML Configuration

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: app
      image: nginx
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disk
                operator: In
                values:
                  - SSD
                  - HDD

In this example, the pod example-pod is configured to run on nodes labeled with disk=SSD or disk=SDD.

Practical Demo

We applied this configuration and observed how Kubernetes scheduled pods based on node labels. Even when labels were modified post-scheduling, existing pods remained unaffected, showcasing Node Affinity's robustness in maintaining pod placement integrity.

Key Differences from Taints and Tolerations

While Taints and Tolerations focus on node acceptance or rejection based on predefined conditions, Node Affinity ensures pods are scheduled on nodes that specifically match given criteria. This distinction is crucial for workload optimization and resource allocation in Kubernetes clusters.

Conclusion

Node Affinity enhances Kubernetes scheduling capabilities by allowing fine-grained control over pod placement based on node attributes. Understanding and effectively utilizing Node Affinity can significantly improve workload performance and cluster efficiency.

Stay tuned for our next installment, where we'll explore Kubernetes resource requests and limits—a critical aspect of optimizing resource utilization in your Kubernetes deployments.

For further reference, check out the detailed YouTube video here:

Understanding Taints and Tolerations in Kubernetes

Jensen Jose — Tue, 09 Jul 2024 17:12:18 +0000

Welcome back to my blog series on Kubernetes! Today we will be taking a dive into a crucial yet confusing topic: Taints and Tolerations. Understanding this concept is vital for anyone working with Kubernetes, as it helps manage workloads more effectively. By the end of this post, you'll have a clear understanding of how to use taints and tolerations, and you'll be able to apply these concepts confidently in your own projects.

What Are Taints and Tolerations?

Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. Taints are applied to nodes, and they repel pods that do not have the corresponding toleration. This mechanism is essential for managing workloads that have specific requirements, such as running AI workloads on nodes with GPUs.

How Taints Work

A taint is a key-value pair that you apply to a node. For instance, you might have a node dedicated to AI workloads, which requires GPUs. You can taint this node with key=value, such as GPU=true. This taint will prevent pods that do not tolerate this taint from being scheduled on the node.

How Tolerations Work

To allow a pod to be scheduled on a node with a taint, you need to add a toleration to the pod. A toleration has to match the taint's key-value pair. For example, if your node has a taint GPU=true, your pod must have a toleration GPU=true to be scheduled on that node.

Taints and Tolerations in Action

Let's break down a practical example:

Tainting a Node:

kubectl taint nodes <node-name> GPU=true:NoSchedule

This command applies a taint to a node, ensuring that only pods with the toleration GPU=true can be scheduled on it.

Adding a Toleration to a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: ai-pod
spec:
  containers:
  - name: ai-container
    image: ai-image
  tolerations:
  - key: "GPU"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"

This YAML file defines a pod with a toleration that matches the node taint.

When you create this pod, Kubernetes will check the taint on the node and the toleration on the pod. If they match, the pod will be scheduled on the tainted node.

Effects of Taints

There are three main effects that you can specify with taints:

NoSchedule: Pods that do not tolerate the taint will not be scheduled on the node.
PreferNoSchedule: Kubernetes will try to avoid scheduling pods that do not tolerate the taint on the node, but it is not guaranteed.
NoExecute: Pods that do not tolerate the taint will be evicted from the node if they are already running.

Node Selectors

While taints and tolerations control which pods can be scheduled on which nodes, node selectors are another way to control pod placement. Node selectors work by adding labels to nodes and specifying those labels in pod specifications.

apiVersion: v1
kind: Pod
metadata:
  name: ai-pod
spec:
  containers:
  - name: ai-container
    image: ai-image
  nodeSelector:
    GPU: "true"

This configuration ensures that the pod is only scheduled on nodes with the label GPU=true.

Example: Scheduling Pods with Taints and Tolerations

Let's see how this works in practice. First, we'll taint a node:

kubectl taint nodes worker1 GPU=true:NoSchedule

Next, we'll create a pod with a matching toleration:

apiVersion: v1
kind: Pod
metadata:
  name: ai-pod
spec:
  containers:
  - name: ai-container
    image: ai-image
  tolerations:
  - key: "GPU"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"

Apply this pod configuration:

kubectl apply -f ai-pod.yaml

The pod will be scheduled on the tainted node because it has the appropriate toleration.

Conclusion

Taints and tolerations are powerful tools in Kubernetes that help you manage where pods are scheduled. By using taints, you can prevent certain workloads from running on specific nodes, while tolerations allow pods to be scheduled on nodes with matching taints. Node selectors provide additional control over pod placement by matching pod labels to node labels.

I hope this post has clarified the concept of taints and tolerations for you. In the next blog post, we'll explore node affinity and anti-affinity, which provide even more control over pod scheduling.

Happy coding, and stay tuned for the next post in this series!

For further reference, check out the detailed YouTube video here: