The headless service is like normal services, but without the Cluster IP. It enables direct access to pods without the need for a proxy.

Rolling updates in Kubernetes replace old pods with new ones incrementally, maintaining service availability. Managed through deployments, this process ensures that a certain number of pods are always operational, allowing for a smooth transition between versions and enabling quick rollbacks if issues arise, thus minimizing downtime.

This platform's architecture includes two main components, which are known as Master Node and Worker Node. Further these two have their in-built components within them. The master code consists Etcd, Kube-apiserver, Kube-scheduler and Kube-controller-manager. Whereas, the worker node includes Kube-proxy and Kubelet, which runs on each node. The Etcd helps to store the configuration of clusters.

With a traditional server setup, application logs are written to a file and then viewed either on each server or collected by a logging agent and sent to a centralized location. In Kubernetes, however, writing logs to disk from a pod is discouraged since you would then have to manage log files for pods. The better way is to have your application output logs to stdout and stderr. The kubelet on each node collects stdout and stderr on the running pods and then combines them into a log file managed by Kubernetes. Then you can use different kubectl commands to view the logs.

In Kubernetes, a Role is used to define permissions within a specific namespace, while a ClusterRole defines permissions across the entire cluster. This means that a Role is limited to a specific namespace and can only grant permissions within that namespace, whereas a ClusterRole can grant permissions across all namespaces in the cluster.

Kubernetes CRI-O is a container runtime designed specifically for Kubernetes, providing a lightweight and fast container runtime for Kubernetes environments.

You can easily roll back a failed rollout of a Kubernetes Deployment, StatefulSet, or DaemonSet using Kubectl. The kubectl rollout undo command will automatically revert the resource to its previous state. For instance, running kubectl rollout undo deployment/demo-deployment restores the previous configuration of the demo-deployment Deployment. However, when declaratively managing workloads using Kubernetes YAML files, “rolling forward” may be preferable to rolling back. This is where you fix the issue in your manifest files first, and then reapply them to your Kubernetes cluster as a new deployment using kubectl apply.

Pod-to-pod communication in Kubernetes relies on the cluster networking model. By default, Kubernetes expects a Container Network Interface (CNI) plugin to be installed. Once a network plugin such as Flannel or Weave is configured, every pod receives its own IP address and can communicate across nodes using the cluster network.

The kube – apiserver follows the scale-out architecture and, is the front-end of the master node control panel. This exposes all the APIs of the Kubernetes Master node components and is responsible for establishing communication between Kubernetes Node and the Kubernetes master components. The Kube-scheduler is responsible for distribution and management of workload on the worker nodes. So, it selects the most suitable node to run the unscheduled pod based on resource requirement and keeps a track of resource utilization. It ensures that the workload is not scheduled on already full nodes.

Kubernetes namespaces serve as a mechanism to partition a single cluster utilized by an organization into distinct and categorizable sub-clusters, each manageable independently. These individual clusters operate as separate modules, allowing users within different modules to interact and share information as needed.

Kubernetes VPA automatically adjusts the resource requirements of a pod based on the current resource usage.

Kubernetes provides immense value for managing containerized applications at an enterprise scale. Its primary advantages include: - Self-Healing: Automatically restarts failed containers, replaces them, and kills containers that don't respond to health checks. - Horizontal Scaling: Instantly scales applications up or down based on CPU usage or custom metrics (HPA). - Storage Orchestration: Automatically mounts your chosen storage system, whether local, cloud provider (AWS/GCP), or network-attached storage.

A Kubernetes Job creates one or more Pods and ensures that a specified number of them successfully terminate. It is used for batch processing or tasks that run to completion. Jobs are particularly useful for: - Running a script or task to completion. - Handling parallel processing with multiple Pods. - Running tasks that are not required to run continuously. There are also specialized jobs like CronJobs, which run Jobs on a scheduled basis.

StatefulSets and Deployments are both Kubernetes controllers used to manage the deployment and scaling of pods, but they serve different purposes: - Deployments: Used for stateless applications, where the state is not retained between pod restarts. Deployments ensure that the desired number of identical pods are running and can update them with rolling updates, rollback, and scaling. Pods in a Deployment are interchangeable, with no guarantees about ordering or uniqueness. - StatefulSets: Designed for stateful applications, where each pod has a unique identity and stable network identity. StatefulSets maintain a persistent identity for each pod, ensuring they are started in a specific order and retain their identities across rescheduling. This is crucial for applications that require stable storage or consistent network identifiers, such as databases. Choosing between the two depends on whether the application requires stable storage and unique identifiers (StatefulSets) or is fully stateless and can be managed with generic, interchangeable pods (Deployments).

Kubernetes provides several options for handling storage, including local storage, hostPath volumes, network-attached storage (NAS), and cloud-based storage. Each option has its pros and cons depending on the specific use case.

Declarative configuration is a method of software operations where you define what you want to be deployed, rather than the process of how the deployment happens. This concept plays a key role in the design of Kubernetes. You can use YAML manifest files to declaratively configure objects in your cluster, such as stating you want to deploy three replicas of a Pod using the nginx:latest image. After you apply the manifest, Kubernetes will automatically create the correct number of replicas in the desired configuration and ensure they remain running.

You can expose your application in Kubernetes using a Service, which defines a policy by which to access the pods. Services can be exposed via different types including ClusterIP, NodePort, and LoadBalancer.

Kubernetes leverages a consistent, centrally managed Domain Name System (DNS) for containers and services, offering ease of discovery and effictive communication within the cluster. In early versions of Kubernetes, SkyDNS powered service discovery. However, CoreDNS has succeeded it as the default DNS server. - CoreDNS is more extendable and easier to manage. - Its modular nature means you enable specific features through plugins. - Nodes and pods use kube-dns or coredns as their predefined DNS servers. - The DNS server typically resides within a Kubernetes cluster and knows all service names and their IP addresses. - On receiving a DNS query, the DNS server tracks IP changes and ensures name-to-IP mapping. - Pod Initiates DNS Request: A pod wants to connect to a service inside or outside the cluster. - DNS Query: The pod sends a DNS query via the specified server (K8s or custom). - DNS Server: The server processes the query. - Query Results: Based on pod's namespace, service name, and domain suffix, the DNS server returns the corresponding IP(s). - Service Discovery: Pods need to locate services. DNS offers an effective way, abstracting the complexity of directly handling service discovery. - Name Resolution: Pods and other entities use DNS to get a service's IP address. The DNS server ensures efficient updates, so pods always have the most accurate IP. - Direct Cluster IP: Services communicate via Cluster IP. - Unrestricted or Port-Defined Communication: Use the service type of "ClusterIP". - Custom Domains: For custom domains, specify appropriate service names so the DNS server properly resolves their IPs. Without namespace information, separate services with the same name and different namespaces might be unreachable. Including namespace info ensures accuracy. - pod / spec.dnsPolicy: Set ClusterFirst to utilize the default DNS service. - pod / spec.dnsConfig: Specify configs for custom DNS. - service : Utilize spec.clusterIP for manual IP assignments. This avoids potential IP address reassignment. - For multi-cluster communication, several solutions are available, including direct IP endpoint access and Ingress. DNS resolution strategies can consider these factors.

To implement this, you need to deploy 3 pods with those 3 data processing configurations. The config and app will be able to handle whenever a queue is called by a pod. To make sure they are accessible, leverage load balancing and a discovery mechanism.

In such a scenario it will be easy for the company to develop a CI/CD pipeline by making use of a methodology like DevOps. But they will face problems in configuring and running the pipeline. So after constructing the CI/CD pipeline, they can opt for carrying out later operations in the cloud platforms like Kubernetes. By working on the Kubernetes cloud platform they will not only get their job done at a low cost but will also save much time on deployment.

Kubernetes (K8s) is an open-source container orchestration platform that automates deploying, scaling, and managing containerized applications. It abstracts away infrastructure complexities, allowing teams to focus on building and running applications efficiently. Its popularity stems from simplifying microservices architectures, managing scalability, and enabling cloud-agnostic deployments. Kubernetes has overtaken Docker (Docker Swarm) as the de facto standard for running and managing containerized workloads across hybrid and multi-cloud environments.

A PersistentVolume (PV) is a piece of storage in the cluster that an administrator has provisioned, or dynamically provisioned using Storage Classes. It is a resource in the cluster that is independent of any individual Pod. A PersistentVolumeClaim (PVC) is a request for storage by a user. It is a declaration of storage needs such as size and access modes (e.g., ReadWriteOnce). Kubernetes matches PVCs to appropriate PVs, binding them together so that the storage can be used by Pods.

Kubernetes Deployment logs can be accessed using Kubectl. The kubectl logs command allows you to directly retrieve the logs from objects such as Pods and Deployments. For example, kubectl logs pod/demo-pod will display the logs from the Pod called demo-pod. You can optionally livestream new logs to your terminal window by including the --follow flag in your command. As an alternative to Kubectl, log collection tools like Fluentd and Logstash allow you to centrally monitor the logs from all the deployments in your cluster.

A node in Kubernetes is a worker machine which is also known as a minion. This node could be a physical machine or a virtual machine. For each node, there is a service to run pods, and it is managed by master components. The node services could include kubelet, kube-proxy, and so on.

Deployments are used to manage stateless applications with multiple replicas, while DaemonSets are used to ensure that a single Pod runs on every node in the cluster.

Kubernetes service mesh is a dedicated infrastructure layer for managing service-to-service communication within a Kubernetes cluster.

Deploying a database in Kubernetes will require a StatefulSet object, one or more Services, and Persistent Volumes. The StatefulSet is important because it ensures the Pods running the database replicas have stable identities and are created in order. For example, it ensures that replica-0 is created first, so it can assume the role of the database primary. The other replicas will then start in order, each with its own Persistent Volumes for storage. This ensures each replica maintains its own copy of the data. Services should then be created to route traffic to the replicas. For instance, a read-write Service may direct traffic to the primary replica (replica-0), whereas a read-only Service could load balance between all the available replicas. Dedicated Kubernetes Operators, available from database vendors, offer a simpler experience by fully automating the deployment process using Kubernetes CRDs.

A StatefulSet is a Kubernetes API object that supports data persistence. A StatefulSet is similar to a deployment, in that it's a collection of pods, However, in a deployment the given pod loses its data when it is destroyed. A StatefulSet enables a pod's information to be preserved and reattached to a newly created pod. A DaemonSet is an API object in which a copy of a given pod is run on each node in a Kubernetes cluster. Logging is a good example of the usefulness of a DaemonSet. A logging system typically uses an application called a collector to gather all the log information generated on each machine, and then forwards that information to a central location where it's aggregated. Configuring a log collector as a Kubernetes DaemonSet ensures that the collector is run installed on each node.

StatefulSets manage pods that need persistent storage and unique identifiers, while DaemonSets ensure that every selected node runs a copy of a specified pod.

RBAC is a security mechanism that restricts users and services based on their permissions. It consists of: - Roles and ClusterRoles: Define the actions allowed on resources. - RoleBindings and ClusterRoleBindings: Assign roles to users or service accounts. The following YAML shows an example role that only allows read-only access to Pods: apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] This pod-reader role can now be bound to a user using RoleBinding: apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-reader-binding subjects: - kind: User name: dummy roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

An Ingress is an API object that manages external access to the services in a cluster, typically HTTP. Ingress can provide load balancing, SSL termination, and name-based virtual hosting.

DaemonSets are used in Kubernetes when you need to run one or more pods on all (or a subset of) the nodes in a cluster. The typical use case for a DaemonSet is logging and monitoring for the hosts. For example, a node needs a service (daemon) that collects health or log data and pushes them to a central system or database. As the name suggests you can use daemon sets for running daemons (and other tools) that need to run on all nodes of a cluster. These can be things like cluster storage daemons (e.g. Quobyte, glusterd, ceph, etc.), log collectors (e.g. fluentd or logstash), or monitoring daemons (e.g. Prometheus Node Exporter, collectd, New Relic agent, etc.)

I'd choose a managed Kubernetes service for production because it reduces operational overhead, but in highly regulated industries, self-hosting might be necessary for compliance.

A pod is the smallest deployable unit in Kubernetes, which can contain one or more containers that share storage, network, and specifications on how to run the containers.

To debug a pod, run this: kubectl describe pod Scroll to the bottom where the events section lives. That is usually where Kubernetes tells you exactly what went wrong, whether it could not pull the image, could not schedule the pod, or something else entirely. If the pod is running but still acting up, the application itself might be the problem. Check the logs: kubectl logs If there are multiple containers inside that pod, Kubernetes needs to know which one you are asking about: kubectl logs -c The logs show what the container was doing before it crashed. Most debugging sessions start and end here.

Basically, there are 2 components of Kubernetes and those are master nodes and worker nodes. Further, these nodes have different components to support Kubernetes. Components of Master Nodes Components of Worker Nodes

Kubernetes also termed K8s or Kube, is an open-source container-based orchestrated platform that helps automate the manual process. It will be involved in deploying, controlling, and scaling the containerized applications.

Kubernetes uses the Secret resource to manage sensitive information such as passwords, OAuth tokens, and SSH keys. Secrets can be created using YAML files or the kubectl create secret command and can be mounted as volumes or exposed as environment variables in Pods. Secrets are base64-encoded and can be further secured by integrating with external secret management tools.

Google Container Engine (GKE) is open-source cluster management and container orchestration system. It is used to run and manage Docker containers. GKE supports only those clusters which run within Google's public cloud services. This engine schedules containers into a cluster. Then, it manages them automatically based on defined requirements.

Pod logs are a valuable source of information for troubleshooting. You can access them using the kubectl logs command.

Choosing cloud-agnostic storage solutions.

Kubernetes Kata Containers is a secure container runtime option for Kubernetes, providing hardware-implemented isolation to ensure security and isolation between containers.

Kubernetes scheduling policy is a set of rules and criteria used to determine which node in the cluster should run a specific pod.

Kubernetes deployments can be automated using various tools such as Helm, Kubernetes Operators, or GitOps workflows. Helm is a package manager for Kubernetes that allows users to define, install, and upgrade Kubernetes applications. While Kubernetes Operators are a Kubernetes-native way of automating application management, GitOps relies on Git as the source of truth for defining and deploying Kubernetes applications.

Ingress in Kubernetes is a collection of rules that allow inbound connections to reach the cluster services. It provides a way to define how external HTTP/S traffic should be routed to services within the cluster. An Ingress controller manages the routing rules defined in Ingress resources and can provide additional features such as SSL termination, load balancing, and name-based virtual hosting.

In Kubernetes, Services serve as an abstraction layer, enabling consistent access to Pods. Traffic is routed to Pods primarily via Selectors and Endpoints. - Selectors: - Purpose: Establish traffic endpoints based on matching labels. - Workflow: Pods are labelled, and Services are configured to match these labels. Upon connectivity, the Service pairs the request to Pods having corresponding labels. - Configuration: Defined in the Service configuration file. - Dynamic Mapping: Enables fine-grained control over which Pods receive traffic. - Endpoints: - Workflow: Automatically managed and updated. When Pods are created or terminated, corresponding Endpoints are adjusted to ensure traffic flow continuity. - ClusterIP: The default behavior, where each Service is assigned a stable internal IP, accessible only within the cluster. - NodePort: Exposes the Service on each Node's IP at a specific port, allowing external access. - LoadBalancer: Provisioned by an external cloud provider, creating a load balancer for accessing the Service from outside the cluster. - ExternalName: Maps a Service to a DNS name, effectively making the Service accessible from inside the cluster using that DNS name. - Session Affinity: - Purpose: Grants control over the duration for which subsequent requests from the same client are sent to the same Pod. - Measured Using Cookies: When set to ClientIP, the user's IP address is used to direct future requests to the same Pod. Using None ensures that each request is independently routed.

Kubernetes Custom Resource Definitions (CRDs) are custom object types added to your cluster. You can interact with CRDs in the same way as built-in objects, via the Kubernetes API and Kubectl. For instance, a PostgresDatabase CRD could hold config details for deploying a Postgres instance, or a SecurityPolicy CRD might contain information relevant to a specific security service. CRDs extend Kubernetes while respecting its standard architecture, making it easier to implement custom automation for advanced use cases.

Etcd is a distributed key-value store used by Kubernetes to store all data used to manage the cluster state. It's crucial for Kubernetes' distributed nature and ensures data consistency and high availability.

A Kubernetes replica set ensures that a specified number of replicas of a pod are running at any given time.

The reason that the service cannot bind to the pods in the deployment is because the labels in the deployment's pods do not match the service's selector field values. A service binds to a pod through a label match between a service selector and pod. When a service starts up, it “looks for” pods in the cluster with labels that are declared in the service's selector field. Figure 1 below illustrates the problem that exists in the manifest file above. Notice that the service in the figure below shows a Kubernetes service that has the selector values type=example and color=blue. Yet, the labels field of each of the pods in the Kubernetes deployment have the values type=example and color=red. The values in the service's selector field and the pods' labels fields do not match up. Hence, no binding. Figure 1: For a Kubernetes service to bind to a pod, the values in the service's selector field must match the values in the pods' labels fields. The values in the service's selector field and the pods' labels fields do NOT match up. Hence, no binding. To bind Kubernetes to the existing pods, change the values in the service's selector field to type=example and color=red.

Rising Kubernetes costs are becoming a major headache for many teams, making it challenging to keep spending in check without sacrificing scalability or innovation. It doesn't help that Kubernetes lacks a robust, built-in cost management solution. On top of that, many cost management tools fail to deliver the accuracy, detail, and control you need to keep costs in check — without slowing down engineering velocity or hindering scalability. Not CloudZero.

Daemon sets are a set of pods that runs on a host. They are used for host layers attributes like monitoring network or simple network.

A Pod is the smallest unit Kubernetes manages. Think of it as a wrapper around your container (or containers).

Load balancing is a way to distribute the incoming traffic into multiple backend servers, which is useful to ensure the application available to the users. In Kubernetes, as shown in the above figure all the incoming traffic lands to a single IP address on the load balancer which is a way to expose your service to outside the internet which routes the incoming traffic to a particular pod (via service) using an algorithm known as round-robin. Even if any pod goes down load balances are notified so that the traffic is not routed to that particular unavailable node. Thus load balancers in Kubernetes are responsible for distributing a set of tasks (incoming traffic) to the pods

The services that do not have cluster IPs are called headless services. These services allow the user to go to the pods directly. These services can let the user reach pods by going through a proxy. Instead, headless services enable direct contact with individual pods, making them excellent for scenarios in which clients must connect to specific pods directly rather than through a load balancer. In headless services, the service's DNS resolves to pod IPs, allowing you to circumvent the proxy that is generally used in standard Kubernetes services. This is especially beneficial in stateful systems like databases, where each pod needs to be individually addressable.

Refer to the above diagram. The left-side architecture represents deploying applications on hosts. So, this kind of architecture will have an operating system and then the operating system will have a kernel that will have various libraries installed on the operating system needed for the application. So, in this kind of framework you can have n number of applications and all the applications will share the libraries present in that operating system whereas while deploying applications in containers the architecture is a little different. This kind of architecture will have a kernel and that is the only thing that's going to be the only thing common between all the applications. So, if there's a particular application that needs Java then that particular application we'll get access to Java and if there's another application that needs Python then only that particular application will have access to Python. The individual blocks that you can see on the right side of the diagram are basically containerized and these are isolated from other applications. So, the applications have the necessary libraries and binaries isolated from the rest of the system, and cannot be encroached by any other application. Related Readings: Containers for Beginners

Kubernetes uses etcd as a consistent and highly-available key value store to keep all cluster data. This includes the state of the cluster, pod scheduling information, and metadata. It's critical for Kubernetes' operation, as it stores the configuration data that can be distributed among multiple nodes in the cluster.

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. Companies use it because it provides reliability, scalability, and portability across environments.

- Use immutable container images for better version control. - Automate deployments with Helm or Kustomize. - Implement progressive delivery (Canary, Blue-Green deployments). - Use GitOps for declarative deployments. - Monitor deployments with Prometheus and Grafana.

Namespaces in Kubernetes are used for dividing cluster resources between users. It helps the environment where more than one user spread projects or teams and provides a scope of resources.

Kubernetes Helm is a package manager for Kubernetes that helps you deploy, manage and upgrade Kubernetes applications.

Kube-scheduler distributes and manages the workload on the worker nodes. It uses various policies to select the most suitable node for a pod based on factors such as resource requirements, node capacity, and pod affinity/anti-affinity. The kube-scheduler component is also responsible for binding the selected node to the pod and updating the Kubernetes API server with the updated information.

Rolling updates in Kubernetes allow you to update the Pods in a Deployment to a new version without downtime. This can be done using the kubectl set image command or by updating the container image in the Deployment YAML file and applying it. For example: spec: containers: - name: my-app image: my-app:2.0 Then apply the updated file with: kubectl apply -f .yaml Kubernetes will gradually replace the old Pods with new ones, ensuring that the number of Pods available does not fall below the specified minimum during the update process.

The Kubernetes Federation allows you to manage multiple clusters from a single control plane, simplifying the management of distributed applications.

- Use NetworkPolicies with Calico or Cilium (EKS add-ons or CNI plugins). - Default-deny ingress/egress and explicitly allow permitted traffic.

In the master node, many types of controllers are accumulated all together to work as one procedure. These controllers are called the Kubernetes Controller Manager. The basic function of the Kubernetes controller manager is to embed controllers and generate namespace and garbage collection. It establishes communications with the API server and helps in the management of end-points. There are basically 4 different types of Kubernetes controller managers that run on the master node: - Replication Controller - Node Controller - Endpoints Controller - Service Account and Token Controller

When a node fails, Kubernetes reschedules the affected Pods to healthy nodes, maintaining application availability.

The node in Kubernetes that keeps track of resource utilization is the kubelet. It runs on each worker node and is responsible for managing the state of the node, including starting and stopping pods, as well as monitoring their resource usage. The Metrics Server collects the relevant resource usage stats from kubelet and generates aggregated metrics via metrics API.

ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. Secrets are similar but are used to store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. The data in Secrets is stored and handled in a more secure fashion than ConfigMaps.

Kubelet runs on each worker node, ensuring pods are running and reporting back to the control plane. It interacts with the container runtime to start and stop containers. Meanwhile, Kubectl is the command-line tool for interacting with Kubernetes clusters, used for deploying applications, managing resources, and troubleshooting.

The Ingress network manages external access to services in the cluster. Specifically, it enables the load balancing of traffic, termination of SSL/TLS, and virtual hosting for HTTP and HTTPS routes exposed from outside the cluster to services within it. The Ingress network helps streamline communication between the applications and external clients by providing a single entry point for incoming traffic.

Kubectl is command line code especially used to manage and deploy applications on this tool. It also has some additional uses like inspecting the cluster resources and creating, deleting or updating components.

The Kubernetes control plane is a set of components that manages and orchestrates the Kubernetes cluster. It includes the following components: API server etcd kube-scheduler kube-controller-manager cloud-controller-manager

Monitoring a Kubernetes cluster involves tracking the performance and health of the cluster and its applications. Common tools and practices include: - Prometheus: An open-source monitoring and alerting toolkit that collects and stores metrics. - Grafana: A visualization tool that can display metrics collected by Prometheus. - Kube-State-Metrics: Generates metrics about the state of Kubernetes objects. - Logging: Using tools like Fluentd, Elasticsearch, and Kibana (EFK stack) to aggregate and analyze logs. - Cluster dashboards: Tools like the Kubernetes Dashboard or Lens provide a graphical interface to monitor cluster resources.

kubelet is an agent that runs on each node in a Kubernetes cluster. It ensures that containers are running in a Pod. The kubelet takes a set of PodSpecs provided by the Kubernetes API server and ensures that the containers described in those PodSpecs are running and healthy. Key responsibilities include: - Pod management: Starting, stopping, and restarting containers. - Node status reporting: Communicating node status and Pod status to the API server. - Resource monitoring: Monitoring resource usage of Pods and reporting metrics. - Health checks: Running liveness and readiness probes. - Container runtime: Interacting with container runtimes (Docker, containerd, CRI-O) to manage containers.

Well yes, this is indeed possible, and to do so the company should consider using Kubernetes. K8'sis designed to optimize and manage resources systematically. It can specifically manage resources for specific types of applications. And with such an orchestration tool, this problem can be solved with ease.

Here are some of the types of controllers: - Node controller - Replication controller - Service account and token controller - Endpoints controller - Namespace controller

Kubernetes is composed of two layers: a control plane and a data plane. The control plane is the container orchestration layer that includes 1. Kubernetes objects that control the cluster, and 2. the data about the cluster's state and configuration. The data plane is the layer that processes the data requests and is managed by the control plane.

Kubernetes Services are an essential component for enabling communication between different parts of an application running on a Kubernetes cluster. There are four types of Kubernetes services — ClusterIP , NodePort , LoadBalancer and ExternalName] #Create a Service: kubectl create -f service.yaml #Get Information about Services: kubectl get services #Describe a Service: kubectl describe service #Delete a Service: kubectl delete service #Edit a Service: kubectl edit service #Check Service Endpoints: kubectl get endpoints #Edit Service Endpoints: kubectl edit endpoints #Expose a Deployment as a service : kubectl expose deployment --type=NodePort --port= --target-port= - Cluster IP (By Default): Expose port Inside the cluster ( Provide Internal Connectivity ) # Service apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 8080 2. NodePort: It enables access to the service from outside the cluster (Provides access to external traffic) # service.yaml apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 8080 type: NodePort 3. LoadBalancer: LoadBalancer provides internal and external connectivity #Service.yaml apiVersion: v1 kind: Service metadata: name: my-loadbalancer-service spec: selector: app: my-app ports: - protocol: TCP port: 80 # External connectivity: Exposes port 80 externally targetPort: 8080 # Internal connectivity: Forwards traffic to port 8080 on selected pods type: LoadBalancer # External connectivity: Creates an external load balancer 4. Headless Service: Headless service allows the client to directly communicate with the Pods. Do not assign IP to itself. #Service.yaml apiVersion: v1 kind: Service metadata: name: my-headless-service spec: clusterIP: None # Specifies that this is a headless service selector: app: my-app ports: - protocol: TCP port: 80

Kubernetes CRD controller is used to define the behavior of the custom resources and their interactions with other Kubernetes components.

A Pod is the smallest and most basic deployable unit in Kubernetes. It represents a single instance of a running process in a cluster and encapsulates one or more containers. Containers within a Pod share the same network namespace and can communicate easily, making them the fundamental building blocks for deploying and managing applications.

The Kube-api server process runs on the master node.

Scaling Kubernetes applications can be done horizontally or vertically. Horizontal scaling involves adding more replicas of the application, while vertical scaling increases the resources of the individual pod. Kubernetes supports both types of scaling, and it can be easily achieved by modifying the replica count or resource limits of a deployment or Statefulset.

Heapster was a project to provide container cluster monitoring and performance analysis for Kubernetes, now deprecated in favor of newer tools like Metrics Server.

ConfigMaps are used to store non-confidential configuration data, like environment variables or command-line arguments. Secrets are designed for storing sensitive information, such as passwords, tokens, or keys, more securely.

By default, pods in a Kubernetes cluster can communicate with each other directly. Each pod receives its own IP address, and Kubernetes networking allows pods to communicate across nodes as if they were on the same network. This is implemented through a CNI plugin such as Flannel or Weave. Pod IPs are temporary and change when a pod is recreated. To solve this, Kubernetes uses Services, which provide a stable IP address and load balance traffic across pods. Ingress sits on top of Services. It manages incoming traffic from external clients and routes requests to the correct service based on domains or URL paths, using an ingress controller to enforce these rules.

Heapster refers to the Kubernetes project which offers robust monitoring for the Kubernetes cluster. It can be also used as a pod so that it can be managed by Kubernetes. It supports Kubernetes and CoreOS clusters. It collects operational events and metrics from each node in the cluster and stores them in a persistent backend and it permits programmatic and visualization access.

Load balancer is a fundamental approach to expose service on this platform. There are only two kinds of load balancers available on this platform. First is the internal load balancer that automatically balances loads and allocates the pods with necessary configuration. Second is the external load balancer that redirects entire traffic from the outer load to backend pods.

To define workloads in Kubernetes, we use the following objects:

Deployments are used for stateless applications, while stateful sets are used for stateful applications, such as databases or other applications that require persistent and stable storage.

Monitoring means staying aware of three things: how the system is performing, what it has been doing, and when something needs your attention. Prometheus is the go-to for metrics collection. It scrapes data from cluster components, nodes, and your applications. Add kube-state-metrics to get visibility into the state of Kubernetes objects, things like replica counts, pod phases, and resource requests. Grafana turns those metrics into dashboards you can actually read. When numbers look off, logs tell you what happened. If a pod keeps restarting, the logs show whether it was a failed connection, a missing config, or an exception. Fluentd, Loki, or the ELK stack centralizes those logs so you are not jumping between nodes. Alerting is what ties everything together. You set thresholds in Prometheus Alertmanager, and when something crosses a limit, you get notified and fix it.

Pods represent the processes running on a cluster. By limiting pods to a single process, Kubernetes can report on the health of each process running in the cluster. Pods have: a unique IP address (which allows them to communicate with each other) persistent storage volumes (as required) configuration information that determine how a container should run. Although most pods contain a single container, many will have a few containers that work closely together to execute a desired function

kubectl logs kubectl describe pod → check events, probes. - Verify environment variables, config maps. - Check for OOMKilled in kubectl get pod -o wide . - Run interactively with kubectl exec -it .

Kubernetes supports multi-cloud and hybrid-cloud environments by abstracting the underlying infrastructure, allowing the same cluster management and orchestration capabilities across different cloud providers and on-premises environments. This flexibility enables consistent deployment, scaling, and management of applications, regardless of the hosting environment. Kubernetes' cluster federation extends its capabilities across cloud boundaries, enabling synchronized deployment, scaling, and management of services across various clouds and data centers, facilitating resilience, resource optimization, and geo-redundancy.

A federated cluster is a tool that permits the user to manage numerous Kubernetes clusters as a single cluster. Hence the federated cluster allows the user to create many clusters within the data cloud and manages these data all together in one place.

Monitoring in Kubernetes tracks the health and performance of pods and nodes, using tools like Prometheus for metrics collection and Grafana for visualization. Logging captures and analyzes application and system logs, utilizing Elasticsearch, Fluentd, and Kibana for comprehensive log management, aiding in troubleshooting and operational insights.

When traffic increases, scale your pods. Adjust the replica count or let the Horizontal Pod Autoscaler handle it. The HPA watches CPU and memory usage through the metrics API and scales pods up or down based on what it sees. For more control, use the Prometheus adapter to feed custom metrics into the HPA, things like request rate, queue depth. That is where autoscaling becomes useful in production. If nodes are running out of capacity, the Cluster Autoscaler steps in. It detects unscheduled pods and provisions new nodes. When demand drops, it scales them back down. For event-driven workloads, KEDA extends Kubernetes autoscaling to support triggers like message queue depth, database row counts, or HTTP traffic, giving you more advantage than the HPA alone.

Etcd is the distributed key-value store that holds the cluster's data. It stores configuration details, metadata, and system state, everything the cluster needs to function. It is built to be fault-tolerant. Even if a node fails or a network partition occurs, etcd preserves data consistency using quorum-based consensus. In a multi-node control plane setup, this keeps the cluster state reliable when things go wrong. If etcd becomes corrupted, the cluster goes blind. The control plane loses its memory of what should exist. That's why etcd backups are critical in production. Only the API server communicates with etcd directly. That separation protects the integrity of the cluster state.

“I isolate the root cause methodically: - Application Code Check: I execute kubectl logs –previous. If I see a stack trace (like ‘DB Connection Refused'), it's a code or config error. - Environment Check: If logs are empty, the container failed to boot. I run kubectl describe pod to check for failed Probes or unmounted ConfigMaps. - Live Debugging: If it's still unclear, I override the YAML command with sleep 3600, keeping the Pod alive so I can kubectl exec inside.”

The kube-controller-manager is responsible for running various controller processes that monitor the state of the cluster and make changes as necessary.

A pod is the smallest deployable unit in Kubernetes that represents a single instance of a running process in a container.

StatefulSets manage the deployment and scaling of stateful applications, ensuring stable network identities and persistent storage.

To regulate the resources for the pods, we make use of the 'resources' parameter while creating the pods. We can request and limit the resources that a pod can consume. This allows us to control various resources required for the pods, like storage, CPU, memory, etc. Below is an example showing how to control the pods' resource usage. apiVersion: v1 kind: Pod metadata: name: resource-control-example spec: containers: - name: container-of-pod image: nginx resources: requests: ephemeral-storage: "1Gi" memory: "500Mi" cpu: "50m" limits: ephemeral-storage: "2Gi" memory: "1Gi" cpu: "100m"

RBAC (Role-Based Access Control) in Kubernetes is a mechanism for managing permissions within a cluster based on user roles. It controls who can perform specific actions on Kubernetes resources. RBAC uses four key Kubernetes objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding. A Role defines a set of permissions within a namespace, while a ClusterRole defines them cluster-wide. These are linked to users or service accounts using RoleBinding (namespaced) or ClusterRoleBinding (cluster-wide). This structure allows precise, least-privilege access control. RBAC is essential for securing Kubernetes environments by ensuring users and workloads only have the permissions they need.

- The Deployment controller creates a new ReplicaSet with the updated configuration (e.g., new container image). - It then incrementally scales up the new ReplicaSet while scaling down the old one. - This process continues until the desired number of updated Pods is running and the old Pods are terminated.

ClusterIP and NodePort are two types of services in Kubernetes, a container orchestration platform, used to expose and manage access to applications running in a Kubernetes cluster. ClusterIP is an internal service type that provides a stable and virtual IP address within the cluster for a set of pods belonging to a specific service. It allows communication between different parts of your application within the cluster by abstracting the underlying pods' IP addresses. NodePort, on the other hand, is a service type that exposes a specific port on all nodes in the Kubernetes cluster. This makes the service accessible from outside the cluster by directing traffic to any node's IP address on the specified port. NodePort services are often used when you need to expose an application externally, but they are less secure compared to other methods such as LoadBalancer or Ingress controllers.

Best practices for deploying applications in Kubernetes include: Using declarative deployment methods, such as Deployments or Helm charts Separating concerns between services by deploying them in separate namespaces Using liveness and readiness probes to ensure the health of the application Setting resource limits and requests to ensure adequate resources for the application

Expect the candidate to discuss deploying etcd as a multi-node cluster across different availability zones, using dedicated hardware or instances for etcd nodes to ensure performance, implementing regular snapshot backups, and setting up active monitoring and alerts for etcd health. Important Points to Mention: - Multi-node etcd clusters across availability zones for fault tolerance. - Dedicated resources for etcd to ensure performance isolation. - Regular snapshot backups for disaster recovery. - Monitoring and alerting for proactive issue resolution. Example You Can Give: “In a production environment, we deployed a three-node etcd cluster spread across three different availability zones to ensure high availability and fault tolerance. Each etcd member was hosted on dedicated instances to provide the necessary compute resources and isolation. We automated snapshot backups every 6 hours and configured Prometheus alerts for metrics indicating performance issues or node unavailability.” Hedge Your Answer: “While these practices significantly enhance the resilience and availability of the etcd cluster, managing etcd comes with its complexities. Performance tuning and disaster recovery planning require deep understanding and experience. Additionally, etcd's sensitivity to network latency and disk I/O performance means that even with these measures, achieving optimal performance may require ongoing adjustments and infrastructure investment.”

There are several service types that can be used to expose applications running on a set of Pods. The different service types include: - ClusterIP: This service type exposes the service on an internal IP within the Kubernetes cluster. It is accessible only within the cluster. - NodePort: NodePort service type exposes the service on a static port on each node's IP. It is accessible outside the cluster using the node's IP address and the NodePort. - LoadBalancer: This service type exposes the service using a cloud provider's load balancer. It automatically creates the load balancer and assigns a public IP to the service, making it accessible from outside the cluster. - ExternalName: ExternalName service type maps the service to a DNS name. It is used to provide external access to services running outside the cluster.

Kubernetes uses CoreDNS (running in kube-system ) to provide internal DNS. Each Service gets a DNS name in the format: ..svc.cluster.local For example: my-app-service.production.svc.cluster.local Pods use these DNS names to communicate with Services instead of hardcoding IP addresses.

The access modes in PersistentVolumeClaim (PVC) are as follows: - ReadWriteOnce (RWO) - It ensures only one node can read or write on the mounted volume. Multiple pods running on the same node can also access the volume. - ReadOnlyMany (ROX) - Multiple nodes can mount the volume as read-only. - ReadWriteMany (RWX) - Multiple nodes can mount the volume as read-write. - ReadWriteOncePod (RWOP) - The volume can be mounted as read-write by a single pod. It is used when we want to ensure only one pod can read or write on the mounted volume.

- Check existing network policies - Describe the network policy - Verify pod labels and selectors - Test connectivity between pods - Update the policy if needed

Kubernetes Service Constraint: A single Service cannot expose the same port number for both TCP and UDP simultaneously. This is a fundamental limitation of the Service resource design. Solution Architectures: 1. Separate Services Approach (Recommended) Application Pod (listening on TCP:8080 and UDP:8080) ↓ TCP Service (port 8080) + UDP Service (port 8080) ↓ External Load Balancer(s) or NodePort(s) # TCP Service apiVersion: v1 kind: Service metadata: name: app-tcp-service spec: selector: app: multi-protocol-app ports: - name: tcp-port protocol: TCP port: 8080 targetPort: 8080 type: LoadBalancer # UDP Service apiVersion: v1 kind: Service metadata: name: app-udp-service spec: selector: app: multi-protocol-app # Same selector ports: - name: udp-port protocol: UDP port: 8080 targetPort: 8080 # Same target port type: LoadBalancer Key design elements: - Both services use the same selector, targeting the same pods - Same targetPort (8080) but different protocols - Separate external IP addresses for TCP and UDP traffic 2. Single Service with Different External Ports apiVersion: v1 kind: Service metadata: name: multi-protocol-service spec: selector: app: multi-protocol-app ports: - name: tcp-8080 protocol: TCP port: 8080 # External TCP port targetPort: 8080 # Application TCP port - name: udp-8081 # Different external port protocol: UDP port: 8081 # External UDP port targetPort: 8080 # Same application UDP port type: LoadBalancer Application Design Considerations Container Configuration: The application container must listen on both protocols: apiVersion: apps/v1 kind: Deployment metadata: name: multi-protocol-app spec: template: spec: containers: - name: app image: your-app:latest ports: - containerPort: 8080 protocol: TCP # Explicit protocol declaration - containerPort: 8080 protocol: UDP # Same port, different protocol Application Code Requirements: - The application must bind to both TCP and UDP sockets on port 8080 - Handle concurrent connections on both protocols - Implement appropriate protocol-specific logic Ingress Configuration for HTTP/HTTPS Ingress controllers typically only handle HTTP/HTTPS (TCP-based) traffic: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress annotations: nginx.ingress.kubernetes.io/backend-protocol: "HTTP" spec: rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: app-tcp-service # Only TCP service port: number: 8080 Ingress Limitations: - Cannot handle UDP traffic - Only routes HTTP/HTTPS requests - UDP traffic must be exposed directly through Services Load Balancer Configuration Cloud Provider Considerations: AWS Application Load Balancer (ALB): - Supports only HTTP/HTTPS (Layer 7) - Cannot handle UDP traffic - Use Network Load Balancer (NLB) for TCP/UDP AWS Network Load Balancer (NLB): - Supports both TCP and UDP - Can handle multi-protocol scenarios - Preserves source IP addresses Example NLB annotation: apiVersion: v1 kind: Service metadata: name: multi-protocol-nlb annotations: service.beta.kubernetes.io/aws-load-balancer-type: "nlb" service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing" spec: type: LoadBalancer selector: app: multi-protocol-app ports: - name: tcp port: 8080 protocol: TCP targetPort: 8080 - name: udp port: 8080 protocol: UDP targetPort: 8080 Monitoring and Troubleshooting Connection Testing: TCP Testing: # Test TCP connectivity telnet 8080 curl http://:8080 UDP Testing: # Test UDP connectivity nc -u 8080 echo "test" | nc -u 8080 Traffic Analysis: - Monitor both TCP and UDP connection metrics - Analyze protocol-specific performance characteristics - Implement health checks for both protocols Production Deployment Patterns 1. DNS-Based Traffic Distribution - Use different DNS names for TCP and UDP services - Implement client-side logic to choose appropriate endpoint - Consider geographic traffic routing 2. Application Gateway Pattern - Deploy a proxy/gateway that handles protocol multiplexing - Single external endpoint with protocol detection - Backend routing to appropriate service endpoints 3. Service Mesh Integration - Leverage service mesh capabilities for advanced traffic management - Implement protocol-aware routing policies - Enhanced observability for multi-protocol traffic

Kubernetes provides three types of autoscaling: - Horizontal Pod Autoscaler (HPA) adjusts the number of Pod replicas based on metrics - Vertical Pod Autoscaler (VPA) adjusts CPU and memory requests for individual Pods - Cluster Autoscaler adjusts the number of worker nodes based on demand You can create an HPA with a single command: kubectl autoscale deployment --cpu=50% --min=2 --max=10 This keeps average CPU utilization across Pods at 50%, scaling between 2 and 10 replicas. HPA requires metrics-server installed in the cluster.

Kubernetes containerization is the process of packaging an application and all its dependencies into a container for deployment and management.

kubeconfig is a configuration file used by kubectl and other Kubernetes clients to communicate with a Kubernetes cluster. It contains details such as: - Clusters: API server addresses and certificate authority data. - Users: Credentials for authenticating to the API server. - Contexts: Combinations of clusters, namespaces, and user credentials for easy switching. The default location for the kubeconfig file

The main Kubernetes features includes: Auto-scaling, DNS management, Load Balancing, Self-healing, Automated rollouts and rollbacks.

The Kubernetes controller manager embeds controllers and is responsible for creating a namespace. Here controllers are control loops that watch the state of your cluster, then make or request changes where needed. Every controller tries to move the current cluster state to the desired state.

Walk through systematically: # 1. Check if Pods are running and healthy kubectl get pods -l app= kubectl describe pod # 2. Check if the Service has registered endpoints kubectl get endpointslices -l kubernetes.io/service-name= # 3. Check readiness probe status — failing probes remove Pods from rotation kubectl describe pod | grep -A5 "Readiness" # 4. Check resource usage — OOMKills cause intermittent restarts kubectl top pods -l app= # 5. Check network policies that might be blocking traffic kubectl get networkpolicies -n Interviewers care about your methodology here. Start broad (are Pods alive?), narrow down (are they receiving traffic?), then look at edge cases (resource pressure, network policies).

A Pod is the smallest, most basic deployable computing unit in Kubernetes. While Docker manages individual containers, Kubernetes manages Pods. - Structure: A Pod encapsulates either a single container (most common) or multiple tightly coupled containers (like a main app and a logging “sidecar”). - Shared Context: All containers within the exact same Pod share the same IP address, network namespace, and storage volumes, allowing them to communicate via localhost. - Ephemeral Nature: Pods are mortal and disposable. If a node fails, the Pod dies, and Kubernetes schedules a new replica to replace it.

A PodDisruptionBudget keeps your app stable during planned cluster work like node upgrades or maintenance. You define how many pods must stay running so the service does not drop below an acceptable level. If you set a rule that only one pod can be unavailable at a time, Kubernetes follows that during node drains and will not evict more pods than the budget allows. PDBs only apply to voluntary disruptions. If a node crashes, the budget does not protect you. They work through the eviction API, which is used during operations like node draining. Normal scaling changes that reduce replicas trigger standard pod termination and are not subject to the budget.

A cluster backup strategy involves two main components : - Cluster State (etcd): The most critical component is the etcd database. Regular snapshots of etcd should be taken. Restoration involves stopping the API server, restoring the etcd data from a snapshot, and restarting the control plane components. - Application Data (Persistent Volumes): For stateful applications, the data stored in Persistent Volumes must also be backed up. Tools like Velero are commonly used for this purpose. Velero can take snapshots of your cluster's resources and persistent volumes, allowing you to restore the entire state of your applications, not just the cluster configuration.

This often comes up as a follow-up to Helm questions. The interviewer wants to see that you understand there is more than one approach to managing Kubernetes manifests and that each has trade-offs. Kustomize takes a different approach. Instead of templates with placeholder values, you write plain Kubernetes YAML and then apply patches and overlays to modify it for different environments. There is no templating language involved. You start with a base set of manifests and then layer on changes using a kustomization.yaml file that specifies what to add, remove, or override. For example, your base might define a Deployment with 2 replicas and a default image tag. Your production overlay would patch the replica count to 5 and swap in the production image. The base manifests remain valid Kubernetes YAML at all times, which makes them easier to read and validate.

A Node is a worker machine in a Kubernetes cluster. It can be a virtual or physical machine and is where Pods are deployed and executed. The Kubernetes control plane manages the Nodes.

PV stands for PersistentVolume and PVC stands for PersistentVolumeClaim. PersistentVolume creates a storage volume so that users can claim a specific amount of storage from it. The PV can be created using different volume provisioners like Local, NFS, CephFS, GCEPersistentDisk, AWSElasticBlockStore, AzureFile, etc. PersistentVolumeClaim allows the users to claim storage resources from PV. Just like Pods can request resources like CPU and memory, PVCs can ask for storage resources from PV with certain access modes. kind: PersistentVolume apiVersion: v1 metadata: name: postgres-pv spec: storageClassName: local capacity: storage: 10Gi accessModes: - ReadWriteOnce hostPath: path: "/data" --- apiVersion: v1 kind: PersistentVolumeClaim metadata: labels: app: postgres name: postgres-pv-claim spec: storageClassName: local accessModes: - ReadWriteOnce resources: requests: storage: 1Gi

It manages network rules and enables communication between services and Pods.

Kubernetes is a distributed open-source technology that helps us in scheduling and executing application containers within and across clusters. A Kubernetes cluster consists of two types of resources: The Master => Coordinates all activities in the cluster, for example, => scheduling applications, maintaining applications' state, scaling applications, and rolling out new updates Nodes => A node is an instance of an OS that serves as a worker machine in a Kubernetes cluster. Also, Node will have two components - Kubelet => Agent for managing and communicating with the master - Tool (Docker/containers) => Tools for running container operations It is designed based on the ground up as a loosely coupled collection of containers centred around deploying, maintaining, and scaling workloads. Works as an engine for resolving state by converging the actual and the desired state of the system (self-healing). Hidden from the underlying hardware of the nodes and provides a uniform interface for workloads to be both deployed and consume the shared pool of resources(hardware) in order to simplify deployment. Pods are the smallest unit of objects that can be deployed on Kubernetes, Kubernetes packages one or more containers into a higher-level structure called a pod. Pod runs one level higher than the container. A POD always runs on a Node but they share a few resources which can be Shared Volumes, Cluster Unique IP, and Info about how to run each container. All containers in the pod are going to be scheduled on an equivalent node. Services are the unified way of accessing the workloads on the pods, The Control plane which is the core of Kubernetes is an API server that lets you query, and manipulate the state of an object in Kubernetes. The following image describes the work-flow of Kubernetes from a high level, wherein the application description is a YAML file also known as a configuration or spec file with the help of which we can deploy applications bundled in the form of pods in cluster or node

Kubernetes Operators are app-specific Kubernetes extensions that automate the process of running a specific service in your cluster. They provide CRDs and custom controllers that allow you to easily deploy the target app without manually configuring objects such as Pods, Services, StatefulSets, and Persistent Volumes. For example, Spacelift's Worker Pool operator lets you deploy a custom Spacelift worker pool in your cluster by creating WorkerPool objects. WorkerPool is a CRD backed by a controller; when you create a new WorkerPool in your cluster, the operator automatically creates the necessary objects to deploy a new pool instance.

Kubernetes and Docker Swarm differ primarily in their complexity and usage scenarios. Kubernetes excels in handling complex, high-demand applications with intricate configurations, providing an efficient solution for container management. However, Docker Swarm is more user-friendly. It offers simplicity and ease of use, making it ideal for smaller applications that need quick deployment and straightforward management.

Role of Kube-apiserver Kube-apiserver can be defined as the front end of the control panel of the master node. It goes along the scale-out architecture. It helps to expose all the components of Kubernetes Master Nodes. It plays a significant role in finding communication between master node components and nodes of Kubernetes. Role of Kube-scheduler The Kube-scheduler performs the distribution of workload. It also helps in the management of workload. It performs all such activities in the worker's node. It can choose an appropriate node. And in that node, the unscheduled pods run. The pods run according to the requirements of the resources. And when the pods run, it keeps a record of the utilization of resources.

Persistent Volumes in Kubernetes are used to persist data even when the pod using it is deleted, ensuring data durability and independence from the pod lifecycle.

Namespaces in Kubernetes provide a way to divide cluster resources between multiple users. They are intended for use in environments with many users spread across multiple teams or projects. Namespaces provide a scope for names and are useful for: - Organizing resources. - Providing resource quotas and limits to different teams. - Enabling policies and access controls.

Troubleshooting a Kubernetes pod involves checking logs, investigating resource utilization, and inspecting the pod status and events.

A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. It ensures that a specified number of pod replicas are running at all times.

A Kubernetes worker node is a physical or virtual machine that runs containerized applications and services. It includes the following components: Kubelet kube-proxy container runtime

By adopting API versioning, gradual upgrades of control plane and nodes, using feature gates, and testing changes in staging before applying to production.

For logging, the standard pattern is: applications write to stdout/stderr, a DaemonSet (Fluent Bit or Fluentd) collects logs from every node, and ships them to a centralized platform like Grafana Loki, Elasticsearch, or CloudWatch. For monitoring, Prometheus and Grafana are the most widely adopted stack. metrics-server provides the resource metrics HPA relies on. # Check resource usage across Pods kubectl top pods --sort-by=cpu # Check node-level resource usage kubectl top nodes For distributed tracing across services, Jaeger or Grafana Tempo track request flow.

Namespaces are a way to divide cluster resources between multiple users. They are used for creating multiple environments within the same cluster, like development, testing, and production.

ETCD can be defined as the distributed key-value store which establishes a relation between the distributed works. The ETCD is basically written in a specific language that is called a GO programming language. Its main function is to accumulate the configuration information of the cluster of Kubernetes. This helps it to represent the form of the cluster at any time.

Daemon sets ensure that a copy of a pod runs on all (or some) nodes in the cluster, used for deploying system services that need to run on every node.

Kubernetes network policy defines how pods within a namespace would communicate with other pods and with the network.

Deployments provide declarative updates for Pods and ReplicaSets. They describe a desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate.

Kubernetes follows a master-node architecture, divided into: - Master Node: Manages the state and activities of the cluster. It contains essential components like the API server, scheduler, and controller manager. - API Server: Acts as the entry point for all API interactions. - Scheduler: Assigns workloads to nodes based on resource availability and specific requirements. - Controller Manager: Maintains the desired state, handling tasks like node management and endpoint creation. - etcd: The distributed key-value store that persists cluster state. - Worker Nodes: Also called minions, these are virtual or physical machines that run the actual workloads in the form of containers. Each worker node runs various Kubernetes components like Kubelet, Kube Proxy, and a container runtime (e.g., Docker, containerd).

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.” 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.”

Kubernetes is a platform that enables users to deploy, manage and scale containerized applications. Some of its key features include: -Declarative syntax: Kubernetes uses a declarative syntax that makes it easy to describe the desired state of an application. -Self-healing: Kubernetes is able to automatically heal applications and nodes in the event of failures. -Horizontal scalability: Kubernetes enables users to scale their applications horizontally, by adding or removing nodes as needed. -Fault tolerance: Kubernetes is able to tolerate failures of individual nodes or pods, ensuring that applications are always available.

A node is a worker machine in Kubernetes, previously known as a minion. A node may be a VM or physical machine, depending on the cluster. Each node contains the services necessary to run pods and is managed by the master components. The services on a node include the container runtime, kubelet and kube-proxy.

Kubernetes comes with an internal DNS server that automatically assigns DNS names to the services it creates. These DNS names are accessible from pods within the cluster. The format of the DNS name is: . However, if both the service and the pod calling the service are in the same namespace, the calling container within the pod can use just the service name as the DNS name (see Figure 2 below). Figure 2: Kubernetes has a DNS server that creates DNS names accessible within a cluster. For example, imagine you have a service, called myservice, in the namespace called mynamespace. The service myservice represents an HTTP web server. Now, imagine you have a pod named mypod also in the namespace mynamespace, and you have a pod named yourpod in the namespace yournamespace. To call the service myservice from a container in the pod yourpod, using curl for example, you would use the URL http://myservice.mynamespace. Why? Because yourpod is in a different namespace from myservice. However, to call myservice from mypod using curl, the DNS name to use is http://myservice because mypod and myservice are in the same namespace, mynamespace.

Kubernetes pod security policies are a set of policies that control the security settings for pods deployed in a Kubernetes cluster.

Bonus question for practice. Taints are applied to nodes to repel pods that do not have matching tolerations. Tolerations are applied to pods to allow them to be scheduled on nodes with specific taints.

A StatefulSet is a Kubernetes resource used to manage stateful applications. Unlike a Deployment, which manages stateless Pods, a StatefulSet is designed for applications that require persistent storage and stable network identifiers. It ensures that: - Each Pod has a unique, stable network identity. - Each Pod maintains a persistent storage that is not affected by the rescheduling or deletion of Pods. - Pods are created in a sequential, ordered manner, which is often required for applications like databases.

A pod is the smallest deployable unit in Kubernetes, representing one or more tightly coupled containers that share networking and storage. Containers in a pod communicate via localhost and can share volumes. Pods are ephemeral, so if a pod fails, Kubernetes replaces it with a new one. To ensure persistence, we use ReplicaSets, Deployments, or StatefulSets for automatic pod management.

Kube-proxy can run on every node and perform TCP/UDP packet forwarding across the backend network service. Kube-proxy is an important component of Kubernetes networking that helps ensure reliable and efficient communication between pods and services within the cluster. By routing traffic to the correct destination, kube-proxy helps ensure reliable and efficient communication within the cluster.

Check for admission webhook failures. Validation or mutation webhooks may have blocked pod creation. Run kubectl describe deployment to see webhook-related errors in the events.

Containers within a pod share networking space and can reach other on localhost. For instance, if you have two containers within a pod, a MySQL container running on port 3306, and a PHP container running on port 80, the PHP container could access the MySQL one through localhost:3306.

Start with the logs. They show what the application was doing before it failed. If it keeps restarting, check the previous instance with kubectl logs --previous. The real error often appears right before the crash. Next, inspect events using kubectl describe pod. Logs show application output. Events show what Kubernetes did or failed to do, such as image pull errors, failed probes, or volume mount issues. Check the pod status. Pending points to scheduling or resource constraints. CrashLoopBackOff means the container keeps failing during startup. At this stage, verify resource requests, environment variables, and external dependencies. If nothing stands out, move to the node level. Check the kubelet logs on the node where the pod was scheduled. On systemd-based systems, use journalctl -u kubelet. If the kubelet is not the issue, inspect the container runtime logs. containerd or CRI-O can surface lower-level errors that never appear through kubectl.

Kubernetes (K8s) is an open-source container orchestration platform that automates deploying, scaling, and managing containerized applications. Originally developed at Google (based on their internal system called Borg) and now maintained by the Cloud Native Computing Foundation (CNCF), it solves the problem of running containers at scale, something that becomes unmanageable quickly when you're coordinating dozens or hundreds of containers across multiple servers by hand. You can verify your cluster is running with a single command: kubectl cluster-info This returns the API server address and key cluster service endpoints, confirming that kubectl can reach the cluster and giving you a quick sanity check on connectivity.

Kubernetes Custom Resource Definitions (CRDs) allow you to create your own custom resources. They extend the Kubernetes API to manage application-specific resources using standard Kubernetes tools and APIs. - Defining CRDs: You define CRDs in a YAML file that specifies the name, schema, and validation rules for the custom resource. - Creating Custom Resources: Once a CRD is defined and applied, you can create and manage instances of the custom resource. - Operators: CRDs are often used with Operators to manage the lifecycle of complex applications. Example CRD definition: ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: crontabs.example.com spec: group: example.com versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: cronSpec: type: string image: type: string scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab shortNames: - ct Applying the CRD: ```bash kubectl apply -f crontab-crd.yaml Creating an instance of the custom resource: apiVersion: example.com/v1 kind: CronTab metadata: name: my-cronjob spec: cronSpec: "* * * * */5" image: my-cron-image Applying the custom resource: kubectl apply -f my-cronjob.yaml

A Kubernetes cluster is a set of nodes that containerized applications run on. These nodes can be physical machines or virtual machines.

As the company's goal is to shift from their monolithic application to microservices, they can end up building piece by piece, in parallel and just switch configurations in the background. Then they can put each of these built-in microservices on the Kubernetes platform. So, they can start by migrating their services once or twice and monitor them to make sure everything is running stable. Once they feel everything is going well, then they can migrate the rest of the application into their Kubernetes cluster.

Container logs in Kubernetes follow this flow: Application → Container Runtime → Node Filesystem → Log Aggregation System ↓ /var/log/containers/ (symlinks) ↓ /var/log/pods/ (actual log files) ↓ /var/lib/docker/containers/ (container runtime logs) Root Causes of Log-Related Disk IO Issues 1. Uncontrolled Log Volume - Applications logging at verbose levels (DEBUG, TRACE) - High-frequency log generation without rate limiting - Large log messages or stack traces - No log rotation or size limits 2. Inefficient Log Handling - Multiple processes reading the same log files - Lack of centralized logging leading to local accumulation - Poor log rotation policies - Insufficient disk space allocation for logs 3. Container Runtime Configuration - Default log drivers without size limits - Missing log rotation configuration - Inadequate garbage collection policies Kubernetes-Native Solutions 1. Pod-Level Log Management Container Log Configuration: apiVersion: v1 kind: Pod metadata: name: app-with-log-limits spec: containers: - name: app image: myapp:latest env: - name: LOG_LEVEL value: "INFO" # Reduce log verbosity - name: LOG_FORMAT value: "structured" # Efficient log format Key logging environment variables: LOG_LEVEL: Controls application verbosity LOG_FORMAT: Structured logs (JSON) are more efficient to process Application-specific configuration to limit log output Ephemeral Storage Limits: spec: containers: - name: app resources: limits: ephemeral-storage: "2Gi" # Limit total ephemeral storage requests: ephemeral-storage: "1Gi" # Reserve storage for logs 2. Node-Level Configuration kubelet Log Rotation Settings: # kubelet configuration apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration containerLogMaxSize: "10Mi" # Maximum size per log file containerLogMaxFiles: 5 # Maximum number of log files Container Runtime Configuration: { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } } Centralized Logging Architecture 1. Log Aggregation Strategy Application Pods → Node Log Files → Log Shipper (DaemonSet) → Centralized Storage Benefits of centralized logging: - Reduced local disk usage - Centralized search and analysis - Retention policy management - Separation of concerns 2. DaemonSet-Based Log Collection apiVersion: apps/v1 kind: DaemonSet metadata: name: log-collector namespace: logging spec: selector: matchLabels: name: log-collector template: spec: containers: - name: fluentd image: fluent/fluentd-kubernetes-daemonset:v1-debian-elasticsearch env: - name: FLUENTD_SYSTEMD_CONF value: "disable" resources: limits: memory: 200Mi # Limit collector resource usage requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers DaemonSet design considerations: - Resource limits to prevent collector from overwhelming nodes - Read-only mounts for security - Efficient log parsing and filtering Advanced Log Management Patterns 1. Structured Logging Implementation apiVersion: v1 kind: ConfigMap metadata: name: app-logging-config data: log4j2.xml: | Benefits of structured logging: - Efficient parsing and indexing - Reduced storage requirements - Better query performance - Consistent log format across services 2. Application-Level Log Sampling apiVersion: v1 kind: ConfigMap metadata: name: app-config data: application.yml: | logging: level: com.company.app: INFO org.springframework: WARN pattern: console: "%d{ISO8601} [%thread] %-5level %logger{36} - %msg%n" sampling: enabled: true rate: 100 # Sample 1 in 100 debug logs Storage Optimization Strategies 1. Node Storage Management Automated Cleanup CronJob: apiVersion: batch/v1 kind: CronJob metadata: name: log-cleanup namespace: kube-system spec: schedule: "0 2 * * *" # Daily at 2 AM jobTemplate: spec: template: spec: hostPID: true hostNetwork: true containers: - name: cleanup image: alpine:latest command: - /bin/sh - -c - | # Clean up old container logs find /host/var/log/containers -name "*.log" -mtime +7 -delete # Clean up old pod logs find /host/var/log/pods -name "*.log" -mtime +7 -delete # Clean up Docker container logs find /host/var/lib/docker/containers -name "*.log" -mtime +7 -delete volumeMounts: - name: host-var mountPath: /host/var - name: host-var-lib mountPath: /host/var/lib securityContext: privileged: true volumes: - name: host-var hostPath: path: /var - name: host-var-lib hostPath: path: /var/lib restartPolicy: OnFailure 2. Storage Class Optimization apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ephemeral provisioner: kubernetes.io/aws-ebs parameters: type: gp3 iops: "3000" throughput: "125" encrypted: "true" reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer Monitoring and Alerting 1. Disk Usage Monitoring Key metrics to monitor: - Node disk utilization by mount point - Container log file sizes and growth rates - Log rotation effectiveness - I/O wait times and disk pressure 2. Log-Specific Alerts # Prometheus alert rules groups: - name: logging.rules rules: - alert: HighLogVolume expr: increase(container_fs_writes_bytes_total[5m]) > 100000000 # 100MB in 5min for: 2m labels: severity: warning annotations: summary: "High log volume detected on {{ $labels.instance }}" - alert: DiskSpaceForLogs expr: (node_filesystem_avail_bytes{mountpoint="/var/log"} / node_filesystem_size_bytes{mountpoint="/var/log"}) < 0.1 for: 1m labels: severity: critical annotations: summary: "Low disk space for logs on {{ $labels.instance }}" Best Practices for Production 1. Log Lifecycle Management - Define clear retention policies - Implement automated cleanup procedures - Regular capacity planning and monitoring - Cost optimization through appropriate storage tiers 2. Application Design - Implement log sampling for high-volume debug logs - Use appropriate log levels for different environments - Structured logging for efficient processing - Error aggregation to reduce duplicate log entries 3. Operational Excellence - Regular log infrastructure health checks - Disaster recovery procedures for log data - Performance testing of logging infrastructure - Integration with incident response procedures

A container is an isolated running process created from a container image. A container runtime is the software that creates and manages containers on a node. Kubernetes uses the Container Runtime Interface (CRI) to talk to runtimes such as containerd and CRI-O. Since Kubernetes v1.24, the built-in dockershim adapter was removed, but Docker-built images still work normally on CRI-compatible runtimes. If you're new to containers, our Introduction to Docker tutorial covers the fundamentals you need before working with Kubernetes.

By default, POD can communicate with any other POD, we can set up network policies to limit this communication between the PODs. - RBAC (Role-based access control) to narrow down the permissions. - Use namespaces to establish security boundaries. - Set the admission control policies to avoid running the privileged containers. - Turn on audit logging.

Three commands cover most situations: # Check Pod status and detailed events kubectl describe pod # Check container logs kubectl logs # Check logs from a previous crashed container kubectl logs --previous # Check cluster events (modern command) kubectl events Here's what typical kubectl describe pod output looks like for a failing Pod: Common statuses and what they mean: - ImagePullBackOff = image doesn't exist or registry auth failed - Pending = insufficient resources or no matching nodes - CrashLoopBackOff = container starts but crashes repeatedly - OOMKilled = exceeded memory limit

Explanation - One of the several ways to answer this question. apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: someapp-ingress spec: rules: - host: my.host http: paths: - backend: serviceName: someapp-internal-service servicePort: 8080

Kube-proxy runs on every node and manages network communication for services. It watches the Kubernetes API for endpoint changes and updates the node's networking rules. When traffic hits a Service's virtual IP, kube-proxy configures routing rules using iptables or IPVS so the kernel directs that traffic to the right backend pods.

Kubernetes TLS is a security protocol used to secure client-server communications within a Kubernetes cluster.

Immutable Infrastructure pertains to the practice of replacing servers or containers instead of modifying them. Kubernetes supports this through declarative configurations that ensure deployed containers are replaced for updates rather than changed.

NodePort exposes a service on each Node's IP at a static port, allowing external traffic to access a service inside the cluster.

If etcd goes down, Kubernetes loses its memory. Etcd stores the entire cluster state. Without it, the control plane can't create, update, or manage resources. Running pods may continue for a while, but no changes can be made. If the outage lasts or data is lost without backups, recovery can be difficult. That's why protecting and backing up etcd is critical in production.

A strong answer covers several layers: - Namespaces per team - RBAC to control access within each Namespace - ResourceQuotas and LimitRanges to prevent one team from consuming all resources - NetworkPolicies to restrict traffic between Namespaces apiVersion: v1 kind: ResourceQuota metadata: name: team-a-quota namespace: team-a spec: hard: requests.cpu: "4" requests.memory: "8Gi" limits.cpu: "8" limits.memory: "16Gi" pods: "20" You should also acknowledge the trade-off: a single large cluster is simpler to operate but harder to isolate, while multiple smaller clusters provide stronger boundaries but increase operational complexity.

Resource quotas prevent a single tenant (namespace) from over-consuming cluster resources, disturbing other tenants from working. You can define ResourceQuotas for namespaces to give a certain amount of resources to that specific namespace. Users of that namespace can then create resources that consume as much resources as defined in the ResourceQuota of that namespace. Example ResourceQuota YAML definition: apiVersion: v1 kind: ResourceQuota metadata: name: namespace-quota namespace: team-a spec: hard: requests.cpu: "4" requests.memory: "8Gi" limits.cpu: "8" limits.memory: "16Gi" pods: "20" You can check a ResourceQuota of a namespace using: kubectl describe resourcequota namespace-quota -n team-a

A Kubernetes operator extends Kubernetes functionality by automating the deployment, scaling, and management of complex applications. It is built using CRDs and custom controllers to handle application-specific logic. Operators work by defining custom resources in Kubernetes and watching for changes in the cluster to automate specific tasks. These are the key components of an operator: - Custom Resource Definition (CRD): Defines a new Kubernetes API resource. - Custom controller: Watches the CRD and applies automation logic based on the desired state. - Reconciliation loop: Continuously ensures the application state matches the expected state.

Deployments and StatefulSets are both high-level objects that manage a set of Pod replicas. Deployments are designed for stateless applications, such as frontend app deployments, where all the Pod replicas are identical to each other. Conversely, StatefulSets enable you to run stateful applications like databases and file servers, where the identity of each replica is crucial. Pods in a StatefulSet have persistent identifiers, are started and stopped in sequential order, and are allocated unique Persistent Volume Claims. This allows you to ensure pod-0 always runs the primary replica in a database service, for example.

You should be creating serviceAccount. A service account creates a token and tokens are stored inside a secret object. By default Kubernetes automatically mounts the default service account. However, we can disable this property by setting automountServiceAccountToken: false in our spec. Also, note each namespace will have a service account apiVersion: v1 kind: ServiceAccount metadata: name: my-sa automountServiceAccountToken: false

Kubernetes scheduler assigns newly created pods to nodes based on factors such as resource requirements, scheduling policies, affinity and anti-affinity specifications, taints and tolerations, and other constraints.

Kubernetes anti-affinities are rules that determine the preferred scheduling of pod based on factors that should be avoided, such as running two replicas of a pod on the same node.

Etcd is a distributed key-value store that holds the cluster's configuration data, providing a reliable source of truth. Kubernetes uses etcd to store information about the cluster's state, configurations, and other critical data.

Init Containers are specialized containers that run before app containers in a Pod are started. They are used for setup tasks that need to complete before the main application containers run. Use cases for Init Containers include: - Setup tasks: Preparing the environment by setting up configurations, fetching secrets, or loading initial data. - Dependencies: Ensuring that certain prerequisites are met before the main application starts. - Security: Running setup tasks with different permissions than the main application container. Init Containers have their own specifications and can have different images from the app containers. Example Pod with Init Containers: ```yaml apiVersion: v1 kind: Pod metadata: name: init-demo spec: initContainers: - name: init-myservice image: busybox command: ['sh', '-c', 'echo Initializing…; sleep 10'] containers: - name: myapp image: busybox command: ['sh', '-c', 'echo Running…; sleep 3600'] ```

Sidecar containers run alongside your main container within the same Pod. Common examples include service mesh proxies (Envoy), log forwarders, and TLS proxies. As of Kubernetes v1.33, native sidecar containers are a stable feature. You define them as init containers with restartPolicy: Always , which gives Kubernetes proper control over their lifecycle — they start before and stop after your main containers. apiVersion: v1 kind: Pod metadata: name: app-with-native-sidecar spec: initContainers: - name: log-shipper image: fluent-bit:latest restartPolicy: Always volumeMounts: - name: shared-logs mountPath: /var/log containers: - name: app image: myapp:1.2 volumeMounts: - name: shared-logs mountPath: /var/log volumes: - name: shared-logs emptyDir: {} Kubernetes now handles their lifecycle properly—they start before and stop after your main containers.

Taints are applied to Nodes to mark that they should not accept certain Pods. Tolerations are applied to Pods to allow them to be scheduled on Nodes that have matching Taints. They work together to control Pod placement.

Kubernetes provides high availability through features like Pod replication across Nodes via Deployments, load balancing traffic across healthy Pod replicas with Services, and self-healing by automatically restarting failed containers or Pods.

Kubernetes provides robust mechanisms, such as ReplicaSets, to ensure consistent pod availability. In the context of failure scenarios or manual scaling, it is essential to understand how ReplicaSets guarantee pods are up and running according to the defined configuration. - Pod Template: It specifies the required state for individual pods within the configured ReplicaSet. - Controller-Reconciler Loop: This Control Plane component continuously monitors the cluster, compares the observed state against the desired state specified in the ReplicaSet, and takes corrective actions accordingly. If there's a mismatch, this loop is responsible for making the necessary adjustments. - Replica Level: Each ReplicaSet specifies the desired number of replicas. It's the responsibility of the Controller-Reconciler Loop to ensure that this count is maintained. During the initial setup, the ReplicaSet creates the specified number of pods and ensures they are in an Up state. The Controller-Reconciler continuously monitors pods. If the observed state deviates from the Pod Template, corrective action is initiated to bring the system back to the specified configuration. - Failure Detection: If a pod is unavailable or not matching the defined template, the Controller-Reconciler identifies the anomaly in the system. - Self-Healing: The Controller-Reconciler instantiates new pods, replaces unhealthy ones, or ensures the required number of pods is available, maintaining the ReplicaSet's defined state. The ReplicaSet allows for dynamic scaling of pods in response to changes in demand. - Auto-Scaling: The Controller-Reconciler automatically scales the number of pods to match the configured thresholds or metrics. - Manual Scaling: Administrators can manually adjust the number of replicas.

A Service in Kubernetes exposes a group of Pods and allows communication between and to them. Since Pods are ephemeral, their IPs can change, meaning the application talking to the Pods must also change the IP address. Services, therefore, provide a stable network endpoint with a fixed IP address. A simple Service YAML definition: apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 80 type: ClusterIP The above Service forwards traffic to Pods that have the label app: my-app

Storage in Kubernetes trips people up because it introduces a layer of indirection that does not exist when you are working with a single server. The interviewer is checking that you understand how Kubernetes separates the provisioning of storage from the consumption of it. This separation exists for a good reason. It allows cluster administrators to manage the infrastructure side of storage (what is available, where it lives, how it performs) while developers only need to declare what their application needs. The two sides are decoupled, which makes it easier to move workloads between environments without rewriting storage configuration. In practice, most teams use StorageClasses to handle this automatically. When a PVC is created, the StorageClass provisions a matching PV on the fly, so no one has to manually create volumes ahead of time.

Init containers in Kubernetes are specialized containers that run before the main application containers in a pod. They are used to perform setup tasks such as preparing configurations, ensuring prerequisites are met, or waiting for external services to become available, ensuring the main containers start with the correct setup or dependencies. Unlike regular containers, init containers must complete successfully before the main application containers start, providing a sequenced, step-by-step initialization process.

The Gateway API is the modern, highly extensible successor to the traditional Ingress resource. | Feature | Gateway API (Modern) | Ingress (Legacy) | |---| | Design Model | Role-Oriented: Separates concerns (Infra Admins manage Gateways, Devs manage HTTPRoutes). | Single object managing everything. | | Protocol Support | HTTP, HTTPS, gRPC, TCP, UDP. | Limited primarily to HTTP/HTTPS. | | Traffic Splitting | Native support for advanced Canary/Blue-Green deployments (weighted routing). | Requires vendor-specific custom annotations (e.g., NGINX snippets). |

When you create a Kubernetes deployment, you are telling Kubernetes the desired state: how many replicas to run, which container image to use, and how much resource each pod needs. Kubernetes works to make that state real across the Kubernetes nodes in your cluster. Behind the scenes, the Deployment creates a ReplicaSet that manages the actual pods. If a pod crashes or a node fails, the ReplicaSet creates a replacement automatically. For traffic that grows over time, set up a horizontal pod autoscaler (HPA). It adjusts pod count based on resource usage, so your application handles demand without manual adjustment.

Scaling means adjusting the number of running pods based on demand. You can do this manually by setting the replica count in your deployment: If one pod fails, the deployment controller creates a replacement. But manual scaling is not practical in dynamic environments. Imagine you run an online shoe store. During the day, traffic increases; at night, it drops. Keeping a fixed pod count wastes resources at night and risks crashing during peak demand. That is where the Horizontal Pod Autoscaler (HPA) comes in. It adjusts replica count automatically based on CPU and memory usage.

The features of Kubernetes, are as follows: Related Readings: Kubernetes for Beginners

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

Basically, K8s is designed in such a manner that it allows the developers to feed cluster services and each service is designed according to a certain configuration. After feeding the cluster services with the desired codes and commands, then the cluster will automatically run configuration in the infrastructure.

For quick, efficient tasks, Kubernetes provides a Job and a CronJob API to manage such tasks.

Kubernetes monitoring is the process of monitoring the health and performance of a Kubernetes cluster and its applications.

Pod Security Standards define policies to control pod behavior, such as restricting privileged containers, root filesystem access, and host networking, enforced via admission controllers.

Kubernetes Kibana is an open-source data visualization and analysis tool that provides real-time analysis of logs and other data generated by Kubernetes clusters.

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

Core Components: Labels are key/value pairs that are attached to Kubernetes resources to give them identifying attributes. Annotations are used to attach arbitrary non-identifying metadata to objects.

ConfigMaps stores non-sensitive configuration data, while secrets stores sensitive data like API keys and passwords. Using secrets allows you to avoid putting secret information into your application code. In contrast, ConfigMaps will enable you to make your applications more configurable, as these values can be easily edited, and you don't need to persist them in your application code. Example ConfigMap YAML definition: apiVersion: v1 kind: ConfigMap metadata: name: my-config data: database_url: "postgres://db.example.com" Example secret YAML definition (with base64 encoded [not encrypted] data): apiVersion: v1 kind: Secret metadata: name: my-secret type: Opaque data: password: cGFzc3dvcmQ= # "password" encoded in Base64

- Metrics: Prometheus + Grafana, or Amazon Managed Prometheus. - Logging: FluentBit → Amazon CloudWatch Logs. - Tracing: AWS X-Ray or OpenTelemetry. - Dashboards: Amazon Managed Grafana or open-source Grafana.

Advantages of Kubernetes: Includes efficient bin packing of containers, self-healing mechanisms (auto-restarts), scalable and easy deployment patterns, and rich service discovery and load balancing capabilities.