Now we know broadly what Kubernetes is and a little bit about its most important partner, Docker, but what does Kubernetes look like once you jump into it?

Below we’ll break down the basic components present in any Kubernetes app and show how they build on each other. We’ll also look at some of the additional tools sure to help you along the way.

Pods

These are the smallest unit of application in Kubernetes. Pods represent a single, isolated instance of an application and the resources needed to execute it, each having their own IP address.

Pods are made up of one or more containers that work together and share a life cycle on the same node; each pod could be composed of a single container or multiple containers, depending on its complexity.

This can be advantageous as all containers within the same pod can communicate without the need for additional setup from the user.

These pods, however, are highly isolated and cannot communicate with other pods. This is where our next component, services, comes into the picture.

Services

Services are an abstraction that sit one level above pods, acting as a director between individual pods and the outside world.

Services define a policy to access selected pods. Once this is done, pods in this service’s set can communicate freely until the policy to access is changed.

Services are also convenient when creating complex, interdependent programs as they set a single Domain Name Service (DNS) record for all pods within their service. Another part of the program, a deployment (see below), can then use this DNS name to access information from these pods without needing to know the IP addresses for each.

In other words, another part of the program can connect to this pod group through the shared DNS record without needing to track status or information of each pod.

Group based access allows for greater flexibility than individual access as pods can be added or removed from the service group without code revision.