Once you have a Kubernetes cluster up and running, there are three key abstractions to understand: pods, services and replication controllers.
Pods. Pods — as in a pod of whales (whale metaphors are very popular in this space) — is a group of containers scheduled on the same host. They are tightly coupled because they are all part of the same application and would have run on the same host in the old days. Each container in a pod shares the same network, IPC and PID namespaces. Of course, since Docker doesn’t support shared PID namespaces (every Docker process is PID 1 of its own hierarchy and there’s no way to merge two running containers), a pod right now is really just a group of Docker containers running on the same host with shared Kubernetes volumes (as distinct from Docker volumes).
Pods are a low level primitive. Users do not normally create them directly; instead, replication controller are responsible for creating pods (see below).
You can view pods like this:
kubectl.sh get pods
Read more about pods in the Kubernetes documentation: Kubernetes Pods
Replication Controllers. Pods, like the containers within them, are ephemeral. They do not survive node failure or reboots. Instead, replication controllers are used to keep a certain number of pod replicas running at all times, taking care to start new pod replicas when more or needed. Thus, replication controllers are longer lived than pods and can be thought of like a manager abstraction sitting atop of the pod concept.
You can view replication controllers like this:
kubectl.sh get replicationControllers
Read more about replication controllers in the Kubernetes documentation: Replication Controllers in Kubernetes.
Services. Services are an abstraction that groups together multiple pods to provide a service. (The term “service” here is used in the microservices architecture sense.) The example in the Kubernetes documentation is that of an image-processing backend, which may consist of several pod replicas. These replicas, grouped together, represent the image processing microservice within your larger application.
A service is longer lived than a replication controller, and a service may create or destroy many replication controllers during its life. Just as replication controllers are a management abstraction sitting atop the pods abstraction, services can be thought of as a control abstraction that sits atop multiple replication controllers.
You can view services like this:
kubectl.sh get services
Read more about services in the Kubernetes documentation: Kubernetes Services.
Source / Further Reading: Design of Kubernetes