A containerized application runs in Kubernetes inside a pod, the cluster’s smallest execution unit. One pod represents one running instance of the application. A pod can also contain a utility container, such as a logger, that shares its network and storage and lives alongside the main container. section 3.3.3
Listing 3.4 pod.yaml: creating a pod
apiVersion: v1 #1
kind: Pod #2
metadata:
name: joker #3
spec:
containers:
- name: hello-joker #4
image: <docker_hub_repo>:hello-joker:v1 #5
ports:
- containerPort: 8083 #6
This Pod manifest places a containerized FastAPI application in a named pod. Its apiVersion and kind identify the Kubernetes object; metadata names it; spec names the container, image, and container port. Replace the image placeholder with an available image before applying it. section 3.3.3
For a first deployment, check the pod before putting more infrastructure around it:
- Run `kubectl create -f pod.yaml`, then `kubectl get pod` to check readiness and status. Use `kubectl apply -f pod.yaml` for subsequent configuration changes. section 3.3.3
- If startup fails, use `kubectl describe pod joker` for details such as an image-pull error and `kubectl logs joker` for application output. Use `kubectl port-forward` to reach the application locally, matching the forwarded container port to the port it actually listens on. section 3.3.3
A standalone pod is useful for learning and inspection, but it is not the whole scaling plan. A ReplicaSet uses a pod template and label selector to maintain a specified number of pods: when one is deleted, another appears. A Deployment manages a ReplicaSet and its pods, including changes to the application image. section 3.3.3
Pods in an ML service
A Yatai deployment can run an API Server pod to receive requests and Runner pods to hold models and perform inference. The two roles have independently configurable replica counts and pod resource requirements. After deployment, `kubectl get pod -n yatai` shows their running instances. section 6.1.3
Pod boundaries also matter inside an ML workflow. Each Kubeflow Pipelines component runs in a separate pod, so components need an explicit way to pass and share data rather than assuming they share one execution environment. section 7.2
