Day-7-Kubernetes

TLDR: This blog post explores the concepts of sidecar containers and resource quotas in Kubernetes, detailing their functionalities, types, and practical implementations. It emphasizes the importance of hands-on practice and provides a comprehensive guide to deploying and managing these components in a Kubernetes cluster.

In this blog post, we will delve into two important topics in Kubernetes: sidecar containers and resource quotas. These concepts are crucial for managing applications effectively in a Kubernetes environment. We will explore what sidecar containers are, their types, and how resource quotas help manage resources in a cluster. Additionally, we will provide practical examples to illustrate these concepts.

What are Sidecar Containers?

Sidecar containers are auxiliary containers that run alongside a main application container within the same pod. They serve as dependencies for the main container, enhancing its functionality without altering its core logic.

Types of Sidecar Containers

1. Init Containers: These are specialized containers that run before the main container starts. They perform initialization tasks, such as checking dependencies or preparing the environment. For example, an init container might verify that a database is accessible before the main application starts.

2. Adapter Containers: These containers run concurrently with the main container and act as proxies. They are useful for logging, tracing, and metrics collection. For instance, an adapter container might handle requests and responses between the main application and external services.

3. Ambassador Containers: Although less commonly used, ambassador containers facilitate communication in microservices architectures. They can manage SSL termination and route traffic to various microservices within a Kubernetes cluster.

Practical Implementation of Sidecar Containers

To illustrate the use of sidecar containers, we will create a deployment file that includes both init and adapter containers. This deployment will consist of 156 lines of code, which we will break down step by step.

Example Deployment File

The deployment file will include:

• Init Containers: These will check for the availability of a service before allowing the main container to start.

• Adapter Containers: These will run alongside the main container to handle logging and other tasks.

Step-by-Step Breakdown

1. Define Init Containers: The init container will use a busybox image to check for a service called my-service. If the service is not available, the main container will not start.

2. Define Adapter Containers: The adapter container will run concurrently with the main container, performing tasks such as logging the current date and writing it to an HTML file.

3. Main Container: The main application container will run the core application logic.

Understanding Resource Quotas

Resource quotas are essential for managing resources in a Kubernetes cluster. They ensure that no single team or application consumes all available resources, which could lead to performance issues for other applications.

How Resource Quotas Work

Resource quotas are applied at the namespace level, allowing administrators to set limits on the amount of CPU and memory that can be used by the resources within that namespace. For example, if a cluster has 20 CPUs and 20 GB of memory, resource quotas can be set to allocate specific amounts to different teams or applications.

Example of Resource Quotas

1. Creating Namespaces: Each team can be assigned a separate namespace to isolate their resources.

2. Setting Quotas: For each namespace, quotas can be set to limit the number of pods, CPU, and memory usage. For instance, a namespace might be limited to 5 CPUs and 5 GB of memory.

3. Applying Limits: In addition to quotas, limits can be set on individual containers to prevent any single container from consuming excessive resources.

4. 

# login to management server
kubectl cluster-info
kubectl get nodes -o wide

apiVersion: apps/v1
kind: Deployment
metadata:
  name: adapter-container-deployment
  labels:
    env: prod
spec:
  replicas: 3
  selector:
    matchLabels:
      env: prod
  template:
    metadata:
      labels:
        env: prod
    spec:
      initContainers:
        - name: wait-for-service
          image: busybox
          command:
            [
              "sh",
              "-c",
              "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done",
            ]
        - name: perform-task
          image: busybox
          command:
            [
              "sh",
              "-c",
              'echo "Init container tasks completed" > /tasks/status.txt',
            ]
          volumeMounts:
            - name: shared-vol
              mountPath: /tasks
      containers:
        - name: adapter-container
          image: kiran2361993/kubegame:v1
          command: ["/bin/sh"]
          args:
            [
              "-c",
              "while true; do echo \\<h1\\>$(date)\\</h1\\> >> /html/index.html; sleep 5; done",
            ]
          ports:
            - containerPort: 80
          volumeMounts:
            - name: shared-vol
              mountPath: /html/
          resources:
            requests:
              cpu: "100m"
              memory: "256Mi"
            limits:
              cpu: "200m"
              memory: "512Mi"
        - name: main-container
          image: kiran2361993/kubegame:v1
          imagePullPolicy: Always
          ports:
            - containerPort: 80
          volumeMounts:
            - name: shared-vol
              mountPath: /usr/share/nginx/html/
          resources:
            requests:
              cpu: "100m"
              memory: "256Mi"
            limits:
              cpu: "200m"
              memory: "512Mi"
      volumes:
        - name: shared-vol
          emptyDir: {}

mkdir init
cd init
nano init.yml # paste above code there -> ctrl+x,y
kubectl apply -f init.yml
# status-> Init:0/2  # will not deploy main container since myservice is not created

watch kubectl get pods -o wide

kubectl expose deployment init-container-deployment --name myservice  --port 80  
kubectl get svc # created myservice will be visible

# Init container tasks completed  -->  /tasks/status.txt

Practical Implementation of Resource Quotas

To demonstrate resource quotas, we will create a namespace and apply resource quotas to it. This will involve:

1. Creating a Namespace: We will create a namespace called development.

2. Applying Resource Quotas: We will set quotas for CPU and memory usage within this namespace.

3. Testing Quotas: We will attempt to create pods and observe how the quotas restrict resource usage.

Conclusion

Understanding sidecar containers and resource quotas is vital for effective Kubernetes management. Sidecar containers enhance the functionality of main application containers, while resource quotas ensure fair resource distribution among applications. By practicing these concepts, you can gain a deeper understanding of Kubernetes and improve your deployment strategies.

Call to Action

If you found this post helpful, please practice these concepts in your own Kubernetes environment. Hands-on experience is the best way to solidify your understanding. Don't forget to subscribe for more insights into Kubernetes and cloud-native technologies!