DEV Community: Praduman

Kubernetes (part-8)

Praduman — Tue, 24 Sep 2024 09:17:13 +0000

Understanding Kubernetes Services: A Comprehensive Guide

A Kubernetes Service is an object that helps you expose an application running in one or more Pods in your cluster. Since pod IP addresses can change when pods are created or destroyed, a service provides a stable IP that doesn't change. This ensures that both internal and external users can always connect to the right application, even if the pods behind it are constantly changing. By default the service that is created is clusterIP, it is useful for communication within the cluster.

To create a service (default: ClusterIP)

kubectl expose <deployment/pod-name> --port=80

To see the services
```
kubectl get svc -owide
```

What Are Endpoints in Kubernetes?

Endpoints are objects that list the IP addresses and ports of the pods associated with a specific service. When you create a service in Kubernetes, it uses a selector to determine which pods it should communicate with. The Endpoints object automatically updates as pods are added or removed, ensuring that the service always knows where to send traffic. It play a crucial role in connecting services to the pods they manage.

Viewing Endpoints
kubectl get endpoints <service-name>

Exploring Different Types of Kubernetes Services

ClusterIP
NodePort
LoadBalancer
ExternalName
Headless
ExternalDNS

Networking Fundamentals in Kubernetes: A Deep Dive

Inside each node, there's always a veth(Virtual Ethernet) pair for networking. When a pod runs, a special container called the pause container is also created. For example, if you create a pod with two containers, like busybox and nginx, there will actually be three containers: the two you defined and the pause container. The pod gets its own IP, and this IP is connected to an interface called eth0(Ethernet interface) inside the pod using CNI.

Create a multi-container pod (mcp.yml)

apiVersion: v1
kind: Pod
metadata:
  name: shared-namespace
spec:
  containers:
    - name: p1
      image: busybox
      command: ['/bin/sh', '-c', 'sleep 10000']
    - name: p2
      image: nginx

```bash
kubectl apply -f mcp.yml
```

<p align="center">

To see the pod’s IP

kubectl get pod shared-namespace -owide

Check the node where the pod is running and SSH into it
```
ssh node01
```
To view the network namespaces created
```
ip netns list
```
To find the pause container
```
lsns | grep nginx
```
Get details of the pause container's namespaces (net, ipc, uts)
```
lsns -p <PID-from-the-previous-command>
```
To check the list of all network namespaces
```
ls -lt /var/run/netns
```

Exec into the namespace or into the pod to see the ip link

ip netns exec <namespace> ip link
kubectl exec -it <pod-name> -- ip addr

Find the veth Pair
- Once you run the above command, you may see an interface with a name like eth@9. The number after @ represents the identifier of the virtual Ethernet (veth) pair interface.
- To find the corresponding link on the Kubernetes node, you can search using this identifier. For example, if the number is 9, run the following on the node
```
ip link | grep -A1 ^9
```
- This will show the details of the veth pair on the node
Inter Node communication

Here, Traffic(packet) goes to eth0 and then veth1 acts as tunnel and traffic goes to root namespace and bridge resolve the destination address using the ARP table then Veth1 send traffic(packet) to pod B. This all only happens if there is a single node

StatefulSet: Managing Stateful Applications in Kubernetes

It helps manage stateful applications where each pod needs a unique identity and keeps its own data. It makes sure pods are started, updated, and stopped one by one, in a set order. Each pod has a fixed name and can keep its data even if it is restarted or moved to another machine. This is useful for apps like databases, where data and order matter.

Key Differences Between Deployments and StatefulSets

Feature	Deployment	StatefulSet
Use Case	For stateless applications	For stateful applications
Pod Identity	Pods are interchangeable and do not have stable identities	Pods have unique, stable identities (e.g., `pod-0`, `pod-1`)
Storage	Typically uses ephemeral storage, data is lost when a pod is deleted	Each pod can have its own persistent volume attached
Scaling Behavior	Pods are scaled simultaneously and in random order	Pods are scaled sequentially (e.g., `pod-0` before `pod-1`)
Pod Updates	All pods can be updated concurrently	Pods are updated sequentially, ensuring one pod is ready before moving to the next
Order of Pod Creation/Deletion	No specific order in pod creation or deletion	Pods are created/deleted in a specific order (e.g., `pod-0`, `pod-1`)
Network Identity	Uses a ClusterIP service, no stable network identity	Typically uses a headless service, giving each pod a stable network identity
Examples	Microservices, stateless web apps	Databases (MySQL, Cassandra), distributed systems requiring unique identity or stable storage
Use of Persistent Volumes	Persistent volumes are shared across pods (if needed)	Each pod gets a dedicated persistent volume

The Service that is created in StatefulSet is the ClusterIP: none i.e., (headless service)

StatefulSet example for deploying a MySQL database in Kubernetes

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql-service"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-storage
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: mysql-storage
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 1Gi

Each pod will have its own persistent storage (mysql-storage).
Pods will have stable network names (mysql-0, mysql-1, etc.), and their data will persist even if they restart.

Create a StatefulSet

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: postgres
spec:
serviceName: "postgres"
replicas: 3
selector:
matchLabels:
app: postgres
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:13
ports:
- containerPort: 5432
name: postgres
env:
- name: POSTGRES_PASSWORD
value: "example"
volumeMounts:
- name: postgres-storage
mountPath: /var/lib/postgresql/data
volumeClaimTemplates:
- metadata:
name: postgres-storage
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
EOF

A persistent volume and persistent volume claim is also created
```
kubectl get pv
```
```
kubectl get pvc
```
Check for pods that is created

Create a service (svc.yml)

apiVersion: v1
kind: Service
metadata:
  name: postgres
  labels:
    app: postgres
spec:
  ports:
  - port: 5432
    name: postgres
  clusterIP: None
  selector:
    app: postgres

Increase the replicas and you will see the each pod have a ordered and fixed name
```
kubectl scale statefulset postgres --replicas=6
```

```bash
kubectl get pod
```

<p align="center">

If you delete a pod a new pod with the same name again created
```
kubectl delete pod postgres-3
```

Check if the service is working or not

kubectl exec -it postgres-0 -- psql -U postgres

NodePort: Exposing Your Kubernetes Application

A NodePort is a way to let people from outside the cluster access your app. It opens a specific port on every node in the cluster, allowing you to reach the app using the node's IP and the assigned port. This port is a number in the range 30000–32767. You can access your application by visiting <NodeIP>:<NodePort>, where NodeIP is the IP address of any node in the cluster, and NodePort is the port assigned by Kubernetes.

Where it's useful ?

For testing and development: You can quickly share access to apps without need of extra networking setup.
For small or internal projects: If a company doesn't use cloud-based load balancers or advanced setups, NodePort is a simple solution to expose an app.

YAML configuration for a NodePort service that exposes an nginx deployment or pod

apiVersion: v1
kind: Service
metadata:
  name: nginx-nodeport
  labels:
    app: nginx
spec:
  type: NodePort  # Specify the service type as NodePort
  selector:
    app: nginx  # This must match the labels of the nginx pods
  ports:
    - protocol: TCP
      port: 80  # The port the service will listen on
      targetPort: 80  # The port the nginx container is listening on
      nodePort: 30008  # NodePort exposed (optional, Kubernetes can assign one if omitted)

Create a Pod and expose it using NodePort service

kubectl run nginx --image=nginx
kubectl expose pod nginx --type=NodePort --port 80

Access the Server http://192.168.1.4:32613

Check NodePort and KUBE Rules

to check the rules in the iptables firewall configuration related to Kubernetes NodePort services
```
sudo iptables -t nat -L -n -v | grep -e NodePort -e KUBE
```
Check Specific NodePort Rules
```
sudo iptables -t nat -L -n -v | grep 32613
```
This indicates that traffic coming to port 32613 (your NodePort) is being redirected properly to the appropriate service.

LoadBalancer: Making Your Application Public

It allows your application to be accessible to the public over the internet. When you create a service of this type, Kubernetes asks your cloud provider (like AWS, GCP, or Azure) to set up a load balancer automatically.

This service type is ideal when you want to expose an application, such as a web server, to users outside your cluster. The cloud provider provides an external IP address, which users can use to access your application.

The load balancer automatically distributes incoming traffic to all the pods running the service. This helps spread the traffic evenly and avoid overloading any single pod.

LoadBalancer YAML file
apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer
spec:
  type: LoadBalancer  # This makes it a LoadBalancer service
  selector:
    app: nginx  # This selects the nginx pods
  ports:
    - protocol: TCP
      port: 80         # Exposes port 80 (HTTP) to the public
      targetPort: 80   # The port on the nginx container
How It Works:

You create the LoadBalancer service.

Kubernetes communicates with the cloud provider, and a load balancer is created.

The load balancer assigns an external IP address.

Traffic from the external IP is sent to your service, which distributes it to the nginx pods.

Creating a LoadBalancer service in minikube

kubectl run nginx --image=nginx
kubectl expose pod nginx --type=LoadBalancer --port=80

Creates a network tunnel, making your LoadBalancer service accessible
```
minikube tunnel
```
Access the Service at External-ip

Why Avoid LoadBalancer in Production?

Cost: LoadBalancers can be expensive, as cloud providers charge for them.
Scalability Problems: They might struggle with sudden increases in traffic.
Single Point of Failure: If the LoadBalancer fails, all services using it can go down.
Limited Flexibility: They have fixed rules, making it hard to manage complex traffic needs.
Performance Delays: They can add extra time (latency) to how quickly users access your services.
Dependence on Cloud Services: If the cloud provider has issues, your services might become unavailable.
Complex Setup: Managing LoadBalancers can complicate your system, especially with multiple clusters.

Alternatives to LoadBalancer for Kubernetes

Ingress Controllers: These are cheaper and allow more flexible traffic management.
Service Mesh: They help manage traffic and improve observability without needing a LoadBalancer.

ExternalName: Mapping Services to External DNS Names

The ExternalName service type is a special kind of service in Kubernetes that allows you to map a service to an external DNS name. Instead of using a cluster IP, it returns a CNAME record with the specified external name. We use it when we need to communicate to an external service (like external API or database) without changing your application code. Using this we can also communicate with services that is present in other namespaces.

Example: Two services within two other namespaces communicate with each other

Use This file to get the Sourcecode

Create two namespace

kubectl create ns database-ns
kubectl create ns application-ns

Create the database pod and service

kubectl apply -f db.yaml
kubectl apply -f db_svc.yaml

Create ExternalName service
```
kubectl apply -f externam-db_svc.yaml
```

Create Application to access the service Docker build

docker build --no-cache --platform=linux/amd64 -t ttl.sh/saiyamdemo:1h .

Create the pod
```
kubectl apply -f apppod.yaml
```
Check the pod logs to see if the connection was successful
```
kubectl logs my-application -n application-ns
```

Ingress: Controlling User Access to Kubernetes Applications

It is a way to control how users access your applications running in Kubernetes. Think of it as a gatekeeper that directs traffic to the right place. To use ingress we firstly need to deploy an Ingress Controller on the cluster and the Ingress are implemented through Ingress Controller. Ingress controllers are the open source project of many companies such as NGINX, Traefik, Istio Ingress, etc.

Now, we create a service using ClusterIP and a resource using Ingress. User request firstly goes to ingress controller then ingress controller send it to ingress then after it goes to the clusterIP service configured by us and at last it goes to the pod. Here we deploy Ingress Controller as the LoadBalancer.

Why Use Ingress?

Single Address: Instead of having different addresses for each app, you can use one address for everything.
Routing by URL: You can send users to different apps based on the URL they visit. For example, /app1 goes to one app and /app2 goes to another.
Secure Connections: Ingress can handle secure connections (HTTPS) easily, so your apps are safe to use.
Balancing Traffic: It spreads out incoming traffic evenly, so no single app gets overloaded.

Example

Imagine you have two apps:

A website
An API

You can set up Ingress to route traffic like this:

If someone goes to /, they get the website.
If they go to /api, they get the API.

Here’s how you might set it up:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: "my-app.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: website-service
            port:
              number: 80
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

Create a deployment (deploy.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
   name: nginx-deployment
spec:
   replicas: 1
   selector:
   matchLabels:
      app: nginx
   template:
      metadata:
         labels:
           app: nginx
      spec:
         containers:
         - name: nginx
           image: nginx:latest
           ports:
           - containerPort: 80
           volumeMounts:
           - name: config-volume
             mountPath: /etc/nginx/nginx.conf
             subPath: nginx.conf  # Ensure this matches the filename in the ConfigMap
           volumes:   
           - name: config-volume
             configMap:
             name: nginx-config

```yaml
kubectl apply -f deploy.yaml
```

Create a clusterIP service (svc.yaml)

apiVersion: v1
kind: Service
metadata:
   name: nginx-service
spec:
   selector:
      app: nginx
    ports:
    - protocol: TCP
      port: 80
      targetPort: 80

```bash
kubectl apply -f svc.yaml
```

verify the service is created
```
kubectl get svc
```

Create a nginx.conf file

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;

events {
worker_connections  1024;
}

http {
include       /etc/nginx/mime.types;
default_type  application/octet-stream;

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

access_log  /var/log/nginx/access.log  main;

sendfile        on;
#tcp_nopush     on;

keepalive_timeout  65;

#gzip  on;

server {
listen       80;
server_name  localhost;

location / {
root   /usr/share/nginx/html;
index  index.html index.htm;
}

location /public {
return 200 'Access to public granted!';
}

error_page   500 502 503 504  /50x.html;
location = /50x.html {
root   /usr/share/nginx/html;
}
}
}

Create a ConfigMap

kubectl create configmap nginx-config --from-file=nginx.conf

Access the server
```
curl <cluster-IP>
```

Now we need to access this application from outside the cluster without using NodePort and LoadBalancer service

Install Ingress controller first

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.9.4/deploy/static/provider/cloud/deploy.yaml

Create a Ingress object (ingress.yaml)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: bootcamp
spec:
  ingressClassName: nginx
  rules:
  - host: "kubernetes.hindi.bootcamp"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80
      - path: /public 
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

ssh onto the node where the pod is deployed and the change the /etc/hosts file

# add this in file
<node-internal-IP> <nodeName>
<node-internal-IP> kubernets.hindi.bootcamp

Now apply the create ingress.yaml file
```
kubectl apply -f ingress.yaml
```
We need to connect user to the ingress controller
```
curl kubernetes.hindi.bootcamp:30418
```

ExternalDNS: Connecting Kubernetes to DNS Providers

It connects your Kubernetes cluster to a DNS provider (like AWS Route53, Google Cloud DNS, or Cloudflare) and updates DNS records when you deploy new services or ingresses. This makes your apps available under a specific domain name.

How it works:

Watch Kubernetes Resources: ExternalDNS continuously monitors Kubernetes resources (like Service, Ingress, or Endpoint resources) for changes.
Determine Desired DNS Records: Based on the services or ingress objects, it calculates the required DNS records.
Update DNS Provider: It then communicates with a DNS provider (like AWS Route53, Google Cloud DNS, or Cloudflare) to create, update, or delete DNS records as needed.

Use Cases

Automatically manage DNS entries for services or applications exposed via Kubernetes Ingress or LoadBalancer services.
Keep DNS records up-to-date when service IPs or endpoints change.
Use annotations to control which resources should have DNS records managed by ExternalDNS.

Conclusion

In this article, we explored various aspects of Kubernetes, including services, networking fundamentals, StatefulSets, and different types of services like NodePort, LoadBalancer, ExternalName, Ingress, and ExternalDNS. We delved into the specifics of how each service type functions, their use cases, and provided practical examples to illustrate their implementation. Understanding these components is crucial for effectively managing and deploying applications in a Kubernetes environment. By mastering these concepts, you can ensure your applications are scalable, resilient, and efficiently managed within your Kubernetes clusters.

Kubernetes (part-7)

Praduman — Mon, 23 Sep 2024 19:15:58 +0000

Understanding ConfigMap: Simplify Your Kubernetes Configuration Management

It is used to store non-confidential configuration data in key-value pairs. It keep configuration separate from the application code, that makes it easier to manage and update without redeploying the entire application

Example 1: Passing Database User to MySQL Pod Using ConfigMap

Create the ConfigMap (cm1.yaml): The ConfigMap will contain the database user and password

# cm1.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: bootcamp-configmap
data:
  username: "saiyam"
  database_name: "exampledb"

```basic
kubectl apply -f cm1.yaml
```

Create the Pod (pod1.yaml): The Pod will run a MySQL container and use the environment variables from the ConfigMap

# pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mysql-pod
spec:
  containers:
  - name: mysql
    image: mysql:5.7
    env:
      - name: MYSQL_USER
        valueFrom:
          configMapKeyRef:
            name: bootcamp-configmap
            key: username
      - name: MYSQL_DATABASE
        valueFrom:
          configMapKeyRef:
            name: bootcamp-configmap
            key: database_name
      - name: MYSQL_PASSWORD
        value: demo123  # Specify a strong password.
      - name: MYSQL_ROOT_PASSWORD
        value: demo345 # You should change this value.
    ports:
      - containerPort: 3306
        name: mysql
    volumeMounts:
      - name: mysql-storage
        mountPath: /var/lib/mysql
  volumes:
    - name: mysql-storage
      emptyDir: {}

```basic
 kubectl apply -f pod1.yaml
```

Access the MySQL Pod: Once the Pod is running, connect to the MySQL container and verify the user setup
```
kubectl exec -it mysql-pod -- mysql -u root -p
```
If asks for password , Use that defined in the ConfigMap
Run MySQL Commands: Inside the MySQL prompt, run the following commands to verify the users and databases:
```
SELECT user FROM mysql.user;
SHOW DATABASES;
```

Example 2: Managing Dev/Prod Properties with ConfigMap

Create the ConfigMap (cm2.yaml)

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-dev
data:
  settings.properties: |
    # Development Configuration
    debug=true
    database_url=http://dev-db.example.com
    featureX_enabled=false

---

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-prod
data:
  settings.properties: |
    # Production Configuration
    debug=false
    database_url=http://prod-db.example.com
    featureX_enabled=true

```basic
kubectl apply -f cm2.yaml
```

Create the Pod (pod2.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-web-app
  template:
    metadata:
      labels:
        app: my-web-app
    spec:
      containers:
      - name: web-app-container
        image: nginx  
        ports:
        - containerPort: 80
        env:
        - name: ENVIRONMENT
          value: "development"  
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      volumes:
      - name: config-volume
        configMap:
          name: app-config-dev

```yaml
kubectl apply -f pod2.yaml
```

Verify the ConfigMap is Mounted: After the Pod is running, you can check if the settings.properties file has been correctly mounted and read its contents
```
kubectl exec -it app-pod -- cat /etc/config/settings.properties
```
This should display the content of the settings.properties file:
```
# Development Configuration
debug=true
database_url=http://dev-db.example.com
featureX_enabled=false
```
Switch to Production: To use the production configuration instead, update the Deployment to mount app-config-prod.

Change this part in pod2.yaml:
```
configMap:
  name: app-config-prod
```
Reapply the deployment
```
kubectl apply -f pod2.yaml
```
Now, if you check the configuration inside the pod, you’ll see the production settings:
```
# Production Configuration
debug=false
database_url=http://prod-db.example.com
featureX_enabled=true
```

Example 3: Accessing ConfigMap Programmatically with Python

read_config.py: This Python script reads and prints the contents of the app-config ConfigMap in the default namespace

from kubernetes import client, config

def main():
    # Load the Kubernetes configuration
    config.load_incluster_config()

    v1 = client.CoreV1Api()
    config_map_name = 'app-config'
    namespace = 'default'

    try:
        # Read the ConfigMap
        config_map = v1.read_namespaced_config_map(config_map_name, namespace)
        print("ConfigMap data:")
        for key, value in config_map.data.items():
            print(f"{key}: {value}")
    except client.exceptions.ApiException as e:
        print(f"Exception when calling CoreV1Api->read_namespaced_config_map: {e}")

if __name__ == '__main__':
    main()

Dockerfile: This Dockerfile builds the image that runs the Python script.

# Use a lightweight Python image
FROM python:3.8-slim

# Install the Kubernetes Python client
RUN pip install kubernetes

# Copy the Python script
COPY read_config.py /read_config.py

# Set the command to run the script
CMD ["python", "/read_config.py"]

Build the Docker Image: Build the Docker image using the provided Dockerfile and push it to a public image registry (in this case, ttl.sh)
```
docker build -t ttl.sh/hindi-boot:1h .
docker push ttl.sh/hindi-boot:1h
```

app.yaml: This YAML file defines all the Kubernetes resources: the ConfigMap, Deployment, Role, and RoleBinding.

# ConfigMap storing some example properties
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: default
data:
  example.property: "Hello, world!"
  another.property: "Just another example."
---
# Deployment to run the Python script in a pod
apiVersion: apps/v1
kind: Deployment
metadata:
  name: config-reader-deployment
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: config-reader
  template:
    metadata:
      labels:
        app: config-reader
    spec:
      containers:
      - name: config-reader
        image: ttl.sh/hindi-boot:1h
        imagePullPolicy: Always
---
# Role granting read access to ConfigMaps in the default namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: config-reader
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch"]
---
# RoleBinding to attach the Role to the default ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-configmaps
  namespace: default
subjects:
- kind: ServiceAccount
  name: default 
  namespace: default
roleRef:
  kind: Role
  name: config-reader
  apiGroup: rbac.authorization.k8s.io

Apply the Kubernetes Resources: Deploy the ConfigMap, Deployment, and RBAC resources to Kubernetes.
```
kubectl apply -f app.yaml
```
Check the Logs: After the pod is running, you can check the logs to see if the ConfigMap has been read successfully.
```
kubectl logs -l app=config-reader
```
The output should display the content of the ConfigMap
```
ConfigMap data:
example.property: Hello, world!
another.property: Just another example.
```

Secrets in Kubernetes: Securely Manage Sensitive Information

When deploying applications in Kubernetes, you often need to handle sensitive information such as passwords, API keys, or tokens. Storing these directly in your code or configuration files can be insecure. Kubernetes Secrets provide a way to securely store and manage sensitive information.

Unlike ConfigMaps (which store non-sensitive configuration data), Secrets are designed for security. They store data in an encoded format (Base64) and can be mounted into Pods or accessed as environment variables.

Types of Kubernetes Secrets: Opaque, TLS, and Docker Registry

Opaque Secret: General-purpose secret, commonly used for storing credentials.
TLS Secret: Specifically for storing SSL/TLS certificates.
Docker Registry Secret: For storing Docker registry credentials, used for pulling private images.

Example 1: Creating a Kubernetes Secret Using YAML

Encode your values in Base64

bash echo -n 'my-db-username' | base64 echo -n 'my-db-password' | base64
This will return
bash bXktZGItdXNlcm5hbWU= bXktZGItcGFzc3dvcmQ=

Create the Secret YAML file (secret.yaml)

yaml apiVersion: v1 kind: Secret metadata: name: db-secret type: opaque data: username: bXktZGItdXNlcm5hbWU= password: bXktZGItcGFzc3dvcmQ=
Apply the secret
bash kubectl apply -f secret.yaml

To view the secret

bash kubectl get secret

To decrypt the encrypted data

bash echo "put-encrypted-data" | base64 -d

Example 2: Creating a Kubernetes Secret from the Command Line

kubectl create secret generic db-secret \
  --from-literal=username=my-db-username \
  --from-literal=password=my-db-password

Using Secrets in a Pod: Environment Variables and Volume Mounts

Once the Secret is created, you can use it in a Pod as either environment variables or mounted as files

Example: Using a Secret as Environment Variables

apiVersion: v1
kind: Pod
metadata:
  name: db-app
spec:
  containers:
  - name: app-container
    image: my-app:latest
    env:
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: username
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password

Here, the username and password from the Secret are injected into the container as environment variables

Example: Mounting a Secret as a Volume

apiVersion: v1
kind: Pod
metadata:
  name: app-with-secret
spec:
  containers:
  - name: app-container
    image: my-app:latest
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secrets
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: db-secret

This will mount the Secret’s data into /etc/secrets/ inside the container

Storing SSH Private Keys in Kubernetes Secrets

kubectl create secret generic my-ssh-key-secret \
--from-file=ssh-privatekey=/path/to/.ssh/id_rsa \
--type=kubernetes.io/ssh-auth

--from-file=ssh-privatekey=/path/to/.ssh/id_rsa:

--from-file: Specifies that the content for the Secret should come from a file.

ssh-privatekey: The key under which the private key will be stored in the Secret.

/path/to/.ssh/id_rsa: Path to the actual SSH private key file (usually located in ~/.ssh/id_rsa).

--type=kubernetes.io/ssh-auth:

This specifies that the Secret is of type kubernetes.io/ssh-auth, which is used for SSH authentication.

Managing SSL/TLS Certificates with Kubernetes TLS Secrets

kubectl create secret tls my-tls-secret \
--cert=path/to/cert/file \
--key=path/to/key/file

--cert=path/to/cert/file:

This specifies the path to the TLS certificate file. Replace path/to/cert/file with the actual path to your .crt (certificate) file.

--key=path/to/key/file:

This specifies the path to the TLS private key file. Replace path/to/key/file with the actual path to your private key file (typically .key).

MySQL Example: Combining ConfigMap and Secrets in Kubernetes

create a configmap (myconfig.yaml)

apiVersion: v1
kind: configMap
metadata:
   name: bootcamp-configMap
data: 
   username: "praduman"
   database_name: "my-db"

```bash
kubectl apply -f myconfig.yaml
```

create secrets (mysecret.yaml)

echo -n 'rootPass' | base64
echo -n 'userPass' | base64

```yaml
apiVersion: v1
kind: Secret
metadata: 
   name: mysql-root-pass
type: Opaque
data: 
   password: <use-base64-encoded>
---
apiVersion: v1
kind: Secret
metadata: 
   name: mysql-user-pass
type: Opaque
data: 
   password: <use-base64-encoded>
```

```bash
kubectl apply -f mysecret.yaml
```

YAML file of deployment using both configMap and Secret(deploy.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        env:
          - name: MYSQL_ROOT_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mysql-root-pass
                key: password
          - name: MYSQL_USER
            valueFrom:
              configMapKeyRef:
                name: bootcamp-configmap
                key: username
          - name: MYSQL_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mysql-user-pass
                key: password
          - name: MYSQL_DATABASE
            valueFrom:
              configMapKeyRef:
                name: bootcamp-configmap
                key: database_name
        ports:
          - containerPort: 3306
        volumeMounts:
          - name: mysql-storage
            mountPath: /var/lib/mysql
      volumes:
        - name: mysql-storage
          emptyDir: {}

```bash
kubectl apply -f deploy.yaml
```

Access the MYSQL pod

kubectl exec -it <pod-name> -- mysql -u root -p

Conclusion

In this article, we explored the essential concepts of Kubernetes ConfigMaps and Secrets, highlighting their importance in managing configuration data and sensitive information securely. ConfigMaps allow you to decouple configuration from application code, making updates seamless without redeploying the entire application. Secrets, on the other hand, provide a secure way to handle sensitive data like passwords and API keys, ensuring they are not exposed in your codebase.

We provided practical examples demonstrating how to use ConfigMaps and Secrets in various scenarios, such as passing database credentials to a MySQL Pod, managing environment-specific properties, and accessing configuration programmatically with Python. Additionally, we covered the different types of Secrets, including Opaque, TLS, and Docker Registry Secrets, and how to use them in Pods as environment variables or volume mounts.

By understanding and implementing these Kubernetes features, you can enhance the security and manageability of your applications, ensuring a more robust and flexible deployment process.

Kubernetes (part-6)

Praduman — Sun, 22 Sep 2024 21:23:20 +0000

Ensuring Application Availability with ReplicaSets

It helps keep your application running by ensuring the correct number of pod replicas are always available, making it essential for scaling and reliability. ReplicaSets are often managed by Deployments, which provide more features like rolling updates. When you create a Deployment, it automatically creates a ReplicaSet for managing pod replicas.

Example:

If you set a ReplicaSet to have 3 pods, and one pod stops, the ReplicaSet will automatically create a new pod so that there are always 3 running.

Defining a ReplicaSet: YAML Example

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

This YAML file tells Kubernetes to create 3 identical pods running the nginx web server. It will automatically make sure there are always 3 pods running, so if one stops, Kubernetes will start another. Each pod runs on port 80, and all are labeled with app: nginx for identification.

Real-Time watch and monitor the status of your pods
```
kubectl get pod -w
```
To see the ReplicaSet present
```
kubectl get rs
```
To delete a replicaSet and all its pod
```
kubectl delete rs <rs-file>
```

Understanding Propagation Policies in Kubernetes

It is used to control how resources are deleted, especially when dealing with related resources like ReplicaSets and their pods. It decides whether the resources created by a ReplicaSet (like pods) should be deleted right away or left running when the ReplicaSet is removed.

Types of Propagation Policies:

Foreground: Pods are deleted first, then the ReplicaSet.
```
kubectl delete replicaset nginx-rs --cascade=foreground
```
Another way: using kubectl proxy with a curl command to delete a ReplicaSet using the Kubernetes API and specify a propagationPolicy
- Start the Kubernetes Proxy
```
kubectl proxy --port=8080
```
This command starts a local proxy that allows you to interact with the Kubernetes API at localhost:8080 without needing to authenticate with tokens.
```
kubectl proxy --port=8080
curl -X DELETE 'http://localhost:8080/apis/apps/v1/namespaces/default/replicasets/nginx-rs' \
     -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
     -H "Content-Type: application/json"
```

Background: ReplicaSet is deleted first, pods are deleted later.
```
kubectl delete replicaset nginx-rs --cascade=background
```
Another way: using kubectl proxy with a curl command to delete a ReplicaSet using the Kubernetes API and specify a propagationPolicy
- Start the Kubernetes Proxy
```
kubectl proxy --port=8080
```
This command starts a local proxy that allows you to interact with the Kubernetes API at localhost:8080 without needing to authenticate with tokens.
```
curl -X DELETE 'http://localhost:8080/apis/apps/v1/namespaces/default/replicasets/nginx-rs' \
     -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
     -H "Content-Type: application/json"
```

Orphan: ReplicaSet is deleted, but the pods remain running.
```
kubectl delete replicaset nginx-rs --cascade=orphan
```
Another way: using kubectl proxy with a curl command to delete a ReplicaSet using the Kubernetes API and specify a propagationPolicy
- Start the Kubernetes Proxy
```
kubectl proxy --port=8080
```
This command starts a local proxy that allows you to interact with the Kubernetes API at localhost:8080 without needing to authenticate with tokens.
```
curl -X DELETE 'http://localhost:8080/apis/apps/v1/namespaces/default/replicasets/nginx-rs' \
     -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
     -H "Content-Type: application/json"
```

Mastering Kubernetes Deployments

It is used to manage and automate the lifecycle of applications running in pods. It provides more advanced features than a ReplicaSet, such as rolling updates, rollback capabilities, and scaling.

Creating and Managing Deployments with YAML

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.16.1
        ports:
        - containerPort: 80

```basic
kubectl apply -f deployment.yaml
```

Get Deployment Status
```
kubectl get deployments
```

Scaling Deployments for Optimal Performance

kubectl scale deployment nginx-deployment --replicas=5

Updating Deployment Images

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

Checking Deployment Status

kubectl rollout status deployment/nginx-deployment

Checking Rollout History

kubectl rollout history deploy/nginx-deployment

View Specific Revision

kubectl rollout history deploy/nginx-deployment --revision=2

Rolling Back to Previous Deployment Revisions

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

Pause a Rollout

kubectl rollout pause deployment/nginx-deployment

Edit Deployment Directly

kubectl edit deployment/nginx-deployment

Recreate Strategy: Minimizing Downtime During Updates

With this strategy, when a new version of an application is deployed, Kubernetes first deletes all existing pods before creating the new ones. This can cause some downtime because there will be a gap between the old pods being terminated and the new ones starting.

Example YAML for Recreate Strategy

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

kubectl apply -f <recreate-yml-file>

kubectl set image deploy/demo-deployment demo=nginx:14.0

Probes: Ensuring Pod Health and Readiness

This is used to check the health of pod. They help Kubernetes know when a pod is ready to start serving traffic or if it’s still alive and functioning correctly. If a probe fails, Kubernetes can take action like restarting the pod

Types of probes in Kubernetes

Liveness Probe: Checks if the pod is alive. Restarts it if it’s stuck.
Readiness Probe: Checks if the pod is ready to serve traffic. Stops sending traffic if it’s not ready.
Startup Probe: Gives the pod time to fully start. Ensures it isn’t marked as failed too early.

Implementing Probes in Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 15
          timeoutSeconds: 2
          periodSeconds: 5
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          timeoutSeconds: 2
          periodSeconds: 5
          successThreshold: 1
          failureThreshold: 3
        startupProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 5
          failureThreshold: 10

kubectl apply -f <yaml-file>

Liveness Probe: Checks if the container is still running. If it fails 3 times (every 5 seconds), the container is restarted.
Readiness Probe: Checks if the container is ready to serve traffic. If it fails 3 times, the container won’t receive traffic until it passes.
Startup Probe: Gives the container 10 chances (every 5 seconds) to start before other probes begin checking it.

Blue-Green Deployment: Minimizing Downtime and Risk

A strategy for deploying applications that minimizes downtime and risk.
It involves running two environments: Blue and Green
Blue represents the current version of the application that's live and handling user traffic.
Green is a new version of the application that is being prepared for release.

Example: You have an application running with version 1 (Blue) and want to deploy version 2 (Green)

Current Deployment (Blue) : This is the live version

yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-blue spec: replicas: 2 selector: matchLabels: app: myapp version: blue template: metadata: labels: app: myapp version: blue spec: containers: - name: myapp image: myapp:1.0 ports: - containerPort: 80

New Deployment (Green): This is the new version

yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-green spec: replicas: 2 selector: matchLabels: app: myapp version: green template: metadata: labels: app: myapp version: green spec: containers: - name: myapp image: myapp:2.0 ports: - containerPort: 80

basic kubectl apply -f myapp-green.yaml

Service: The service will route traffic to the live version (initially Blue). Later, it will be updated to point to the Green version.

yaml apiVersion: v1 kind: Service metadata: name: myapp-service spec: selector: app: myapp version: blue # Initially points to Blue ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer

Switch Traffic to Green: Update the service to point to the Green version

yaml apiVersion: v1 kind: Service metadata: name: myapp-service spec: selector: app: myapp version: green # Now points to Green ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer

basic kubectl apply -f myapp-service.yaml

To rollback to Blue, just update the service selector back to the Blue version

Canary Deployment: Gradual and Safe Application Updates

A strategy where a new version of an application is deployed to a small portion of users (e.g., 10%), while the rest continue using the old version. This allows you to test the new version in production with minimal risk. If it works well, you gradually increase its usage (e.g., 50%, then 100%) and If the canary version causes issues, you can quickly rollback and send all traffic back to the old version.

Example : Let's say you have version 1 of your app running and you want to canary release version 2

Existing Deployment (Version 1)

yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-v1 spec: replicas: 4 selector: matchLabels: app: myapp version: v1 template: metadata: labels: app: myapp version: v1 spec: containers: - name: myapp image: myapp:1.0 ports: - containerPort: 80

Canary Deployment (Version 2)

yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-canary spec: replicas: 1 # Canary version has only 1 replica selector: matchLabels: app: myapp version: canary template: metadata: labels: app: myapp version: canary spec: containers: - name: myapp image: myapp:2.0 ports: - containerPort: 80

basic kubectl apply -f myapp-canary.yaml

Service: The service can be configured to split traffic between the two versions. Initially, it will send most traffic to version 1 (v1) and a small portion to the canary version

yaml apiVersion: v1 kind: Service metadata: name: myapp-service spec: selector: app: myapp version: v1 ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer

Update Service: Modify the service to route a small portion of traffic to the Canary deployment

yaml apiVersion: v1 kind: Service metadata: name: myapp-service spec: selector: app: myapp ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer
> You can use Kubernetes features like weighted routing in an Ingress controller, `to route a portion of traffic to the Canary` or manage it through a service mesh.
Monitor Canary: Check the performance and stability of the Canary version. If there are no issues, you can gradually increase the traffic directed to Canary.

Full Rollout: Once confident in the Canary’s stability, update the service selector to point to the new version and increase the replicas of the Canary deployment while reducing the replicas of the Stable deployment.

Cleanup: Remove the old stable deployment after the Canary version is fully rolled out and stable.

Canary deployments help ensure that new releases are stable and function correctly with minimal risk.

Conclusion

In this article, we explored various aspects of Kubernetes, including ReplicaSets, Deployments, Probes, and deployment strategies like Blue-Green and Canary deployments. Understanding these concepts is crucial for managing and scaling applications efficiently in a Kubernetes environment. By leveraging these tools and strategies, you can ensure high availability, reliability, and seamless updates for your applications, ultimately enhancing your overall DevOps practices.

Kubernetes (part-5)

Praduman — Sun, 22 Sep 2024 21:21:25 +0000

Efficient Kubernetes Scheduling with Kube-Scheduler

The kube-scheduler is Kubernetes default scheduler and part of the control plane. It selects the best node for new or unscheduled pods by filtering out nodes that don't meet the pod's requirements, known as feasible nodes. If no nodes are suitable, the pod remains unscheduled until one becomes available. The scheduler scores feasible nodes and selects the highest-scoring one to run the pod. This decision is then communicated to the API server in a process called binding. Custom schedulers can also be created if needed.

Mastering Labels and Selectors for Resource Grouping

Labels and Selectors are standard methods to group things together. Labels are properties attached to each resources. Selectors help you to filter these resources. Kubernetes uses labels to connect different objects together.

A pod definition file with labels

apiVersion: v1
kind: Pod
metadata:
 name: simple-webapp
 labels:
   app: App1
   function: Front-end
spec:
 containers:
 - name: simple-webapp
   image: nginx
   ports:
   - containerPort: 8080

```basic
kubectl apply -f <pod-definition-file>
```

To select the pod with labels
```
kubectl get pods --selector app=App1
```

To see the lable of a pod

kubectl get pods <pod-name> --show-labels

To label a pod once it is created
```
kubectl label pod <pod-name> key=value
```
To see pods with/without specific label
```
kubectl get pod -l <key>=<value>
```

```basic
kubectl get pod -l <key>!=<value>
```

Imperative way to create deployment

kubectl create deploy bootcamp --image=nginx --replicas 3

Selection of pod using lable in replicasets

 apiVersion: apps/v1
 kind: ReplicaSet
 metadata:
   name: simple-webapp
   labels:
     app: App1
     function: Front-end
 spec:
  replicas: 3
  selector:
    matchLabels:
     app: App1
  template:
    metadata:
      labels:
        app: App1
        function: Front-end
    spec:
      containers:
      - name: simple-webapp
        image: simple-webapp

Selection of pod using lable in services

  apiVersion: v1
  kind: Service
  metadata:
   name: my-service
  spec:
   selector:
     app: App1
   ports:
   - protocol: TCP
     port: 80
     targetPort: 9376

Understanding Kubernetes Namespaces for Resource Isolation

Namespaces are a way to divide cluster resources between multiple users, teams, or projects. They provide a scope for names, allowing multiple users to share the same cluster without interfering with each other.

Kubernetes starts with four initial namespaces:

default: A space where you start working in Kubernetes right away
kube-node-lease: Keeps track of whether each node in the system is healthy or not
kube-public: A place where anyone, even without special access, can see certain information
kube-system: Where Kubernetes itself stores its important stuff

To see all namespaces
```
kubectl get namespace
```
To create a namespace
```
kubectl create ns <name-of-namespace>
```

Avoid creating namespaces with the prefix kube- since it is reserved for Kubernetes system namespaces

Creating two namespace and create deployment on each with nginx image and try to access the deployment on the other ns from the current ns
```
kubectl create ns frontent
```

```basic
kubectl create ns backend
```

```basic
kubectl create deploy demo -n frontent --image=nginx
```

```basic
kubectl create deploy demo -n backend --image=nginx
```

```basic
kubectl get deployment -n frontent -owide
```

To switch to a namespace

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

Managing Resource Quotas in Kubernetes

This is a way to manage and limit resource usage in a specific namespace. It ensures that no single team, application, or user can consume too many resources (like CPU, memory, storage, or the number of objects) in a shared cluster. This Prevent one team or application from using all the resources in the cluster and also Manage resources efficiently.

How Resource Quota Works

Administrators set quotas at the namespace level, and Kubernetes enforces them. When a Pod or object (like a Persistent Volume or Service) is created, Kubernetes checks the quota and ensures that the creation doesn't exceed the defined limits

Create a namespace
```
kubectl create ns example-namespace
```

Create a resourceQuota

apiVersion: v1
kind: ResourceQuota
metadata:
  name: example-quota
  namespace: example-namespace
spec:
  hard:
    requests.cpu: "500m" # total amount of CPU that can be requested
    requests.memory: "200Gi" # total amount of memory that can be requested
    limits.cpu: "1" # total amount of CPU limit across all pods
    limits.memory: 400Gi # total amount of memory limit across all pods
    pods: "10" # total number of pods that can be created

```basic
kubectl apply -f <RQ-name.yaml>
```

To check resouceQuota
```
kubectl get resourceQuota
```

Ensuring Pod Scheduling Readiness

Pod Scheduling Readiness is a feature that lets you control when a Pod is ready to be placed on a node. It adds a delay in scheduling the Pod until certain conditions are met, making sure the Pod is fully prepared. This is helpful when the Pod depends on other services or resources to be available before it can start running smoothly

Example: Waiting for a Service to Be Ready

Pod definition file that includes custom scheduling gates

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  schedulingGates:
  - name: example.com/service-ready
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.6

Implement a Custom Controller

# Pseudo-code for the custom controller
if service_is_ready:
  remove_scheduling_gate(pod_name="test-pod", gate_name="example.com/service-ready")

Use the Custom Controller to Manage Scheduling

The custom controller will ensure that the Pod is only scheduled when the specified service is confirmed to be ready. Until then, the Pod will remain unscheduled.

This approach ensures that the Pod will only be scheduled when the necessary conditions are met, providing a more controlled scheduling process

Enhancing Availability with Pod Topology Spread Constraints

It help to ensure high availability by spreading Pods across different nodes, zones, or regions. It also helps to maintain balanced load by evenly distributing Pods to prevent overloading any single node or domain. It Improve fault tolerance by avoiding concentration in a single location

Example

Kubernetes Deployment using Pod Topology Spread Constraints to evenly distribute Pods across different nodes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 4
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: app-container
        image: nginx
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: demo-app

maxSkew: degree to which the pod is evenly distributed
topologyKey: key of node labels
whenUnsatisfiable: If the constraints cannot be met, DoNotSchedule or ScheduleAnyway
labelSelector: find maching pod

To scale this deployment
kubectl scale deployment demo-app --replicas=6

When you need to prevent new workloads from being scheduled on a node due to issues with that node, you can cordon the node. Cordon marks the node as unschedulable, ensuring that no new pods are scheduled to it.

kubectl cordon <node-name>

To make that node again schedulable you need to uncordon that node

kubectl uncordon <node-name>

Prioritizing Pods with Priority Classes

It helps the Kubernetes Scheduler decide which Pods should be scheduled first when resources are limited. Pods with higher priority values are scheduled before those with lower priority. Higher-priority Pods can displace lower-priority Pods if resources are scarce.

Example of priorityClass

Here’s how you can create a PriorityClass and use it with a Pod

Define a PriorityClass

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: demo-priority
value: 1000000
globalDefault: false
description: "This priority class is for critical workloads."

Use the PriorityClass in a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: high-priority-pod
spec:
  priorityClassName: demo-priority
  containers:
    - name: my-container
      image: my-image

Understanding and Managing Pod Overhead

Pod Overhead is the extra amount of resources a Pod needs beyond what its containers require. It covers things like the Pod's management and networking needs. Pod Overhead helps ensure that enough resources are available for both the Pod and its additional needs, not just the containers inside it

How It Works

Container Requests: You specify how much CPU and memory a container needs
Add Overhead: Kubernetes adds extra resources for the Pod’s management and networking
Total Resources: The total resources needed are the sum of container requests plus Pod Overhead

Example: Specify Pod Overhead in a Pod’s resource request

Define a Pod with Overhead

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
  overhead:
    cpu: "100m"
    memory: "100Mi"

In this example:

Container Requests: The container requests 512 Mi of memory and 500 milliCPU.
Pod Overhead: An additional 100 Mi of memory and 100 milliCPU are reserved for the Pod’s overhead.

Conclusion

In this article, we delved into several advanced Kubernetes concepts, including scheduling, labels and selectors, namespaces, resource quotas, pod scheduling readiness, topology spread constraints, priority classes, and pod overhead. Mastering these features is essential for effectively managing and optimizing Kubernetes clusters. By utilizing these tools and techniques, you can ensure high availability, balanced resource usage, and controlled scheduling processes, ultimately leading to a more robust and resilient Kubernetes environment.

Kubernetes (part-4)

Praduman — Sun, 22 Sep 2024 11:09:31 +0000

Init container can be converted to sidecar container using restartpolicy: always

Example of a Sidecar Container

# This is the identity the Pods will run as.
apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo-kubectl-sidecar
  namespace: default
---
# This defines the namespace-scope permissions granted.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: demo-kubectl-sidecar
  namespace: default
rules:
- apiGroups:
  - ''
  resources:
  - pods
  verbs:
  - get
  - watch
---
# This joins the ServiceAccount to the Role above.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: demo-kubectl-sidecar
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: demo-kubectl-sidecar
subjects:
- kind: ServiceAccount
  name: demo-kubectl-sidecar
---
# This defines the cluster-scope permissions granted.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: demo-kubectl-sidecar
rules:
- apiGroups:
  - ''
  resources:
  - nodes
  verbs:
  - get
  - watch
---
# This joins the ServiceAccount to the ClusterRole above.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: demo-kubectl-sidecar
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: demo-kubectl-sidecar
subjects:
- kind: ServiceAccount
  name: demo-kubectl-sidecar
  namespace: default
---
# This is the actual workload.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-kubectl-sidecar
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-kubectl-sidecar
  template:
    metadata:
      labels:
        app: demo-kubectl-sidecar
    spec:
      serviceAccountName: demo-kubectl-sidecar
      securityContext:
        # Set this to any valid GID, and two things happen:
        #   1) The volume "content" is group-owned by this GID.
        #   2) This GID is added to each container.
        fsGroup: 9376
      containers:
      - name: server
        image: nginx
        volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: content
          readOnly: true
      initContainers:
      - name: sidecar
        image: thockin/kubectl-sidecar:v1.30.0-1
        restartPolicy: Always
        env:
          - name: MYPOD
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: MYNS
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: MYNODE
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
        args:
          - bash
          - -c
          - |
            while true; do
              kubectl -n $MYNS get pod $MYPOD -o json | jq '.status' > /data/this-pod-status.json
              kubectl get node $MYNODE -o json | jq '.status' > /data/this-node-status.json
              sleep 30
            done
        volumeMounts:
        - name: content
          mountPath: /data
        securityContext:
          # This doesn't need to run as root.
          runAsUser: 9376
          runAsGroup: 9376
      volumes:
      - name: content
        emptyDir: {}
      terminationGracePeriodSeconds: 5

kubectl apply -f <yaml-file-name>

kubectl port-forward deployment/demo-kubectl-sidecar 8080:80

curl http://localhost:8080/this-pod-status.json
curl http://localhost:8080/this-node-status.json

Understanding the Role of the Pause Container in Kubernetes

When we try to restart a container then its IP changes. But if a container inside a pod restart then the IP of the pod remains same, this is due to pause container present in kubernetes.

It holds the network namespace and IP address for the Pod, allowing the other containers within the Pod to communicate and share networking resources.

The pause container is automatically created by containerd when you start a Pod. It is not visible to kubectl, but you can see it using the ctr command.

How to View Pause Containers and Pod IPs

To see all pause containers on the node

ctr --namespace k8s.io containers list | grep pause

To check the IP of the specific pod
```
kubectl get pod <pod-name> -owide
```

Kubernetes User Namespaces

User namespaces enhance security by isolating user IDs (UIDs) and group IDs (GIDs) inside containers from the host system. This means that a root user inside a container doesn't have root privileges on the host, reducing the risk if a container is compromised.

This feature helps limit the damage from attacks by keeping container permissions separate from host permissions. User namespaces are now more stable and widely available, supporting both stateless and stateful pods.

Pod Disruptions

Pods do not disappear until someone (a person or a controller) destroys them, or there is an unavoidable hardware or system software error.

Types: *Voluntary and involuntary disruptions*

Voluntary disruption

* Deleting the deployment

* Updating a deployment's pod template

* Directly deleting a pod

* Draining a node

* Removing a pod from a node to allow something else to fit on that node

Non-voluntary disruption

* Hardware failure

* Cluster administrator deletes a VM (instance) by mistake

* Cloud provider or hypervisor failure makes a VM disappear

* Kernel panic

* Node disappears from the cluster due to network partition

* Eviction of a pod due to the node running out of resources

Here are some ways to reduce involuntary disruptions:

Ensure your pod requests the resources it needs.
Replicate your application if you need higher availability.
For even higher availability with replicated applications, spread them across racks (using anti-affinity) or across zones (if using a multi-zone cluster).

Pod disruption budgets (PDB)

It helps to keep your application running smoothly by limiting how many pods can be disrupted at once. They ensure that a minimum number of pods remain available during maintenance or updates. You set up a PDB to specify how many pods need to stay up and running, and Kubernetes follows these rules during planned disruptions but not during unexpected ones like crashes.

We use PDB only for high availability

Here is an example of a PDB configuration:

Create a deployment

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

Create PDB

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: nginx

Check available PDB
```
kubectl get pdb
```

Do rolling updates (update nginx image)

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

Watch the pods now
```
kubectl get pods -w
```

Setting Resource Requests and Limits for Efficient Resource Management

In Kubernetes, applications run as pods inside nodes. A node is a physical or virtual machine with specific configurations like CPU and memory. Each application consumes a certain amount of these resources.

Kubernetes uses the concepts of resource requests and limits to manage CPU and memory usage:

Resource Requests: The minimum amount of CPU and memory that a pod needs to run.
Resource Limits: The maximum amount of CPU and memory a pod is allowed to use.

These settings are crucial for scheduling because they help the scheduler find the best node to deploy a pod. For example, if a pod requires at least 2 CPUs and 1 GB of RAM, you set these values in the resource requests and limits. The scheduler then finds a suitable node that can accommodate these requirements.

When creating a highly available Kubernetes cluster, it's important to properly configure resource requests and limits to ensure efficient resource utilization and stability.

Understanding CPU Throttling in Kubernetes

CPU throttling means limiting a pod's CPU usage when it tries to use more than its allowed amount. This prevents one pod from using too much CPU and affecting other pods on the same node. If a pod reaches its CPU limit, Kubernetes slows it down to stay within the limit, which can make the pod run slower. This helps ensure that resources are shared fairly and the cluster stays stable.

Overutilization and Underutilization of Resources

Overutilization happens when a resource is used too much, exceeding its capacity. For example, if a CPU is consistently running at 100%, it can cause performance issues, slow down processes, or even crash the system because there's not enough capacity left for other tasks.
Underutilization occurs when a resource is used too little, meaning it's not being fully used even though it's available. For instance, if a server has a lot of memory but is only using a small portion of it, the rest of the memory is underutilized, leading to inefficient use of resources and potentially higher costs without any benefit.

we can specify the LimitRange of a namespace

apiVersion: v1
kind: LimitRange
metadata:
  name: example-limitrange
  namespace: default
spec:
  limits:
  - type: Pod
    max:
      cpu: "2"
      memory: "1Gi"
    min:
      cpu: "200m"
      memory: "100Mi"
  - type: Container
    max:
      cpu: "1"
      memory: "500Mi"
    min:
      cpu: "100m"
      memory: "50Mi"
    default:
      cpu: "300m"
      memory: "200Mi"
    defaultRequest:
      cpu: "200m"
      memory: "100Mi"

Now you can directly create pods without specifying limit and ranges it will automatically assigned to the pod

Quality of Service (QoS)

Quality of Service (QoS) in Kubernetes is a way to prioritize and manage resources for Pods to ensure they get the resources they need based on their importance and requirements. Kubernetes classifies Pods into different QoS tiers based on their resource requests and limits.

Pods that have both CPU and memory requests and limits set, and the requests are equal to the limits. These Pods get the highest priority for resources and known as guaranteed QOS.

Guaranteed QoS Example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-guaranteed
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: "500m"

Pods that have CPU and memory requests and limits set, but the requests and limits are not equal. These Pods get some level of resource assurance but can use more resources if available and known as burstable QOS.

Burstable QoS Example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-burstable
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        memory: "256Mi"
      limits:
        memory: "512Mi"

Pods that do not specify any CPU or memory requests or limits. These Pods get the lowest priority for resources and can be easily evicted if the node is under resource pressure and known as besteffort QOS.
BestEffort QoS Example:
```
apiVersion: v1
kind: Pod
metadata:
  name: nginx-besteffort
spec:
  containers:
  - name: nginx
    image: nginx
```
When k8s runs out of resource then on the basis of QOS class, first evict the BestEffort then Burstable and at last Guaranteed evicted

Understanding Kubernetes Downward API

Downward API is a useful feature that allows Pods to access information about themselves and the cluster environment. It helps applications running inside Pods to get metadata and resource details, which they might need to operate correctly or adjust their behavior.

The Downward API provides a way for Pods to obtain information about themselves, such as:

Pod Name: The name assigned to the Pod.
Namespace: The namespace in which the Pod is running.
Pod Labels and Annotations: Metadata attached to the Pod.
Resource Limits and Requests: Information about how much CPU and memory the Pod has been allocated.

How to Use the Downward API

The Downward API provides this information through environment variables or files within the Pod. Here’s a simple example of how to use it:

Using Environment Variables:

You can define environment variables in your Pod spec to expose metadata from the Downward API:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace

In this example:

* The `POD_NAME` environment variable will be set to the Pod's name.

* The `POD_NAMESPACE` environment variable will be set to the Pod's namespace.

Using Volumes:

You can also expose metadata through files in a volume:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    volumeMounts:
    - name: pod-info
      mountPath: /etc/podinfo
  volumes:
  - name: pod-info
    downwardAPI:
      items:
      - path: "name"
        fieldRef:
          fieldPath: metadata.name
      - path: "namespace"
        fieldRef:
          fieldPath: metadata.namespace

In this example:

* The Pod’s name and namespace will be available as files in /etc/podinfo within the container.

Conclusion

In conclusion, this article delves into essential Kubernetes concepts, including the transformation of init containers to sidecar containers, the critical role of the pause container in maintaining network namespaces, and the security benefits of user namespaces. It also covers the different types of pod disruptions and how to manage them using Pod Disruption Budgets (PDB). Additionally, the article explains the importance of setting resource requests and limits for efficient resource utilization and stability, and it categorizes the different Quality of Service (QoS) classes in Kubernetes. Practical examples and YAML configurations are provided to help illustrate these concepts, making it a comprehensive guide for managing Kubernetes environments effectively.

Kubernetes (part-3)

Praduman — Sun, 22 Sep 2024 11:06:13 +0000

Imperative vs. Declarative: Two Approaches to Kubernetes Infrastructure Management

Imperative: Directly command Kubernetes to perform actions step-by-step

To create a pod in imperative way we need to run a single command kubectl run my-pod —image=nginx
Declarative: Define the desired state in a configuration file and let Kubernetes manage it
To create a pod in imperative way we need to write a pod definition file( a yaml file ) first
```
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: my-container
    image: nginx
```
then run command kubectl apply -f filename.yaml

Understanding YAML: The Backbone of Kubernetes Configuration

YAML stands for (YAML Ain't Markup Language)
It is easy & comes with human-readable format
Indentation matters alot
It is used for configuring Kubernetes resources
It allows you to define and organize settings in a structured way
It makes easy to create and manage complex configurations

YAML file to create a pod

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

Command used to apply a YAML configuration :
kubectl apply -f filename.yaml

This command tells Kubernetes to create or update resources based on the specifications defined in the YAML file

Key Concepts in YAML: Objects, Lists, Comments, and Multi-line Strings

Objects: Collections of key-value pairs, similar to dictionaries in Python. They are defined using indentation.

Example:
```
person:
  name: Alice
  age: 30
  city: New York
```
In this example, person is an object with three key-value pairs: name, age, and city.
Lists: Sequences of items, where each item is prefixed by a hyphen (-) and space.

Example:
```
yamlCopy codefruits:
  - Apple
  - Banana
  - Cherry
```
Here, fruits is a list containing three items: Apple, Banana, and Cherry.
Comments: YAML allows comments, start with a #. These are ignored by YAML and are used for adding explanations.

Example:
```
# This is a comment
server:
  host: localhost
  port: 8080
```

Multi-line Strings: YAML provides ways to handle multi-line strings using | (literal block) or > (folded block).

Literal Block (|):

description: |
  This is a multi-line
  string that preserves newlines.

Folded Block (>):

description: >
  This is a multi-line
  string that folds into a single line.

Pods in Kubernetes: The Fundamental Unit of Deployment

Application runs as a pod in kubernetes

Pod is the smallest unit in kubernetes
Inside pod the containers run
It holds one or more containers that works together
No two similar kind of container can run in a single pod
Each Pod gets its own IP address
Containers in the same Pod can communicate with each other using localhost
Pods can have storage that containers in the Pod can use to share files

Example: YAML file to create a Pod

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    ports:
    - containerPort: 80

This file creates a Pod called my-pod with a single container that runs the nginx web server.

Creating same pod in imperative way
kubectl run my-pod --image=nginx --port=80

Command to list all the pods running in the cluster is kubectl get pods
If you want more information about a specific pod the use kubectl describe pod pod-name

Pod Lifecycle: From Creation to Termination

It represents the different phases a pod goes through from creation to termination.

Pending

* The pod is created but not yet running. It’s waiting for the scheduler to assign it to a node or for container images to be pulled

Running

* The pod is assigned to a node, and at least one container is running. However, the container might face issues like:

    * **CrashLoopBackOff**: The container repeatedly crashes and restarts

    * **Error**: The container terminates with an error

Succeeded

* All containers in the pod have finished successfully and won't restart

Failed

* One or more containers in the pod have terminated with an error, and the pod is not being restarted.

Termination:

When a pod is deleted, it enters in Terminating state, where Kubernetes stops and removes its containers

Namespaces in Kubernetes: Organizing and Isolating Resources

namespaces are used to organize and isolate resources within a cluster. They allow different teams, projects, or environments (like dev, test, and prod) to run without conflicts. Each namespace has its own resources, and you can apply resource limits and access controls per namespace. It makes easier to manage and separate resources in a large Kubernetes cluster

Key commands:

Create a namespace
```
kubectl create namespace my-namespace
```

List resources in a specific namespace

kubectl get pods -n my-namespaceview all namespaces

view all namespaces
```
kubectl get ns
```

Init Containers: Setting Up Your Pod for Success

Init Container is like a helper that runs before the main part of your app starts in a pod. It’s used to perform setup tasks or ensure certain conditions are met before the main container runs

Init containers always run before any other container in the pod
A pod can have one or more init containers
The main container will not start until the Init container completes finishes successfully
If a pod’s init container fails, the kubelet repeatedly restart that init container untill it succeeds
If the pod has a restartpolicy of never, and an init container fails during startup of the pod, kubernetes treats overall pod as failed
The regular init containers do not support the lifecycle, livenessProbe, readinessProbe or startupProbe fields

Init container definition file

apiVersion: v1
kind: Pod
metadata:
  name: bootcamp-pod
spec:
  volumes:
  - name: shared-data
    emptyDir: {}
  initContainers:
  - name: bootcamp-init
    image: busybox
    command: ['sh', '-c', 'wget -O /usr/share/data/index.html http://kubesimplify.com']
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/data
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html

Multiple init containers definition file

apiVersion: v1
kind: Pod
metadata:
  name: init-demo-2
spec:
  initContainers:
  - name: check-db-service
    image: busybox
    command: ['sh', '-c', 'until nslookup db.default.svc.cluster.local; do echo waiting for db service; sleep 2; done;']
  - name: check-myservice
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice.default.svc.cluster.local; do echo waiting for db service; sleep 2; done;']
  containers:
  - name: main-container
    image: busybox
    command: ['sleep', '3600']

Definition file of services for multiple init container

apiVersion: v1
kind: Service
metadata:
  name: db
spec:
  selector:
    app: demo1
  ports:
  - protocol: TCP
    port: 3306
    targetPort: 3306
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  selector:
    app: demo2
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Sidecar Containers: Enhancing Your Main Application

Sidecar Container is an additional container that runs alongside the main container in a pod. It helps enhance or support the main container’s functionality

The sidecar container runs in the same pod as the main container, sharing the same network and storage resources
It can act as a proxy server to handle communication between the main container and external services

Example of multiple container with a sidecar container

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  volumes:
  - name: shared-data
    emptyDir: {}
  initContainers:
  - name: meminfo-container
    image: alpine
    restartPolicy: Always
    command: ['sh', '-c', 'sleep 5; while true; do cat /proc/meminfo > /usr/share/data/index.html; sleep 10; done;']
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/
data
  containers:
  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html

Example of a pod with a sidecar container

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-example
spec:
  containers:
    - name: main-container
      image: main-app-image
      ports:
        - containerPort: 80
    - name: sidecar-container
      image: logging-agent-image
      volumeMounts:
        - name: shared-storage
          mountPath: /logs
  volumes:
    - name: shared-storage
      emptyDir: {}

Main Container: Runs the primary application
Sidecar Container: Runs a logging agent that collects logs from the shared storage directory

Conclusion

In conclusion, Kubernetes offers a robust and flexible platform for managing containerized applications. By understanding the different ways to define and manage infrastructure, such as imperative and declarative approaches, users can choose the method that best suits their needs. YAML plays a crucial role in configuring Kubernetes resources, providing a human-readable format that simplifies the creation and management of complex configurations. Pods, as the smallest unit in Kubernetes, encapsulate containers and their lifecycle, ensuring efficient resource utilization and communication. Namespaces help in organizing and isolating resources, making it easier to manage large clusters. Additionally, init containers and sidecar containers extend the functionality of pods, allowing for more sophisticated application setups. By mastering these concepts, users can effectively leverage Kubernetes to deploy, scale, and manage their applications in a cloud-native environment.

Kubernetes (part-2)

Praduman — Sat, 21 Sep 2024 19:08:45 +0000

Kubernetes tools for creating clusters

kubeadm
kops
ksctl

when you create a cluster using these tools, it is called a self-managed Kubernetes cluster

Some managed kubernetes cluster

EKS - AWS
GKE - GCP
Redhat - OpenShifts
AKS - Azure
DKE - Digital Ocean

we generally create self-managed k8s cluster if we have our own servers

Tools for running Kubernetes clusters in a local environment:

kind
minikube
rancher desktop
docker desktop

Understanding Kubernetes Architecture: Master and Worker Nodes

Kubernetes architecture is divided into master nodes and worker nodes, each with specific components that handle different tasks.

Master Node

The master node is the control center of the Kubernetes cluster. It manages the cluster and coordinates all activities.

ETCD: A key-value store that keeps all the cluster's data and configuration. It is crucial for maintaining the cluster's state.
Kube-API Server: The main management point for the cluster. It handles requests from users, other components, and external agents, and updates the cluster's state.
Kube-Scheduler: Assigns tasks to worker nodes based on available resources and needs, making sure resources are used efficiently.
Controller Manager: Keeps the cluster in the desired state by managing various controllers, like the replication controller and endpoint controller.
Cloud Controller Manager: Handles cloud-specific tasks. It allows Kubernetes to interact with cloud provider APIs for things like load balancers and storage.

Worker Node

Worker nodes run the applications. They handle the workload by running pods, which are the smallest deployable units in Kubernetes.

Kubelet: An agent on each worker node that makes sure containers are running in pods as they should.
Kube-Proxy: Manages network communication for the pods, ensuring proper routing within the cluster and to external networks.
Container Runtime Interface (CRI): The software that runs the containers, like Docker or containerd, managing their lifecycle.
Pod: The smallest deployable unit in Kubernetes, consisting of one or more containers that share storage, network, and configuration. Pods are scheduled on worker nodes and managed by the kubelet.

Step-by-Step Guide: K8s Installation Using KOPS on EC2

Create an EC2 instance and connect it to your local machine or use your personal laptop.

Required dependencies:

Python3
AWS CLI
kubectl

KOPS Installation

curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64

chmod +x kops-linux-amd64

sudo mv kops-linux-amd64 /usr/local/bin/kops

Set up AWS CLI configuration on your EC2 Instance or Laptop.

Run aws configure

Kubernetes Cluster Installation

Follow these steps carefully and read each command before executing.

Create an S3 bucket to store KOPS objects:

aws s3api create-bucket --bucket kops-abhi-storage --region us-east-1

Create the cluster:

kops create cluster --name=demok8scluster.k8s.local --state=s3://kops-abhi-storage --zones=us-east-1a --node-count=1 --node-size=t2.micro --master-size=t2.micro --master-volume-size=8 --node-volume-size=8

Edit the configuration:

Important: Edit the cluster configuration as there are multiple resources created that won't fall into the free tier.
```
kops edit cluster demok8scluster.k8s.local
```

Build the cluster:

kops update cluster demok8scluster.k8s.local --yes --state=s3://kops-abhi-storage

This will take a few minutes to complete.

Verify the cluster installation:

kops validate cluster demok8scluster.k8s.local

kubectl commands

Nodes present in the cluster
```
kubectl get nodes
```
Create a pod
```
kubectl run nginx --image=nginx
```

How kubectl Commands Work: Behind the Scenes

when we give a command, we are generally communicate with the cluster

How we did that ?

using the config file, which are present inside the .kube folder on the controlplane

cat .kube/config

How things work

Let's say we need to create a pod using a command

kubectl run my-pod --image=nginx

when we want to do any work using kubectl command. firstly, they make a RestAPI call to API server. After that 3 more things happen :

Authentication
Authorization
Admission

To ensure the request is valid and the person making the request is authorized to perform the task without violating any policies.

The scheduler looks for the best node based on taints/tolerations, affinity, and node selector to run the workload. Then, kubelet runs the workload and talks to CRI to pull the image and start it. The status is updated. Kube-proxy acts like iptables, and your workload runs. Health checks pass and inform the API server that the pod is running, and data is stored in ETCD.

Inside kubeconfig file we have :

user information
cluster information
context information

Inside context, we define which user is connected to which cluster.
Inside users, we define the users present.
Inside clusters, we define the clusters present.

Command to view config file :

kubectl config view

Command to view contexts :

kubectl config get-contexts

Command to view the users :

kubectl config get-users

Creating a New User in Kubernetes: A Detailed Guide

Create a private key using openssl
```
openssl genrsa -out praduman.key 2048
```

```bash
openssl req -new -key praduman.key -out praduman.csr -subj "/CN=praduman/O=group1"
```

</p>

Encode created CSR to base64
```
cat praduman.csr | base64 | tr -d '\n'
```
Create CSR
```
vi csr.yaml
```

```yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
    name: praduman
spec:
    request: <BASE64-encoded CSR>
    signinerName: kubernetes.io/kube-apiserver-client
    usages:
    - client auth
```

> Replace base64\_csr with the previous output

Apply yaml file and approve the certificate to the user

kubectl apply -f csr.yaml
kubectl certificate approve praduman

Get the crt specific to the user using jsonpath

kubectl get csr praduman -o jsonpath='{.status.certificate}' | base64 --decode > praduman.crt

a praduman.crt file is created

Create a role and role binding
```
vim role.yaml
```

```yaml
 kind: Role
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   namespace: default
   name: pod-reader
 rules:
 - apiGroups: [""]
   resources: ["pods"]
   verbs: ["get", "watch", "list"]
---
 kind: RoleBinding
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: read-pods
   namespace: default
 subjects:
 - kind: User
   name: praduman
   apiGroup: rbac.authorization.k8s.io
 roleRef:
   kind: Role
   name: pod-reader
   apiGroup: rbac.authorization.k8s.io
```

```basic
kubectl apply -f role.yaml
```

</p>

Set credentials

kubectl config set-credentials praduman --client-certificate=praduman.crt --client-key=praduman.key

Create context

kubectl config set-context praduman-context --cluster=kubernetes --namespace=default --user=praduman

view contexts
```
kubectl config get-contexts
```

you will see a context with name praduman-context in the default namespace and kubernetes cluster

use the created context

kubectl config use-context praduman-context

a new user is now created and now you can use it

How kubectl command works

Firstly, it searches for the kubeconfig file.
If you set this variable in the current shell, then it first looks for the config file that you provide.
```
export KUBECONFIG=path-to-your-config-file
```
Another way to do this is to provide the kubeconfig file path along with the command.
```
kubectl get pod --kubeconfig ~/.kube/config
```

Let's say you have 3 clusters. Each cluster must have its own kubeconfig file. How will you merge all the config files?

first method

export KUBECONFIG=/path/to/first/config:/path/to/second/config:/path/to/third/config

second method (use kubectx tool)

we use kubectx when we have multiple cluster, users and context for Faster way to switch between clusters (context) in kubectl

# switch to another cluster that's in kubeconfig
$ kubectx minikube
Switched to context "minikube".

# switch back to previous cluster
$ kubectx -
Switched to context "oregon".

# rename context
$ kubectx dublin=gke_ahmetb_europe-west1-b_dublin
Context "gke_ahmetb_europe-west1-b_dublin" renamed to "dublin".

GVR (Group-Version-Resource)

Think of GVR as the address for finding a type of resource in Kubernetes

Group: A broad category (like a section in a library)
Version: A specific edition within that category (like a book edition)
Resource: The actual item you want (like a specific book)

Example: apps/v1/deployments

Group: apps (the section for applications)
Version: v1 (the first edition of this section)
Resource: deployments (the specific item you’re looking for, like a book on deployments)

GVK (Group-Version-Kind)

GVK is similar, but it focuses on the type of item you’re working with

Group: Same broad category
Version: Same specific edition
Kind: The specific type or class of the item

Example: apps/v1/Deployment

Group: apps
Version: v1
Kind: Deployment (the exact type of item you’re dealing with, like a specific chapter in the book)

GVR tells you where to find the resource (apps/v1/deployments)

GVK tells you exactly what the resource is (apps/v1/Deployment)

Communicate with the API server without using kubectl and kubeconfig

wanted to talk to kubernetes api server without kubectl or kubeconfig ?

we will talk to kubernetes directly through api server

create a service account

kubectl create serviceaccount praduman -n default

create cluster role binding

kubectl create clusterrolebinding praduman-clusteradmin-binding --clusterrole=cluster-admin --serviceaccount=default:praduman

create a token
```
kubectl create token praduman
```

```bash
Token=<output-of-the-above-cmd>
```

```bash
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
```

create deployment

curl -X POST $APISERVER/apis/apps/v1/namespaces/default/deployments \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d @deploy.json \
  -k

list pods

curl -X GET $APISERVER/api/v1/namespaces/default/pods \
  -H "Authorization: Bearer $TOKEN" \
  -k

Conclusion

In conclusion, this article provides a detailed exploration of Kubernetes, covering its architecture, tools for creating and managing clusters, and practical steps for setting up a Kubernetes cluster using KOPS on EC2. It distinguishes between self-managed and managed Kubernetes clusters, highlights tools for local development, and delves into the components of master and worker nodes. Additionally, it offers commands and procedures for cluster creation, configuration, and user management, including direct interaction with the Kubernetes API server using REST calls. This comprehensive guide serves as a valuable resource for anyone looking to understand and implement Kubernetes effectively.

Kubernetes (part-1)

Praduman — Sat, 21 Sep 2024 19:03:32 +0000

Understanding Kubernetes: The Container Orchestration Powerhouse

Kubernetes, also known as k8s, is an open-source system that helps automate the deployment, scaling, and management of applications in containers. It is a container orchestration platform.

When you install Kubernetes, you create a cluster, which is a group of nodes. Nodes are physical or virtual machines that helps to run your containers.

Virtual machines can also be orchestrated through Kubernetes by installing KubeVirt.

Kubernetes are:

CNCF Graduated Project
Inspired by Borg and Omega
Launched in 2014
Designed for Scale
Run Anywhere

Why Choose Kubernetes? Unleashing the Power of Container Management

Kubernetes is popular because it offers powerful features:

Autoscaling: Automatically adjusts the number of running containers based on current demand, ensuring efficient resource usage and optimal performance.
Autohealing: Detects and replaces failed containers to maintain the health and availability of applications.
Scheduling: Efficiently allocates containers to nodes based on resource requirements and constraints, optimizing resource usage.
Load Balancing: Distributes network traffic across multiple containers to ensure no single container is overwhelmed.
Storage Orchestration: Automatically mounts the necessary storage systems, whether local, cloud-based, or network storage.
Deployment Automation: Automates the deployment, scaling, and rollback of applications, ensuring smooth updates and maintaining high availability.
Monitoring and Logging Integration: Provides integration with various tools for monitoring and logging, offering insights into application performance and health.

Docker's Drawbacks: Why Kubernetes is the Superior Choice

Docker is a platform for running containers, which are lightweight temporary by nature.

Here are some key issues with Docker:

Ephemeral Nature: Containers have short lifespans. If a container stops or crashes, the application inside becomes inaccessible until someone restarts it.
Single Host Limitation: Docker manages containers on a single machine, making it difficult to handle large-scale deployments.
Manual Monitoring: Monitoring and managing a large number of containers manually is impractical. Running commands like docker ps to check container states isn't feasible at scale.
Handling Traffic: When a container experiences a surge in traffic, Docker lacks built-in mechanisms to automatically distribute the load or scale up the number of containers, leading to potential performance issues.

How Kubernetes Helps

Kubernetes addresses these problems with features like:

Autohealing: Automatically detects and restarts failed containers, ensuring applications remain accessible without manual intervention.
Autoscaling: Automatically adjusts the number of running containers based on traffic demand, ensuring that applications can handle increased traffic without performance degradation.
Multi-Host Orchestration: Manages containers across multiple machines, enabling large-scale deployments and better resource utilization.

Step-by-Step Guide: Creating a Container Using Docker

firstly make sure you have installed Docker on your server

Pull nginx image from dockerHub on your local.

docker run -d --name my-nginx-container --memory 512m --cpus 1 nginx

check image are running
```
docker ps
```

print process id (PID) of container nginx

docker inspect --format '{{.State.Pid}}' my-nginx-container

(or)

ps aux | grep '[n]ginx' | sort -n -k 2 | head -n 1 | awk '{print $2}'

list namespaces of a process of linux
```
lsns -p <PID>
```

Conclusion

Kubernetes, or k8s, revolutionizes the way applications are deployed, scaled, and managed by automating these processes within containerized environments. Its robust features, such as autoscaling, autohealing, efficient scheduling, load balancing, and storage orchestration, make it an indispensable tool for modern DevOps practices. Unlike Docker, which is limited to single-host container management and requires manual intervention for scaling and monitoring, Kubernetes excels in multi-host orchestration and automatic management of container health and scaling. By leveraging Kubernetes, organizations can achieve greater efficiency, reliability, and scalability in their application deployments.

DEV Community: Praduman

Kubernetes (part-8)

Understanding Kubernetes Services: A Comprehensive Guide

What Are Endpoints in Kubernetes?

Exploring Different Types of Kubernetes Services

Networking Fundamentals in Kubernetes: A Deep Dive

StatefulSet: Managing Stateful Applications in Kubernetes

Key Differences Between Deployments and StatefulSets

NodePort: Exposing Your Kubernetes Application

Where it's useful ?

Create a Pod and expose it using NodePort service

LoadBalancer: Making Your Application Public

How It Works:

Why Avoid LoadBalancer in Production?

Alternatives to LoadBalancer for Kubernetes

ExternalName: Mapping Services to External DNS Names

Ingress: Controlling User Access to Kubernetes Applications

Why Use Ingress?

Example

ExternalDNS: Connecting Kubernetes to DNS Providers

How it works:

Use Cases

Conclusion

Kubernetes (part-7)

Understanding ConfigMap: Simplify Your Kubernetes Configuration Management

Example 1: Passing Database User to MySQL Pod Using ConfigMap

Example 2: Managing Dev/Prod Properties with ConfigMap

Example 3: Accessing ConfigMap Programmatically with Python

Secrets in Kubernetes: Securely Manage Sensitive Information

Types of Kubernetes Secrets: Opaque, TLS, and Docker Registry

Example 1: Creating a Kubernetes Secret Using YAML

Example 2: Creating a Kubernetes Secret from the Command Line

Using Secrets in a Pod: Environment Variables and Volume Mounts

Example: Using a Secret as Environment Variables

Example: Mounting a Secret as a Volume

Storing SSH Private Keys in Kubernetes Secrets

Managing SSL/TLS Certificates with Kubernetes TLS Secrets

MySQL Example: Combining ConfigMap and Secrets in Kubernetes

Conclusion

Kubernetes (part-6)

Ensuring Application Availability with ReplicaSets

Understanding Propagation Policies in Kubernetes

Types of Propagation Policies:

Mastering Kubernetes Deployments

Recreate Strategy: Minimizing Downtime During Updates

Probes: Ensuring Pod Health and Readiness

Types of probes in Kubernetes

Implementing Probes in Deployment YAML

Blue-Green Deployment: Minimizing Downtime and Risk

Canary Deployment: Gradual and Safe Application Updates

Conclusion

Kubernetes (part-5)

Efficient Kubernetes Scheduling with Kube-Scheduler

Mastering Labels and Selectors for Resource Grouping

Understanding Kubernetes Namespaces for Resource Isolation

Managing Resource Quotas in Kubernetes

How Resource Quota Works

Ensuring Pod Scheduling Readiness

Use the Custom Controller to Manage Scheduling

Enhancing Availability with Pod Topology Spread Constraints

Prioritizing Pods with Priority Classes

Understanding and Managing Pod Overhead

How It Works

Example: Specify Pod Overhead in a Pod’s resource request

Conclusion

Kubernetes (part-4)

Example of a Sidecar Container

Understanding the Role of the Pause Container in Kubernetes

How to View Pause Containers and Pod IPs

Kubernetes User Namespaces

Pod Disruptions

Pod disruption budgets (PDB)

Setting Resource Requests and Limits for Efficient Resource Management

Understanding CPU Throttling in Kubernetes

Overutilization and Underutilization of Resources

Quality of Service (QoS)

Understanding Kubernetes Downward API

How to Use the Downward API

Conclusion

Kubernetes (part-3)