Masterbtc/Kubernetes_documentation huggingface dataset:
# Field Selectors

Field SelectorsField selectors let you select Kubernetes objects based on the value of one or more resource fields. Here are some examples of field selector queries:metadata.name=my-servicemetadata.namespace!=defaultstatus.phase=PendingThis kubectl command selects all Pods for which the value of the status.phase field is Running:kubectl get pods --field-selector status.phase=Running Note:Field selectors are essentially resource filters. By default, no selectors/filters are applied, meaning that all resources of the specified type are selected. This makes the kubectl queries kubectl get pods and kubectl get pods --field-selector "" equivalent.Supported fieldsSupported field selectors vary by Kubernetes resource type. All resource types support the metadata.name and metadata.namespace fields. Using unsupported field selectors produces an error. For example:kubectl get ingress --field-selector foo.bar=baz Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace" List of supported fieldsKindFieldsPodspec.nodeNamespec.restartPolicyspec.schedulerNamespec.serviceAccountNamespec.hostNetworkstatus.phasestatus.podIPstatus.nominatedNodeNameEventinvolvedObject.kindinvolvedObject.namespaceinvolvedObject.nameinvolvedObject.uidinvolvedObject.apiVersioninvolvedObject.resourceVersioninvolvedObject.fieldPathreasonreportingComponentsourcetypeSecrettypeNamespacestatus.phaseReplicaSetstatus.replicasReplicationControllerstatus.replicasJobstatus.successfulNodespec.unschedulableCertificateSigningRequestspec.signerNameCustom resources fieldsAll custom resource types support the metadata.name and metadata.namespace fields.Additionally, the spec.versions[*].selectableFields field of a CustomResourceDefinition declares which other fields in a custom resource may be used in field selectors. See selectable fields for custom resources for more information about how to use field selectors with CustomResourceDefinitions.Supported operatorsYou can use the =, ==, and != operators with field selectors (= and == mean the same thing). This kubectl command, for example, selects all Kubernetes Services that aren't in the default namespace:kubectl get services --all-namespaces --field-selector metadata.namespace!=default Note:Set-based operators (in, notin, exists) are not supported for field selectors.Chained selectorsAs with label and other selectors, field selectors can be chained together as a comma-separated list. This kubectl command selects all Pods for which the status.phase does not equal Running and the spec.restartPolicy field equals Always:kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always Multiple resource typesYou can use field selectors across multiple resource types. This kubectl command selects all Statefulsets and Services that are not in the default namespace:kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
# Validate node setup

Validate node setupNode Conformance TestNode conformance test is a containerized test framework that provides a system verification and functionality test for a node. The test validates whether the node meets the minimum requirements for Kubernetes; a node that passes the test is qualified to join a Kubernetes cluster.Node PrerequisiteTo run node conformance test, a node must satisfy the same prerequisites as a standard Kubernetes node. At a minimum, the node should have the following daemons installed:CRI-compatible container runtimes such as Docker, containerd and CRI-OkubeletRunning Node Conformance TestTo run the node conformance test, perform the following steps:Work out the value of the --kubeconfig option for the kubelet; for example: --kubeconfig=/var/lib/kubelet/config.yaml. Because the test framework starts a local control plane to test the kubelet, use http://localhost:8080 as the URL of the API server. There are some other kubelet command line parameters you may want to use:--cloud-provider: If you are using --cloud-provider=gce, you should remove the flag to run the test.Run the node conformance test with command:# $CONFIG_DIR is the pod manifest path of your kubelet. # $LOG_DIR is the test output path. sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ registry.k8s.io/node-test:0.2 Running Node Conformance Test for Other ArchitecturesKubernetes also provides node conformance test docker images for other architectures:ArchImageamd64node-test-amd64armnode-test-armarm64node-test-arm64Running Selected TestTo run specific tests, overwrite the environment variable FOCUS with the regular expression of tests you want to run.sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e FOCUS=MirrorPod \ # Only run MirrorPod test registry.k8s.io/node-test:0.2 To skip specific tests, overwrite the environment variable SKIP with the regular expression of tests you want to skip.sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test registry.k8s.io/node-test:0.2 Node conformance test is a containerized version of node e2e test. By default, it runs all conformance tests.Theoretically, you can run any node e2e test if you configure the container and mount required volumes properly. But it is strongly recommended to only run conformance test, because it requires much more complex configuration to run non-conformance test.CaveatsThe test leaves some docker images on the node, including the node conformance test image and images of containers used in the functionality test.The test leaves dead containers on the node. These containers are created during the functionality test.
# Kubelet Device Manager API Versions

Kubelet Device Manager API VersionsThis page provides details of version compatibility between the Kubernetes device plugin API, and different versions of Kubernetes itself.Compatibility matrixv1alpha1v1beta1Kubernetes 1.21-✓Kubernetes 1.22-✓Kubernetes 1.23-✓Kubernetes 1.24-✓Kubernetes 1.25-✓Kubernetes 1.26-✓Key:✓ Exactly the same features / API objects in both device plugin API and the Kubernetes version.+ The device plugin API has features or API objects that may not be present in the Kubernetes cluster, either because the device plugin API has added additional new API calls, or that the server has removed an old API call. However, everything they have in common (most other APIs) will work. Note that alpha APIs may vanish or change significantly between one minor release and the next.- The Kubernetes cluster has features the device plugin API can't use, either because server has added additional API calls, or that device plugin API has removed an old API call. However, everything they share in common (most APIs) will work.
# kubeadm kubeconfig

kubeadm kubeconfigkubeadm kubeconfig provides utilities for managing kubeconfig files.For examples on how to use kubeadm kubeconfig user see Generating kubeconfig files for additional users.kubeadm kubeconfigSynopsisKubeconfig file utilities.Options-h, --helphelp for kubeconfigOptions inherited from parent commands--rootfs stringThe path to the 'real' host root filesystem. This will cause kubeadm to chroot into the provided path.kubeadm kubeconfig userThis command can be used to output a kubeconfig file for an additional user.SynopsisOutput a kubeconfig file for an additional user.kubeadm kubeconfig user [flags] Examples # Output a kubeconfig file for an additional user named foo kubeadm kubeconfig user --client-name=foo # Output a kubeconfig file for an additional user named foo using a kubeadm config file bar kubeadm kubeconfig user --client-name=foo --config=bar Options--client-name stringThe name of user. It will be used as the CN if client certificates are created--config stringPath to a kubeadm configuration file.-h, --helphelp for user--org stringsThe organizations of the client certificate. It will be used as the O if client certificates are created--token stringThe token that should be used as the authentication mechanism for this kubeconfig, instead of client certificates--validity-period duration Default: 8760h0m0sThe validity period of the client certificate. It is an offset from the current time.Options inherited from parent commands--rootfs stringThe path to the 'real' host root filesystem. This will cause kubeadm to chroot into the provided path.
# Using CoreDNS for Service Discovery

Using CoreDNS for Service DiscoveryThis page describes the CoreDNS upgrade process and how to install CoreDNS instead of kube-dns.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 KubernetesYour Kubernetes server must be at or later than version v1.9.To check the version, enter kubectl version.About CoreDNSCoreDNS is a flexible, extensible DNS server that can serve as the Kubernetes cluster DNS. Like Kubernetes, the CoreDNS project is hosted by the CNCF.You can use CoreDNS instead of kube-dns in your cluster by replacing kube-dns in an existing deployment, or by using tools like kubeadm that will deploy and upgrade the cluster for you.Installing CoreDNSFor manual deployment or replacement of kube-dns, see the documentation at the CoreDNS website.Migrating to CoreDNSUpgrading an existing cluster with kubeadmIn Kubernetes version 1.21, kubeadm removed its support for kube-dns as a DNS application. For kubeadm v1.34, the only supported cluster DNS application is CoreDNS.You can move to CoreDNS when you use kubeadm to upgrade a cluster that is using kube-dns. In this case, kubeadm generates the CoreDNS configuration ("Corefile") based upon the kube-dns ConfigMap, preserving configurations for stub domains, and upstream name server.Upgrading CoreDNSYou can check the version of CoreDNS that kubeadm installs for each version of Kubernetes in the page CoreDNS version in Kubernetes.CoreDNS can be upgraded manually in case you want to only upgrade CoreDNS or use your own custom image. There is a helpful guideline and walkthrough available to ensure a smooth upgrade. Make sure the existing CoreDNS configuration ("Corefile") is retained when upgrading your cluster.If you are upgrading your cluster using the kubeadm tool, kubeadm can take care of retaining the existing CoreDNS configuration automatically.Tuning CoreDNSWhen resource utilisation is a concern, it may be useful to tune the configuration of CoreDNS. For more details, check out the documentation on scaling CoreDNS.What's nextYou can configure CoreDNS to support many more use cases than kube-dns does by modifying the CoreDNS configuration ("Corefile"). For more information, see the documentation for the kubernetes CoreDNS plugin, or read the Custom DNS Entries for Kubernetes. in the CoreDNS blog.
# List All Container Images Running in a Cluster

List All Container Images Running in a ClusterThis page shows how to use kubectl to list all of the Container images for Pods running in a 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.In this exercise you will use kubectl to fetch all of the Pods running in a cluster, and format the output to pull out the list of Containers for each.List all Container images in all namespacesFetch all Pods in all namespaces using kubectl get pods --all-namespacesFormat the output to include only the list of Container image names using -o jsonpath={.items[*].spec['initContainers', 'containers'][*].image}. This will recursively parse out the image field from the returned json.See the jsonpath reference for further information on how to use jsonpath.Format the output using standard tools: tr, sort, uniqUse tr to replace spaces with newlinesUse sort to sort the resultsUse uniq to aggregate image countskubectl get pods --all-namespaces -o jsonpath="{.items[*].spec['initContainers', 'containers'][*].image}" |\ tr -s '[[:space:]]' '\n' |\ sort |\ uniq -c The jsonpath is interpreted as follows:.items[*]: for each returned value.spec: get the spec['initContainers', 'containers'][*]: for each container.image: get the imageNote:When fetching a single Pod by name, for example kubectl get pod nginx, the .items[*] portion of the path should be omitted because a single Pod is returned instead of a list of items.List Container images by PodThe formatting can be controlled further by using the range operation to iterate over elements individually.kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort List Container images filtering by Pod labelTo target only Pods matching a specific label, use the -l flag. The following matches only Pods with labels matching app=nginx.kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx List Container images filtering by Pod namespaceTo target only pods in a specific namespace, use the namespace flag. The following matches only Pods in the kube-system namespace.kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}" List Container images using a go-template instead of jsonpathAs an alternative to jsonpath, Kubectl supports using go-templates for formatting the output:kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}" What's nextReferenceJsonpath reference guideGo template reference guide
# Node Reference Information

Node Reference InformationThis section contains the following reference topics about nodes:the kubelet's checkpoint APIa list of Articles on dockershim Removal and on Using CRI-compatible RuntimesKubelet Device Manager API VersionsNode Labels Populated By The KubeletLocal Files And Paths Used By The KubeletNode .status informationLinux Node Swap BehaviorsSeccomp informationYou can also read node reference details from elsewhere in the Kubernetes documentation, including:Node Metrics Data.CRI Pod & Container Metrics.Understand Pressure Stall Information (PSI) Metrics.
# Authentication Resources

Authentication ResourcesServiceAccountServiceAccount binds together: * a name, understood by users, and perhaps by peripheral systems, for an identity * a principal that can be authenticated and authorized * a set of secrets.TokenRequestTokenRequest requests a token for a given service account.TokenReviewTokenReview attempts to authenticate a token to a known user.CertificateSigningRequestCertificateSigningRequest objects provide a mechanism to obtain x509 certificates by submitting a certificate signing request, and having it asynchronously approved and issued.ClusterTrustBundle v1beta1ClusterTrustBundle is a cluster-scoped container for X.SelfSubjectReviewSelfSubjectReview contains the user information that the kube-apiserver has about the user making this request.PodCertificateRequest v1alpha1PodCertificateRequest encodes a pod requesting a certificate from a given signer.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.
# Install Tools

Install ToolsSet up Kubernetes tools on your computer.kubectlThe Kubernetes command-line tool, kubectl, allows you to run commands against Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage cluster resources, and view logs. For more information including a complete list of kubectl operations, see the kubectl reference documentation.kubectl is installable on a variety of Linux platforms, macOS and Windows. Find your preferred operating system below.Install kubectl on LinuxInstall kubectl on macOSInstall kubectl on Windowskindkind lets you run Kubernetes on your local computer. This tool requires that you have either Docker or Podman installed.The kind Quick Start page shows you what you need to do to get up and running with kind.View kind Quick Start GuideminikubeLike kind, minikube is a tool that lets you run Kubernetes locally. minikube runs an all-in-one or a multi-node local Kubernetes cluster on your personal computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes, or for daily development work.You can follow the official Get Started! guide if your focus is on getting the tool installed.View minikube Get Started! GuideOnce you have minikube working, you can use it to run a sample application.kubeadmYou can use the kubeadm tool to create and manage Kubernetes clusters. It performs the actions necessary to get a minimum viable, secure cluster up and running in a user friendly way.Installing kubeadm shows you how to install kubeadm. Once installed, you can use it to create a cluster.View kubeadm Install Guide
# WebhookAdmission Configuration (v1)

WebhookAdmission Configuration (v1)Package v1 is the v1 version of the API.Resource TypesWebhookAdmissionWebhookAdmissionWebhookAdmission provides configuration for the webhook admission controller.FieldDescriptionapiVersionstringapiserver.config.k8s.io/v1kindstringWebhookAdmissionkubeConfigFile [Required]stringKubeConfigFile is the path to the kubeconfig file.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.
# Generating Reference Pages for Kubernetes Components and Tools

Generating Reference Pages for Kubernetes Components and ToolsThis page shows how to build the Kubernetes component and tool reference pages.Before you beginStart with the Prerequisites section in the Reference Documentation Quickstart guide.Follow the Reference Documentation Quickstart to generate the Kubernetes component and tool reference pages.What's nextGenerating Reference Documentation QuickstartGenerating Reference Documentation for kubectl CommandsGenerating Reference Documentation for the Kubernetes APIContributing to the Upstream Kubernetes Project for Documentation
# Limit Storage Consumption

Limit Storage ConsumptionThis example demonstrates how to limit the amount of storage consumed in a namespace.The following resources are used in the demonstration: ResourceQuota, LimitRange, and PersistentVolumeClaim.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.Scenario: Limiting Storage ConsumptionThe cluster-admin is operating a cluster on behalf of a user population and the admin wants to control how much storage a single namespace can consume in order to control cost.The admin would like to limit:The number of persistent volume claims in a namespaceThe amount of storage each claim can requestThe amount of cumulative storage the namespace can haveLimitRange to limit requests for storageAdding a LimitRange to a namespace enforces storage request sizes to a minimum and maximum. Storage is requested via PersistentVolumeClaim. The admission controller that enforces limit ranges will reject any PVC that is above or below the values set by the admin.In this example, a PVC requesting 10Gi of storage would be rejected because it exceeds the 2Gi max.apiVersion: v1 kind: LimitRange metadata: name: storagelimits spec: limits: - type: PersistentVolumeClaim max: storage: 2Gi min: storage: 1Gi Minimum storage requests are used when the underlying storage provider requires certain minimums. For example, AWS EBS volumes have a 1Gi minimum requirement.ResourceQuota to limit PVC count and cumulative storage capacityAdmins can limit the number of PVCs in a namespace as well as the cumulative capacity of those PVCs. New PVCs that exceed either maximum value will be rejected.In this example, a 6th PVC in the namespace would be rejected because it exceeds the maximum count of 5. Alternatively, a 5Gi maximum quota when combined with the 2Gi max limit above, cannot have 3 PVCs where each has 2Gi. That would be 6Gi requested for a namespace capped at 5Gi.apiVersion: v1 kind: ResourceQuota metadata: name: storagequota spec: hard: persistentvolumeclaims: "5" requests.storage: "5Gi" SummaryA limit range can put a ceiling on how much storage is requested while a resource quota can effectively cap the storage consumed by a namespace through claim counts and cumulative storage capacity. The allows a cluster-admin to plan their cluster's storage budget without risk of any one project going over their allotment.
# ListMeta

ListMetaListMeta describes metadata that synthetic resources must have, including lists and various status objects.import "k8s.io/apimachinery/pkg/apis/meta/v1"ListMeta describes metadata that synthetic resources must have, including lists and various status objects. A resource may have only one of {ObjectMeta, ListMeta}.continue (string)continue may be set if the user set a limit on the number of items returned, and indicates that the server has more data available. The value is opaque and may be used to issue another request to the endpoint that served this list to retrieve the next set of available objects. Continuing a consistent list may not be possible if the server configuration has changed or more than a few minutes have passed. The resourceVersion field returned when using this continue value will be identical to the value in the first response, unless you have received this token from an error message.remainingItemCount (int64)remainingItemCount is the number of subsequent items in the list which are not included in this list response. If the list request contained label or field selectors, then the number of remaining items is unknown and the field will be left unset and omitted during serialization. If the list is complete (either because it is not chunking or because this is the last chunk), then there are no more remaining items and this field will be left unset and omitted during serialization. Servers older than v1.15 do not set this field. The intended use of the remainingItemCount is estimating the size of a collection. Clients should not rely on the remainingItemCount to be set or to be exact.resourceVersion (string)String that identifies the server's internal version of this object that can be used by clients to determine when objects have changed. Value must be treated as opaque by clients and passed unmodified back to the server. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistencyselfLink (string)Deprecated: selfLink is a legacy read-only field that is no longer populated by the system.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.
# Configuration APIs

Configuration APIsClient Authentication (v1)Client Authentication (v1beta1)Event Rate Limit Configuration (v1alpha1)Image Policy API (v1alpha1)kube-apiserver Admission (v1)kube-apiserver Audit Configuration (v1)kube-apiserver Configuration (v1)kube-apiserver Configuration (v1alpha1)kube-apiserver Configuration (v1beta1)kube-controller-manager Configuration (v1alpha1)kube-proxy Configuration (v1alpha1)kube-scheduler Configuration (v1)kubeadm Configuration (v1beta3)kubeadm Configuration (v1beta4)kubeconfig (v1)Kubelet Configuration (v1)Kubelet Configuration (v1alpha1)Kubelet Configuration (v1beta1)Kubelet CredentialProvider (v1)kuberc (v1alpha1)WebhookAdmission Configuration (v1)
# Kubernetes Issue Tracker

Kubernetes Issue TrackerTo report a security issue, please follow the Kubernetes security disclosure process.Work on Kubernetes code and public issues are tracked using GitHub Issues.Official list of known CVEs (security vulnerabilities) that have been announced by the Security Response CommitteeCVE-related GitHub issuesSecurity-related announcements are sent to the kubernetes-security-announce@googlegroups.com mailing list.
# Kubelet Checkpoint API

Kubelet Checkpoint APIFEATURE STATE: Kubernetes v1.30 [beta] (enabled by default: true)Checkpointing a container is the functionality to create a stateful copy of a running container. Once you have a stateful copy of a container, you could move it to a different computer for debugging or similar purposes.If you move the checkpointed container data to a computer that's able to restore it, that restored container continues to run at exactly the same point it was checkpointed. You can also inspect the saved data, provided that you have suitable tools for doing so.Creating a checkpoint of a container might have security implications. Typically a checkpoint contains all memory pages of all processes in the checkpointed container. This means that everything that used to be in memory is now available on the local disk. This includes all private data and possibly keys used for encryption. The underlying CRI implementations (the container runtime on that node) should create the checkpoint archive to be only accessible by the root user. It is still important to remember if the checkpoint archive is transferred to another system all memory pages will be readable by the owner of the checkpoint archive.Operationspost checkpoint the specified containerTell the kubelet to checkpoint a specific container from the specified Pod.Consult the Kubelet authentication/authorization reference for more information about how access to the kubelet checkpoint interface is controlled.The kubelet will request a checkpoint from the underlying CRI implementation. In the checkpoint request the kubelet will specify the name of the checkpoint archive as checkpoint-<podFullName>-<containerName>-<timestamp>.tar and also request to store the checkpoint archive in the checkpoints directory below its root directory (as defined by --root-dir). This defaults to /var/lib/kubelet/checkpoints.The checkpoint archive is in tar format, and could be listed using an implementation of tar. The contents of the archive depend on the underlying CRI implementation (the container runtime on that node).HTTP RequestPOST /checkpoint/{namespace}/{pod}/{container}Parametersnamespace (in path): string, requiredNamespacepod (in path): string, requiredPodcontainer (in path): string, requiredContainertimeout (in query): integerTimeout in seconds to wait until the checkpoint creation is finished. If zero or no timeout is specified the default CRI timeout value will be used. Checkpoint creation time depends directly on the used memory of the container. The more memory a container uses the more time is required to create the corresponding checkpoint.Response200: OK401: Unauthorized404: Not Found (if the ContainerCheckpoint feature gate is disabled)404: Not Found (if the specified namespace, pod or container cannot be found)500: Internal Server Error (if the CRI implementation encounter an error during checkpointing (see error message for further details))500: Internal Server Error (if the CRI implementation does not implement the checkpoint CRI API (see error message for further details))
# Installing Kubernetes with deployment tools

Installing Kubernetes with deployment toolsThere are many methods and tools for setting up your own production Kubernetes cluster. For example:kubeadmCluster API: A Kubernetes sub-project focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters.kops: An automated cluster provisioning tool. For tutorials, best practices, configuration options and information on reaching out to the community, please check the kOps website for details.kubespray: A composition of Ansible playbooks, inventory, provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. You can reach out to the community on Slack channel #kubespray.
# Concepts

The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your cluster, and helps you obtain a deeper understanding of how Kubernetes works.OverviewKubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.Cluster ArchitectureThe architectural concepts behind Kubernetes.ContainersTechnology for packaging an application along with its runtime dependencies.WorkloadsUnderstand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them.Services, Load Balancing, and NetworkingConcepts and resources behind networking in Kubernetes.StorageWays to provide both long-term and temporary storage to Pods in your cluster.ConfigurationResources that Kubernetes provides for configuring Pods.SecurityConcepts for keeping your cloud-native workload secure.PoliciesManage security and best-practices with policies.Scheduling, Preemption and EvictionCluster AdministrationLower-level detail relevant to creating or administering a Kubernetes cluster.Windows in KubernetesKubernetes supports nodes that run Microsoft Windows.Extending KubernetesDifferent ways to change the behavior of your Kubernetes cluster.
# Kubernetes API Aggregation Layer

Kubernetes API Aggregation LayerThe aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs. The additional APIs can either be ready-made solutions such as a metrics server, or APIs that you develop yourself.The aggregation layer is different from Custom Resource Definitions, which are a way to make the kube-apiserver recognise new kinds of object.Aggregation layerThe aggregation layer runs in-process with the kube-apiserver. Until an extension resource is registered, the aggregation layer will do nothing. To register an API, you add an APIService object, which "claims" the URL path in the Kubernetes API. At that point, the aggregation layer will proxy anything sent to that API path (e.g. /apis/myextension.mycompany.io/v1/…) to the registered APIService.The most common way to implement the APIService is to run an extension API server in Pod(s) that run in your cluster. If you're using the extension API server to manage resources in your cluster, the extension API server (also written as "extension-apiserver") is typically paired with one or more controllers. The apiserver-builder library provides a skeleton for both extension API servers and the associated controller(s).Response latencyExtension API servers should have low latency networking to and from the kube-apiserver. Discovery requests are required to round-trip from the kube-apiserver in five seconds or less.If your extension API server cannot achieve that latency requirement, consider making changes that let you meet it.What's nextTo get the aggregator working in your environment, configure the aggregation layer.Then, setup an extension api-server to work with the aggregation layer.Read about APIService in the API referenceLearn about Declarative Validation Concepts, an internal mechanism for defining validation rules that in the future will help support validation for extension API server development.Alternatively: learn how to extend the Kubernetes API using Custom Resource Definitions.
# Running Automated Tasks with a CronJob

Running Automated Tasks with a CronJobThis page shows how to run automated tasks using Kubernetes CronJob object.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 KubernetesCreating a CronJobCron jobs require a config file. Here is a manifest for a CronJob that runs a simple demonstration task every minute:application/job/cronjob.yaml apiVersion: batch/v1 kind: CronJob metadata: name: hello spec: schedule: "* * * * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox:1.28 imagePullPolicy: IfNotPresent command: - /bin/sh - -c - date; echo Hello from the Kubernetes cluster restartPolicy: OnFailure Run the example CronJob by using this command:kubectl create -f https://k8s.io/examples/application/job/cronjob.yaml The output is similar to this:cronjob.batch/hello created After creating the cron job, get its status using this command:kubectl get cronjob hello The output is similar to this:NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE hello */1 * * * * False 0 <none> 10s As you can see from the results of the command, the cron job has not scheduled or run any jobs yet. Watch for the job to be created in around one minute:kubectl get jobs --watch The output is similar to this:NAME COMPLETIONS DURATION AGE hello-4111706356 0/1 0s hello-4111706356 0/1 0s 0s hello-4111706356 1/1 5s 5s Now you've seen one running job scheduled by the "hello" cron job. You can stop watching the job and view the cron job again to see that it scheduled the job:kubectl get cronjob hello The output is similar to this:NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE hello */1 * * * * False 0 50s 75s You should see that the cron job hello successfully scheduled a job at the time specified in LAST SCHEDULE. There are currently 0 active jobs, meaning that the job has completed or failed.Now, find the pods that the last scheduled job created and view the standard output of one of the pods.Note:The job name is different from the pod name.# Replace "hello-4111706356" with the job name in your system pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name}) Show the pod log:kubectl logs $pods The output is similar to this:Fri Feb 22 11:02:09 UTC 2019 Hello from the Kubernetes cluster Deleting a CronJobWhen you don't need a cron job any more, delete it with kubectl delete cronjob <cronjob name>:kubectl delete cronjob hello Deleting the cron job removes all the jobs and pods it created and stops it from creating additional jobs. You can read more about removing jobs in garbage collection.
# Containers

ContainersTechnology for packaging an application along with its runtime dependencies.This page will discuss containers and container images, as well as their use in operations and solution development.The word container is an overloaded term. Whenever you use the word, check whether your audience uses the same definition.Each container that you run is repeatable; the standardization from having dependencies included means that you get the same behavior wherever you run it.Containers decouple applications from the underlying host infrastructure. This makes deployment easier in different cloud or OS environments.Each node in a Kubernetes cluster runs the containers that form the Pods assigned to that node. Containers in a Pod are co-located and co-scheduled to run on the same node.Container imagesA container image is a ready-to-run software package containing everything needed to run an application: the code and any runtime it requires, application and system libraries, and default values for any essential settings.Containers are intended to be stateless and immutable: you should not change the code of a container that is already running. If you have a containerized application and want to make changes, the correct process is to build a new image that includes the change, then recreate the container to start from the updated image.Container runtimesA fundamental component that empowers Kubernetes to run containers effectively. It is responsible for managing the execution and lifecycle of containers within the Kubernetes environment.Kubernetes supports container runtimes such as containerd, CRI-O, and any other implementation of the Kubernetes CRI (Container Runtime Interface).Usually, you can allow your cluster to pick the default container runtime for a Pod. If you need to use more than one container runtime in your cluster, you can specify the RuntimeClass for a Pod to make sure that Kubernetes runs those containers using a particular container runtime.You can also use RuntimeClass to run different Pods with the same container runtime but with different settings.Container EnvironmentContainer Lifecycle Hooks
# Event Rate Limit Configuration (v1alpha1)

Event Rate Limit Configuration (v1alpha1)Resource TypesConfigurationConfigurationConfiguration provides configuration for the EventRateLimit admission controller.FieldDescriptionapiVersionstringeventratelimit.admission.k8s.io/v1alpha1kindstringConfigurationlimits [Required][]Limitlimits are the limits to place on event queries received. Limits can be placed on events received server-wide, per namespace, per user, and per source+object. At least one limit is required.LimitAppears in:ConfigurationLimit is the configuration for a particular limit typeFieldDescriptiontype [Required]LimitTypetype is the type of limit to which this configuration appliesqps [Required]int32qps is the number of event queries per second that are allowed for this type of limit. The qps and burst fields are used together to determine if a particular event query is accepted. The qps determines how many queries are accepted once the burst amount of queries has been exhausted.burst [Required]int32burst is the burst number of event queries that are allowed for this type of limit. The qps and burst fields are used together to determine if a particular event query is accepted. The burst determines the maximum size of the allowance granted for a particular bucket. For example, if the burst is 10 and the qps is 3, then the admission control will accept 10 queries before blocking any queries. Every second, 3 more queries will be allowed. If some of that allowance is not used, then it will roll over to the next second, until the maximum allowance of 10 is reached.cacheSizeint32cacheSize is the size of the LRU cache for this type of limit. If a bucket is evicted from the cache, then the allowance for that bucket is reset. If more queries are later received for an evicted bucket, then that bucket will re-enter the cache with a clean slate, giving that bucket a full allowance of burst queries.The default cache size is 4096.If limitType is 'server', then cacheSize is ignored.LimitType(Alias of string)Appears in:LimitLimitType is the type of the limit (e.g., per-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.
# Updating Reference Documentation

Updating Reference DocumentationThe topics in this section document how to generate the Kubernetes reference guides.To build the reference documentation, see the following guide:Generating Reference Documentation QuickstartContributing to the Upstream Kubernetes CodeGenerating Reference Documentation for the Kubernetes APIGenerating Reference Documentation for kubectl CommandsGenerating Reference Documentation for MetricsGenerating Reference Pages for Kubernetes Components and Tools
# LocalObjectReference

LocalObjectReferenceLocalObjectReference contains enough information to let you locate the referenced object inside the same namespace.import "k8s.io/api/core/v1"LocalObjectReference contains enough information to let you locate the referenced object inside the same namespace.name (string)Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#namesThis 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.
# LabelSelector

LabelSelectorA label selector is a label query over a set of resources.import "k8s.io/apimachinery/pkg/apis/meta/v1"A label selector is a label query over a set of resources. The result of matchLabels and matchExpressions are ANDed. An empty label selector matches all objects. A null label selector matches no objects.matchExpressions ([]LabelSelectorRequirement)Atomic: will be replaced during a mergematchExpressions is a list of label selector requirements. The requirements are ANDed.A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.matchExpressions.key (string), requiredkey is the label key that the selector applies to.matchExpressions.operator (string), requiredoperator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.matchExpressions.values ([]string)Atomic: will be replaced during a mergevalues is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.matchLabels (map[string]string)matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.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.
# Viewing Site Analytics

Viewing Site AnalyticsThis page contains information about the kubernetes.io analytics dashboard.View the dashboard.This dashboard is built using Google Looker Studio and shows information collected on kubernetes.io using Google Analytics 4 since August 2022.Using the dashboardBy default, the dashboard shows all collected analytics for the past 30 days. Use the date selector to see data from a different date range. Other filtering options allow you to view data based on user location, the device used to access the site, the translation of the docs used, and more.If you notice an issue with this dashboard, or would like to request any improvements, please open an issue.
# Kubernetes Custom Metrics (v1beta2)

Kubernetes Custom Metrics (v1beta2)Package v1beta2 is the v1beta2 version of the custom_metrics API.Resource TypesMetricListOptionsMetricValueMetricValueListMetricListOptionsMetricListOptions is used to select metrics by their label selectorsFieldDescriptionapiVersionstringcustom.metrics.k8s.io/v1beta2kindstringMetricListOptionslabelSelectorstringA selector to restrict the list of returned objects by their labels. Defaults to everything.metricLabelSelectorstringA selector to restrict the list of returned metrics by their labelsMetricValueAppears in:MetricValueListMetricValue is the metric value for some objectFieldDescriptionapiVersionstringcustom.metrics.k8s.io/v1beta2kindstringMetricValuedescribedObject [Required]core/v1.ObjectReferencea reference to the described objectmetric [Required]MetricIdentifierNo description provided.timestamp [Required]meta/v1.Timeindicates the time at which the metrics were producedwindowSeconds [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 metric for thisMetricValueListMetricValueList is a list of values for a given metric for some set of objectsFieldDescriptionapiVersionstringcustom.metrics.k8s.io/v1beta2kindstringMetricValueListmetadata [Required]meta/v1.ListMetaNo description provided.items [Required][]MetricValuethe value of the metric across the described objectsMetricIdentifierAppears in:MetricValueMetricIdentifier identifies a metric by name and, optionally, selectorFieldDescriptionname [Required]stringname is the name of the given metricselectormeta/v1.LabelSelectorselector represents the label selector that could be used to select this metric, and will generally just be the selector passed in to the query used to fetch this metric. When left blank, only the metric's Name will be used to gather metrics.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.
# Service Resources

Service ResourcesServiceService is a named abstraction of software service (for example, mysql) consisting of local port (for example 3306) that the proxy listens on, and the selector that determines which pods will answer requests sent through the proxy.EndpointsEndpoints is a collection of endpoints that implement the actual service.EndpointSliceEndpointSlice represents a set of service endpoints.IngressIngress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend.IngressClassIngressClass represents the class of the Ingress, referenced by the Ingress Spec.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.