This guide is for application owners who want to build highly available applications, and thus need to understand what types of disruptions can happen to Pods. It is also for cluster administrators who want to perform automated cluster actions, like upgrading and autoscaling clusters. Voluntary and involuntary disruptions Pods do not disappear until someone (a person or a controller) destroys them, or there is an unavoidable hardware or system software error.

An overview of the key components that make up a Kubernetes cluster.

The kubectl command-line tool supports several different ways to create and manage Kubernetes objects. This document provides an overview of the different approaches. Read the Kubectl book for details of managing objects by Kubectl. Management techniques Warning:A Kubernetes object should be managed using only one technique. Mixing and matching techniques for the same object results in undefined behavior. Management technique Operates on Recommended environment Supported writers Learning curve Imperative commands Live objects Development projects 1+ Lowest Imperative object configuration Individual files Production projects 1 Moderate Declarative object configuration Directories of files Production projects 1+ Highest Imperative commands When using imperative commands, a user operates directly on live objects in a cluster.

FEATURE STATE: Kubernetes v1.30 [stable] Pods were considered ready for scheduling once created. Kubernetes scheduler does its due diligence to find nodes to place all pending Pods. However, in a real-world case, some Pods may stay in a "miss-essential-resources" state for a long period. These Pods actually churn the scheduler (and downstream integrators like Cluster AutoScaler) in an unnecessary manner. By specifying/removing a Pod's .spec.schedulingGates, you can control when a Pod is ready to be considered for scheduling.

If two Pods in your cluster want to communicate, and both Pods are actually running on the same node, use _Service Internal Traffic Policy_ to keep network traffic within that node. Avoiding a round trip via the cluster network can help with reliability, performance (network latency and throughput), or cost.

Production-Grade Container Orchestration

Production-Grade Container Orchestration

Synopsis Create a pod disruption budget with the specified name, selector, and desired minimum available pods. kubectl create poddisruptionbudget NAME --selector=SELECTOR --min-available=N [--dry-run=server|client|none] Examples # Create a pod disruption budget named my-pdb that will select all pods with the app=rails label # and require at least one of them being available at any point in time kubectl create poddisruptionbudget my-pdb --selector=app=rails --min-available=1 # Create a pod disruption budget named my-pdb that will select all pods with the app=nginx label # and require at least half of the pods selected to be available at any point in time kubectl create pdb my-pdb --selector=app=nginx --min-available=50% Options --allow-missing-template-keys     Default: true If true, ignore any errors in templates when a field or map key is missing in the template.

Synopsis Create a role binding for a particular role or cluster role. kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none] Examples # Create a role binding for user1, user2, and group1 using the admin cluster role kubectl create rolebinding admin --clusterrole=admin --user=user1 --user=user2 --group=group1 # Create a role binding for service account monitoring:sa-dev using the admin role kubectl create rolebinding admin-binding --role=admin --serviceaccount=monitoring:sa-dev Options --allow-missing-template-keys     Default: true If true, ignore any errors in templates when a field or map key is missing in the template.

Synopsis Update the user, group, or service account in a role binding or cluster role binding. kubectl set subject (-f FILENAME | TYPE NAME) [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none] Examples # Update a cluster role binding for serviceaccount1 kubectl set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1 # Update a role binding for user1, user2, and group1 kubectl set subject rolebinding admin --user=user1 --user=user2 --group=group1 # Print the result (in YAML format) of updating rolebinding subjects from a local, without hitting the server kubectl create rolebinding admin --role=admin --user=admin -o yaml --dry-run=client | kubectl set subject --local -f - --user=foo -o yaml Options --all Select all resources, in the namespace of the specified resource types