prepforcareers.com

When a developer commits code to Git, the CI/CD pipeline gets triggered automatically. The pipeline first pulls the latest code, runs tests and code quality checks, then builds the application. If Docker is being used, it creates a Docker image and pushes it to a registry. After that, the deployment stage deploys the application to a test or production environment. This process helps deliver changes faster and reduces manual errors.

When I run a Docker container, Docker first checks whether the image exists locally. If not, it pulls it from a registry. Then Docker creates a writable container layer on top of the image, configures networking, allocates resources, and starts the container’s main process. The container keeps running as long as that main process is active.

When a pod is created, it remains in a Pending state until the Kubernetes Scheduler finds a suitable worker node. The scheduler checks available resources like CPU and memory, along with any node selectors, taints, tolerations, or affinity rules. Once a suitable node is found, the pod is assigned there and the kubelet starts the containers.

CrashLoopBackOff means the container keeps crashing and Kubernetes is repeatedly trying to restart it. Common causes include application errors, wrong environment variables, incorrect configuration, missing dependencies, or resource issues. I usually start by checking the pod logs using ‘kubectl logs’, then inspect events with ‘kubectl describe pod’ to identify the root cause.

A readiness probe checks whether a container is ready to receive traffic. If it fails, Kubernetes stops sending requests to that pod. A liveness probe checks whether the application is still healthy. If it fails, Kubernetes restarts the container. In simple terms, readiness controls traffic, while liveness controls restarts.

Kubernetes has a control plane and worker nodes. The control plane includes components like the API Server, Scheduler, Controller Manager, and etcd. The API Server receives requests, the Scheduler decides where pods run, Controllers maintain the desired state, and etcd stores cluster information. Worker nodes run kubelet, kube-proxy, and the actual application containers.

Kubernetes Services provide a stable way for applications to communicate. When a Service is created, it gets a DNS name and ClusterIP. Pods can use that DNS name instead of individual pod IPs. CoreDNS automatically resolves service names to the correct backend pods.

When I run ‘kubectl apply’, the YAML file is sent to the API Server. Kubernetes compares the desired state defined in the YAML with the current cluster state. If changes are detected, the API Server updates the objects. Controllers then work to make the actual state match the desired state.

A Deployment is used for stateless applications like web servers. A StatefulSet is used for stateful applications like databases because it provides stable identities and storage. A DaemonSet ensures that one pod runs on every node, which is useful for log collection or monitoring agents.

I usually separate configuration from application code. For Kubernetes, I use ConfigMaps and Secrets. For Terraform, I use different variable files for dev, staging, and production. This approach allows the same codebase to be reused across environments while keeping environment-specific settings separate.

Terraform keeps a state file that tracks the resources it manages. Before making changes, Terraform compares the configuration with the state file to determine what needs to be created, modified, or deleted. Dependencies are automatically identified through resource references, allowing Terraform to create resources in the correct order.

Terraform drift occurs when someone manually changes infrastructure outside Terraform. As a result, the actual infrastructure no longer matches the Terraform configuration. I usually detect drift by running ‘terraform plan’, which shows differences between the current state and the desired configuration.

I prefer creating reusable Terraform modules and then using different variable files for dev, test, and production environments. This keeps the code consistent while allowing environment-specific customization. It also reduces duplication and makes maintenance easier.

When a user enters a domain name, the system first checks the local cache. If the record isn’t found, the query goes to a recursive DNS resolver. The resolver contacts root servers, then TLD servers, and finally the authoritative DNS server. The IP address is returned and the application can connect to the target server.

Layer 4 load balancers make routing decisions based on IP addresses and ports. Layer 7 load balancers understand HTTP and HTTPS traffic, allowing routing based on URLs, headers, or hostnames. Layer 7 provides more flexibility for modern web applications.

I start by checking CPU, memory, disk, and network utilization. Then I review application logs, monitoring dashboards, and database performance metrics. Tools like Prometheus, Grafana, and APM solutions help identify whether the bottleneck is in the application, infrastructure, or database layer.

I monitor infrastructure metrics, application metrics, logs, and business metrics. For example, CPU usage, memory usage, API response times, error rates, and disk usage. Alerts should focus on actionable issues rather than generating unnecessary noise. The goal is to detect problems before users are affected.

In modern environments, I prefer using TLS or mutual TLS to encrypt communication between services. Authentication can be handled using service accounts, tokens, certificates, or identity providers depending on the architecture. The main goal is to ensure that only trusted services can communicate with each other.

Common approaches include rolling deployments, blue-green deployments, and canary deployments. Personally, I’ve mostly worked with rolling updates in Kubernetes, where new pods are gradually started before old pods are terminated. This allows users to continue accessing the application during deployments.

First, I confirm the impact and identify which services are affected. Then I check monitoring dashboards, alerts, logs, and recent deployments. If a recent change caused the issue, I consider rolling back. I continue investigating infrastructure, networking, databases, and application logs until the root cause is identified. Once resolved, I document the incident and preventive actions to avoid similar issues in the future.