Jump right into Kubernetes development with career-focused lessons and hands-on practice.

DevOps for Developers

Kubernetes is a powerful container management tool that's taking the world by storm. This detailed course will help you master it.

In this course, you'll start with the fundamentals of Kubernetes and what the main components of a cluster look like. You'll then learn how to use those components to build, test, deploy, and upgrade applications, as well as how to achieve state persistence once your application is deployed. You'll also learn how to secure your deployments and manage resources, which are crucial DevOps skills.

By the time you're done, you'll have a firm grasp on what Kubernetes is, as well as the skills to deploy your own clusters and applications with confidence.

A Practical Guide to Kubernetes

# The problem


Pods are the smallest unit in Kubernetes and have a relatively short life span. They are born, and destroyed. They are never healed. The system heals itself by creating new Pods (cells) and by terminating those that are unhealthy or those that are surplus. The system can last long while Pods cannot.

Controllers, together with other components like the scheduler, ensure that the Pods are doing the right thing. They control the scheduler. We have used only one of them so far. 

ReplicaSet are supposed to ensure that the desired number of Pods are always running. If there are too few Pods, ReplicaSet will create new ones. If there are too many of them, some will be destroyed. Pods that become unhealthy are terminated as well. All that, and a bit more, is controlled by ReplicaSet.

The problem with our current setup is that there are no communication paths. Our Pods cannot communicate with each other. So far, only containers inside a Pod can talk with each other through `localhost`. This necessitates both the API and the database needed to be inside the same Pod. This was a less than appropriate solution for quite a few reasons. 

The main problem is that we cannot scale one without the other. We can not design the setup in a way that there are, for example, three replicas of the API and one replica of the database. The primary obstacle, again, is communication.

Truth be told, each Pod does get its own address. We could also split the API and the database into different Pods and configure the API Pods to communicate with the database through the address of the Pod it lives in.

 However, because Pods are unreliable, short-lived, and volatile, we cannot assume that the database would always be accessible through the IP of a Pod. When that Pod gets destroyed (or fails), the ReplicaSet would create a new one and assign it a new address. 

We need a stable, never-to-be-changed address that will forward requests to whichever Pod is currently running.

# The solution

Kubernetes Services provide addresses through which associated Pods can be accessed.




Find out why establishing communication between Pods is necessary. 

Getting Started with Communication

Find out why establishing communication between Pods is necessary.