Top 100 Kubernetes Interview Questions

1. What is Kubernetes?

Kubernetes (often abbreviated as K8s) is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. It was originally designed by Google and is now maintained by the Cloud Native Computing Foundation (CNCF). You can learn more from the official Kubernetes website.

2. What is the difference between Docker and Kubernetes?

• Docker is a platform for building and running individual containers.
• Kubernetes is a system for managing and orchestrating containers across a cluster of machines.

Kubernetes often uses Docker (or another container runtime like containerd) to run the containers, but its primary role is to manage the application's lifecycle, scaling, and availability.

3. What are the main components of the Kubernetes architecture?

The Kubernetes architecture consists of a Control Plane (master nodes) and Worker Nodes.

• Control Plane Components: kube-apiserver, etcd, kube-scheduler, kube-controller-manager.
• Worker Node Components: kubelet, kube-proxy, Container Runtime (e.g., Docker).

4. What is a Pod?

A Pod is the smallest and simplest deployable unit in Kubernetes. It represents a single instance of a running process in your cluster. A Pod can contain one or more containers that are co-located, share the same network and storage resources, and are always scheduled together on the same node.

5. What is the role of the kube-apiserver?

The kube-apiserver is the front-end for the Kubernetes control plane and the only component that communicates directly with etcd. It validates and processes REST requests, updates etcd, and notifies other components of changes.

6. What is etcd and what is its role in Kubernetes?

etcd is a distributed, consistent key-value store used by Kubernetes to store all cluster data, including configuration data, state information, and metadata. It serves as the "source of truth" for the cluster.

7. What is the role of the kube-scheduler?

The kube-scheduler is responsible for assigning Pods to nodes based on resource requirements, constraints, and policies. It considers factors like resource requirements, hardware/software constraints, affinity/anti-affinity specifications, and data locality.

8. What is the role of the kube-controller-manager?

The kube-controller-manager runs controller processes that regulate the state of the cluster. It includes controllers for nodes, replication, endpoints, service accounts, and tokens. Each controller watches the shared state of the cluster through the apiserver and makes changes to move the current state toward the desired state.

9. What is the role of the kubelet?

The kubelet is an agent that runs on each node in the cluster. It ensures that containers are running in a Pod by taking a set of PodSpecs provided through various mechanisms and ensuring the described containers are running and healthy.

10. What is the role of kube-proxy?

kube-proxy is a network proxy that runs on each node in the cluster. It maintains network rules on nodes that allow network communication to Pods from inside or outside the cluster. It uses the operating system packet filtering layer if available, or forwards the traffic itself.

11. What is a Deployment in Kubernetes?

A Deployment provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment, and the Deployment controller changes the actual state to the desired state at a controlled rate. Deployments are used to manage stateless applications.

12. What is a ReplicaSet?

A ReplicaSet ensures that a specified number of Pod replicas are running at any given time. While Deployments are the recommended way to manage ReplicaSets, ReplicaSets can be used independently to maintain a stable set of replica Pods.

13. What is a StatefulSet?

A StatefulSet is a workload API object used to manage stateful applications. It provides guarantees about the ordering and uniqueness of Pods. StatefulSets maintain a sticky identity for each Pod, making them suitable for applications that require stable network identifiers, persistent storage, and ordered deployment and scaling.

14. What is a DaemonSet?

A DaemonSet ensures that all (or some) nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. DaemonSets are commonly used for cluster-wide services like logging, monitoring, or storage.

15. What is a Job in Kubernetes?

A Job creates one or more Pods and ensures that a specified number of them successfully terminate. As Pods successfully complete, the Job tracks the successful completions. Jobs are used for batch processing or one-off tasks.

16. What is a CronJob?

A CronJob creates Jobs on a time-based schedule. It uses the standard cron format for scheduling. CronJobs are useful for periodic and recurring tasks like backups, report generation, or email sending.

17. What is the difference between a Deployment and a StatefulSet?

• Deployment: For stateless applications, Pods are interchangeable, no stable network identity, no persistent storage requirements.
• StatefulSet: For stateful applications, Pods have stable unique identifiers, stable persistent storage, ordered deployment and scaling.

18. What is a ReplicationController?

A ReplicationController ensures that a specified number of Pod replicas are running at any given time. It has been largely replaced by ReplicaSets and Deployments, but is still supported. ReplicaSets provide more expressive pod selection capabilities.

19. How do you perform a rolling update with a Deployment?

You can update a Deployment by changing the Pod template spec. Kubernetes will perform a rolling update by gradually replacing old Pods with new ones. The update strategy can be configured with maxUnavailable and maxSurge parameters to control the update process.

20. How do you roll back a Deployment?

You can roll back a Deployment to a previous revision using the kubectl rollout undo command: kubectl rollout undo deployment/[deployment-name]. You can also specify a specific revision with the --to-revision flag.

21. What is the difference between a Pod and a Container?

A container is a running instance of an image, while a Pod is a Kubernetes abstraction that represents a group of one or more containers with shared storage/network resources and a specification for how to run the containers.

22. What are Init Containers?

Init Containers are specialized containers that run before app containers in a Pod. They can contain utilities or setup scripts not present in the app image. Init Containers always run to completion and each must complete successfully before the next one starts.

23. What are the different Pod restart policies?

Pod restart policies include:

• Always: Always restart the container (default)
• OnFailure: Restart only if the container exits with a non-zero status
• Never: Never restart the container

24. What are the different Pod lifecycle phases?

Pod phases include:

• Pending: Pod has been accepted but containers not created
• Running: Pod is bound to a node and all containers are created
• Succeeded: All containers have terminated successfully
• Failed: All containers have terminated, at least one failed
• Unknown: Pod state could not be obtained

25. What are the different image pull policies?

Image pull policies include:

• Always: Always pull the image
• Never: Never pull the image, use local only
• IfNotPresent: Pull only if not present locally (default)

26. What is the difference between requests and limits?

• Requests: The amount of resources that are guaranteed to the container. Kubernetes uses this to schedule Pods on nodes.
• Limits: The maximum amount of resources a container can use. If a container exceeds its memory limit, it might be terminated.

27. What are liveness and readiness probes?

• Liveness probe: Determines if the container is running. If it fails, the container is restarted.
• Readiness probe: Determines if the container is ready to serve requests. If it fails, the Pod is removed from service endpoints.

28. What are the different types of probes?

Probe types include:

• HTTP GET: Sends an HTTP GET request to the specified path
• TCP Socket: Attempts to open a TCP connection to the specified port
• Exec: Executes a specified command inside the container

29. What is a Horizontal Pod Autoscaler (HPA)?

A Horizontal Pod Autoscaler automatically scales the number of Pods in a replication controller, deployment, replica set, or stateful set based on observed CPU utilization or other custom metrics.

30. What is a Vertical Pod Autoscaler (VPA)?

A Vertical Pod Autoscaler automatically adjusts the CPU and memory requests and limits of Pods based on usage. It can both down-scale Pods that are over-requesting resources and up-scale Pods that are under-requesting resources.

31. What is a Service in Kubernetes?

A Service is an abstraction that defines a logical set of Pods and a policy by which to access them. Services enable network access to a set of Pods, providing a stable IP address and DNS name, and load balancing across the Pods.

32. What are the different types of Services?

Service types include:

• ClusterIP: Exposes the service on a cluster-internal IP (default)
• NodePort: Exposes the service on each Node's IP at a static port
• LoadBalancer: Exposes the service externally using a cloud provider's load balancer
• ExternalName: Maps the service to the contents of the externalName field

33. What is an Ingress?

An Ingress is an API object that manages external access to services in a cluster, typically HTTP/HTTPS. Ingress provides load balancing, SSL termination, and name-based virtual hosting. It requires an Ingress controller to function.

34. What is an Ingress controller?

An Ingress controller is responsible for fulfilling the Ingress rules. It's typically a reverse proxy or load balancer that runs in the cluster. Common Ingress controllers include Nginx, Traefik, HAProxy, and cloud-provider specific controllers.

35. What is the difference between a Service and an Ingress?

• Service: Provides internal service discovery and load balancing, operates at L4 (TCP/UDP).
• Ingress: Provides external access with HTTP/HTTPS routing capabilities, operates at L7 (HTTP).

36. What is a NetworkPolicy?

A NetworkPolicy specifies how groups of Pods are allowed to communicate with each other and other network endpoints. Network Policies are implemented by a network plugin that supports the Kubernetes NetworkPolicy API.

37. What is the Kubernetes DNS service?

Kubernetes includes a built-in DNS service that provides DNS records for Services and Pods. Services are assigned a DNS name in the form my-svc.my-namespace.svc.cluster-domain.example, and Pods get a DNS record in the form pod-ip-address.my-namespace.pod.cluster-domain.example.

38. What is CoreDNS?

CoreDNS is a flexible, extensible DNS server that has become the default DNS service in Kubernetes clusters. It replaced kube-dns as the default cluster DNS in Kubernetes version 1.13+.

39. What is a Headless Service?

A Headless Service is created by setting clusterIP: None in the service specification. Instead of load-balancing, it returns the IP addresses of the Pods associated with the service. This is useful for stateful applications or when you want to communicate with specific Pods directly.

40. What is the difference between ClusterIP and NodePort?

• ClusterIP: Exposes the service on an internal IP in the cluster, only accessible within the cluster.
• NodePort: Exposes the service on each Node's IP at a static port, accessible from outside the cluster.

41. What is a LoadBalancer Service?

A LoadBalancer Service exposes the service externally using a cloud provider's load balancer. It automatically creates a NodePort and ClusterIP service to which the external load balancer routes traffic.

42. What is the Kubernetes Service Discovery mechanism?

Kubernetes provides service discovery through:

• Environment variables injected into Pods
• DNS service that provides DNS records for Services
• The Kubernetes API server

43. What is the CNI (Container Network Interface)?

The Container Network Interface (CNI) is a plugin specification that defines how network connectivity should be provided to containers. Kubernetes uses CNI plugins to implement pod networking. Popular CNI plugins include Calico, Flannel, Weave Net, and Cilium.

44. What are the requirements for Kubernetes networking?

Kubernetes networking model requires that:

• All containers can communicate with all other containers without NAT
• All nodes can communicate with all containers without NAT
• The IP that a container sees itself as is the same IP that others see it as

45. What is the difference between Ingress and LoadBalancer?

• LoadBalancer: Provides L4 load balancing, typically creates a cloud load balancer per service, can be expensive.
• Ingress: Provides L7 load balancing and routing, typically uses a single load balancer for multiple services, more cost-effective for HTTP/HTTPS traffic.

46. What is a Volume in Kubernetes?

A Volume in Kubernetes is a directory accessible to containers in a Pod. Unlike container filesystems, data in volumes is preserved across container restarts. Kubernetes supports many types of volumes, including emptyDir, hostPath, and cloud provider-specific volumes.

47. What is a PersistentVolume (PV)?

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. PVs are cluster resources that exist independently of any individual Pod.

48. What is a PersistentVolumeClaim (PVC)?

A PersistentVolumeClaim (PVC) is a request for storage by a user. It specifies the size, access modes, and storage class required. The Kubernetes control plane binds PVCs to appropriate PVs that meet the requirements.

49. What is the difference between PV and PVC?

• PersistentVolume (PV): The actual storage resource in the cluster.
• PersistentVolumeClaim (PVC): A request for storage that gets bound to a PV.

This abstraction separates the concerns of storage administration from storage consumption.

50. What are Storage Classes?

A StorageClass provides a way to describe the "classes" of storage available. Different classes might map to quality-of-service levels, backup policies, or arbitrary policies determined by the cluster administrators. Storage Classes enable dynamic provisioning of PersistentVolumes.

51. What is dynamic provisioning?

Dynamic provisioning allows storage volumes to be created on-demand. When a PersistentVolumeClaim is created, the appropriate storage plugin automatically provisions a PersistentVolume based on the StorageClass specified in the PVC.

52. What are the different access modes for PersistentVolumes?

Access modes include:

• ReadWriteOnce (RWO): Read-write by a single node
• ReadOnlyMany (ROX): Read-only by many nodes
• ReadWriteMany (RWX): Read-write by many nodes
• ReadWriteOncePod (RWOP): Read-write by a single Pod (Kubernetes 1.22+)

53. What is the difference between emptyDir and hostPath?

• emptyDir: Temporary directory that shares a Pod's lifetime, erased when Pod is removed.
• hostPath: Mounts a file or directory from the host node's filesystem into the Pod.

54. What is a ConfigMap?

A ConfigMap is an API object used to store non-confidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or configuration files in a volume.

55. What is a Secret?

A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Secrets are similar to ConfigMaps but are specifically intended to hold confidential data and provide additional security protections.

56. What is the difference between ConfigMap and Secret?

• ConfigMap: For non-sensitive configuration data, stored as plain text.
• Secret: For sensitive data, stored as base64-encoded (not encrypted by default), with additional security considerations.

57. How do you create a ConfigMap?

ConfigMaps can be created:

• From literal values: kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2
• From a file: kubectl create configmap my-config --from-file=path/to/file
• From a directory: kubectl create configmap my-config --from-file=path/to/dir
• From a YAML manifest

58. How do you create a Secret?

Secrets can be created:

• From literal values: kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secret
• From a file: kubectl create secret generic my-secret --from-file=path/to/file
• From a YAML manifest (with base64-encoded values)

59. How can Pods consume ConfigMaps?

Pods can consume ConfigMaps as:

• Environment variables
• Command-line arguments
• Configuration files in a volume

60. How can Pods consume Secrets?

Pods can consume Secrets as:

• Environment variables
• Files in a volume (mounted as tmpfs)
• Image pull secrets for private registries

61. What are the different types of Secrets?

Secret types include:

• Opaque: Arbitrary user-defined data (default)
• kubernetes.io/service-account-token: Service account token
• kubernetes.io/dockercfg: Serialized ~/.dockercfg file
• kubernetes.io/dockerconfigjson: Serialized ~/.docker/config.json file
• kubernetes.io/basic-auth: Credentials for basic authentication
• kubernetes.io/ssh-auth: SSH credentials
• kubernetes.io/tls: TLS certificate and key

62. What is an immutable ConfigMap or Secret?

Immutable ConfigMaps and Secrets are ones that cannot be updated after creation. This provides benefits like:

• Protection against accidental updates that could cause application outages
• Significant performance improvements for clusters that use many ConfigMaps/Secrets
• Reduced load on the kube-apiserver

63. How do you update a ConfigMap or Secret that is being used by a Pod?

When a ConfigMap or Secret is updated, the changes are automatically propagated to Pods that consume them as volumes. For environment variables, the Pod needs to be restarted to pick up the changes. Some applications can watch for changes in mounted ConfigMap/Secret volumes and reload automatically.

64. What are the security best practices for Secrets?

• Enable encryption at rest for Secrets
• Use RBAC to restrict access to Secrets
• Consider using external secret management systems (e.g., HashiCorp Vault, AWS Secrets Manager)
• Use immutable Secrets where appropriate
• Regularly rotate Secrets

65. What is the difference between a ServiceAccount and a Secret?

• ServiceAccount: Provides an identity for processes that run in a Pod, used for authentication to the API server.
• Secret: Stores sensitive information that can be consumed by Pods, including service account tokens.

Each ServiceAccount has a Secret that contains its API token.

66. What is RBAC in Kubernetes?

RBAC (Role-Based Access Control) is a method of regulating access to computer or network resources based on the roles of individual users within an organization. In Kubernetes, RBAC is used to control access to the Kubernetes API.

67. What are the main components of RBAC?

RBAC in Kubernetes consists of:

• Role and ClusterRole: Define permissions (what actions can be performed on which resources)
• RoleBinding and ClusterRoleBinding: Bind roles to subjects (users, groups, or service accounts)

68. What is the difference between Role and ClusterRole?

• Role: Applies to a specific namespace
• ClusterRole: Applies to the entire cluster (cluster-scoped resources) or can be used across all namespaces

69. What is the difference between RoleBinding and ClusterRoleBinding?

• RoleBinding: Grants permissions within a specific namespace, can reference a Role or ClusterRole
• ClusterRoleBinding: Grants permissions across the entire cluster, can only reference a ClusterRole

70. What is a ServiceAccount?

A ServiceAccount provides an identity for processes that run in a Pod. When a process authenticates to the API server, it identifies itself as a particular ServiceAccount. Each Pod has a ServiceAccount associated with it (defaults to "default" if not specified).

71. What is Pod Security?

Pod Security is a Kubernetes feature that allows administrators to enforce security standards on Pods. It includes:

• Pod Security Standards: Baseline and restricted policies that define security requirements
• Pod Security Admission: A built-in admission controller that enforces these standards

72. What are the Pod Security Standards?

Pod Security Standards define three different policies to restrict the behavior of pods:

• Privileged: Unrestricted policy, provides the widest possible level of permissions
• Baseline: Minimally restrictive policy that prevents known privilege escalations
• Restricted: Heavily restricted policy, following current Pod hardening best practices

73. What is a SecurityContext?

A SecurityContext defines privilege and access control settings for a Pod or Container. It includes settings like:

• Running user and group IDs
• Linux capabilities
• SELinux options
• AppArmor profiles
• Read-only root filesystem
• Privilege escalation settings

74. What is a PodSecurityPolicy (PSP)?

PodSecurityPolicy was a cluster-level resource that controlled security sensitive aspects of the pod specification. It was deprecated in Kubernetes 1.21 and removed in 1.25, replaced by Pod Security Admission and other policy enforcement mechanisms.

75. What is the role of an Admission Controller?

An Admission Controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. They can be validating, mutating, or both. They are used to enforce security policies, add labels, or perform other validation.

76. What are taints and tolerations?

Taints and tolerations are a mechanism to control which Pods can be scheduled on which nodes.

• A Taint is applied to a node to repel Pods that do not tolerate it.
• A Toleration is applied to a Pod to allow it to be scheduled on a node with a matching taint.

This is useful for dedicating nodes to specific workloads or preventing certain workloads from running on specific nodes.

77. What is node affinity and anti-affinity?

Node affinity and anti-affinity allow you to constrain which nodes your Pod is eligible to be scheduled on, based on labels on the node.

• Affinity attracts Pods to a set of nodes.
• Anti-affinity repels Pods from a set of nodes.

There are "required" and "preferred" versions for both, allowing for hard and soft constraints.

78. What is pod affinity and anti-affinity?

Pod affinity and anti-affinity allow you to constrain which nodes your Pod can be scheduled on based on the labels of Pods already running on that node.

• Pod affinity can be used to co-locate Pods (e.g., for performance).
• Pod anti-affinity can be used to spread Pods across nodes (e.g., for high availability).

79. How does the Kubernetes scheduler decide where to place a Pod?

The scheduler uses a two-step process:

1. Filtering: The scheduler finds the set of nodes where it's feasible to schedule the Pod (e.g., nodes that have enough resources).
2. Scoring: The scheduler ranks the feasible nodes and picks the one with the highest score. The scoring is based on rules like affinity, anti-affinity, and resource availability.

80. What is a PriorityClass?

A PriorityClass is a non-namespaced object that defines a mapping from a priority class name to an integer value. The higher the value, the higher the priority. The scheduler uses this to prioritize Pods, and can preempt (evict) lower-priority Pods to make room for higher-priority ones.

81. What is the Cluster Autoscaler?

The Cluster Autoscaler is a component that automatically adjusts the size of a Kubernetes cluster by adding or removing nodes based on the resource requests of pending Pods. It works with cloud providers to provision or de-provision nodes as needed.

82. How do you manually scale a Deployment?

You can manually scale a Deployment using the kubectl scale command:

kubectl scale deployment [deployment-name] --replicas=5

This will adjust the number of replicas in the Deployment to the specified count.

83. What are resource quotas and limit ranges?

• ResourceQuota: Provides constraints that limit aggregate resource consumption per namespace. It can limit the quantity of objects that can be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that namespace.
• LimitRange: Provides constraints on the amount of resources that can be consumed by individual Pods or Containers in a namespace.

84. What is a Pod Disruption Budget (PDB)?

A Pod Disruption Budget (PDB) limits the number of Pods of a replicated application that are down simultaneously from voluntary disruptions. For example, a PDB can ensure that a certain number or percentage of replicas are always available during a node drain for maintenance.

85. How do you drain a node for maintenance?

To safely drain a node for maintenance, you use the kubectl drain command:

kubectl drain [node-name] --ignore-daemonsets

This command cordons the node (marks it as unschedulable) and then evicts all the Pods from it, respecting any Pod Disruption Budgets. The --ignore-daemonsets flag is needed because DaemonSet Pods are not evicted.

86. What is the difference between taints and labels?

• Labels are key-value pairs attached to objects, such as Pods and Nodes, used for selection and organization. They are used with selectors for affinity rules.
• Taints are applied to nodes to repel Pods. They are used with tolerations to restrict which Pods can be scheduled on a node.

87. How do you troubleshoot a Pod that is stuck in a `Pending` state?

A Pod in a `Pending` state means it cannot be scheduled onto a node. To troubleshoot:

1. Use kubectl describe pod [pod-name] to view the events section, which often gives the reason (e.g., insufficient CPU/memory, taints not tolerated, affinity rules not met).
2. Check for resource quotas or limit ranges that might be preventing scheduling.
3. Ensure the cluster has enough resources available.

88. How do you troubleshoot a Pod that is in a `CrashLoopBackOff` state?

A `CrashLoopBackOff` status means the container is starting, crashing, and being restarted repeatedly. To troubleshoot:

1. Check the logs of the crashing container: kubectl logs [pod-name].
2. If the container crashes too quickly, check the logs of the previous instance: kubectl logs [pod-name] --previous.
3. Use kubectl describe pod [pod-name] to check for issues like incorrect command, configuration errors, or failed probes.
4. If needed, get a shell into a running instance (if possible) or a similar container to debug interactively.

89. What are some common `kubectl` commands for debugging?

• kubectl get pods -o wide: See which nodes Pods are on.
• kubectl describe [pod|service|deployment] [name]: Get detailed information and events.
• kubectl logs [pod-name]: View container logs.
• kubectl exec -it [pod-name] -- /bin/sh: Get a shell into a container.
• kubectl port-forward [pod-name] [local-port]:[pod-port]: Access a Pod's port locally.

90. How would you monitor a Kubernetes cluster?

The most common monitoring stack for Kubernetes is Prometheus for metrics collection and Grafana for visualization and dashboards. This setup allows you to monitor:

• Cluster health (node status, resource usage)
• Control plane components
• Application metrics (if exposed in a Prometheus-compatible format)

Other tools include Datadog, New Relic, and the built-in Kubernetes Dashboard.

91. What are Kubernetes events and how do you view them?

Kubernetes events are objects that provide insight into what is happening inside a cluster, such as decisions made by the scheduler or reasons why some Pods were evicted from a node. You can view them with:

kubectl get events

Events are also included at the bottom of the output of kubectl describe.

92. What is the purpose of `kubectl top`?

The kubectl top command allows you to view resource (CPU/Memory) consumption for nodes and pods. It requires the Metrics Server to be installed in the cluster.

• kubectl top node: Shows resource usage for all nodes.
• kubectl top pod: Shows resource usage for all pods in the current namespace.

93. How do you debug DNS issues in Kubernetes?

1. Use nslookup or dig from within a debug Pod to test DNS resolution for services.
2. Check the CoreDNS logs: kubectl logs -n kube-system [coredns-pod-name].
3. Verify the /etc/resolv.conf file inside your application Pod to ensure it's pointing to the cluster DNS service.
4. Ensure the service and its endpoints are correctly configured.

94. What are some common reasons for a service not being accessible?

• The service selector does not match any Pod labels.
• The Pods are not running or are in a failing state.
• A NetworkPolicy is blocking traffic.
• The service's `targetPort` does not match the container's `containerPort`.
• DNS resolution is failing.

95. What is the difference between `kubectl apply` and `kubectl create`?

• kubectl create: A command to create a new resource from a file or stdin. It will fail if the resource already exists. This is an imperative command.
• kubectl apply: A command that creates or updates a resource from a file or stdin. If the resource exists, `apply` will calculate the differences and apply the changes. This is a declarative approach and is the recommended way to manage Kubernetes objects.

96. What is Helm and why is it used?

Helm is a package manager for Kubernetes. It helps you manage Kubernetes applications through Helm Charts, which are packages of pre-configured Kubernetes resources. Helm simplifies the process of deploying, upgrading, and managing complex applications on Kubernetes.

97. What is a Helm Chart?

A Helm Chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.

98. What is a service mesh (e.g., Istio, Linkerd) and what problems does it solve?

A service mesh is a dedicated infrastructure layer for making service-to-service communication safe, fast, and reliable. It provides features like:

• Traffic management (load balancing, routing, retries)
• Security (mutual TLS, authentication, authorization)
• Observability (metrics, tracing, logging)

It works by deploying a lightweight proxy (often Envoy) as a "sidecar" container in each Pod.

99. What is the difference between Docker Swarm and Kubernetes?

• Simplicity: Docker Swarm is generally considered easier to set up and manage.
• Scalability & Features: Kubernetes is more complex but also more powerful and flexible, with a larger feature set for managing large-scale production workloads.
• Community & Ecosystem: Kubernetes has a much larger community and a more extensive ecosystem of tools and integrations.

100. What is GitOps and how does it relate to Kubernetes?

GitOps is a way of implementing Continuous Deployment for cloud-native applications. It uses Git as a single source of truth for declarative infrastructure and applications. An automated process ensures that the production environment matches the state described in the repository.

Tools like Argo CD and Flux are popular GitOps operators for Kubernetes. They run in the cluster, watch a Git repository, and automatically apply any changes to the cluster, ensuring the cluster state matches the Git state.