Production-Grade Container Orchestration

Synopsis View the latest last-applied-configuration annotations by type/name or file. The default output will be printed to stdout in YAML format. You can use the -o option to change the output format. kubectl apply view-last-applied (TYPE [NAME | -l label] | TYPE/NAME | -f FILENAME) Examples # View the last-applied-configuration annotations by type/name in YAML kubectl apply view-last-applied deployment/nginx # View the last-applied-configuration annotations by file in JSON kubectl apply view-last-applied -f deploy.

kubeadm kubeconfig provides utilities for managing kubeconfig files. For examples on how to use kubeadm kubeconfig user see Generating kubeconfig files for additional users. kubeadm kubeconfig overview Synopsis Kubeconfig file utilities. Options -h, --help help for kubeconfig Options inherited from parent commands --rootfs string The path to the 'real' host root filesystem. This will cause kubeadm to chroot into the provided path. kubeadm kubeconfig user This command can be used to output a kubeconfig file for an additional user.

A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by the control plane. Kubernetes v1.34 supports clusters with up to 5,000 nodes. More specifically, Kubernetes is designed to accommodate configurations that meet all of the following criteria: No more than 110 pods per node No more than 5,000 nodes No more than 150,000 total pods No more than 300,000 total containers You can scale your cluster by adding or removing nodes.

A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. Usually, you define a Deployment and let that Deployment manage ReplicaSets automatically.

Production-Grade Container Orchestration

FEATURE STATE: Kubernetes v1.11 [beta] Cloud infrastructure technologies let you run Kubernetes on public, private, and hybrid clouds. Kubernetes believes in automated, API-driven infrastructure without tight coupling between components. The cloud-controller-manager is a Kubernetes control plane component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that only interact with your cluster.

This website contains documentation for the current version of Kubernetes and the four previous versions of Kubernetes. The availability of documentation for a Kubernetes version is separate from whether that release is currently supported. Read Support period to learn about which versions of Kubernetes are officially supported, and for how long.

Kubernetes runs your workload by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the control plane and contains the services necessary to run Pods. Typically you have several nodes in a cluster; in a learning or resource-limited environment, you might have only one node. The components on a node include the kubelet, a container runtime, and the kube-proxy.

This page describes running Kubernetes across multiple zones. Background Kubernetes is designed so that a single Kubernetes cluster can run across multiple failure zones, typically where these zones fit within a logical grouping called a region. Major cloud providers define a region as a set of failure zones (also called availability zones) that provide a consistent set of features: within a region, each zone offers the same APIs and services.