Are you looking for somewhere to learn more about Kubernetes interview questions? You’re in the right place! We publish a Kubernetes question every day on our social media channels, LinkedIn, Telegram, and YouTube, and at the end of the week, we provide the correct answers with details here. If you want to test your Kubernetes knowledge or prepare yourself for Kubernetes role interviews, follow our social media.
What is the default cascade deletion strategy in Kubernetes?
Kubernetes deletes dependent resources in background mode by default, which means when you delete a resource, for example, Deployment, the controller deletes the Deployment resource, returns you the result and removes ReplicaSets and Pods in the background. In the foreground mode, it waits until all dependent resources get deleted, and in the orphan mode, it just removes the Deployment resource and leaves the dependents untouched, and you should remove them by yourself.
What will happen if a cluster with some removed API resources gets upgraded?
For example, a 1.24 cluster with PSP objects upgraded to 1.25, which has removed the deprecated PSP resource completely, and it’s not available anymore.
A) Upgrade will fail until PSP resources are removed
B) Upgrade will be successful, and PSP resources will be removed automatically
C) Upgrade will be successful, and PSP resources will still be accessible after that
D) Upgrade will be successful, and PSP resources will become orphan
Cluster upgrade means running a new version of kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy, etc., and in that case, you stop the old versions and start new versions. All the already created objects are still available in the etcd database, even if the new Kubernetes version does not support some of them. So, if you update the cluster, the upgrade will be successful, but the removed API resources become orphans in the etcd, and you should connect to etcd and remove them manually.
25 October 2023:
What is Kubernetes Finalizer?
A) Keys to tell Kubernetes to wait until resource got deployed completely
B) Keys to tell Kubernetes the resource has some dependencies before deployment
C) Keys to tell Kubernetes to wait until conditions are met before deleting resource
D) Keys to tell Kubernetes to wait for some actions before deploying resource
Finalizers are special keys to tell Kubernetes to wait until some conditions are met before deleting the resource. You can assign finalizers to the Kubernetes objects when you create them, or the controller or some Operators may add finalizers to the resources to achieve some things. For example, when you try to delete a PVC resource, the controller adds a finalizer to the PVC to stop its deletion process until none of the Pods use that PVC storage. When the condition is met, and no one uses the PVC, the controller removes the finalizer, and the resource can be deleted safely.
A) Service which returns actual Pods’ IP addresses
B) Service which returns multiple Service CIDR addresses
C) Service which has no DNS name
D) Service which has no Endpoints resource
Headless Service is a special Service type with a DNS name but no ClusterIP. When you try to resolve a Headless Service, you’ll get the actual Pods’ IP addresses instead of ClusterIP. Headless Services load balancing uses the DNS round-robin load balancing algorithm. In some scenarios, like clustering stateful applications, they can be used to identify the number of active members and their actual IP addresses.
How can you make sure your application is resilient to node disruptions?
A) By deploying more than one replica
B) By adding proper PriorityClass to the Pods
C) By creating PDB resource for Pods
D) All of the above choices
Having all the above choices would be best to make your application resilient to node failure and disruption. By deploying the application with multiple replicas, your application can be deployed into various worker nodes. By using PriorityClass, your application will be safe if the worker node goes under resource pressure, and by using PDB, you can enforce the application’s high availability during some maintenance works like node upgrades.
Kubernetes itself is wild. Man vs. Wild in interviews needs deep knowledge, hands-on experience and additional skills to pass. If you want to pass Kubernetes role interviews, read more and do many more with Kubernetes. Our goal in Kubedemy is to help you understand and solve Kubernetes difficulties in all situations.
If you like this series of articles, please share them and write your thoughts as comments here. Your feedback encourages me to complete this massively planned program.