Bottom line: Choose the API server health signal from the action it should drive. A restart decision, a decision to stop sending traffic and an operator investigation need separate entries in the control-plane runbook.
\nThe Kubernetes API health endpoints documentation is the primary reference.
\nThe aggregate livez endpoint addresses whether the API server needs restarting, while readyz addresses whether it can accept traffic. The guide directs machines to use HTTP status codes and reserves verbose output for human diagnosis. Its separate individual-health-check subsection is labeled alpha since Kubernetes 1.37; those per-check endpoints are outside this article.
This article covers the aggregate control-plane endpoints, not application-container probe configuration or individual alpha checks. An endpoint response is one observation. It does not establish that every cluster workload, dependency or administrator workflow is functioning. Keep authentication and the approved connection method within the deployment-specific runbook.
\nDSE recommends writing two explicit control-plane decisions before changing a health consumer. Name the component that can restart an API server and the component that can stop routing requests to one. Have their owners identify which aggregate endpoint each uses and what happens when the request itself cannot be completed.
\nKeep the machine contract small. Record the endpoint, response status, observation time and server identity. Treat a connection failure as its own diagnostic condition rather than manufacturing a successful response from a missing body. Review any existing text parser against the documented status-code contract before relying on it.
\nGive operators a separate diagnostic step. Use the documented authenticated kubectl get example with --raw when that access method is appropriate, and retain the verbose checks for investigation. Do not copy the page’s local TLS-bypass example into an ordinary monitoring runbook. Select the approved trust and authentication configuration for the actual cluster.
Document the return-to-service decision as well as the failure action. Require the responsible operator to connect the endpoint result with the maintenance or incident timeline. Keep a temporary diagnostic exclusion out of the normal machine check unless a separately reviewed requirement explicitly calls for it.
\nProposed verification, not performed: prepare three labeled inputs at the health consumer boundary: a successful aggregate status, a failed status and an unavailable endpoint. Confirm the intended restart or routing branch without disrupting an unapproved control plane. Identify injected inputs clearly; they are not evidence that an API server entered those states.
\nSeparately, obtain an authorized verbose response and ask an operator to explain which checks require investigation. Retain the actual HTTP status beside that text. Review whether the automation would reach the same decision if human-readable wording changed while the status remained the same. Record the chosen endpoint, authenticated route, consumer behavior and unresolved conditions with the runbook revision.
\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Choose the API server health signal from the action it should drive. A restart decision, a decision to stop sending traffic and an operator investigation need separate entries in the control-plane runbook.\nSource fact: documented behavior\nThe Kubernetes API health endpoints documentation is the primary reference.\nThe aggregate livez endpoint addresses whether the API server needs restarting, while readyz addresses whether it can accept traffic. The guide directs machines to use HTTP status codes and reserves verbose output for human diagnosis. Its separate individual-health-check subsection is labeled alpha since Kubernetes 1.37; those per-check endpoints are outside this article.\nWhat the source does not establish\nThis article covers the aggregate control-plane endpoints, not application-container probe configuration or individual alpha checks. An endpoint response is one observation. It does not establish that every cluster workload, dependency or administrator workflow is functioning. Keep authentication and the approved connection method within the deployment-specific runbook.\nApplicability questions\n\nWhich decision will consume the check: restart, traffic routing or investigation?\nWhich API server instance and approved authenticated route are being tested?\nDoes automation use the HTTP status or parse diagnostic text?\nWhat evidence will confirm recovery beyond the health response?\n\nDSE recommendation: map each signal to an action\nDSE recommends writing two explicit control-plane decisions before changing a health consumer. Name the component that can restart an API server and the component that can stop routing requests to one. Have their owners identify which aggregate endpoint each uses and what happens when the request itself cannot be completed.\nKeep the machine contract small. Record the endpoint, response status, observation time and server identity. Treat a connection failure as its own diagnostic condition rather than manufacturing a successful response from a missing body. Review any existing text parser against the documented status-code contract before relying on it.\nGive operators a separate diagnostic step. Use the documented authenticated kubectl get example with --raw when that access method is appropriate, and retain the verbose checks for investigation. Do not copy the page’s local TLS-bypass example into an ordinary monitoring runbook. Select the approved trust and authentication configuration for the actual cluster.\nDocument the return-to-service decision as well as the failure action. Require the responsible operator to connect the endpoint result with the maintenance or incident timeline. Keep a temporary diagnostic exclusion out of the normal machine check unless a separately reviewed requirement explicitly calls for it.\nVerification and evidence\nProposed verification, not performed: prepare three labeled inputs at the health consumer boundary: a successful aggregate status, a failed status and an unavailable endpoint. Confirm the intended restart or routing branch without disrupting an unapproved control plane. Identify injected inputs clearly; they are not evidence that an API server entered those states.\nSeparately, obtain an authorized verbose response and ask an operator to explain which checks require investigation. Retain the actual HTTP status beside that text. Review whether the automation would reach the same decision if human-readable wording changed while the status remained the same. Record the chosen endpoint, authenticated route, consumer behavior and unresolved conditions with the runbook revision.\nOfficial references\n\nKubernetes API health endpoints — Kubernetes.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Choose the API server health signal from the action it should drive. A restart decision, a decision to stop sending traffic and an operator investigation need separate entries in the control-plane runbook.\n\n## Source fact: documented behavior\n\nThe [Kubernetes API health endpoints](https://kubernetes.io/docs/reference/using-api/health-checks/) documentation is the primary reference.\n\nThe aggregate livez endpoint addresses whether the API server needs restarting, while readyz addresses whether it can accept traffic. The guide directs machines to use HTTP status codes and reserves verbose output for human diagnosis. Its separate individual-health-check subsection is labeled alpha since Kubernetes 1.37; those per-check endpoints are outside this article.\n\n## What the source does not establish\n\nThis article covers the aggregate control-plane endpoints, not application-container probe configuration or individual alpha checks. An endpoint response is one observation. It does not establish that every cluster workload, dependency or administrator workflow is functioning. Keep authentication and the approved connection method within the deployment-specific runbook.\n\n## Applicability questions\n\n- Which decision will consume the check: restart, traffic routing or investigation?\n\n- Which API server instance and approved authenticated route are being tested?\n\n- Does automation use the HTTP status or parse diagnostic text?\n\n- What evidence will confirm recovery beyond the health response?\n\n## DSE recommendation: map each signal to an action\n\nDSE recommends writing two explicit control-plane decisions before changing a health consumer. Name the component that can restart an API server and the component that can stop routing requests to one. Have their owners identify which aggregate endpoint each uses and what happens when the request itself cannot be completed.\n\nKeep the machine contract small. Record the endpoint, response status, observation time and server identity. Treat a connection failure as its own diagnostic condition rather than manufacturing a successful response from a missing body. Review any existing text parser against the documented status-code contract before relying on it.\n\nGive operators a separate diagnostic step. Use the documented authenticated kubectl get example with --raw when that access method is appropriate, and retain the verbose checks for investigation. Do not copy the page’s local TLS-bypass example into an ordinary monitoring runbook. Select the approved trust and authentication configuration for the actual cluster.\n\nDocument the return-to-service decision as well as the failure action. Require the responsible operator to connect the endpoint result with the maintenance or incident timeline. Keep a temporary diagnostic exclusion out of the normal machine check unless a separately reviewed requirement explicitly calls for it.\n\n## Verification and evidence\n\nProposed verification, not performed: prepare three labeled inputs at the health consumer boundary: a successful aggregate status, a failed status and an unavailable endpoint. Confirm the intended restart or routing branch without disrupting an unapproved control plane. Identify injected inputs clearly; they are not evidence that an API server entered those states.\n\nSeparately, obtain an authorized verbose response and ask an operator to explain which checks require investigation. Retain the actual HTTP status beside that text. Review whether the automation would reach the same decision if human-readable wording changed while the status remained the same. Record the chosen endpoint, authenticated route, consumer behavior and unresolved conditions with the runbook revision.\n\n## Official references\n\n- [Kubernetes API health endpoints](https://kubernetes.io/docs/reference/using-api/health-checks/) — Kubernetes.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/separate-kubernetes-api-server-readiness-from-liveness/", "url": "https://update.dsesecurity.com/updates/separate-kubernetes-api-server-readiness-from-liveness/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/separate-kubernetes-api-server-readiness-from-liveness/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Business Continuity", "item": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "ListItem", "position": 3, "name": "Separate Kubernetes API server readiness from liveness", "item": "https://update.dsesecurity.com/updates/separate-kubernetes-api-server-readiness-from-liveness/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/separate-kubernetes-api-server-readiness-from-liveness/#article", "identifier": "https://update.dsesecurity.com/updates/separate-kubernetes-api-server-readiness-from-liveness/", "url": "https://update.dsesecurity.com/updates/separate-kubernetes-api-server-readiness-from-liveness/", "headline": "Separate Kubernetes API server readiness from liveness", "description": "Choose aggregate API server health endpoints by the intended action, and keep verbose diagnostic output separate from machine health decisions.", "abstract": "Choose aggregate API server health endpoints by the intended action, and keep verbose diagnostic output separate from machine health decisions.", "articleBody": "Bottom line: Choose the API server health signal from the action it should drive. A restart decision, a decision to stop sending traffic and an operator investigation need separate entries in the control-plane runbook.\nSource fact: documented behavior\nThe Kubernetes API health endpoints documentation is the primary reference.\nThe aggregate livez endpoint addresses whether the API server needs restarting, while readyz addresses whether it can accept traffic. The guide directs machines to use HTTP status codes and reserves verbose output for human diagnosis. Its separate individual-health-check subsection is labeled alpha since Kubernetes 1.37; those per-check endpoints are outside this article.\nWhat the source does not establish\nThis article covers the aggregate control-plane endpoints, not application-container probe configuration or individual alpha checks. An endpoint response is one observation. It does not establish that every cluster workload, dependency or administrator workflow is functioning. Keep authentication and the approved connection method within the deployment-specific runbook.\nApplicability questions\n\nWhich decision will consume the check: restart, traffic routing or investigation?\nWhich API server instance and approved authenticated route are being tested?\nDoes automation use the HTTP status or parse diagnostic text?\nWhat evidence will confirm recovery beyond the health response?\n\nDSE recommendation: map each signal to an action\nDSE recommends writing two explicit control-plane decisions before changing a health consumer. Name the component that can restart an API server and the component that can stop routing requests to one. Have their owners identify which aggregate endpoint each uses and what happens when the request itself cannot be completed.\nKeep the machine contract small. Record the endpoint, response status, observation time and server identity. Treat a connection failure as its own diagnostic condition rather than manufacturing a successful response from a missing body. Review any existing text parser against the documented status-code contract before relying on it.\nGive operators a separate diagnostic step. Use the documented authenticated kubectl get example with --raw when that access method is appropriate, and retain the verbose checks for investigation. Do not copy the page’s local TLS-bypass example into an ordinary monitoring runbook. Select the approved trust and authentication configuration for the actual cluster.\nDocument the return-to-service decision as well as the failure action. Require the responsible operator to connect the endpoint result with the maintenance or incident timeline. Keep a temporary diagnostic exclusion out of the normal machine check unless a separately reviewed requirement explicitly calls for it.\nVerification and evidence\nProposed verification, not performed: prepare three labeled inputs at the health consumer boundary: a successful aggregate status, a failed status and an unavailable endpoint. Confirm the intended restart or routing branch without disrupting an unapproved control plane. Identify injected inputs clearly; they are not evidence that an API server entered those states.\nSeparately, obtain an authorized verbose response and ask an operator to explain which checks require investigation. Retain the actual HTTP status beside that text. Review whether the automation would reach the same decision if human-readable wording changed while the status remained the same. Record the chosen endpoint, authenticated route, consumer behavior and unresolved conditions with the runbook revision.\nOfficial references\n\nKubernetes API health endpoints — Kubernetes.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T00:09:56+00:00", "dateModified": "2026-10-29T00:10:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/separate-kubernetes-api-server-readiness-from-liveness/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/separate-kubernetes-api-server-readiness-from-liveness/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Separate Kubernetes API server readiness from liveness" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 532, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes — Kubernetes API health endpoints", "url": "https://kubernetes.io/docs/reference/using-api/health-checks/" } } ] } }