Kubernetes Basics

Q1: Explain the core components of Kubernetes architecture.

Ans: The components are as follow: 1. API Server – entry point for all cluster operations.
2. etcd – distributed key-value store for cluster state.
3. Controller Manager – ensures desired state matches actual state.
4. Scheduler – assigns Pods to nodes.
5. Kubelet – agent running on each node.
6. Kube-proxy – manages networking and service routing.

Q2: How do you manage secrets?

Ans: Secrets in Kubernetes are managed using the Secret object, which stores sensitive data such as passwords, tokens, or keys. They can be created using kubectl or YAML manifests and then mounted into Pods as environment variables or volumes.

Q3: What are the disadvantages of keeping secrets in k8s secret?

Ans: Kubernetes Secrets are only base64-encoded, not encrypted by default, which makes them vulnerable if etcd is not secured. They require proper RBAC and encryption at rest to ensure security. Misconfigured access controls can expose sensitive data.

Q4: How does your containers fetch secret? Give step wise flow.

Ans: 1. Create a Secret object in Kubernetes. 2. Reference the Secret in the Pod specification. 3. Secrets can be injected as environment variables or mounted as volumes. 4. The container reads the secret from the environment variable or file path. 5. Application logic uses the secret securely.

Q5: What is difference between volume mounts and PVC?

Ans: Volume mounts attach a storage volume directly to a Pod, while PersistentVolumeClaim (PVC) is a request for storage resources from the cluster. PVCs provide abstraction and allow Pods to use PersistentVolumes (PV) managed by Kubernetes.

Q6: What is PV and PVC?

Ans: PersistentVolume (PV) is a piece of storage provisioned in the cluster, while PersistentVolumeClaim (PVC) is a request by a user to consume that storage. PVs are cluster resources, PVCs are user requests for those resources.

Q7: What is taint and tolerations?

Ans: Taints are applied to nodes to repel certain Pods, while tolerations are applied to Pods to allow them to be scheduled on tainted nodes. Together, they control Pod placement and prevent workloads from running on inappropriate nodes.

Q8: Explain types of probes.

Ans: Kubernetes supports three types of probes: 1. Liveness Probe – checks if the container is still running. 2. Readiness Probe – checks if the container is ready to serve traffic. 3. Startup Probe – checks if the application has started successfully.

Q9: How will you troubleshoot 'Image pull back off' error'. Describe the steps and commands.

Ans: 1. Run `kubectl describe pod ` to check events. 2. Verify image name and tag. 3. Check registry credentials and Secret configuration. 4. Ensure network connectivity to the registry. 5. Run `kubectl get events` for detailed error logs. 6. Correct image path or authentication issues.

Q10: Suppose you have deployed a deployment and you are getting 0/2 ready. Explain the troubleshooting steps.

Ans: 1. Run `kubectl describe deployment ` to check events. 2. Inspect Pods with `kubectl get pods` and `kubectl describe pod`. 3. Check container logs using `kubectl logs `. 4. Verify readiness/liveness probes. 5. Ensure resources (CPU/memory) are sufficient. 6. Fix misconfigurations and redeploy.

Q11: Write a deployment yaml file.

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

Q12: Suppose you have got a ticket that there is a latency of 180ms observed how will you troubleshoot.

Ans: 1. Check application logs for performance bottlenecks. 2. Use `kubectl top pod` to monitor resource usage. 3. Inspect network policies and service configuration. 4. Run `kubectl describe svc` to verify load balancing. 5. Use monitoring tools like Prometheus/Grafana to trace latency. 6. Optimize application code or scale replicas.

Q13: You are deploying and it failed how will you roll back.

Ans: Use `kubectl rollout undo deployment ` to roll back to the previous stable version. Check rollout status with `kubectl rollout status deployment ` to confirm rollback success.

Q14: What are the types of scaling in K8S?

Ans: Kubernetes supports two types of scaling: 1. Horizontal Pod Autoscaling (HPA) – scales Pods based on CPU/memory usage or custom metrics. 2. Vertical Pod Autoscaling (VPA) – adjusts resource requests/limits for Pods. Additionally, Cluster Autoscaler scales nodes based on workload demand.

Q15: Explain how you would debug a sudden increase in latency across services in Kubernetes.

Ans: 1. Check Pod resource usage with `kubectl top pods`. 2. Inspect logs for errors or timeouts. 3. Use `kubectl describe pod` to check events and probe failures. 4. Verify network policies and DNS resolution. 5. Check service endpoints with `kubectl get endpoints`. 6. Use monitoring tools (Prometheus, Grafana) to identify bottlenecks. 7. Investigate node resource saturation or noisy neighbors. 8. Trace requests using distributed tracing (Jaeger, Zipkin).

Q16: What’s the use of a PodDisruptionBudget?

Ans: A PodDisruptionBudget (PDB) ensures a minimum number of Pods remain available during voluntary disruptions (like node drains or upgrades). It prevents Kubernetes from evicting too many Pods at once, maintaining application availability.

Q17: How do you do cluster upgrades. What are the steps you take.

Ans: 1. Backup cluster state and etcd. 2. Review release notes for breaking changes. 3. Upgrade control plane components (API server, controller manager, scheduler). 4. Upgrade kubelet and kube-proxy on nodes. 5. Perform rolling node upgrades. 6. Validate workloads and monitoring. 7. Test failover and rollback procedures.

Q18: How do you perform rolling updates and rollbacks in Kubernetes?

Ans: Rolling updates are done using Deployments with `kubectl rollout restart deployment `. Kubernetes gradually replaces old Pods with new ones. Rollbacks are performed with `kubectl rollout undo deployment `, reverting to the previous ReplicaSet.

Q19: Differentiate between ClusterIP, NodePort, and LoadBalancer Service types.

Ans: ClusterIP: Exposes service internally within the cluster. NodePort: Exposes service on a static port across all nodes. LoadBalancer: Integrates with cloud provider load balancers to expose service externally.

Q20: What is a StatefulSet and when would you use it?

Ans: A StatefulSet manages Pods with stable identities and persistent storage. It is used for stateful applications like databases, where Pod identity and storage consistency are critical.

Q21: How does Pod-to-Pod communication work across different nodes?

Ans: Pods communicate using the cluster network (CNI plugin). Each Pod gets a unique IP, and kube-proxy manages routing. Communication across nodes is handled by the underlying CNI (Calico, Flannel, Cilium) ensuring flat networking.

Q22: What is an init container?

Ans: An init container is a special type of container that runs before the main application container in a Pod. It is used to perform initialization tasks such as setting up files, downloading resources, or running configuration scripts.

Q23: Write a pod yaml file for init container.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  initContainers:
  - name: init-db
    image: busybox
    command: ['sh', '-c', 'echo Initializing... && sleep 5']
  containers:
  - name: myapp
    image: myapp:latest
    ports:
    - containerPort: 8080

Q24: What is Cluster Autoscaler?

Ans: Cluster Autoscaler automatically adjusts the size of a Kubernetes cluster based on workload demands. It adds nodes when Pods cannot be scheduled and removes underutilized nodes to optimize costs.

Q25: Explain Role-Based Access Control (RBAC) in Kubernetes.

Ans: RBAC defines permissions based on roles and bindings. Roles specify allowed actions (verbs) on resources, and RoleBindings or ClusterRoleBindings assign these roles to users, groups, or service accounts.

Q26: What are Service Accounts? How are they used?

Ans: Service Accounts provide an identity for Pods to interact with the Kubernetes API. They are used for authentication, mounting secrets, and granting RBAC permissions to workloads.

Q27: Can two containers in the same pod bind two the same port? Why or why not?

Ans: No, two containers in the same Pod cannot bind to the same port because they share the same network namespace. - That means they share the same IP address and port space. - If one container is already bound to port 8080, another container in the same Pod cannot also bind to 8080, it will fail with a port conflict.

Q28: What would you do if a Pod in Kubernetes is stuck in 'CrashLoopBackOff' state?

Ans: The approach is as follow: 1. Check Logs – use 'kubectl logs' to identify the cause of repeated crashes.
2. Inspect Events – run 'kubectl describe pod' to see detailed error events.
3. Validate Config – check environment variables, secrets, and mounted volumes.
4. Resource Limits – ensure the Pod has sufficient CPU/memory.
5. Fix and Redeploy – correct the issue and redeploy the Pod.

Q29: If one Kubernetes service is receiving heavy traffic while others are idle, how would you handle resource allocation?

Ans: The solution is as follow: 1. Scale Down Idle Deployments – reduce replicas for underutilized services.
2. Scale Up Busy Service – increase replicas using 'kubectl scale' or HPA.
3. Autoscaling – configure Horizontal Pod Autoscaler to adjust replicas automatically.
4. Resource Quotas – prioritize critical services with higher resource requests/limits.

Q30: What happens if the Kubernetes API server goes down?

Ans: The impact is as follow: 1. No New Operations – cluster cannot schedule new Pods or process configuration changes.
2. Existing Workloads – running Pods continue to function since kubelet manages them locally.
3. Recovery – restart or restore the API server, often backed by etcd.
4. Best Practice – run API server in HA mode with multiple replicas.

Q31: How would you debug a situation where a Pod cannot reach another Pod in the same cluster?

Ans: The approach is as follow: 1. Check Services – verify if a Service is correctly exposing the target Pod.
2. Network Policies – ensure no restrictive policies are blocking traffic.
3. DNS Resolution – confirm CoreDNS is resolving service names.
4. Firewall Rules – check host-level firewalls or cloud security groups.

Q32: What would you do if a Deployment keeps creating Pods but they remain in 'Pending' state?

Ans: The handling is as follow: 1. Check Node Resources – ensure nodes have enough CPU/memory.
2. Scheduling Constraints – verify affinity/taints/tolerations are not blocking scheduling.
3. Storage Issues – confirm PVCs are bound to PVs.
4. Cluster Capacity – add more nodes or scale the cluster to meet demand.

Q33: Walk me through how a user request flows through your system from DNS → Load Balancer → Service → Pod → Database.

Ans: A user request first resolves via DNS to the application’s public endpoint. The Load Balancer receives the request and distributes it across available nodes. Kubernetes Service abstracts pods and routes traffic to healthy endpoints. The request reaches a Pod running the application container, which processes logic and queries the Database. The Database executes the query and returns results back through the same chain to the user.

Q34: Your Kubernetes pods are restarting every few minutes. What’s your debugging flow?

Ans: Start by checking pod events and logs (`kubectl describe pod`, `kubectl logs`). Inspect readiness/liveness probes for misconfiguration. Verify resource limits (CPU/memory) and check for OOMKilled events. Review CrashLoopBackOff reasons. Inspect node health and kubelet logs. Validate image integrity and startup commands. Finally, check external dependencies (DB, API) that may cause startup failures.

Q35: Your system latency suddenly increased after a deployment. What would you check first?

Ans: First, compare metrics before and after deployment. Check application logs for errors or slow queries. Validate database query performance and indexes. Inspect service mesh or network policies for added latency. Review resource utilization (CPU, memory, I/O). Roll back deployment to confirm if latency is tied to new code/config changes.

Q36: Traffic increases 10x during peak hours. Which components become bottlenecks?

Ans: Load Balancer may hit connection limits. Kubernetes Service routing could struggle if pods are insufficient. Pods may exhaust CPU/memory, leading to throttling. Database becomes a critical bottleneck due to connection pool saturation and slow queries. Storage I/O and network bandwidth may also degrade under heavy load.

Q37: Your monitoring didn’t detect an outage for 10 minutes. What went wrong?

Ans: Possible causes include: monitoring probes misconfigured or targeting wrong endpoints, alert thresholds set too high, missing health checks for dependencies, delayed scraping intervals, or alerting pipeline issues (e.g., notification service down). Gaps in synthetic monitoring or lack of redundancy in observability stack can also delay detection.

Q38: How does Pod-to-Pod communication work across different nodes?

Ans: Kubernetes uses the Container Network Interface (CNI) to provide a flat, cluster-wide network. Each pod gets its own IP address, and communication across nodes is handled by the underlying CNI plugin (e.g., Flannel, Calico, Cilium). Packets are routed transparently without NAT, allowing pods to talk directly to each other regardless of node boundaries.

Q39: What are Network Policies in Kubernetes? When would you use them?

Ans: Network Policies are rules that define how pods can communicate with each other and with external endpoints. They allow fine-grained control over ingress and egress traffic. You use them to enforce security boundaries, restrict communication between namespaces, or limit access to sensitive services (e.g., only allowing frontend pods to talk to backend pods).

Q40: How does Kubernetes handle DNS for services and pods?

Ans: Kubernetes runs a DNS service (usually CoreDNS) inside the cluster. Each service gets a DNS entry like `service-name.namespace.svc.cluster.local`. Pods can resolve these names automatically. Pods themselves also get DNS records, but services are the primary abstraction for stable discovery. This enables seamless service-to-service communication without hardcoding IPs.

Q41: What is Horizontal Pod Autoscaling (HPA)? How does it work?

Ans: HPA automatically adjusts the number of pod replicas based on observed metrics such as CPU or memory usage. It queries metrics from the Metrics Server, compares them against target thresholds, and scales the Deployment or ReplicaSet up or down accordingly. This ensures workloads adapt to fluctuating demand.

Q42: What is Vertical Pod Autoscaling (VPA)?

Ans: VPA adjusts the resource requests and limits (CPU/memory) of pods instead of scaling the number of replicas. It analyzes historical usage and recommends or applies changes to pod specifications. This is useful for workloads that cannot be horizontally scaled easily but need more resources to perform efficiently.

Q43: How would you troubleshoot a failed Deployment?

Ans: Check the Deployment status with `kubectl describe deployment`. Inspect ReplicaSet and pod events for scheduling or image pull errors. Verify container logs for runtime issues. Ensure resource requests are not preventing scheduling. Confirm that the Deployment spec matches expectations and roll back if necessary.

Q44: Explain Liveness and Readiness Probes. Why are they important?

Ans: Liveness probes check if a container is still running; if it fails, Kubernetes restarts the container. Readiness probes check if a container is ready to serve traffic; if it fails, the pod is removed from Service endpoints. They are critical for ensuring application health and preventing traffic from being sent to unhealthy pods.

Q45: How do you secure access to the Kubernetes API server?

Ans: Secure access involves enabling RBAC for fine-grained permissions, using TLS for encrypted communication, and authenticating via certificates, tokens, or external identity providers. Network policies and firewalls can restrict API server access. Audit logging and API server flags further strengthen security.

Q46: How would you debug a Pod that is stuck in a Pending state?

Ans: Check pod events with `kubectl describe pod` to see scheduling errors. Common causes include insufficient resources, unschedulable node selectors, taints/tolerations mismatch, or missing PersistentVolume claims. Verify cluster capacity and ensure the scheduler can place the pod on a suitable node.

Q47: How would you troubleshoot an application that is unreachable from outside the cluster?

Ans: Verify that the Service type is correctly configured (NodePort, LoadBalancer, or Ingress). Check ingress controller logs and rules. Ensure firewall and cloud provider security groups allow traffic. Confirm DNS resolution and that pods are healthy and passing readiness probes. Validate network policies aren’t blocking external access.

Q48: What is the use of -n

Ans: The use is as follows: In Kubernetes (`kubectl`), the -n (or --namespace) flag is used to scope a command to a specific namespace. By default, kubectl commands run in the 'default' namespace. If your resources (like pods, services, or deployments) are isolated in a different logical cluster partition, you must use -n <namespace-name> to interact with them.

Q49: How do you find which deployment uses a specific environment variable in Kubernetes?

Ans: The methods are as follow: 1. Using kubectl and grep: You can fetch all deployments in a namespace and filter the output using kubectl get deployments -n <namespace> -o yaml | grep -B 10 -A 2 "ENV_VAR_NAME".
2. Using custom columns/jsonpath: For a more structured approach, you can use jsonpath to parse the deployment spec: kubectl get deployments -A -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .spec.template.spec.containers[*].env[*]}{'\t'}{.name}{"="} {.value}{"\n"}{end}{end}' | grep "ENV_VAR_NAME".

Q50: How do you perform node maintenance in Kubernetes?

Ans: The steps are as follow: 1. Cordon the Node: Mark the node as unschedulable to prevent new pods from being assigned to it using kubectl cordon <node-name>.
2. Drain the Node: Safely evict all running pods from the node using kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data.
3. Perform Maintenance: Carry out your OS upgrades or hardware repairs.
4. Uncordon the Node: Bring the node back into service so it can accept new pods again using kubectl uncordon <node-name>.

Q51: If you're installing the Kubernetes package by using Helm and the helm package is not installed its failed. How do we troubleshoot?

Ans: The troubleshooting steps are as follow: 1. Verify Installation: Confirm if Helm is actually missing by running helm version. If it returns 'command not found', Helm is not installed on the system executing the command.
2. Install Helm binary: Download and install Helm using the official script: curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash.
3. Check Environment PATH: If you installed Helm but it still fails, ensure the directory containing the helm binary (usually /usr/local/bin) is included in your system's $PATH environment variable.