Masterbtc/Kubernetes_documentation huggingface dataset:
# Running Multiple Instances of Your App

Running Multiple Instances of Your AppObjectivesScale an existing app manually using kubectl.Scaling an applicationYou can create from the start a Deployment with multiple instances using the --replicas parameter for the kubectl create deployment command.Previously we created a Deployment, and then exposed it publicly via a Service. The Deployment created only one Pod for running our application. When traffic increases, we will need to scale the application to keep up with user demand.If you haven't worked through the earlier sections, start from Using minikube to create a cluster.Scaling is accomplished by changing the number of replicas in a Deployment.Note:If you are trying this after the previous section, then you may have deleted the service you created, or have created a Service of type: NodePort. In this section, it is assumed that a service with type: LoadBalancer is created for the kubernetes-bootcamp Deployment.If you have not deleted the Service created in the previous section, first delete that Service and then run the following command to create a new Service with its type set to LoadBalancer:kubectl expose deployment/kubernetes-bootcamp --type="LoadBalancer" --port 8080 Scaling overviewScaling is accomplished by changing the number of replicas in a Deployment.Scaling out a Deployment will ensure new Pods are created and scheduled to Nodes with available resources. Scaling will increase the number of Pods to the new desired state. Kubernetes also supports autoscaling of Pods, but it is outside of the scope of this tutorial. Scaling to zero is also possible, and it will terminate all Pods of the specified Deployment.Running multiple instances of an application will require a way to distribute the traffic to all of them. Services have an integrated load-balancer that will distribute network traffic to all Pods of an exposed Deployment. Services will monitor continuously the running Pods using endpoints, to ensure the traffic is sent only to available Pods.Once you have multiple instances of an application running, you would be able to do Rolling updates without downtime. We'll cover that in the
# Instrumentation

InstrumentationKubernetes Component SLI MetricsHigh-level indicators for measuring the reliability and performance of Kubernetes components.CRI Pod & Container MetricsCollection of Pod & Container metrics via the CRI.Node metrics dataMechanisms for accessing metrics at node, volume, pod and container level, as seen by the kubelet.Understand Pressure Stall Information (PSI) MetricsDetailed explanation of Pressure Stall Information (PSI) metrics and how to use them to identify resource pressure in Kubernetes.Kubernetes z-pagesProvides runtime diagnostics for Kubernetes components, offering insights into component runtime status and configuration flags.Kubernetes Metrics ReferenceDetails of the metric data that Kubernetes components export.
# Building a Basic DaemonSet

Building a Basic DaemonSetThis page demonstrates how to build a basic DaemonSet that runs a Pod on every node in a Kubernetes cluster. It covers a simple use case of mounting a file from the host, logging its contents using an init container, and utilizing a pause container.Before you beginYou 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. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:iximiuz LabsKillercodaKodeKloudPlay with KubernetesA Kubernetes cluster with at least two nodes (one control plane node and one worker node) to demonstrate the behavior of DaemonSets.Define the DaemonSetIn this task, a basic DaemonSet is created which ensures that the copy of a Pod is scheduled on every node. The Pod will use an init container to read and log the contents of /etc/machine-id from the host, while the main container will be a pause container, which keeps the Pod running.application/basic-daemonset.yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: example-daemonset spec: selector: matchLabels: app.kubernetes.io/name: example template: metadata: labels: app.kubernetes.io/name: example spec: containers: - name: pause image: registry.k8s.io/pause initContainers: - name: log-machine-id image: busybox:1.37 command: ['sh', '-c', 'cat /etc/machine-id > /var/log/machine-id.log'] volumeMounts: - name: machine-id mountPath: /etc/machine-id readOnly: true - name: log-dir mountPath: /var/log volumes: - name: machine-id hostPath: path: /etc/machine-id type: File - name: log-dir hostPath: path: /var/logCreate a DaemonSet based on the (YAML) manifest:kubectl apply -f https://k8s.io/examples/application/basic-daemonset.yaml Once applied, you can verify that the DaemonSet is running a Pod on every node in the cluster:kubectl get pods -o wide The output will list one Pod per node, similar to:NAME READY STATUS RESTARTS AGE IP NODE example-daemonset-xxxxx 1/1 Running 0 5m x.x.x.x node-1 example-daemonset-yyyyy 1/1 Running 0 5m x.x.x.x node-2 You can inspect the contents of the logged /etc/machine-id file by checking the log directory mounted from the host:kubectl exec <pod-name> -- cat /var/log/machine-id.log Where <pod-name> is the name of one of your Pods.Cleaning upTo delete the DaemonSet, run this command:kubectl delete --cascade=foreground --ignore-not-found --now daemonsets/example-daemonset This simple DaemonSet example introduces key components like init containers and host path volumes, which can be expanded upon for more advanced use cases. For more details refer to DaemonSet.What's nextSee Performing a rolling update on a DaemonSetSee Creating a DaemonSet to adopt existing DaemonSet pods
# Issue Wranglers

Issue WranglersAlongside the PR Wrangler, formal approvers, reviewers and members of SIG Docs take week-long shifts triaging and categorising issues for the repository.DutiesEach day in a week-long shift the Issue Wrangler will be responsible for:Triaging and tagging incoming issues daily. See Triage and categorize issues for guidelines on how SIG Docs uses metadata.Keeping an eye on stale & rotten issues within the kubernetes/website repository.Maintenance of the Issues board.RequirementsMust be an active member of the Kubernetes organization.A minimum of 15 non-trivial contributions to Kubernetes (of which a certain amount should be directed towards kubernetes/website).Performing the role in an informal capacity already.Helpful Prow commands for wranglersBelow are some commonly used commands for Issue Wranglers:# reopen an issue /reopen # transfer issues that don't fit in k/website to another repository /transfer[-issue] # change the state of rotten issues /remove-lifecycle rotten # change the state of stale issues /remove-lifecycle stale # assign sig to an issue /sig <sig_name> # add specific area /area <area_name> # for beginner friendly issues /good-first-issue # issues that needs help /help wanted # tagging issue as support specific /kind support # to accept triaging for an issue /triage accepted # closing an issue we won't be working on and haven't fixed yet /close not-planned To find more Prow commands, refer to the Command Help documentation.When to close IssuesFor an open source project to succeed, good issue management is crucial. But it is also critical to resolve issues in order to maintain the repository and communicate clearly with contributors and users.Close issues when:A similar issue is reported more than once. You will first need to tag it as /triage duplicate; link it to the main issue & then close it. It is also advisable to direct the users to the original issue.It is very difficult to understand and address the issue presented by the author with the information provided. However, encourage the user to provide more details or reopen the issue if they can reproduce it later.The same functionality is implemented elsewhere. One can close this issue and direct user to the appropriate place.The reported issue is not currently planned or aligned with the project's goals.If the issue appears to be spam and is clearly unrelated.If the issue is related to an external limitation or dependency and is beyond the control of the project.To close an issue, leave a /close comment on the issue.
# Options for Highly Available Topology

Options for Highly Available TopologyThis page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters.You can set up an HA cluster:With stacked control plane nodes, where etcd nodes are colocated with control plane nodesWith external etcd nodes, where etcd runs on separate nodes from the control planeYou should carefully consider the advantages and disadvantages of each topology before setting up an HA cluster.Note:kubeadm bootstraps the etcd cluster statically. Read the etcd Clustering Guide for more details.Stacked etcd topologyA stacked HA cluster is a topology where the distributed data storage cluster provided by etcd is stacked on top of the cluster formed by the nodes managed by kubeadm that run control plane components.Each control plane node runs an instance of the kube-apiserver, kube-scheduler, and kube-controller-manager. The kube-apiserver is exposed to worker nodes using a load balancer.Each control plane node creates a local etcd member and this etcd member communicates only with the kube-apiserver of this node. The same applies to the local kube-controller-manager and kube-scheduler instances.This topology couples the control planes and etcd members on the same nodes. It is simpler to set up than a cluster with external etcd nodes, and simpler to manage for replication.However, a stacked cluster runs the risk of failed coupling. If one node goes down, both an etcd member and a control plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.You should therefore run a minimum of three stacked control plane nodes for an HA cluster.This is the default topology in kubeadm. A local etcd member is created automatically on control plane nodes when using kubeadm init and kubeadm join --control-plane.External etcd topologyAn HA cluster with external etcd is a topology where the distributed data storage cluster provided by etcd is external to the cluster formed by the nodes that run control plane components.Like the stacked etcd topology, each control plane node in an external etcd topology runs an instance of the kube-apiserver, kube-scheduler, and kube-controller-manager. And the kube-apiserver is exposed to worker nodes using a load balancer. However, etcd members run on separate hosts, and each etcd host communicates with the kube-apiserver of each control plane node.This topology decouples the control plane and etcd member. It therefore provides an HA setup where losing a control plane instance or an etcd member has less impact and does not affect the cluster redundancy as much as the stacked HA topology.However, this topology requires twice the number of hosts as the stacked HA topology. A minimum of three hosts for control plane nodes and three hosts for etcd nodes are required for an HA cluster with this topology.What's nextSet up a highly available cluster with kubeadm
# Patch

PatchPatch is provided to give a concrete name and type to the Kubernetes PATCH request body.import "k8s.io/apimachinery/pkg/apis/meta/v1"Patch is provided to give a concrete name and type to the Kubernetes PATCH request body.This page is automatically generated.If you plan to report an issue with this page, mention that the page is auto-generated in your issue description. The fix may need to happen elsewhere in the Kubernetes project.
# Adding Linux worker nodes

Adding Linux worker nodesThis page explains how to add Linux worker nodes to a kubeadm cluster.Before you beginEach joining worker node has installed the required components from Installing kubeadm, such as, kubeadm, the kubelet and a container runtime.A running kubeadm cluster created by kubeadm init and following the steps in the document Creating a cluster with kubeadm.You need superuser access to the node.Adding Linux worker nodesTo add new Linux worker nodes to your cluster do the following for each machine:Connect to the machine by using SSH or another method.Run the command that was output by kubeadm init. For example:sudo kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash> Additional information for kubeadm joinNote:To specify an IPv6 tuple for <control-plane-host>:<control-plane-port>, IPv6 address must be enclosed in square brackets, for example: [2001:db8::101]:2073.If you do not have the token, you can get it by running the following command on the control plane node:# Run this on a control plane node sudo kubeadm token list The output is similar to this:TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS 8ewj1p.9r9hcjoqgajrj4gi 23h 2018-06-12T02:51:28Z authentication, The default bootstrap system: signing token generated by bootstrappers: 'kubeadm init'. kubeadm: default-node-token By default, node join tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired, you can create a new token by running the following command on the control plane node:# Run this on a control plane node sudo kubeadm token create The output is similar to this:5didvk.d09sbcov8ph2amjw To print a kubeadm join command while also generating a new token you can use:sudo kubeadm token create --print-join-command If you don't have the value of --discovery-token-ca-cert-hash, you can get it by running the following commands on the control plane node:# Run this on a control plane node sudo cat /etc/kubernetes/pki/ca.crt | openssl x509 -pubkey | openssl rsa -pubin -outform der 2>/dev/null | \ openssl dgst -sha256 -hex | sed 's/^.* //' The output is similar to:8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78 The output of the kubeadm join command should look something like:[preflight] Running pre-flight checks ... (log output of join workflow) ... Node join complete: * Certificate signing request sent to control-plane and response received. * Kubelet informed of new secure connection details. Run 'kubectl get nodes' on control-plane to see this machine join. A few seconds later, you should notice this node in the output from kubectl get nodes. (for example, run kubectl on a control plane node).Note:As the cluster nodes are usually initialized sequentially, the CoreDNS Pods are likely to all run on the first control plane node. To provide higher availability, please rebalance the CoreDNS Pods with kubectl -n kube-system rollout restart deployment coredns after at least one new node is joined.What's nextSee how to add Windows worker nodes.
# Linux Node Swap Behaviors

Linux Node Swap BehaviorsTo allow Kubernetes workloads to use swap, on a Linux node, you must disable the kubelet's default behavior of failing when swap is detected, and specify memory-swap behavior as LimitedSwap:The available choices for swap behavior are:NoSwap(default) Workloads running as Pods on this node do not and cannot use swap. However, processes outside of Kubernetes' scope, such as system daemons (including the kubelet itself!) can utilize swap. This behavior is beneficial for protecting the node from system-level memory spikes, but it does not safeguard the workloads themselves from such spikes.LimitedSwapKubernetes workloads can utilize swap memory. The amount of swap available to a Pod is determined automatically.To learn more, read swap memory management.
# Security For Linux Nodes

Security For Linux NodesThis page describes security considerations and best practices specific to the Linux operating system.Protection for Secret data on nodesOn Linux nodes, memory-backed volumes (such as secret volume mounts, or emptyDir with medium: Memory) are implemented with a tmpfs filesystem.If you have swap configured and use an older Linux kernel (or a current kernel and an unsupported configuration of Kubernetes), memory backed volumes can have data written to persistent storage.The Linux kernel officially supports the noswap option from version 6.3, therefore it is recommended the used kernel version is 6.3 or later, or supports the noswap option via a backport, if swap is enabled on the node.Read swap memory management for more info.
# Extend Resources

Extend ResourcesCustomResourceDefinitionCustomResourceDefinition represents a resource that should be exposed on the API server.DeviceClassDeviceClass is a vendor- or admin-provided resource that contains device configuration and selectors.MutatingWebhookConfigurationMutatingWebhookConfiguration describes the configuration of and admission webhook that accept or reject and may change the object.ValidatingWebhookConfigurationValidatingWebhookConfiguration describes the configuration of and admission webhook that accept or reject and object without changing it.This page is automatically generated.If you plan to report an issue with this page, mention that the page is auto-generated in your issue description. The fix may need to happen elsewhere in the Kubernetes project.
# Pod Security Policies

Pod Security PoliciesRemoved featurePodSecurityPolicy was deprecated in Kubernetes v1.21, and removed from Kubernetes in v1.25.Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using either or both:Pod Security Admissiona 3rd party admission plugin, that you deploy and configure yourselfFor a migration guide, see Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller. For more information on the removal of this API, see PodSecurityPolicy Deprecation: Past, Present, and Future.If you are not running Kubernetes v1.34, check the documentation for your version of Kubernetes.
# Kubernetes External Metrics (v1beta1)

Kubernetes External Metrics (v1beta1)Package v1beta1 is the v1beta1 version of the external metrics API.Resource TypesExternalMetricValueExternalMetricValueListExternalMetricValueAppears in:ExternalMetricValueListExternalMetricValue is a metric value for external metric A single metric value is identified by metric name and a set of string labels. For one metric there can be multiple values with different sets of labels.FieldDescriptionapiVersionstringexternal.metrics.k8s.io/v1beta1kindstringExternalMetricValuemetricName [Required]stringthe name of the metricmetricLabels [Required]map[string]stringa set of labels that identify a single time series for the metrictimestamp [Required]meta/v1.Timeindicates the time at which the metrics were producedwindow [Required]int64indicates the window ([Timestamp-Window, Timestamp]) from which these metrics were calculated, when returning rate metrics calculated from cumulative metrics (or zero for non-calculated instantaneous metrics).value [Required]k8s.io/apimachinery/pkg/api/resource.Quantitythe value of the metricExternalMetricValueListExternalMetricValueList is a list of values for a given metric for some set labelsFieldDescriptionapiVersionstringexternal.metrics.k8s.io/v1beta1kindstringExternalMetricValueListmetadata [Required]meta/v1.ListMetaNo description provided.items [Required][]ExternalMetricValuevalue of the metric matching a given set of labelsThis page is automatically generated.If you plan to report an issue with this page, mention that the page is auto-generated in your issue description. The fix may need to happen elsewhere in the Kubernetes project.
# Common Definitions

Common DefinitionsDeleteOptionsDeleteOptions may be provided when deleting an API object.LabelSelectorA label selector is a label query over a set of resources.ListMetaListMeta describes metadata that synthetic resources must have, including lists and various status objects.LocalObjectReferenceLocalObjectReference contains enough information to let you locate the referenced object inside the same namespace.NodeSelectorRequirementA node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.ObjectFieldSelectorObjectFieldSelector selects an APIVersioned field of an object.ObjectMetaObjectMeta is metadata that all persisted resources must have, which includes all objects users must create.ObjectReferenceObjectReference contains enough information to let you inspect or modify the referred object.PatchPatch is provided to give a concrete name and type to the Kubernetes PATCH request body.QuantityQuantity is a fixed-point representation of a number.ResourceFieldSelectorResourceFieldSelector represents container resources (cpu, memory) and their output format.StatusStatus is a return value for calls that don't return other objects.TypedLocalObjectReferenceTypedLocalObjectReference contains enough information to let you locate the typed referenced object inside the same namespace.This page is automatically generated.If you plan to report an issue with this page, mention that the page is auto-generated in your issue description. The fix may need to happen elsewhere in the Kubernetes project.
# Assign Pods to Nodes

Assign Pods to NodesThis page shows how to assign a Kubernetes Pod to a particular node in a Kubernetes cluster.Before you beginYou 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. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:iximiuz LabsKillercodaKodeKloudPlay with KubernetesTo check the version, enter kubectl version.Add a label to a nodeList the nodes in your cluster, along with their labels:kubectl get nodes --show-labels The output is similar to this:NAME STATUS ROLES AGE VERSION LABELS worker0 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker0 worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1 worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2 Choose one of your nodes, and add a label to it:kubectl label nodes <your-node-name> disktype=ssd where <your-node-name> is the name of your chosen node.Verify that your chosen node has a disktype=ssd label:kubectl get nodes --show-labels The output is similar to this:NAME STATUS ROLES AGE VERSION LABELS worker0 Ready <none> 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0 worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1 worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2 In the preceding output, you can see that the worker0 node has a disktype=ssd label.Create a pod that gets scheduled to your chosen nodeThis pod configuration file describes a pod that has a node selector, disktype: ssd. This means that the pod will get scheduled on a node that has a disktype=ssd label.pods/pod-nginx.yaml apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent nodeSelector: disktype: ssd Use the configuration file to create a pod that will get scheduled on your chosen node:kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml Verify that the pod is running on your chosen node:kubectl get pods --output=wide The output is similar to this:NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0 Create a pod that gets scheduled to specific nodeYou can also schedule a pod to one specific node via setting nodeName.pods/pod-nginx-specific-node.yaml apiVersion: v1 kind: Pod metadata: name: nginx spec: nodeName: foo-node # schedule pod to specific node containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent Use the configuration file to create a pod that will get scheduled on foo-node only.What's nextLearn more about labels and selectors.Learn more about nodes.
# Quantity

QuantityQuantity is a fixed-point representation of a number.import "k8s.io/apimachinery/pkg/api/resource"Quantity is a fixed-point representation of a number. It provides convenient marshaling/unmarshaling in JSON and YAML, in addition to String() and AsInt64() accessors.The serialization format is: \<quantity> ::= \<signedNumber>\<suffix> (Note that \<suffix> may be empty, from the "" case in \<decimalSI>.) \<digit> ::= 0 | 1 | ... | 9 \<digits> ::= \<digit> | \<digit>\<digits> \<number> ::= \<digits> | \<digits>.\<digits> | \<digits>. | .\<digits> \<sign> ::= "+" | "-" \<signedNumber> ::= \<number> | \<sign>\<number> \<suffix> ::= \<binarySI> | \<decimalExponent> | \<decimalSI> \<binarySI> ::= Ki | Mi | Gi | Ti | Pi | Ei (International System of units; See: http://physics.nist.gov/cuu/Units/binary.html) \<decimalSI> ::= m | "" | k | M | G | T | P | E (Note that 1024 = 1Ki but 1000 = 1k; I didn't choose the capitalization.) \<decimalExponent> ::= "e" \<signedNumber> | "E" \<signedNumber> No matter which of the three exponent forms is used, no quantity may represent a number greater than 2^63-1 in magnitude, nor may it have more than 3 decimal places. Numbers larger or more precise will be capped or rounded up. (E.g.: 0.1m will rounded up to 1m.) This may be extended in the future if we require larger or smaller quantities.When a Quantity is parsed from a string, it will remember the type of suffix it had, and will use the same type again when it is serialized.Before serializing, Quantity will be put in "canonical form". This means that Exponent/suffix will be adjusted up or down (with a corresponding increase or decrease in Mantissa) such that:No precision is lost - No fractional digits will be emitted - The exponent (or suffix) is as large as possible.The sign will be omitted unless the number is negative.Examples:1.5 will be serialized as "1500m" - 1.5Gi will be serialized as "1536Mi"Note that the quantity will NEVER be internally represented by a floating point number. That is the whole point of this exercise.Non-canonical values will still parse as long as they are well formed, but will be re-emitted in their canonical form. (So always use canonical form, or don't diff.)This format is intended to make it difficult to use these numbers without writing some sort of special handling code in the hopes that that will cause implementors to also use a fixed point implementation.This page is automatically generated.If you plan to report an issue with this page, mention that the page is auto-generated in your issue description. The fix may need to happen elsewhere in the Kubernetes project.
# Resize CPU and Memory Resources assigned to Containers

Resize CPU and Memory Resources assigned to ContainersFEATURE STATE: Kubernetes v1.33 [beta] (enabled by default: true)This page explains how to change the CPU and memory resource requests and limits assigned to a container without recreating the Pod.Traditionally, changing a Pod's resource requirements necessitated deleting the existing Pod and creating a replacement, often managed by a workload controller. In-place Pod Resize allows changing the CPU/memory allocation of container(s) within a running Pod while potentially avoiding application disruption.Key Concepts:Desired Resources: A container's spec.containers[*].resources represent the desired resources for the container, and are mutable for CPU and memory.Actual Resources: The status.containerStatuses[*].resources field reflects the resources currently configured for a running container. For containers that haven't started or were restarted, it reflects the resources allocated upon their
# 

Requirements:You need a machine that is running Linux or macOS.You need to have these tools installed:Python v3.7.x+GitGolang version 1.13+Pip used to install PyYAMLPyYAML v5.1.2makegcc compiler/linkerDocker (Required only for kubectl command reference)Your PATH environment variable must include the required build tools, such as the Go binary and python.You need to know how to create a pull request to a GitHub repository. This involves creating your own fork of the repository. For more information, see Work from a local clone.
# Debug a StatefulSet

Debug a StatefulSetThis task shows you how to debug a StatefulSet.Before you beginYou need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.You should have a StatefulSet running that you want to investigate.Debugging a StatefulSetIn order to list all the pods which belong to a StatefulSet, which have a label app.kubernetes.io/name=MyApp set on them, you can use the following:kubectl get pods -l app.kubernetes.io/name=MyApp If you find that any Pods listed are in Unknown or Terminating state for an extended period of time, refer to the Deleting StatefulSet Pods task for instructions on how to deal with them. You can debug individual Pods in a StatefulSet using the Debugging Pods guide.What's nextLearn more about debugging an init-container.
# Container Environment

Container EnvironmentThis page describes the resources available to Containers in the Container environment.Container environmentThe Kubernetes Container environment provides several important resources to Containers:A filesystem, which is a combination of an image and one or more volumes.Information about the Container itself.Information about other objects in the cluster.Container informationThe hostname of a Container is the name of the Pod in which the Container is running. It is available through the hostname command or the gethostname function call in libc.The Pod name and namespace are available as environment variables through the downward API.User defined environment variables from the Pod definition are also available to the Container, as are any environment variables specified statically in the container image.Cluster informationA list of all services that were running when a Container was created is available to that Container as environment variables. This list is limited to services within the same namespace as the new Container's Pod and Kubernetes control plane services.For a service named foo that maps to a Container named bar, the following variables are defined:FOO_SERVICE_HOST=<the host the service is running on> FOO_SERVICE_PORT=<the port the service is running on> Services have dedicated IP addresses and are available to the Container via DNS, if DNS addon is enabled. What's nextLearn more about Container lifecycle hooks.Get hands-on experience attaching handlers to Container lifecycle events.
# API Overview

API OverviewThis section provides reference information for the Kubernetes API.The REST API is the fundamental fabric of Kubernetes. All operations and communications between components, and external user commands are REST API calls that the API Server handles. Consequently, everything in the Kubernetes platform is treated as an API object and has a corresponding entry in the API.The Kubernetes API reference lists the API for Kubernetes version v1.34.For general background information, read The Kubernetes API. Controlling Access to the Kubernetes API describes how clients can authenticate to the Kubernetes API server, and how their requests are authorized.API versioningThe JSON and Protobuf serialization schemas follow the same guidelines for schema changes. The following descriptions cover both formats.The API versioning and software versioning are indirectly related. The API and release versioning proposal describes the relationship between API versioning and software versioning.Different API versions indicate different levels of stability and support. You can find more information about the criteria for each level in the API Changes documentation.Here's a summary of each level:Alpha:The version names contain alpha (for example, v1alpha1).Built-in alpha API versions are disabled by default and must be explicitly enabled in the kube-apiserver configuration to be used.The software may contain bugs. Enabling a feature may expose bugs.Support for an alpha API may be dropped at any time without notice.The API may change in incompatible ways in a later software release without notice.The software is recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.Beta:The version names contain beta (for example, v2beta3).Built-in beta API versions are disabled by default and must be explicitly enabled in the kube-apiserver configuration to be used (except for beta versions of APIs introduced prior to Kubernetes 1.22, which were enabled by default).Built-in beta API versions have a maximum lifetime of 9 months or 3 minor releases (whichever is longer) from introduction to deprecation, and 9 months or 3 minor releases (whichever is longer) from deprecation to removal.The software is well tested. Enabling a feature is considered safe.The support for a feature will not be dropped, though the details may change.The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable API version. When this happens, migration instructions are provided. Adapting to a subsequent beta or stable API version may require editing or re-creating API objects, and may not be straightforward. The migration may require downtime for applications that rely on the feature.The software is not recommended for production uses. Subsequent releases may introduce incompatible changes. Use of beta API versions is required to transition to subsequent beta or stable API versions once the beta API version is deprecated and no longer served.Note:Please try beta features and provide
# Weave Net for NetworkPolicy

Weave Net for NetworkPolicyThis page shows how to use Weave Net for NetworkPolicy.Before you beginYou need to have a Kubernetes cluster. Follow the kubeadm getting started guide to bootstrap one.Install the Weave Net addonFollow the Integrating Kubernetes via the Addon guide.The Weave Net addon for Kubernetes comes with a Network Policy Controller that automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces and configures iptables rules to allow or block traffic as directed by the policies.Test the installationVerify that the weave works.Enter the following command:kubectl get pods -n kube-system -o wide The output is similar to this:NAME READY STATUS RESTARTS AGE IP NODE weave-net-1t1qg 2/2 Running 0 9d 192.168.2.10 worknode3 weave-net-231d7 2/2 Running 1 7d 10.2.0.17 worknodegpu weave-net-7nmwt 2/2 Running 3 9d 192.168.2.131 masternode weave-net-pmw8w 2/2 Running 0 9d 192.168.2.216 worknode2 Each Node has a weave Pod, and all Pods are Running and 2/2 READY. (2/2 means that each Pod has weave and weave-npc.)What's nextOnce you have installed the Weave Net addon, you can follow the Declare Network Policy to try out Kubernetes NetworkPolicy. If you have any question, contact us at #weave-community on Slack or Weave User Group.
# Tasks

This section of the Kubernetes documentation contains pages that show how to do individual tasks. A task page shows how to do a single thing, typically by giving a short sequence of steps.If you would like to write a task page, see Creating a Documentation Pull Request.Install ToolsSet up Kubernetes tools on your computer.Administer a ClusterLearn common tasks for administering a cluster.Configure Pods and ContainersPerform common configuration tasks for Pods and containers.Monitoring, Logging, and DebuggingSet up monitoring and logging to troubleshoot a cluster, or debug a containerized application.Manage Kubernetes ObjectsDeclarative and imperative paradigms for interacting with the Kubernetes API.Managing SecretsManaging confidential settings data using Secrets.Inject Data Into ApplicationsSpecify configuration and other data for the Pods that run your workload.Run ApplicationsRun and manage both stateless and stateful applications.Run JobsRun Jobs using parallel processing.Access Applications in a ClusterConfigure load balancing, port forwarding, or setup firewall or DNS configurations to access applications in a cluster.Extend KubernetesUnderstand advanced ways to adapt your Kubernetes cluster to the needs of your work environment.TLSUnderstand how to protect traffic within your cluster using Transport Layer Security (TLS).Manage Cluster DaemonsPerform common tasks for managing a DaemonSet, such as performing a rolling update.NetworkingLearn how to configure networking for your cluster.Extend kubectl with pluginsExtend kubectl by creating and installing kubectl plugins.Manage HugePagesConfigure and manage huge pages as a schedulable resource in a cluster.Schedule GPUsConfigure and schedule GPUs for use as a resource by nodes in a cluster.
# Getting started

This section lists the different ways to set up and run Kubernetes. When you install Kubernetes, choose an installation type based on: ease of maintenance, security, control, available resources, and expertise required to operate and manage a cluster.You can download Kubernetes to deploy a Kubernetes cluster on a local machine, into the cloud, or for your own datacenter.Several Kubernetes components such as kube-apiserver or kube-proxy can also be deployed as container images within the cluster.It is recommended to run Kubernetes components as container images wherever that is possible, and to have Kubernetes manage those components. Components that run containers - notably, the kubelet - can't be included in this category.If you don't want to manage a Kubernetes cluster yourself, you could pick a managed service, including certified platforms. There are also other standardized and custom solutions across a wide range of cloud and bare metal environments.Learning environmentIf you're learning Kubernetes, use the tools supported by the Kubernetes community, or tools in the ecosystem to set up a Kubernetes cluster on a local machine. See Install tools.Production environmentWhen evaluating a solution for a production environment, consider which aspects of operating a Kubernetes cluster (or abstractions) you want to manage yourself and which you prefer to hand off to a provider.For a cluster you're managing yourself, the officially supported tool for deploying Kubernetes is kubeadm.What's nextDownload KubernetesDownload and install tools including kubectlSelect a container runtime for your new clusterLearn about best practices for cluster setupKubernetes is designed for its control plane to run on Linux. Within your cluster you can run applications on Linux or other operating systems, including Windows.Learn to set up clusters with Windows nodes
# API Access Control

API Access ControlFor an introduction to how Kubernetes implements and controls API access, read Controlling Access to the Kubernetes API.Reference documentation:AuthenticatingAuthenticating with Bootstrap TokensAdmission ControllersDynamic Admission ControlAuthorizationRole Based Access ControlAttribute Based Access ControlNode AuthorizationWebhook AuthorizationCertificate Signing Requestsincluding CSR approval and certificate signingService accountsDeveloper guideAdministrationKubelet Authentication & Authorizationincluding kubelet TLS bootstrapping
# Kubernetes Documentation

Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation (CNCF).Understand KubernetesLearn about Kubernetes and its fundamental concepts.Why Kubernetes?Components of a clusterThe Kubernetes APIObjects In KubernetesContainersWorkloads and PodsView ConceptsTry KubernetesFollow tutorials to learn how to deploy applications in Kubernetes.Hello MinikubeWalkthrough the basicsStateless Example: PHP Guestbook with RedisStateful Example: Wordpress with Persistent VolumesView TutorialsSet up a K8s clusterGet Kubernetes running based on your resources and needs.Learning environmentProduction environmentInstall the kubeadm setup toolSecuring a clusterkubeadm command referenceSet up KubernetesLearn how to use KubernetesLook up common tasks and how to perform them using a short sequence of steps.kubectl Quick ReferenceInstall kubectlConfigure access to clustersUse the Web UI DashboardConfigure a Pod to Use a ConfigMapGetting helpView TasksLook up reference informationBrowse terminology, command line syntax, API resource types, and setup tool documentation.Glossarykubectl command line toolLabels, annotations and taintsKubernetes API referenceOverview of APIFeature GatesView ReferenceContribute to KubernetesFind out how you can help make Kubernetes better.Contribute to KubernetesContribute to documentationSuggest content improvementsOpening a pull requestDocumenting a feature for a releaseLocalizing the docsParticipating in SIG DocsViewing Site AnalyticsSee Ways to ContributeTrainingGet certified in Kubernetes and make your cloud native projects successful!View trainingDownload KubernetesInstall Kubernetes or upgrade to the newest version.Download KubernetesAbout the documentationThis website contains documentation for the current and previous 4 versions of Kubernetes.See available versions
# Automatic Cleanup for Finished Jobs

Automatic Cleanup for Finished JobsA time-to-live mechanism to clean up old Jobs that have finished execution.FEATURE STATE: Kubernetes v1.23 [stable]When your Job has finished, it's useful to keep that Job in the API (and not immediately delete the Job) so that you can tell whether the Job succeeded or failed.Kubernetes' TTL-after-finished controller provides a TTL (time to live) mechanism to limit the lifetime of Job objects that have finished execution.Cleanup for finished JobsThe TTL-after-finished controller is only supported for Jobs. You can use this mechanism to clean up finished Jobs (either Complete or Failed) automatically by specifying the .spec.ttlSecondsAfterFinished field of a Job, as in this example.The TTL-after-finished controller assumes that a Job is eligible to be cleaned up TTL seconds after the Job has finished. The timer starts once the status condition of the Job changes to show that the Job is either Complete or Failed; once the TTL has expired, that Job becomes eligible for cascading removal. When the TTL-after-finished controller cleans up a job, it will delete it cascadingly, that is to say it will delete its dependent objects together with it.Kubernetes honors object lifecycle guarantees on the Job, such as waiting for finalizers.You can set the TTL seconds at any time. Here are some examples for setting the .spec.ttlSecondsAfterFinished field of a Job:Specify this field in the Job manifest, so that a Job can be cleaned up automatically some time after it finishes.Manually set this field of existing, already finished Jobs, so that they become eligible for cleanup.Use a mutating admission webhook to set this field dynamically at Job creation time. Cluster administrators can use this to enforce a TTL policy for finished jobs.Use a mutating admission webhook to set this field dynamically after the Job has finished, and choose different TTL values based on job status, labels. For this case, the webhook needs to detect changes to the .status of the Job and only set a TTL when the Job is being marked as completed.Write your own controller to manage the cleanup TTL for Jobs that match a particular selector.CaveatsUpdating TTL for finished JobsYou can modify the TTL period, e.g. .spec.ttlSecondsAfterFinished field of Jobs, after the job is created or has finished. If you extend the TTL period after the existing ttlSecondsAfterFinished period has expired, Kubernetes doesn't guarantee to retain that Job, even if an update to extend the TTL returns a successful API response.Time skewBecause the TTL-after-finished controller uses timestamps stored in the Kubernetes jobs to determine whether the TTL has expired or not, this feature is sensitive to time skew in your cluster, which may cause the control plane to clean up Job objects at the wrong time.Clocks aren't always correct, but the difference should be very small. Please be aware of this risk when setting a non-zero TTL.What's nextRead Clean up Jobs automaticallyRefer to the Kubernetes Enhancement Proposal (KEP) for adding this mechanism.
# Kubeadm

KubeadmKubeadm is a tool built to provide kubeadm init and kubeadm join as best-practice "fast paths" for creating Kubernetes clusters.kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.How to installTo install kubeadm, see the installation guide.What's nextkubeadm init to bootstrap a Kubernetes control-plane nodekubeadm join to bootstrap a Kubernetes worker node and join it to the clusterkubeadm upgrade to upgrade a Kubernetes cluster to a newer versionkubeadm config if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for kubeadm upgradekubeadm token to manage tokens for kubeadm joinkubeadm reset to revert any changes made to this host by kubeadm init or kubeadm joinkubeadm certs to manage Kubernetes certificateskubeadm kubeconfig to manage kubeconfig fileskubeadm version to print the kubeadm versionkubeadm alpha to preview a set of features made available for gathering
# Binding

BindingBinding ties one object to another; for example, a pod is bound to a node by a scheduler.apiVersion: v1import "k8s.io/api/core/v1"BindingBinding ties one object to another; for example, a pod is bound to a node by a scheduler.apiVersion: v1kind: Bindingmetadata (ObjectMeta)Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadatatarget (ObjectReference), requiredThe target object that you want to bind to the standard object.Operationscreate create a BindingHTTP RequestPOST /api/v1/namespaces/{namespace}/bindingsParametersnamespace (in path): string, requirednamespacebody: Binding, requireddryRun (in query): stringdryRunfieldManager (in query): stringfieldManagerfieldValidation (in query): stringfieldValidationpretty (in query): stringprettyResponse200 (Binding): OK201 (Binding): Created202 (Binding): Accepted401: Unauthorizedcreate create binding of a PodHTTP RequestPOST /api/v1/namespaces/{namespace}/pods/{name}/bindingParametersname (in path): string, requiredname of the Bindingnamespace (in path): string, requirednamespacebody: Binding, requireddryRun (in query): stringdryRunfieldManager (in query): stringfieldManagerfieldValidation (in query): stringfieldValidationpretty (in query): stringprettyResponse200 (Binding): OK201 (Binding): Created202 (Binding): Accepted401: UnauthorizedThis page is automatically generated.If you plan to report an issue with this page, mention that the page is auto-generated in your issue description. The fix may need to happen elsewhere in the Kubernetes project.
# Policy Resources

Policy ResourcesFlowSchemaFlowSchema defines the schema of a group of flows.LimitRangeLimitRange sets resource usage limits for each kind of resource in a Namespace.ResourceQuotaResourceQuota sets aggregate quota restrictions enforced per namespace.NetworkPolicyNetworkPolicy describes what network traffic is allowed for a set of Pods.PodDisruptionBudgetPodDisruptionBudget is an object to define the max disruption that can be caused to a collection of pods.PriorityLevelConfigurationPriorityLevelConfiguration represents the configuration of a priority level.ValidatingAdmissionPolicyValidatingAdmissionPolicy describes the definition of an admission validation policy that accepts or rejects an object without changing it.ValidatingAdmissionPolicyBindingValidatingAdmissionPolicyBinding binds the ValidatingAdmissionPolicy with paramerized resources.MutatingAdmissionPolicy v1beta1MutatingAdmissionPolicy describes the definition of an admission mutation policy that mutates the object coming into admission chain.MutatingAdmissionPolicyBinding v1alpha1MutatingAdmissionPolicyBinding binds the MutatingAdmissionPolicy with parametrized resources.This page is automatically generated.If you plan to report an issue with this page, mention that the page is auto-generated in your issue description. The fix may need to happen elsewhere in the Kubernetes project.