标签：#kodekloud

We have a web server container running the nginx image. The access and error logs generated by the web server are not critical enough to be placed on a persistent volume. However, Nautilus developers need access to the last 24 hours of logs so that they can trace issues and bugs. Therefore, we need to ship the access and error logs for the web server to a log-aggregation service. Following the separation of concerns principle, we implement the Sidecar pattern by deploying a second container that ships the error and access logs from nginx. Nginx does one thing, and it does it well - serving web pages. The second container also specializes in its task - shipping logs. Since containers are running on the same Pod, we can use a shared emptyDir volume to read and write logs. Create a pod named webserver . Create an emptyDir volume named shared-logs . Create a regular container in the webserver pod from the nginx:latest image named nginx-container , and an init container from the ubuntu:latest image named sidecar-container . Add the following command to the sidecar-container "sh","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done" Mount the shared-logs volume in both containers at /var/log/nginx . Ensure all containers are in a running state. What is a Sidecar Container? Think of a sidecar like a motorcycle sidecar – it's attached to the main vehicle and extends its capabilities without changing the main vehicle itself. ┌─────────────────────────────────────────────────────────────────────────────┐ │ The Sidecar Analogy │ │ │ │ ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ Motorcycle: The Main Vehicle │ │ │ │ - Does its primary job (serving web pages) │ │ │ │ - Doesn't worry about extra tasks │ │ │ └────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ Sidecar: Adds Extra Functional

The Nautilus DevOps team is gearing up to deploy applications on a Kubernetes cluster for migration purposes. A team member has been tasked with creating a ReplicaSet outlined below: Create a ReplicaSet using nginx image with latest tag (ensure to specify as nginx:latest ) and name it nginx-replicaset . Apply labels: app as nginx_app , type as front-end . Name the container nginx-container . Ensure the replica count is 4 . Solution Step 1: Generate the ReplicaSet YAML First, let's generate a base ReplicaSet manifest: kubectl create replicaset nginx-replicaset \ --image = nginx:latest \ --dry-run = client -o yaml > nginx-replicaset.yaml Step 2: Edit the YAML to Add Requirements Open the file and modify it according to the requirements: nano nginx-replicaset.yaml Update the file with: Replica count: 4 Labels: app: nginx_app , type: front-end Container name: nginx-container Here's the complete YAML: apiVersion : apps/v1 kind : ReplicaSet metadata : name : nginx-replicaset labels : app : nginx_app type : front-end spec : replicas : 4 selector : matchLabels : app : nginx_app type : front-end template : metadata : labels : app : nginx_app type : front-end spec : containers : - name : nginx-container image : nginx:latest ports : - containerPort : 80 Step 3: Apply the ReplicaSet Create the ReplicaSet in your cluster: kubectl apply -f nginx-replicaset.yaml Expected output: replicaset.apps/nginx-replicaset created Step 4: Verify the ReplicaSet Check that the ReplicaSet was created successfully: kubectl get replicasets Expected output: NAME DESIRED CURRENT READY AGE nginx-replicaset 4 4 4 10s Step 5: Verify Pods Check that 4 pods were created: kubectl get pods Expected output: NAME READY STATUS RESTARTS AGE nginx-replicaset-xxxxx 1/1 Running 0 15s nginx-replicaset-yyyyy 1/1 Running 0 15s nginx-replicaset-zzzzz 1/1 Running 0 15s nginx-replicaset-wwwww 1/1 Running 0 15s Step 6: Verify Labels Check that the labels are correctly applied: kubectl get replicaset nginx-replicaset --s