Here are some Kubernetes real-time scenarios based interview questions:

1# How would you scale a deployment in Kubernetes?

To scale a deployment in Kubernetes, you can use the kubectl scale command and specify

the desired number of replicas for the deployment. For example, to scale a deployment

named “my-deployment” to 5 replicas, you can use the command: “kubectl scale deployment

my-deployment — replicas=5”.

2# How would you troubleshoot a pod that is not starting in Kubernetes?

To troubleshoot a pod that is not starting in Kubernetes, you can use the kubectl describe

pod command to get more information about the pod’s status and events. You can also

check the pod’s logs using the kubectl logs command. Additionally, you can use the kubectl

exec command to enter the container’s shell and investigate further.

3# How would you deploy a new version of an application in Kubernetes?

To deploy a new version of an application in Kubernetes, you can update the deployment’s

image tag to the new version and use the kubectl apply command to apply the changes.

Kubernetes will then automatically create new pods with the updated image and gradually

replace the old pods with the new ones.

4# How would you implement a rolling update strategy in Kubernetes?

To implement a rolling update strategy in Kubernetes, you can update the deployment’s

image tag to the new version and use the kubectl apply command with the — record flag to

create a new revision. Then, you can use the kubectl rollout command to perform the rolling

update, specifying the max unavailable and max surge parameters to control the number of

pods that can be unavailable and the number of new pods that can be created at a time.
5# How would you secure a Kubernetes cluster?

To secure a Kubernetes cluster, you can implement various security measures such as using

role-based access control (RBAC) to restrict access to the cluster resources, enabling

network policies to control traffic flow, encrypting sensitive data using secrets, and using

container security measures such as image scanning and runtime security.

6# How would you scale a stateful application in Kubernetes?

To scale a stateful application in Kubernetes, you need to take into account the stateful

nature of the application and the data it stores. You can use statefulsets to manage stateful

applications and specify the desired number of replicas. However, you also need to ensure

that the data is replicated and distributed properly across the replicas using persistent

volumes and storage classes.

7# How would you perform a backup and restore of a Kubernetes cluster?

To perform a backup and restore of a Kubernetes cluster, you can use various tools and

strategies such as Velero (formerly Heptio Ark), kubeadm-dumper, etcdctl, and other

backup and recovery solutions. You need to ensure that you have a consistent backup of the

cluster state, including the etcd database, and that you have tested the restore process in a

separate environmen

1. What is the difference between config map and secret? (Differentiate the answers as with
examples)
Config maps ideally stores application configuration in a plain text format whereas Secrets store
sensitive data like password in an encrypted format. Both config maps and secrets can be used as
volume and mounted inside a pod through a pod definition file.

Config map:
kubectl create configmap myconfigmap
--from-literal=env=dev
Secret:
echo -n ‘admin’ > ./username.txt
echo -n ‘abcd1234’ ./password.txt
kubectl create secret generic mysecret --from-file=./username.txt --from-
file=./password.txt
2. If a node is tainted, is there a way to still schedule the pods to that node?
When a node is tainted, the pods don’t get scheduled by default, however, if we have to still
schedule a pod to a tainted node we can start applying tolerations to the pod spec.

Apply a taint to a node:

kubectl taint nodes node1 key=value:NoSchedul
Apply toleration to a pod:
spec:
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoSchedule"
3. Can we use many claims out of a persistent volume? Explain?
The mapping between persistent volume and persistent volume claim is always one-to-one. Even
When you delete the claim, PersistentVolume still remains as we set persistentVolumeReclaimPolicy
is set to Retain and Any other claims will not reuse it. Below is the spec to create the Persistent
Volume.

apiVersion: v1
kind: PersistentVolume
metadata:
name: mypv
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
4. What kind of object do you create, when your dashboard like application, queries the
Kubernetes API to get some data?
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
5. What is the difference between a Pod and a Job? Differentiate the answers as with
examples)
A Pod always ensure that a container is running whereas the Job ensures that the pods run to its
completion. Job is to do a finite task.

Examples:
$ kubectl run mypod1 --image=nginx --restart=Never
$ kubectl run mypod2 --image=nginx --restart=onFailure
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mypod1 1/1 Running 0 59s
$ kubectl get job
NAME DESIRED SUCCESSFUL AGE
mypod1 1 0 19s
6. How does Kubernetes handle service discovery and load balancing?
Kubernetes uses two primary components for service discovery and load balancing:

 Services: Kubernetes services provide a stable network endpoint to access a group

of pods. Services act as an abstraction layer, allowing clients to connect to the service
without needing to know the individual pod’s IP addresses. Kubernetes assigns a
virtual IP address and a DNS name to the service, which load balances traffic to the
underlying pods.
 kube-proxy: kube-proxy is a network proxy that runs on each node in the Kubernetes
cluster. It manages the network routing and load balancing for services. It ensures that
traffic sent to a service’s virtual IP address is distributed to the corresponding pods.
7. Explain the difference between a deployment and a statefulset in Kubernetes.
A deployment and a statefulset are two different controllers in Kubernetes with distinct use cases:

 Deployment: A deployment manages stateless applications or microservices. It

provides declarative updates, scaling, and rollback capabilities. Deployments are
suitable for applications that don’t require stable, unique network identities or stable
storage.
 StatefulSet: A statefulset manages stateful applications that require stable network
identities and stable storage. It ensures that each pod in the set has a stable
hostname, network identity, and persistent storage. StatefulSets are typically used for
databases, distributed systems, and applications that require ordered deployment and
scaling.
8. How does Kubernetes handle persistent storage for stateful applications?
Kubernetes provides persistent storage through Persistent Volumes (PVs) and Persistent Volume
Claims (PVCs):

 Persistent Volume (PV): A PV is a cluster-wide resource that represents a piece of

networked storage in the cluster, such as a physical disk or a network-attached
storage (NAS). Administrators provision and manage PVs.
 Persistent Volume Claim (PVC): A PVC is a request for a specific amount of storage
resources by a user or application. It binds to a suitable PV with matching capacity
and access modes. PVCs are used by developers to request and consume storage
resources in a more abstracted manner.

Dharti SutariyaDharti SutariyaWhy

won’t the service defined
in the manifest file below bind to the pod defined
in the same file?
Below is a manifest file that declares a Kubernetes deployment and a
Kubernetes service. What’s going wrong with it?

apiVersion: apps/v1

kind: Deployment

metadata:

name: my_deployment

spec:

selector:

matchLabels:

type: example

color: red

replicas: 3

strategy:

type: RollingUpdate

rollingUpdate:

maxSurge: 25%

maxUnavailable: 10%

template:

metadata:
 labels:

type: example

color: red

spec:

containers:

- name: echocolor

image: reselbob/echocolor:v0.1

ports:

- containerPort: 3000

env:

- name: COLOR_ECHO_COLOR

value: RED

- name: COLOR_ECHO_VERSION

value: V1

---

apiVersion: v1

kind: Service

metadata:

name: my_service
spec:

selector:

type: example

color: blue

ports:

protocol: TCP

port: 3000

targetPort: 3000

type: NodePort

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.

What is an init container and when would you use

one?

An init container is a container that Kubernetes runs before any other containers
in the pod are created. You can use an init container to implement initialization
behavior that other pods will use.
The example below shows how to create an init container that waits for a
database service to come online before it creates the container that will use the
database.

apiVersion: v1

kind: Pod

metadata:

name: myapp-pod

labels:

app: myapp

spec:

containers:

- name: myapp-container

image: busybox:1.31

command: ['sh', '-c', 'echo The app is running! && sleep

3600']

initContainers:

- name: init-myservice

image: busybox:1.31

command: ['sh', '-c', 'until nslookup redis-master; do

echo waiting for redis-master; sleep 2; done;']
What’s the difference between a Kubernetes
ConfigMap and a Kubernetes secret?

A ConfigMap is a Kubernetes API object used to store data that is not

confidential. ConfigMap information is stored in a variety of information formats,
such as key-value pairs and JSON. (The sample Kubernetes ConfigMap below
contains both name-value pairs and a JSON object.) Typically a developer uses
a ConfigMap to provide information to the cluster that gets consumed by other
API objects.

kind: ConfigMap

apiVersion: v1

metadata:

name: db-configmap

data:

# Configuration data as key-value properties

database: mongodb

database_uri: mongodb://localhost:27017

# Other data in JSON

keys: |

maximum.connections=5

timeout=10000
A Kubernetes secret is a Kubernetes object that stores information in the cluster
in an encrypted format. Typically a secret is used to store confidential
information. The example below is a manifest file that describes a Kubernetes
secret for a username/password pair. Notice the Base64 encrypted values.

apiVersion: v1

kind: Secret

metadata:

name: mysecret

type: Opaque

data:

# An encrypted username/password pair

username: YWRtaW4=

password: MWYyZDFlMmU2N2Rm

What is a Kubernetes operator?

A Kubernetes operator is a design pattern to package, deploy, and manage a

Kubernetes application. Think of an operator as a way to create and deploy all
the Kubernetes resources that go with an application at once using automation.

For example, an operator creates a Kubernetes service, the backing pods, the
storage volumes as well as the Roles, and RoleBindngs, and all the
configurations that are part of an application that runs on a Kubernetes cluster.
There are Kubernetes operators for MySQL, Oracle and Redis to name a few

How do you implement service discovery

internally in a Kubernetes cluster?

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:

<service>.<namepace>

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.

What is the purpose of kubelet?

The purpose of kubelet is to realize containers on a given Kubernetes node.

Every node in a Kubernetes cluster has a running instance of kubelet.

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

What is RBAC and how does it relate to

Kubernetes?

Role-based access control (RBAC) is the technique by which one creates

Kubernetes Roles and RoleBindings. A Kubernetes Role is an abstraction that
defines a relationship between a Kubernetes resource and action — for example,
“can create a pod” where pod is the Kubernetes resource and create is the
action. A RoleBinding maps a particular user or service to a particular Role.
What is the difference between a StatefulSet and
a DaemonSet?

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.

What is a sidecar and when is it best to use one?

In a sidecar pattern, one container is created in a pod to provide service to

another container in that pod. The sidecar container runs on the same machine
under the same IP address as all the other containers that run in the pod. Thus,
it’s very efficient to move traffic between the main container and the sidecar
container. The sidecar provides extended features to the main container, yet it is
independent so it allows updates without stopping the main container.

When you need to provide additional features or services to a container in a

versatile, low-latency manner, the sidecar pattern is a good way to go.
How can you make it so that a pod runs on a
specific node?

Use node affinity. Node affinity is a Kubernetes deployment technique in which a

node is assigned an arbitrary label, and then pods are configured to be assigned
to that node according to the label created.

For example, this following code snippet creates an arbitrary

label, nodelocation, and assigns the value usa to the node named worker-01:

kubectl label nodes worker-01 nodelocation=usa

The manifest file shown below describes a Kubernetes deployment in which all
the pods created for the deployment are assigned to any node that has a label
with key-value pair nodelocation=usa.

apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx-deployment

labels:

app: nginx

spec:

replicas: 5

selector:
 matchLabels:

app: nginx

template:

metadata:

labels:

app: nginx

spec:

# bind the pods in the deployment to nodes that have

the key-value

# pair, nodelocation=usa

affinity:

nodeAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

- matchExpressions:

- key: nodelocation

operator: In

values:

- usa
 containers:

- name: nginx

image: nginx:1.14.2

ports:

- containerPort: 80

-ADS BY GOOGLE