Common Kubernetes Questions

Q: Should a pod contain multiple containers?

Ans: Containers are designed to run only a single process per container. This way, the logs also remain separate. However, in certain cases, we may also want containers to share certain resources. Kubernetes achieves this by configuring Docker to have all containers of a pod share the same set of Linux namespaces instead of each container having its own set.

Q: Should a mult-tier application consisting of an application server and database be configured as a single pod or multiple pods?

Ans: As these systems run on separate machines, they should be running on separate pods which have their own networking and storage resources. If either system needs to be scaled up, those pods can have their replication sets scaled up independently. Each of these pods can also be tuned to have consume different computing resources such as CPU and memory. It also allows Kubernetes to schedule the pods to different nodes, improving the utilisation of the infrastructure.

Q: What is your opinion about running databases on Kubernetes?

Ans: Databases on Kubernetes makes little sense. Kubernetes is built for stateless applications that broadly follow the 12 factor principle for such applications. Databases on the other hand are persistent and the most important consideration for their performance at many times come down to how fast their hard disk speed is. Hence, because databases are stateful and require very good access to the underlying storage, I would run a database on its own or on a VM. We can’t much of the benefits of Kubernetes for database, which a VM technology already provides.

Q: What is the motivation behind moving to Kubernetes?

Ans: It provides manageability and orchestration for applications running in containers, regardless of whether you are running these applications in the cloud or on-premise. It is vendor agnostic, with cloud providers providing managed Kubernetes services.

Q: Why and how do you do a canary release in Kubernetes?

Ans: When a new version of an application is to be released into production, a canary release is done which allows a pod in a multi-pod running cluster to be deployed for testing to a small group of users to ensure that the release is fine, before replacing all the other pods with this new release. This is done by pause ing a Kubernetes deployment so that the canary release can be tested and then resume ing the deployment to replace the old versions in the other pods.

Q: How do you ensure that certain kinds of pods are exclusively deployed on certain kind of nodes so that other pods do not get deployed on these marked nodes?

Ans: We use a combination of Affinity, Taints and Tollerations. Taints ensure that only those pods marked with the same tollerations are allowed to be deployed on these nodes. To further ensure that those tolerant pods don’t get deployed on other types of nodes, we also use affinity rules.

Q: Why do we need a stateful set?

Ans: It allows pods to come up one after another sequentially, which is required in a database replication scenario, where the master DB needs to come up first before the slave DBs come up and replicate from the master. It also provides ordinal names for each of pods to denote a sequence and for the slaves to address the master.

Q: Why do we use containers to distribute Java applications?

Ans: It is required to ensure we have a consistent and predictable run time java platform with the necessary dependencies (e.g. JDBC libraries) for our Java application. The real benefit of containers occurs when you need to add enterprise capabilities to your application, by using Kubernetes as a platform. Kubernetes provides a great foundation for other projects such as Istio, Kibana, etc, that support your containerised application. For more details, see https://developers.redhat.com/blog/2018/06/28/why-kubernetes-is-the-new-application-server/