Kubernetes Admin Mock Interview Questions & Prep | SPOTO

Kubernetes enables non-disruptive updates, ensuring cluster maintenance without downtime.

Persistent Volumes can be dynamically provisioned using storage classes, which allows for greater flexibility and scalability compared to static hostPath volumes.

Upgrading a Kubernetes cluster typically involves a sequence of steps to ensure minimal downtime and a smooth transition. The most common tool for this is kubeadm. Here are the steps: 1. Upgrade kubeadm on the control plane node. 2. Drain the control plane node. 3. Upgrade the kubelet and kubectl on the control plane node. 4. Uncordon the control plane node. 5. Upgrade kubeadm on the worker nodes. 6. Drain each worker node. 7. Upgrade the kubelet and kubectl on the worker node. 8. Uncordon the worker node. This process is repeated for each worker node.

A container is an isolated running process created from a container image. A container runtime is the software that creates and manages containers on a node. Kubernetes uses the Container Runtime Interface (CRI) to talk to runtimes such as containerd and CRI-O. Since Kubernetes v1.24, the built-in dockershim adapter was removed, but Docker-built images still work normally on CRI-compatible runtimes.

Kubernetes is based on a master-slave module. The worker module consists of 4 components: - API Server: This is a primary manager responsible for exposing the Kubernetes API, which allows users to interact with the cluster. It also provides Authentication. - Scheduler: Decision-making for deploying pods within the cluster. Which pod will schedule on which node. - Controller Manager: Control and Manage cluster, Ensure the desired state matches the actual state. - ETCD: It's a database that stores configuration date, state, and metadata. The Worker module consists of 3 components: - Kubelet: It is responsible for ensuring that containers are running in a Pod. - Container Runtime: Software responsible for running containers. - Kube-proxy: Maintains network rules on nodes. - Pods: The smallest deployable units of computing that can be created and managed in Kubernetes.

Kubernetes supports secure communication through Transport Layer Security (TLS) certificates and mutual authentication between Pods and Services.

Container orchestration (dummies) is a method of deploying, operating, and scaling containerized applications. These containers can be managed on a single or more than one server. With this practice, users can easily automate various operations, such as container provisioning, availability, load balancing, etc. It also helps to manage the lifecycle of containers like design, deploy, scale and destruction. It also helps to ensure that all containers are working together, efficiently and seamlessly to provide desired services. It is an orchestration technique in which organizations can manage the containerized applications throughout the lifecycle. It allows developers to manage complex workloads and environments without dealing with underlying infrastructure. This technique reduces extra costs and increases scalability and efficiency to get improved performance.

- Portability: Kubernetes is portable, running both on-premises and in the cloud. - Scalability: It's proven its mettle in managing massive container workloads efficiently, adapting to varying resource demands and scheduling tasks effectively. - Community and Ecosystem: A vast and active community contributes to the platform, ensuring it stays innovative and adaptable to evolving business needs. - Extensive Feature Set: Kubernetes offers rich capabilities, making it suitable for diverse deployment and operational requirements. - Reliability and Fault Tolerance: From self-healing capabilities to rolling updates, it provides mechanisms for high availability and resilience. - Automation and Visibility: It simplifies operational tasks and offers insights into the state of the system. - Security and Compliance: It provides role-based access control, network policies, and other security measures to meet compliance standards.

The different types of controller managers in Kubernetes are: - node controller - replication controller - endpoints controller - service accounts controller - token controller - namespace controller

StatefulSets are used for applications that require persistent storage and unique network identifiers. Unlike Deployments, StatefulSets ensure that the naming and storage remains consistent even when the pods are rescheduled to new nodes.

Kubernetes allows easy rollbacks via kubectl. It keeps a history of ReplicaSets, enabling you to revert to a previous state. Some K8s rollback strategies include: - Recreate deletes old pods before creating new ones. - RollingUpdate gradually replaces old pods. - Canary Deployments gradually shift traffic to new versions.

The node status consists of the following information: - Address - Condition - Capacity - Info

GKE is Google Kubernetes Engine that is used for managing and orchestrating systems for Docker containers. With the help of Google Public Cloud, we can also orchestrate the container cluster.

The main benefit of rolling update such that it allows the deployment update to occur with zero downtime. It can be better handled by incremental replacement of the current nodes with the new ones. The scheduling of new pods on the nodes will occur and Kubernetes will wait for the new pods to start before eliminating the old pods.

Operators in Kubernetes are a powerful concept that extends the platform's native capabilities by automating complex application management tasks. They encapsulate domain-specific knowledge and best practices into custom controllers, allowing for the automation of tasks such as deploying, configuring, scaling, and managing stateful applications. Operators leverage the Kubernetes API and its declarative nature to continuously monitor and reconcile the desired state of an application with its current state. This intelligent automation simplifies the operation of containerized applications, reduces human intervention, and enhances the reliability and scalability of Kubernetes clusters. Operators are particularly useful for managing stateful applications like databases, where their ability to handle lifecycle events and updates makes them an invaluable tool in the Kubernetes ecosystem.

Pods are the smallest objects that can be deployed on a Kubernetes cluster. A pod can contain one or more containers, and the applications run inside them. These containers share the resources allotted to the pods, like storage, network, etc. The sample manifest below creates a pod using the busybox image. apiVersion: v1 kind: Pod metadata: name: busybox spec: containers: - image: busybox command: - sleep - "1800" imagePullPolicy: IfNotPresent name: busybox

Config maps ideally stores application configuration in a plain text format whereas Secrets store sensitive data like password in an encrypted format. Both config maps and secrets can be used as volume and mounted inside a pod through a pod definition file. Config map: kubectl create configmap myconfigmap --from-literal=env=dev Secret: echo -n ‘admin' > ./username.txt echo -n ‘abcd1234' ./password.txt kubectl create secret generic mysecret --from-file=./username.txt --from-file=./password.txt

To perform maintenance on a Node, you first drain it using `kubectl drain --ignore-daemonsets` to safely evict all user Pods. After maintenance, you make it schedulable again with `kubectl uncordon `.

Labels are key/value pairs attached to objects (e.g. Pods). They help to organize Kubernetes objects. Selectors filter resources based on Labels. Here is an example Pod that has the labels environment: production and app: nginx : apiVersion: v1 kind: Pod metadata: name: my-pod labels: environment: production app: nginx spec: containers: - name: nginx-container image: nginx:1.21 ports: - containerPort: 80 You could now use the following label selector to fetch all Pods that have the label environment: pod assigned: kubectl get pods -l environment=production

The Heapster lets us do the container cluster monitoring. It lets us do cluster-wide monitoring and event data aggregation. It has native support for Kubernetes.

Node affinity rules use requiredDuringSchedulingIgnoredDuringExecution to schedule pods on specific nodes, while taints and tolerations prevent pods from scheduling on nodes unless they tolerate the taint.

Kubernetes container orchestration is the automated process of deploying, scaling, and managing containerized applications in a Kubernetes cluster.

Kubernetes Dashboard is a web-based user interface for managing and monitoring Kubernetes clusters.

A ReplicaSet ensures that a specified number of Pod replicas are running at any given time, but it lacks the ability to perform updates and rollbacks. A Deployment provides declarative updates for Pods and ReplicaSets. It manages ReplicaSets and allows for: - Rolling updates: Gradually replacing old Pods with new ones. - Rollbacks: Reverting to previous versions of a Deployment. - Scaling: Adjusting the number of replicas. - Pausing and resuming: Controlling the update process.

Kubernetes security starts by controlling access from end to end. First, you decide who can interact with the cluster. Then what workloads are allowed to be done. Finally, protecting the data that those workloads depend on. Everything begins at the API server. Every request is authenticated using client certificates, bearer tokens, or OIDC. After authentication, RBAC determines what actions an identity can perform. Pod security admission and pod security standards define what pods can do at runtime, such as preventing privileged containers or containers running as root. Network policies restrict how pods communicate with each other, limiting unnecessary internal traffic. Secrets store sensitive data like passwords and API keys. By default, they are only base64-encoded, so encryption at rest must be enabled inside etcd. All cluster communication runs over TLS, and etcd should never be directly accessible to workloads or users. Only the kube-apiserver should communicate with etcd over a secure channel. Many production environments also integrate external secret managers like HashiCorp Vault or AWS Secrets Manager for tighter control.

Kubernetes Persistent Volumes (PVs) provide persistent storage to cluster Pods. They store data outside of Pods so it persists after Pods are restarted or replaced. Persistent Volume Claims (PVCs) represent a request by a Pod to use storage provided by a PV. Therefore, PVs are the actual storage resources, whereas PVCs are Pod requests to use storage. PVCs are backed by PVs that can provide the PVC's requested storage capacity and access mode, such as ReadWriteOnce for single-Pod access, or ReadWriteMany for simultaneous access from many Pods.

Kubernetes Secrets are specifically designed to store sensitive information securely, such as passwords, OAuth tokens, and SSH keys, preventing them from being exposed in the environment.

Deployments for stateless apps, StatefulSets for apps needing persistent identity (databases), DaemonSets for cluster-wide agents (logging/monitoring).

Taints and tolerations are mechanisms used to control which nodes can schedule pods. Taints in Kubernetes mark nodes with characteristics that repel certain pods. Toleration allows pods to tolerate specific taints, enabling them to be scheduled on tainted nodes. Apply Taint to Node: kubectl taint nodes key=value:effect Define Pod with Toleration: apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: nginx tolerations: - key: "key" # Key of the taint operator: "Equal" # Operator to match the key-value pair (optional) value: "value" # Value of the taint (optional) effect: "NoSchedule" # Effect of the taint The different effects that can be associated with a taint: - NoSchedule: Pod will be scheduled if the toleration is not present. - PreferNoSchedule: No Gurrenty- Can schedule and Can not be scheduled - NoExecute: Delete the pod and schedule a new pod

To scale a deployment in Kubernetes, you can use the kubectl scale command or specify the desired number of replicas in the deployment's configuration file. For example, using kubectl : kubectl scale deployment --replicas= Alternatively, you can update the replicas field in the deployment YAML file and apply the changes: spec: replicas: Then apply the configuration with: kubectl apply -f .yaml Kubernetes will then ensure the desired number of Pod replicas are running.

Kubernetes ensures high availability by eliminating single points of failure at every layer, from the application down to the control plane itself. At the application layer, you run multiple replicas. If one pod crashes or a node goes down, Kubernetes reschedules workloads onto healthy nodes and creates replacements. Even during updates, old versions are replaced so the application stays available. At the control plane layer, multiple API servers run behind a load balancer so no single instance becomes a bottleneck. Etcd runs as a distributed cluster using quorum-based consensus, tolerating node failures as long as the majority of members are healthy. The scheduler and controller manager typically run multiple instances using leader election. One instance becomes the leader while others remain ready to take over if the leader fails. Spreading both the control plane and worker nodes across multiple availability zones protects against zone-level failures.

- Check the PVC status - Describe the PVC for errors - Verify the storage class - Check the underlying cloud storage. If using AWS, check EBS Attachments, and if using Azure, verify Azure Disk provisioning. - Inspect the pod logs for mount failures - Manually test volume mounting

A kubeconfig file resides on the machine where kubectl is installed. It holds the cluster endpoint and the credentials needed to authenticate. When you run a kubectl command, that is the first thing it reads. Without a valid endpoint and credentials, kubectl has no reference point. It wouldn't know which cluster to target or how to verify your identity.

Replica sets are a newer version that support a broader set of selectors for managing pods, whereas replication controllers were the earlier form of pod scaling and management in Kubernetes.

As all of us know that I.T. departments launch thousands of containers, with tasks running across a numerous number of nodes across the world in a distributed system. In such a situation the company can use something that offers them agility, scale-out capability, and DevOps practice to the cloud-based applications. So, the company can, therefore, use Kubernetes to customize their scheduling architecture and support multiple container formats. This makes it possible for the affinity between container tasks that gives greater efficiency with extensive support for various container networking solutions and container storage.

A readiness probe determines if a Pod is ready to receive traffic. If the probe fails, the Pod is removed from the load balancer until it becomes healthy again.

Core Concepts: Services, Ingress, and Network Policies provide different levels of network abstraction and control.

Prometheus is used for Kubernetes monitoring. The Prometheus ecosystem consists of multiple components. - Mainly Prometheus server which scrapes and stores time-series data. - Client libraries for instrumenting application code. - Push gateway for supporting short-lived jobs. - Special-purpose exporters for services like StatsD, HAProxy, Graphite, etc. - An alert manager to handle alerts on various support tools.

A node is a master or worker machine in Kubernetes. It can be a physical machine or a virtual machine. A node is a member of a Kubernetes cluster. Each node in a Kubernetes cluster is assigned a unique ID, which is used to identify the node when communicating with the Kubernetes API. When a new node is added to a Kubernetes cluster, the Kubernetes API is contacted to register the node with the cluster. The Kubernetes API stores information about the node, including its assigned ID, the addresses of the node's Kubernetes masters, and the labels assigned to the node. When a node is removed from a Kubernetes cluster, the Kubernetes API is contacted to unregister the node from the cluster. The Kubernetes API removes information about the node from its database, including the node's assigned ID, the addresses of the node's Kubernetes masters, and the labels assigned to the node.

Minikube is important because it allows you to have a local Kubernetes environment. Minikube is a single node Kubernetes environment that you can install on your laptop. This is important because it allows you to develop and test Kubernetes applications without having to deploy them to a cluster.

Storage in Kubernetes is decoupled into two objects to separate infrastructure management from application deployment. | Feature | Persistent Volume (PV) | Persistent Volume Claim (PVC) | |---| | Definition | A piece of physical/cloud storage provisioned by an administrator. | A request for storage made by a developer/user. | | Role | The actual storage resource (e.g., AWS EBS, NFS). | The “ticket” claiming a specific size and access mode from a PV. | | Lifecycle | Independent of any individual Pod. | Bound to a PV; destroyed or retained based on reclaim policy. |

Securing a Kubernetes cluster involves several layers and best practices: - Network Security: Implement network policies to control traffic flow between pods and services. Use firewalls and VPNs to secure communication between nodes. - Authentication and Authorization: Use Role-Based Access Control (RBAC) to enforce fine-grained access controls. Integrate with identity providers for centralized authentication. - Secrets Management: Store sensitive data in Kubernetes Secrets, encrypt secrets at rest, and use external secret management tools. - Audit Logging: Enable audit logging to monitor and record cluster activities, helping in identifying potential security incidents. - Pod Security Policies: Define and enforce security policies for pods, such as restricting privileged containers and ensuring read-only root file systems. - Regular Updates: Keep Kubernetes and its components up to date with the latest security patches and releases. - Image Security: Use trusted sources for container images, scan images for vulnerabilities, and enforce image policies.

A Pod in a CrashLoopBackOff state means its container is repeatedly crashing and restarting. To troubleshoot: - Describe the Pod using to check the container's last state and exit code. Exit code usually indicates an application error, while suggests it was killed due to exceeding memory limits (OOMKilled) - Check for incorrect CMD and missing binaries. - Check logs with to view the output from the previous container instance. This often reveals the root cause, such as missing files, misconfigurations, or runtime errors. - Verify configuration by inspecting environment variables, ConfigMaps, Secrets, and command-line arguments. Incorrect values or missing dependencies can cause startup failures. - Inspect probes especially liveness probes. Misconfigured probes can cause healthy containers to be restarted unnecessarily, leading to a crash loop.

Role-Based Access Control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In Kubernetes, RBAC allows you to control who can access the Kubernetes API and what permissions they have.

Role-Based Access Control (RBAC) in Kubernetes manages user and process permissions, defining who can access which resources and operations. It uses roles to define permissions and bindings to assign those roles to users or groups, enhancing security by ensuring only authorized access to cluster resources.

Kubernetes Secrets are used to manage sensitive information such as passwords, OAuth tokens, and SSH keys. Secrets are stored in the cluster and can be mounted as files or exposed as environment variables in Pods. They help to avoid exposing sensitive data in the Pod specification. - Types of Secrets: Opaque (default), Docker config, TLS, basic auth, and SSH auth. - Creating Secrets: Use kubectl create secret or define them in a YAML file. Example of creating a Secret:kubectl create secret generic mysecret --from-literal=username=myuser --from-literal=password=mypassword Example Secret YAML configuration: apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: bXl1c2Vy password: bXlwYXNzd29yZA== Mounting a Secret in a Pod: ```yaml apiVersion: v1 kind: Pod metadata: name: secret-pod spec: containers: - name: mycontainer image: nginx env: - name: USERNAME valueFrom: secretKeyRef: name: mysecret key: username - name: PASSWORD valueFrom: secretKeyRef: name: mysecret key: password ```

Both store configuration data you inject into Pods. A ConfigMap is for non-sensitive data like feature flags or database hostnames. A Secret is intended for sensitive data like passwords and API keys. Example ConfigMap: apiVersion: v1 kind: ConfigMap metadata: name: app-config data: database_host: "postgres.production.svc.cluster.local" log_level: "info" Example Secret: apiVersion: v1 kind: Secret metadata: name: app-secret type: Opaque data: db_password: cGFzc3dvcmQxMjM= # base64-encoded Kubernetes Secrets are base64-encoded by default, not encrypted. Without enabling encryption at rest and proper RBAC controls, Secrets can still be exposed to anyone with sufficient cluster access. However, they are still treated as sensitive resources and offer better access control and handling than ConfigMaps. Our Kubernetes Configuration and Production Readiness tutorial covers ConfigMaps and Secrets in depth with hands-on examples.

Kubernetes is an open-source platform designed to automate deploying, scaling, and operating application containers. It groups containers that make up an application into logical units for easy management and discovery.

There are multiple ways to check if the deployment running as expected. 1. Check if the deployment has been successfully rolled out. To check the rollout status, run the below command: kubectl rollout status deployment/ 2. Check the events related to the deployment. Run the following command to check the latest events of the namespace: kubectl get events -n --sort-by='.lastTimestamp' We can also get events related to a certain Pod that is not running using this command: kubectl get events -n | grep 3. Check the logs of the Pods that are not running as expected. If the Pod is in the CrashBackLoopOff state, then we can check its logs using this command. kubectl logs -n

Container orchestration is a process that involves managing and coordinating the deployment, scaling, and operation of multiple containers that run on a single server or across multiple servers. It automates container provisioning, networking, resource allocation, load balancing, availability, and lifecycle management tasks. Container orchestration tools, such as Kubernetes, Docker Swarm, and Apache Mesos, help ensure that containers work together seamlessly and efficiently to deliver the desired applications or services.

Performing maintenance activities on a Kubernetes (K8s) node requires careful planning and execution to minimize disruption to running applications and ensure the overall health and stability of the cluster. Here are the general steps to perform maintenance on a Kubernetes node: ``` kubectl drain –ignore-daemonsets ``` Replace `` with the name of the node you want to drain. ``` kubectl cordon ``` ``` kubectl uncordon ``` It's crucial to plan maintenance windows during low-traffic periods or periods of reduced load to minimize the impact on running applications. For critical production environments, consider using Kubernetes features like PodDisruptionBudgets and readiness probes to ensure high availability during maintenance activities. Always document your maintenance activities and follow best practices recommended by the Kubernetes community to maintain a stable and reliable cluster.

Here's a structured debugging approach to showcase your understanding of Kubernetes Network Policies (use commands). - Check existing network policies - Describe the network policy - Verify pod labels and selectors - Test connectivity between pods - Update the policy if needed

The candidate should talk about implementing resource requests and limits, utilizing Horizontal Pod Autoscalers, and monitoring with tools like Prometheus. They could also mention the use of Vertical Pod Autoscalers and PodDisruptionBudgets for more nuanced resource management and maintaining application performance. Important Points to Mention: - Resource requests and limits help ensure Pods are scheduled on nodes with adequate resources and prevent resource contention. - Horizontal Pod Autoscaler automatically adjusts the number of pod replicas based on observed CPU utilization or custom metrics. - Vertical Pod Autoscaler recommends or automatically adjusts requests and limits to optimize resource usage. - Monitoring tools like Prometheus are critical for identifying resource bottlenecks and inefficiencies. Example You Can Give: “For an application experiencing fluctuating traffic, we implemented Horizontal Pod Autoscalers based on custom metrics from Prometheus, targeting a specific number of requests per second per pod. This allowed us to automatically scale out during peak times and scale in during quieter periods, optimizing resource usage and maintaining performance. Additionally, we set resource requests and limits for each pod to ensure predictable scheduling and avoid resource contention.” Hedge Your Answer: “Resource optimization in Kubernetes is highly dependent on the specific characteristics of the workload and the underlying infrastructure. For instance, overly aggressive autoscaling can lead to rapid scaling events that may disrupt service stability. Similarly, improper configuration of resource requests and limits might either lead to inefficient resource utilization or Pods being evicted. Continuous monitoring and adjustment are essential to find the right balance.”

Deployments are used for stateless applications where pod identity doesn't matter. You can use it for web services, APIs, and microservices. StatefulSets is used for stateful applications (where pod identity and persistent storage are crucial, such as databases and message queues). Some ideal use cases include PostgreSQL and MySQL databases, Kafka, and Zookeeper. StatefulSets ensure: - Stable network identity (each pod gets a consistent hostname). - Ordered scaling and termination (pods start/stop sequentially). - Persistent storage via Persistent Volume Claims (PVCs).

The logs of the pods can be viewed using the following command: kubectl logs -n To tail and follow the logs, we can use the -f and --tail flags. kubectl logs --tail 100 -f -n

Kubernetes Ingress is an API object that defines rules for directing inbound traffic to Kubernetes services.

PodSecurityPolicy (PSP) was removed in Kubernetes v1.25. It's been replaced by Pod Security Admission (PSA), a built-in admission controller that enforces security standards at the Namespace level. PSA defines three profiles: - Privileged (unrestricted) - Baseline (prevents known privilege escalations) - Restricted (heavily locked down). apiVersion: v1 kind: Namespace metadata: name: production labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/warn: restricted Any Pod that doesn't meet the restricted standard will be rejected in this Namespace.

A Pod is the smallest deployable unit in Kubernetes. It represents one or more containers running in a shared environment. Containers inside a Pod share networking and storage resources. Here's a simple Pod definition YAML file: apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: nginx-container image: nginx:1.21 ports: - containerPort: 80

Kubernetes on-premises deployment is the deployment of Kubernetes clusters on private or enterprise servers and data centers.

Secrets can be mounted into Pods as volumes or exposed as environment variables, allowing applications to access sensitive data without exposing it directly.

In Kubernetes, a rolling update ensures your application is updated without downtime. This process carefully replaces old pods with new ones, employing a health check mechanism for a smooth transition. A rolling update involves several components, including the Replica Set, the Update Control Loop, the Pod Update Process, and Health Checking of pods. Here are their details: - Replica Set: Initiates the update by altering the pods it supervises. - Pod Lifecycle: Old pods gradually terminate while new ones start up according to the update strategy, such as maxUnavailable and maxSurge. - Readiness Probes: Each new pod is verified against its readiness to serve traffic, ensuring the application is live and responsive before the transition. - Liveness Probes: These checks confirm the stability of new pods. If a pod fails a liveness probe, it's terminated and replaced with a new version, maintaining application reliability. - Rolling Update Status status: Informs about the progress of the update. - Annotations from Provider: Kubernetes providers may supply additional insights, such as spec.rollingUpdate.strategy.

Ingress is an API object that manages external access (HTTP/HTTPS) to Services within a Kubernetes cluster. Unlike a standard LoadBalancer that operates at Layer 4 (IP/Port), an Ingress controller operates at Layer 7 (Application Layer). Key Benefits: - Path-Based Routing: Routes traffic based on URLs (e.g., example.com/api maps to Service A, example.com/web to Service B). - Host-Based Routing: Directs traffic based on specific subdomains. - SSL/TLS Termination: Manages SSL certificates centrally, offloading decryption work from backend Pods.

There are several types of volumes that can be used to persist and share data between containers in pods: - EmptyDir: - An EmptyDir volume is created when a pod is assigned to a node, and it exists as long as the pod is running on that node. - It is initially empty and is used to share data between containers in the same pod. - The data in an EmptyDir volume is lost when the pod is deleted or restarted. apiVersion: v1 kind: Pod metadata: name: emptydir-pod spec: containers: - name: nginx-container image: nginx volumeMounts: - name: shared-data mountPath: /data volumes: - name: shared-data emptyDir: {} 2. HostPath: - A HostPath volume mounts a file or directory from the host node's filesystem into the pod. - It allows pods to access files or directories on the node's filesystem. - HostPath volumes are not suitable for production use in multi-node clusters because they can lead to data inconsistency and security risks. apiVersion: v1 kind: Pod metadata: name: hostpath-pod spec: containers: - name: nginx-container image: nginx volumeMounts: - name: host-path mountPath: /host volumes: - name: host-path hostPath: path: /var/log 3. PersistentVolume (PV): PersistentVolume is like a storage area in a computer system that holds data even when the applications using it are turned off. So, even if your computer or application shuts down, the data in the PersistentVolume stays safe and sound until you need it again. apiVersion: v1 kind: PersistentVolume metadata: name: my-pv spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /mnt/data 4. PersistentVolumeClaim (PVC): When you create a PersistentVolumeClaim, you're basically asking the system for a certain amount of storage space to store your data or files. It's like saying, “Hey, I need this much storage, please give it to me.” Once the system approves your request, it finds an available PersistentVolume (the storage space) that matches your needs and assigns it to you. Then, you can use that space to store your data. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi 5. Amazon Elastic Kubernetes Service (EKS) EBS : apiVersion: v1 kind: PersistentVolume metadata: name: ebs-pv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce storageClassName: gp2 awsElasticBlockStore: volumeID: fsType: ext4 --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ebs-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi EFS: apiVersion: v1 kind: PersistentVolume metadata: name: efs-pv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteMany storageClassName: efs-sc nfs: server: path: / --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: efs-pvc spec: accessModes: - ReadWriteMany resources: requests: storage: 5Gi

Manage the deployment and scaling of a set of replica Pods. Types of Deployment Strategies: 1. Rolling Update Deployment: Default Strategies (To update a system without causing downtime) Updates by Replacing old instance with new one This creates a pod before deleting. 2. Recreate Deployment: This Terminate the instance and creates new ones This may lead to downtime 3. Blue-green Deployment: This maintains two identical production environment One active: Blue, One Inactive: Green This has zero downtime Provide easy rollback and safe environment for testing new version 4. Canary Deployment: Involves rolling out a new version to a small subset of users or instances first. By Monitoring metrics and user feedback, we can evaluate the performance of the new version in production with minimal impact before proceeding with the full rollout. 5. AB testing Deployment: Allow us to deploy multiple versions simultaneously and direct a portion of the traffic to each version. 6. Multicluster Deployment: For Redundancy, performance optimization, or Regulatory compliance We can orchestrate deployment across multiple Kubernetes clusters Eg : Kubernetes federation Gitops

Achieving High Availability (HA) in AKS requires multi-layered infrastructure planning: - Availability Zones (AZs): Distribute your worker nodes across multiple physical AZs to survive datacenter-level power or network failures. - Pod Anti-Affinity: Configure YAML rules to ensure replica Pods never schedule on the same exact node, preventing single points of failure. - Global Routing: Deploy replica AKS clusters across multiple geographic regions, routing user traffic via Azure Traffic Manager. - Node Auto-Repair: Enable this to let AKS automatically replace failing VMs. To avoid wasting resources, set limits on how much your applications can use. Use tools like KubeCost or Prometheus to track usage, remove anything that's not needed, and set up systems that adjust automatically based on demand.

Candidates should explain how service meshes provide observability, reliability, and security for microservices communication. They might discuss specific service meshes like Istio or Linkerd and describe features such as traffic management, service discovery, load balancing, mTLS, and circuit breaking. Important Points to Mention: - Enhanced observability into microservices interactions. - Traffic management capabilities for canary deployments and A/B testing. - mTLS for secure service-to-service communication. - Resilience patterns like circuit breakers and retries. Example You Can Give: “For a microservices architecture experiencing complex inter-service communication and reliability challenges, we implemented Istio as our service mesh. It allowed us to introduce canary deployments, gradually shifting traffic to new versions and monitoring for issues. Istio's mTLS feature also helped us secure communications without modifying service code. Additionally, we leveraged Istio's observability tools to gain insights into service dependencies and performance.” Hedge Your Answer: “Although service meshes add significant value in terms of security, observability, and reliability, they also introduce additional complexity and overhead to the Kubernetes environment. The decision to use a service mesh should be balanced with considerations regarding the current and future complexity of the application architecture, as well as the team's capacity to manage this complexity. Moreover, the benefits of a service mesh might be overkill for simpler applications or environments where Kubernetes' built-in capabilities suffice.”

A DaemonSet in Kubernetes is a functionality that enables the deployment of a Kubernetes pod on every cluster node that satisfies specific criteria. Whenever a new node is introduced to the cluster, the associated pod is automatically deployed to it. Conversely, when a node is removed from the cluster, the corresponding pod is also taken down.

Core Concepts: Rolling updates for Deployments and Pod disruption budgets during updates help maintain availability while updating.

A Custom Resource Definition (CRD) is a way to extend the Kubernetes API with your own resource types. Out of the box, Kubernetes knows about resources like Pods, Services, and Deployments. A CRD lets you define something entirely new, for example, a Database or Certificate resource, and Kubernetes will treat it like any other native resource. You can create, list, update, and delete instances of it using kubectl. On its own, a CRD just stores data in the API. It does not do anything until you pair it with a controller that watches for those resources and acts on them.

Kubernetes uses ConfigMaps for non-confidential data and Secrets for sensitive data, allowing for the separation of configuration artifacts from image content to keep containerized applications portable.

This architecture depends upon the application and many other factors. Following are the common logging patterns - Node level logging agent. - Streaming sidecar container. - Sidecar container with the logging agent. - Export logs directly from the application. In the setup, journalbeat and filebeat are running as daemonset. Logs collected by these are dumped to the kafka topic which is eventually dumped to the ELK stack. The same can be achieved using EFK stack and fluentd-bit.

- ReplicationController: Legacy controller (deprecated). - ReplicaSet: Newer version; supports set-based selectors. - Deployment: Manages ReplicaSets, provides rollouts and rollbacks.

Stateful applications require stable network identities, data persistence, and ordered scaling, which are challenges Kubernetes StatefulSets aim to address.

Kubernetes adopts a software-defined networking (SDN) approach to manage communication between pods. Each pod in the cluster is allocated a distinct IP address, facilitating inter-pod communication through standard network protocols like TCP and UDP. Upon pod creation, Kubernetes automatically generates a virtual network interface on the hosting node. This interface links to a virtual network that interconnects all pods within the cluster. This virtual network is layered on top of the underlying infrastructure network, utilizing overlay networking to ensure uniform network functionality across diverse environments. Beyond pod-to-pod communication, Kubernetes furnishes several functionalities for service discovery and load balancing. For instance, it assigns a virtual IP (VIP) to each service, enabling pods to access services consistently via an IP address, irrespective of the service's node. Moreover, Kubernetes employs an in-built load balancer to distribute incoming traffic across the pods supporting a service automatically.

Types of controller managers are: 1) endpoints controller, 2) service accounts controller, 3) node controller, 4) namespace controller, 5) replication controller, 6) token controller.

A Heapster is a cluster-wide aggregator of data that runs on each node. It is a Kubernetes project that provides a robust monitoring solution for Kubernetes clusters. Heapster is flexible and modular, making it easy to use and customize for different needs. However, Heapster has been deprecated since Kubernetes version 1.11. Its functionality has been replaced by the Kubernetes Metrics Server, which provides a more efficient and scalable way to collect and expose resource utilization data from Kubernetes nodes and pods.

Resource requests are used during Pod scheduling. Kubernetes ensures Pods are only scheduled to Nodes that can supply the requested amount of each resource, without impacting other workloads. Resource limits cap the maximum amount of a resource that a running Pod can use. Breaching a CPU limit can cause Pods to be throttled, for example, while breaching a memory limit makes Pods eligible for termination.

Following a custom resource is installed, users can create and access its objects using kubectl, just like they do for built-in resources like Pods. A custom resource is an extension of the Kubernetes API that is not always available in a default Kubernetes installation. However, many core Kubernetes functions are now built using custom resources, making Kubernetes more modular. Custom resources can come and go in a running the cluster through dynamic registration, and cluster admins can update custom resources independently of the cluster.

A sidecar is an additional container that runs alongside your main application container within the same pod. Because they share the same network namespace and can share storage volumes, the sidecar can complement the main container without the application needing to know about it. A prevailing use case is log collection. Your application writes logs to a shared volume, and a sidecar container running something like Fluentd or Filebeat reads from that volume and forwards the logs to a centralized system. The application itself does not need any logging library or integration. It just writes to disk, and the sidecar handles the rest.

The Kubernetes CNI is a specification that defines a standardized interface for integrating with container networking plugins.

A pod is the most basic Kubernetes object. A pod consists of a group of containers running in your cluster. Most commonly, a pod runs a single primary container.

kubectl is the command-line tool used to interact with a Kubernetes cluster.

K8s is simply shorthand for Kubernetes. The '8' represents the eight letters between the initial 'K' and the final 's' in the word Kubernetes.

You can update a running container's image seamlessly using the imperative kubectl set image command. This triggers a Zero-Downtime Rolling Update automatically. kubectl set image deployment/my-deployment nginx=nginx:1.17 Alternatively, you can edit the live configuration directly in your terminal using your default text editor (like Vim) by running: kubectl edit deployment my-deployment While these imperative commands are excellent for quick troubleshooting or hotfixes, modern DevOps best practices dictate updating the image tag directly in your version-controlled Git repository and letting a GitOps tool apply the change declaratively.

Show your understanding of diverse workloads by discussing these top K8s use cases: - Microservices architectures (e.g., REST APIs, GraphQL services) - Event-driven applications (Kafka consumers, message queues) - Machine learning workloads (TensorFlow Serving, Jupyter notebooks) - CI/CD pipelines (GitHub Actions runners, Jenkins agents) - Data processing workloads (Spark, Flink, Airflow) - Multi-cloud/hybrid workloads needing portability

A load balancer is one of the most common and standard ways of exposing service. There are two types of load balancer used based on the working environment i.e. either the Internal Load Balancer or the External Load Balancer. The Internal Load Balancer automatically balances load and allocates the pods with the required configuration whereas the External Load Balancer directs the traffic from the external load to the backend pods. Related Readings: Kubernetes Networking and Services

Both store configuration data you inject into Pods. A ConfigMap is for non-sensitive data like feature flags or database hostnames. A Secret is intended for sensitive data like passwords and API keys. Example ConfigMap: apiVersion: v1 kind: ConfigMap metadata: name: app-config data: database_host: "postgres.production.svc.cluster.local" log_level: "info" Example Secret: apiVersion: v1 kind: Secret metadata: name: app-secret type: Opaque data: db_password: cGFzc3dvcmQxMjM= # base64-encoded Kubernetes Secrets are base64-encoded by default, not encrypted. Without enabling encryption at rest and proper RBAC controls, Secrets can still be exposed to anyone with sufficient cluster access. However, they are still treated as sensitive resources and offer better access control and handling than ConfigMaps.

These include: - Role-Based Access Control (RBAC) to manage permissions more efficiently - Network policies to restrict pod-to-pod communication - Pod Security Standards (PSS) to enforce best practices like non-root containers - Secrets management via Kubernetes Secrets, external vaults like HashiCorp Vault - Image scanning with tools like Trivy or Anchore - Pod security policies and admission controllers for pre-deployment checks

Ingress is an API object that manages external access to services within a Kubernetes cluster. It acts as a traffic controller, directing incoming requests to the appropriate services based on rules and configurations. Ingress enables the implementation of features like SSL termination, load balancing, and path-based routing.

Kubernetes performs a rolling update by gradually upgrading the replicas of a pod, ensuring that the application remains available and responsive during the update.

It controls and manages the worker nodes. It makes up the control plane of a cluster and is responsible for scheduling tasks and monitoring the state of the cluster. The master node has several components, such as Kube-APIServer, Kube-Controller-manager, Etcd, and Kube-Scheduler, to help manage worker nodes.

Pods are referred to as the smallest unit of the execution in Kubernetes and are comprised of one or more containers with one or more applications and binaries. Nodes are referred to as physical servers or virtual machines that comprise of Kubernetes cluster.

Zero-downtime Deployments ensure that updates do not interrupt live traffic. Kubernetes achieves that using: - Rolling updates (default, gradually replacing old Pods with new ones). - Canary deployments (testing with a subset of users). - Blue-green deployments (switching between production and test environments). Readiness probes help Kubernetes avoid traffic being sent to unready Pods.

Bonus question for practice. Steps include checking CoreDNS pods, verifying DNS configurations, testing DNS resolution with tools like nslookup, and examining network policies.

ConfigMaps are Kubernetes resources used to store configuration data in key-value pairs, which can be consumed by Pods as environment variables or mounted as volumes.

Horizontal Pod Autoscaling automatically adjusts the number of pods in a deployment or replication controller based on observed CPU utilization or custom metrics provided.

The role of Load Balancing in Kubernetes is to distribute incoming network traffic across multiple instances of a service or a set of Pods that are part of a Kubernetes Deployment or ReplicaSet. Load balancing ensures that each instance or Pod receives a fair share of requests, optimizing resource utilization and providing high availability for applications. Here's how load balancing works in Kubernetes: Overall, load balancing in Kubernetes ensures that applications are efficiently distributed across the available Pods, that they remain highly available, and that traffic is managed effectively as the cluster scales or undergoes updates. This enhances the overall performance, reliability, and scalability of applications running in a Kubernetes cluster.

Google Kubernetes Engine (GKE) is a fully managed Kubernetes service designed for running containers and container clusters on the infrastructure of Google Cloud. Built upon Kubernetes, which is an open-source platform for container management and orchestration developed by Google, GKE streamlines the deployment and operation of containerized applications.

A CronJob is a specialized Kubernetes Job that runs on a scheduled basis. CronJobs use cron syntax to define the schedule and are used for periodic tasks such as backups, report generation, and cleanup operations. Example CronJob configuration: apiVersion: batch/v1beta1 kind: CronJob metadata: name: example-cronjob spec: schedule: "0 0 * * *" # Runs at midnight every day jobTemplate: spec: template: spec: containers: - name: example image: busybox args: - /bin/sh - -c - "echo Hello, Kubernetes!" restartPolicy: OnFailure

A Custom Resource Definition (CRD) is used to create new Kubernetes resources unavailable in the Kubernetes core. It is a way of extending Kubernetes functionality by defining custom resources that can be used to create Kubernetes objects, such as pods, services, and deployments. Custom resources can represent any Kubernetes object type and can be used to create custom controllers that programmatically manage these resources. For example, you can create a CRD for a custom application load balancer and then use a custom controller to manage the load balancer. In summary, a Kubernetes CRD allows you to create custom resources that extend Kubernetes functionality beyond its core features. You can use custom resources to create custom controllers that manage these resources programmatically.

Kube-Proxy refers to network proxy and it runs on each node within a k8 cluster. It takes care of maintaining the connectivity between the pods and services. It does this by the translation of the service definitions into networking rules.

Bonus question for practice. Check HPA metrics and configuration, verify resource requests/limits, review deployment events, and ensure there are no constraints like PodDisruptionBudgets.

The node port service is a fundamental way to get external traffic to your service. It opens a particular port on all nodes and forwards network traffic sent to this port.

Operators extend Kubernetes functionality by combining Custom Resource Definitions (CRDs) with custom controllers that implement domain-specific logic: Custom Resource (Desired State) → Controller (Reconciliation Logic) → Kubernetes Resources (Actual State) Design Philosophy Declarative API Design: Users describe what they want (desired state) rather than how to achieve it (imperative commands). Controller Pattern: Continuously observe the current state and take actions to make it match the desired state. Kubernetes-Native Integration: Leverage existing Kubernetes primitives and patterns for consistency and reliability. CRD Design Principles 1. Resource Modeling Define clear abstractions that map to your domain: apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: webapps.example.com spec: group: example.com versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: # Desired state type: object properties: replicas: type: integer minimum: 1 maximum: 10 image: type: string database: type: object properties: host: type: string port: type: integer required: ["host", "port"] required: ["replicas", "image", "database"] status: # Observed state type: object properties: ready: type: boolean replicas: type: integer conditions: type: array items: type: object properties: type: type: string status: type: string lastTransitionTime: type: string format: date-time reason: type: string message: type: string Key design elements: - spec: User-defined desired state with validation constraints - status: Controller-managed observed state and conditions - Validation: OpenAPI schema ensures data integrity - Versioning: Support for API evolution and backward compatibility 2. Status and Conditions Design Follow Kubernetes conventions for status reporting: status: ready: true replicas: 3 conditions: - type: "Available" status: "True" lastTransitionTime: "2023-10-01T10:00:00Z" reason: "MinimumReplicasAvailable" message: "Deployment has minimum availability" - type: "Progressing" status: "True" lastTransitionTime: "2023-10-01T10:00:00Z" reason: "NewReplicaSetAvailable" message: "ReplicaSet has successfully progressed" Controller Logic Design 1. Reconciliation Loop Pattern func (r *WebAppReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { // 1. Fetch the custom resource webapp := &webappv1.WebApp{} err := r.Get(ctx, req.NamespacedName, webapp) if err != nil { return ctrl.Result{}, client.IgnoreNotFound(err) } // 2. Determine desired state from spec desiredDeployment := r.buildDeployment(webapp) desiredService := r.buildService(webapp) // 3. Get current state currentDeployment := &appsv1.Deployment{} err = r.Get(ctx, types.NamespacedName{Name: webapp.Name, Namespace: webapp.Namespace}, currentDeployment) // 4. Reconcile differences if errors.IsNotFound(err) { // Create new deployment err = r.Create(ctx, desiredDeployment) } else if err == nil { // Update existing deployment if needed if !r.deploymentEqual(currentDeployment, desiredDeployment) { err = r.Update(ctx, desiredDeployment) } } // 5. Update status based on current state r.updateStatus(ctx, webapp) // 6. Return reconciliation result return ctrl.Result{RequeueAfter: time.Minute * 5}, nil } Key reconciliation principles: - Idempotency: Multiple reconciliations should have the same effect - Error handling: Distinguish between retriable and permanent errors - Status updates: Always reflect current observed state - Requeue strategy: Balance responsiveness with resource usage 2. Owner References for Resource Management // Set owner reference for garbage collection err = ctrl.SetControllerReference(webapp, deployment, r.Scheme) if err != nil { return ctrl.Result{}, err } Benefits of owner references: - Automatic cleanup when custom resource is deleted - Clear resource ownership hierarchy - Prevents orphaned resources Advanced Controller Patterns 1. Multi-Resource Coordination Complex applications often require coordinating multiple Kubernetes resources: func (r *WebAppReconciler) reconcileDatabase(ctx context.Context, webapp *webappv1.WebApp) error { // Create database secret secret := r.buildDatabaseSecret(webapp) err := r.reconcileResource(ctx, secret) if err != nil { return err } // Create database deployment deployment := r.buildDatabaseDeployment(webapp) err = r.reconcileResource(ctx, deployment) if err != nil { return err } // Create database service service := r.buildDatabaseService(webapp) return r.reconcileResource(ctx, service) } 2. Condition-Based State Management func (r *WebAppReconciler) updateStatus(ctx context.Context, webapp *webappv1.WebApp) error { // Check deployment readiness deployment := &appsv1.Deployment{} err := r.Get(ctx, types.NamespacedName{Name: webapp.Name, Namespace: webapp.Namespace}, deployment) if err != nil { // Deployment not found - update condition r.setCondition(webapp, "Available", metav1.ConditionFalse, "DeploymentNotFound", "Deployment does not exist") } else if deployment.Status.ReadyReplicas == *deployment.Spec.Replicas { // Deployment ready r.setCondition(webapp, "Available", metav1.ConditionTrue, "MinimumReplicasAvailable", "All replicas are ready") webapp.Status.Ready = true } else { // Deployment not ready r.setCondition(webapp, "Available", metav1.ConditionFalse, "InsufficientReplicas", "Not all replicas are ready") webapp.Status.Ready = false } return r.Status().Update(ctx, webapp) } Error Handling and Reliability 1. Retry Strategy func (r *WebAppReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { // ... reconciliation logic ... if err != nil { // Classify error type if isRetriableError(err) { // Exponential backoff for retriable errors return ctrl.Result{RequeueAfter: calculateBackoff(req)}, nil } else { // Log permanent errors but don't retry r.Log.Error(err, "Permanent error during reconciliation") return ctrl.Result{}, nil } } return ctrl.Result{RequeueAfter: time.Minute * 5}, nil } 2. Event Recording // Record events for user visibility r.Recorder.Event(webapp, "Normal", "Created", "Successfully created deployment") r.Recorder.Event(webapp, "Warning", "Failed", "Failed to create service") Testing Strategy 1. Unit Testing Controller Logic func TestWebAppReconciler_Reconcile(t *testing.T) { // Setup test environment scheme := runtime.NewScheme() _ = webappv1.AddToScheme(scheme) _ = appsv1.AddToScheme(scheme) client := fake.NewClientBuilder().WithScheme(scheme).Build() reconciler := &WebAppReconciler{ Client: client, Scheme: scheme, } // Create test custom resource webapp := &webappv1.WebApp{ ObjectMeta: metav1.ObjectMeta{ Name: "test-webapp", Namespace: "default", }, Spec: webappv1.WebAppSpec{ Replicas: 3, Image: "nginx:latest", }, } // Test reconciliation _, err := reconciler.Reconcile(context.TODO(), ctrl.Request{ NamespacedName: types.NamespacedName{ Name: "test-webapp", Namespace: "default", }, }) assert.NoError(t, err) // Verify expected resources were created deployment := &appsv1.Deployment{} err = client.Get(context.TODO(), types.NamespacedName{Name: "test-webapp", Namespace: "default"}, deployment) assert.NoError(t, err) assert.Equal(t, int32(3), *deployment.Spec.Replicas) } 2. Integration Testing Test operators in real Kubernetes environments using frameworks like: - Ginkgo/Gomega: BDD-style testing framework - envtest: Lightweight Kubernetes API server for testing - Kind/minikube: Full cluster testing environments Operational Considerations 1. Metrics and Monitoring Implement controller-specific metrics: - Reconciliation duration and frequency - Error rates and types - Custom resource creation/update/deletion rates - Resource drift detection 2. Security and RBAC Define minimal required permissions: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: webapp-operator rules: - apiGroups: ["example.com"] resources: ["webapps"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: [""] resources: ["services", "secrets"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] Security principles: - Grant only necessary permissions - Use namespace-scoped roles when possible - Regular security audits and permission reviews

A NodePort exposes a service on a static port (30000–32767) on each node's IP, making it accessible externally. It is handy for debugging but less flexible than LoadBalancer or Ingress, which provide better external access control. Meanwhile, a Service Port is the internal port on which the service forwards traffic to pods.

Helm utilizes a packaging format called charts, which are collection of files which describe the cohesive set of Kubernetes resources. Whether you are deploying a simple component, like a memcached pod, or a complex web app stack which involves HTTP servers, databases, caches, and more, all the files you need are contained in a single chart. Helm chart packages provide all the resources you need to deploy an application to a Kubernetes cluster, which involves YAML configuration files for secrets, services, deployments, and config maps that provide the app's desired state.

A Kubernetes context is a group of access parameters that has a cluster, a user, and a namespace. The current context is the cluster that is currently the default for kubectl, and all kubectl commands run against that cluster.

Definitely yes. To meet these requirements, this company may need a platform that can offer digital experience to millions of clients. Kubernetes is one such platform, it can easily get data to the client websites. In order to use this platform, they have to adopt cloud environments such as AWS. Additionally, they also need to implement micro service architecture that enables them to use Docker containers. After these processes, they can leverage the benefits of this platform, which make them autonomous in creating and deploying applications. It also improves their scalability and response.

A Kubernetes ConfigMap is an object used to store configuration data that a pod or container can consume. On the other hand, a Kubernetes Secret is used to store sensitive information, such as a password or API key.

Kube-proxy is a daemon that runs on each Kubernetes node. It is responsible for proxying pod IPs and service IPs to the correct pods and services. Kube-proxy is started automatically by Kubernetes. Kubernetes also uses kube-proxy to load balance services.

Kubernetes is a platform for managing containerized stateless or stateful applications across a cluster of nodes. Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery. Kubernetes also automates the replication of the containers across multiple nodes in a cluster, as well as healing of failed containers. Kubernetes was originally designed by Google, and is now maintained by the Cloud Native Computing Foundation. Some of the key features of Kubernetes include: – Provisioning and managing containers across multiple hosts – Scheduling and deploying containers – Orchestrating containers as part of a larger application – Automated rollouts and rollbacks – Handling container health and failure – Scaling containers up and down as needed – It has a large and active community that develops new features and supports users. – It has a variety of tools for managing storage and networking for containers.

Labels are key/value pairs attached to objects, such as pods, which are used to organize and select subsets of objects. Selectors are queries that match labels and are used to determine the objects that a particular service or deployment applies to. This mechanism allows flexible and powerful grouping of related resources.

This often comes in the form of "tell me about Istio or Linkerd" or "why would you use a service mesh?" The interviewer is trying to understand whether you know the actual use case for a service mesh and can articulate when it is and is not worth the added complexity. A service mesh itself is simply a dedicated infrastructure layer that manages communication between services within your cluster. It works by deploying a proxy (typically Envoy) as a sidecar alongside each pod. These proxies handle all network traffic between services, giving you a consistent way to apply policies and observe communication without modifying application code. The capabilities a service mesh provides include: Historically, service meshes gained traction because ingress controllers lacked many of these features natively. If you needed traffic splitting, mutual TLS between internal services, or detailed observability, a mesh was often the only practical option. However, with the Gateway API maturing and supporting features like traffic splitting, header-based routing, and cross-namespace routing out of the box, the justification for adopting a mesh purely for traffic management is harder to make than it used to be. The Gateway API covers a growing portion of what teams previously needed a mesh for. Where a service mesh still holds clear value is in mTLS enforcement across all service-to-service communication and deep observability at the network layer. If your organization has strict security requirements around encryption in transit or you need granular visibility into how services communicate, a mesh addresses those needs in a way that the Gateway API does not.

Both are controllers that ensure a specified number of Pod replicas are running at any given time. However, the Replication Controller is a legacy technology, while the ReplicaSet is the modern standard used under the hood by Kubernetes Deployments. | Feature | ReplicaSet (Modern) | Replication Controller (Legacy) | |---| | Selector Type | Supports Set-based selectors (e.g., environment in (prod, qa)). | Supports only Equality-based selectors (e.g., environment = prod). | | Usage | Managed automatically by Deployments. | Managed directly by the user. | | Recommendation | The current industry standard. | Deprecated; avoid using in modern clusters. |

To regulate access to the Kubernetes cluster, you can use Role-Based Access Control (RBAC) to define fine-grained access policies. RBAC allows you to specify what actions are allowed and denied for different users and service accounts within the cluster. You can create roles and role bindings to grant permissions to specific resources, such as pods, services, and deployments. Additionally, you can leverage network policies to control traffic flow between pods and define which pods are allowed to communicate with each other. Regularly reviewing and updating access control policies is important to maintain a secure Kubernetes cluster.

Federated clusters (often managed via KubeFed) allow you to coordinate and manage multiple distinct Kubernetes clusters as a single, unified entity from one API endpoint.

Pods are the smallest deployable units in Kubernetes, consisting of one or more containers that share resources such as networking and storage.

You can approach the problem using the following steps: 1. Check Pod resource utilization. Increase resources in case they are at their limits. kubectl top pods --sort-by=cpu kubectl top pods --sort-by=memory 2. Describe the slow Pod to get more information. Look for resource throttling, restart counts, or liveness probe failures. kubectl describe pod 3. Check container logs for errors. Look for timeouts, errors, or connection failures. kubectl logs 4. Test network latency, as they can slow down applications. kubectl exec -it -- ping my-database kubectl exec -it -- curl http://my-service 5. Verify Kubernetes node health and check for resource exhaustion on nodes. kubectl get nodes kubectl describe node

Kubernetes is more feature-rich, offering stronger auto-scaling, rolling updates, and maintaining complex, large-scale applications. Docker Swarm is simpler to deploy and manage but less flexible in large-scale environments.

This question tests whether you understand the gap between running containers on a single machine and running them reliably in production. Anyone can do docker run. The interviewer wants to know why that stops being enough. When you run containers at scale, you quickly run into problems that a container runtime alone does not handle. Kubernetes exists to fill that gap. Specifically, it takes care of:

Kubectl is a command line tool (CLI) that you can use to interact with Kubernetes API servers from a terminal. Kubectl = Kube Control CLI.

Developers should have to detect the issue has risen. They can do it by evaluating the system components like Kube-proxy, Kubelet and pod statuses. In order to bring back the healthy state of the cluster, we have to recover or restart failed components.

Crucial Kubectl commands: kubectl create, kubectl get, kubectl apply, kubectl delete, and kubectl describe.

To monitor the core health of your Kubernetes cluster, you can use several kubectl commands. The most fundamental is kubectl get nodes, which verifies if all worker and master nodes are in a Ready state. For a broader system overview, kubectl cluster-info displays the health and addresses of the master and essential services like CoreDNS. Additionally, running kubectl get pods -n kube-system allows you to inspect the status of critical control plane components (like the API server and etcd) to ensure no underlying system crashes are occurring.

In Kubernetes, achieving data persistence is essential for ensuring that data survives pod restarts, scaling, or updates. There are several strategies to achieve data persistence: Persistent Volumes (PVs) and Persistent Volume Claims (PVCs): Kubernetes provides PVs and PVCs as abstractions for managing storage resources. PVs represent physical storage volumes, while PVCs are requests for storage by pods. By defining PVCs and associating them with pods, you ensure that the data stored in these volumes remains intact even if the pod is rescheduled to a different node. StatefulSets: StatefulSets are a specialized controller for managing stateful applications in Kubernetes. They ensure that pods are created and scaled in a predictable manner, with stable network identities and ordered deployment. StatefulSets can be used in conjunction with PVCs to manage data persistence for stateful applications. Distributed Storage Solutions: Kubernetes also supports various distributed storage solutions, such as Network File Systems (NFS), Ceph, and GlusterFS, which can be integrated into your cluster to provide scalable and resilient data storage. These solutions allow you to create persistent volumes that can be accessed by multiple pods simultaneously. By leveraging these Kubernetes features and storage options, you can achieve data persistence, ensuring that your applications can reliably store and retrieve data, even in dynamic and containerized environments.

Here is the Kubernetes YAML configuration: apiVersion: v1 kind: Service metadata: name: my-service namespace: test-ns spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 --- apiVersion: v1 kind: Pod metadata: name: dns-example namespace: test-ns spec: containers: - name: test image: your-image command: [ "nslookup", "my-service" ]

apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp type: Frontend ports: - protocol: TCP port: 80 targetPort: 9376 Here, the Service 'my-service' selects all the Pods with labels app=MyApp and type=Frontend and forwards the traffic on the port 80 to the targetPort 9376.

A sidecar container runs alongside the main application container inside the same Pod. It is commonly used for: - Logging and monitoring (e.g. collecting logs with Fluentd). - Security proxies (e.g. running Istio's Envoy proxy for service mesh). - Configuration management (e.g. syncing application settings). Example sidecar container for log processing: apiVersion: v1 kind: Pod metadata: name: app-with-sidecar spec: containers: - name: main-app image: my-app volumeMounts: - mountPath: /var/log name: shared-logs - name: log-collector image: fluentd volumeMounts: - mountPath: /var/log name: shared-logs volumes: - name: shared-logs emptyDir: {} The sidecar container runs Fluentd, which collects logs from the main container via a shared volume.

Implementing Kubernetes enables more scalable platforms through its container orchestration capabilities. This allows for easy scaling up or down based on demand, better resource management, and continuous deployment practices.

A Helm Chart is a collection of all components needed to deploy an application on Kubernetes; it contains YAML files that define the deployments, services and configuration. It facilitates easy application deployment and is regularly utilized in CI/CD pipelines to allow versioned and repeatable deployments.

Pods can get stuck in states like CrashLoopBackOff, Pending, or ImagePullBackOff. Here is how you recognize and fix them. CrashLoopBackOff means the container keeps crashing. Kubernetes restarts it but backs off after repeated failures. Check the logs with kubectl logs and look for missing environment variables, dependency failures, or incorrect startup commands. Pending means Kubernetes cannot schedule the pod. Usually, insufficient CPU or memory, missing PersistentVolumes, or taints blocking scheduling. Run kubectl describe pod to see exactly why the pod has not been assigned to a node. ImagePullBackOff means Kubernetes cannot pull the container image. Caused by wrong image name, authentication issues with a private registry, or network problems. kubectl describe pod will tell you why.

To view the logs of a specific pod in Kubernetes, you can use the kubectl logs command. Syntax: kubectl logs

The control plane manages the cluster's state. Each component has a specific role: - The API server is the front door, every kubectl command and internal request goes through it. etcd is the key-value store that holds all cluster state. - The scheduler assigns newly created Pods to nodes based on resource availability. - The controller manager runs reconciliation loops that watch cluster state and make corrections, for instance, ensuring the right number of Pod replicas are running. In cloud-managed clusters (EKS, GKE, AKS), you'll also see the cloud-controller-manager, which integrates with the cloud provider's APIs for load balancers and storage. You can inspect many control plane-related Pods and cluster system components with: kubectl get pods -n kube-system

Service meshes introduce a sidecar proxy (typically Envoy) alongside each application container. This architecture provides powerful capabilities but comes with resource overhead: Application Container (Your App) + Sidecar Container (Envoy Proxy) ↓ All network traffic flows through the sidecar proxy Resource Consumption Analysis Common Resource Usage Patterns: Memory Consumption: - Configuration cache (routes, clusters, listeners) - Connection pools and buffers - TLS certificate storage - Metrics and tracing data CPU Consumption: - Traffic proxying and load balancing - TLS termination and encryption - Metrics collection and aggregation - Configuration updates and reloads Diagnostic Approach 1. Resource Usage Profiling Analyze current resource consumption patterns: # Compare resource usage between app and sidecar kubectl top pod --containers | grep -E "(app|istio-proxy)" # Detailed resource analysis kubectl describe pod | grep -A 10 "Requests|Limits" 2. Envoy Admin Interface Analysis Access Envoy's admin interface for detailed metrics: # Port forward to Envoy admin port kubectl port-forward 15000:15000 # Key endpoints for analysis: curl localhost:15000/stats/prometheus # Detailed metrics curl localhost:15000/memory # Memory usage breakdown curl localhost:15000/config_dump # Configuration analysis Critical metrics to analyze: envoy_server_memory_allocated: Current memory usage envoy_server_live_cluster_count: Number of service endpoints envoy_http_downstream_cx_active: Active connections envoy_cluster_assignment_stale: Configuration staleness Optimization Strategies 1. Right-Sizing Sidecar Resources Default vs Optimized Configuration: # Default Istio sidecar resources (often over-provisioned) resources: requests: cpu: 100m # Often too high for low-traffic services memory: 128Mi # Can be reduced for simple applications limits: cpu: 2000m # Usually excessive memory: 1024Mi # Can cause OOM for memory-intensive configs # Optimized configuration for low-traffic services resources: requests: cpu: 10m # Reduced for low-traffic patterns memory: 40Mi # Minimal memory footprint limits: cpu: 200m # Reasonable upper bound memory: 256Mi # Adequate for most scenarios Application-Specific Optimization: # Pod annotation for sidecar resource tuning metadata: annotations: sidecar.istio.io/proxyCPU: "10m" sidecar.istio.io/proxyMemory: "64Mi" sidecar.istio.io/proxyCPULimit: "100m" sidecar.istio.io/proxyMemoryLimit: "128Mi" 2. Feature-Based Optimization Disable Unnecessary Features: # Disable tracing for non-critical services metadata: annotations: sidecar.istio.io/inject: "true" traffic.sidecar.istio.io/includeInboundPorts: "8080" traffic.sidecar.istio.io/excludeOutboundPorts: "3306,6379" # Database connections Selective Mesh Participation: # Exclude services that don't need mesh features metadata: annotations: sidecar.istio.io/inject: "false" # Disable for background jobs Use cases for mesh exclusion: - Batch processing jobs - Database instances - Monitoring and logging services - Internal tooling and maintenance pods 3. Configuration Optimization Reduce Configuration Scope: # Sidecar resource for limiting configuration scope apiVersion: networking.istio.io/v1beta1 kind: Sidecar metadata: name: default namespace: production spec: egress: - hosts: - "./production/*" # Only same-namespace services - "istio-system/*" # System services # Excludes all other namespaces, reducing config size Benefits of scoped configuration: - Reduced memory footprint - Faster configuration updates - Improved startup times - Better security isolation Performance Tuning 1. Connection Pool Optimization apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: circuit-breaker spec: host: backend-service trafficPolicy: connectionPool: tcp: maxConnections: 10 # Limit concurrent connections connectTimeout: 30s # Connection timeout keepAlive: time: 7200s # Keep-alive time interval: 75s # Keep-alive probe interval http: http1MaxPendingRequests: 10 # Queue limit http2MaxRequests: 100 # Concurrent HTTP/2 requests maxRequestsPerConnection: 2 # Requests per connection maxRetries: 3 # Retry limit 2. Circuit Breaker Configuration trafficPolicy: outlierDetection: consecutiveErrors: 5 # Errors before ejection interval: 30s # Analysis interval baseEjectionTime: 30s # Minimum ejection time maxEjectionPercent: 50 # Maximum percentage ejected Monitoring and Alerting 1. Resource Usage Monitoring Key metrics to track: - Sidecar CPU and memory utilization - Configuration size and update frequency - Connection pool usage and efficiency - Request latency and error rates 2. Cost Analysis Calculate the total cost of service mesh overhead: - Sidecar resource consumption vs application resources - Network latency impact - Operational complexity overhead - Security and observability benefits Alternative Architectures 1. Ambient Mesh (Istio) - Reduces per-pod resource overhead - Shared proxy infrastructure - Suitable for high-density deployments 2. Gateway-Only Pattern - Service mesh features only at ingress/egress - Reduced internal network overhead - Simplified internal service communication 3. Selective Mesh Adoption - Apply service mesh only to critical communication paths - Hybrid architecture with selective sidecar injection - Cost-benefit analysis for each service Production Best Practices 1. Gradual Optimization - Start with default configurations - Monitor and measure actual usage patterns - Iteratively optimize based on real data - Validate performance impact of changes 2. Testing Strategy - Load testing with realistic traffic patterns - Chaos engineering to test resilience - Performance regression testing - Cost monitoring and optimization 3. Capacity Planning - Account for mesh overhead in cluster sizing - Plan for configuration update scenarios - Consider mesh version upgrade impacts - Monitor resource utilization trends

A senior engineer should demonstrate awareness of Kubernetes' evolving landscape, mentioning resources like the official Kubernetes blog, SIG meetings, KEPs (Kubernetes Enhancement Proposals), and community forums. They might also discuss significant changes in recent releases or upcoming features that could impact how clusters are managed.

kubectl exec works when the container has a shell and the debugging tools you need. But many production images are minimal or distroless — they don't include sh , curl , or nslookup . kubectl debug solves this by attaching an ephemeral container to a running Pod. The ephemeral container shares the Pod's network and process namespace, so you can inspect everything without modifying the original image. # Attach a debug container to a running Pod kubectl debug -it --image=busybox --target=app # Create a copy of the Pod with a debug container (doesn't affect the original) kubectl debug --copy-to=debug-pod --image=ubuntu --share-processes Use kubectl exec when the container already has the tools you need. Use kubectl debug when it doesn't, or when you don't want to risk disrupting a running container by installing packages inside it.

ReadWriteMany allows multiple nodes to read from and write to the volume, supporting the need for multiple pods in different nodes to access and update shared data consistently.

Ingress network manages external access to the services in a cluster, typically HTTP. It can provide load balancing, SSL termination, and name-based virtual hosting.

Core Components: Secrets and ConfigMaps are different types of objects used to centrally manage application configuration and secrets.

Kubernetes automatically load balances traffic between the Pods selected by a service. In the case of ClusterIP services, only the cluster-internal networking layer is involved. Traffic to the Service is directed to any of the available Pods, on any available Node. In comparison, LoadBalancer services also involve an external load balancer. This service type provisions a load balancer in your cloud account, using your cluster's active cloud provider integration. Traffic to the load balancer's public IP address is then automatically routed into the cluster's networking layer. The traffic's onward routing to a matching Pod is handled internally, in the same way as a ClusterIP service.

The mapping between persistent volume and persistent volume claim is always one-to-one. Even When you delete the claim, PersistentVolume still remains as we set persistentVolumeReclaimPolicy is set to Retain and Any other claims will not reuse it. Below is the spec to create the Persistent Volume. apiVersion: v1 kind: PersistentVolume metadata: name: mypv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain

Kubelet is a daemon on each node that runs on each Kubernetes node. Kubelet is responsible for communicating with the API server to get information about the state of the nodes and pods in the cluster, and for pulling and pushing images to and from the nodes.

Core Concepts: Horizontal Pod Autoscaler (HPA) dynamically scales the number of replica Pods in a Deployment, ReplicaSet, or StatefulSet. Cluster autoscaler scales underlying infrastructure, including nodes.

High availability requires planning at multiple levels: - Run multiple control plane nodes (three or five) so the cluster survives node failures - Enable the Cluster Autoscaler to add/remove worker nodes based on demand - Use Pod Disruption Budgets to maintain minimum availability during upgrades - Spread replicas across nodes using anti-affinity rules apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: my-app-pdb spec: minAvailable: 2 selector: matchLabels: app: my-app This ensures that at least two Pods remain running during voluntary disruptions, such as node drains.

While both Docker Swarm and Kubernetes are container orchestration platforms, they have distinct differences: - Ease of Setup: Docker Swarm is easier to set up, but Kubernetes provides more flexibility and robustness in large-scale environments. - Scaling: Kubernetes supports automatic scaling and load balancing, while Docker Swarm has limited auto-scaling capabilities. - User Interface: Kubernetes comes with a built-in dashboard for management, while Docker Swarm lacks a native GUI. - Load Balancing: Kubernetes requires manual load balancing, whereas Docker Swarm automatically balances traffic. - Logging & Monitoring: Kubernetes has integrated tools, while Docker Swarm relies on third-party tools. Related Readings: Docker Swarm

The load balancer monitors the availability of pods through the Kubernetes Endpoints API. When a request is made for a particular Kubernetes service, the Kubernetes load balancer organizes the request among the relevant Kubernetes pods for the service, either in a specific order or using a round-robin approach.

Init containers are special containers that run before the primary containers start. They help prepare the environment by checking dependencies, loading configuration files, or setting up data. One example could be an init container that waits for a database to be up and running: apiVersion: v1 kind: Pod metadata: name: app-with-init spec: initContainers: - name: wait-for-db image: busybox command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done'] containers: - name: my-app image: my-app-image

A Pending state means the Control Plane's Scheduler cannot find a suitable Worker Node for the Pod. Most Likely Causes: - Resource Exhaustion: No Node has enough unallocated CPU/Memory to meet the Pod's strict requests. - Taints & Tolerations: The Pod lacks the required tolerations to schedule on tainted Nodes. - Storage Issues: The Pod is waiting on a Persistent Volume Claim (PVC) that hasn't bound. - Affinity Rules: Strict nodeAffinity constraints cannot be met by the current cluster topology.

Taints and tolerations control which Pods can be scheduled on which nodes. A taint repels pods from a node. A toleration allows a pod to be scheduled on a tainted node. Taints block Pods; tolerations allow exceptions. Taints have three effects: 1. NoSchedule: Prevents new pods from being scheduled on the node unless they tolerate the taint. 2. PreferNoSchedule: This is a soft rule; Kubernetes tries to avoid placing pods there but may still do so if necessary. 3. NoExecute: Not only prevents scheduling but also evicts existing pods that do not tolerate the taint.

Look for insights on deploying Kubernetes masters in multi-node configurations across different availability zones, leveraging etcd clustering for data redundancy, and using load balancers to distribute traffic to API servers. The candidate should also discuss the importance of node health checks and auto-repair mechanisms to ensure high availability. Important Points to Mention: - Multi-master setup for redundancy. - etcd clustering across zones for data resilience. - Load balancers for API server traffic distribution. - Automated health checks and repair for worker nodes. Example You Can Give: “In designing a high-availability cluster for an e-commerce platform, we deployed a multi-master setup across three availability zones, with etcd members distributed similarly to ensure data redundancy. A TCP load balancer was configured to distribute API requests to the API servers, ensuring no single point of failure. We also implemented node auto-repair with Kubernetes Engine to automatically replace unhealthy nodes.” Hedge Your Answer: “While these strategies significantly enhance cluster availability, they also introduce complexity in cluster management and potential cost implications. For some applications, especially those tolerant to brief downtimes, such a high level of redundancy may not be cost-effective. The optimal configuration often depends on the specific application requirements and the trade-offs between cost, complexity, and availability.”

Kubernetes uses two primary components for service discovery and load balancing: - Services: Kubernetes services provide a stable network endpoint to access a group of pods. Services act as an abstraction layer, allowing clients to connect to the service without needing to know the individual pod's IP addresses. Kubernetes assigns a virtual IP address and a DNS name to the service, which load balances traffic to the underlying pods. - kube-proxy: kube-proxy is a network proxy that runs on each node in the Kubernetes cluster. It manages the network routing and load balancing for services. It ensures that traffic sent to a service's virtual IP address is distributed to the corresponding pods.

Implementing multi-tenancy in Kubernetes involves isolating different teams or users (tenants) within a single cluster. This can be achieved through: - Namespaces - Resource Quotas - Network Policies - RBAC

Labels and Selectors are essential sections in Kubernetes configuration files for deployments and services due to how they link Kubernetes services to pods. Labels are key-value pairs that identify pods distinctly; the deployment assigns these labels and uses them as a starting point for the pod prior to its creation, and the Selector matches these labels. Labels and selectors combine to create connections between deployments, pods, and services in Kubernetes.

A ConfigMap is a Kubernetes API object used to store data that is not confidential. ConfigMap information is stored in a variety of information formats, such as key-value pairs and JSON. (The sample Kubernetes ConfigMap below contains both name-value pairs and a JSON object.) Typically a developer uses a ConfigMap to provide information to the cluster that gets consumed by other API objects. kind: ConfigMap apiVersion: v1 metadata: name: db-configmap data: # Configuration data as key-value properties database: mongodb database_uri: mongodb://localhost:27017 # Other data in JSON keys: | maximum.connections=5 timeout=10000 | A Kubernetes secret is a Kubernetes object that stores information in the cluster in an encrypted format. Typically a secret is used to store confidential information. The example below is a manifest file that describes a Kubernetes secret for a username/password pair. Notice the Base64 encrypted values. apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: # An encrypted username/password pair username: YWRtaW4= password: MWYyZDFlMmU2N2Rm |

A Namespace is a virtual cluster within a physical cluster, allowing multiple teams or projects to share the same cluster resources while maintaining isolation.

In a sidecar pattern, one container is created in a pod to provide service to another container in that pod. The sidecar container runs on the same machine under the same IP address as all the other containers that run in the pod. Thus, it's very efficient to move traffic between the main container and the sidecar container. The sidecar provides extended features to the main container, yet it is independent so it allows updates without stopping the main container. When you need to provide additional features or services to a container in a versatile, low-latency manner, the sidecar pattern is a good way to go.

Immutable infrastructure means you don't change systems after they're deployed. Instead of updating or patching a running server, you create a new version and replace the old one. Kubernetes follows this idea. When you update an application, it creates new pods with the updated version and replaces the old ones step by step. If something goes wrong, you roll back.

Kubernetes has introduced enhanced security features, support for Windows containers, server-side apply for API changes, and improvements in network policy execution.

A PersistentVolume (PV) is the actual storage resource, a piece of disk provisioned either by an admin or dynamically by a StorageClass. A PersistentVolumeClaim (PVC) is a request for storage made by a Pod. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: app-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: standard And a Pod that mounts it: apiVersion: v1 kind: Pod metadata: name: app spec: containers: - name: app image: myapp:1.2 volumeMounts: - name: data mountPath: /app/data volumes: - name: data persistentVolumeClaim: claimName: app-data With dynamic provisioning (the norm in production), you don't pre-create PVs. The StorageClass provisions them automatically when a PVC is created.

A Pod is the smallest deployable unit in Kubernetes, wrapping one or more containers that share storage and networking.

Container monitoring tools in Kubernetes include Prometheus for metrics collection and Grafana for visualization.

ConfigMaps and Secrets keep configuration and sensitive information out of your container images. Hardcoding values into application code creates security risks and makes the codebase harder to maintain. Kubernetes lets you inject configuration at runtime instead. A ConfigMap holds non-sensitive information like URLs, port configurations, and environment variables. A Secret is for database passwords, API keys, and tokens. Here is a code example of a ConfigMap and a Secret:

Candidates should describe strategies like rolling updates, blue-green deployments, and canary releases. They should mention Kubernetes features like Deployments, Services, and health checks, and explain how to use them to achieve zero-downtime updates. Advanced answers might also include the use of service meshes for more controlled traffic routing and fault injection testing. Important Points to Mention: - Rolling updates gradually replace old Pods with new ones. - Blue-green deployments switch traffic between two identical environments. - Canary releases gradually introduce a new version to a subset of users. - Health checks ensure only healthy Pods serve traffic. Example You Can Give: “For a critical payment service, we used a canary deployment strategy to minimize risk during updates. We first deployed a new version to 10% of users, monitoring error rates and performance metrics. After confirming stability, we gradually increased traffic to the new version using Kubernetes Deployments to manage the rollout, ensuring zero downtime.” Hedge Your Answer: “While these strategies aim to minimize downtime, their effectiveness can vary based on the application architecture, deployment complexity, and external dependencies. For instance, stateful applications or those requiring database migrations may need additional steps not covered by Kubernetes primitives alone. Furthermore, network issues or misconfigurations can still lead to service disruptions, underscoring the importance of thorough testing and monitoring.”

Upgrading a Kubernetes cluster involves updating the control plane components and the nodes. The general steps include: - Backup etcd: Ensure you have a recent backup of the etcd database. - Upgrade the master nodes: Update the Kubernetes API server, controller manager, and scheduler. - Upgrade the worker nodes: Upgrade kubelet and kube-proxy on each node. - Verify the cluster: Ensure all components are running the new version and the cluster is functioning correctly. - Upgrade applications: Update the deployments to use the new Kubernetes features if needed. Commands to upgrade the control plane: kubeadm upgrade plan kubeadm upgrade apply Upgrade kubelet and kube-proxy on nodes: apt-get upgrade -y kubelet kubeadm kubectl systemctl restart kubelet Always refer to the official Kubernetes documentation for detailed steps specific to your Kubernetes version and environment.

Increasing Kubernetes security is crucial to protect your cluster, applications, and sensitive data from potential threats and unauthorized access. Here are several essential practices and measures to enhance Kubernetes security: By following these security measures and best practices, you can significantly enhance the security of your Kubernetes cluster, reducing the risk of potential threats and ensuring a more resilient and protected environment for your applications.

In K8's scheduler is responsible to spawn pods into nodes. There are many factors that can lead to unstartable POD. The most common one is running out of resources, use the commands like kubectl describe -n to see the reason why POD is not started. Also, keep an eye on kubectl to get events to see all events coming from the cluster.

The answer should include monitoring current usage with metrics and logs, predicting future needs based on trends or upcoming projects, and considering the overhead of Kubernetes components. They should also discuss tools and practices for scaling the cluster and applications. Important Points to Mention: - Utilization of monitoring tools like Prometheus for gathering usage metrics. - Analysis of historical data to forecast future resource needs. - Consideration of cluster component overhead in capacity planning. - Implementation of auto-scaling strategies for both nodes and pods. Example You Can Give: “In preparing for an expected surge in user traffic for an online retail application, we analyzed historical Prometheus metrics to identify peak usage patterns and forecast future demands. We then increased our cluster capacity ahead of time while configuring Horizontal Pod Autoscalers for our frontend services to dynamically scale with demand. Additionally, we enabled Cluster Autoscaler to add or remove nodes based on the overall cluster resource utilization, ensuring we could meet user demand efficiently.” Hedge Your Answer: “Capacity planning in Kubernetes requires a balance between ensuring adequate resources for peak loads and avoiding over-provisioning that leads to unnecessary costs. Predictive analysis can guide capacity adjustments, but unforeseen events or sudden spikes in demand can still challenge even the most well-planned environments. Continuous monitoring and adjustment, combined with a responsive scaling strategy, are essential to navigate these challenges effectively.”

Implement centralized logging with tools like Fluentd or ELK stack. Use monitoring tools like Prometheus for metrics and Grafana for visualization to maintain the health of applications.

Disadvantages of Kubernetes: Complexity in setup and management, steep learning curve, and overhead in smaller applications or environments.

Namespaces are virtual clusters within a Kubernetes cluster, used to divide cluster resources among multiple users or teams.

Core Concepts: Deployments, with their built-in features like rolling updates and rollbacks, provide a mechanism for achieving zero-downtime deployments.

CRDs extend the Kubernetes API with your own resource types. An operator is a controller that watches these custom resources and takes automated action. apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: databases.example.com spec: group: example.com scope: Namespaced names: plural: databases singular: database kind: Database versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: engine: type: string version: type: string Once applied, you can manage databases like native Kubernetes resources: kubectl get databases A PostgreSQL operator, for example, might handle backups, failover, and scaling based on the state of Database resources. Operators encode operational knowledge into software.

To troubleshoot a failing pod in Kubernetes, start by inspecting the pod's logs using kubectl logs for error messages or issues. Use kubectl describe pod to get more details about the pod's state and events, identifying reasons for failure. Check resource limits, liveness and readiness probes, and network configurations for possible causes. Additionally, ensuring that the application code within the pod is debuggable and monitoring the pod's metrics can provide insights into its behavior and potential issues.

You can separate resources by using namespaces. These can be created either using kubectl or applying a YAML file. After you have created the namespace you can then place resources, or create new resources, within that namespace. Some people think of namespaces in Kubernetes like a virtual cluster in your actual Kubernetes cluster.

Deployments are used for stateless applications; they manage Pods via ReplicaSets and are ideal for rolling updates. StatefulSets are for stateful applications, ensuring ordered deployment, stable network identities, and managing persistent storage claims.

Kubernetes objects: Includes pods, services, volumes, namespaces, and controllers such as DaemonSets, Deployments, StatefulSets, ReplicaSets, and Jobs.

Two main components of Kubernetes architecture are the Master node and the Worker node. Master node: The master node is the control plane making global decisions inside the cluster. The master node comprises the control plane components responsible for managing and coordinating the cluster. These components are the API server, scheduler, cloud controller manager, and controller manager. Worker node: The worker node has four very light components, which makes sense because you want to reserve most of the space for your pods. These components are the proxy, the Kubelet, and the container runtime.

RBAC is built around four resources: - Roles (namespace-scoped permissions) - ClusterRoles (cluster-wide permissions) - RoleBindings (assign Roles or ClusterRoles within a namespace) - ClusterRoleBindings (assign ClusterRoles across the cluster) Kubernetes still uses rbac.authorization.k8s.io/v1 for these resources. Here's a Role that grants read-only access to Pods in a specific Namespace: apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: dev rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] And a RoleBinding that assigns it to a user: apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods-binding namespace: dev subjects: - kind: User name: jane roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io The principle of least privilege applies: start with no permissions and grant only what's needed.

Clusters in Kubernetes refer to a group of interconnected physical or virtual machines called nodes that work together to efficiently and automatically run containerized applications in a distributed and fault-tolerant manner. Kubernetes clusters allow engineers to orchestrate and monitor containers across multiple physical, virtual, and cloud servers. Kubernetes clusters are designed to be highly available, resilient, and scalable. By using a cluster, engineers can take advantage of the automatic scaling and self-healing capabilities of Kubernetes for optimized application performance.

Taints and Tolerations are scheduling mechanisms that work together to control which Pods can run on which Nodes, helping enforce workload isolation and resource specialization. Taint (NodeLevel) - A taint is applied to a Node. - It tells Kubernetes: "Do not schedule Pods here unless they explicitly tolerate this condition." - Format: (e.g., ) Toleration (Pod-Level) - A toleration is added to a Pod. - It allows the Pod to ignore specific taints and be scheduled on matching Nodes. - It doesn't guarantee placement just permits it.

Kubelet is responsible for ensuring that containers are running in a Pod. It communicates with the control plane and manages the containers' lifecycle on a node.

Labels are used in Kubernetes to tie a service to an individual pod or a group of pods. Add the following parameters to your spec. Selector: app: vcv-app By doing so, your service will be tied to pods containing “vcv-app”.

HPA automatically scales pods based on CPU/memory utilization or custom metrics. It monitors pod usage and adjusts the replica count dynamically. Give an example HPA definition to support your answer.

To collect central logs from Pods running in a Kubernetes cluster, you can use a centralized logging solution. One popular approach is to use the ELK Stack, which consists of three main components: Elasticsearch, Logstash (or Fluentd), and Kibana. Here's how you can set up central logging using the ELK Stack: – If using Logstash: Install and configure Logstash on a separate node or container. Create Logstash pipelines to process and forward logs to Elasticsearch. – If using Fluentd: Deploy Fluentd as a DaemonSet on each node in the Kubernetes cluster. Fluentd will collect logs from containers running on each node and send them to Elasticsearch. Additionally, you can consider using other centralized logging solutions like Loki or Splunk for log aggregation and analysis. The process may vary slightly depending on the logging tool you choose, but the core concept remains the same: collect logs centrally from Kubernetes Pods and make them available for analysis and visualization in a user-friendly interface. Keep in mind that setting up and maintaining a centralized logging solution requires careful planning and consideration of resource usage, especially if you have a large number of Pods generating a significant volume of logs.

There are many different ways to expose services but the load balancer is one of the most ideal ways to expose service. Ingress networks can be defined as a series of rules, that play the role of an entry point to the Kubernetes cluster. Further, it permits incoming connections, and these connections are configured later to provide services through different mediums like URLs that can be reached, load traffic balancer, or can also be configured through name-based virtual holding. There are various services present in clusters and Ingress is an API object that allows access to the services present in the clusters. And this is possible by making use of HTTP, further, it is one of the meticulous ways to expose services.

A container is a standard software unit that packages the code along with its libraries and dependencies. This helps to ensure that the application can run quickly and efficiently. Besides packaging, containers help build, ship, deploy, and scale your application with ease. On the other hand, a pod is a group of containers with shared storage and network resources. A pod is the smallest deployable unit that can be created and managed within the Kubernetes ecosystem. In other words, on Kubernetes, containers run in pods.

Kubectl allows you to deploy and manage applications on a Kubernetes cluster, inspect and debug cluster resources, and view logs and metrics, among other things. Here's a brief overview of what Kubectl can do: - Create, read, update, and delete Kubernetes resources (pods, services, deployments, etc.) - Interact with the Kubernetes API server to manage cluster resources - Monitor the status of resources and diagnose issues - Manage Kubernetes configurations and secrets - View logs and metrics for applications running on the cluster

Docker delivers a facility to manage the lifecycle of a container, while it also helps in building the run-time container. Well, Docker may help in building run-time containers and so on but the Docker container cannot communicate. These containers need a platform to communicate. This is where Kubernetes plays a crucial role in arranging communication between the Docker containers.

Every application contains a group of containers that tend to run across a number of hosts. Well in order to perform well, these containers need to communicate with each other. And the communication of these containers is possible by means of Kubernetes. Kubernetes is basically cloud-agnostic and is designed in a certain way to allow communication between multiple containers. And this is how the deployment of containers takes place.

Upgrading a Kubernetes cluster is mainly about order and compatibility. You upgrade the control plane first, and that means upgrading its core components: the API server, controller manager, cloud controller manager, and scheduler. Worker nodes can run behind the control plane version but never ahead of it. After that, you upgrade cluster nodes one at a time. Cordon and drain each node before upgrading so workloads move safely to other nodes, then bring it back and continue. This reduces disruption. To minimize downtime, review version changes, back up cluster data, test beforehand, and ensure your apps have enough replicas to stay available.

- Node stops sending heartbeats → marked NotReady. - Pods become Unknown → rescheduled by controllers. - EKS Node Group or Auto Scaling Group (ASG) may automatically replace failed nodes. - Use PodDisruptionBudgets (PDBs) to maintain availability.

Kubernetes uses a kubeconfig file to manage how clients like kubectl connect to a Kubernetes API server. By default, it resides at ~/.kube/config. The file is built around three things: The cluster: Defines the API server address and the certificate authority data used to verify the cluster's identity. The users: Stores the authentication credentials, whether tokens, client certificates, or other supported methods. The context: Links cluster and user together. When you run kubectl config use-context, you are choosing which cluster and credentials to use.

Liveness and readiness probes are essential concepts in container orchestration systems such as Kubernetes, designed to enhance the reliability and availability of applications running within containers. A liveness probe is a mechanism that checks whether a container is running as expected or if it has encountered an internal failure or deadlock. This probe periodically sends a request to a predefined endpoint or executes a command within the container, and based on the response, it determines if the container is in a healthy state. If the probe detects that the container is not functioning correctly, it can trigger actions like restarting the container to restore its functionality, ensuring that the application remains responsive and available. On the other hand, a readiness probe evaluates whether a container is ready to start receiving network traffic. It checks whether the application within the container has been fully initialised and is prepared to serve incoming requests. Readiness probes are particularly valuable during application scaling or rolling updates. When a container reports itself as ready, it can be added to a load balancer or a service pool to begin handling traffic.

Kubectl is the command-line configuration tool for Kubernetes that communicates with a Kubernetes API server. Using kubectl allows you to create, inspect, update, and delete Kubernetes objects.

The Kube-scheduler assigns pods to nodes based on resource availability, affinity rules, and constraints. It considers: - CPU & memory requests/limits - Node taints & tolerations - Pod affinity/anti-affinity - Custom scheduling policies If a pod cannot be scheduled, it remains in a Pending state.

Expect discussions on StatefulSets for managing stateful applications, Persistent Volumes (PV) and Persistent Volume Claims (PVC) for storage, and Headless Services for stable network identities. The candidate might also talk about backup/restore strategies for stateful data and the use of operators to automate stateful application management. Important Points to Mention: - StatefulSets ensure ordered deployment, scaling, and deletion, along with unique network identifiers for each Pod. - Persistent Volumes and Persistent Volume Claims provide durable storage that survives Pod restarts. - Headless Services allow Pods to be addressed directly, bypassing the need for a load-balancing layer. Example You Can Give: “In a project to deploy a highly available PostgreSQL cluster, we used StatefulSets to maintain the identity of each database pod across restarts and redeployments. Each pod was attached to a Persistent Volume Claim to ensure that the database files persisted beyond the pod lifecycle. A headless service was configured to provide a stable network identity for each pod, facilitating peer discovery within the PostgreSQL cluster.” Hedge Your Answer: “Although Kubernetes provides robust mechanisms for managing stateful applications, challenges can arise, particularly with complex stateful workloads that require precise management of state and identity. For example, operational complexities can increase when managing database version upgrades or ensuring data consistency across replicas. Additionally, the responsibility for data backup and disaster recovery strategies falls on the operator, as Kubernetes does not natively handle these aspects.”

Candidates should explain using network policies to define rules for pod-to-pod communications within a Kubernetes cluster, thereby enhancing security. They might explain the default permissive networking in Kubernetes and how network policies can restrict traffic flows, citing examples using YAML definitions. Important Points to Mention: - Network policies allow administrators to control traffic flow at the IP address or port level, enhancing cluster security. - They are implemented by the Kubernetes network plugin and require a network provider that supports network policies. - Effective use of network policies can significantly reduce the risk of unauthorized access or breaches within the cluster. Example You Can Give: “To isolate and secure backend services from public internet access, we defined network policies that only allowed traffic from specific front-end pods. Here's an example policy that restricts ingress traffic to the backend pods to only come from pods with the label role: frontend : apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: backend-access-policy spec: podSelector: matchLabels: app: backend ingress: - from: - podSelector: matchLabels: role: frontend This policy ensures that only front-end pods can communicate with the backend, significantly enhancing our service's security posture.” Hedge Your Answer: “While network policies are a powerful tool for securing traffic within a Kubernetes cluster, their effectiveness depends on the correct and comprehensive definition of the policies. Misconfigured policies can inadvertently block critical communications or leave vulnerabilities open. Additionally, the implementation and behavior of network policies can vary between different network providers, necessitating thorough testing and validation to ensure policies behave as expected in your specific environment.”

Look for explanations on how GitOps uses Git repositories as the source of truth for declarative infrastructure and applications. Benefits include improved deployment predictability, easier rollback, enhanced security, and better compliance. They might mention specific tools like Argo CD or Flux. Important Points to Mention: - GitOps leverages Git as a single source of truth for system and application configurations, enabling version control, collaboration, and audit trails. - Automated synchronization and deployment processes ensure that the Kubernetes cluster's state matches the configuration stored in Git. - Simplifies rollback to previous configurations and enhances security through pull request reviews and automated checks. Example You Can Give: “In a recent project to streamline deployment processes, we adopted a GitOps workflow using Argo CD. We stored all Kubernetes deployment manifests in a Git repository. Argo CD continuously synchronized the cluster state with the repository. When we needed to update an application, we simply updated its manifest in Git and merged the change. Argo CD automatically applied the update to the cluster. This not only streamlined our deployment process but also provided a clear audit trail for changes and simplified rollbacks.” Hedge Your Answer: “While GitOps offers numerous benefits in terms of automation, security, and auditability, its effectiveness is highly dependent on the organization's maturity in CI/CD practices and developers' familiarity with Git workflows. Additionally, for complex deployments, there might be a learning curve in managing configurations declaratively. It also requires a solid backup strategy for the Git repository, as it becomes a critical point of failure.”

Kubernetes provides three types of autoscaling to optimize resource usage: - Horizontal Pod Autoscaler (HPA): Adjusts the number of Pods based on CPU usage, memory usage, or custom metrics. - Vertical Pod Autoscaler (VPA): Adjusts the CPU and memory requests for individual Pods. - Cluster Autoscaler: Adjusts the number of worker nodes in the cluster based on resource needs. You can create an HPA using kubectl: kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10 The above command creates an HPA for a Deployment with the name nginx and tries to keep the average CPU utilization across all Pods at 50%, with a minimum number of replicas at 1 and a maximum number of replicas at 10.

Both spread Pods across nodes, but they work differently. Pod anti-affinity uses hard or soft rules to prevent Pods from landing on the same node. It works for simple cases, but doesn't give you control over how evenly Pods are distributed. Topology spread constraints let you define a maxSkew , which is the maximum allowed difference in Pod count between topology domains (nodes, zones, or regions). This gives you more precise control over distribution. apiVersion: apps/v1 kind: Deployment metadata: name: web-app spec: replicas: 6 selector: matchLabels: app: web template: metadata: labels: app: web spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: web containers: - name: app image: myapp:1.2 This ensures Pods are spread evenly across availability zones, with no zone having more than one extra Pod compared to any other. Use anti-affinity when you just need "don't put two Pods on the same node." Use topology spread constraints when you need even distribution across zones or regions, which matters for production workloads where a zone outage shouldn't take down most of your replicas.