A Pod is Kubernetes’ smallest deployable unit. Instead of deploying a container directly, define a Pod for the application and its runtime configuration. The Pod runs on a worker node; the scheduler chooses an available node according to its resource requirements. section 8.2.2 section 8.2.1
A Pod specification supplies what the workload needs to run:
- A container image and version, plus environment variables such as an application port or another service’s URL. section 8.2.2 section 8.2.4
- When needed, resource reservations, configuration from ConfigMaps or Secrets, and disk claims. section 8.2.2
apiVersion: v1
kind: Pod
metadata:
name: order
spec:
containers:
- name: order
image: huseyinbabal/order:1.0.0
env:
- name: APPLICATION_PORT
value: "8080"
- name: "PAYMENT_SERVICE_URL"
value: "payment:8081"
The Order Pod manifest names the container image and passes APPLICATION_PORT and PAYMENT_SERVICE_URL as environment variables. section 8.2.4
Create the Order Pod
Save the manifest as order.yaml and run `kubectl apply -f order.yaml`. kubectl sends it to the API server, its metadata is stored in etcd, the scheduler assigns a node, and that node’s kubelet pulls the image and runs the container. section 8.2.4
A single Pod is not the whole production deployment. Use a Deployment when the service needs multiple instances or managed image updates: its ReplicaSet creates Pods from a template. Use a Service to expose Pods as an endpoint; Service selectors can also route requests across old and new Pods during a canary rollout. section 8.2.5 section 8.4.3
