Masterbtc/Kubernetes_documentation huggingface dataset:
# Tutorials

This section of the Kubernetes documentation contains tutorials. A tutorial shows how to accomplish a goal that is larger than a single task. Typically a tutorial has several sections, each of which has a sequence of steps. Before walking through each tutorial, you may want to bookmark the Standardized Glossary page for later references.BasicsKubernetes Basics is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features.Introduction to Kubernetes (edX)Hello MinikubeConfigurationConfiguring Redis Using a ConfigMapAuthoring PodsAdopting Sidecar ContainersStateless ApplicationsExposing an External IP Address to Access an Application in a ClusterExample: Deploying PHP Guestbook application with RedisStateful ApplicationsStatefulSet BasicsExample: WordPress and MySQL with Persistent VolumesExample: Deploying Cassandra with Stateful SetsRunning ZooKeeper, A CP Distributed SystemServicesConnecting Applications with ServicesUsing Source IPSecurityApply Pod Security Standards at Cluster levelApply Pod Security Standards at Namespace levelRestrict a Container's Access to Resources with AppArmorSeccompCluster ManagementConfiguring Swap Memory on Kubernetes NodesRunning Kubelet in Standalone ModeInstall Drivers and Allocate Devices with DRAWhat's nextIf you would like to write a tutorial, see Content Page Types for information about the tutorial page type.
# Reference

This section of the Kubernetes documentation contains references.API ReferenceGlossary - a comprehensive, standardized list of Kubernetes terminologyKubernetes API ReferenceOne-page API Reference for Kubernetes v1.34Using The Kubernetes API - overview of the API for Kubernetes.API access control - details on how Kubernetes controls API accessWell-Known Labels, Annotations and TaintsOfficially supported client librariesTo call the Kubernetes API from a programming language, you can use client libraries. Officially supported client libraries:Kubernetes Go client libraryKubernetes Python client libraryKubernetes Java client libraryKubernetes JavaScript client libraryKubernetes C# client libraryKubernetes Haskell client libraryCLIkubectl - Main CLI tool for running commands and managing Kubernetes clusters.JSONPath - Syntax guide for using JSONPath expressions with kubectl.kubeadm - CLI tool to easily provision a secure Kubernetes cluster.Componentskubelet - The primary agent that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy.kube-apiserver - REST API that validates and configures data for API objects such as pods, services, replication controllers.kube-controller-manager - Daemon that embeds the core control loops shipped with Kubernetes.kube-proxy - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends.kube-scheduler - Scheduler that manages availability, performance, and capacity.Scheduler PoliciesScheduler ProfilesList of ports and protocols that should be open on control plane and worker nodesConfig APIsThis section hosts the documentation for "unpublished" APIs which are used to configure kubernetes components or tools. Most of these APIs are not exposed by the API server in a RESTful way though they are essential for a user or an operator to use or manage a cluster.kubeconfig (v1)kuberc (v1alpha1)kube-apiserver admission (v1)kube-apiserver configuration (v1alpha1) andkube-apiserver configuration (v1beta1) and kube-apiserver configuration (v1)kube-apiserver event rate limit (v1alpha1)kubelet configuration (v1alpha1) and kubelet configuration (v1beta1) kubelet configuration (v1)kubelet credential providers (v1) kube-scheduler configuration (v1)kube-controller-manager configuration (v1alpha1)kube-proxy configuration (v1alpha1)audit.k8s.io/v1 APIClient authentication API (v1beta1) and Client authentication API (v1)WebhookAdmission configuration (v1)ImagePolicy API (v1alpha1)Config API for kubeadmv1beta3v1beta4External APIsThese are the APIs defined by the Kubernetes project, but are not implemented by the core project:Metrics API (v1beta1)Custom Metrics API (v1beta2)External Metrics API (v1beta1)Design DocsAn archive of the design docs for Kubernetes functionality. Good starting points are Kubernetes Architecture and Kubernetes Design Overview.
# Use Kube-router for NetworkPolicy

Use Kube-router for NetworkPolicyThis page shows how to use Kube-router for NetworkPolicy.Before you beginYou need to have a Kubernetes cluster running. If you do not already have a cluster, you can create one by using any of the cluster installers like Kops, Bootkube, Kubeadm etc.Installing Kube-router addonThe Kube-router Addon comes with a Network Policy Controller that watches Kubernetes API server for any NetworkPolicy and pods updated and configures iptables rules and ipsets to allow or block traffic as directed by the policies. Please follow the trying Kube-router with cluster installers guide to install Kube-router addon.What's nextOnce you have installed the Kube-router addon, you can follow the Declare Network Policy to try out Kubernetes NetworkPolicy.
# Windows Storage

Windows StorageThis page provides an storage overview specific to the Windows operating system.Persistent storageWindows has a layered filesystem driver to mount container layers and create a copy filesystem based on NTFS. All file paths in the container are resolved only within the context of that container.With Docker, volume mounts can only target a directory in the container, and not an individual file. This limitation does not apply to containerd.Volume mounts cannot project files or directories back to the host filesystem.Read-only filesystems are not supported because write access is always required for the Windows registry and SAM database. However, read-only volumes are supported.Volume user-masks and permissions are not available. Because the SAM is not shared between the host & container, there's no mapping between them. All permissions are resolved within the context of the container.As a result, the following storage functionality is not supported on Windows nodes:Volume subpath mounts: only the entire volume can be mounted in a Windows containerSubpath volume mounting for SecretsHost mount projectionRead-only root filesystem (mapped volumes still support readOnly)Block device mappingMemory as the storage medium (for example, emptyDir.medium set to Memory)File system features like uid/gid; per-user Linux filesystem permissionsSetting secret permissions with DefaultMode (due to UID/GID dependency)NFS based storage/volume supportExpanding the mounted volume (resizefs)Kubernetes volumes enable complex applications, with data persistence and Pod volume sharing requirements, to be deployed on Kubernetes. Management of persistent volumes associated with a specific storage back-end or protocol includes actions such as provisioning/de-provisioning/resizing of volumes, attaching/detaching a volume to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod that needs to persist data.Volume management components are shipped as Kubernetes volume plugin. The following broad classes of Kubernetes volume plugins are supported on Windows:FlexVolume pluginsPlease note that FlexVolumes have been deprecated as of 1.23CSI PluginsIn-tree volume pluginsThe following in-tree plugins support persistent storage on Windows nodes:azureFilevsphereVolume
# Extending the Kubernetes API

Extending the Kubernetes APICustom resources are extensions of the Kubernetes API. Kubernetes provides two ways to add custom resources to your cluster:The CustomResourceDefinition (CRD) mechanism allows you to declaratively define a new custom API with an API group, kind, and schema that you specify. The Kubernetes control plane serves and handles the storage of your custom resource. CRDs allow you to create new types of resources for your cluster without writing and running a custom API server.The aggregation layer sits behind the primary API server, which acts as a proxy. This arrangement is called API Aggregation (AA), which allows you to provide specialized implementations for your custom resources by writing and deploying your own API server. The main API server delegates requests to your API server for the custom APIs that you specify, making them available to all of its clients.Custom ResourcesKubernetes API Aggregation Layer
# kubectl reference

kubectl referencekubectlkubectl annotatekubectl api-resourceskubectl api-versionskubectl applykubectl attachkubectl authkubectl autoscalekubectl certificatekubectl cluster-infokubectl completionkubectl configkubectl cordonkubectl cpkubectl createkubectl debugkubectl deletekubectl describekubectl diffkubectl drainkubectl editkubectl eventskubectl execkubectl explainkubectl exposekubectl getkubectl kustomizekubectl labelkubectl logskubectl optionskubectl patchkubectl pluginkubectl port-forwardkubectl proxykubectl replacekubectl rolloutkubectl runkubectl scalekubectl setkubectl taintkubectl topkubectl uncordonkubectl versionkubectl wait
# Suggesting content improvements

Suggesting content improvementsIf you notice an issue with Kubernetes documentation or have an idea for new content, then open an issue. All you need is a GitHub account and a web browser.In most cases, new work on Kubernetes documentation begins with an issue in GitHub. Kubernetes contributors then review, categorize and tag issues as needed. Next, you or another member of the Kubernetes community open a pull request with changes to resolve the issue.Opening an issueIf you want to suggest improvements to existing content or notice an error, then open an issue.Click the Create an issue link on the right sidebar. This redirects you to a GitHub issue page pre-populated with some headers.Describe the issue or suggestion for improvement. Provide as many details as you can.Click Submit new issue.After submitting, check in on your issue occasionally or turn on GitHub notifications. Reviewers and other community members might ask questions before they can take action on your issue.Suggesting new contentIf you have an idea for new content, but you aren't sure where it should go, you can still file an issue. Either:Choose an existing page in the section you think the content belongs in and click Create an issue.Go to GitHub and file the issue directly.How to file great issuesKeep the following in mind when filing an issue:Provide a clear issue description. Describe what specifically is missing, out of date, wrong, or needs improvement.Explain the specific impact the issue has on users.Limit the scope of a given issue to a reasonable unit of work. For problems with a large scope, break them down into smaller issues. For example, "Fix the security docs" is too broad, but "Add details to the 'Restricting network access' topic" is specific enough to be actionable.Search the existing issues to see if there's anything related or similar to the new issue.If the new issue relates to another issue or pull request, refer to it either by its full URL or by the issue or pull request number prefixed with a # character. For example, Introduced by #987654.Follow the Code of Conduct. Respect your fellow contributors. For example, "The docs are terrible" is not helpful or polite
# Documenting a feature for a release

Documenting a feature for a releaseEach major Kubernetes release introduces new features that require documentation. New releases also bring updates to existing features and documentation (such as upgrading a feature from alpha to beta).Generally, the SIG responsible for a feature submits draft documentation of the feature as a pull request to the appropriate development branch of the kubernetes/website repository, and someone on the SIG Docs team provides editorial
# Kubelet Systemd Watchdog

Kubelet Systemd WatchdogFEATURE STATE: Kubernetes v1.32 [beta] (enabled by default: true)On Linux nodes, Kubernetes 1.34 supports integrating with systemd to allow the operating system supervisor to recover a failed kubelet. This integration is not enabled by default. It can be used as an alternative to periodically requesting the kubelet's /healthz endpoint for health checks. If the kubelet does not respond to the watchdog within the timeout period, the watchdog will kill the kubelet.The systemd watchdog works by requiring the service to periodically send a keep-alive signal to the systemd process. If the signal is not received within a specified timeout period, the service is considered unresponsive and is terminated. The service can then be restarted according to the configuration.ConfigurationUsing the systemd watchdog requires configuring the WatchdogSec parameter in the [Service] section of the kubelet service unit file:[Service] WatchdogSec=30s Setting WatchdogSec=30s indicates a service watchdog timeout of 30 seconds. Within the kubelet, the sd_notify() function is invoked, at intervals of \( WatchdogSec \div 2\). to send WATCHDOG=1 (a keep-alive message). If the watchdog is not fed within the timeout period, the kubelet will be killed. Setting Restart to "always", "on-failure", "on-watchdog", or "on-abnormal" will ensure that the service is automatically restarted.Some details about the systemd configuration:If you set the systemd value for WatchdogSec to 0, or omit setting it, the systemd watchdog is not enabled for this unit.The kubelet supports a minimum watchdog period of 1.0 seconds; this is to prevent the kubelet from being killed unexpectedly. You can set the value of WatchdogSec in a systemd unit definition to a period shorter than 1 second, but Kubernetes does not support any shorter interval. The timeout does not have to be a whole integer number of seconds.The Kubernetes project suggests setting WatchdogSec to approximately a 15s period. Periods longer than 10 minutes are supported but explicitly not recommended.Example Configuration[Unit] Description=kubelet: The Kubernetes Node Agent Documentation=https://kubernetes.io/docs/home/ Wants=network-online.target After=network-online.target [Service] ExecStart=/usr/bin/kubelet # Configures the watchdog timeout WatchdogSec=30s Restart=on-failure StartLimitInterval=0 RestartSec=10 [Install] WantedBy=multi-user.target What's nextFor more details about systemd configuration, refer to the systemd documentation
# Contributing to Kubernetes blogs

Contributing to Kubernetes blogsThere are two official Kubernetes blogs, and the CNCF has its own blog where you can cover Kubernetes too. For the main Kubernetes blog, we (the Kubernetes project) like to publish articles with different perspectives and special focuses, that have a link to Kubernetes.With only a few special case exceptions, we only publish content that hasn't been submitted or published anywhere else.Read the blog guidelines for more about that aspect.Official Kubernetes blogsMain blogThe main Kubernetes blog is used by the project to communicate new features, community reports, and any news that might be relevant to the Kubernetes community. This includes end users and developers. Most of the blog's content is about things happening in the core project, but Kubernetes as a project encourages you to submit about things happening elsewhere in the ecosystem too!Anyone can write a blog post and submit it for publication. With only a few special case exceptions, we only publish content that hasn't been submitted or published anywhere else.Contributor blogThe Kubernetes contributor blog is aimed at an audience of people who work on Kubernetes more than people who work with Kubernetes. The Kubernetes project deliberately publishes some articles to both blogs.Anyone can write a blog post and submit it for review.Article updates and maintenanceThe Kubernetes project does not maintain older articles for its blogs. This means that any published article more than one year old will normally not be eligible for issues or pull requests that ask for changes. To avoid establishing precedent, even technically correct pull requests are likely to be rejected.However, there are exceptions like the following:(updates to) articles marked as evergreenremoving or correcting articles giving advice that is now wrong and dangerous to followfixes to ensure that an existing article still renders correctlyFor any article that is over a year old and not marked as evergreen, the website automatically displays a notice that the content may be stale.Evergreen articlesYou can mark an article as evergreen by setting evergreen: true in the front matter.We only mark blog articles as maintained (evergreen: true in front matter) if the Kubernetes project can commit to maintaining them indefinitely. Some blog articles absolutely merit this; for example, the release comms team always marks official release announcements as evergreen.What's nextDiscover the official blogs:Kubernetes blogKubernetes contributor blogRead about reviewing blog pull requestsSubmitting articles to Kubernetes blogsBlog guidelinesBlog article mirroringPost-release communicationsHelping as a blog writing buddy
# Cluster Administration

Cluster AdministrationLower-level detail relevant to creating or administering a Kubernetes cluster.The cluster administration overview is for anyone creating or administering a Kubernetes cluster. It assumes some familiarity with core Kubernetes concepts.Planning a clusterSee the guides in Setup for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called distros.Note:Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.Before choosing a guide, here are some considerations:Do you want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.Will you be using a hosted Kubernetes cluster, such as Google Kubernetes Engine, or hosting your own cluster?Will your cluster be on-premises, or in the cloud (IaaS)? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.If you are configuring Kubernetes on-premises, consider which networking model fits best.Will you be running Kubernetes on "bare metal" hardware or on virtual machines (VMs)?Do you want to run a cluster, or do you expect to do active development of Kubernetes project code? If the latter, choose an actively-developed distro. Some distros only use binary releases, but offer a greater variety of choices.Familiarize yourself with the components needed to run a cluster.Managing a clusterLearn how to manage nodes.Read about Node autoscaling.Learn how to set up and manage the resource quota for shared clusters.Securing a clusterGenerate Certificates describes the steps to generate certificates using different tool chains.Kubernetes Container Environment describes the environment for Kubelet managed containers on a Kubernetes node.Controlling Access to the Kubernetes API describes how Kubernetes implements access control for its own API.Authenticating explains authentication in Kubernetes, including the various authentication options.Authorization is separate from authentication, and controls how HTTP calls are handled.Using Admission Controllers explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.Admission Webhook Good Practices provides good practices and considerations when designing mutating admission webhooks and validating admission webhooks.Using Sysctls in a Kubernetes Cluster describes to an administrator how to use the sysctl command-line tool to set kernel parameters .Auditing describes how to interact with Kubernetes' audit logs.Securing the kubeletControl Plane-Node communicationTLS bootstrappingKubelet authentication/authorizationOptional Cluster ServicesDNS Integration describes how to resolve a DNS name directly to a Kubernetes service.Logging and Monitoring Cluster Activity explains how logging in Kubernetes works and how to implement it.
# Articles on dockershim Removal and on Using CRI-compatible Runtimes

Articles on dockershim Removal and on Using CRI-compatible RuntimesThis is a list of articles and other pages that are either about the Kubernetes' deprecation and removal of dockershim, or about using CRI-compatible container runtimes, in connection with that removal.Kubernetes projectKubernetes blog: Dockershim Removal FAQ (originally published 2020/12/02)Kubernetes blog: Updated: Dockershim Removal FAQ (updated published 2022/02/17)Kubernetes blog: Kubernetes is Moving on From Dockershim: Commitments and Next Steps (published 2022/01/07)Kubernetes blog: Dockershim removal is coming. Are you ready? (published 2021/11/12)Kubernetes documentation: Migrating from dockershimKubernetes documentation: Container RuntimesKubernetes enhancement proposal: KEP-2221: Removing dockershim from kubeletKubernetes enhancement proposal issue: Removing dockershim from kubelet (k/enhancements#2221)You can provide
# Inject Data Into Applications

Inject Data Into ApplicationsSpecify configuration and other data for the Pods that run your workload.Define a Command and Arguments for a ContainerDefine Dependent Environment VariablesDefine Environment Variables for a ContainerDefine Environment Variable Values Using An Init ContainerExpose Pod Information to Containers Through Environment VariablesExpose Pod Information to Containers Through FilesDistribute Credentials Securely Using Secrets
# Security

SecuritySecurity is an important concern for most organizations and people who run Kubernetes clusters. You can find a basic security checklist elsewhere in the Kubernetes documentation.To learn how to deploy and manage security aspects of Kubernetes, you can follow the tutorials in this section.Apply Pod Security Standards at the Cluster LevelApply Pod Security Standards at the Namespace LevelRestrict a Container's Access to Resources with AppArmorRestrict a Container's Syscalls with seccomp
# ObjectReference

ObjectReferenceObjectReference contains enough information to let you inspect or modify the referred object.import "k8s.io/api/core/v1"ObjectReference contains enough information to let you inspect or modify the referred object.apiVersion (string)API version of the referent.fieldPath (string)If referring to a piece of an object instead of an entire object, this string should contain a valid JSON/Go field access statement, such as desiredState.manifest.containers[2]. For example, if the object reference is to a container within a pod, this would take on a value like: "spec.containers{name}" (where "name" refers to the name of the container that triggered the event) or if no container name is specified "spec.containers[2]" (container with index 2 in this pod). This syntax is chosen only to have some well-defined way of referencing a part of an object.kind (string)Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kindsname (string)Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#namesnamespace (string)Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/resourceVersion (string)Specific resourceVersion to which this reference is made, if any. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistencyuid (string)UID of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uidsThis 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.
# Running Pods on Only Some Nodes

Running Pods on Only Some NodesThis page demonstrates how can you run Pods on only some Nodes as part of a DaemonSetBefore 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 KubernetesRunning Pods on only some NodesImagine that you want to run a DaemonSet, but you only need to run those daemon pods on nodes that have local solid state (SSD) storage. For example, the Pod might provide cache service to the node, and the cache is only useful when low-latency local storage is available.Step 1: Add labels to your nodesAdd the label ssd=true to the nodes which have SSDs.kubectl label nodes example-node-1 example-node-2 ssd=true Step 2: Create the manifestLet's create a DaemonSet which will provision the daemon pods on the SSD labeled nodes only.Next, use a nodeSelector to ensure that the DaemonSet only runs Pods on nodes with the ssd label set to "true".controllers/daemonset-label-selector.yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: ssd-driver labels: app: nginx spec: selector: matchLabels: app: ssd-driver-pod template: metadata: labels: app: ssd-driver-pod spec: nodeSelector: ssd: "true" containers: - name: example-container image: example-imageStep 3: Create the DaemonSetCreate the DaemonSet from the manifest by using kubectl create or kubectl applyLet's label another node as ssd=true.kubectl label nodes example-node-3 ssd=true Labelling the node automatically triggers the control plane (specifically, the DaemonSet controller) to run a new daemon pod on that node.kubectl get pods -o wide The output is similar to:NAME READY STATUS RESTARTS AGE IP NODE <daemonset-name><some-hash-01> 1/1 Running 0 13s ..... example-node-1 <daemonset-name><some-hash-02> 1/1 Running 0 13s ..... example-node-2 <daemonset-name><some-hash-03> 1/1 Running 0 5s ..... example-node-3
# Troubleshooting Applications

Troubleshooting ApplicationsDebugging common containerized application issues.This doc contains a set of resources for fixing issues with containerized applications. It covers things like common issues with Kubernetes resources (like Pods, Services, or StatefulSets), advice on making sense of container termination messages, and ways to debug running containers.Debug PodsDebug ServicesDebug a StatefulSetDetermine the Reason for Pod FailureDebug Init ContainersDebug Running PodsGet a Shell to a Running Container
# Generating Reference Documentation for Metrics

Generating Reference Documentation for MetricsThis page demonstrates the generation of metrics reference documentation.Before you beginRequirements:You need a machine that is running Linux or macOS.You need to have these tools installed:Python v3.7.x+GitGolang version 1.13+Pip used to install PyYAMLPyYAML v5.1.2makegcc compiler/linkerDocker (Required only for kubectl command reference)Your PATH environment variable must include the required build tools, such as the Go binary and python.You need to know how to create a pull request to a GitHub repository. This involves creating your own fork of the repository. For more information, see Work from a local clone.Clone the Kubernetes repositoryThe metric generation happens in the Kubernetes repository. To clone the repository, change directories to where you want the clone to exist.Then, execute the following command:git clone https://www.github.com/kubernetes/kubernetes This creates a kubernetes folder in your current working directory.Generate the metricsInside the cloned Kubernetes repository, locate the test/instrumentation/documentation directory. The metrics documentation is generated in this directory.With each release, new metrics are added. After you run the metrics documentation generator script, copy the metrics documentation to the Kubernetes website and publish the updated metrics documentation.To generate the latest metrics, make sure you are in the root of the cloned Kubernetes directory. Then, execute the following command:./test/instrumentation/update-documentation.sh To check for changes, execute:git status The output is similar to:./test/instrumentation/documentation/documentation.md ./test/instrumentation/documentation/documentation-list.yaml Copy the generated metrics documentation file to the Kubernetes website repositorySet the Kubernetes website root environment variable.Execute the following command to set the website root:export WEBSITE_ROOT=<path to website root> Copy the generated metrics file to the Kubernetes website repository.cp ./test/instrumentation/documentation/documentation.md "${WEBSITE_ROOT}/content/en/docs/reference/instrumentation/metrics.md" Note:If you get an error, check that you have permission to copy the file. You can use chown to change the file ownership back to your own user.Create a pull requestTo create a pull request, follow the instructions in Opening a pull request.What's nextContribute-upstreamGenerating Reference Docs for Kubernetes Components and ToolsGenerating Reference Documentation for kubectl Commands
# Liveness, Readiness, and Startup Probes

Liveness, Readiness, and Startup ProbesKubernetes has various types of probes:Liveness probeReadiness probeStartup probeLiveness probeLiveness probes determine when to restart a container. For example, liveness probes could catch a deadlock when an application is running but unable to make progress.If a container fails its liveness probe repeatedly, the kubelet restarts the container.Liveness probes do not wait for readiness probes to succeed. If you want to wait before executing a liveness probe, you can either define initialDelaySeconds or use a startup probe.Readiness probeReadiness probes determine when a container is ready to accept traffic. This is useful when waiting for an application to perform time-consuming initial tasks that depend on its backing services; for example: establishing network connections, loading files, and warming caches. Readiness probes can also be useful later in the container’s lifecycle, for example, when recovering from temporary faults or overloads.If the readiness probe returns a failed state, Kubernetes removes the pod from all matching service endpoints.Readiness probes run on the container during its whole lifecycle.Startup probeA startup probe verifies whether the application within a container is started. This can be used to adopt liveness checks on slow starting containers, avoiding them getting killed by the kubelet before they are up and running.If such a probe is configured, it disables liveness and readiness checks until it succeeds.This type of probe is only executed at startup, unlike liveness and readiness probes, which are run periodically.Read more about the Configure Liveness, Readiness and Startup Probes.
# Ports and Protocols

Ports and ProtocolsWhen running Kubernetes in an environment with strict network boundaries, such as on-premises datacenter with physical network firewalls or Virtual Networks in Public Cloud, it is useful to be aware of the ports and protocols used by Kubernetes components.Control planeProtocolDirectionPort RangePurposeUsed ByTCPInbound6443Kubernetes API serverAllTCPInbound2379-2380etcd server client APIkube-apiserver, etcdTCPInbound10250Kubelet APISelf, Control planeTCPInbound10259kube-schedulerSelfTCPInbound10257kube-controller-managerSelfAlthough etcd ports are included in control plane section, you can also host your own etcd cluster externally or on custom ports.Worker node(s)ProtocolDirectionPort RangePurposeUsed ByTCPInbound10250Kubelet APISelf, Control planeTCPInbound10256kube-proxySelf, Load balancersTCPInbound30000-32767NodePort Services†AllUDPInbound30000-32767NodePort Services†All† Default port range for NodePort Services.All default port numbers can be overridden. When custom ports are used those ports need to be open instead of defaults mentioned here.One common example is API server port that is sometimes switched to 443. Alternatively, the default port is kept as is and API server is put behind a load balancer that listens on 443 and routes the requests to API server on the default port.
# Post-release communications

Post-release communicationsThe Kubernetes Release Comms team (part of SIG Release) looks after release announcements, which go onto the main project blog.After each release, the Release Comms team take over the main blog for a period and publish a series of additional articles to explain or announce changes related to that release. These additional articles are termed post-release comms.Opting in to post-release commsDuring a release cycle, as a contributor, you can opt in to post-release comms about an upcoming change to Kubernetes.To opt in you open a draft, placeholder pull request (PR) against k/website. Initially, this can be an empty commit. Mention the KEP issue or other Kubernetes improvement issue in the description of your placeholder PR.When you open the draft pull request, you open it against main as the base branch and not against the dev-1.35 branch. This is different from the process for upcoming release changes and new features.You should also leave a comment on the related kubernetes/enhancements issue with a link to the PR to notify the Release Comms team managing this release. Your comment helps the team see that the change needs announcing and that your SIG has opted in.As well as the above, you should ideally contact the Release Comms team via Slack (channel #release-comms) to let them know that you have done this and would like to opt in.Preparing the article contentYou should follow the usual article submission process to turn your placeholder PR into something ready for review. However, for post-release comms, you may not have a writing buddy; instead, the Release Comms team may assign a member of the team to help guide what you're doing.You should squash the commits in your pull request; if you're not sure how to, it's absolutely OK to ask Release Comms or the blog team for help.Provided that your article is flagged as a draft (draft: true) in the front matter, the PR can merge at any time during the release cycle.PublicationAhead of the actual release, the Release Comms team check what content is ready (if it's not ready by the deadline, and you didn't get an exception, then the announcement won't be included). They build a schedule for the articles that will go out and open new pull requests to turn those articles from draft to published.Caution:All these pull requests to actually publish post-release articles must be held (Prow command /hold) until the release has actually happened.The blog team approvers still provide final sign off on promoting the content from draft to accepted for publication. Ahead of release day, the PR (or PRs) for publishing these announcements should have LGTM (“looks good to me”) and approved labels, along with the do-not-merge/hold label to ensure the PR doesn't merge too early.Release Comms / the Release Team can then unhold that PR (or set of PRs) as soon as the website Git repository is unfrozen after the actual release.On the day each article is scheduled to publish, automation triggers a website build and that article becomes visible.
# kubeadm reset phase

kubeadm reset phasekubeadm reset phase enables you to invoke atomic steps of the node reset process. Hence, you can let kubeadm do some of the work and you can fill in the gaps if you wish to apply customization.kubeadm reset phase is consistent with the kubeadm reset workflow, and behind the scene both use the same code.kubeadm reset phaseSynopsisUse this command to invoke single phase of the "reset" workflowkubeadm reset phase [flags] Options-h, --helphelp for phaseOptions inherited from parent commands--rootfs stringThe path to the 'real' host root filesystem. This will cause kubeadm to chroot into the provided path.kubeadm reset phase preflightUsing this phase you can execute preflight checks on a node that is being reset.Run reset pre-flight checksSynopsisRun pre-flight checks for kubeadm reset.kubeadm reset phase preflight [flags] Options--dry-runDon't apply any changes; just output what would be done.-f, --forceReset the node without prompting for confirmation.-h, --helphelp for preflight--ignore-preflight-errors stringsA list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.Options inherited from parent commands--rootfs stringThe path to the 'real' host root filesystem. This will cause kubeadm to chroot into the provided path.kubeadm reset phase remove-etcd-memberUsing this phase you can remove this control-plane node's etcd member from the etcd cluster.SynopsisRemove a local etcd member for a control plane node.kubeadm reset phase remove-etcd-member [flags] Options--dry-runDon't apply any changes; just output what would be done.-h, --helphelp for remove-etcd-member--kubeconfig string Default: "/etc/kubernetes/admin.conf"The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.Options inherited from parent commands--rootfs stringThe path to the 'real' host root filesystem. This will cause kubeadm to chroot into the provided path.kubeadm reset phase cleanup-nodeUsing this phase you can perform cleanup on this node.SynopsisRun cleanup node.kubeadm reset phase cleanup-node [flags] Options--cert-dir string Default: "/etc/kubernetes/pki"The path to the directory where the certificates are stored. If specified, clean this directory.--cleanup-tmp-dirCleanup the "/etc/kubernetes/tmp" directory--cri-socket stringPath to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket.--dry-runDon't apply any changes; just output what would be done.-h, --helphelp for cleanup-nodeOptions inherited from parent commands--rootfs stringThe path to the 'real' host root filesystem. This will cause kubeadm to chroot into the provided path.What's nextkubeadm init to bootstrap a Kubernetes control-plane nodekubeadm join to connect a node to the clusterkubeadm reset to revert any changes made to this host by kubeadm init or kubeadm joinkubeadm alpha to try experimental functionality
# Cluster Resources

Cluster ResourcesAPIServiceAPIService represents a server for a particular GroupVersion.ComponentStatusComponentStatus (and ComponentStatusList) holds the cluster validation info.EventEvent is a report of an event somewhere in the cluster.IPAddressIPAddress represents a single IP of a single IP Family.LeaseLease defines a lease concept.LeaseCandidate v1beta1LeaseCandidate defines a candidate for a Lease object.NamespaceNamespace provides a scope for Names.NodeNode is a worker node in Kubernetes.RuntimeClassRuntimeClass defines a class of container runtime supported in the cluster.ServiceCIDRServiceCIDR defines a range of IP addresses using CIDR format (e.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.
# Proxies in Kubernetes

Proxies in KubernetesThis page explains proxies used with Kubernetes.ProxiesThere are several different proxies you may encounter when using Kubernetes:The kubectl proxy:runs on a user's desktop or in a podproxies from a localhost address to the Kubernetes apiserverclient to proxy uses HTTPproxy to apiserver uses HTTPSlocates apiserveradds authentication headersThe apiserver proxy:is a bastion built into the apiserverconnects a user outside of the cluster to cluster IPs which otherwise might not be reachableruns in the apiserver processesclient to proxy uses HTTPS (or http if apiserver so configured)proxy to target may use HTTP or HTTPS as chosen by proxy using available informationcan be used to reach a Node, Pod, or Servicedoes load balancing when used to reach a ServiceThe kube proxy:runs on each nodeproxies UDP, TCP and SCTPdoes not understand HTTPprovides load balancingis only used to reach servicesA Proxy/Load-balancer in front of apiserver(s):existence and implementation varies from cluster to cluster (e.g. nginx)sits between all clients and one or more apiserversacts as load balancer if there are several apiservers.Cloud Load Balancers on external services:are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)are created automatically when the Kubernetes service has type LoadBalancerusually supports UDP/TCP onlySCTP support is up to the load balancer implementation of the cloud providerimplementation varies by cloud provider.Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin will typically ensure that the latter types are set up correctly.Requesting redirectsProxies have replaced redirect capabilities. Redirects have been deprecated.
# ResourceFieldSelector

ResourceFieldSelectorResourceFieldSelector represents container resources (cpu, memory) and their output format.import "k8s.io/api/core/v1"ResourceFieldSelector represents container resources (cpu, memory) and their output formatresource (string), requiredRequired: resource to selectcontainerName (string)Container name: required for volumes, optional for env varsdivisor (Quantity)Specifies the output format of the exposed resources, defaults to "1"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.
# Scheduling, Preemption and Eviction

Scheduling, Preemption and EvictionIn Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them. Preemption is the process of terminating Pods with lower Priority so that Pods with higher Priority can schedule on Nodes. Eviction is the process of terminating one or more Pods on Nodes.SchedulingKubernetes SchedulerAssigning Pods to NodesPod OverheadPod Topology Spread ConstraintsTaints and TolerationsScheduling FrameworkDynamic Resource AllocationScheduler Performance TuningResource Bin Packing for Extended ResourcesPod Scheduling ReadinessDeschedulerPod DisruptionPod disruption is the process by which Pods on Nodes are terminated either voluntarily or involuntarily.Voluntary disruptions are started intentionally by application owners or cluster administrators. Involuntary disruptions are unintentional and can be triggered by unavoidable issues like Nodes running out of resources, or by accidental deletions.Pod Priority and PreemptionNode-pressure EvictionAPI-initiated Eviction
# Container Runtime Interface (CRI)

Container Runtime Interface (CRI)The CRI is a plugin interface which enables the kubelet to use a wide variety of container runtimes, without having a need to recompile the cluster components.You need a working container runtime on each Node in your cluster, so that the kubelet can launch Pods and their containers.The Container Runtime Interface (CRI) is the main protocol for the communication between the kubelet and Container Runtime.The Kubernetes Container Runtime Interface (CRI) defines the main gRPC protocol for the communication between the node components kubelet and container runtime.The APIFEATURE STATE: Kubernetes v1.23 [stable]The kubelet acts as a client when connecting to the container runtime via gRPC. The runtime and image service endpoints have to be available in the container runtime, which can be configured separately within the kubelet by using the --container-runtime-endpoint command line flag.For Kubernetes v1.26 and later, the kubelet requires that the container runtime supports the v1 CRI API. If a container runtime does not support the v1 API, the kubelet will not register the node.UpgradingWhen upgrading the Kubernetes version on a node, the kubelet restarts. If the container runtime does not support the v1 CRI API, the kubelet will fail to register and report an error. If a gRPC re-dial is required because the container runtime has been upgraded, the runtime must support the v1 CRI API for the connection to succeed. This might require a restart of the kubelet after the container runtime is correctly configured.What's nextLearn more about the CRI protocol definition
# Access Applications in a Cluster

Access Applications in a ClusterConfigure load balancing, port forwarding, or setup firewall or DNS configurations to access applications in a cluster.Deploy and Access the Kubernetes DashboardDeploy the web UI (Kubernetes Dashboard) and access it.Accessing ClustersConfigure Access to Multiple ClustersUse Port Forwarding to Access Applications in a ClusterUse a Service to Access an Application in a ClusterConnect a Frontend to a Backend Using ServicesCreate an External Load BalancerList All Container Images Running in a ClusterSet up Ingress on Minikube with the NGINX Ingress ControllerCommunicate Between Containers in the Same Pod Using a Shared VolumeConfigure DNS for a ClusterAccess Services Running on Clusters
# Use an Image Volume With a Pod

Use an Image Volume With a PodFEATURE STATE: Kubernetes v1.33 [beta] (enabled by default: false)This page shows how to configure a pod using image volumes. This allows you to mount content from OCI registries inside containers.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.31.To check the version, enter kubectl version.The container runtime needs to support the image volumes featureYou need to exec commands in the hostYou need to be able to exec into podsYou need to enable the ImageVolume feature gateRun a Pod that uses an image volumeAn image volume for a pod is enabled by setting the volumes.[*].image field of .spec to a valid reference and consuming it in the volumeMounts of the container. For example:pods/image-volumes.yaml apiVersion: v1 kind: Pod metadata: name: image-volume spec: containers: - name: shell command: ["sleep", "infinity"] image: debian volumeMounts: - name: volume mountPath: /volume volumes: - name: volume image: reference: quay.io/crio/artifact:v2 pullPolicy: IfNotPresent Create the pod on your cluster:kubectl apply -f https://k8s.io/examples/pods/image-volumes.yaml Attach to the container:kubectl attach -it image-volume bash Check the content of a file in the volume:cat /volume/dir/file The output is similar to:1 You can also check another file in a different path:cat /volume/file The output is similar to:2 Use subPath (or subPathExpr)It is possible to utilize subPath or subPathExpr from Kubernetes v1.33 when using the image volume feature.pods/image-volumes-subpath.yaml apiVersion: v1 kind: Pod metadata: name: image-volume spec: containers: - name: shell command: ["sleep", "infinity"] image: debian volumeMounts: - name: volume mountPath: /volume subPath: dir volumes: - name: volume image: reference: quay.io/crio/artifact:v2 pullPolicy: IfNotPresent Create the pod on your cluster:kubectl apply -f https://k8s.io/examples/pods/image-volumes-subpath.yaml Attach to the container:kubectl attach -it image-volume bash Check the content of the file from the dir sub path in the volume:cat /volume/file The output is similar to:1 Further readingimage volumes