Kubernetes Administrator Interview Questions & Answers | SPOTO

Kubernetes helps in containerized deployment by scaling, loading, balancing, and monitoring containers. You can take advantage of these features by deploying your containerized applications on a Kubernetes cluster. To do this, you create a deployment configuration that instructs Kubernetes on creating and updating instances of your application. Kubernetes manage these instances, which can automatically recover from failures and scale up or down based on demand.

Kubernetes support for multi-tenancy is achieved through namespaces, which isolate clusters into virtually separated sub-clusters. This allows for effective resource management and security isolation among different teams or projects.

A node is a machine in a Kubernetes cluster. Worker nodes are where pods actually run. Every cluster has two main parts: The control plane manages the cluster's state. It decides where pods run, whether containers should restart, and how scaling should occur. In production, it runs across multiple machines and spans availability zones to avoid a single point of failure. Worker nodes run the actual application workloads. When you deploy an application, it is packaged into pods and scheduled onto worker nodes.

StatefulSet | Deployment | |---|---| | A collection of identical stateful pods are handled by the resource is called StatefulSet. | This resource controls identical pods deployment. | | Statefulset helpful in managing stateful applications that need persistent storage with a dependable network ID. | It enables you to control your application's state and ensure that the right number of replicas are always running. |

Steps to approach the problem: 1. Verify external connectivity from inside a Pod. Check if the database is reachable from the Kubernetes network. kubectl exec -it -- curl http://my-database.example.com:5432 2. Check DNS resolution inside the Pod. If it fails, CoreDNS may be configured wrong. kubectl exec -it -- nslookup my-database.example.com 3. Check if network policies exist that block external access, as they can prevent outbound traffic. kubectl get networkpolicies kubectl describe networkpolicy

PersistentVolumeClaims are Kubernetes resources used by Pods to request access to persistent storage. They can be created by defining a PersistentVolumeClaim resource in a YAML or JSON configuration file.

We can list all Pods using the kubectl get pods command.

For many types of Service, the selector identifies which Pods to include in the service. The matching Pods are called endpoints for the Service. Kubernetes retrieves these endpoints from the API server, and the Service kube-proxy sets up appropriate iptables rules (or equivalent on other platforms or using ipvs) to match the Service behavior.

RBAC defines roles and role bindings to restrict which users or service accounts can perform actions on resources, ensuring least privilege access.

A Custom Operator automates complex application tasks-like deployment, scaling, and backup-using Kubernetes-native APIs. It consists of: - A Custom Resource Definition (CRD) that defines a new type of object (e.g., MyDatabase ) - A Controller that watches for changes and acts to maintain the desired state Operators embed domain-specific logic, making Kubernetes capable of managing not just infrastructure but full application lifecycles. They're ideal for stateful apps like databases, caches, or monitoring systems.

Multi-Tenancy Models Namespace-Level Tenancy (Soft Multi-Tenancy): Each tenant gets dedicated namespaces with isolation through RBAC, network policies, and resource quotas. Node-Level Tenancy (Hard Multi-Tenancy): Tenants get dedicated nodes with stronger isolation but higher resource overhead. Cluster-Level Tenancy (Full Isolation): Each tenant gets their own cluster – maximum isolation but highest operational overhead. Architectural Decision Framework Security Requirements → Compliance Needs → Cost Constraints → Operational Complexity ↓ ↓ ↓ ↓ Choose appropriate tenancy model and isolation mechanisms Namespace-Level Multi-Tenancy Design 1. Resource Isolation Strategy # Tenant-specific namespace with labeling apiVersion: v1 kind: Namespace metadata: name: tenant-a labels: tenant: tenant-a tier: production compliance-level: high The labeling strategy enables: - Automated policy application - Monitoring and alerting segmentation - Resource allocation and billing Resource Quota Implementation: # Comprehensive resource limits per tenant apiVersion: v1 kind: ResourceQuota metadata: name: tenant-a-quota namespace: tenant-a spec: hard: requests.cpu: "10" # Total CPU requests requests.memory: 20Gi # Total memory requests limits.cpu: "20" # Total CPU limits limits.memory: 40Gi # Total memory limits pods: "50" # Maximum pod count persistentvolumeclaims: "10" # Maximum PVC count services: "20" # Maximum service count Key quota considerations: requests vs limits: Controls resource allocation vs consumption Pod limits prevent resource exhaustion attacks PVC limits control storage costs Service limits prevent port exhaustion 2. Security Isolation Mechanisms RBAC Design Pattern: Tenant Admin → Full access to tenant namespaces Tenant Developer → Limited access to development namespaces Tenant Viewer → Read-only access to tenant resources Network Isolation: # Default deny + explicit allow pattern apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: tenant-isolation namespace: tenant-a spec: podSelector: {} # Applies to all pods policyTypes: - Ingress - Egress ingress: - from: - namespaceSelector: matchLabels: tenant: tenant-a # Only same-tenant traffic egress: - to: - namespaceSelector: matchLabels: tenant: tenant-a # Only same-tenant traffic - to: [] # Allow egress to system services namespaceSelector: matchLabels: name: kube-system Node-Level Tenancy for Enhanced Isolation When to Use Node-Level Tenancy: - Regulatory compliance requirements - Performance-sensitive workloads - Tenants with conflicting security requirements Implementation Strategy: # Dedicated nodes for sensitive tenant apiVersion: v1 kind: Node metadata: name: node-tenant-a-1 labels: tenant: tenant-a compliance: pci-dss spec: taints: - key: "tenant" value: "tenant-a" effect: "NoSchedule" # Only tenant-a pods can schedule Tenant Pod Scheduling: spec: nodeSelector: tenant: tenant-a # Schedule only on tenant nodes tolerations: - key: "tenant" operator: "Equal" value: "tenant-a" effect: "NoSchedule" Observability and Monitoring Strategy 1. Tenant-Specific Monitoring Prometheus (Per-tenant metrics) → Grafana (Tenant dashboards) → AlertManager (Tenant-specific alerts) 2. Logging Segregation - Tenant-specific log aggregation - Separate retention policies per tenant - Compliance-aware log handling 3. Cost Attribution - Resource usage tracking per tenant - Chargeback/showback reporting - Capacity planning per tenant Operational Considerations Tenant Onboarding Automation - Automated namespace creation with proper labels - Default resource quotas and network policies - RBAC setup and credential distribution Upgrade and Maintenance - Tenant-aware maintenance windows - Progressive rollout strategies - Tenant-specific testing procedures Disaster Recovery - Tenant-specific backup and restore procedures - Cross-cluster tenant migration capabilities - RTO/RPO requirements per tenant Advanced Multi-Tenancy Patterns Hierarchical Tenancy: Organizations with sub-organizations requiring nested resource hierarchies. Dynamic Tenancy: Temporary tenants with automated cleanup and resource reclamation. Hybrid Tenancy: Combining multiple tenancy models based on workload characteristics and requirements.

OpenShift is an enterprise Kubernetes platform that includes additional features like developer tools, integrated security, and enhanced management capabilities. Kubernetes and OpenShift are both container orchestration platforms, but they have some key differences. OpenShift is a commercial product, while Kubernetes is open-source. This means that OpenShift comes with a subscription fee, while Kubernetes is free to use. OpenShift also includes additional features and support that are not available in Kubernetes. OpenShift is more opinionated than Kubernetes. This means that OpenShift makes some decisions about how containerized applications should be deployed and managed. Kubernetes is more flexible, allowing users to customise the way their applications are orchestrated. OpenShift has a wider range of features than Kubernetes. OpenShift includes features for security, networking, and monitoring that are not available in Kubernetes. This makes OpenShift a good choice for organisations that need a more comprehensive container orchestration platform.

The cluster autoscaler follows a specific decision tree: Pending Pods Detected ↓ Check if pods have resource requests (REQUIRED) ↓ Simulate pod scheduling on new nodes ↓ Evaluate scaling constraints and policies ↓ Make scaling decision Why Autoscaling Fails 1. Missing Resource Requests This is the most common issue. Pods without resource requests cannot trigger autoscaling because the scheduler doesn't know how much capacity they need. # This pod CANNOT trigger autoscaling spec: containers: - name: app image: nginx # No resources specified # This pod CAN trigger autoscaling spec: containers: - name: app image: nginx resources: requests: # Required for autoscaling cpu: 100m memory: 128Mi The requests section tells the autoscaler how much capacity is needed, enabling it to calculate whether new nodes are required. 2. Node Group Configuration Issues Autoscaling operates on node groups (AWS Auto Scaling Groups, GCP Instance Groups, etc.). Common configuration problems: - Maximum limits reached: Node group already at maximum size - Instance type availability: Requested instance types not available in the zone - Service quotas: Cloud provider quotas preventing new instance creation - Launch configuration issues: Problems with AMIs, security groups, or IAM roles 3. Scheduling Constraints Even with resource requests, pods might not be schedulable on new nodes due to: - Node affinity rules: Requiring specific node labels that new nodes don't have - Anti-affinity rules: Preventing pods from being scheduled together - Taints and tolerations: New nodes having taints that pods don't tolerate - Pod disruption budgets: Preventing scaling operations Systematic Investigation Approach 1. Verify Autoscaler Health Check if the autoscaler itself is functioning: - Controller logs and error messages - Recent scaling decisions and their rationale - Connectivity to cloud provider APIs 2. Analyze Pending Pod Characteristics For each pending pod, examine: - Resource requests (CPU, memory, storage) - Scheduling constraints (affinity, tolerations) - Pod priority and preemption settings 3. Node Group Assessment - Current vs maximum node count - Instance type availability and pricing - Zone distribution and capacity 4. Cloud Provider Integration - API rate limits and quota usage - IAM permissions for autoscaler - Network and security group configurations Architectural Considerations Multi-Zone Strategy: Design node groups across multiple availability zones to handle zone-specific capacity issues. Mixed Instance Types: Use multiple instance types in node groups to increase scheduling flexibility. Priority-Based Scaling: Implement pod priority classes to ensure critical workloads trigger scaling before lower-priority ones. High Priority Pods → Immediate scaling triggers Normal Priority Pods → Standard scaling behavior Low Priority Pods → Best effort scheduling

Kubernetes provides a secure way to manage sensitive information, such as passwords, OAuth tokens, and SSH keys.

Kubernetes provides three levels of load balancing: - Internal Load Balancing (ClusterIP): This distributes traffic to pods within a cluster. - External Load Balancing (LoadBalancer Service): It provisions cloud-based external load balancers. - Ingress Load Balancing: Routes traffic based on hostnames and paths. For pod-to-pod balancing, Kube-proxy implements IPTables mode (the default mode and efficient packet forwarding) and IPVS mode, which offer better performance for large-scale clusters.

Taints repel pods from nodes unless the pod has a matching toleration. Used for specialized node assignments.

It is a Google-managed implementation of the Kubernetes open-source management platform for clusters and Docker containers. It provides a managed environment for deploying, scaling, and managing your containerized applications using Google infrastructure. It is designed to simplify containerized applications' deployment, management, and scaling in a production environment.

It is a daemon, which is used for embedding the core control loops that regulates system performance. It is a crucial loop of this platform and can not be terminated.

Kubernetes Service: apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp ports: - name: http protocol: TCP port: 80 targetPort: 9376 type: LoadBalancer

Kubernetes provides a robust platform for deploying, scaling, and managing containerized applications. Unlike Docker Swarm, which is specifically designed for Docker containers, Kubernetes is container-agnostic, supporting runtimes like Containerd and CRI-O. Moreover, Kubernetes is more feature-rich, offering features such as service discovery, rolling updates, and automated scaling.

Look for comprehensive security strategies that include network policies, RBAC, Pod Security Policies (or their replacements, like OPA/Gatekeeper or Kyverno, considering PSP deprecation), secrets management, and TLS for encrypted communication. Advanced responses may cover static and dynamic analysis tools for CI/CD pipelines, securing the container supply chain, and cluster audit logging. Important Points to Mention: - Network policies restrict traffic flow between pods, enhancing network security. - RBAC controls access to Kubernetes resources, ensuring only authorized users can perform operations. - Pod Security Policies (or modern alternatives) enforce security-related policies. - Secrets management is essential for handling sensitive data like passwords and tokens securely. - Implementing TLS encryption secures data in transit. Example You Can Give: “To secure a cluster handling sensitive data, we implemented RBAC to define clear access controls for different team members, ensuring they could only interact with resources necessary for their role. We used network policies to isolate different segments of the application, preventing potential lateral movement in case of a breach. For secrets management, we integrated an external secrets manager to automate the injection of secrets into our applications securely.” Get DavidW (skyDragon)'s stories in your inbox Join Medium for free to get updates from this writer. Hedge Your Answer: “Securing a Kubernetes cluster involves a multi-faceted approach and continuous vigilance. While the strategies mentioned provide a strong security foundation, the dynamic nature of containerized environments and the evolving threat landscape necessitate ongoing assessment and adaptation. Additionally, the effectiveness of these measures can vary based on the cluster environment, application architecture, and compliance requirements, underscoring the need for a tailored security strategy.”

Kube-proxy is a controller that runs on each node of a cluster. It is used to monitor the communication between services and pods just like a load balancer or network policy. Engineers or developers also use Kube-proxy to perform various general tasks, such as UDP, SCTP forwarding, TCP, etc. They can use this tool to run services on every node.

Kubernetes employs various security mechanisms, including Role-Based Access Control (RBAC) for fine-grained control over access to resources. Additionally, PodSecurityPolicies define the security context of a Pod. Integration with container registries, network policies, and secrets management further enhances the security posture of Kubernetes clusters.

Here are some of the services in Kubernetes: Cluster IP: This is the default service type in Kubernetes, and it exposes the service on a cluster-internal IP. This means that only the services inside the cluster can access it. Node Port: This type of service exposes the service on a static port on each node in the cluster. This makes the service accessible from outside the cluster. Load balancer: This type of service provisions an external load balancer in the cloud infrastructure and directs traffic to the Kubernetes service. This allows you to expose your service to the internet. External name: This type of service maps the service to an external DNS name. This allows you to reference external services by name from within your cluster.

A DaemonSet ensures that all (or some) nodes run a copy of a Pod. It is typically used for deploying background daemons or agents that need to run on every node, such as logging agents, monitoring agents, or network plugins. DaemonSets can be used for: - Node-level logging: Deploying log collectors on all nodes. - Node monitoring: Running node monitoring agents like Prometheus Node Exporter. - Network services: Deploying network tools or storage plugins on each node. Example of a DaemonSet configuration: apiVersion: apps/v1 kind: DaemonSet metadata: name: node-logger spec: selector: matchLabels: name: node-logger template: metadata: labels: name: node-logger spec: containers: - name: logger image: fluentd

Ingress is a powerful Kubernetes service that acts as an HTTP and HTTPS load balancer and provides routing for external traffic to services in a cluster. Let's look at its key components: - Ingress Resource: This is a Kubernetes object that acts as a configuration file for managing external access to services in a cluster. It defines rules and settings for how traffic should be routed. - Ingress Controller: The Ingress Controller is in charge of obeying the Ingress Resource's rules and configuring the load balancer and traffic routing. Most often, the Ingress Controller is implemented through a Kubernetes extension or a third-party tool, like NGINX or Traefik. - Load Balancer: Operating at layer 7 of the OSI model, the Load Balancer directs traffic to available services based on rules. The Ingress Controller configures and manages this Load Balancer on behalf of the cluster. Note: A cloud provider might offer its own Load Balancer, but the Ingress Controller can also use standard cloud provider tools or its own mechanism if the cluster isn't on a cloud platform. - Rules: These are defined within the Ingress Resource and specify how incoming traffic should be handled. Rules typically match a specific path or domain and define the associated backend Kubernetes service. Ingress is an ideal fit for clusters needing to route HTTP or HTTPS traffic. It's especially beneficial in microservices architectures, as it centralizes and simplifies access to services. This, in turn, improves security, ease of management, and facilitates traffic optimizations like caching.

The available management and orchestrator features in Kubernetes are: 1. Cluster management components: These components manage the Kubernetes cluster. 2. Container orchestration components: These components orchestrate the deployment and operation of containers. 3. Scheduling components: These components schedule and manage the deployment of containers on nodes in the cluster. 4. Networking components: These components provide networking capabilities for containers in the cluster. 5. Storage components: These components provide storage for containers in the cluster. 6. Security components: These components provide security for the containers in the cluster.

Kubernetes Nodes are the compute hosts that run your containers. They're coordinated by a control plane that manages your Nodes as a cluster. The control plane stores cluster-level data, schedules containers onto Nodes, and takes action to reschedule workloads if a Node fails. The Node architecture makes Kubernetes clusters highly scalable because you can continually add new Nodes to increase deployment capacity.

A Kubernetes cluster is a group of nodes that run containerized applications across various environments and machines—cloud-based, physical, virtual, and on-premises. It enables the easy development of applications as well as their management and movement.

A Service is a way to expose an application running on a set of Pods as a network service. It provides a stable IP address and DNS name, abstracting away changes to Pod IPs due to scaling or restarts.

Pods are disposable. When they are killed and replaced, their internal IP addresses change. A service solves this by providing a stable entry point that maps to those shifting pods, keeping the application reachable. Kubernetes service types: ClusterIP: Assigns a stable cluster IP address, reachable from inside the cluster. This is the default type and is used for pod-to-pod communication. NodePort: Opens a static port on every node's IP. It allows external access to the service from outside the cluster. LoadBalancer: Exposes the service using an external load balancer from your cloud provider. Sits on top of NodePort. ExternalName: Maps a service to an external DNS name, routing traffic to a service outside the cluster.

Persistent Volumes (PVs) in Kubernetes represent physical storage resources within a cluster, while Persistent Volume Claims (PVCs) are requests made by Pods for specific storage resources. PVs and PVCs abstract the underlying storage details, providing a consistent and scalable method for managing storage in a containerized environment.

A pod is the smallest unit in Kubernetes that runs one or more containers. It allows containers to share the same network and storage resources.

Kubectl is a command-line interface for Kubernetes. With Kubectl, you can manage your Kubernetes clusters and applications. Kubectl can be used on your local machine, or you can use it with a Kubernetes cluster. kubectl can be used to create, delete, and manage Kubernetes objects.

Securing a Kubernetes cluster involves multiple layers and best practices to protect against unauthorized access and vulnerabilities: - Authentication and Authorization: Use RBAC (Role-Based Access Control) to manage access to the API server. - Network Policies: Define network policies to control traffic between Pods. - Secrets Management: Store sensitive data in Secrets and limit access using RBAC. - Pod Security Policies: Enforce security standards for Pods, such as running as non-root users. - Image Security: Use trusted registries, scan images for vulnerabilities, and employ image signing. - Audit Logging: Enable audit logging to track access and modifications in the cluster. - ETCD Security: Secure ETCD with TLS encryption and access controls. Example of a Network Policy to restrict access: ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-only-frontend namespace: mynamespace spec: podSelector: matchLabels: role: backend ingress: - from: - podSelector: matchLabels: role: frontend Applying the Network Policy: ```bash kubectl apply -f network-policy.yaml

Load Balancing is one of the most common and standard ways of exposing the services. There are two types of load balancing in K8s and they are: Internal load balancer – This type of balancer automatically balances loads and allocates the pods with the required incoming load. External Load Balancer – This type of balancer directs the traffic from the external loads to backend pods.

The master node runs several key processes, including kube-apiserver, kube-scheduler, and etcd, crucial for cluster management and state storage.

This is a two-part abstraction for managing storage in a cluster. - PersistentVolume (PV): A piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using a StorageClass. It is a cluster-level resource, like a node. - PersistentVolumeClaim (PVC): A request for storage by a user or application. It is similar to a Pod requesting CPU or memory. A PVC consumes a PV resource and must exist in the same namespace as the Pod that uses it.

To check the status of a deployed K8, run the following command: kubectl rollout status Once you run this, you should see the following in your command prompt: NAME READY UP-TO-DATE AVAILABLE AGE name-of-deployment 0/3 0 0 6s

A Controller in Kubernetes is a control loop that watches the state of the cluster and makes changes towards a desired state. Examples include the Deployment Controller, StatefulSet Controller, and Node Controller.

Taints and Tolerations control where Pods run: - Taints: Mark nodes to reject Pods. - Tolerations: Allow Pods to ignore certain Taints. Here's an example for tainting a node only to accept specific workloads: kubectl taint nodes node1 key1=value1:NoSchedule This means no Pod can be scheduled on node1 until it has the required Toleration. A Toleration is added in the PodSpec section like the following: apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent tolerations: - key: "key1" operator: "Equal" value: “value1” effect: "NoSchedule" The Pod would be allowed to be scheduled on node1

If you need quick, lightweight container orchestration for a small use case, consider Swarm. For anything requiring multi-cluster management, robust security, or complex networking, Kubernetes wins.

Both objects decouple configuration artifacts from container images, making applications portable. | Feature | ConfigMap | Secret | |---| | Purpose | Stores non-confidential configuration data. | Stores highly sensitive data. | | Examples | Environment variables, config files (nginx.conf). | Passwords, SSH keys, OAuth tokens, TLS certificates. | | Encoding | Stored as plain text. | Encoded in Base64 (not encrypted by default). | | Usage | Injected as environment variables or mounted files. | Ideally mounted strictly as read-only memory volumes. |

Approach to tackle the problem: 1. Roll back to the previous working version. kubectl rollout undo deployment my-app 2. Check the Deployment history and identify what has changed in the new version. kubectl rollout history deployment my-app 3. Check the new Pod's logs for errors. kubectl logs -l app=my-app 4. Check readiness and liveness probes. 5. Verify image-pulling issues. Sometimes, the new image is wrong or unavailable.

To delete a service in Kubernetes, you can use the kubectl delete service command.

A sidecar is a secondary container added to a pod to enhance or augment the main container, often used for logging, monitoring, or configuration updates.

Kube-proxy is designed for maintaining network rules on nodes, enabling network communication to and from Pods.

In Kubernetes, a load balancer is a component that distributes incoming network traffic across multiple instances of an application running in a cluster. The load balancer sends connections to one server in the pool based on an algorithm to determine the next server and sends new connections to the next server, which is available. This algorithm is ideal where virtual machines incur costs, such as in hosted environments. Some of the strategies used for load balancing are Round robin, Session infinity, and IP hashing.

This page provides an overview of init containers, which are specialized containers that carry out in front of app containers in a Pod. You can specify init containers in the Pod specification as well as to the containers array (which describes app containers). Init containers can contain utilities or setup scripts that aren't present in an app image. Resource limitations, volumes, and security settings are just a few of the characteristics and functions that app containers support in it containers.

A Kubernetes service is an abstraction layer that exposes a set of pods as a network service, allowing them to communicate with each other and with other services outside the cluster.

The default backend in an Ingress controller handles requests that do not match any of the defined rules. It's typically configured to serve a default service, like a 404 page or a fallback application.

You can create a new service imperatively using the kubectl expose command. For example: kubectl expose deployment my-deployment –port=80 –target-port=8080 –type=NodePort This instantly creates a Service that routes traffic to the labels associated with my-deployment. However, for production environments, it is highly recommended to use a declarative YAML file (kind: Service). This allows you to define selectors, ports, and the specific Service type (like ClusterIP or LoadBalancer) while keeping the configuration stored in version control (GitOps).

Federated clusters in Kubernetes allow multiple Kubernetes clusters to be interconnected, forming a larger mesh of clusters. This allows for greater scale and redundancy, as well as simplified management of multiple clusters. Federated clusters are configured by setting up a federated control plane, and then adding other Kubernetes clusters to the federated control plane. The federated control plane can be used to manage the other Kubernetes clusters in a number of ways, including: - The nodes in the other clusters - The Pods in the other clusters - The Services in the other clusters - The Secrets in the other clusters - The ConfigMaps in the other clusters - The Deployments in the other clusters - The ReplicationControllers in the other clusters - The Ingresses in the other clusters - The LoadBalancers in the other clusters

Kubernetes is an open-source container orchestration platform used for automating the deployment, scaling, and management of containerized applications.

Docker mainly creates and runs containers, while Kubernetes mainly manages and scales those containers.

A pod is the smallest and most basic deployable object in Kubernetes. It represents a single instance of a running process in your cluster. #Create a Pod: kubectl create pod --image= #List Pods: kubectl get pods #Describe a Pod: kubectl describe pod #Delete a Pod: kubectl delete pod #Execute Command in a Pod: kubectl exec -it -- #Port Forwarding to a Pod: kubectl port-forward : #View Logs of a Pod: kubectl logs #Attach to a Running Container in a Pod: kubectl attach -it -c #Copy Files to/from a Pod: #From Pod: kubectl cp :/remote/path /local/path #To Pod: kubectl cp /local/path :/remote/path #Execute Command in a Specific Container of a Pod: kubectl exec -it -c -- #Get Pod's IP Address: kubectl get pod -o jsonpath='{.status.podIP}' #Get Pod's YAML Configuration: kubectl get pod -o yaml

An Ingress network is a set of protocols that acts as an entry point for external traffic into the Kubernetes cluster and manages access to services within the cluster. An Ingress network is traffic whose source lies in the public internet or an external network and is sent to the destined node in the private network. It is used to manage user access for the services within the Kubernetes cluster.

Namespaces provide a mechanism for isolating groups of resources within a single cluster. They are used to divide cluster resources between multiple users or teams and provide a scope for names.

Bonus question for practice. Troubleshoot by checking pod events, resource requests/limits, node taints and tolerations, and the scheduler logs.

Kubernetes handles application configuration using ConfigMaps and Secrets: - ConfigMaps: Store non-sensitive configuration data as key-value pairs, allowing you to decouple configuration from container images. ConfigMaps can be mounted as volumes or exposed as environment variables. - Secrets: Store sensitive data such as passwords and tokens. Secrets are base64-encoded and can be mounted as volumes or exposed as environment variables. It's recommended to encrypt Secrets at rest and integrate with external secret management tools for enhanced security.

Kubernetes significantly enhances container orchestration by providing a robust and comprehensive platform for automating the deployment, scaling, and management of containerized applications. At its core, Kubernetes offers a cluster management framework that abstracts the underlying infrastructure, making it easier to deploy and manage containers across diverse environments. It automates tasks like load balancing, self-healing, and rolling updates, thereby ensuring high availability and resilience. Kubernetes also allows for efficient resource allocation, ensuring that containers run optimally on a cluster, and it can dynamically scale applications based on demand. Its declarative configuration model allows users to specify the desired state of their applications, and Kubernetes takes care of reconciling the actual state with the desired state, simplifying the management of complex containerized systems.

The kubectl scale command enables the ability to instantly change the number of replicas needed for running an application. While using this command, the new number of replicas needs to be specified by setting the –replicas flag.

Liveness probes determine if a container is running; if it fails, the kubelet restarts the container. Readiness probes determine if a container is ready to serve traffic; if it fails, the Service removes the Pod's IP.

Kubernetes manages secrets using the Secret object, which allows storing and managing sensitive information such as passwords, OAuth tokens, and SSH keys. Secrets can be created manually or automatically and are mounted into pods as files or environment variables. Kubernetes stores secrets in etcd, which should be encrypted at rest to enhance security. Best practices for managing secrets in Kubernetes include: - Enabling encryption at rest etc. - Using RBAC to restrict access to secrets. - Limiting the use of secrets as environment variables to reduce exposure. - Regularly rotating and updating secrets. - Using external secret management solutions, such as HashiCorp Vault or AWS Secrets Manager, to manage and inject secrets into the cluster securely.

The purpose of kubelet is to realize containers on a given Kubernetes node. Every node in a Kubernetes cluster has a running instance of kubelet. When Kubernetes needs to create a pod(s), it identifies the node where the pod(s) can be created using Scheduler. A message then gets sent to the kubelet instance on the identified node. Kubelet in turn works with the container runtime interface (CRI) to create the container(s) for the pod(s). Figure 3 below outlines how these processes work together. Figure 3: How kubelet realizes containers on a Kubernetes node

A ConfigMap is a Kubernetes object used to store non-confidential configuration data in key-value pairs. ConfigMaps allow you to decouple configuration artifacts from image content, making your applications more portable. They can be used to inject configuration data into Pods using environment variables, command-line arguments, or configuration files.

ImagePullBackOff means that the Kubelet was unable to pull the container image from its registry. The steps are: - Describe the Pod: Run kubectl describe pod and check the Events section for detailed error messages. - Verify Image Name: Check for typos in the container image name or tag in your Pod or Deployment manifest. - Check Registry Accessibility: Ensure the node can connect to the container registry. Check Pull Secrets: If the image is in a private registry, verify that an imagePullSecret is correctly configured in your namespace and referenced in the Pod's spec.

The Kubernetes Vertical Pod Autoscaler (VPA) automatically adjusts the CPU and memory requests and limits for containers in a Pod based on their usage. VPA helps to ensure that Pods have the right amount of resources without manual tuning. - Mode: VPA can run in three modes - 'Off', 'Auto', and 'Recreate'. In 'Off' mode, it only provides recommendations. In 'Auto' mode, it updates the resources automatically. In 'Recreate' mode, it updates the resources by recreating the Pods. Example of deploying a VPA: apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: myapp-vpa namespace: default spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: myapp updatePolicy: updateMode: "Auto" Applying the VPA configuration: kubectl apply -f myapp-vpa.yaml

In order to scatter the traffic across different nodes I will follow this procedure - - Deploy multiple pods across different nodes - Use a Service of type LoadBalancer or NodePort - Configure the service to distribute traffic to the pods

Upgrading a Kubernetes cluster is a multi-step process that requires minimal downtime and maintains cluster stability. Administrators should follow a structured approach to prevent issues during the upgrade: - Drain and backup etcd, before the upgrade to ensure that you can restore it in case the upgrade fails. - Upgrade the control plane node. - Upgrade kubelet and kubectl on control plane nodes. - Upgrade worker nodes one by one. Before upgrading, each worker node must be drained to prevent workload disruption. - Upgrade cluster add-ons (e.g., Ingress controllers, monitoring tools, …).

The Kubernetes scheduler is responsible for scheduling pods to run on available nodes in the cluster based on available resources and other scheduling requirements.

Kube-scheduler is the default scheduler for Kubernetes. It assigns nodes to newly created pods.

Based on the visual diagram, Kubernetes features a centralized control system managing multiple worker nodes. - User Access: Users interact through a User Interface (UI) or Kubectl CLI, routing all commands to the API Server. - Control Components: This central block consists of the API Server, Scheduler, Controller-Manager, and etcd data store. - Worker Nodes: These machines execute the actual workloads. Each node relies on Docker, a kubelet, and a kube-proxy. Inside these nodes are Pods, which encapsulate the individual Containers.

- Set maxUnavailable: 0 and use readinessProbes. - Monitor via CloudWatch Alarms or Prometheus Alerts. - Integrate with Argo Rollouts or Flagger for progressive delivery.

Add these to your specs to ensure that an app in a pod is not down and is running: spec: containers: - name: liveness ports: - containerPort: 80 livenessProbe: initialDelaySeconds: 3 periodSeconds: 4 timeoutSeconds: 1 successThreshold: 1 failureThreshold: 1 httpGet: host: scheme: HTTP path: /path httpHeaders: - name: Host value: visualcv.com

Pods are used in Kubernetes and other container orchestration platforms to provide a higher level of abstraction and flexibility when managing containers. Instead of using individual containers, pods group one or more containers together within the same network namespace and share the same storage volumes. This approach offers several advantages. It simplifies the management of inter-container communication, as containers within a pod can communicate over localhost, making it easier to build and deploy microservices that rely on multiple containers working together. Pods enable shared access to storage volumes, ensuring that data can be consistently accessed by all containers in the pod. Additionally, pods can be easily scaled as a single unit, making it more convenient to manage and scale related containers together. This level of encapsulation also provides improved isolation, resource allocation, and monitoring capabilities, enhancing overall system reliability and manageability.

Network Policies in Kubernetes are used to control the traffic flow between pods and other network endpoints. They are implemented using the Kubernetes Network Policy API, which allows administrators to define rules that specify how pods are allowed to communicate with each other and other network entities. A Network Policy is defined in YAML format and includes specifications such as pod selectors, ingress rules, and egress rules. Pod selectors determine which pods the policy applies to, while ingress and egress rules define the allowed sources and destinations for traffic. By default, pods are non-isolated and accept traffic from any source. Applying a Network Policy restricts traffic to only what is explicitly allowed, enhancing security and compliance within the cluster.

The Linux kernel terminates the container with an out-of-memory (OOM) error. Memory limits are enforced; unlike the CPU, which can be throttled, memory cannot be overcommitted. After termination, Kubernetes follows the pod's restart policy. For Deployments, this defaults to Always. If the container exceeds its memory limit, the pod enters a CrashLoopBackOff state. If the entire node runs low on memory, Kubernetes may evict pods to protect node stability.

Controlling the resource usage of a Pod in Kubernetes is essential to ensure fair allocation of resources and prevent individual Pods from consuming excessive CPU and memory, which could negatively impact other Pods and the overall cluster performance. Kubernetes provides several mechanisms to control the resource usage of Pods: – Resource Requests: It specifies the minimum amount of CPU and memory required for a container to run. Kubernetes will use this information for scheduling and determining the amount of resources allocated to a Pod. – Resource Limits: It specifies the maximum amount of CPU and memory that a container can consume. Kubernetes enforces these limits to prevent a single container from using more resources than specified, which helps in avoiding resource contention. Here's an example of setting resource requests and limits in a Pod's container specification: ```yaml apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: – name: my-container image: my-image resources: requests: cpu: "0.5" memory: "512Mi" limits: cpu: "1" memory: "1Gi" ``` 2. **Resource Quotas**: Kubernetes allows you to define Resource Quotas at the namespace level to limit the total amount of CPU and memory that can be consumed by all Pods within the namespace. Resource Quotas help prevent resource hogging and ensure a fair distribution of resources among different applications. By using these mechanisms, you can effectively control the resource usage of Pods in your Kubernetes cluster, ensuring efficient resource allocation, high availability, and optimal performance for all applications running in the cluster.

Init containers are special containers that run and complete before other containers in the same pod start. They are primarily used to perform initialization tasks such as setting up configuration files, initializing databases, or waiting for external services to become available. apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: main-container image: nginx:latest # Add other container specifications here initContainers: - name: init-container image: busybox:latest command: ['sh', '-c', 'echo Initializing...'] # Add other init container specifications here # Add other pod specifications here Init containers differ from regular containers within a pod in that they run to completion before the main application containers start, and they do not share the same lifecycle or resources as the main containers.

etcd is the cluster's brain. If it completely crashes, the cluster essentially becomes “read-only.” - The Impact: Existing Pods and applications will continue running without interruption. However, you cannot make any changes. You cannot deploy new Pods, scale existing ones, or update configurations, because the API Server has nowhere to read or write state. - The Recovery: You must restore the database from a backup. You use the etcdctl snapshot restore command, pointing it to your latest .db backup file, and then restart the kube-apiserver and etcd pods to resync the cluster.

Helm describes itself as a package manager for Kubernetes. In the same way you might use apt or yum to install software on a Linux machine, Helm lets you package, version, and install applications on a Kubernetes cluster. A Helm package is called a chart. A chart contains all the Kubernetes manifests needed to run an application (Deployments, Services, ConfigMaps, etc.) along with a values.yaml file that lets you customize the configuration without editing the manifests directly. For example, a single chart for a web application could be deployed across staging and production by passing in different values for replica count, image tag, or resource limits. Charts can be shared through repositories, and many open source projects publish official Helm charts. This means you can deploy something like PostgreSQL or Prometheus with a single command and customize it through values rather than writing manifests from scratch.

To solve this issue that organization must replace their monolithic code base with microservice design. Every microservice works like a container, which can be orchestrated and deployed by using this platform. This transition is a complex procedure and requires careful planning and execution.

Container orchestration is critical to working with containers, allowing organizations to unlock their full benefits. It can be used in any environment where you use containers. Container orchestration is needed to manage and automate containerized applications' deployment, scaling, and management. It helps to reduce operational overhead, increase efficiency and scalability, and ensure infrastructure availability, thus helping to improve application performance.

Requests define the minimum resources guaranteed to a container; the scheduler uses these to decide which node has room. Limits define the maximum; the kubelet enforces these via Linux cgroups. apiVersion: v1 kind: Pod metadata: name: resource-demo spec: containers: - name: app image: nginx:1.27 resources: requests: cpu: "250m" memory: "256Mi" limits: cpu: "500m" memory: "512Mi" If a container exceeds its memory limit, it is terminated with an OOMKilled error. If it exceeds its CPU limit, it is throttled, and the application slows down but is not killed. Kubernetes defines three QoS classes: - Guaranteed: requests = limits (for CPU and memory) - Burstable: requests < limits - BestEffort: no requests or limits Our Kubernetes Configuration and Production Readiness tutorial walks through setting resource boundaries to prevent noisy neighbor problems in shared clusters.

This is a common follow-up to the LoadBalancer question, and the interviewer is not only checking whether you understand the difference but also whether you can identify when a LoadBalancer alone is not sufficient. An Ingress is a Kubernetes resource that manages external HTTP and HTTPS traffic and routes it to different services within the cluster based on rules you define. Instead of provisioning a separate load balancer for every service, you deploy a single Ingress controller (such as NGINX Ingress Controller or Traefik) behind one LoadBalancer, and then define routing rules that direct traffic based on hostnames or URL paths. For example, you could configure an Ingress so that: api.example.com routes to your API service app.example.com routes to your frontend service app.example.com/docs routes to a documentation service This gives you a single entry point to the cluster with flexible routing, TLS termination, and other HTTP-level features, all managed declaratively through Kubernetes resources. However, Ingress has its limitations. The resource spec is relatively simple and does not natively support things like traffic splitting, header-based routing, or fine-grained control over how different teams manage their own routing. Much of this functionality ends up being handled through provider-specific annotations, which reduces portability between Ingress controllers.

The components of the Kubernetes Master include the API server, the controller manager, the Scheduler, and the etcd components. The Kubernetes Master components are responsible for running and managing the Kubernetes cluster.

Explanation - USER_PASSWORD environment variable will store the value from the password key in the secret called "some-secret" In other words, you reference a value from a Kubernetes Secret.

GKE is a managed service that allows users to deploy and run containerized applications on GCP. GKE provides various functionalities for container orchestration, such as management, security, governance, and configuration of clusters. This tool can independently manage the entire infrastructure of clusters. For instance, nodes, components and control planes can be easily managed through this tool.

It is a distributed, consistent, and highly available key-value store that serves as the central database for Kubernetes. It plays a foundational role in maintaining the state and configuration of the entire cluster What etcd Stores: • Desired state: Definitions of resources like Deployments, Services, ConfigMaps, etc. • Current state: Real-time status of Pods, Nodes, and other components. • Metadata: Cluster-wide configuration, access control policies, and runtime data.

Kubernetes DNS is a service that provides DNS resolution for services and pods in a Kubernetes cluster.

To ensure a zero downtime Kubernetes rollout, we use rolling updates strategy. With Rolling Updates strategy, our deployments are pushed incrementally without incurring any downtime on production. The way Rolling Update strategy works is that an update is pushed to a pod incrementally. The maximum number of pods unavailable = 1 and the maximum number of pods created = 1 as conditions. When the rolling update is in process, traffic is only routed to available pods.

It specifies what to do with an incoming request to the Kubernetes cluster that isn't mapped to any backend i.e what to do when no rules being defined for the incoming HTTP request If the default backend service is not defined, it's recommended to define it so that users still see some kind of message instead of an unclear error.

Kubernetes, often abbreviated as K8s, is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. It provides a container-centric infrastructure, ensuring seamless scaling, efficient utilization of resources, and enhanced automation, thereby simplifying the management of complex microservices architectures.

There are certain micro-services provided to every application. And those micro-services can serve only when they are synchronized well. The synchronization of the micro-services is highly important, in order to run any application in a seamless manner. In such cases container orchestration comes into play, in layman's terms, orchestration is known as the fusion of different types of instruments to produce a great piece of music. The role of container orchestration is to fuse different components of an application to deliver a smooth service.

Helm leverage a packaging format known as charts, which are a group of files that define the cohesive sets of resources. All the files are stored in a single chart from simple components like Memcached pod to complex web app stack, such as HTTP servers, caches, databases, etc. these packages also provide all the necessary resources for deploying an application to a cluster.

A daemonset ensures that all nodes you select are running exactly one copy of a pod. A deployment is a resource object in Kubernetes that provides declarative updates to applications. It manages the scheduling and lifecycle of pods. It provides several key features for managing pods, including pod health checks, rolling updates of pods, the ability to roll back, and the ability to easily scale pods horizontally. The replication controller specifies how many exact copies of a pod should be running in a cluster. It differs from a deployment in that it does not offer pod health checks, and the rolling update process is not as robust.

The CKA exam contains 23 questions.

To automatically scale the workload to match demand, a Horizontal Pod Autoscaling in Kubernetes updates a workload resource (such a deployment or stateful set). The Horizontal Pod Autoscaler (HPA) automatically scales the number of Pod replicas in a Deployment, ReplicaSet, or StatefulSet based on observed metrics, such as CPU utilization or custom metrics. It increases the number of Pods to handle increased load and decreases them when the load subsides, optimizing resource usage. apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: my-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment # or StatefulSet, or ReplicaSet, depending on your workload name: my-deployment minReplicas: 3 maxReplicas: 5 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 65

The Cloud Controller Manager (CCM) is the bridge that links your Kubernetes cluster to a specific cloud provider's API (like AWS, Azure, or GCP). It decouples the core Kubernetes code from cloud-specific dependencies, allowing providers to release updates independently. The CCM handles: - Node Controller: Checks the cloud provider to determine if a Node has been deleted in the cloud after it stops responding. - Route Controller: Sets up underlying network routes in the cloud infrastructure. - Service Controller: Automatically provisions and destroys cloud load balancers when you create a Service of type LoadBalancer.

Kubernetes is structured so that all communication happens via the API, which is the central point. All requests must pass through it, whether from kubectl, the scheduler, or any other component. Imagine if components could update cluster data directly without validation. You'd have inconsistent states and security issues. The API server checks every request, confirms permissions, and then either performs the action or returns information. If the API server goes down, existing pods may continue to run, but you won't be able to deploy new workloads.

Monitoring a Kubernetes cluster involves setting up various tools and practices to collect and analyze data on the cluster's health, performance, and resource usage. Here's a step-by-step guide to monitoring a Kubernetes cluster effectively: By following these steps and continuously monitoring your Kubernetes cluster, you can gain valuable insights, detect and resolve issues promptly, and maintain a stable and well-performing environment for your applications.

Taints repel pods from nodes unless pods have matching tolerations. Node Affinity attracts pods to nodes with specific labels. Use case: Use taints to enforce strict node usage (e.g., GPU-only), and node affinity to guide placement preferences (e.g., high-memory nodes).

You can get basic logs using `kubectl logs `. For production, you typically implement a centralized logging solution like Fluentd or Logstash to collect, aggregate, and store logs from all Pods.

It is another name for Kubernetes, an open-source platform for managing containerized applications. Kubernetes automates the scaling, deployment, and management of containerized applications, allowing them to run consistently across different computing environments.

- Check the Ingress status - Describe the Ingress resource - Verify the Ingress Controller is running. Restart it if it's down. - Check service backend mapping. - Inspect the Ingress logs - Manually test routing with curl

Role Based Access Control (RBAC) in Kubernetes controls access to cluster resources by defining roles, role bindings, and service accounts to manage authentication and authorisation.

The Kubernetes API is a RESTful API used to manage and operate Kubernetes clusters.

View cluster resources: kubectl get pods – Lists all pods in the current namespace kubectl get nodes – Shows the status of cluster nodes kubectl get services – Displays all services deployed Inspect and debug: kubectl describe pod – Shows detailed information and events for a specific pod kubectl logs – Outputs logs from a container kubectl exec -it -- /bin/sh – Opens an interactive shell in a running container Apply and manage configurations: kubectl apply -f – Creates or updates resources defined in a manifest file kubectl delete -f – Removes the specified resources Namespace and context management: kubectl config use-context – Switches between cluster contexts kubectl get pods --all-namespaces – Lists pods across all namespaces

A Kubernetes Helm Chart is a collection of Kubernetes manifest files packaged together in a single archive. Helm Charts can simplify application deployment and management by providing a standard way to package and version applications.

Over the course of time, using the default namespace alone is proving to be difficult, since you are unable to get a good overview of all the applications you can manage within the cluster as a whole. The namespaces allow applications to be organized into groups that make sense, such as a namespace for all monitoring applications and another for all security applications. Additionally, namespaces can be used for managing Blue/Green environments, in which each namespace contains its own version of an app as well as sharing resources with other namespaces (such as logging or monitoring). It is also possible to have one cluster with multiple teams using namespaces. The use of the same cluster by multiple teams may lead to conflict. Suppose they end up creating an app that has the same name, this means that one team will override the app created by the other team as Kubernetes prohibits two apps with the same name (within the same namespace).

A Kubernetes Controller is a loop that watches the state of the cluster and makes changes to move the current state towards the desired state. Controllers include: - ReplicationController: Ensures a specified number of Pod replicas are running. - Deployment Controller: Manages Deployments and ensures the correct number of Pods are running, updated, and rolled back if needed. - StatefulSet Controller: Manages stateful applications with persistent storage. - DaemonSet Controller: Ensures that a copy of a Pod runs on all or some nodes. - Job Controller: Manages Jobs to ensure Pods run to completion.

Init containers run before your main application containers and must complete successfully before the app starts. They're useful for setup tasks like waiting for dependencies, running migrations, or generating config. apiVersion: v1 kind: Pod metadata: name: app-with-init spec: initContainers: - name: wait-for-db image: busybox command: ['sh', '-c', 'until nc -z postgres-service 5432; do echo waiting; sleep 2; done'] containers: - name: app image: myapp:1.2 This init container waits until the PostgreSQL service is reachable on port 5432 before the main app starts.

- Master Node: - Also known as Control Plane Node, it manages the entire cluster. - Houses the API Server, Controller Manager, and Scheduler, primarily responsible for cluster orchestration. - It initializes and configures workloads, spans across several Master nodes to ensure high availability, and typically doesn't run user applications. - Also, the etcd database is often hosted separately or as a clustered data store. - Worker Node: - Also called Minion or Ingress Node. - Serves as the compute layer of the cluster and by design hosts the containers that make up the actual workloads ('pods') or app services. - Acts as a bridge to offload the networking and monitoring overhead from the Master node and to ensure the security of the cluster. - Other Nodes: - Special-purpose nodes or clusters may introduce other node types, such as dedicated storage or networking elements. However, these are not universal and won't be found in most standard Kubernetes setups.

A Helm chart is a package format that defines a set of pre-configured Kubernetes resources, enabling easy application deployment and management.

Ingress controllers can become bottlenecks due to several factors: Internet Traffic → Load Balancer → Ingress Controller → Backend Services ↓ Performance Bottleneck (CPU, Memory, Network, Configuration) Common bottleneck sources: - Insufficient ingress controller resources - Poor load balancing algorithms - Inefficient SSL/TLS termination - Configuration overhead and rule complexity - Backend service capacity limitations Diagnostic Methodology 1. Performance Metrics Analysis Key Ingress Controller Metrics: # NGINX Ingress Controller metrics kubectl get --raw /api/v1/namespaces/ingress-nginx/services/ingress-nginx-controller-metrics:http-metrics/proxy/metrics | grep -E "nginx_ingress_controller_requests_total|nginx_ingress_controller_request_duration_seconds|nginx_ingress_controller_response_size" Critical metrics to monitor: nginx_ingress_controller_requests_total: Request rate and volume nginx_ingress_controller_request_duration_seconds: Response latency percentiles nginx_ingress_controller_response_size: Response payload analysis nginx_ingress_controller_ssl_expire_time_seconds: Certificate health nginx_ingress_controller_nginx_process_*: Process-level resource usage 2. Resource Utilization Assessment # Analyze current resource consumption kubectl top pod -n ingress-nginx --containers kubectl describe pod -n ingress-nginx # Check node resource availability kubectl describe node | grep -A 10 "Allocated resources" 3. Configuration Analysis Review ingress configuration complexity: - Number of ingress rules and backends - SSL certificate configuration overhead - Routing complexity and regex patterns - Middleware and annotation usage Horizontal Scaling Strategies 1. Ingress Controller Replica Scaling apiVersion: apps/v1 kind: Deployment metadata: name: ingress-nginx-controller namespace: ingress-nginx spec: replicas: 5 # Scale up from default strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 # Ensure availability during updates maxSurge: 1 template: spec: containers: - name: controller image: k8s.gcr.io/ingress-nginx/controller:v1.1.1 resources: requests: cpu: 500m # Increased from default 100m memory: 512Mi # Increased from default 90Mi limits: cpu: 1000m memory: 1Gi 2. Horizontal Pod Autoscaling (HPA) apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: ingress-nginx-hpa namespace: ingress-nginx spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: ingress-nginx-controller minReplicas: 3 # Minimum for high availability maxReplicas: 20 # Scale based on demand metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # Scale up at 70% CPU - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 # Scale up at 80% memory behavior: scaleUp: stabilizationWindowSeconds: 60 policies: - type: Percent value: 100 # Double replicas quickly under load periodSeconds: 15 scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 10 # Conservative scale-down periodSeconds: 60 Key HPA considerations: - Conservative scale-down to avoid thrashing - Aggressive scale-up for traffic spikes - Stabilization windows to prevent rapid scaling - Multiple metrics for comprehensive scaling decisions Performance Optimization 1. NGINX Configuration Tuning apiVersion: v1 kind: ConfigMap metadata: name: nginx-configuration namespace: ingress-nginx data: # Worker process optimization worker-processes: "auto" # Match CPU cores worker-connections: "16384" # Connections per worker max-worker-open-files: "65536" # File descriptor limit # Connection handling upstream-keepalive-connections: "320" # Backend keepalive upstream-keepalive-timeout: "60" # Keepalive timeout upstream-keepalive-requests: "10000" # Requests per connection keep-alive: "75" # Client keepalive keep-alive-requests: "1000" # Client keepalive requests # Buffer optimization large-client-header-buffers: "4 16k" # Header buffer size client-body-buffer-size: "64k" # Body buffer size proxy-buffer-size: "16k" # Proxy buffer size proxy-buffers: "8 16k" # Number of proxy buffers # Compression and caching enable-brotli: "true" # Enable Brotli compression gzip-level: "6" # Gzip compression level proxy-cache-valid: "200 302 1h" # Cache valid responses # Rate limiting rate-limit: "100" # Requests per second rate-limit-window: "1m" # Rate limit window Performance tuning rationale: - Worker processes match available CPU cores - Increased connection limits for high concurrency - Optimized buffer sizes for typical workloads - Compression and caching for response optimization 2. SSL/TLS Optimization # SSL configuration optimization data: ssl-protocols: "TLSv1.2 TLSv1.3" # Modern protocols only ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384" ssl-session-cache-size: "10m" # SSL session cache ssl-session-timeout: "1h" # Session timeout ssl-buffer-size: "4k" # SSL buffer optimization Advanced Scaling Patterns 1. Multi-Tier Ingress Architecture Public Internet → External Load Balancer → Public Ingress Controllers ↓ Internal Network → Internal Load Balancer → Internal Ingress Controllers ↓ Backend Services Public Ingress Configuration: # Public traffic ingress apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: public-api-ingress annotations: kubernetes.io/ingress.class: "nginx-public" nginx.ingress.kubernetes.io/rate-limit: "1000" nginx.ingress.kubernetes.io/rate-limit-window: "1m" spec: tls: - hosts: - api.company.com secretName: api-tls-secret rules: - host: api.company.com http: paths: - path: /api/v1 pathType: Prefix backend: service: name: public-api-service port: number: 80 Internal Ingress Configuration: # Internal traffic ingress apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: internal-api-ingress annotations: kubernetes.io/ingress.class: "nginx-internal" nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/8,172.16.0.0/12" spec: rules: - host: internal-api.company.local http: paths: - path: / pathType: Prefix backend: service: name: internal-api-service port: number: 80 2. Geographic Load Distribution # Regional ingress controllers apiVersion: apps/v1 kind: Deployment metadata: name: ingress-nginx-us-east namespace: ingress-nginx spec: replicas: 5 template: spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/region operator: In values: ["us-east-1"] containers: - name: controller image: k8s.gcr.io/ingress-nginx/controller:v1.1.1 env: - name: POD_REGION value: "us-east-1" Load Balancing Strategies 1. Advanced Load Balancing Algorithms apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress annotations: nginx.ingress.kubernetes.io/upstream-hash-by: "$binary_remote_addr" # IP hash nginx.ingress.kubernetes.io/load-balance: "ip_hash" # Sticky sessions nginx.ingress.kubernetes.io/session-cookie-name: "ingress-session" # Session affinity nginx.ingress.kubernetes.io/session-cookie-expires: "86400" # 24 hours spec: rules: - host: app.company.com http: paths: - path: / pathType: Prefix backend: service: name: app-service port: number: 80 Load balancing method selection: - Round Robin: Default, good for stateless applications - IP Hash: Session affinity for stateful applications - Least Connections: Best for long-running connections - Weighted: Different capacity backend services 2. Circuit Breaker Integration # Circuit breaker configuration annotations: nginx.ingress.kubernetes.io/server-snippet: | location /health { access_log off; return 200 "healthy\n"; } nginx.ingress.kubernetes.io/configuration-snippet: | if ($request_uri = /health) { return 200 "healthy\n"; } error_page 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } Monitoring and Alerting 1. Performance Monitoring Dashboard Key performance indicators (KPIs): - Request rate (RPS) and volume trends - Response latency percentiles (P50, P95, P99) - Error rate and status code distribution - SSL certificate expiration monitoring - Backend service health and availability 2. Automated Alerting # Prometheus alert rules for ingress performance groups: - name: ingress-performance.rules rules: - alert: IngressHighLatency expr: histogram_quantile(0.95, increase(nginx_ingress_controller_request_duration_seconds_bucket[5m])) > 1.0 for: 2m labels: severity: warning annotations: summary: "Ingress latency is high" description: "95th percentile latency is {{ $value }} seconds" - alert: IngressHighErrorRate expr: rate(nginx_ingress_controller_requests_total{status=~"5.."}[5m]) / rate(nginx_ingress_controller_requests_total[5m]) > 0.05 for: 3m labels: severity: critical annotations: summary: "High error rate on ingress controller" description: "Error rate is {{ $value | humanizePercentage }}" - alert: IngressControllerDown expr: up{job="ingress-nginx-controller-metrics"} == 0 for: 1m labels: severity: critical annotations: summary: "Ingress controller is down" Capacity Planning 1. Traffic Pattern Analysis - Historical traffic analysis and trending - Peak usage identification and planning - Seasonal and business cycle considerations - Growth projection and capacity modeling 2. Load Testing Strategy # Load testing with realistic traffic patterns # Use tools like Artillery, k6, or JMeter # Example k6 load test script import http from 'k6/http'; import { check, sleep } from 'k6'; export let options = { stages: [ { duration: '2m', target: 100 }, // Ramp up { duration: '5m', target: 100 }, // Stay at 100 users { duration: '2m', target: 200 }, // Ramp up to 200 users { duration: '5m', target: 200 }, // Stay at 200 users { duration: '2m', target: 0 }, // Ramp down ], thresholds: { http_req_duration: ['p(95)<500'], // 95% of requests under 500ms http_req_failed: ['rate<0.05'], # Error rate under 5% }, }; export default function() { let response = http.get('https://api.company.com/health'); check(response, { 'status is 200': (r) => r.status === 200, }); sleep(1); } Best Practices for Production 1. High Availability Design - Multi-zone ingress controller deployment - Health check configuration and monitoring - Graceful shutdown and connection draining - Backup ingress controllers for disaster recovery 2. Security Considerations - Rate limiting and DDoS protection - Web Application Firewall (WAF) integration - SSL/TLS configuration hardening - Security headers and policy enforcement 3. Operational Excellence - Blue-green deployment for ingress updates - Canary releases for configuration changes - Automated rollback procedures - Regular performance testing and optimization

Nodes are a collection of resources within Kubernetes that support container(s). Depending upon the Kubernetes cluster, a node can be a physical machine or a virtual machine.

The kubectl describe pod command provides in-depth information about a specific pod within a Kubernetes cluster. It displays the pod's status, events, configuration, and other relevant details. To utilize this command, you need to specify the name of the pod you want to examine. For instance, to describe a pod named my-pod, you would use the following command: kubectl describe pod my-pod

Different services within Kubernetes: Include ClusterIP for internal cluster communication, NodePort to expose services on each node's IP at a static port, and LoadBalancer to expose the service externally using a cloud provider's load balancer.

A Pod is the smallest operational unit in Kubernetes. It's an abstraction that represents a group of one or more containers, sharing the same network namespace and storage volumes.

It is clear from the above file that the service "silicon" is a reference to a namespace called "chip".

Kubernetes operator is an extension of the Kubernetes API that enables the automation of complex application or cluster management operations.

etcd serves as Kubernetes' distributed database, storing all cluster state: API Server ↔ etcd Cluster ↔ All Kubernetes Resources (Pods, Services, ConfigMaps, etc.) Performance Impact: - etcd latency directly affects API server response times - etcd unavailability means cluster operations stop - etcd corruption can result in complete cluster failure Common Performance Degradation Causes 1. Storage Performance Issues Disk I/O Bottlenecks: - etcd is extremely sensitive to disk latency - Network-attached storage with high latency - Shared storage with other I/O-intensive workloads - Insufficient IOPS for write operations Storage Requirements: - etcd recommends dedicated SSD storage - Minimum 50 IOPS for small clusters - 500+ IOPS for production clusters - Low-latency storage (< 10ms write latency) 2. Memory and Configuration Issues Memory Pressure: - etcd keeps recently accessed data in memory - Insufficient memory leads to increased disk I/O - Memory fragmentation affecting performance Configuration Problems: - Inappropriate snapshot and compaction settings - Large database size due to lack of compaction - Quota limits being reached 3. Network Latency and Partitions Multi-Node Communication: - High network latency between etcd members - Network partitions causing leader election issues - Insufficient bandwidth for cluster communication Diagnostic Approach 1. Performance Metrics Analysis Key etcd Metrics: # Access etcd metrics (from within etcd pod) curl http://localhost:2379/metrics | grep -E "etcd_server_has_leader|etcd_server_leader_changes_seen_total|etcd_disk_wal_fsync_duration_seconds|etcd_disk_backend_commit_duration_seconds" Critical metrics to monitor: etcd_server_has_leader: Should always be 1 etcd_server_leader_changes_seen_total: Frequent changes indicate instability etcd_disk_wal_fsync_duration_seconds: Write latency to disk etcd_disk_backend_commit_duration_seconds: Transaction commit time etcd_network_peer_round_trip_time_seconds: Network latency between members 2. Cluster Health Assessment # Check cluster health ETCDCTL_API=3 etcdctl endpoint health --cluster ETCDCTL_API=3 etcdctl endpoint status --write-out=table --cluster # Check member list and leadership ETCDCTL_API=3 etcdctl member list --write-out=table High Availability Architecture 1. Multi-Member Cluster Design Optimal Member Count: 3 Members: Tolerates 1 failure (minimum for production) 5 Members: Tolerates 2 failures (recommended for critical workloads) 7 Members: Tolerates 3 failures (for extremely critical environments) Geographic Distribution: Multi-AZ Deployment: Member 1: Availability Zone A Member 2: Availability Zone B Member 3: Availability Zone C Benefits of multi-AZ deployment: - Survives entire availability zone failures - Reduces correlated failures - Improves overall cluster resilience 2. Leader Election and Consensus Raft Consensus Algorithm: etcd uses Raft for distributed consensus, requiring a majority (quorum) for decisions: 3-member cluster: Needs 2 members for quorum 5-member cluster: Needs 3 members for quorum 7-member cluster: Needs 4 members for quorum Leadership Stability: - Stable leadership is crucial for performance - Frequent leader changes indicate network or performance issues - Leader election timeout tuning affects failover speed Performance Optimization 1. Storage Configuration Optimal etcd Configuration: apiVersion: v1 kind: Pod metadata: name: etcd spec: containers: - name: etcd image: k8s.gcr.io/etcd:3.5.0 command: - etcd - --data-dir=/var/lib/etcd - --quota-backend-bytes=8589934592 # 8GB database size limit - --auto-compaction-retention=1000 # Keep 1000 revisions - --auto-compaction-mode=revision # Compaction by revision count - --snapshot-count=5000 # Snapshot every 5000 operations - --heartbeat-interval=100 # 100ms heartbeat interval - --election-timeout=1000 # 1000ms election timeout Key configuration parameters: quota-backend-bytes: Prevents database from growing too large auto-compaction-retention: Automatically removes old data snapshot-count: Controls snapshot frequency for WAL log management heartbeat-interval: Balance between responsiveness and network overhead 2. Resource Allocation spec: containers: - name: etcd resources: requests: cpu: 100m memory: 512Mi limits: cpu: 200m memory: 1Gi volumeMounts: - name: etcd-data mountPath: /var/lib/etcd volumes: - name: etcd-data hostPath: path: /var/lib/etcd type: DirectoryOrCreate Resource considerations: - Dedicated CPU cores for etcd in large clusters - Sufficient memory for caching frequently accessed data - Dedicated storage volumes with appropriate performance characteristics Backup and Recovery Strategy 1. Automated Backup Procedures #!/bin/bash # Automated etcd backup script BACKUP_DIR="/backup/etcd" DATE=$(date +%Y%m%d-%H%M%S) # Create snapshot ETCDCTL_API=3 etcdctl snapshot save ${BACKUP_DIR}/etcd-snapshot-${DATE}.db \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key # Verify snapshot integrity ETCDCTL_API=3 etcdctl snapshot status ${BACKUP_DIR}/etcd-snapshot-${DATE}.db # Clean up old backups (keep 7 days) find ${BACKUP_DIR} -name "etcd-snapshot-*.db" -mtime +7 -delete 2. Disaster Recovery Procedures Cluster Restore Process: - Stop all etcd members - Remove existing data directories - Restore from snapshot on all members - Update cluster membership configuration - Start etcd members with new cluster configuration Monitoring and Alerting 1. Performance Monitoring Critical SLI/SLO Definitions: - Write latency < 25ms (99th percentile) - Read latency < 5ms (99th percentile) - Leader election frequency < 1 per hour - Database size within quota limits 2. Alerting Strategy # Prometheus alert rules for etcd groups: - name: etcd.rules rules: - alert: etcdInsufficientMembers expr: count(etcd_server_has_leader) < 3 for: 3m labels: severity: critical annotations: summary: "etcd cluster has insufficient members" - alert: etcdHighCommitDurations expr: histogram_quantile(0.99, etcd_disk_backend_commit_duration_seconds_bucket) > 0.25 for: 2m labels: severity: warning annotations: summary: "etcd commit durations are high" - alert: etcdHighFsyncDurations expr: histogram_quantile(0.99, etcd_disk_wal_fsync_duration_seconds_bucket) > 0.5 for: 2m labels: severity: warning annotations: summary: "etcd WAL fsync durations are high" Advanced Optimization Techniques 1. Database Maintenance Manual Compaction (when needed): # Compact etcd database to reclaim space ETCDCTL_API=3 etcdctl compact $(ETCDCTL_API=3 etcdctl endpoint status --write-out="json" | jq -r '.[] | .Status.header.revision') # Defragment database ETCDCTL_API=3 etcdctl defrag --cluster 2. Capacity Planning Growth Monitoring: - Track database size growth rate - Monitor revision accumulation - Plan for peak usage scenarios - Implement automated maintenance procedures 3. Network Optimization Dedicated Network for etcd: - Separate network interfaces for etcd traffic - Low-latency network configuration - Bandwidth allocation for cluster communication - Network security and isolation Production Best Practices 1. Infrastructure Design - Dedicated nodes for etcd (separate from worker nodes) - High-performance SSD storage with adequate IOPS - Network redundancy and low-latency connections - Regular performance benchmarking and testing 2. Operational Excellence - Automated backup and recovery procedures - Regular disaster recovery testing - Performance monitoring and capacity planning - Security hardening and access control 3. Upgrade and Maintenance - Rolling upgrade procedures for etcd clusters - Compatibility testing between etcd and Kubernetes versions - Change management for configuration updates - Regular security patching and vulnerability management

Kubernetes provides a built-in secret's API resource for securely storing sensitive information such as passwords, API keys, and other confidential data. Kubernetes also allows for configuration management using config maps, which can be used to store non-sensitive configuration data as key-value pairs

Pods in a cluster of k8s can speak to one another by default use the internal IP addresses. The underlying container runtime or network plugin gives a virtual network overlay to this communication.

Kubernetes handles persistent storage via Persistent Volumes (PVs) and Persistent Volume Claims (PVCs), supporting various storage backends. Dynamic provisioning automates PV creation in response to PVC requests, ensuring consistent and reliable storage allocation without manual intervention, facilitating stateful application management.

A Deployment manages the lifecycle of Pods through ReplicaSets. When you update a Deployment (e.g., changing the image tag), Kubernetes creates a new ReplicaSet, scales it up gradually, and scales down the old one, thereby avoiding downtime. # Update the image kubectl set image deployment/my-app app=nginx:1.28 # Watch the rollout progress kubectl rollout status deployment/my-app # View rollout history kubectl rollout history deployment/my-app # Roll back if something goes wrong kubectl rollout undo deployment/my-app You can control the speed using maxSurge and maxUnavailable in the Deployment's strategy section.

A Kubernetes namespace is a way to divide cluster resources between multiple users or teams. It provides a way to isolate resources and prevent naming conflicts. On the other hand, Kubernetes labels are key-value pairs attached to Kubernetes objects to help identify and organize them.

As an extension to K8, the operator provides the capability of managing applications and their components using custom resources. Operators generally comply with all the principles relating to Kubernetes, especially those relating to the control loops.

Kubernetes kubectl logs is the command to retrieve the logs generated by a specific pod.

Persistent Volume Claims (PVCs) can reference storage classes to enable dynamic provisioning of Persistent Volumes based on specified storage infrastructure requirements.

ConfigMaps store non-sensitive configuration data that can be consumed by pods or used to configure software components. Secrets store sensitive information such as passwords, tokens, or keys, protecting them within the cluster.

A Custom Resource Definition (CRD) extends Kubernetes APIs, allowing users to define and manage custom resources. They are used for specific use cases where the Kubernetes API should still be used for managing these resources, such as: - Managing custom applications (e.g., Machine learning models). - Enabling Kubernetes operators for self-healing applications. Example CRD YAML definition: apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: shirts.stable.example.com spec: group: stable.example.com scope: Namespaced names: plural: shirts singular: shirt kind: Shirt versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: color: type: string size: type: string selectableFields: - jsonPath: .spec.color - jsonPath: .spec.size additionalPrinterColumns: - jsonPath: .spec.color name: Color type: string - jsonPath: .spec.size name: Size type: string You could now, for example, retrieve the shirt object using kubectl: kubectl get shirts

The kube-proxy runs on each of the nodes. It can do simple tasks such as TCP, UDP, forwarding, and so on. It shows the services in the Kubernetes API on each node.

Operators are custom Kubernetes controllers that automate the deployment, scaling, and management of complex stateful applications, encoding domain-specific operational knowledge.

Etcd is the key-value store that holds the entire cluster state. Regular backups are essential to avoid data loss. You can create a backup using the below command: ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \ --cacert= --cert= --key= \ snapshot save If you now want to restore from a backup, you can run: etcdutl --data-dir snapshot restore snapshot.db

The kube-proxy is responsible for managing network routing between pods and services in the Kubernetes cluster.

Kubernetes pod liveness probe is used to determine if a pod is alive and running.

The candidate should talk about centralized logging solutions (e.g., ELK stack, Loki) for aggregating logs from multiple sources, and monitoring tools (e.g., Prometheus, Grafana) for tracking the health and performance of the cluster and applications. Advanced answers may include implementing custom metrics and alerts. Important Points to Mention: - Centralized logging enables aggregation, search, and analysis of logs from all components and applications within the Kubernetes cluster. - Monitoring with Prometheus and visualizing with Grafana provides insights into application performance and cluster health. - The importance of setting up alerts based on specific metrics to proactively address issues. Example You Can Give: “For a large e-commerce platform, we implemented an ELK stack for centralized logging, aggregating logs from all services for easy access and analysis. We used Prometheus for monitoring our Kubernetes cluster and services, with Grafana dashboards for real-time visualization of key performance metrics. We set up alerts for critical thresholds, such as high CPU or memory usage, enabling us to quickly identify and mitigate potential issues before they affected customers.” Hedge Your Answer: “Implementing comprehensive logging and monitoring in a large-scale Kubernetes environment is crucial but can introduce complexity and overhead, particularly in terms of resource consumption and management. Fine-tuning what metrics to collect and logs to retain is essential to balance visibility with operational efficiency. Additionally, the effectiveness of monitoring and logging systems is contingent upon proper configuration and regular maintenance to adapt to evolving application and infrastructure landscapes.”

Affinity and anti-affinity rules expand the types of constraints you can define for scheduling Pods. - Node Affinity: Attracts Pods to a set of nodes based on node labels. It is conceptually similar to nodeSelector but more expressive. - Inter-pod Affinity/Anti-affinity: Attracts or repels Pods from other Pods based on the labels of Pods already running on a node. This can be used to co-locate Pods of a service in the same availability zone (affinity) or spread them across different zones for high availability (anti-affinity).

Kubelet is an agent available at the node level and it is involved in executing pod needs, managing the resources, and monitoring the cluster health. Kubelet helps the IT teams connect K8s with the other APIs.

It is an API extension that is not always available in this tool. This is why APIs have to be installed in the system to build and access their components with kubectl. Its modularity enables users to build numerous core functions. With dynamic registration, it can be used anywhere in a running cluster. The cluster admin can also update the resources independently to integrate with external systems. It can extend the functionality of this platform for domain-specific concepts.

An Ingress Controller is responsible for managing access to services in a Kubernetes cluster by processing and fulfilling the rules set in Ingress Resources. This includes routing traffic from external sources to the correct internal services and managing SSL/TLS termination.

Key Kubernetes security best practices include strict access control, network segmentation, and workload hardening. - Use Role-Based Access Control (RBAC): Grant users and services the minimum necessary permissions to ensure secure access. Avoid using cluster-admin unless absolutely required. - Enable Audit Logging: Configure the audit log to monitor and trace access patterns, especially changes to sensitive resources. - Restrict API Server Access: Limit external access to the Kubernetes API server using firewalls or private networking. - Use Network Policies: Define NetworkPolicy objects to control traffic flow between pods, enforcing least-privilege communication. - Run Containers as Non-Root: Avoid running containers with root privileges. Set runAsUser, readOnlyRootFilesystem, and drop unnecessary Linux capabilities. Use correct security context settings to enforce this. - Keep Kubernetes and Dependencies Updated: Regularly patch the control plane, kubelets, and third-party tools to address known vulnerabilities. - Scan Your Cluster Regularly: Use security tools to detect vulnerabilities in workloads and infrastructure. See Kubernetes security tools for options. - Use Pod Security Standards: Apply PodSecurity admission or tools like OPA Gatekeeper to enforce pod-level security controls. - Limit Secret Exposure: Store secrets encrypted and only mount them where necessary. Use tools like Vault or native Kubernetes encryption at rest. - Prevent Misconfigurations with Admission Controls: Use Validating Admission Policies or webhooks to block insecure resource definitions at creation.

Service Accounts in Kubernetes provide an identity for processes that run in a Pod. They are used to control API access within the cluster and to provide Pods with the necessary permissions to interact with other Kubernetes resources. Service Accounts help manage the security and access control by defining: - Permissions: What actions a Pod can perform. - Token authentication: Tokens are automatically mounted into Pods and can be used to authenticate against the API server. Example of creating a Service Account: kubectl create serviceaccount my-serviceaccount Binding it to a role: kubectl create rolebinding my-binding --role=my-role --serviceaccount=default:my-serviceaccount Service Accounts provide fine-grained access control and are essential for managing security in a Kubernetes cluster.

The load balancing is related to services. In this platform, two kinds of load balancing are available. - Internal Load Balancer - External Load Balancer

Labels are key/value pairs attached to objects that help organize and select resources. Selectors filter resources based on those labels. apiVersion: v1 kind: Pod metadata: name: web-pod labels: app: web environment: production spec: containers: - name: nginx image: nginx:1.27 You can then query for Pods using label selectors: # Get all production pods kubectl get pods -l environment=production # Get all pods for the web app in production kubectl get pods -l app=web,environment=production Services, Deployments, and NetworkPolicies all use selectors to target the right set of Pods.

A Pod Disruption Budget (PDB) in Kubernetes ensures that a specified minimum number of pods remain running during voluntary disruptions like upgrades or maintenance. PDBs protect applications' availability, preventing the system from evicting too many pods from a service, crucial for maintaining service reliability and availability during operational activities.

A container is a single, isolated process. A Pod is a logical host for one or more tightly coupled containers that need to share resources. Containers within the same Pod share the same network namespace (they can communicate via localhost) and can share storage volumes. While a Pod can contain a single container, the Pod itself is the object that Kubernetes manages, schedules, and scales.

For many years, Docker was the default container runtime in Kubernetes. However, this changed when Kubernetes removed direct Docker support (known as dockershim) in version 1.24. From that point on, Kubernetes moved fully to runtimes that implement the Container Runtime Interface (CRI), such as containerd and CRI-O. This highlights an important point: Kubernetes is not tied to any single container runtime. Docker still plays an important role in the broader ecosystem. It is widely used to build, package, and distribute applications and their dependencies as container images. Those images follow the OCI (Open Container Initiative) standard, which means they can be run by any compliant runtime — including the CRI-based runtimes used by Kubernetes. So you can continue building images with Docker and run them on Kubernetes without issue. The key distinction is that Docker focuses on building and running containers, while Kubernetes is designed to orchestrate containers at scale. They address different layers of the container stack and are often used together, but Kubernetes does not depend on Docker itself to operate.

A canary deployment involves releasing a new version of an application to a subset of users or nodes to test its performance and stability before a full rollout.

Kubernetes assigns Quality of Service (QoS) classes to pods (Guaranteed, Burstable, BestEffort) based on their resource requests and limits. QoS influences pod scheduling and eviction priorities, ensuring critical services get the necessary resources and maintain stable performance, while less critical pods can be adjusted or evicted based on cluster resource needs.

The kube-scheduler acts as the default matchmaking engine for your Kubernetes cluster. Its primary job is to watch for newly created Pods with no assigned Node and select the optimal machine for them to run on. It makes this decision through a two-step process: - Filtering: It eliminates Nodes that don't meet the Pod's specific requirements (e.g., insufficient CPU/Memory, missing hardware like GPUs, or matching Taints). - Scoring: It ranks the remaining healthy Nodes based on rules like Pod affinity/anti-affinity and resource utilization, assigning the Pod to the highest-scoring Node.

A Job creates one or more Pods and ensures that a specified number of them complete successfully. A CronJob manages Jobs that run on a repeating schedule, like a cron utility.

init containers will set a stage for you before running the actual POD. Wait for some time before starting the app Container with a command like sleep 60. Clone a git repository into a volume.

To persist the application-related data, we need to create PVC and use it as a mount point while creating a Pod. Below is an example of creating a PVC. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-application spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi After creating a PVC, the name of the PVC needs to be referred to in the Pod definition file. apiVersion: v1 kind: Pod metadata: name: nginx-pod-pvc spec: volumes: - name: pod-volume-pvc persistentVolumeClaim: claimName: pvc-application containers: - name: task-pv-container image: nginx ports: - containerPort: 80 volumeMounts: - mountPath: "/data/nginx/" name: pod-volume-pvc

This is usually one of the first questions in a Kubernetes interview. The interviewer wants to see that you understand the overall layout, not just a list of component names. Structuring your answer around how the pieces relate to each other shows that you can do more than memorizing documentation. Kubernetes is primarily split into the control plane and worker nodes. On the worker nodes, which is where your pods actually end up running, the key components include: - Kubelet: The agent running on each node that talks to the control plane. It receives instructions from the API server and makes sure the containers in its pods are running as expected. - Kube-proxy: Handles networking on each node. It maintains network rules that allow pods to communicate with each other and with services outside the cluster. - Container runtime: The software responsible for actually running containers (such as containerd or CRI-O). The control plane, which is responsible for making decisions about the cluster and responding to events (like a pod crashing or a new deployment being created), consists of: - Kube-apiserver: The central point of communication. Every component in the cluster, including kubectl commands, talks to the cluster through this API. - etcd: A key-value store that holds all cluster state. When you create a deployment or a service, that information lives in etcd. - Kube-scheduler: Watches for newly created pods that have no node assigned and selects a suitable node for them to run on, based on resource availability and constraints. - Controller manager: A collection of controllers bundled into a single process. Each controller watches for a specific type of resource and works to move the current state toward the desired state. For example, the ReplicaSet controller ensures the correct number of pod replicas are running. Answering this way, by grouping components under where they run and what role they serve, tells the interviewer you understand the architecture as a system rather than treating it as a flat list of terms.

Reviewing the ETCD member list helps verify the current members, their status, and the health of each member, which is vital for troubleshooting database failures.

ClusterIP for internal communication, NodePort to expose on each node's IP, LoadBalancer for external access.

Service discovery in Kubernetes automatically assigns a stable DNS name and IP address to each service, allowing other pods to discover and communicate with services reliably. This mechanism simplifies internal communication within the cluster, ensuring that services can easily locate and connect with each other regardless of node placement.

A Kubernetes Controller Manager is a Kubernetes control plane component that runs controller processes. It ensures the desired state of the cluster matches the observed state. It is a daemon that embeds the core control loops shipped with Kubernetes. Some types of these controllers are: - Node controller - Job controller - Replication controller - Endpoints controller - Service Account & Token controller

Pods are the smallest deployable unit in Kubernetes. They group one or more containers, such as an application instance and a logging sidecar. The containers within a Pod are managed as a single resource, always run on the same Node, and share a network namespace. Pods are automatically replaced with new ones if they fail, helping ensure reliable operations.

Kubernetes is the Linux kernel which is used for distributed systems. It helps you to be abstract the underlying hardware of the nodes(servers) and offers a consistent interface for applications that consume the shared pool of resources.

A Namespace is a way to logically partition resources within a single cluster. You'd use them to separate teams, environments (dev vs. staging), or to apply different resource quotas and access controls. # Create a namespace kubectl create namespace dev # Deploy a pod into that namespace kubectl run nginx --image=nginx --namespace=dev # List pods in that namespace kubectl get pods --namespace=dev By default, Kubernetes provides the default , kube-node-lease , kube-system , and kube-public Namespaces. Most production clusters create additional ones to organize workloads.

LoadBalancer a service that distributes incoming network traffic across multiple backend Kubernetes pods to ensure reliability and availability.

Minikube is a lightweight implementation of Kubernetes, which creates a VM on your local machine. It is a tool that sets the Kubernetes environment on your laptop or PC, and it addresses a different type of use case than most other distributions, such as Rancher, EKS, and OpenShift. It creates a lightweight, self-contained environment with all the necessary components for running Kubernetes, such as the API server, etcd, and kubelet. This allows developers to experiment with Kubernetes without the need for a full-scale production environment.

In Kubernetes, the imperative approach involves giving direct commands to perform actions on the cluster, like creating or updating resources manually. Declarative approach, however, involves defining the desired state of the cluster in configuration files and letting Kubernetes make changes to match that state. I prefer the declarative approach as it provides better scalability, version control, and easier rollback capabilities, aligning with Kubernetes' design philosophy of declaring desired states for resources.

Mainly K8 cluster consists of two types of nodes, executor and master. Executor node: (This runs on master node) - Kube-proxy: This service is responsible for the communication of pods within the cluster and to the outside network, which runs on every node. This service is responsible to maintain network protocols when your pod establishes a network communication. - kubelet: Each node has a running kubelet service that updates the running node accordingly with the configuration(YAML or JSON) file. NOTE: kubelet service is only for containers created by Kubernetes. Master services: - Kube-apiserver: Master API service which acts as an entry point to K8 cluster. - Kube-scheduler: Schedule PODs according to available resources on executor nodes. - Kube-controller-manager: is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired stable state

Container orchestration involves automating a significant portion of the operational tasks needed to operate containerized workloads and services. This includes various responsibilities that software teams must handle throughout a container's lifecycle, such as provisioning, deploying, scaling (both up and down), managing networking, load balancing, and other related functions.

Companies use Kubernetes to manage orchestration and IT workloads with high efficiency.

Architectural Approaches Pattern 1: VPN Gateway Pods External Database (via VPN) ↑ VPN Gateway Pods (Multiple replicas) ↑ Internal Service (Load balancing) ↑ Application Pods Pattern 2: Database Proxy Pattern External Database (via VPN) ↑ Database Proxy Pods (With VPN client) ↑ Database Service (Stable endpoint) ↑ Application Pods (No VPN knowledge) Design Considerations 1. High Availability Requirements VPN connections are inherently stateful, making HA challenging: - Multiple VPN endpoints: Deploy VPN clients on multiple nodes - Connection health monitoring: Implement health checks for VPN connectivity - Failover mechanisms: Automatic switching between VPN connections - Geographic distribution: VPN gateways in different availability zones 2. Security Architecture Network Segmentation: - VPN pods run in dedicated namespace with restricted permissions - Network policies isolating VPN traffic from other workloads - Dedicated service accounts with minimal RBAC permissions Secret Management: - VPN certificates and keys stored in Kubernetes secrets - Rotation procedures for VPN credentials - Integration with external secret management systems 3. Traffic Flow Design Option A: Direct VPN Client Pattern: Each application pod includes a VPN client sidecar. Provides maximum security but increases complexity. Option B: Shared VPN Gateway: Centralized VPN gateways that multiple applications use. Simpler to manage but creates a shared component. Option C: Database Proxy Pattern: VPN connectivity is hidden behind a database proxy service. Applications connect to the proxy using standard database protocols. Implementation Strategy VPN Gateway as Infrastructure Treat VPN connectivity as cluster infrastructure rather than application-specific components: # VPN gateway pods with high availability apiVersion: apps/v1 kind: Deployment metadata: name: vpn-gateway namespace: infrastructure spec: replicas: 3 # HA across nodes strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 # Ensure VPN availability during updates Key configuration elements: replicas: 3: Ensures multiple VPN connections maxUnavailable: 1: Maintains VPN availability during rolling updates - Dedicated namespace for security isolation Database Connectivity Layer # Database proxy service providing stable endpoint apiVersion: v1 kind: Service metadata: name: external-database namespace: infrastructure spec: selector: app: db-proxy ports: - port: 5432 # Standard PostgreSQL port targetPort: 5432 type: ClusterIP # Internal access only The service provides a stable endpoint (external-database.infrastructure.svc.cluster.local) that applications can use without VPN knowledge. Operational Considerations Monitoring and Alerting - VPN connection status and latency monitoring - Database connectivity health checks - Traffic flow analysis and bottleneck detection Disaster Recovery - Backup VPN configurations and certificates - Automated failover procedures - Cross-region VPN connectivity options Performance Optimization - Connection pooling at the proxy layer - Caching strategies for frequently accessed data - Traffic compression and optimization Security Best Practices 1. Principle of Least Privilege - VPN pods run with minimal required permissions - Network policies restricting VPN pod communications - Dedicated service accounts with specific RBAC rules 2. Defense in Depth - Multiple layers of security (network, application, data) - Regular security audits and penetration testing - Compliance with regulatory requirements 3. Operational Security - Secure credential rotation procedures - Audit logging for all VPN connections - Integration with security monitoring systems

Deploying on hosts involves installing applications directly on servers, requiring manual scaling and updates. Containers abstract the application from the host, providing isolated environments, making scaling and updating more efficient.

StatefulSets are Kubernetes resources used to manage stateful applications by providing stable network identities, persistent storage, and ordered deployment and scaling.

HPA automatically scales pods based on CPU/memory utilization or custom metrics. It monitors pod usage and adjusts the replica count dynamically.

Labels are key-value pairs attached to Kubernetes objects like Pods, Nodes, and Services. They are used to organize and select subsets of objects based on specific criteria. Selectors allow you to define queries to identify these subsets. Types of selectors include: - Equality-based selectors: Match labels exactly ( key=value ). - Set-based selectors: Match labels based on set operations (e.g., key in (value1, value2) ). Labels and selectors are essential for grouping and managing Kubernetes resources efficiently.

Kubernetes automates application deployment, scaling, and management, making it easy to deploy and manage container-based applications at scale. Other benefits include: Simplified application management Improved scaling and availability Easy deployment and rollback Improved resource utilization Increased portability and flexibility

Using strategies like canary deployments, rolling updates with maxSurge and maxUnavailable, and health checks to detect failures early and roll back automatically.

Container images represent a significant attack vector: Untrusted Registry → Malicious Images → Compromised Containers → Cluster Breach Common threats: - Malware embedded in public images - Supply chain attacks through compromised base images - Vulnerable dependencies in application layers - Unauthorized access to sensitive registries Policy Enforcement Approaches 1. Admission Controller Pattern Admission controllers intercept and validate requests before objects are created: kubectl apply → API Server → Admission Controllers → etcd Storage ↓ Policy Validation (Allow/Deny Decision) 2. OPA Gatekeeper Implementation Open Policy Agent (OPA) Gatekeeper provides flexible policy enforcement: # Constraint Template for allowed registries apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: allowedregistries spec: crd: spec: names: kind: AllowedRegistries validation: properties: registries: type: array items: type: string targets: - target: admission.k8s.gatekeeper.sh rego: | package allowedregistries violation[{"msg": msg}] { container := input.review.object.spec.containers[_] image := container.image not startswith(image, input.parameters.registries[_]) msg := sprintf("Image '%v' is not from allowed registry. Allowed registries: %v", [image, input.parameters.registries]) } violation[{"msg": msg}] { container := input.review.object.spec.initContainers[_] image := container.image not startswith(image, input.parameters.registries[_]) msg := sprintf("Init container image '%v' is not from allowed registry", [image]) } Key components of the template: ConstraintTemplate: Defines the policy logic in Rego language Image validation against allowed registry list Support for both regular and init containers Descriptive error messages for policy violations 3. Policy Application # Apply the constraint to specific namespaces apiVersion: constraints.gatekeeper.sh/v1beta1 kind: AllowedRegistries metadata: name: must-use-internal-registry spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] - apiGroups: ["apps"] kinds: ["Deployment", "ReplicaSet", "DaemonSet", "StatefulSet"] namespaces: ["production", "staging"] # Enforce in specific namespaces parameters: registries: - "internal-registry.company.com/" - "registry.company.com/" - "gcr.io/company-project/" # Allow specific public repos Alternative Enforcement Mechanisms 1. ValidatingAdmissionWebhook Custom admission webhook for complex validation logic: apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionWebhook metadata: name: image-policy-webhook webhooks: - name: image-policy.company.com clientConfig: service: name: image-policy-service namespace: security-system path: "/validate-image" rules: - operations: ["CREATE", "UPDATE"] apiGroups: [""] apiVersions: ["v1"] resources: ["pods"] - operations: ["CREATE", "UPDATE"] apiGroups: ["apps"] apiVersions: ["v1"] resources: ["deployments", "replicasets", "daemonsets", "statefulsets"] admissionReviewVersions: ["v1", "v1beta1"] failurePolicy: Fail # Deny if webhook unavailable Benefits of custom webhooks: - Complex validation logic beyond simple string matching - Integration with external security scanning systems - Real-time vulnerability assessment - Custom business logic enforcement 2. Pod Security Standards Kubernetes native security policies: apiVersion: v1 kind: Namespace metadata: name: production labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/audit: restricted pod-security.kubernetes.io/warn: restricted pod-security.kubernetes.io/enforce-version: latest Security levels: - Privileged: Unrestricted (allows known privilege escalations) - Baseline: Minimally restrictive (prevents known privilege escalations) - Restricted: Heavily restricted (follows pod hardening best practices) Image Scanning Integration 1. Pre-Deployment Scanning # Admission controller with image scanning apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionWebhook metadata: name: image-scan-webhook webhooks: - name: scan.security.company.com clientConfig: service: name: image-scan-service namespace: security-system path: "/scan-and-validate" rules: - operations: ["CREATE", "UPDATE"] apiGroups: [""] apiVersions: ["v1"] resources: ["pods"] timeoutSeconds: 30 # Allow time for scanning failurePolicy: Fail Scanning workflow: - Extract image references from pod specification - Trigger vulnerability scan if not already scanned - Check scan results against security policies - Allow or deny based on vulnerability assessment 2. Continuous Monitoring Implement ongoing image monitoring for deployed workloads: - Regular vulnerability database updates - Automated alerts for newly discovered vulnerabilities - Policy-driven remediation workflows - Compliance reporting and audit trails Registry Access Control 1. Network-Level Restrictions # Network policy restricting registry access apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: registry-access-control namespace: production spec: podSelector: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: name: registry-system # Internal registry namespace ports: - protocol: TCP port: 5000 - to: [] # Block external registry access ports: - protocol: TCP port: 443 - protocol: TCP port: 80 2. Authentication and Authorization Image Pull Secrets Management: apiVersion: v1 kind: Secret metadata: name: internal-registry-secret namespace: production type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: --- apiVersion: v1 kind: ServiceAccount metadata: name: app-service-account namespace: production imagePullSecrets: - name: internal-registry-secret automountServiceAccountToken: false # Security best practice Registry authentication strategies: - Service account-based authentication - Short-lived token rotation - Role-based access control (RBAC) integration - Audit logging for registry access Exemption and Emergency Procedures 1. Emergency Override Mechanisms # Emergency namespace exempt from registry policies apiVersion: v1 kind: Namespace metadata: name: emergency-response labels: policy.company.com/registry-exempt: "true" policy.company.com/emergency: "true" 2. Temporary Policy Exemptions # Time-limited policy exemption apiVersion: constraints.gatekeeper.sh/v1beta1 kind: AllowedRegistries metadata: name: production-registry-policy spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] excludedNamespaces: ["emergency-response", "incident-response"] parameters: registries: - "internal-registry.company.com/" Monitoring and Compliance 1. Policy Violation Monitoring Track and alert on policy violations: - Failed admission attempts due to registry violations - Unauthorized registry access attempts - Policy exemption usage patterns - Compliance dashboard and reporting 2. Audit and Compliance # Audit policy for image-related events apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Metadata resources: - group: "" resources: ["pods"] namespaces: ["production", "staging"] annotations: audit.company.com/image-policy: "enforced" Compliance requirements: - Regulatory compliance (SOX, HIPAA, PCI-DSS) - Industry standards (CIS Kubernetes Benchmark) - Internal security policies and governance - Supply chain security requirements Best Practices for Production 1. Layered Security Approach - Multiple policy enforcement points - Defense in depth with overlapping controls - Continuous monitoring and alerting - Regular policy effectiveness testing 2. Operational Excellence - Clear exemption procedures for emergencies - Regular policy review and updates - Training for development teams - Integration with CI/CD pipelines 3. Performance Considerations - Efficient policy evaluation algorithms - Caching of scan results and policy decisions - Minimal impact on deployment velocity - Graceful degradation during policy system outages

These are all workload controllers, but they serve different purposes based on the nature of the application. - Deployment: The most common controller, used for stateless applications where any Pod can be replaced by another without loss of service. Pods are interchangeable. - StatefulSet: Used for stateful applications that require stable, unique network identifiers, stable persistent storage, and ordered deployment and scaling. Examples include databases or message queues. - DaemonSet: Ensures that all (or some) nodes run a copy of a Pod. This is useful for cluster-level agents like log collectors, monitoring agents, or storage daemons that must run on every node.

Secrets can be encrypted at rest using etcd encryption, managed via RBAC for access control, and injected into pods securely without exposing sensitive data.

Kubernetes controller manager runs controller processes, handling routine tasks in the cluster, such as replicating pods and handling node operations.

Ingress and Ingress Controllers work together to manage external access to services within a Kubernetes cluster, especially for HTTP/HTTPS traffic. Ingress - A Kubernetes API object that defines Layer 7 routing rules. - Routes traffic based on hostnames (e.g., api.example.com ) or paths (e.g.,/users ). - Enables centralized and declarative management of external access. Ingress Controller - A runtime component that enforces the rules defined in the Ingress object. - Acts as a reverse proxy or load balancer (e.g., NGINX, Traefik, cloud-native options). - Must be deployed separately-Ingress rules alone don't function without it.

Taints and tolerations in Kubernetes control pod placement on nodes. Nodes can be tainted to reject certain pods unless those pods.

In Kubernetes, a Pod serves as the smallest deployable unit, generally encapsulating a single application. The primary function of the Pod is to provide a cohesive context for executing one or more containers. - Context Sharing: Containers within the same Pod share a common network namespace, hostname, and storage volumes, optimizing their interactions. - Logical Bundling: Designates one of the containers as the primary application with the remaining containers often providing supplementary services or shared resources. - Atomicity: Containers in a single Pod are scheduled onto the same node and execute in close proximity. This ensures that they are either all running or all terminated. - Networking: Containers within the same Pod are reachable via localhost and have a single, shared IP address. This design simplifies internal communication. - Resource Sharing: All containers in a Pod have identical resource-sharing provisions, ensuring that they have the same CPU and memory limits. - Storage Volumes: Shared volumes can be mounted across all containers within a Pod to promote data sharing among its constituent containers. - Lifecycle Coordination: Defines the life cycle for all containers in a Pod, such that if one container exits, the termination affects the entire Pod, consistent with the atomic execution concept. - Dedicated Workloads: Pods that host a single container are often used for self-sufficient, standalone tasks. These tasks have specific resource requirements and are designed to run independently. - Coordinated Workloads: Pods with multiple containers emphasize complementarity. These containers often tackle related tasks, such as syncing data, logging, or serving as administrative dashboards.

Kubernetes has become an essential system for containerized applications, allowing a maintained process of running application infrastructures. This has made containers an essential element for packaging your code along with the libraries and dependencies for the smooth running of your application. Containers ensure that there is no application downtime for users. This is possible because of rolling updates, which is the default deployment strategy for Kubernetes. When you try to update an application, you don't update all the instances of your application at once. It will result in an application outage where service will not be available during the period when the older version of your instances is down, and newer versions are up. In Kubernetes, you don't destroy all your instances; rather, you take down one older version of an instance at a time and bring up a newer version. This results in a seamless update of your application as the application never goes down during the process.

In Kubernetes, a ReplicaSet is a collection of pods that are always up and running. The replication controller's objectives are to ensure that a desired number of pod replicas are running at all times, and to maintain the desired state of the pods in the system. A ReplicaSet is a newer, more advanced concept that replaces replication controllers. A ReplicaSet allows you to define a minimum number of pods that must be up and running at all times, and provides a richer set of features than replication controllers. ReplicaSets are the basic building blocks of Kubernetes clusters. They provide the ability to have multiple copies of an application running in parallel, and to scale out (add more nodes) or scale in (remove nodes) the number of copies as needed. Replication controllers provide the ability to maintain a desired number of pod replicas for a particular application. A ReplicaSet ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless you require custom update orchestration or don't require updates at all.

The metrics server likely isn't reporting CPU or memory usage correctly. Without metric data, the HPA controller has nothing to act on and won't scale out.

GKE stands for Google Kubernetes Engine. It is a managed service provided by Google Cloud Platform that simplifies the deployment, scaling, and management of Kubernetes clusters.

Container resource monitoring means that you can keep track of CPU, Memory, and Disk space utilization for each container in your Kubernetes cluster. There are a two main ways to monitor the Kubernetes cluster. One way is to use the built-in kubectl command-line interface: this is able to monitor CPU utilization, memory usage and disk space. If you need to keep track of more data, then there's another way: to use a third-party monitoring tool such as Datadog, New Relic, or Prometheus.

A Kubernetes job runs a specific task to completion, such as running a batch job or performing a data processing task.

Kubectl is a command-line tool for Kubernetes that lets you control Kubernetes clusters.

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. It provides rules for routing traffic based on hostnames and paths to specific Services.

A Kubernetes deployment provides a declarative way to deploy and manage pods and replicas. Key characteristics of a deployment: - Specifies the desired state – number of replica pods to deploy - The deployment controller handles scaling up/down and rolling updates of pods - Supports rollback to previous versions - Maintains revision history of deployments - Offers availability and scaling guarantees for pods - Used in conjunction with pods, replicas, and replication controllers - Allows defining update strategies like rolling updates or blue-green deployments

A headless service is used to interface with service discovery mechanisms without being tied to a ClusterIP, therefore allowing you to directly reach pods without having to access them through a proxy. It is useful when neither load balancing nor a single Service IP is required.

Kubernetes and rolling updates: Supports rolling updates to deploy new versions incrementally with no downtime by gradually replacing instances of the previous version of an application with instances of the new version.

Docker is a container engine, it makes you build and run usually no more than one container at most, locally on your PC for development purposes. Docker Compose is a Docker utility to run multiple containers and let them share volumes and networking via the docker engine features, runs locally to emulate service composition and remotely on clusters. Docker Compose is mostly used as a helper when you want to start multiple Docker containers and don't want to start each one separately using docker run …. Docker Swarm is for running and connecting containers on multiple hosts. It does things like scaling, starting a new container when one crashes, networking containers. Kubernetes is a container orchestration platform, it takes care of running containers and enhancing the engine features so that containers can be composed and scaled to serve complex applications (sort of PaaS, managed by you or cloud provider). Kubernetes' goal is very similar to that for Docker Swarm but it's developer by Google.

Kubernetes affinities are rules that determine the preferred scheduling of pods based on various factors, such as the existence of a specific data volume or the location of a specific node.

When a node fails, Kubernetes automatically: - Marks the node as NotReady after missing heartbeat signals. - Evicts pods from the failing node if PodDisruptionBudgets allows it. - Reschedules workloads onto healthy nodes based on resource availability. For resiliency and high availability (HA): - Use multi-node control planes to avoid single points of failure. - Enable Pod Anti-Affinity to distribute workloads across nodes. - Implement self-healing mechanisms via liveness probes and auto-scaling.

A Service of type LoadBalancer operates primarily at Layer 4 (TCP/UDP) and exposes a single Service externally. In cloud environments, it typically provisions one external load balancer per Service, which can become costly at scale. An Ingress, on the other hand, operates at Layer 7 (HTTP/HTTPS) and provides routing rules (host-based and path-based) to direct traffic to multiple Services through a single entry point. apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: ingressClassName: nginx rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: my-app-service port: number: 80 Worth mentioning in interviews: Ingress is stable but feature-frozen, and Gateway API is the newer, more expressive successor for Kubernetes traffic management. Its core resources reached GA in Gateway API v1.0 (2023). It provides more expressive routing, better role separation, and support for protocols beyond HTTP.

Namespaces in Kubernetes logically isolate resources within a cluster. They help separate environments (such as dev, staging, and prod) or teams. Using a single default namespace is not a K8s best practice because: - It clutters resources, making them challenging to manage. - It increases security risks, as all resources share the same space. - It limits access control, as RBAC rules apply at the namespace level. Instead, you'll want to organize workloads into namespaces to improve security, scalability, and maintainability.