A pod is a Kubernetes API object representing a running instance of an application. It groups one or more closely related containers so Kubernetes can place and manage them as one unit. A pod often contains just one container; unlike a container, a pod is a resource you can list with kubectl. section 5.0 section 5.1 section 3.3.1
All containers in a pod run on the same worker node. They share a network namespace, including an IP address and port space, so they can communicate closely but cannot bind to the same port. Think of a pod as a small logical computer for one application, not as a place to collect unrelated services. section 5.1 section 5.1.1 section 5.1.2
Put containers together only when they need to run together:
- An application and an Envoy sidecar can share a pod: the proxy accepts HTTPS traffic and forwards it to the application on localhost. section 5.4.2
- A frontend and a database usually belong in separate pods. Kubernetes can then place them on different nodes and scale them independently. section 5.1.2
- Containers that need to exchange files can mount the same pod volume, even at different paths in their own filesystems. section 9.2.3
A pod manifest declares the desired container configuration in its spec. The basic v1 manifest names the Pod and specifies a container image and port; it does not need a status section. Apply it with kubectl apply -f pod.kiada.yaml. Reading the object back with kubectl get po kiada -o yaml reveals fields added after creation, including status. Some pod fields cannot be changed by reapplying a manifest; deleting and recreating the pod is an option. section 5.2.1 section 5.2.2
Listing 5.1 A basic pod manifest file
apiVersion: v1 #1
kind: Pod #2
metadata:
name: kiada #3
spec:
containers:
- name: kiada #4
image: luksa/kiada:0.1 #5
ports:
- containerPort: 8080 #6
A minimal Pod manifest shows apiVersion: v1, kind: Pod, metadata.name, and one container under spec.containers. section 5.2.1
Check what happened with kubectl get pod kiada and kubectl describe pod kiada. READY and STATUS give a quick view; events show steps such as node assignment, image pull, container creation, and startup. The Pod object's status also records its phase, conditions, IP addresses, and individual container states. section 5.2.3 section 6.1
For repeated application instances, a Deployment specifies the desired replica count and creates Pod objects to represent those replicas. Scaling a Deployment to three replicas produces three pods, not three containers in one pod. A Service can provide one communication entry point to those replicas. A standalone pod is different: deleting its Pod object says the pod and its containers should no longer exist; it cannot simply be stopped and started again. section 3.3.4 section 3.3.3 section 5.6.1
Inspect a two-container pod
Create an application-and-Envoy pod with kubectl apply -f pod.kiada-ssl.yaml. After checking it with kubectl get and kubectl describe, forward its ports using kubectl port-forward kiada-ssl 8080 8443 9901. For logs, select a container explicitly—for example, kubectl logs kiada-ssl -c envoy—or use --all-containers. section 5.4.2 section 5.4.3
