Skip to content

CKAD

Notes for Network and Services

CKAD
1. Introduction to Network Policies in Kubernetes

Network Policies in Kubernetes allow you to control the flow of traffic at the IP address or port level, which is crucial for ensuring that only authorized services can communicate with each other.

2. Understanding Pod Isolation
  • Non-isolated Pods: By default, pods in Kubernetes can receive traffic from any source. Without any network policies, pods are considered non-isolated.
  • Isolated Pods: When a pod is selected by a network policy, it becomes isolated, and only traffic allowed by the network policies will be permitted.
3. Creating a Front-end and Back-end Pod
  • Scenario: We have a front-end web application and a back-end API service. We want to ensure that only the front-end can communicate with the back-end.

  • Front-end Pod:

    apiVersion: v1
kind: Pod
metadata:
  name: frontend-pod
  labels:
    app: frontend
spec:
  containers:
  - name: frontend-container
    image: nginx

  • Back-end Pod:

    apiVersion: v1
kind: Pod
metadata:
  name: backend-pod
  labels:
    app: backend
spec:
  containers:
  - name: backend-container
    image: nodejs
4. Implementing a Default Deny Network Policy

  • Objective: Create a default deny policy to ensure that no unauthorized communication occurs.

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
5. Allowing Traffic from Front-end to Back-end

  • Objective: Allow only the front-end pod to communicate with the back-end pod.

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 80

  • Explanation: This policy allows ingress traffic to the back-end pod (label app: backend) only from the front-end pod (label app: frontend).

6. Testing and Verifying Network Policies
  • Testing: Use kubectl exec to simulate traffic from the front-end to the back-end and verify that the traffic is allowed. Attempt to access the back-end from a different pod and observe that the traffic is blocked.
Summary

Employing network policies ensures secure communication within your Kubernetes cluster, adhering to the principle of least privilege.

Kubernetes Services with Pod Creation

CKAD
1. Introduction to Kubernetes Services
  • Purpose: Kubernetes Services allow for the exposure of applications running on Pods, both within the cluster and externally.
  • Types of Services: Includes ClusterIP for internal exposure and NodePort for external exposure.
2. Creating a Sample Application Pod
  • Objective: Deploy a simple web application pod to demonstrate service exposure.

  • Pod YAML Example:

    apiVersion: v1
kind: Pod
metadata:
  name: web-app-pod
  labels:
    app: web-app
spec:
  containers:
  - name: nginx-container
    image: nginx

  • Explanation: This creates a pod named web-app-pod with an Nginx container, labeled app: web-app, which we will expose using Services.

3. Exposing the Pod with a ClusterIP Service
  • Objective: Expose the web-app-pod within the cluster.

  • Service YAML Example:

    apiVersion: v1
kind: Service
metadata:
  name: clusterip-web-service
spec:
  type: ClusterIP
  selector:
    app: web-app
  ports:
    - protocol: TCP
      port: 8081
      targetPort: 80

  • Explanation: The clusterip-web-service exposes the web-app-pod inside the cluster on TCP port 8081.

4. Exposing the Pod with a NodePort Service
  • Objective: Expose the web-app-pod externally, outside the Kubernetes cluster.

  • Service YAML Example:

    apiVersion: v1
kind: Service
metadata:
  name: nodeport-web-service
spec:
  type: NodePort
  selector:
    app: web-app
  ports:
    - protocol: TCP
      port: 8082
      targetPort: 80
      nodePort: 30081

  • Explanation: The nodeport-web-service makes the pod accessible externally on TCP port 30081 on each node in the cluster.

5. Verifying Service Exposure
  • ClusterIP Verification: Use kubectl exec to access the web-app-pod from another pod within the cluster using the ClusterIP service.
  • NodePort Verification: Access the web-app-pod externally using <NodeIP>:30081, where NodeIP is the IP address of any node in the cluster.
6. Summary
  • Effective Use of Services: Understanding how to expose pods using ClusterIP and NodePort services is essential for application accessibility in Kubernetes.

Implementing Blue/Green and Canary Deployment Strategies in Kubernetes

CKAD

Overview

Learn how to implement blue/green and canary deployment strategies in Kubernetes. These methods enhance stability and reliability when deploying new versions of applications.

Key Concepts

Blue/Green and Canary deployments are strategies to reduce risks during application updates, allowing gradual and controlled rollouts.

Blue/Green Deployment

What is Blue/Green Deployment?

Blue/Green Deployment involves two identical environments: one active (Blue) and one idle (Green). New versions are deployed to Green and, after testing, traffic is switched from Blue to Green.

Blue Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue-deployment
  labels:
    app: bluegreen-test
    color: blue
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bluegreen-test
      color: blue
  template:
    metadata:
      labels:
        app: bluegreen-test
        color: blue
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80
Green Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: green-deployment
  labels:
    app: bluegreen-test
    color: green
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bluegreen-test
      color: green
  template:
    metadata:
      labels:
        app: bluegreen-test
        color: green
    spec:
      containers:
        - name: nginx
          image: nginx:1.15.8
          ports:
            - containerPort: 80
Service to Switch Traffic
apiVersion: v1
kind: Service
metadata:
  name: bluegreen-test-svc
spec:
  selector:
    app: bluegreen-test
    color: blue  # Change to green to switch traffic
  ports:
    - protocol: TCP
      port: 80

Switching Traffic

Update the color label in the Service from blue to green to direct traffic to the new version.

Canary Deployment

What is Canary Deployment?

Canary Deployment involves rolling out a new version to a small subset of users before deploying it to the entire user base, allowing for gradual and controlled updates.

Main Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: main-deployment
spec:
  replicas: 5  # Main user base
  selector:
    matchLabels:
      app: canary-test
      environment: main
  template:
    metadata:
      labels:
        app: canary-test
        environment: main
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80

Canary Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: canary-deployment
spec:
  replicas: 1  # Subset of users
  selector:
    matchLabels:
      app: canary-test
      environment: main
  template:
    metadata:
      labels:
        app: canary-test
        environment: main
    spec:
      containers:
        - name: nginx
          image: nginx:1.15.8
          ports:
            - containerPort: 80

Service to Direct Traffic:

apiVersion: v1
kind: Service
metadata:
  name: canary-test-svc
spec:
  selector:
    app: canary-test
  ports:
    - protocol: TCP
      port: 80

Managing Traffic

Control user exposure to the new version by adjusting the number of replicas in the canary deployment.

Conclusion

Blue/Green and Canary deployment strategies in Kubernetes offer a methodical approach to manage application updates, reducing risks and ensuring a smoother rollout process.

CKAD kubectl Cheat Sheet

CKAD

0. Context Management

0.1 View Current Context

kubectl config current-context

0.2 List All Contexts

kubectl config get-contexts

0.3 Switch Context

kubectl config use-context my-context
  • my-context: Name of the context to switch to.

1. Pods

1.1 Managing a Pod

Creating a Pod
kubectl run my-pod --image=nginx:latest --restart=Never --env=VAR1=value1
  • --image nginx:latest: Specifies the container image.
  • --restart Never: Controls the restart policy.
  • --env VAR1=value1: Sets environment variables.

Declarative:

  • Generate YAML:
kubectl run my-pod --image=nginx:latest --restart=Never --env=VAR1=value1 --dry-run=client -o yaml > my-pod.yaml
  • Apply YAML:
kubectl apply -f my-pod.yaml
Getting Pods
kubectl get pods -o wide --watch
  • -o wide: Provides more detailed output.
  • --watch: Watches for changes in real-time.
Describing a Pod
kubectl describe pod my-pod

2. Deployments

2.1 Managing Deployments

Creating a Deployment
kubectl create deployment my-deployment --image=nginx:latest --replicas=2
  • --image nginx:latest: Specifies the container image.
  • --replicas 2: Number of desired replicas.

Declarative:

  • Generate YAML:
kubectl create deployment my-deployment --image=nginx:latest --replicas=2 --dry-run=client -o yaml > my-deployment.yaml
  • Apply YAML:
kubectl apply -f my-deployment.yaml
Scaling a Deployment
kubectl scale deployment my-deployment --replicas=5
  • --replicas 5: Sets the number of desired replicas.

Declarative:

  • Update YAML: Adjust replicas in my-deployment.yaml file.
  • Apply YAML:
kubectl apply -f my-deployment.yaml

3. Services

3.1 Creating a Service

kubectl expose deployment my-deployment --port=80 --type=ClusterIP
  • --port 80: Specifies the port number.
  • --type ClusterIP: Defines the type of service.

Declarative:

  • Generate YAML:
kubectl expose deployment my-deployment --port=80 --type=ClusterIP --dry-run=client -o yaml > my-service.yaml
  • Apply YAML:
kubectl apply -f my-service.yaml

4. Namespaces

4.1 Managing Namespaces

Creating a Namespace
kubectl create namespace my-namespace

Declarative:

  • Generate YAML:
kubectl create namespace my-namespace --dry-run=client -o yaml > my-namespace.yaml
  • Apply YAML:
kubectl apply -f my-namespace.yaml
Listing Namespaces
kubectl get namespaces

5. Configuration

5.1 Managing ConfigMaps and Secrets

Creating a ConfigMap
kubectl create configmap my-configmap --from-literal=key1=value1 --from-file=./config-file.txt
  • --from-literal key1=value1: Sets a key-value pair directly.
  • --from-file ./config-file.txt: Creates a ConfigMap from a file.

Declarative:

  • Generate YAML:
kubectl create configmap my-configmap --from-literal=key1=value1 --from-file=./config-file.txt --dry-run=client -o yaml > my-configmap.yaml

-

Apply YAML:

kubectl apply -f my-configmap.yaml
Creating a Secret
kubectl create secret generic my-secret --from-literal=key1=value1 --from-file=./secret-file.txt
  • --from-literal key1=value1: Sets a key-value pair for the secret.
  • --from-file ./secret-file.txt: Creates a Secret from a file.

Declarative:

  • Generate YAML:
kubectl create secret generic my-secret --from-literal=key1=value1 --from-file=./secret-file.txt --dry-run=client -o yaml > my-secret.yaml
  • Apply YAML:
kubectl apply -f my-secret.yaml

6. Monitoring and Logging

6.1 Getting Logs

kubectl logs my-pod -f --since=1h
  • -f: Follow log output in real-time.
  • --since 1h: Show logs since a certain time.

7. Jobs and CronJobs

7.1 Managing Jobs and CronJobs

Creating a Job
kubectl create job my-job --image=busybox
  • --image busybox: Specifies the container image.

Declarative:

  • Generate YAML:
kubectl create job my-job --image=busybox --dry-run=client -o yaml > my-job.yaml
  • Apply YAML:
kubectl apply -f my-job.yaml
Creating a CronJob
kubectl create cronjob my-cronjob --schedule="*/5 * * * *" --image=busybox
  • --schedule "*/5 * * * *": Sets the cron schedule in cron format.

Declarative:

  • Generate YAML:
kubectl create cronjob my-cronjob --schedule="*/5 * * * *" --image=busybox --dry-run=client -o yaml > my-cronjob.yaml
  • Apply YAML:
kubectl apply -f my-cronjob.yaml

8. Rolling Updates and Rollbacks

8.1 Managing Updates and Rollbacks

Updating a Deployment
kubectl set image deployment/my-deployment nginx=nginx:1.9.1

Declarative:

  • Update YAML: Adjust image in my-deployment.yaml.
  • Apply YAML:
kubectl apply -f my-deployment.yaml
Rolling Back a Deployment
kubectl rollout undo deployment/my-deployment

Declarative:

  • Use previous version of my-deployment.yaml.
  • Apply YAML:
kubectl apply -f my-deployment.yaml

9. Resource Management

9.1 Setting Resource Requests and Limits

kubectl set resources deployment/my-deployment --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi
  • --limits cpu=200m,memory=512Mi and --requests cpu=100m,memory=256Mi: Set resource constraints.

Declarative:

  • Update YAML: Adjust resources in my-deployment.yaml.
  • Apply YAML:
kubectl apply -f my-deployment.yaml

10. Debugging

10.1 Diagnosing and Fixing Issues

Executing into a Container
kubectl exec -it my-pod -- /bin/bash

Declarative: Not applicable for exec command.

Port Forwarding
kubectl port-forward my-pod 8080:80
  • 8080:80: Forwards local port 8080 to the Pod's port 80.

Declarative: Not applicable for port-forward command.

Copying Files to/from a Container
kubectl cp /path/on/local/file.txt my-pod:/path/in/container/file.txt

Declarative: Not applicable for cp command.

11. Labels and Selectors

11.1 Managing Labels

Adding Labels to a Pod
kubectl label pods my-pod key1=value1 key2=value2
  • Adds labels key1=value1 and key2=value2 to my-pod.
Updating Labels of a Pod
kubectl label pods my-pod key1=value1 --overwrite
  • Updates the value of key1 to value1 on my-pod, overwriting if it exists.
Removing Labels from a Pod
kubectl label pods my-pod key1-
  • Removes the label key1 from my-pod.
Filtering Resources by Labels
kubectl get pods -l key1=value1,key2=value2
  • Lists all pods with labels key1=value1 and key2=value2.
Using Labels for Resource Management
  • Imperative:
  • Assigning a label:
kubectl label pods my-pod env=dev
  • Selecting resources:
kubectl get pods -l env=dev
  • Declarative:
  • Update YAML: Add labels under metadata.labels in resource definition files.
  • Apply YAML:
kubectl apply -f <resource-definition-file>.yaml

Deploying and Managing MySQL with Helm in Kubernetes

CKAD

Overview

This guide explains how to deploy and manage the MySQL database using Helm in a Kubernetes environment. Helm, a package manager for Kubernetes, simplifies the process of managing Kubernetes applications.

Note

For detailed Helm installation instructions, refer to Installing Helm. Helm Charts package all the resource definitions necessary to deploy an application in Kubernetes.

Deploying MySQL with Helm

Helm streamlines the deployment of applications in Kubernetes, and here’s how you can use it to deploy MySQL:

1. Add a Helm Repository

First, add the Bitnami Helm repository which contains the MySQL chart:

helm repo add bitnami https://charts.bitnami.com/bitnami

2. Update the Repository

Ensure you have the latest charts by updating the repository:

helm repo update

3. Install MySQL Chart

Replace $MYSQL_ROOT_PASSWORD with your desired root password.

kubectl create ns my-database

export MYSQL_ROOT_PASSWORD=strong-password

To install the MySQL chart with a custom password:

helm install --set mysqlRootPassword=$MYSQL_ROOT_PASSWORD --set volumePermissions.enabled=true -n my-database my-mysql bitnami/mysql

The volumePermissions.enabled=true setting helps avoid potential permission issues with persistent volumes.

Tip

Use helm search repo [repository-name] to find available charts in a repository.

4. Intentionally Update to an Incompatible MySQL Image Tag

To simulate a real-world problem where an update might cause issues, let's intentionally update to an incompatible MySQL image tag:

helm upgrade my-mysql bitnami/mysql -n my-database --set image.tag=nonexistent

Info

The purpose of this command is to simulate a problematic update, allowing us to demonstrate the rollback process. This update intentionally uses a non-existent tag, which will cause the update to fail, resembling a common real-world issue.

5. Viewing Helm Release History

To view the history of the MySQL release:

helm history my-mysql -n my-database

6. Listing Installed Helm Charts

List all installed Helm charts in a specific namespace:

helm list -n my-database

7. Rolling Back a Helm Release

To rollback to the first version of the MySQL release:

helm rollback my-mysql 1 -n my-database

Caution

Rollbacks cannot be undone. Be sure of the revision number.

8. Uninstalling the MySQL Release

To remove the MySQL release:

helm uninstall my-mysql -n my-database

Conclusion

Using Helm to deploy and manage applications like MySQL in Kubernetes simplifies the process considerably. Following these steps, including addressing common deployment challenges like permission issues, will allow you to effectively manage MySQL in your Kubernetes clusters.