FEATURE STATE: Kubernetes v1.29 [stable] By default, Kubernetes 1.31 publishes Service Level Indicator (SLI) metrics for each Kubernetes component binary. This metric endpoint is exposed on the serving HTTPS port of each component, at the path /metrics/slis. The ComponentSLIs feature gate defaults to enabled for each Kubernetes component as of v1.27. SLI Metrics With SLI metrics enabled, each Kubernetes component exposes two metrics, labeled per healthcheck: a gauge (which represents the current state of the healthcheck) a counter (which records the cumulative counts observed for each healthcheck state) You can use the metric information to calculate per-component availability statistics.

This page shows how to create a Kubernetes Service object that external clients can use to access an application running in a cluster. The Service provides load balancing for an application that has two running instances. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts.

This task shows how to create a frontend and a backend microservice. The backend microservice is a hello greeter. The frontend exposes the backend using nginx and a Kubernetes Service object. Objectives Create and run a sample hello backend microservice using a Deployment object. Use a Service object to send traffic to the backend microservice's multiple replicas. Create and run a nginx frontend microservice, also using a Deployment object. Configure the frontend microservice to send traffic to the backend microservice.

This page shows how to run an application using a Kubernetes Deployment object. Objectives Create an nginx deployment. Use kubectl to list information about the deployment. Update the deployment. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts.

Use Custom Resources Extend the Kubernetes API with CustomResourceDefinitions Versions in CustomResourceDefinitions F...

Synopsis Creates an autoscaler that automatically chooses and sets the number of pods that run in a Kubernetes cluster. Looks up a deployment, replica set, stateful set, or replication controller by name and creates an autoscaler that uses the given resource as a reference. An autoscaler can automatically increase or decrease number of pods deployed within the system as needed. kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] Examples # Auto scale a deployment "foo", with the number of pods between 2 and 10, no target CPU utilization specified so a default autoscaling policy will be used kubectl autoscale deployment foo --min=2 --max=10 # Auto scale a replication controller "foo", with the number of pods between 1 and 5, target CPU utilization at 80% kubectl autoscale rc foo --max=5 --cpu-percent=80 Options --allow-missing-template-keys     Default: true If true, ignore any errors in templates when a field or map key is missing in the template.

Synopsis Output shell completion code for the specified shell (bash, zsh, fish, or powershell). The shell code must be evaluated to provide interactive completion of kubectl commands. This can be done by sourcing it from the .bash_profile. Detailed instructions on how to do this are available here: for macOS: https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/#enable-shell-autocompletion for linux: https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#enable-shell-autocompletion for windows: https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/#enable-shell-autocompletion Note for zsh users: [1] zsh completions are only supported in versions of zsh >= 5.

The topics in this section document how to generate the Kubernetes reference guides. To build the reference documentation, see the following guide: Generating Reference Documentation Quickstart

SIG Docs Reviewers and Approvers do a few extra things when reviewing a change. Every week a specific docs approver volunteers to triage and review pull requests. This person is the "PR Wrangler" for the week. See the PR Wrangler scheduler for more information. To become a PR Wrangler, attend the weekly SIG Docs meeting and volunteer. Even if you are not on the schedule for the current week, you can still review pull requests (PRs) that are not already under active review.

This page serves two purposes: Demonstrate how the Kubernetes documentation uses Markdown Provide a "smoke test" document we can use to test HTML, CSS, and template changes that affect the overall documentation. Heading levels The above heading is an H2. The page title renders as an H1. The following sections show H3-H6. H3 This is in an H3 section. H4 This is in an H4 section. H5 This is in an H5 section.