100 must-know Kubernetes interview questions and answers in 2025

Here are some of the resource monitoring tools:

• Grafana
• Kibana
• CAdvisor
• Prometheus
• SolarWinds
• ElasticSearch
• Sysdig

Grafana is an open-source interactive data visualization platform. It was developed by Grafana Labs, which allows users to see their data via charts, graphs, and alerts for the web when connected to supported data sources. It is divided into frontend and backend, written in TypeScript and Go, respectively.

CAdvisor stands for container advisor, which discovers active containers and monitors them. The tool runs as a daemon process in the background, collecting, aggregating, and processing useful DevOps information. With CAdvisor you can track historical resource usage with histograms and analyze the memory footprint of the code running on servers. It primarily helps understand resource consumption.

Prometheus is an open-source monitoring and alerting system of the Cloud Native Computing Foundation. It was originally developed by SoundCloud and is designed to help users monitor their systems and applications by collecting and processing real-time metrics data. Prometheus has a powerful query language and a flexible alerting system that allows users to define custom rules and receive alerts when certain conditions are met.

Additionally, Prometheus offers various options for data visualization, including built-in graph and dashboarding capabilities. Prometheus supports static and dynamic service discovery mechanisms to discover and monitor targets automatically.

They are the same but differ only in using selectors to reproduce pods.The replication controller allows us to create multiple pods easily, but if a pod crashes, it ensures it is replaced with a new pod. It can scale the number of pods and update or delete multiple pods with a single command.

The replica set is the same as the replication controller except that they have more options for the selectors. They use set-based selectors to manage the pods. Here the rolling-update command won't work.

A replica set in Kubernetes uses label selectors to identify which pods it should manage. The selectors specify a set of key-value pairs that the replica set uses to match against the labels applied to the pods. Set-based selectors allow filtering keys according to a set of values. There are three kinds of operators: in, not in, and exists. The replica set will look for pods whose labels match the selectors.

Replication controllers use label selectors to identify the set of pods that they manage. Specifically, they use equality-based selectors, which allow filtering by label key and values. These selectors look for pods with labels that match a specific key-value pair. To use an equality-based selector, you can use the "-l" or "--selector" option.

They allow filtering by label keys and values. Thus they will only look for pods with the exact same phrase as the label. When a pod or other resource is created, it can be labeled with key-value pairs. Equality-based selectors allow you to select resources based on an exact match of those key-value pairs.

Application monitoring with Kubernetes is not reliant on a single monitoring provider. You can utilize resource metrics or entire metrics pipelines to collect monitoring information on new clusters.

The resource metrics pipeline only delivers a subset of metrics related to cluster components such as the Horizontal Pod Autoscaler controller and the kubectl top function. The lightweight, short-term, in-memory metrics server collects these measurements, which are then provided via the metrics.k8s.io API.

A complete metrics pipeline gives you access to more detailed metrics. Using technologies such as the Horizontal Pod Autoscaler, Kubernetes may respond to these indicators by dynamically scaling or adjusting the cluster based on its present condition.

The Headless Service creates a service grouping that does not allocate an IP address or forward traffic. So here, the spec.clusterIP is explicitly set to "None," and the spec.type is set to "ClusterIP."

This service is used for stateful apps, such as databases, where it is essential to maintain a consistent network identity for each instance. With Headless service, you don't need the proxy to reach the pods.

Here are some of the security measures we can take:

• Limit the access to ETCD
• Implement network segmentation
• Define source quota
• Provide limited access to nodes of Kubernetes

Federated clusters help manage multiple Kubernetes clusters, which means you can manage multiple Kubernetes clusters in one place. It provides a centralized view of all the clusters, making it easier to manage and scale applications across different clusters.

Using a federated cluster, you can deploy and manage applications consistently across all your clusters, enabling better workload distribution, resource management, and redundancy.

The automated configuration, coordination, and management of computer systems, services, and applications is called orchestration in DevOps. It leverages DevOps tools that allow for version control, rapid updates and releases, and other best practices for software engineering.

Orchestration in software involves coordinating and managing multiple computer systems, applications, and/or services, stringing together various tasks to execute a larger workflow or process. These processes can consist of numerous tasks that are automated and can involve multiple systems.

This is one of the most popular k8s interview questions. When security updates become available, the Kubernetes administrator must execute the maintenance work of applying the security patch to the running container to prevent it from becoming vulnerable, which is an inevitable component of the administration. To safely drain the K8s node, use the following two commands:

• kubectl cordon
• kubectl drain –ignore-daemon set

Here are some key differences between Docker Swarm and Kubernetes:

Architecture: Docker Swarm is a clustering and scheduling tool for Docker containers, while Kubernetes is a container orchestration platform that can manage containers from different container runtimes such as Docker, containerd, and CRI-O.

Installation: Docker Swarm has a simple installation process, and it is relatively easy to set up and manage a Swarm cluster. Kubernetes, on the other hand, has a more complex installation process and requires a lot of configuration and setup before the cluster is up and running.

Scalability: Docker Swarm and Kubernetes can scale horizontally by adding or removing nodes, but Kubernetes has more advanced scaling features than Swarm.

Load balancing: Kubernetes has an advanced load-balancing feature that can distribute traffic across containers based on various factors such as resource utilization, network latency, and more. Swarm, on the other hand, has a simpler load-balancing mechanism that relies on round-robin scheduling.

Here are some of the features of Kubernetes:

• Manages clusters at the same time
• Monitors nodes and containers
• Scales resources vertically and horizontally
• Automated deployment and rollout of containerized applications
• Self-healing capabilities to restart or replace failed containers automatically
• Load balancing and service discovery for distributing traffic across containers

As Kubernetes helps efficiently optimize resources, it helps with resource distribution. The orchestration tool also ensures that specific resources are used with the application to enhance overall operational efficiency.

Load balancing: Kubernetes provides a built-in load balancer to distribute incoming network traffic to the pods running on the cluster. This helps to evenly distribute the workload across the nodes in the cluster, which can help to optimize resource utilization.

Auto scaling: Kubernetes can automatically scale the number of replicas of a pod based on the resource utilization of the existing pods. This helps to ensure that there are always enough resources available to handle the workload and can help to optimize resource utilization.

Resource management: Kubernetes allows you to specify the resource requirements and limits for each pod, which helps to ensure that the right amount of resources is allocated to each pod.

An organization can use the DevOps framework to achieve low cost and improve technical operations. Here’s how an organization can use Kubernetes to improve technical operations and keep costs low:

Automate the deployment process: Kubernetes provides automated deployment of containerized applications, which reduces manual intervention and saves time. Organizations can use Kubernetes to automate the deployment process and improve technical operations.

Efficient resource utilization: Kubernetes can optimize the use of computing resources by allowing containers to share resources and run on the same nodes. This feature helps to reduce the cost of infrastructure by utilizing resources efficiently.

Horizontal scaling: Kubernetes allows an organization to scale its applications horizontally by adding more containers to the cluster. This feature allows organizations to handle increased traffic without over provisioning resources, which can lead to cost savings.

Monitoring and logging: Kubernetes provides monitoring and logging capabilities, which allow an organization to identify and resolve issues quickly. By using these features, organizations can improve technical operations and reduce the cost of troubleshooting.

A node status contains address, condition, capacity, and info. It identifies the status of the nodes within the system.

Address: It depends on your cloud provider or bare metal configuration whether you have to use it or not.

Condition: It discusses the status or conditions of all running nodes.

Capacity: This block tells about the total resources processed by the node.

Info: It discusses general information about the node, such as the Kubernetes version, kernel version, container runtime details, and the current operating system which the node uses.

The process that runs on the Kubernetes master node is the Kube-apiserver. This process is the access point for all the REST commands that control the cluster. It is the only Kubernetes control panel component with a user-accessible API and the sole master component you will interact with. It acts as a gateway to the cluster and supports life cycle orchestration.

Pods are fundamental structures in Kubernetes that represent a single instance of a running process in a cluster. A pod encapsulates one or more containers, which share the same network namespace and can communicate with each other through the localhost interface.

Pods provide a logical unit of deployment in Kubernetes, allowing for easy scaling and management of containerized applications. They can be used to deploy stateless services and stateful applications that require shared storage or coordination between containers.

Each pod in Kubernetes has a unique IP address, which allows it to communicate with other pods and services in the cluster.

Kube-scheduler allows nodes to schedule freshly created pods. It determines which nodes are accurate placements for every pod in the scheduling queue according to available resources and constraints. This scheduler selects an optimal node for each new Pod or unscheduled Pod for them to run on. But still, every container in pods has different requirements for resources and needs.

The clusters of containers in Kubernetes are a set of nodes. They create some routes so the containers running on the nodes can communicate. They allow containers to run across multiple machines and environments, such as physical, virtual, and cloud-based. Kubernetes clusters coordinate processes such as scheduling and scaling applications, maintaining a cluster's state, and implementing updates.

The DaemonSets are pod sets that run on a host only one time on a host. And so, they are used attributes of host layers such as -network or network monitoring. DaemonSet enables you to run the Kubernetes pod on the cluster nodes that fulfill certain criteria or requirements. It ensures that some or all nodes run a copy of a pod. DaemonSets are used to deploy background services, run cluster storage, log collection, and deploy a node monitoring daemon on every node

Some initial namespaces are as follows:

Default: This namespace is included by Kubernetes so that users can start using the new cluster without needing first to create a namespace.

Kube-system: It is the namespace for objects and is created by the Kubernetes system.

Kube-public: This namespace is readable to authenticated and non-authenticated clients alike. It is reserved mainly for cluster usage.

It is a default service in Kubernetes that apps inside your cluster can access. It provides a load-balanced IP address. One or more pods matching the label selector can forward traffic to the IP address.

With ClusterIP addresses, it is easier to manage and connect services in a Kubernetes cluster easier. Because each service has a unique IP address, traffic can be easily routed to the correct service without knowing the underlying pods' specific IP address.

NodePort is a Kubernetes networking concept that allows external traffic to access a service in a cluster directly. It is done by opening a specific port on all nodes and sending traffic from this port to the service. When a service is created with a NodePort type, Kubernetes assigns a static port number to the service. The assigned port is then opened on every node in the cluster. This allows any traffic that is sent to this port on any node to be forwarded to the corresponding service.

It is an object that lets users access services from your Kubernetes, even outside the Kubernetes cluster. You can also configure the access by defining which connections reach which services.

As it is an API object, it provides some routing rules. You can easily manage user access for the services in the Kubernetes cluster through these rules. It is done through HTTPS/ HTTP. Hence users can easily set rules for traffic routing without needing load balancers.

Within a pod, containers share networking space and can reach one another through localhost. This means they can communicate using standard inter-process communication mechanisms like TCP/IP or Unix domain sockets as if running on the same machine. In addition to communicating through localhost, pod containers can communicate with each other using Kubernetes services or environment variables.

Where Secret stores critical data in an encrypted format, ConfigMaps stores the configuration of an application in a normal plain text format. However, both of them can be used as volume and be mounted on a pod through a pod definition file.

It stands for Role-Based Access Control. It allows the management of permissions for users and groups inside a Kubernetes cluster. With RBAC, one can set access permissions and the required conditions to fulfill to gain access. Roles define a set of permissions granted to users or groups, and role bindings associate roles with specific users or groups.

Using RBAC, you can limit access to sensitive resources and ensure that only authorized users and applications can perform certain actions within the cluster. This helps to improve the security and reliability of your Kubernetes environment.

You can get a static IP for a Kubernetes load balancer by changing the DNS records. You must also check the Kubernetes version and allocate static IPs under Networking > External IP addresses. You can follow these steps for assigning a static IP:

• Reserve a static IP address from your cloud provider's pool of available IPs.
• Create a Kubernetes service of type "LoadBalancer."
• Assign the reserved static IP address to the service using the loadBalancerIP field in the service definition.
• Check that the service uses the static IP address by inspecting the service using the kubectl describe service.

Some tools we can use for container orchestration are:

Docker Swarm: It is an orchestration management tool running on Docker applications that helps in the creation and deployment of Docker nodes.

Apache Mesos: It is a cluster manager that helps in resource isolation and sharing.

Kubernetes: Kubernetes (commonly abbreviated K8s) is an open-source container orchestration system that automates software deployment, scaling, and management.

Here are some of the objects used by Kubernetes:

• Pods
• Controllers and replication set
• Cron jobs
• DaemonSets
• Distinctive identities
• Stateful sets
• Deployments

StatefulSets are a type of workload API that manage stateful applications. They can also be used to manage the scaling and deployment of pod sets. StatefulSets are often used to manage the deployment and scaling of pods that require stable network identities and persistent storage, making them well-suited for stateful workloads.

DaemonSets are used for the following reasons:

Running system-level services: DaemonSets are often used to run system-level services that need to be deployed on every node in the cluster, such as logging agents, monitoring agents, or network services like load balancers.

Data collection: DaemonSets can collect data or metrics from each node in the cluster, such as system metrics, network traffic, or application logs.

Consistent deployment: By using DaemonSets to deploy services or applications, you can ensure that they are deployed consistently across all nodes in the cluster, which can help reduce configuration errors and ensure consistent operation.

High availability: Running services or applications as DaemonSets can provide high availability, as they can be automatically deployed on any new nodes added to the cluster and replaced if a node fails or becomes unavailable.

Resource isolation: Running services or applications as DaemonSets can provide resource isolation, as they can be deployed on specific cluster nodes with the necessary resources or configurations, such as specialized hardware or network connections.

In Kubernetes, managing applications isn't as simple as maintaining stateless applications where each replica reaches the required status and updates are done the same way. Because of the stateful nature of stateful applications, upgrading each replica may necessitate distinct treatment. As a result, managing stateful applications frequently necessitates using a human operator. This is where Kubernetes Operator is useful.

Kubernetes Operators are software extensions that automate the management of complex applications on Kubernetes clusters. Operators are designed to be highly customizable and adaptable to the needs of specific applications. They can perform tasks such as monitoring the health of an application, performing backups and restores, upgrading or rolling back versions, scaling resources up or down, and more.

Some Kubectl commands are:

• kubectl annotate
• kubectl config
• kubectl autoscale
• kubectl config current-context
• kubectl apply
• kubectl config set.
• kubectl cluster-info
• kubectl attach

Kube-apiserver is used to configure and validate API objects. Also, it is used to enable users to interact with the Kubernetes cluster where the Kubernetes server API is used. Thus, it is the front-end part of the control plane, and it is this frontend that tests whether the incoming request is legitimate or not.

A Kube-apiserver validates and provides data for API objects and includes pods, services, and replication controllers. The API server sends command REST operations and provides the frontmost to the cluster's shared state through which all other components interact.

Syntax:

kube-apiserver [flags]

To update the Kubernetes cluster, one needs to update the components of the cluster. and the specific instructions to upgrade the same depends on the specific setup and configuration used with your cluster.

Here's the upgrade process:

• First, find the desired target version and upgrade plan.
• Save crucial data and configuration by taking the backup.
• Now, upgrade the control plane components.
• Also, upgrade the worker nodes, one by one, through a rolling upgrade process.
• Finally, verify whether the cluster and the components are functioning properly.

The two Kubernetes pods are single-container pods and multi-container pods. Here’s a brief explanation of each.

Single-container pods: These pods contain only one container and are the most common type of pod used in Kubernetes. They can be created using commands such as kubectl run or kubectl create.

Multi-container pods: These pods contain multiple containers that are tightly coupled and need to run together on the same host. Multi-container pods are created using the kubectl create command with a YAML file that defines the pod's configuration..

Labels are added to objects during their creation and can be altered by the users at run time. They are precisely collections of keys that hold some values.

They are a type of metadata that work through the concept of key-value pair attached to objects. In many cases, they are also used to define "identifying aspects" of an object mainly to help the user at a later stage. Also, as they do not imply semantics to Kubernetes by default, they do not directly change any functionality like other metadata.

Some of the objectives of a replication controller are:

• Control and administer pod lifecycle
• Monitor and verify the permissible number of replicas
• Help user to check pod status
• Enable the alteration of pod

Persistent volume (PV) is a storage piece that an administrator provides to a Kubernetes cluster. Suppose a developer needs persistent storage for an application in a cluster; they do so by creating a persistent volume claim (PVC) and then mounting the volume to a path in the pod. Once this process is done, the pod can claim any volume matching its requirements.

Yes, the Secrets in Kubernetes are objects that hold sensitive information such as login credentials for the user, passwords, OAuth tokens, and SSH keys. Here “Secrets” give you more control over this information and its accidental exposure. Using Secrets, Kubernetes ensures that the sensitive data is encrypted, only authorized entities can access it, and it is not exposed to unauthorized users or applications.

The Sematext Docker Agent is a lightweight log collection agent that runs as a container on a Docker host. It collects and streams logs, events, and metrics from Docker containers and nodes to Sematext Cloud, a cloud-based monitoring and logging platform. With Sematext Docker Agent, users can monitor their Docker environments in real-time, troubleshoot issues quickly, and gain insights into container performance. Sematext Docker Agent supports Kubernetes, Docker Swarm, and other container orchestration systems.

It is a public cloud Kubernetes platform that aids developers in building applications. Its offerings include automated installation, life cycle management, and upgrades. OpenShift provides developers with tools and services to build, deploy, and manage applications in a containerized environment. These tools include an integrated development environment (IDE), container images, source code management, automated builds, and deployments.

Securing APIs on Kubernetes is crucial to prevent unauthorized access and data breaches. One approach is to implement Role-Based Access Control (RBAC) policies with the kube-dashboard, which allows defining permissions for individual users or groups. Another option is to use Kubeless, a Kubernetes-native serverless framework, to protect APIs by automatically injecting security measures such as rate limiting and authentication. Additionally, it's important to use the correct authorization mode, such as the Node Authorizer or Attribute-Based Access Control (ABAC), to ensure that only authorized requests are accepted. By combining these methods, Kubernetes can provide strong API security for your applications.

The scheduler in K8 is in charge of spawning pods into nodes. A variety of circumstances can cause unstartable POD. The most typical reason for POD not starting is a lack of resources; use commands like kubectl describe POD> -n Namespace> to find out why. Also, watch kubectl get events to observe the cluster's events.

The different types of Kubernetes volumes are as follows:

EmptyDir: This volume is first created when a node is assigned with a pod. Initially, it is empty. A volume of type emptyDir is available for the lifetime of the pod.

Flocker: It is an open-source and clustered container data volume manager.

HostPath: This volume mounts a file or directory from the host node's filesystem into the pod. It can provide access to host files or share files between containers on the same host.

NFS: Network File System (NFS) allows computers to either access or share files over the network. It is a dedicated file storage when multiple users must retrieve data for centralized disk capacity.

PVC stands for Persistent Volume Claim, a request made by a user for storage in a Kubernetes cluster. When a user creates a PVC, Kubernetes matches it with an appropriate Persistent Volume (PV) based on the storage requirements and properties specified in the PVC.

Persistent Volumes are network-attached storage devices that multiple pods can access in a cluster. A PVC is a request for a specific amount of storage, which is bound to a single pod or multiple pods, depending on the user's requirements.

The Kubernetes network policy indicates how pods in the same namespace communicate with one another and the network endpoint. Network policies allow you to control traffic at the IP address and port level. With Kubernetes network policy, you can define rules that specify which traffic can flow between pods and which traffic should be blocked.

Using the default namespace alone makes it difficult to keep track of all the applications you can manage in your cluster over time. Custom namespaces help in grouping apps into logical groupings, such as one namespace for monitoring programs and another for security applications, and so on. This makes it easier to manage and monitor different applications within your cluster and control access to specific resources.

We can use the following commands

• Use the command ‘kubectl cordon’ to mark the node as “un-schedulable”. This moves the node to maintenance mode and prevents new pods from being scheduled on it.
• The ‘kubectl drain –ignore-daemon-set’ command removes the existing pods from the node. The ‘--ignore-daemon-set’ option will skip over any pods that are part of a DaemonSet, which ensures that essential system services are not disrupted.

Here are the steps for performing maintenance in a single pod:

• Get the name of the pod you want to perform maintenance using the command
• Put the pod in maintenance mode by adding a label to it. You can use any label name, but here we'll use "maintenance-mode."
• Verify that the label has been applied to the pod
• Perform maintenance on the pod as needed
• Remove the maintenance label from the pod when you're done
• Verify that the label has been removed

We can control the resource usage of the pod through the use of limit and request.

Request: It controls the minimum guaranteed amount of resources (CPU and memory) that are required for a container.

Limit: It puts a limit on the resources any single container can make use of. This means that the container can never consume more than the memory amount or CPU amount indicated.

You can think of it as request is the minimum amount of resources to be used by a pod while limit is the maximum amount of resources that pod can use.

Kubernetes (K8s) runs various services on nodes, including:

On Worker Nodes:

kubelet: Responsible for node management and ensuring that containers are running as expected.

kube-proxy: Provides network proxy services to enable communication between nodes and services.

On Master Nodes:

kube-apiserver: Provides the Kubernetes API through which all the other components interact with the cluster.

kube-scheduler: Assigns newly-created pods to a node based on resource availability and other constraints.

kube-controller-manager: Monitors the cluster state and performs tasks to maintain desired state, such as scaling up or down.

Other services that may run on worker nodes include kube-dns, which provides DNS resolution for Kubernetes services, and kubelet, which manages pod lifecycles on the node.

The PDB (Pod Disruption Budget) allows you to limit the disruption to application use when its pods need to be rescheduled for some other reason on the Kubernetes nodes.

Kubernetes' Pod Disruption Budget (PDB) is a handy layer of defense for dealing with this type of issue. If you already have a Kubernetes cluster in production, the command ‘kubectl get pdb —all-namespaces’ will show you all the PDBs in all the namespaces of your Kubernetes cluster.

A Kubernetes administrator can make a one-of-a-kind deployment. Pod Disruption Budget ensures that the application's minimum number of running pods is preserved, as specified by the property minAvailable in the spec file. It is useful while executing a drain, as the drain will stop until the PDB is respected, ensuring the application's High Availability (HA). In the following spec file, minAvailable is set to 2, implying that the minimum number of available pods is two (even after the election).

If you use default namespaces alone, it gets difficult in the long run since you will not be able to manage them within a cluster as a whole. By default, all resources in a Kubernetes cluster are created in the default namespace, but as your application grows and you add more resources, it can become difficult to manage them all in one namespace.

With custom namespaces, this problem is resolved. By creating custom namespaces, you can logically group your resources based on your needs, such as separating production and development environments or separating applications by team or department. This makes it easier to manage and maintain your resources within the cluster, and also provides better security and resource isolation.

There are some common logging patterns as follows:

Node level logging agent: This involves installing a logging agent directly on the node where the pod is running. The logging agent collects logs from all the containers on that node and sends them to a central logging server.

Streaming sidecar container: In this pattern, a separate container, known as a sidecar, is added to the pod. The sidecar container is responsible for streaming the logs from the other containers in the podto a central logging server.

Sidecar container with the logging agent: Similar to the streaming sidecar container pattern, a separate container is added to the pod. However, in this pattern, the sidecar container also includes a logging agent that collects logs from the other containers in the pod and streams them to a central logging server.

Fluentd logging pattern: This pattern involves deploying Fluentd, a unified logging layer, to capture, filter, and forward logs generated by the main container to a central logging system.

By using LoadBalancer as follows

The type LoadBalancer field creates an external load balancer to distribute traffic to the service across the worker nodes.

If a node is tainted, pods will not be scheduled on it by default, but you can use tolerations in the pod spec to allow specific pods to be scheduled on the tainted node. Tolerations are used to specify that a pod can tolerate (or "ignore") a certain taint, allowing it to be scheduled on a tainted node. This can be useful in scenarios where you want to reserve certain nodes for specific types of workloads or to mark nodes as unsuitable for certain workloads.

We can achieve zero downtime in Kubernetes through RollingUpdate strategy. It is a process that allows updating the Kubernetes system with little effect on performance and zero downtime. This strategy involves gradually replacing old instances of an application with new ones, thus ensuring that the application is always available to end-users.

When you use RollingUpdate strategy, Kubernetes creates a new replica set with the updated version of your application and gradually replaces the old replica set with the new one. This ensures that the new version is rolled out to users gradually and any issues can be caught early.

We can check that a pod always runs through a liveness probe. In case the check fails, it restarts the container. This probe is helpful in multiple instances when the container runs but the application crashes.

Example:

In this example, the "/heal" endpoint of the "k8s.gcr.io/liveness" container is checked by the liveness probe. If the probe fails to receive a response from this endpoint, Kubernetes will automatically restart the container. This helps ensure that the pod always runs, even if the container encounters issues.

No, it doesn't look right since there is only 1 replica, and any changes to the state full set may result in an outage. It means that the rolling update of a StatefulSet needs to rip apart one or more old pods before replicating them. Therefore, it's generally recommended to have at least two replicas in a StatefulSet to ensure high availability during rolling updates.

In such cases, SIGKILL instantly ends the container and spawns a new one using out of memory (OOM) error. This will result in the kernel sending a SIGKILL signal to the process running inside the container. By default, Kubernetes will send a SIGTERM signal to the container's main process and wait for a certain period of time (determined by the terminationGracePeriodSeconds parameter) for the process to exit gracefully.

We can run a pod on a specific node using node affinity. Here, a node is assigned to an arbitrary label, and they are configured to be assigned to that node as per the label created.

For example, this code snippet creates an arbitrary label, node location, and assigns the value Germany to the node named person-01:

kubectl label nodes person-01 nodelocation=Germany

Inside Kubernetes, when the master node fails, the cluster remains operational. There is no effect on the pod creation or any service member changes.

If a worker node fails, the master stops receiving updates, and any pods running on the failed worker node are terminated. The Kubernetes scheduler will then create new replicas of the terminated pods on other healthy worker nodes in the cluster.