Chapter 5: Running applications with pods

Introduction

The chapter introduces the Pod as the central Kubernetes object representing a running instance of an application.

• Pod as application instance: Explain what a Pod object represents and why this chapter starts with it.
  Why it matters: This gives you a starting point for understanding how Kubernetes runs applications.

Key terms: Pod object, running instance

5.1 Understanding pods

This section explains that Kubernetes deploys and manages containers as pods, whose containers always run together on one worker node.

• Pods as co-located units: Explain that Kubernetes deploys and manages a pod as one unit rather than deploying its containers individually. Describe how a pod can contain one or several containers, but all containers in a pod run on the same worker node.
  Why it matters: This establishes what you deploy and manage when running containers on Kubernetes.

Key terms: pod, containers, worker node

5.1.1 Understanding the purpose of pods

This section explains why related processes are usually placed in separate containers within one pod and how shared namespaces let those containers work together.

• Single process container design: Explain why running an application's processes in separate containers is usually easier to manage than running them all in one container.
  Why it matters: This explains why putting every related process into one container loses useful container-management behavior.
• Pod as shared unit: Explain why a pod groups closely related processes that run in separate containers.
  Why it matters: The pod provides the grouping that related processes need without requiring them to share one container.
• Shared pod network namespace: Describe the network environment shared by containers in one pod and its consequence for port numbers.
  Why it matters: Shared networking lets cooperating containers use one pod network environment but requires them to avoid port conflicts within the pod.
• Other shared and separate namespaces: Distinguish which other environments pod containers share, which sharing is optional, and how they can share files.
  Why it matters: Not every part of a container's environment is shared simply because it belongs to a pod.

Key terms: root process, standard output, container runtime, pod, containers, shared resources, Network namespace, network interfaces, IP address, port space

5.1.2 Organizing containers into pods

This section explains when to put containers in separate pods and when closely related processes belong together as a primary container and sidecars.

• Separate placement of components: Explain why a frontend and database should usually run in separate pods, even though Kubernetes permits them to share one.
  Why it matters: Separating independent components gives Kubernetes more freedom to use the cluster’s available machines.
• Independent scaling of components: Explain why components with different scaling needs must be placed in separate pods.
  Why it matters: Pod boundaries determine which components you can replicate independently.
• Complementary sidecar containers: Describe when a sidecar belongs beside a primary container and how the section’s examples extend the primary application.
  Why it matters: A sidecar can add a closely coupled capability without modifying the primary application, but it is not a free extra process.
• Pod grouping decision rule: Apply the section’s rule of thumb to decide whether containers should share a pod or run in separate pods.
  Why it matters: The decision rule prevents convenience alone from becoming a reason to couple independent components.

Key terms: pod, co-located, cluster node, hardware utilization, horizontal scaling, replicas, frontend, backend, primary container, sidecar container

5.2 Creating pods from YAML or JSON files

This section introduces creating pods from YAML or JSON manifests and explains why keeping application definitions in files is useful.

• Pod creation with manifests: Distinguish creating pods with the imperative kubectl create command from the usual approach of defining an object in a YAML or JSON manifest and posting it to the Kubernetes API. Explain why someone might choose YAML.
  Why it matters: This is the file-based approach used to create the pods in the following exercises.
• Benefits of file-based definitions: Explain how storing application definitions in YAML files supports repeatable deployment and a history of changes.
  Why it matters: File-based definitions make deployments repeatable while letting you track changes as you do with code.

Key terms: kubectl create, JSON or YAML manifest file, Kubernetes API, YAML files, repeatable, VCS (Version Control System)

5.2.1 Creating a YAML manifest for a pod

This section walks through a minimal YAML manifest for a Kiada pod, explains why it is shorter than a retrieved Pod object, and shows how to generate a starting manifest or look up fields.

• Kiada pod manifest contents: Describe the object and container specified by the example manifest: API version v1, a Pod named kiada, and one container named kiada using the luksa/kiada:0.1 image with application port 8080.
  Why it matters: These details let you read what the example Pod manifest requests before creating it.
• Minimal versus retrieved manifests: Explain why the handwritten Pod manifest is short even though the Pod object read back after creation will contain more fields.
  Why it matters: You need not copy every field of a retrieved object into a manifest to create a Pod.
• Manifest creation aids: Describe how the suggested kubectl command provides an editable Pod YAML starting point without creating the object, and how to look up available Pod fields.
  Why it matters: These commands provide a starting file and field guidance when writing a Pod manifest.

Key terms: Pod, manifest, v1, kiada, luksa/kiada:0.1, metadata, status, API, kubectl run, --dry-run=client

5.2.2 Creating the Pod object from the YAML file

This subsection shows how to create a Pod from its YAML manifest, reapply the file to make changes, and retrieve the full Pod object from the API.

• Applying a Pod manifest: Explain that kubectl apply posts a manifest to the Kubernetes API to create a Pod, and that editing and reapplying the file can update an existing Pod. State that an update may fail if it changes an immutable field, in which case the Pod can be deleted and recreated.
  Why it matters: This is how the manifest file becomes a Pod in the cluster and how you can apply later changes.
• Retrieving the full Pod manifest: Describe reading the created Pod object back from the Kubernetes API and how its full manifest differs from the original file.
  Why it matters: Reading the object back lets you see the Pod as it exists in the cluster, not just the fields you submitted.

Key terms: manifest, Kubernetes API, kubectl apply, mutable, full object manifest, metadata, status, spec, kubectl explain

5.2.3 Checking the newly created pod

This section shows how to check a newly created pod with kubectl and use its events to see what happened during startup.

• Pod status and details: Explain how to check a newly created pod with kubectl and where to look when a brief status summary is not enough.
  Why it matters: A quick status check tells you whether the pod is running, while a detailed view helps you inspect it further.
• Pod startup events: Describe where pod events appear, what their order shows about startup, and what the absence of warnings suggests.
  Why it matters: Events reveal the startup steps behind the pod’s current status and may flag problems.

Key terms: kubectl get, kubectl get pod -o wide, kubectl describe, kubectl get -o yaml, events, warning events, worker nodes, container image

5.3 Interacting with the application and the pod

Introduces the upcoming checks and interactions with a running application and its container.

5.3.1 Sending requests to the application in the pod

This section shows how to find a pod’s address and application port, then test or access the application directly from a node, another pod, a local port-forward, or the API server.

• Pod address and port discovery: Describe how to find a pod’s IP address and the port its application uses. Explain why listing container ports in the pod definition is useful even though it does not control connectivity.
  Why it matters: The IP and actual listening port are what you need for direct connectivity tests.
• Worker node connectivity test: Explain how and why to test an application by running curl from a worker node, especially the node hosting the pod.
  Why it matters: A short communication route helps distinguish a pod problem from trouble elsewhere in the path.
• One-off client pod test: Describe using a temporary pod to run curl against the target pod and explain what this tests.
  Why it matters: It tests the pod-to-pod route your application’s peers may actually use.
• Local pod port forwarding: Explain how kubectl port-forward lets a local client contact a specific pod, and trace the communication path and its limitation.
  Why it matters: A failed port-forward does not by itself prove that the pod is unreachable through ordinary network routes.
• API server HTTP proxy: Describe how kubectl get --raw can request an HTTP application in a pod and when this method is used.
  Why it matters: It offers a quick HTTP check for a developer or administrator without setting up port forwarding.

Key terms: podIP, kubectl get, wide output, container ports, worker node, curl, pod IP, one-off pod, client-pod, pod-to-pod connectivity

5.3.2 Viewing application logs

This section explains how to view a pod container’s logs with kubectl, narrow or stream the output, and understand when those logs remain available.

• Container logging streams: Explain why containerized applications usually write logs to stdout and stderr rather than application-specific files.
  Why it matters: This explains why Kubernetes can offer a standard way to retrieve application logs.
• Kubectl log inspection options: Describe how to retrieve and follow a pod container’s log with kubectl, and how to display timestamps or limit the output by time or line count.
  Why it matters: These options let you inspect just the log output relevant to a request or troubleshooting period.
• Container log availability: Explain how container restarts, log rotation, and pod deletion affect logs viewed through kubectl, including when to use --previous or centralized logging.
  Why it matters: Knowing these limits prevents you from mistaking missing old output for a lack of earlier activity.

Key terms: standard output (stdout), standard error streams (stderr), container runtime, kubectl logs, --follow, -f, --timestamps, --since-time, RFC3339, --previous

5.3.3 Attaching to a running container

This section shows how kubectl attach streams a container’s output and, when input is enabled, lets a user send text to the running application.

• Attached container output: Explain how kubectl attach displays a running application’s standard output and error, and how that compares with kubectl logs -f when the application does not read standard input.
  Why it matters: It helps distinguish merely watching an application’s output from interacting with it.
• Interactive standard input: Describe what must be configured in the pod and specified in kubectl attach to send text to a running application, and what the Kiada example does with that text.
  Why it matters: Both the container configuration and the attach option are needed for this form of interaction.
• Input across attach sessions: Explain how the stdinOnce setting affects whether standard input remains available after an attach session ends.
  Why it matters: It explains why a later attach session may or may not accept input.

Key terms: kubectl attach, kubectl logs -f, standard output, standard error, stdin, kubectl attach -i, EOF, status message, stdinOnce, standard input channel

5.3.4 Executing commands in running containers

This section explains how to use kubectl exec to inspect a running container with either a single command or an interactive shell.

• Single commands inside containers: Explain how kubectl exec helps debug a running container by running a binary available in its file system, without logging in to the node hosting the pod.
  Why it matters: It gives you a direct way to inspect a container when debugging an application.
• Interactive shell execution: Distinguish running one command with kubectl exec from starting an interactive shell, and explain what the -it options do.
  Why it matters: An interactive shell lets you explore the container with several commands in one session.

Key terms: kubectl exec, container, pod, -it, -i, -t, bash, standard input, terminal (TTY)

5.3.5 Copying files to and from containers

Explains how to copy files between a local computer and a running pod’s container, and when that is useful or limited.

• Copy direction and container selection: Describe how kubectl cp copies files or directories in either direction between a local computer and a pod’s container. Explain how path order determines the direction and when to use -c.
  Why it matters: Path order and container selection determine where the copied file ends up.
• Copying limits and uses: Explain why copying into a running container is mainly useful during development and what prerequisite limits kubectl cp, including when copying debugging binaries.
  Why it matters: This helps you recognize when copying a file is practical and why a copy might fail.

Key terms: kubectl cp, -c flag, default container, tar binary, debug

5.3.6 Debugging pods using ephemeral containers

This section shows how ephemeral containers provide debugging tools for an existing pod and explains when sharing a process namespace is needed to inspect other containers’ processes.

• Production image debugging limits: Explain why a production container may lack the shell or tools needed for debugging, and why adding tools to its image may be impractical when a problem appears sporadically.
  Why it matters: It explains why debugging the running pod can be better than rebuilding and redeploying its application image.
• Ephemeral container debugging workflow: Describe how to add an ephemeral debug container with a tool-containing image to an existing pod using kubectl debug, then use its tools to investigate the pod.
  Why it matters: It lets you investigate the pod that exhibits a problem even when its application image lacks the needed tools.
• Shared process namespace visibility: Explain why an ephemeral container cannot normally see processes in other containers, and describe the pod setting that changes this behavior.
  Why it matters: It explains why a debug container may be able to inspect network traffic yet not see the application container’s processes.

Key terms: container image, attack surface, production containers, ephemeral container, kubectl debug, nicolaka/netshoot, tcpdump, PID namespace, process namespace, shareProcessNamespace

5.4 Running multiple containers in a pod

This section introduces a sidecar reverse proxy as a way to add HTTPS to the HTTP-only Kiada application without changing its code.

• Sidecar proxy for HTTPS: Explain how a reverse proxy running alongside the Kiada application in a sidecar container can handle HTTPS requests on its behalf without changing app.js.
  Why it matters: This explains why the pod can serve HTTPS without adding TLS code to Kiada.

Key terms: Kiada application, HTTP, HTTPS, reverse proxy, sidecar container, Envoy

5.4.1 Extending the Kiada Node.js application using the Envoy proxy

This section describes how adding an Envoy container lets the Kiada pod handle HTTPS and explains the tradeoff against implementing TLS in the Node.js application.

• HTTPS request path through Envoy: Trace how the two-container pod handles requests: Node.js continues to handle HTTP directly, while Envoy handles incoming HTTPS and sends a new HTTP request to Node.js over localhost.
  Why it matters: This request path explains what each container contributes to the application.
• Proxy versus application TLS tradeoff: Explain why adding Envoy may be easier and more extensible, even though implementing TLS in Node.js itself would use fewer computing resources and have lower latency.
  Why it matters: The tradeoff explains why the example adds a proxy despite its overhead.

Key terms: Envoy container, Node.js container, HTTPS, HTTP, local loopback device, localhost IP address, TLS support, Envoy proxy, network hop, latency

5.4.2 Adding Envoy proxy to the pod

This section adds an Envoy proxy alongside the Kiada application by using a prepared image, defining a two-container pod, and checking that it starts.

• Prepared Envoy image: Explain why the example uses a prepared Envoy image rather than the official image directly.
  Why it matters: The image choice explains how this example can run Envoy without a separate file-provisioning step.
• Envoy request path: Trace how the configured Envoy proxy handles an HTTPS request in this pod.
  Why it matters: This request path explains what the second container does for the application.
• Two-container pod creation: Describe the new pod’s containers, the purpose of its port names, and how the section creates and checks the pod.
  Why it matters: The manifest and checks turn the proxy arrangement into a running pod with both containers.

Key terms: Envoy proxy container image, configuration, certificate, private key, Envoy, terminate TLS, localhost, administration interface, pod.kiada-ssl.yaml, kiada-ssl

5.4.3 Interacting with the two-container pod

This section shows how to access an application through its Envoy sidecar and how to target individual containers when viewing logs or running commands.

• HTTP and HTTPS access: Explain how port forwarding lets you access the application over HTTP and HTTPS, and what the HTTPS result demonstrates about the Envoy sidecar.
  Why it matters: The HTTPS request confirms what the added Envoy container contributes to the application.
• HTTPS certificate verification: Explain why the example uses curl’s --insecure option and how the section describes addressing the two certificate-verification problems without it.
  Why it matters: It distinguishes a hostname mismatch from the separate problem of trusting a self-signed certificate.
• Container-specific logs and commands: Describe how to select a container when viewing logs or running a command in the two-container pod, including the options for viewing both containers’ logs and the exec default.
  Why it matters: Selecting the container ensures you inspect or enter the intended part of the pod.

Key terms: kubectl port-forward, HTTP, HTTPS, Envoy proxy, sidecar container, --insecure, -k, self-signed, --resolve, --cacert

5.5 Running additional containers at pod startup

This section contrasts the parallel startup of a pod’s main containers with the option to run an initialization sequence before they start.

• Pod container startup order: Explain that containers in a multi-container pod normally start in parallel and cannot be ordered by declaring dependencies between them, but Kubernetes can run a sequence of containers to initialize the pod before its main containers start.
  Why it matters: It clarifies why ordinary container startup cannot guarantee that one container is ready before another starts.

Key terms: pod, main containers, initialize the pod

5.5.1 Introducing init containers

This section explains how init containers prepare a pod before its regular containers start, what they can do, and why separating initialization can help.

• Init container startup order: Explain when init containers run and what must happen before a pod’s regular containers start.
  Why it matters: This ordering lets a pod finish its preparation before the application begins running.
• Pod initialization tasks: Describe the kinds of preparation an init container can perform for a pod’s regular containers.
  Why it matters: These examples show what it means in practice to prepare a pod before its application runs.
• Separate initialization benefits: Justify doing initialization in an init container rather than in the main container when reusable or infrastructure-specific setup is needed.
  Why it matters: Keeping setup separate can make the same preparation usable across applications without changing their images.
• Initialization security boundary: Explain how moving a task that needs sensitive data into an init container can reduce exposure of the main container.
  Why it matters: Keeping a registration token out of the running application’s filesystem limits what an attacker exploiting that application can read.

Key terms: init containers, main containers, volumes, network namespaces, precondition, init container image, main container image, infrastructure-specific initialization code, attack surface, secret token

5.5.2 Adding init containers to a pod

This section shows how to define init containers in a pod manifest and how their execution appears during pod startup.

• Init container manifest definition: Describe where init containers are declared in a pod manifest, what each definition needs in this example, and how their names relate to regular container names.
  Why it matters: These distinctions let you add startup containers without confusing them with the pod’s regular containers.
• Network check startup purpose: Explain what the two example init containers do and why a connectivity check could be useful before an application starts.
  Why it matters: The connectivity check illustrates a practical reason to run work before the main application.
• Container startup and status sequence: Trace the order in which the example pod’s containers start and describe the status displayed during and after initialization.
  Why it matters: The observed sequence helps you interpret a pod that has not yet started its main application containers.

Key terms: initContainers, containers, spec, name, image, init container, network connectivity test, ping, command-line argument, init-demo

5.5.3 Inspecting init containers

This section explains how to inspect init containers through their logs and by running commands in them while they are active.

• Init container log inspection: Explain how to view an init container’s output with kubectl logs and when those logs are available.
  Why it matters: Logs remain available for checking what an init container did even after it finishes.
• Running commands in init containers: Describe when kubectl exec can run a command in an init container and what happens to an interactive shell when the container finishes.
  Why it matters: The short window for using exec makes it useful for investigating a slow init container, not for inspecting one that has already finished.

Key terms: init container, kubectl logs, -c option, standard and error output, kubectl exec, main process

5.5.4 Kubernetes native sidecar containers

This section explains how native sidecars start early, keep running, and shut down late, and when to use them instead of regular sidecar containers.

• Native sidecar startup order: Explain how to define a native sidecar and how its startup differs from an ordinary init container. Describe why its position in the initContainers list matters.
  Why it matters: Starting a sidecar before a dependent init container lets that init container use its service.
• Native sidecar lifetime: Describe how Kubernetes keeps a native sidecar available while the pod runs and orders its termination relative to normal containers.
  Why it matters: A network or logging sidecar must not disappear while other containers still depend on it.
• Sidecar mode choice: Distinguish when a sidecar should be native from when running it as a regular container is sufficient, including the case of a batch-processing pod.
  Why it matters: The right form depends on whether the pod relies on the sidecar’s availability and whether the pod needs to complete.

Key terms: native sidecar container, initContainers, restartPolicy, Always, init phase, native sidecar, restart policy, shutdown sequence, regular container, envoy

5.6 Deleting pods and other objects

This section introduces the effects of deleting pods, Deployments, and LoadBalancer-typed services before covering deletion commands.

• Effects of deleting objects: Explain what happens when a pod, a Deployment, or a LoadBalancer-typed service is deleted.
  Why it matters: Knowing these effects helps you anticipate what will be removed when cleaning up cluster objects.

Key terms: pod, containers, Deployment object, LoadBalancer-typed service, load balancer

5.6.1 Deleting a pod by name

This subsection explains how to delete pods by name, what happens during deletion, and why a deleted pod must be recreated rather than restarted.

• Deleting pods by name: Describe how to delete one pod by name or several pods in one command, and explain what the kubectl delete command waits for by default.
  Why it matters: You can remove the intended pods and decide whether to wait for deletion to finish.
• Pod deletion consequences: Explain what happens to a pod and its containers during deletion, and distinguish deleting a pod from stopping it temporarily.
  Why it matters: Deleting a pod is permanent removal, not a way to pause it for later use.

Key terms: kubectl delete, --wait=false, pod name, Kubelet, Terminating, Pod object

5.6.2 Deleting objects defined in manifest files

This section shows how to delete Kubernetes objects using the manifest files from which they were created, including multiple files or a directory of manifests.

• Manifest Based Object Deletion: Explain how to delete objects by passing their manifest file to kubectl delete, and why a file containing several objects can make removing an application straightforward.
  Why it matters: You can remove the objects defined for an application without naming each object separately.
• Multiple Manifest File Selection: Describe how to operate on multiple manifest files by supplying comma-separated filenames or a directory, and state when recursive selection is needed.
  Why it matters: Selecting several files or a directory avoids deleting objects one manifest at a time.

Key terms: manifest file, kubectl delete -f, kubectl apply -f, manifest files, directory, --recursive, -R

5.6.3 Deleting all pods

This section shows how to delete all pods and explains why pods managed by a Deployment reappear until the Deployment is scaled to zero or deleted.

• Deleting and checking all pods: Describe how the --all option deletes pods without naming them individually and how kubectl get pods is used afterward to check what remains.
  Why it matters: Checking after deletion reveals whether removing the pods had the intended effect.
• Deployment replacement of deleted pods: Explain why deleting Deployment-associated pods does not keep them gone, and state the two ways the section gives to stop replacements.
  Why it matters: It explains why repeatedly deleting the same workload's pods does not remove the workload.

Key terms: --all option, kubectl get pods, Deployment object, controller, desired number of replicas, replacement pod

5.6.4 Deleting objects using the “all” keyword

This section explains how to delete many Kubernetes objects at once, what the all keyword excludes, and how to confirm a deletion first.

• Broad deletion command syntax: Explain the different roles of all and --all in kubectl delete all --all, and describe what kubectl reports when it deletes objects.
  Why it matters: The two occurrences of “all” do different jobs, so distinguishing them helps you understand what the command will delete.
• Limits of all selection: Explain why deleting all does not delete every object kind, and describe how to include Events explicitly.
  Why it matters: A successful broad deletion does not mean every kind of object is gone.
• Interactive deletion confirmation: Describe how to check which objects a delete command will remove and confirm before deletion.
  Why it matters: Confirmation offers a chance to catch an unintended broad deletion.

Key terms: kubectl delete, all, --all, Event object kind, events,all, --interactive

5.7 Summary

The section recaps how pods group and scale containers, how init containers affect startup, and how kubectl helps developers work with pods.