Chapter 6: Managing the pod life cycle and container health
This chapter introduction previews a deeper look at pod and container operation, including status, health, lifecycle hooks, and life cycles.
After this chapter you will be able to
- Pod status and life cycle. Explain that reading a Pod object back from the API reveals its status, and identify the pod’s phase, conditions, and individual container states as the status information relevant to its life cycle.
- Pod phase and location. Explain that a pod is in one of five phases at any moment and that its phase provides a quick summary of what is happening with it. Describe where to find the phase in the Pod object.
- Pod condition meaning and changes. Explain how pod conditions differ from the pod phase and describe how the named conditions can change over a pod’s lifetime.
- Inspecting pod condition details. Describe where to inspect pod conditions and what their status and diagnostic fields report.
- Individual container status fields. Explain how a pod’s container status distinguishes the current state from the previous terminated state and reports readiness, restarts, and container and image identifiers.
- Container restart and recreation. Explain what happens when a pod’s container terminates and what Kubernetes means by restarting it. Describe what happens to the pod’s other containers and to data written in the terminated container’s filesystem.
- Repeated restart back-off. Trace how the delay before a container restart changes after repeated terminations and explain what CrashLoopBackOff indicates in the container status.
- Liveness probe failure response. Describe how Kubernetes uses a liveness probe and what happens when the check fails.
- Three liveness probe mechanisms. Distinguish HTTP GET, TCP Socket, and Exec liveness probes by what each checks and what counts as success or failure.
- HTTP GET health criterion. Explain how the kiada container’s HTTP GET liveness probe checks whether the application can still serve requests and what response counts as healthy.
- Probe timing and failure settings. Explain what the liveness probe timing and failure fields control, using the kiada probe’s default behavior as an example.
- Failure threshold and restart. Trace what happens when Envoy’s health check is made to fail: the warning event, the effect of a single failure, and the restart after three consecutive failures.
- TCP socket liveness checks. Explain when to use a tcpSocket liveness probe and how it determines success or failure. Describe what the section’s example checks.
- In-container command liveness checks. Explain when to use an exec liveness probe, where its command runs, and how the command’s result affects container health.
- Slow startup liveness tradeoff. Explain why a slow-starting application can get stuck in a restart loop under liveness probes, and why simply allowing more liveness failures slows detection of later health problems.
- Startup probe handoff. Describe which probe runs while the container starts, when Kubernetes switches to the liveness probe, and what repeated startup-probe failure means.
- Liveness probes and false restarts. Explain why pods generally need a liveness probe and why an incorrectly implemented handler can be worse than having none.
- Internal application health checks. Describe what a liveness endpoint should check and why external dependencies must not determine its result.
- Container lifecycle hook timing. Explain that a post-start hook runs when a container starts and a pre-stop hook runs shortly before it stops, allowing additional actions at those points in the container’s life cycle.
- Post-start hook purpose and timing. Explain when a post-start hook runs and why it can be useful for initializing an application without changing its code or image.
- Exec hook quote initialization. Trace how the Quote service’s exec post-start hook prepares a quote for Nginx to serve, including how it runs multiple commands.
- Hook effects on container status. Describe how an unfinished or failed post-start hook affects container status, access, and diagnosis.
- HTTP GET hook limitations. Distinguish an HTTP GET post-start hook from an exec hook and explain the timing and response-code pitfalls described here.
- Pre-stop shutdown sequence. Explain when a pre-stop hook runs relative to SIGTERM and how it can help a container shut down gracefully, using the Nginx example.
- Application SIGTERM delivery. Explain why an application may not receive SIGTERM and what to change instead of adding a hook to send it.
- Container-level hook triggers. Distinguish container termination from pod shutdown as a trigger for pre-stop hooks, and state when the hook is not called.
- Pod life cycle stages. Describe the three stages of a pod’s life cycle and what happens to its containers in each stage.
- Sequential init container startup. Trace how a pod starts its init containers in the order listed in initContainers, pulling each image before starting its container and waiting for successful completion before moving on.
- Failed init container policies. Distinguish what happens after an init container fails under restart policies Always or OnFailure versus Never.
- Container startup order and independence. Explain when regular containers begin starting, why they may start at different times, and how a post-start hook can delay another container.
- Startup hooks and health probes. Trace how the main process, post-start hook, startup probe, and liveness probe fit into a container’s startup and continued running.
- Failure termination and restart policy. Explain what happens when startup or liveness probing repeatedly fails, and how the pod’s restart policy affects the terminated container.
- Graceful container termination sequence. Trace the pre-stop hook, termination signal, grace period, and forced kill when a container must stop; distinguish its shutdown from other containers’ shutdown.
- Pod termination sequence. Trace what happens when a Pod object is deleted, from the status change through container shutdown to deletion of the object.
- Deletion grace period controls. Explain where the pod’s deletion grace period comes from, how it can be changed, and what it means for shutdown.
- Native sidecar lifecycle ordering. Explain how a native sidecar affects the order in which a pod’s containers start and terminate.
What it builds on
- Understanding the structure of an object manifest (chapter 4) · Introduces the structure of an object manifest, which includes a status section.
- Understanding individual object fields (chapter 4) · Reading individual fields of a Kubernetes object.
- Using kubectl (chapter 3) · Using kubectl to inspect Kubernetes objects.
- Understanding an object’s status conditions (chapter 4) · The idea of status conditions on Kubernetes objects.
- Inspecting objects using the kubectl describe command (chapter 4) · Inspecting Kubernetes objects with kubectl describe.
- Introducing init containers (chapter 5) · The distinction between init containers and regular containers.
- Running multiple containers in a pod (chapter 5) · The example uses a pod with separate Node.js and Envoy containers.
- Adding Envoy proxy to the pod (chapter 5) · The pod has a Node.js application and an Envoy proxy container.
Section by section
Introduction
This chapter introduction previews a deeper look at pod and container operation, including status, health, lifecycle hooks, and life cycles.
6.1 Understanding the pod’s status
This section identifies where to read a pod’s status and which status fields matter for understanding its life cycle.
- Pod status and life cycle: Explain that reading a Pod object back from the API reveals its status, and identify the pod’s phase, conditions, and individual container states as the status information relevant to its life cycle.
Why it matters: These fields give you a starting point for interpreting what is happening to a pod.
Key terms: Pod object, status section, phase, conditions, container states
6.1.1 Understanding the pod phase
The section introduces the pod phase as a quick summary of a pod’s state, shows where to inspect it, and cautions that kubectl’s STATUS column does not always show the phase.
- Pod phase and location: Explain that a pod is in one of five phases at any moment and that its phase provides a quick summary of what is happening with it. Describe where to find the phase in the Pod object.
Why it matters: The phase gives you a quick place to start when checking what is happening with a pod. - Phase versus STATUS column: Distinguish the pod’s phase from the STATUS column in kubectl get pods, and describe ways to inspect the phase directly.
Why it matters: Reading the phase directly avoids mistaking a problem shown in STATUS for the pod’s phase.
Key terms: pod phase, Pod object, status section, kubectl get pods, STATUS column, kubectl describe, status.phase
6.1.2 Understanding pod conditions
This section explains how pod conditions give a more detailed view of a pod’s state than its phase and how to inspect those conditions.
- Pod condition meaning and changes: Explain how pod conditions differ from the pod phase and describe how the named conditions can change over a pod’s lifetime.
Why it matters: Conditions help you distinguish a pod’s current state from its broader life-cycle phase. - Inspecting pod condition details: Describe where to inspect pod conditions and what their status and diagnostic fields report.
Why it matters: The manifest provides the detail needed to investigate a condition that is not fulfilled.
Key terms: pod phase, pod conditions, PodScheduled, Initialized, Ready, ContainersReady, kubectl describe, status.conditions, status, reason
6.1.3 Understanding the container status
This section explains what individual container statuses reveal and how to inspect them in a pod.
- Individual container status fields: Explain how a pod’s container status distinguishes the current state from the previous terminated state and reports readiness, restarts, and container and image identifiers.
Why it matters: These fields help you tell what is happening to a particular container rather than relying on the pod’s overall status. - Inspecting regular and init containers: Describe how to find individual container statuses and where init-container statuses appear in a Pod object.
Why it matters: Looking at individual statuses lets you identify which regular or init container needs attention.
Key terms: container status, state, lastState, containerID, imageID, ready, kubectl get pods, kubectl describe, initContainerStatuses
6.2 Keeping containers healthy
This section introduces the question of how to keep pods healthy and their containers running when containers die.
6.2.1 Understanding container auto-restart
This section explains how Kubernetes responds when a container terminates, how a pod’s restart policy affects that response, and why repeated terminations delay restarts.
- Container restart and recreation: Explain what happens when a pod’s container terminates and what Kubernetes means by restarting it. Describe what happens to the pod’s other containers and to data written in the terminated container’s filesystem.
Why it matters: It explains both the application’s automatic recovery from a terminated process and why container-local files cannot be relied on after a restart. - Pod-level restart policy: Describe the default restart behavior and where it can be changed.
Why it matters: A successful process exit can still cause a restart, and the setting affects the whole pod. - Repeated restart back-off: Trace how the delay before a container restart changes after repeated terminations and explain what CrashLoopBackOff indicates in the container status.
Why it matters: It explains why a repeatedly terminating container may remain unavailable for minutes instead of restarting immediately.
Key terms: Kubelet, Pod object, container restart, container filesystem, restartPolicy, pod spec, exit code, exponential back-off, CrashLoopBackOff, Waiting
6.2.2 Checking the container’s health using liveness probes
This section explains why liveness probes are needed, what Kubernetes does when one fails, and how the three probe types determine success.
- Need for external health checks: Explain why restarting a container only after its process exits may not keep an application healthy.
Why it matters: A running process is not necessarily a working application. - Liveness probe failure response: Describe how Kubernetes uses a liveness probe and what happens when the check fails.
Why it matters: A liveness probe lets Kubernetes act on a failure even when the application process has not exited. - Three liveness probe mechanisms: Distinguish HTTP GET, TCP Socket, and Exec liveness probes by what each checks and what counts as success or failure.
Why it matters: The probe type determines what evidence Kubernetes uses to judge whether a container is alive.
Key terms: unresponsive, liveness probe, restart policy, regular containers, init containers, HTTP GET probe, TCP Socket probe, Exec probe
6.2.3 Creating an HTTP GET liveness probe
Shows how to add HTTP GET liveness probes to both containers in a pod and configure their targets and failure timing.
- HTTP GET health criterion: Explain how the kiada container’s HTTP GET liveness probe checks whether the application can still serve requests and what response counts as healthy.
Why it matters: The response criterion determines whether this probe reports the application as healthy. - Envoy health endpoint target: Describe why Envoy’s liveness probe targets its /ready endpoint on admin port 9901 rather than the HTTPS-forwarding port 8443.
Why it matters: The two containers need probe targets suited to the endpoints their applications actually provide. - Probe timing and failure settings: Explain what the liveness probe timing and failure fields control, using the kiada probe’s default behavior as an example.
Why it matters: These settings determine when checks begin and how quickly repeated failures mark a container unhealthy.
Key terms: HTTP GET probe, path, port, HTTP status, Envoy proxy, /ready, admin port, initialDelaySeconds, periodSeconds, timeoutSeconds
6.2.4 Observing the liveness probe in action
Shows how to observe successful and failing liveness probes, a container restart after repeated failures, and evidence of how the container shut down.
- Successful probe visibility: Explain why successful liveness probes do not appear in pod status or events, and where their HTTP requests can be observed for the two containers.
Why it matters: Knowing where to look prevents you from mistaking a lack of events for a lack of probing. - Failure threshold and restart: Trace what happens when Envoy’s health check is made to fail: the warning event, the effect of a single failure, and the restart after three consecutive failures.
Why it matters: The threshold explains why an isolated failed check need not restart a container. - Graceful restart evidence: Describe how the pod status and previous container logs show whether Envoy shut down gracefully during the probe-triggered restart.
Why it matters: A restart count alone does not tell you whether the old process had a chance to shut down gracefully.
Key terms: liveness probe, container logs, /tmp/envoy.admin.log, Warning event, failureThreshold, RESTARTS, exit code zero, exit code 137, SIGTERM, --previous
6.2.5 Using the exec and the tcpSocket liveness probe types
Explains how tcpSocket and exec liveness probes check container health when an application has no HTTP health-check endpoint.
- TCP socket liveness checks: Explain when to use a tcpSocket liveness probe and how it determines success or failure. Describe what the section’s example checks.
Why it matters: A TCP connection can provide a liveness check when the application has no HTTP health-check endpoint. - In-container command liveness checks: Explain when to use an exec liveness probe, where its command runs, and how the command’s result affects container health.
Why it matters: A command offers a health check for an application that cannot be checked through a TCP connection.
Key terms: tcpSocket liveness probe, TCP port, failureThreshold, exec liveness probe, exit code, timeoutSeconds
6.2.6 Using a startup probe when an application is slow to start
Explains how a startup probe lets a slow-starting application warm up without delaying detection of health problems after startup.
- Slow startup liveness tradeoff: Explain why a slow-starting application can get stuck in a restart loop under liveness probes, and why simply allowing more liveness failures slows detection of later health problems.
Why it matters: It explains why one set of liveness settings may not work well for both startup and normal operation. - Startup probe handoff: Describe which probe runs while the container starts, when Kubernetes switches to the liveness probe, and what repeated startup-probe failure means.
Why it matters: The handoff gives the application time to start without sacrificing prompt health checks afterward. - Separate startup and liveness timing: Describe how the Kiada example gives startup more time while retaining quick liveness checks during normal operation.
Why it matters: The example shows how to set different time allowances for warm-up and ongoing health checks.
Key terms: liveness probe, periodSeconds, failureThreshold, initialDelaySeconds, startup probe
6.2.7 Creating effective liveness probe handlers
This section explains how to design liveness checks that detect a stuck application without causing unnecessary restarts or consuming excessive resources.
- Liveness probes and false restarts: Explain why pods generally need a liveness probe and why an incorrectly implemented handler can be worse than having none.
Why it matters: A probe should help recover a stuck application, not disrupt one that is healthy. - Internal application health checks: Describe what a liveness endpoint should check and why external dependencies must not determine its result.
Why it matters: Checking only problems a restart can address prevents one service failure from triggering restarts elsewhere. - Lightweight probe handlers: Explain why liveness probe handlers should complete quickly and use few resources.
Why it matters: A health check should not slow down the application it is meant to protect. - Probe failure threshold: Explain why repeated failures should be handled with the probe’s failureThreshold rather than a retry loop inside its handler.
Why it matters: The probe configuration can tolerate occasional failures while keeping the handler simple.
Key terms: liveness probe, probe handler, health-check endpoint, /healthz, internal components, backend service, HTTP GET probe, exec liveness probe, failureThreshold, retry loop
6.3 Executing actions at container start-up and shutdown
Introduces container lifecycle hooks, when they run, where they are configured, and which handlers they support.
- Container lifecycle hook timing: Explain that a post-start hook runs when a container starts and a pre-stop hook runs shortly before it stops, allowing additional actions at those points in the container’s life cycle.
Why it matters: The hook type determines when an additional action runs. - Hook scope and handlers: Distinguish per-container lifecycle hooks from pod-level init containers, and describe the supported command and HTTP GET handlers and the absence of tcpSocket handlers.
Why it matters: The scope and handler choices determine where a hook can be configured and what action it can perform.
Key terms: lifecycle hooks, post-start hooks, pre-stop hooks, regular containers, init containers, HTTP GET, tcpSocket handlers
6.3.1 Using post-start hooks to perform actions when the container starts
This section explains how post-start hooks run initialization actions when a container starts, using exec and HTTP GET examples, and shows how their timing and failures affect the container.
- Post-start hook purpose and timing: Explain when a post-start hook runs and why it can be useful for initializing an application without changing its code or image.
Why it matters: The timing determines whether the initialization action can safely depend on the application already running. - Exec hook quote initialization: Trace how the Quote service’s exec post-start hook prepares a quote for Nginx to serve, including how it runs multiple commands.
Why it matters: The example shows how a hook can prepare content that a container’s main process then serves. - Hook effects on container status: Describe how an unfinished or failed post-start hook affects container status, access, and diagnosis.
Why it matters: A pod that appears not to have started may actually be running its main process while its hook is still unfinished. - HTTP GET hook limitations: Distinguish an HTTP GET post-start hook from an exec hook and explain the timing and response-code pitfalls described here.
Why it matters: An HTTP hook can repeatedly restart a container if it calls a server that has not started, yet a wrong URI may go unnoticed.
Key terms: post-start lifecycle hook, exec, httpGet, fortune, nginx:alpine, postStart, Waiting, ContainerCreating, Pending, FailedPostStartHook
6.3.2 Using pre-stop hooks to run a process just before the container terminates
This section explains how pre-stop hooks run before container termination, how they can support graceful shutdown, and why they are not a substitute for correct signal handling.
- Pre-stop shutdown sequence: Explain when a pre-stop hook runs relative to SIGTERM and how it can help a container shut down gracefully, using the Nginx example.
Why it matters: The order of these actions determines whether an application gets a chance to finish work during shutdown. - Hook actions and failure: Describe the pre-stop actions presented here and what happens if a hook fails.
Why it matters: A terminating container does not prove that its pre-stop action succeeded. - Application SIGTERM delivery: Explain why an application may not receive SIGTERM and what to change instead of adding a hook to send it.
Why it matters: Fixing the process that receives SIGTERM addresses the cause of a missed shutdown signal. - Container-level hook triggers: Distinguish container termination from pod shutdown as a trigger for pre-stop hooks, and state when the hook is not called.
Why it matters: A pre-stop hook cannot reliably stand in for a one-time action at pod shutdown.
Key terms: pre-stop hook, SIGTERM, nginx -s quit, graceful shutdown, exec, httpGet, sleep, FailedPreStopHook, ENTRYPOINT, CMD
6.4 Understanding the pod life cycle
Introduces the three stages of a pod’s life cycle, from initialization through running to termination.
- Pod life cycle stages: Describe the three stages of a pod’s life cycle and what happens to its containers in each stage.
Why it matters: These stages give you a framework for following what happens to a pod from creation to termination.
Key terms: initialization stage, run stage, termination stage, init containers, regular containers
6.4.1 Understanding the initialization stage
This section explains how a pod starts its init containers, pulls their images, handles failures, and may occasionally run them again.
- Sequential init container startup: Trace how a pod starts its init containers in the order listed in initContainers, pulling each image before starting its container and waiting for successful completion before moving on.
Why it matters: It explains why a regular container may not have started even though the pod has begun initializing. - Container image pull policy: Explain what the imagePullPolicy controls when an init container starts or restarts, including the consequence of Always when the registry is offline.
Why it matters: Image-pull behavior can determine whether a container starts or restarts when its registry is unavailable. - Failed init container policies: Distinguish what happens after an init container fails under restart policies Always or OnFailure versus Never.
Why it matters: The restart policy determines whether initialization can recover from a failed init container. - Init container re-execution: Explain why operations performed by init containers must be idempotent even though they normally execute only once.
Why it matters: Repeat-safe initialization avoids problems if Kubernetes has to run an init container again.
Key terms: init containers, initContainers, regular containers, imagePullPolicy, Always, image registry, restart policy, OnFailure, Never, Init:Error
6.4.2 Understanding the run stage
This section traces what happens to regular pod containers during the run stage, from image pulling and startup through health checks, termination, and possible restart.
- Container startup order and independence: Explain when regular containers begin starting, why they may start at different times, and how a post-start hook can delay another container.
Why it matters: It explains why containers in one pod may become available at different times. - Startup hooks and health probes: Trace how the main process, post-start hook, startup probe, and liveness probe fit into a container’s startup and continued running.
Why it matters: The sequence clarifies which checks can affect a newly started container and when liveness checks begin. - Failure termination and restart policy: Explain what happens when startup or liveness probing repeatedly fails, and how the pod’s restart policy affects the terminated container.
Why it matters: It distinguishes a failed container’s fate from the fate of the other containers in its pod. - Graceful container termination sequence: Trace the pre-stop hook, termination signal, grace period, and forced kill when a container must stop; distinguish its shutdown from other containers’ shutdown.
Why it matters: It shows when an application has a chance to exit cleanly and when Kubernetes will force it to stop.
Key terms: init containers, regular containers, post-start hook, imagePullPolicy, main container process, startup probe, liveness probe, failure threshold, restartPolicy, Terminated state
6.4.3 Understanding the termination stage
Explains how deleting a pod terminates its containers, how the deletion grace period controls shutdown time, and why handling SIGTERM matters.
- Pod termination sequence: Trace what happens when a Pod object is deleted, from the status change through container shutdown to deletion of the object.
Why it matters: The sequence explains why deleting a Pod object may not remove it immediately. - Deletion grace period controls: Explain where the pod’s deletion grace period comes from, how it can be changed, and what it means for shutdown.
Why it matters: Choosing an appropriate grace period gives an application time to shut down without needlessly delaying pod deletion. - Kiada slow shutdown diagnosis: Explain how the kiada-ssl example identifies and fixes the cause of a slow pod shutdown.
Why it matters: The example shows why checking how an application responds to SIGTERM is more useful than simply shortening its shutdown time.
Key terms: Terminating, pre-stop hook, SIGTERM, KILL signal, deletion grace period, metadata.deletionGracePeriodSeconds, spec.terminationGracePeriodSeconds, --grace-period, pre-stop hooks, kiada-ssl Pod
6.4.4 Visualizing the full life cycle of the pod’s containers
This section summarizes the pod’s initialization and normal operation, emphasizing when native sidecar containers start and terminate.
- Native sidecar lifecycle ordering: Explain how a native sidecar affects the order in which a pod’s containers start and terminate.
Why it matters: Sidecars follow different start-up and shutdown ordering from regular containers.
Key terms: restartPolicy, Always, sidecar container, initContainers, regular containers
6.5 Summary
Summarizes how to inspect pod status, understand container replacement and health checks, and manage container startup and graceful shutdown.
Where this is used later
- Persisting files across container restarts (chapter 9) · Explains why a volume is needed to retain files across container restarts.
- Running tasks with the Job resource (chapter 18) · Container restart behavior
- Introducing readiness probes (chapter 11) · The exec and TCP socket probe types introduced for liveness checks.
- Introducing volumes (chapter 9) · The pod life cycle and container restarts.
- Implementing real-world readiness probes (chapter 11) · Pod termination
Concepts explained in this chapter
- liveness checkA liveness probe is a Kubernetes health check that determines whether a container's application is functioning and can trigger container termination after failure.
- post-start hookA post-start hook is a Kubernetes container lifecycle handler invoked when a container starts.
- pre-stop hookA pre-stop hook is a Kubernetes container lifecycle action executed before Kubernetes terminates the container.
- SIGTERMSIGTERM is an operating-system termination signal that requests a process to shut down gracefully.
- CrashLoopBackOffCrashLoopBackOff is a Kubernetes container state reason indicating repeated termination and a waiting period before the next restart.
- lifecycle methodA lifecycle hook is a Kubernetes container configuration that triggers an action at a defined point in the container lifecycle.
- restart policyThe OnFailure restart policy directs Kubernetes to restart containers when they terminate unsuccessfully.
- exec lifecycle hookAn exec lifecycle hook runs a command or process inside a container at a configured lifecycle event.
- http get lifecycle hookAn HTTP GET lifecycle hook sends an HTTP GET request to a specified host, port, and path at a configured container lifecycle event.
- termination grace periodThe terminationGracePeriodSeconds field specifies the default number of seconds Kubernetes allows a pod's containers to terminate gracefully.
- startup probeA startup probe is a Kubernetes container health check that determines when a slow-starting application has initialized sufficiently for other probes to begin operating.
- container auto-restartA container restart is the termination and subsequent creation or execution of a replacement instance of a container by its runtime or orchestrator.
- http get probeAn httpGet probe is a Kubernetes container probe that sends an HTTP GET request to determine the application state.
- pod phaseA pod phase is a high-level Kubernetes status value summarizing the pod's current lifecycle stage.
- exec probeAn exec probe is a Kubernetes liveness-check mechanism that runs a command inside a container and succeeds when the command exits with code zero before its timeout.
- exponential backoffExponential backoff is a retry strategy that progressively increases the delay between successive attempts, subject to a maximum and reset conditions.
- init containerAn init container is a Kubernetes pod container that runs during initialization before the pod's regular containers start.
- image pull policyAn image pull policy is a Kubernetes container setting that determines when its container image is pulled onto a node.
- primary containerA regular container is a pod container that runs after all init containers have completed.
- exit codeAn exit code is a numeric result returned by a process when it terminates, conventionally indicating success or failure.
- termination stageThe termination stage is the pod lifecycle stage in which its containers are shut down after the Pod object is deleted.
- exec formThe exec form is Dockerfile syntax that invokes an ENTRYPOINT or CMD executable directly without starting a shell.
- graceful shutdownA graceful shutdown is an orderly termination procedure that stops accepting new work and allows in-progress work to complete before exit.
- shell formThe shell form is Dockerfile syntax that runs an ENTRYPOINT or CMD instruction through a shell.
- container recreationContainer recreation is the replacement of a terminated container by discarding it and creating a new container.
- TCP socket probeA TCP socket probe is a Kubernetes container probe that checks whether a TCP connection can be established on a specified port.
- ready conditionContainer readiness is the status indicating whether a container is ready to serve its intended workload.
- conditionA condition is a status entry representing one aspect of a Kubernetes object's current state.
- podA pod object is a Kubernetes API resource representing the desired and observed state of a pod.
- statusStatus is the Kubernetes object field containing information about the current observed state of the represented component or resource.
- native sidecarA native sidecar is a Kubernetes container configured as an init container with restartPolicy set to Always, giving it sidecar lifecycle ordering and restart behavior.
- sidecar processThe sidecar pattern places a complementary process in a separate container alongside a primary application process in the same pod.
- containerA container is an isolated execution environment that packages an application process with its dependencies while sharing the host operating system kernel.
- terminatingTerminating is a Kubernetes lifecycle status indicating that an object has been marked for deletion but has not yet been fully removed.
← Chapter 5: Running applications with pods
Chapter 7: Organizing pods and other resources using namespaces and labels →
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.