Masterbtc/Kubernetes_documentation huggingface dataset:
# Kubernetes API

Kubernetes APIKubernetes' API is the application that serves Kubernetes functionality through a RESTful interface and stores the state of the cluster.Kubernetes resources and "records of intent" are all stored as API objects, and modified via RESTful calls to the API. The API allows configuration to be managed in a declarative way. Users can interact with the Kubernetes API directly, or via tools like kubectl. The core Kubernetes API is flexible and can also be extended to support custom resources.Workload ResourcesService ResourcesConfig and Storage ResourcesAuthentication ResourcesAuthorization ResourcesPolicy ResourcesExtend ResourcesCluster ResourcesCommon DefinitionsOther ResourcesCommon Parameters
# Kubelet Configuration (v1alpha1)

Kubelet Configuration (v1alpha1)Resource TypesCredentialProviderConfigImagePullIntentImagePulledRecordCredentialProviderConfigCredentialProviderConfig is the configuration containing information about each exec credential provider. Kubelet reads this configuration from disk and enables each provider as specified by the CredentialProvider type.FieldDescriptionapiVersionstringkubelet.config.k8s.io/v1alpha1kindstringCredentialProviderConfigproviders [Required][]CredentialProviderproviders is a list of credential provider plugins that will be enabled by the kubelet. Multiple providers may match against a single image, in which case credentials from all providers will be returned to the kubelet. If multiple providers are called for a single image, the results are combined. If providers return overlapping auth keys, the value from the provider earlier in this list is attempted first.ImagePullIntentImagePullIntent is a record of the kubelet attempting to pull an image.FieldDescriptionapiVersionstringkubelet.config.k8s.io/v1alpha1kindstringImagePullIntentimage [Required]stringImage is the image spec from a Container's image field. The filename is a SHA-256 hash of this value. This is to avoid filename-unsafe characters like ':' and '/'.ImagePulledRecordImagePullRecord is a record of an image that was pulled by the kubelet.If there are no records in the kubernetesSecrets field and both nodeWideCredentials and anonymous are false, credentials must be re-checked the
# Scheduling Policies

Scheduling PoliciesIn Kubernetes versions before v1.23, a scheduling policy can be used to specify the predicates and priorities process. For example, you can set a scheduling policy by running kube-scheduler --policy-config-file <filename> or kube-scheduler --policy-configmap <ConfigMap>.This scheduling policy is not supported since Kubernetes v1.23. Associated flags policy-config-file, policy-configmap, policy-configmap-namespace and use-legacy-policy-config are also not supported. Instead, use the Scheduler Configuration to achieve similar behavior.What's nextLearn about schedulingLearn about kube-scheduler ConfigurationRead the kube-scheduler configuration reference (v1)
# Administration with kubeadm

Administration with kubeadmIf you don't yet have a cluster, visit bootstrapping clusters with kubeadm.The tasks in this section are aimed at people administering an existing cluster:Adding Linux worker nodesAdding Windows worker nodesUpgrading kubeadm clustersUpgrading Linux nodesUpgrading Windows nodesConfiguring a cgroup driverCertificate Management with kubeadmReconfiguring a kubeadm clusterChanging The Kubernetes Package Repository
# Guaranteed Scheduling For Critical Add-On Pods

Guaranteed Scheduling For Critical Add-On PodsKubernetes core components such as the API server, scheduler, and controller-manager run on a control plane node. However, add-ons must run on a regular cluster node. Some of these add-ons are critical to a fully functional cluster, such as metrics-server, DNS, and UI. A cluster may stop working properly if a critical add-on is evicted (either manually or as a side effect of another operation like upgrade) and becomes pending (for example when the cluster is highly utilized and either there are other pending pods that schedule into the space vacated by the evicted critical add-on pod or the amount of resources available on the node changed for some other reason).Note that marking a pod as critical is not meant to prevent evictions entirely; it only prevents the pod from becoming permanently unavailable. A static pod marked as critical can't be evicted. However, non-static pods marked as critical are always rescheduled.Marking pod as criticalTo mark a Pod as critical, set priorityClassName for that Pod to system-cluster-critical or system-node-critical. system-node-critical is the highest available priority, even higher than system-cluster-critical.
# Kubernetes z-pages

Kubernetes z-pagesProvides runtime diagnostics for Kubernetes components, offering insights into component runtime status and configuration flags.FEATURE STATE: Kubernetes v1.32 [alpha]Kubernetes core components can expose a suite of z-endpoints to make it easier for users to debug their cluster and its components. These endpoints are strictly to be used for human inspection to gain real time debugging information of a component binary. Avoid automated scraping of data returned by these endpoints; in Kubernetes 1.34 these are an alpha feature and the response format may change in future releases.z-pagesKubernetes v1.34 allows you to enable z-pages to help you troubleshoot problems with its core control plane components. These special debugging endpoints provide internal information about running components. For Kubernetes 1.34, components serve the following endpoints (when enabled):z-pagesstatuszflagzstatuszEnabled using the ComponentStatusz feature gate, the /statusz endpoint displays high level information about the component such as its Kubernetes version, emulation version, start time and more.The /statusz response from the API server is similar to:kube-apiserver statusz Warning: This endpoint is not meant to be machine parseable, has no formatting compatibility guarantees and is for debugging purposes only. Started: Wed Oct 16 21:03:43 UTC 2024 Up: 0 hr 00 min 16 sec Go version: go1.23.2 Binary version: 1.32.0-alpha.0.1484&#43;5eeac4f21a491b-dirty Emulation version: 1.32.0-alpha.0.1484 flagzEnabled using the ComponentFlagz feature gate, the /flagz endpoint shows you the command line arguments that were used to start a component.The /flagz data for the API server looks something like:kube-apiserver flags Warning: This endpoint is not meant to be machine parseable, has no formatting compatibility guarantees and is for debugging purposes only. advertise-address=192.168.8.2 contention-profiling=false enable-priority-and-fairness=true profiling=true authorization-mode=[Node,RBAC] authorization-webhook-cache-authorized-ttl=5m0s authorization-webhook-cache-unauthorized-ttl=30s authorization-webhook-version=v1beta1 default-watch-cache-size=100
# Use an HTTP Proxy to Access the Kubernetes API

Use an HTTP Proxy to Access the Kubernetes APIThis page shows how to use an HTTP proxy to access the Kubernetes API.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.If you do not already have an application running in your cluster, start a Hello world application by entering this command:kubectl create deployment hello-app --image=gcr.io/google-samples/hello-app:2.0 --port=8080 Using kubectl to start a proxy serverThis command starts a proxy to the Kubernetes API server:kubectl proxy --port=8080 Exploring the Kubernetes APIWhen the proxy server is running, you can explore the API using curl, wget, or a browser.Get the API versions:curl http://localhost:8080/api/ The output should look similar to this:{ "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "10.0.2.15:8443" } ] } Get a list of pods:curl http://localhost:8080/api/v1/namespaces/default/pods The output should look similar to this:{ "kind": "PodList", "apiVersion": "v1", "metadata": { "resourceVersion": "33074" }, "items": [ { "metadata": { "name": "kubernetes-bootcamp-2321272333-ix8pt", "generateName": "kubernetes-bootcamp-2321272333-", "namespace": "default", "uid": "ba21457c-6b1d-11e6-85f7-1ef9f1dab92b", "resourceVersion": "33003", "creationTimestamp": "2016-08-25T23:43:30Z", "labels": { "pod-template-hash": "2321272333", "run": "kubernetes-bootcamp" }, ... } What's nextLearn more about kubectl proxy.
# Windows in Kubernetes

Windows in KubernetesKubernetes supports nodes that run Microsoft Windows.Kubernetes supports worker nodes running either Linux or Microsoft Windows.🛇 This item links to a third party project or product that is not part of Kubernetes itself. More informationThe CNCF and its parent the Linux Foundation take a vendor-neutral approach towards compatibility. It is possible to join your Windows server as a worker node to a Kubernetes cluster.You can install and set up kubectl on Windows no matter what operating system you use within your cluster.If you are using Windows nodes, you can read:Networking On WindowsWindows Storage In KubernetesResource Management for Windows NodesConfigure RunAsUserName for Windows Pods and ContainersCreate A Windows HostProcess PodConfigure Group Managed Service Accounts for Windows Pods and ContainersSecurity For Windows NodesWindows Debugging TipsGuide for Scheduling Windows Containers in Kubernetesor, for an overview, read:Windows containers in KubernetesGuide for Running Windows Containers in KubernetesItems on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the CNCF website guidelines for more details.You should read the content guide before proposing a change that adds an extra third-party link.
# Common Parameters

Common ParametersallowWatchBookmarksallowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored.continueThe continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the
# Node metrics data

Node metrics dataMechanisms for accessing metrics at node, volume, pod and container level, as seen by the kubelet.The kubelet gathers metric statistics at the node, volume, pod and container level, and emits this information in the Summary API.You can send a proxied request to the stats summary API via the Kubernetes API server.Here is an example of a Summary API request for a node named minikube:kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary" Here is the same API call using curl:# You need to run "kubectl proxy" first # Change 8080 to the port that "kubectl proxy" assigns curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary Note:Beginning with metrics-server 0.6.x, metrics-server queries the /metrics/resource kubelet endpoint, and not /stats/summary.Summary metrics API sourceBy default, Kubernetes fetches node summary metrics data using an embedded cAdvisor that runs within the kubelet. If you enable the PodAndContainerStatsFromCRI feature gate in your cluster, and you use a container runtime that supports statistics access via Container Runtime Interface (CRI), then the kubelet fetches Pod- and container-level metric data using CRI, and not via cAdvisor.Pressure Stall Information (PSI)FEATURE STATE: Kubernetes v1.34 [beta]As a beta feature, Kubernetes lets you configure kubelet to collect Linux kernel Pressure Stall Information (PSI) for CPU, memory, and I/O usage. The information is collected at node, pod and container level. See Summary API for detailed schema. This feature is enabled by default, by setting the KubeletPSI feature gate. The information is also exposed in Prometheus metrics.You can learn how to interpret the PSI metrics in Understand PSI Metrics.RequirementsPressure Stall Information requires:Linux kernel versions 4.20 or later.cgroup v2What's nextThe task pages for Troubleshooting Clusters discuss how to use a metrics pipeline that rely on these data.
# Roles and responsibilities

Roles and responsibilitiesAnyone can contribute to Kubernetes. As your contributions to SIG Docs grow, you can apply for different levels of membership in the community. These roles allow you to take on more responsibility within the community. Each role requires more time and commitment. The roles are:Anyone: regular contributors to the Kubernetes documentationMembers: can assign and triage issues and provide non-binding review on pull requestsReviewers: can lead reviews on documentation pull requests and can vouch for a change's qualityApprovers: can lead reviews on documentation and merge changesAnyoneAnyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!Anyone can:Open an issue in any Kubernetes repository, including kubernetes/websiteGive non-binding
# Volume Health Monitoring

Volume Health MonitoringFEATURE STATE: Kubernetes v1.21 [alpha]CSI volume health monitoring allows CSI Drivers to detect abnormal volume conditions from the underlying storage systems and report them as events on PVCs or Pods.Volume health monitoringKubernetes volume health monitoring is part of how Kubernetes implements the Container Storage Interface (CSI). Volume health monitoring feature is implemented in two components: an External Health Monitor controller, and the kubelet.If a CSI Driver supports Volume Health Monitoring feature from the controller side, an event will be reported on the related PersistentVolumeClaim (PVC) when an abnormal volume condition is detected on a CSI volume.The External Health Monitor controller also watches for node failure events. You can enable node failure monitoring by setting the enable-node-watcher flag to true. When the external health monitor detects a node failure event, the controller reports an Event will be reported on the PVC to indicate that pods using this PVC are on a failed node.If a CSI Driver supports Volume Health Monitoring feature from the node side, an Event will be reported on every Pod using the PVC when an abnormal volume condition is detected on a CSI volume. In addition, Volume Health information is exposed as Kubelet VolumeStats metrics. A new metric kubelet_volume_stats_health_status_abnormal is added. This metric includes two labels: namespace and persistentvolumeclaim. The count is either 1 or 0. 1 indicates the volume is unhealthy, 0 indicates volume is healthy. For more information, please check KEP.Note:You need to enable the CSIVolumeHealth feature gate to use this feature from the node side.What's nextSee the CSI driver documentation to find out which CSI drivers have implemented this feature.
# CronJob

CronJobCronJob represents the configuration of a single cron job.apiVersion: batch/v1import "k8s.io/api/batch/v1"CronJobCronJob represents the configuration of a single cron job.apiVersion: batch/v1kind: CronJobmetadata (ObjectMeta)Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadataspec (CronJobSpec)Specification of the desired behavior of a cron job, including the schedule. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-statusstatus (CronJobStatus)Current status of a cron job. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-statusCronJobSpecCronJobSpec describes how the job execution will look like and when it will actually run.jobTemplate (JobTemplateSpec), requiredSpecifies the job that will be created when executing a CronJob.JobTemplateSpec describes the data a Job should have when created from a templatejobTemplate.metadata (ObjectMeta)Standard object's metadata of the jobs created from this template. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadatajobTemplate.spec (JobSpec)Specification of the desired behavior of the job. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-statusschedule (string), requiredThe schedule in Cron format, see https://en.wikipedia.org/wiki/Cron.timeZone (string)The time zone name for the given schedule, see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones. If not specified, this will default to the time zone of the kube-controller-manager process. The set of valid time zone names and the time zone offset is loaded from the system-wide time zone database by the API server during CronJob validation and the controller manager during execution. If no system-wide time zone database can be found a bundled version of the database is used instead. If the time zone name becomes invalid during the lifetime of a CronJob or due to a change in host configuration, the controller will stop creating new new Jobs and will create a system event with the reason UnknownTimeZone. More information can be found in https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#time-zonesconcurrencyPolicy (string)Specifies how to treat concurrent executions of a Job. Valid values are:"Allow" (default): allows CronJobs to run concurrently; - "Forbid": forbids concurrent runs, skipping
# SelfSubjectReview

SelfSubjectReviewSelfSubjectReview contains the user information that the kube-apiserver has about the user making this request.apiVersion: authentication.k8s.io/v1import "k8s.io/api/authentication/v1"SelfSubjectReviewSelfSubjectReview contains the user information that the kube-apiserver has about the user making this request. When using impersonation, users will receive the user info of the user being impersonated. If impersonation or request header authentication is used, any extra keys will have their case ignored and returned as lowercase.apiVersion: authentication.k8s.io/v1kind: SelfSubjectReviewmetadata (ObjectMeta)Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadatastatus (SelfSubjectReviewStatus)Status is filled in by the server with the user attributes.SelfSubjectReviewStatusSelfSubjectReviewStatus is filled by the kube-apiserver and sent back to a user.userInfo (UserInfo)User attributes of the user making this request.UserInfo holds the information about the user needed to implement the user.Info interface.userInfo.extra (map[string][]string)Any additional information provided by the authenticator.userInfo.groups ([]string)Atomic: will be replaced during a mergeThe names of groups this user is a part of.userInfo.uid (string)A unique value that identifies this user across time. If this user is deleted and another user by the same name is added, they will have different UIDs.userInfo.username (string)The name that uniquely identifies this user among all active users.Operationscreate create a SelfSubjectReviewHTTP RequestPOST /apis/authentication.k8s.io/v1/selfsubjectreviewsParametersbody: SelfSubjectReview, requireddryRun (in query): stringdryRunfieldManager (in query): stringfieldManagerfieldValidation (in query): stringfieldValidationpretty (in query): stringprettyResponse200 (SelfSubjectReview): OK201 (SelfSubjectReview): Created202 (SelfSubjectReview): 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.
# Introduction to kubectl

Introduction to kubectlkubectl is the Kubernetes cli version of a swiss army knife, and can do many things.While this Book is focused on using kubectl to declaratively manage applications in Kubernetes, it also covers other kubectl functions.Command FamiliesMost kubectl commands typically fall into one of a few categories:TypeUsed ForDescriptionDeclarative Resource ManagementDeployment and operations (e.g. GitOps)Declaratively manage Kubernetes workloads using resource configurationImperative Resource ManagementDevelopment OnlyRun commands to manage Kubernetes workloads using Command Line arguments and flagsPrinting Workload StateDebuggingPrint information about workloadsInteracting with ContainersDebuggingExec, attach, cp, logsCluster ManagementCluster operationsDrain and cordon NodesDeclarative Application ManagementThe preferred approach for managing resources is through declarative files called resource configuration used with the kubectl Apply command. This command reads a local (or remote) file structure and modifies cluster state to reflect the declared intent.ApplyApply is the preferred mechanism for managing resources in a Kubernetes cluster.Printing State about WorkloadsUsers will need to view workload state.Printing summarize state and information about resourcesPrinting complete state and information about resourcesPrinting specific fields from resourcesQuery resources matching labelsDebugging Workloadskubectl supports debugging by providing commands for:Printing Container logsPrinting cluster eventsExec or attaching to a ContainerCopying files from Containers in the cluster to a user's filesystemCluster ManagementOn occasion, users may need to perform operations to the Nodes of cluster. kubectl supports commands to drain workloads from a Node so that it can be decommissioned or debugged.PorcelainUsers may find using resource configuration overly verbose for development and prefer to work with the cluster imperatively with a shell-like workflow. kubectl offers porcelain commands for generating and modifying resources.Generating + creating resources such as Deployments, StatefulSets, Services, ConfigMaps, etc.Setting fields on resourcesEditing (live) resources in a text editorPorcelain for Dev OnlyPorcelain commands are time saving for experimenting with workloads in a dev cluster, but shouldn't be used for production.
# Image Policy API (v1alpha1)

Image Policy API (v1alpha1)Resource TypesImageReviewImageReviewImageReview checks if the set of images in a pod are allowed.FieldDescriptionapiVersionstringimagepolicy.k8s.io/v1alpha1kindstringImageReviewmetadatameta/v1.ObjectMetaStandard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadataRefer to the Kubernetes API documentation for the fields of the metadata field.spec [Required]ImageReviewSpecSpec holds information about the pod being evaluatedstatusImageReviewStatusStatus is filled in by the backend and indicates whether the pod should be allowed.ImageReviewContainerSpecAppears in:ImageReviewSpecImageReviewContainerSpec is a description of a container within the pod creation request.FieldDescriptionimagestringThis can be in the form image:tag or image@SHA:012345679abcdef.ImageReviewSpecAppears in:ImageReviewImageReviewSpec is a description of the pod creation request.FieldDescriptioncontainers[]ImageReviewContainerSpecContainers is a list of a subset of the information in each container of the Pod being created.annotationsmap[string]stringAnnotations is a list of key-value pairs extracted from the Pod's annotations. It only includes keys which match the pattern *.image-policy.k8s.io/*. It is up to each webhook backend to determine how to interpret these annotations, if at all.namespacestringNamespace is the namespace the pod is being created in.ImageReviewStatusAppears in:ImageReviewImageReviewStatus is the result of the review for the pod creation request.FieldDescriptionallowed [Required]boolAllowed indicates that all images were allowed to be run.reasonstringReason should be empty unless Allowed is false in which case it may contain a short description of what is wrong. Kubernetes may truncate excessively long errors when displaying to the user.auditAnnotationsmap[string]stringAuditAnnotations will be added to the attributes object of the admission controller request using 'AddAnnotation'. The keys should be prefix-less (i.e., the admission controller will add an appropriate prefix).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.
# Workload Management

Workload ManagementKubernetes provides several built-in APIs for declarative management of your workloads and the components of those workloads.Ultimately, your applications run as containers inside Pods; however, managing individual Pods would be a lot of effort. For example, if a Pod fails, you probably want to run a new Pod to replace it. Kubernetes can do that for you.You use the Kubernetes API to create a workload object that represents a higher abstraction level than a Pod, and then the Kubernetes control plane automatically manages Pod objects on your behalf, based on the specification for the workload object you defined.The built-in APIs for managing workloads are:Deployment (and, indirectly, ReplicaSet), the most common way to run an application on your cluster. Deployment is a good fit for managing a stateless application workload on your cluster, where any Pod in the Deployment is interchangeable and can be replaced if needed. (Deployments are a replacement for the legacy ReplicationController API).A StatefulSet lets you manage one or more Pods – all running the same application code – where the Pods rely on having a distinct identity. This is different from a Deployment where the Pods are expected to be interchangeable. The most common use for a StatefulSet is to be able to make a link between its Pods and their persistent storage. For example, you can run a StatefulSet that associates each Pod with a PersistentVolume. If one of the Pods in the StatefulSet fails, Kubernetes makes a replacement Pod that is connected to the same PersistentVolume.A DaemonSet defines Pods that provide facilities that are local to a specific node; for example, a driver that lets containers on that node access a storage system. You use a DaemonSet when the driver, or other node-level service, has to run on the node where it's useful. Each Pod in a DaemonSet performs a role similar to a system daemon on a classic Unix / POSIX server. A DaemonSet might be fundamental to the operation of your cluster, such as a plugin to let that node access cluster networking, it might help you to manage the node, or it could provide less essential facilities that enhance the container platform you are running. You can run DaemonSets (and their pods) across every node in your cluster, or across just a subset (for example, only install the GPU accelerator driver on nodes that have a GPU installed).You can use a Job and / or a CronJob to define tasks that run to completion and then stop. A Job represents a one-off task, whereas each CronJob repeats according to a schedule.Other topics in this section:Automatic Cleanup for Finished JobsReplicationController
# Resource Management for Windows nodes

Resource Management for Windows nodesThis page outlines the differences in how resources are managed between Linux and Windows.On Linux nodes, cgroups are used as a pod boundary for resource control. Containers are created within that boundary for network, process and file system isolation. The Linux cgroup APIs can be used to gather CPU, I/O, and memory use statistics.In contrast, Windows uses a job object per container with a system namespace filter to contain all processes in a container and provide logical isolation from the host. (Job objects are a Windows process isolation mechanism and are different from what Kubernetes refers to as a Job).There is no way to run a Windows container without the namespace filtering in place. This means that system privileges cannot be asserted in the context of the host, and thus privileged containers are not available on Windows. Containers cannot assume an identity from the host because the Security Account Manager (SAM) is separate.Memory managementWindows does not have an out-of-memory process killer as Linux does. Windows always treats all user-mode memory allocations as virtual, and pagefiles are mandatory.Windows nodes do not overcommit memory for processes. The net effect is that Windows won't reach out of memory conditions the same way Linux does, and processes page to disk instead of being subject to out of memory (OOM) termination. If memory is over-provisioned and all physical memory is exhausted, then paging can slow down performance.CPU managementWindows can limit the amount of CPU time allocated for different processes but cannot guarantee a minimum amount of CPU time.On Windows, the kubelet supports a command-line flag to set the scheduling priority of the kubelet process: --windows-priorityclass. This flag allows the kubelet process to get more CPU time slices when compared to other processes running on the Windows host. More information on the allowable values and their meaning is available at Windows Priority Classes. To ensure that running Pods do not starve the kubelet of CPU cycles, set this flag to ABOVE_NORMAL_PRIORITY_CLASS or above.Resource reservationTo account for memory and CPU used by the operating system, the container runtime, and by Kubernetes host processes such as the kubelet, you can (and should) reserve memory and CPU resources with the --kube-reserved and/or --system-reserved kubelet flags. On Windows these values are only used to calculate the node's allocatable resources.Caution:As you deploy workloads, set resource memory and CPU limits on containers. This also subtracts from NodeAllocatable and helps the cluster-wide scheduler in determining which pods to place on which nodes.Scheduling pods without limits may over-provision the Windows nodes and in extreme cases can cause the nodes to become unhealthy.On Windows, a good practice is to reserve at least 2GiB of memory.To determine how much CPU to reserve, identify the maximum pod density for each node and monitor the CPU usage of the system services running there, then choose a value that meets your workload needs.
# Use Antrea for NetworkPolicy

Use Antrea for NetworkPolicyThis page shows how to install and use Antrea CNI plugin on Kubernetes. For background on Project Antrea, read the Introduction to Antrea.Before you beginYou need to have a Kubernetes cluster. Follow the kubeadm getting started guide to bootstrap one.Deploying Antrea with kubeadmFollow Getting Started guide to deploy Antrea for kubeadm.What's nextOnce your cluster is running, you can follow the Declare Network Policy to try out Kubernetes NetworkPolicy.
# TypedLocalObjectReference

TypedLocalObjectReferenceTypedLocalObjectReference contains enough information to let you locate the typed referenced object inside the same namespace.import "k8s.io/api/core/v1"TypedLocalObjectReference contains enough information to let you locate the typed referenced object inside the same namespace.kind (string), requiredKind is the type of resource being referencedname (string), requiredName is the name of resource being referencedapiGroup (string)APIGroup is the group for the resource being referenced. If APIGroup is not specified, the specified Kind must be in the core API group. For any other third-party types, APIGroup is required.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.
# Extend Kubernetes

Extend KubernetesUnderstand advanced ways to adapt your Kubernetes cluster to the needs of your work environment.Configure the Aggregation LayerUse Custom ResourcesSet up an Extension API ServerConfigure Multiple SchedulersUse an HTTP Proxy to Access the Kubernetes APIUse a SOCKS5 Proxy to Access the Kubernetes APISet up Konnectivity service
# Helping as a blog writing buddy

Helping as a blog writing buddyThere are two official Kubernetes blogs, and the CNCF has its own blog where you can cover Kubernetes too. Read contributing to Kubernetes blogs to learn about these two blogs.When people contribute to either blog as an author, the Kubernetes project pairs up authors as writing buddies. This page explains how to fulfil the buddy role.You should make sure that you have at least read an outline of article submission before you read on within this page.Buddy responsibilitiesAs a writing buddy, you:help the blog team get articles ready to merge and to publishsupport your buddy to produce content that is good to mergeprovide a review on the article that your buddy has writtenWhen the team pairs you up with another author, the idea is that you both support each other by reviewing the other author's draft article. Most people reading articles on the Kubernetes blog are not experts; the content should try to make sense for that audience, or at least to support non-expert readers appropriately.The blog team are also there to help you both along the journey from draft to publication. They will either be directly able to approve your article for publication, or can arrange for the approval to happen.Supporting the blog teamYour main responsibility here is to communicate about your capacity, availability and progress in a reasonable timeline. If many weeks go by and your buddy hasn't heard from you, it makes the overall work take more time.Supporting your buddyThere are two parts to the process(This is the recommended option)The blog team recommend that the main author for the article sets up collaborative editing using either a Google Doc or HackMD (their choice). The main author then shares that document with the following people:Any co-authorsYou (their writing buddy)Ideally, with a nominated person from the blog team.As a writing buddy, you then read the draft text and either directly make suggestions or provide
# Compatibility Version For Kubernetes Control Plane Components

Compatibility Version For Kubernetes Control Plane ComponentsSince release v1.32, we introduced configurable version compatibility and emulation options to Kubernetes control plane components to make upgrades safer by providing more control and increasing the granularity of steps available to cluster administrators.Emulated VersionThe emulation option is set by the --emulated-version flag of control plane components. It allows the component to emulate the behavior (APIs, features, ...) of an earlier version of Kubernetes.When used, the capabilities available will match the emulated version:Any capabilities present in the binary version that were introduced after the emulation version will be unavailable.Any capabilities removed after the emulation version will be available.This enables a binary from a particular Kubernetes release to emulate the behavior of a previous version with sufficient fidelity that interoperability with other system components can be defined in terms of the emulated version.The --emulated-version must be <= binaryVersion. See the help message of the --emulated-version flag for supported range of emulated versions.
# Configure Pod Initialization

Configure Pod InitializationThis page shows how to use an Init Container to initialize a Pod before an application Container runs.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.Create a Pod that has an Init ContainerIn this exercise you create a Pod that has one application Container and one Init Container. The init container runs to completion before the application container starts.Here is the configuration file for the Pod:pods/init-containers.yaml apiVersion: v1 kind: Pod metadata: name: init-demo spec: containers: - name: nginx image: nginx ports: - containerPort: 80 volumeMounts: - name: workdir mountPath: /usr/share/nginx/html # These containers are run during pod initialization initContainers: - name: install image: busybox:1.28 command: - wget - "-O" - "/work-dir/index.html" - http://info.cern.ch volumeMounts: - name: workdir mountPath: "/work-dir" dnsPolicy: Default volumes: - name: workdir emptyDir: {} In the configuration file, you can see that the Pod has a Volume that the init container and the application container share.The init container mounts the shared Volume at /work-dir, and the application container mounts the shared Volume at /usr/share/nginx/html. The init container runs the following command and then terminates:wget -O /work-dir/index.html http://info.cern.ch Notice that the init container writes the index.html file in the root directory of the nginx server.Create the Pod:kubectl apply -f https://k8s.io/examples/pods/init-containers.yaml Verify that the nginx container is running:kubectl get pod init-demo The output shows that the nginx container is running:NAME READY STATUS RESTARTS AGE init-demo 1/1 Running 0 1m Get a shell into the nginx container running in the init-demo Pod:kubectl exec -it init-demo -- /bin/bash In your shell, send a GET request to the nginx server:root@nginx:~# apt-get update root@nginx:~# apt-get install curl root@nginx:~# curl localhost The output shows that nginx is serving the web page that was written by the init container:<html><head></head><body><header> <title>http://info.cern.ch</title> </header> <h1>http://info.cern.ch - home of the first website</h1> ... <li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li> ... What's nextLearn more about communicating between Containers running in the same Pod.Learn more about Init Containers.Learn more about Volumes.Learn more about Debugging Init Containers
# Enforce Pod Security Standards by Configuring the Built-in Admission Controller

Enforce Pod Security Standards by Configuring the Built-in Admission ControllerKubernetes provides a built-in admission controller to enforce the Pod Security Standards. You can configure this admission controller to set cluster-wide defaults and exemptions.Before you beginFollowing an alpha release in Kubernetes v1.22, Pod Security Admission became available by default in Kubernetes v1.23, as a beta. From version 1.25 onwards, Pod Security Admission is generally available.To check the version, enter kubectl version.If you are not running Kubernetes 1.34, you can switch to viewing this page in the documentation for the Kubernetes version that you are running.Configure the Admission ControllerNote:pod-security.admission.config.k8s.io/v1 configuration requires v1.25+. For v1.23 and v1.24, use v1beta1. For v1.22, use v1alpha1.apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration plugins: - name: PodSecurity configuration: apiVersion: pod-security.admission.config.k8s.io/v1 # see compatibility note kind: PodSecurityConfiguration # Defaults applied when a mode label is not set. # # Level label values must be one of: # - "privileged" (default) # - "baseline" # - "restricted" # # Version label values must be one of: # - "latest" (default) # - specific version like "v1.34" defaults: enforce: "privileged" enforce-version: "latest" audit: "privileged" audit-version: "latest" warn: "privileged" warn-version: "latest" exemptions: # Array of authenticated usernames to exempt. usernames: [] # Array of runtime class names to exempt. runtimeClasses: [] # Array of namespaces to exempt. namespaces: [] Note:The above manifest needs to be specified via the --admission-control-config-file to kube-apiserver.
# Documentation Content Guide

Documentation Content GuideThis page contains guidelines for Kubernetes documentation.If you have questions about what's allowed, join the #sig-docs channel in Kubernetes Slack and ask!You can register for Kubernetes Slack at https://slack.k8s.io/.For information on creating new content for the Kubernetes docs, follow the style guide.OverviewSource for the Kubernetes website, including the docs, resides in the kubernetes/website repository.Located in the kubernetes/website/content/<language_code>/docs folder, the majority of Kubernetes documentation is specific to the Kubernetes project.What's allowedKubernetes docs allow content for third-party projects only when:Content documents software in the Kubernetes projectContent documents software that's out of project but necessary for Kubernetes to functionContent is canonical on kubernetes.io, or links to canonical content elsewhereThird party contentKubernetes documentation includes applied examples of projects in the Kubernetes project—projects that live in the kubernetes and kubernetes-sigs GitHub organizations.Links to active content in the Kubernetes project are always allowed.Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker), networking policy (CNI plugins), Ingress controllers, and logging.Docs can link to third-party open source software (OSS) outside the Kubernetes project only if it's necessary for Kubernetes to function.Dual sourced contentWherever possible, Kubernetes docs link to canonical sources instead of hosting dual-sourced content.Dual-sourced content requires double the effort (or more!) to maintain and grows stale more quickly.Note:If you're a maintainer for a Kubernetes project and need help hosting your own docs, ask for help in #sig-docs on Kubernetes Slack.More informationIf you have questions about allowed content, join the Kubernetes Slack #sig-docs channel and ask!What's nextRead the Style guide.
# Manage Kubernetes Objects

Manage Kubernetes ObjectsDeclarative and imperative paradigms for interacting with the Kubernetes API.Declarative Management of Kubernetes Objects Using Configuration FilesDeclarative Management of Kubernetes Objects Using KustomizeManaging Kubernetes Objects Using Imperative CommandsImperative Management of Kubernetes Objects Using Configuration FilesUpdate API Objects in Place Using kubectl patchUse kubectl patch to update Kubernetes API objects in place. Do a strategic merge patch or a JSON merge patch.Migrate Kubernetes Objects Using Storage Version Migration
# Coarse Parallel Processing Using a Work Queue

Coarse Parallel Processing Using a Work QueueIn this example, you will run a Kubernetes Job with multiple parallel worker processes.In this example, as each pod is created, it picks up one unit of work from a task queue, completes it, deletes it from the queue, and exits.Here is an overview of the steps in this example:Start a message queue service. In this example, you use RabbitMQ, but you could use another one. In practice you would set up a message queue service once and reuse it for many jobs.Create a queue, and fill it with messages. Each message represents one task to be done. In this example, a message is an integer that we will do a lengthy computation on.Start a Job that works on tasks from the queue. The Job starts several pods. Each pod takes one task from the message queue, processes it, and exits.Before you beginYou should already be familiar with the basic, non-parallel, use of Job.You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. 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 KubernetesYou will need a container image registry where you can upload images to run in your cluster.This task example also assumes that you have Docker installed locally.Starting a message queue serviceThis example uses RabbitMQ, however, you can adapt the example to use another AMQP-type message service.In practice you could set up a message queue service once in a cluster and reuse it for many jobs, as well as for long-running services.Start RabbitMQ as follows:# make a Service for the StatefulSet to use kubectl create -f https://kubernetes.io/examples/application/job/rabbitmq/rabbitmq-service.yaml service "rabbitmq-service" created kubectl create -f https://kubernetes.io/examples/application/job/rabbitmq/rabbitmq-statefulset.yaml statefulset "rabbitmq" created Testing the message queue serviceNow, we can experiment with accessing the message queue. We will create a temporary interactive pod, install some tools on it, and experiment with queues.First create a temporary interactive Pod.# Create a temporary interactive container kubectl run -i --tty temp --image ubuntu:22.04 Waiting for pod default/temp-loe07 to be running, status is Pending, pod ready: false ... [ previous line repeats several times .. hit return when it stops ] ... Note that your pod name and command prompt will be different.
# Other Tools

Other ToolsKubernetes contains several tools to help you work with the Kubernetes system.crictlcrictl is a command-line interface for inspecting and debugging CRI-compatible container runtimes.DashboardDashboard, the web-based user interface of Kubernetes, allows you to deploy containerized applications to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself.Helm🛇 This item links to a third party project or product that is not part of Kubernetes itself. More informationHelm is a tool for managing packages of pre-configured Kubernetes resources. These packages are known as Helm charts.Use Helm to:Find and use popular software packaged as Kubernetes chartsShare your own applications as Kubernetes chartsCreate reproducible builds of your Kubernetes applicationsIntelligently manage your Kubernetes manifest filesManage releases of Helm packagesKomposeKompose is a tool to help Docker Compose users move to Kubernetes.Use Kompose to:Translate a Docker Compose file into Kubernetes objectsGo from local Docker development to managing your application via KubernetesConvert v1 or v2 Docker Compose yaml files or Distributed Application BundlesKuiKui is a GUI tool that takes your normal kubectl command line requests and responds with graphics.Kui takes the normal kubectl command line requests and responds with graphics. Instead of ASCII tables, Kui provides a GUI rendering with tables that you can sort.Kui lets you:Directly click on long, auto-generated resource names instead of copying and pastingType in kubectl commands and see them execute, even sometimes faster than kubectl itselfQuery a Job and see its execution rendered as a waterfall diagramClick through resources in your cluster using a tabbed UIMinikubeminikube is a tool that runs a single-node Kubernetes cluster locally on your workstation for development and testing purposes.Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the CNCF website guidelines for more details.You should read the content guide before proposing a change that adds an extra third-party link.