Kubectl

alpha diff

Diff resources included in pod.json. By default, it will diff LOCAL and LIVE versions kubectl alpha diff -f pod.json When one version is specified, diff that version against LIVE cat service.yaml | kubectl alpha diff -f - MERGED Or specify both versions kubectl alpha diff -f pod.json -f service.yaml LAST LOCAL Diff configurations specified by filename or stdin between their local, last-applied, live and/or "merged" versions. LOCAL and LIVE versions are diffed by default. Other available keywords are MERGED and LAST. Output is always YAML. KUBERNETES EXTERNAL DIFF environment variable can be used to select your own diff command. By default, the "diff" command available in your path will be run with "-u" (unicode) and "-N" (treat new files as empty) options. Usage $ diff -f FILENAME

top

Display Resource (CPU/Memory/Storage) usage. The top command allows you to see the resource consumption for nodes or pods. This command requires Heapster to be correctly configured and working on the server. Usage $ top

config current-context

Display the current-context kubectl config current-context Displays the current-context Usage $ current-context

drain

Drain node "foo", even if there are pods not managed by a ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet on it. $ kubectl drain foo --force As above, but abort if there are pods not managed by a ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet, and use a grace period of 15 minutes. $ kubectl drain foo --grace-period=900 Drain node in preparation for maintenance. The given node will be marked unschedulable to prevent new pods from arriving. 'drain' evicts the pods if the APIServer supports eviction (http://kubernetes.io/docs/admin/disruptions/). Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are DaemonSet-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any DaemonSet-managed pods, because those pods would be immediately replaced by the DaemonSet controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by ReplicationController, ReplicaSet, DaemonSet, StatefulSet or Job, then drain will not delete any pods unless you use --force. --force will also allow deletion to proceed if the managing resource of one or more pods is missing. 'drain' waits for graceful termination. You should not operate on the machine until the command completes. When you are ready to put the node back into service, use kubectl uncordon, which will make the node schedulable again. ! http://kubernetes.io/images/docs/kubectl_drain.svg Usage $ drain NODE

cluster-info dump

Dump current cluster state to stdout kubectl cluster-info dump Dump current cluster state to /path/to/cluster-state kubectl cluster-info dump --output-directory=/path/to/cluster-state Dump all namespaces to stdout kubectl cluster-info dump --all-namespaces Dump a set of namespaces to /path/to/cluster-state kubectl cluster-info dump --namespaces default,kube-system --output-directory=/path/to/cluster-state Dumps cluster info out suitable for debugging and diagnosing cluster problems. By default, dumps everything to stdout. You can optionally specify a directory with --output-directory. If you specify a directory, kubernetes will build a set of files in that directory. By default only dumps things in the 'kube-system' namespace, but you can switch to a different namespace with the --namespaces flag, or specify --all-namespaces to dump all namespaces. The command also dumps the logs of all of the pods in the cluster, these logs are dumped into different directories based on namespace and pod name. Usage $ dump

edit-last-applied

Edit the last-applied-configuration annotations by type/name in YAML. kubectl apply edit-last-applied deployment/nginx Edit the last-applied-configuration annotations by file in JSON. kubectl apply edit-last-applied -f deploy.yaml -o json Edit the latest last-applied-configuration annotations of resources from the default editor. The edit-last-applied command allows you to directly edit any API resource you can retrieve via the command line tools. It will open the editor defined by your KUBE _EDITOR, or EDITOR environment variables, or fall back to 'vi' for Linux or 'notepad' for Windows. You can edit multiple objects, although changes are applied one at a time. The command accepts filenames as well as command line arguments, although the files you point to must be previously saved versions of resources. The default format is YAML. To edit in JSON, specify "-o json". The flag --windows-line-endings can be used to force Windows line endings, otherwise the default for your operating system will be used. In the event an error occurs while updating, a temporary file will be created on disk that contains your unapplied changes. The most common error when updating a resource is another editor changing the resource on the server. When this occurs, you will have to apply your changes to the newer version of the resource, or update your temporary saved copy to include the latest resource version. Usage $ edit-last-applied (RESOURCE/NAME | -f FILENAME)

cp

!!!Important Note!!! # Requires that the 'tar' binary is present in your container # image. If 'tar' is not present, 'kubectl cp' will fail. # Copy /tmp/foo_dir local directory to /tmp/bar_dir in a remote pod in the default namespace kubectl cp /tmp/foo_dir <some-pod>:/tmp/bar_dir Copy /tmp/foo local file to /tmp/bar in a remote pod in a specific container kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container> Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace kubectl cp /tmp/foo <some-namespace>/<some-pod>:/tmp/bar Copy /tmp/foo from a remote pod to /tmp/bar locally kubectl cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar Copy files and directories to and from containers. Usage $ cp <file-spec-src> <file-spec-dest>

apply

Apply the configuration in pod.json to a pod. kubectl apply -f ./pod.json Apply the JSON passed into stdin to a pod. cat pod.json | kubectl apply -f - Note: --prune is still in Alpha # Apply the configuration in manifest.yaml that matches label app=nginx and delete all the other resources that are not in the file and match label app=nginx. kubectl apply --prune -f manifest.yaml -l app=nginx Apply the configuration in manifest.yaml and delete all the other configmaps that are not in the file. kubectl apply --prune -f manifest.yaml --all --prune-whitelist=core/v1/ConfigMap Apply a configuration to a resource by filename or stdin. The resource name must be specified. This resource will be created if it doesn't exist yet. To use 'apply', always create the resource initially with either 'apply' or 'create --save-config'. JSON and YAML formats are accepted. Alpha Disclaimer: the --prune functionality is not yet complete. Do not use unless you are aware of what the current state is. See https://issues.k8s.io/34274. Usage $ apply -f FILENAME

certificate approve

Approve a certificate signing request. kubectl certificate approve allows a cluster admin to approve a certificate signing request (CSR). This action tells a certificate signing controller to issue a certificate to the requestor with the attributes requested in the CSR. SECURITY NOTICE: Depending on the requested attributes, the issued certificate can potentially grant a requester access to cluster resources or to authenticate as a requested identity. Before approving a CSR, ensure you understand what the signed certificate can do. Usage $ approve (-f FILENAME | NAME)

autoscale

Auto scale a deployment "foo", with the number of pods between 2 and 10, no target CPU utilization specified so a default autoscaling policy will be used: kubectl autoscale deployment foo --min=2 --max=10 Auto scale a replication controller "foo", with the number of pods between 1 and 5, target CPU utilization at 80%: kubectl autoscale rc foo --max=5 --cpu-percent=80 Creates an autoscaler that automatically chooses and sets the number of pods that run in a kubernetes cluster. Looks up a Deployment, ReplicaSet, or ReplicationController by name and creates an autoscaler that uses the given resource as a reference. An autoscaler can automatically increase or decrease number of pods deployed within the system as needed. Usage $ autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU]

auth cani

Check to see if I can create pods in any namespace kubectl auth can-i create pods --all-namespaces Check to see if I can list deployments in my current namespace kubectl auth can-i list deployments.extensions Check to see if I can do everything in my current namespace ("*" means all) kubectl auth can-i '*' '*' Check to see if I can get the job named "bar" in namespace "foo" kubectl auth can-i list jobs.batch/bar -n foo Check to see if I can read pod logs kubectl auth can-i get pods --subresource=log Check to see if I can access the URL /logs/ kubectl auth can-i get /logs/ Check whether an action is allowed. VERB is a logical Kubernetes API verb like 'get', 'list', 'watch', 'delete', etc. TYPE is a Kubernetes resource. Shortcuts and groups will be resolved. NONRESOURCEURL is a partial URL starts with "/". NAME is the name of a particular Kubernetes resource. Usage $ can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL]

set

Configure application resources These commands help you make changes to existing application resources. Usage $ set SUBCOMMAND

convert

Convert 'pod.yaml' to latest version and print to stdout. kubectl convert -f pod.yaml Convert the live state of the resource specified by 'pod.yaml' to the latest version # and print to stdout in JSON format. kubectl convert -f pod.yaml --local -o json Convert all files under current directory to latest version and create them all. kubectl convert -f . | kubectl create -f - Convert config files between different API versions. Both YAML and JSON formats are accepted. The command takes filename, directory, or URL as input, and convert it into format of version specified by --output-version flag. If target version is not specified or not supported, convert to latest version. The default output will be printed to stdout in YAML format. One can use -o option to change to output destination. Usage $ convert -f FILENAME

clusterrole

Create a ClusterRole. Usage $ clusterrole NAME --verb=verb --resource=resource.group [--resource-name=resourcename] [--dry-run]

clusterrolebinding

Create a ClusterRoleBinding for a particular ClusterRole. Usage $ clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run]

role

Create a Role named "pod-reader" that allows user to perform "get", "watch" and "list" on pods kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods Create a Role named "pod-reader" with ResourceName specified kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod Create a Role named "foo" with API Group specified kubectl create role foo --verb=get,list,watch --resource=rs.extensions Create a Role named "foo" with SubResource specified kubectl create role foo --verb=get,list,watch --resource=pods,pods/status Create a role with single rule. Usage $ role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run]

rolebinding

Create a RoleBinding for user1, user2, and group1 using the admin ClusterRole kubectl create rolebinding admin --clusterrole=admin --user=user1 --user=user2 --group=group1 Create a RoleBinding for a particular Role or ClusterRole. Usage $ rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run]

configmap

Create a configmap based on a file, directory, or specified literal value. A single configmap may package one or more key/value pairs. When creating a configmap based on a file, the key will default to the basename of the file, and the value will default to the file content. If the basename is an invalid key, you may specify an alternate key. When creating a configmap based on a directory, each file whose basename is a valid key in the directory will be packaged into the configmap. Any directory entries except regular files are ignored (e.g. subdirectories, symlinks, devices, pipes, etc). Usage $ configmap NAME [--from-file=[key=]source] [--from-literal=key1=value1] [--dry-run]

deployment

Create a deployment with the specified name. Usage $ deployment NAME --image=image [--dry-run]

job

Create a job with the specified name. Usage $ job NAME [--from=CRONJOB]

namespace

Create a namespace with the specified name. Usage $ namespace NAME [--dry-run]

service clusterip

Create a new ClusterIP service named my-cs kubectl create service clusterip my-cs --tcp=5678:8080 Create a new ClusterIP service named my-cs (in headless mode) kubectl create service clusterip my-cs --clusterip="None" Create a ClusterIP service with the specified name. Usage $ clusterip NAME [--tcp=<port>:<targetPort>] [--dry-run]

service externalname

Create a new ExternalName service named my-ns kubectl create service externalname my-ns --external-name bar.com Create an ExternalName service with the specified name. ExternalName service references to an external DNS address instead of only pods, which will allow application authors to reference services that exist off platform, on other clusters, or locally. Usage $ externalname NAME --external-name external.name [--dry-run]

service loadbalancer

Create a new LoadBalancer service named my-lbs kubectl create service loadbalancer my-lbs --tcp=5678:8080 Create a LoadBalancer service with the specified name. Usage $ loadbalancer NAME [--tcp=port:targetPort] [--dry-run]

service nodeport

Create a new NodePort service named my-ns kubectl create service nodeport my-ns --tcp=5678:8080 Create a NodePort service with the specified name. Usage $ nodeport NAME [--tcp=port:targetPort] [--dry-run]

secret tls

Create a new TLS secret named tls-secret with the given key pair: kubectl create secret tls tls-secret --cert=path/to/tls.cert --key=path/to/tls.key Create a TLS secret from the given public/private key pair. The public/private key pair must exist before hand. The public key certificate must be .PEM encoded and match the given private key. Usage $ tls NAME --cert=path/to/cert/file --key=path/to/key/file [--dry-run]

quota

Create a new resourcequota named my-quota kubectl create quota my-quota --hard=cpu=1,memory=1G,pods=2,services=3,replicationcontrollers=2,resourcequotas=1,secrets=5,persistentvolumeclaims=10 Create a new resourcequota named best-effort kubectl create quota best-effort --hard=pods=100 --scopes=BestEffort Create a resourcequota with the specified name, hard limits and optional scopes Usage $ quota NAME [--hard=key1=value1,key2=value2] [--scopes=Scope1,Scope2] [--dry-run=bool]

secret generic

Create a new secret named my-secret with keys for each file in folder bar kubectl create secret generic my-secret --from-file=path/to/bar Create a new secret named my-secret with specified keys instead of names on disk kubectl create secret generic my-secret --from-file=ssh-privatekey=~/.ssh/id_rsa --from-file=ssh-publickey=~/.ssh/id_rsa.pub Create a new secret named my-secret with key1=supersecret and key2=topsecret kubectl create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret Create a new secret named my-secret using a combination of a file and a literal kubectl create secret generic my-secret --from-file=ssh-privatekey=~/.ssh/id_rsa --from-literal=passphrase=topsecret Create a new secret named my-secret from an env file kubectl create secret generic my-secret --from-env-file=path/to/bar.env Create a secret based on a file, directory, or specified literal value. A single secret may package one or more key/value pairs. When creating a secret based on a file, the key will default to the basename of the file, and the value will default to the file content. If the basename is an invalid key or you wish to chose your own, you may specify an alternate key. When creating a secret based on a directory, each file whose basename is a valid key in the directory will be packaged into the secret. Any directory entries except regular files are ignored (e.g. subdirectories, symlinks, devices, pipes, etc). Usage $ generic NAME [--type=string] [--from-file=[key=]source] [--from-literal=key1=value1] [--dry-run]

serviceaccount

Create a new service account named my-service-account kubectl create serviceaccount my-service-account Create a service account with the specified name. Usage $ serviceaccount NAME [--dry-run]

poddisruptionbudget

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% Create a pod disruption budget with the specified name, selector, and desired minimum available pods Usage $ poddisruptionbudget NAME --selector=SELECTOR --min-available=N [--dry-run]

priorityclass

Create a priorityclass named high-priority kubectl create priorityclass default-priority --value=1000 --description="high priority" Create a priorityclass named default-priority that considered as the global default priority kubectl create priorityclass default-priority --value=1000 --global-default=true --description="default priority" Create a priorityclass with the specified name, value, globalDefault and description Usage $ priorityclass NAME --value=VALUE --global-default=BOOL [--dry-run]

create

Create a resource from a file or from stdin. JSON and YAML formats are accepted. Usage $ create -f FILENAME

secret

Create a secret using specified subcommand. Usage $ secret

expose

Create a service for a replicated nginx, which serves on port 80 and connects to the containers on port 8000. kubectl expose rc nginx --port=80 --target-port=8000 Create a service for a replication controller identified by type and name specified in "nginx-controller.yaml", which serves on port 80 and connects to the containers on port 8000. kubectl expose -f nginx-controller.yaml --port=80 --target-port=8000 Create a service for a pod valid-pod, which serves on port 444 with the name "frontend" kubectl expose pod valid-pod --port=444 --name=frontend Create a second service based on the above service, exposing the container port 8443 as port 443 with the name "nginx-https" kubectl expose service nginx --port=443 --target-port=8443 --name=nginx-https Create a service for a replicated streaming application on port 4100 balancing UDP traffic and named 'video-stream'. kubectl expose rc streamer --port=4100 --protocol=udp --name=video-stream Create a service for a replicated nginx using replica set, which serves on port 80 and connects to the containers on port 8000. kubectl expose rs nginx --port=80 --target-port=8000 Create a service for an nginx deployment, which serves on port 80 and connects to the containers on port 8000. kubectl expose deployment nginx --port=80 --target-port=8000 Expose a resource as a new Kubernetes service. Looks up a deployment, service, replica set, replication controller or pod by name and uses the selector for that resource as the selector for a new service on the specified port. A deployment or replica set will be exposed as a service only if its selector is convertible to a selector that service supports, i.e. when the selector contains only the matchLabels component. Note that if no port is specified via --port and the exposed resource has multiple ports, all will be re-used by the new service. Also if no labels are specified, the new service will re-use the labels from the resource it exposes. Possible resources include (case insensitive): pod (po), service (svc), replicationcontroller (rc), deployment (deploy), replicaset (rs) Usage $ expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type]

service

Create a service using specified subcommand. Usage $ service

delete

Delete a pod using the type and name specified in pod.json. kubectl delete -f ./pod.json Delete a pod based on the type and name in the JSON passed into stdin. cat pod.json | kubectl delete -f - Delete pods and services with same names "baz" and "foo" kubectl delete pod,service baz foo Delete pods and services with label name=myLabel. kubectl delete pods,services -l name=myLabel Delete a pod with minimal delay kubectl delete pod foo --now Force delete a pod on a dead node kubectl delete pod foo --grace-period=0 --force Delete all pods kubectl delete pods --all Delete resources by filenames, stdin, resources and names, or by resources and label selector. JSON and YAML formats are accepted. Only one type of the arguments may be specified: filenames, resources and names, or resources and label selector. Some resources, such as pods, support graceful deletion. These resources define a default period before they are forcibly terminated (the grace period) but you may override that value with the --grace-period flag, or pass --now to set a grace-period of 1. Because these resources often represent entities in the cluster, deletion may not be acknowledged immediately. If the node hosting a pod is down or cannot reach the API server, termination may take significantly longer than the grace period. To force delete a resource, you must pass a grace period of 0 and specify the --force flag. IMPORTANT: Force deleting pods does not wait for confirmation that the pod's processes have been terminated, which can leave those processes running until the node detects the deletion and completes graceful deletion. If your processes use shared storage or talk to a remote API and depend on the name of the pod to identify themselves, force deleting those pods may result in multiple processes running on different machines using the same identification which may lead to data corruption or inconsistency. Only force delete pods when you are sure the pod is terminated, or if your application can tolerate multiple copies of the same pod running at once. Also, if you force delete pods the scheduler may place new pods on those nodes before the node has released those resources and causing those pods to be evicted immediately. Note that the delete command does NOT do resource version checks, so if someone submits an update to a resource right when you submit a delete, their update will be lost along with the rest of the resource. Usage $ delete ([-f FILENAME] | TYPE [(NAME | -l label | --all)])

config delete-context

Delete the context for the minikube cluster kubectl config delete-context minikube Delete the specified context from the kubeconfig Usage $ delete-context NAME

config delete-cluster

Delete the minikube cluster kubectl config delete-cluster minikube Delete the specified cluster from the kubeconfig Usage $ delete-cluster NAME

certificate deny

Deny a certificate signing request. kubectl certificate deny allows a cluster admin to deny a certificate signing request (CSR). This action tells a certificate signing controller to not to issue a certificate to the requestor. Usage $ deny (-f FILENAME | NAME)

describe

Describe a node kubectl describe nodes kubernetes-node-emt8.c.myproject.internal Describe a pod kubectl describe pods/nginx Describe a pod identified by type and name in "pod.json" kubectl describe -f pod.json Describe all pods kubectl describe pods Describe pods by label name=myLabel kubectl describe po -l name=myLabel Describe all pods managed by the 'frontend' replication controller (rc-created pods # get the name of the rc as a prefix in the pod the name). kubectl describe pods frontend Show details of a specific resource or group of resources Print a detailed description of the selected resources, including related resources such as events or controllers. You may select a single object by name, all objects of that type, provide a name prefix, or label selector. For example: $ kubectl describe TYPE NAME_PREFIX will first check for an exact match on TYPE and NAME PREFIX. If no such resource exists, it will output details for every resource that has a name prefixed with NAME PREFIX. Use "kubectl api-resources" for a complete list of supported resources. Usage $ describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME)

edit

Edit the service named 'docker-registry': kubectl edit svc/docker-registry Use an alternative editor KUBE_EDITOR="nano" kubectl edit svc/docker-registry Edit the job 'myjob' in JSON using the v1 API format: kubectl edit job.v1.batch/myjob -o json Edit the deployment 'mydeployment' in YAML and save the modified config in its annotation: kubectl edit deployment/mydeployment -o yaml --save-config Edit a resource from the default editor. The edit command allows you to directly edit any API resource you can retrieve via the command line tools. It will open the editor defined by your KUBE _EDITOR, or EDITOR environment variables, or fall back to 'vi' for Linux or 'notepad' for Windows. You can edit multiple objects, although changes are applied one at a time. The command accepts filenames as well as command line arguments, although the files you point to must be previously saved versions of resources. Editing is done with the API version used to fetch the resource. To edit using a specific API version, fully-qualify the resource, version, and group. The default format is YAML. To edit in JSON, specify "-o json". The flag --windows-line-endings can be used to force Windows line endings, otherwise the default for your operating system will be used. In the event an error occurs while updating, a temporary file will be created on disk that contains your unapplied changes. The most common error when updating a resource is another editor changing the resource on the server. When this occurs, you will have to apply your changes to the newer version of the resource, or update your temporary saved copy to include the latest resource version. Usage $ edit (RESOURCE/NAME | -f FILENAME)

exec

Get output from running 'date' from pod 123456-7890, using the first container by default kubectl exec 123456-7890 date Get output from running 'date' in ruby-container from pod 123456-7890 kubectl exec 123456-7890 -c ruby-container date Switch to raw terminal mode, sends stdin to 'bash' in ruby-container from pod 123456-7890 # and sends stdout/stderr from 'bash' back to the client kubectl exec 123456-7890 -c ruby-container -i -t -- bash -il List contents of /usr from the first container of pod 123456-7890 and sort by modification time. # If the command you want to execute in the pod has any flags in common (e.g. -i), # you must use two dashes (--) to separate your command's flags/arguments. # Also note, do not surround your command and its flags/arguments with quotes # unless that is how you would execute it normally (i.e., do ls -t /usr, not "ls -t /usr"). kubectl exec 123456-7890 -i -t -- ls -t /usr Execute a command in a container. Usage $ exec POD [-c CONTAINER] -- COMMAND [args...]

attach

Get output from running pod 123456-7890, using the first container by default kubectl attach 123456-7890 Get output from ruby-container from pod 123456-7890 kubectl attach 123456-7890 -c ruby-container Switch to raw terminal mode, sends stdin to 'bash' in ruby-container from pod 123456-7890 # and sends stdout/stderr from 'bash' back to the client kubectl attach 123456-7890 -c ruby-container -i -t Get output from the first pod of a ReplicaSet named nginx kubectl attach rs/nginx Attach to a process that is already running inside an existing container. Usage $ attach (POD | TYPE/NAME) -c CONTAINER

explain

Get the documentation of the resource and its fields kubectl explain pods Get the documentation of a specific field of a resource kubectl explain pods.spec.containers List the fields for supported resources This command describes the fields associated with each supported API resource. Fields are identified via a simple JSONPath identifier: .[.] Add the --recursive flag to display all of the fields at once without descriptions. Information about each field is retrieved from the server in OpenAPI format. Use "kubectl api-resources" for a complete list of supported resources. Usage $ explain RESOURCE

auth

Inspect authorization Usage $ auth

completion

Installing bash completion on macOS using homebrew ## If running Bash 3.2 included with macOS brew install bash-completion brew install bash-completion@2 kubectl completion bash > $(brew --prefix)/etc/bash_completion.d/kubectl Installing bash completion on Linux ## Load the kubectl completion code for bash into the current shell source <(kubectl completion bash) kubectl completion bash > ~/.kube/completion.bash.inc printf " Kubectl shell completion source '$HOME/.kube/completion.bash.inc' " >> $HOME/.bash_profile source $HOME/.bash_profile Load the kubectl completion code for zsh[1] into the current shell source <(kubectl completion zsh) Set the kubectl completion code for zsh[1] to autoload on startup kubectl completion zsh > "${fpath[1]}/_kubectl" Output shell completion code for the specified shell (bash or zsh). The shell code must be evaluated to provide interactive completion of kubectl commands. This can be done by sourcing it from the .bash _profile. Detailed instructions on how to do this are available here: https://kubernetes.io/docs/tasks/tools/install-kubectl/#enabling-shell-autocompletion Note for zsh users: [1] zsh completions are only supported in versions of zsh >= 5.2 Usage $ completion SHELL

get

List all pods in ps output format. kubectl get pods List all pods in ps output format with more information (such as node name). kubectl get pods -o wide List a single replication controller with specified NAME in ps output format. kubectl get replicationcontroller web List deployments in JSON output format, in the "v1" version of the "apps" API group: kubectl get deployments.v1.apps -o json List a single pod in JSON output format. kubectl get -o json pod web-pod-13je7 List a pod identified by type and name specified in "pod.yaml" in JSON output format. kubectl get -f pod.yaml -o json Return only the phase value of the specified pod. kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}} List all replication controllers and services together in ps output format. kubectl get rc,services List one or more resources by their type and names. kubectl get rc/web service/frontend pods/web-pod-13je7 Display one or many resources Prints a table of the most important information about the specified resources. You can filter the list using a label selector and the --selector flag. If the desired resource type is namespaced you will only see results in your current namespace unless you pass --all-namespaces. Uninitialized objects are not shown unless --include-uninitialized is passed. By specifying the output as 'template' and providing a Go template as the value of the --template flag, you can filter the attributes of the fetched resources. Use "kubectl api-resources" for a complete list of supported resources. Usage $ get [(-o|--output=)json|yaml|wide|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...] (TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME ...) [flags]

config get-contexts

List all the contexts in your kubeconfig file kubectl config get-contexts Describe one context in your kubeconfig file. kubectl config get-contexts my-context Displays one or many contexts from the kubeconfig file. Usage $ get-contexts [(-o|--output=)name)]

config get-clusters

List the clusters kubectl knows about kubectl config get-clusters Display clusters defined in the kubeconfig. Usage $ get-clusters

port-forward

Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod kubectl port-forward pod/mypod 5000 6000 Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in a pod selected by the deployment kubectl port-forward deployment/mydeployment 5000 6000 Listen on port 8888 locally, forwarding to 5000 in the pod kubectl port-forward pod/mypod 8888:5000 Listen on a random port locally, forwarding to 5000 in the pod kubectl port-forward pod/mypod :5000 Forward one or more local ports to a pod. Use resource type/name such as deployment/mydeployment to select a pod. Resource type defaults to 'pod' if omitted. If there are multiple pods matching the criteria, a pod will be selected automatically. The forwarding session ends when the selected pod terminates, and rerun of the command is needed to resume forwarding. Usage $ port-forward TYPE/NAME [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N]

uncordon

Mark node "foo" as schedulable. $ kubectl uncordon foo Mark node as schedulable. Usage $ uncordon NODE

cordon

Mark node "foo" as unschedulable. kubectl cordon foo Mark node as unschedulable. Usage $ cordon NODE

rollout pause

Mark the nginx deployment as paused. Any current state of # the deployment will continue its function, new updates to the deployment will not # have an effect as long as the deployment is paused. kubectl rollout pause deployment/nginx Mark the provided resource as paused Paused resources will not be reconciled by a controller. Use "kubectl rollout resume" to resume a paused resource. Currently only deployments support being paused. Usage $ pause RESOURCE

certificate

Modify certificate resources. Usage $ certificate SUBCOMMAND

config

Modify kubeconfig files using subcommands like "kubectl config set current-context my-context" The loading order follows these rules: If the --kubeconfig flag is set, then only that file is loaded. The flag may only be set once and no merging takes place. If $KUBECONFIG environment variable is set, then it is used a list of paths (normal path delimitting rules for your system). These paths are merged. When a value is modified, it is modified in the file that defines the stanza. When a value is created, it is created in the first file that exists. If no files in the chain exist, then it creates the last file in the list. Otherwise, ${HOME}/.kube/config is used and no merging takes place. Usage $ config SUBCOMMAND

patch

Partially update a node using a strategic merge patch. Specify the patch as JSON. kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' Partially update a node using a strategic merge patch. Specify the patch as YAML. kubectl patch node k8s-node-1 -p $'spec:\n unschedulable: true' Partially update a node identified by the type and name specified in "node.json" using strategic merge patch. kubectl patch -f node.json -p '{"spec":{"unschedulable":true}}' Update a container's image; spec.containers[*].name is required because it's a merge key. kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' Update a container's image using a json patch with positional arrays. kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]' Update field(s) of a resource using strategic merge patch, a JSON merge patch, or a JSON patch. JSON and YAML formats are accepted. Please refer to the models in https://htmlpreview.github.io/?https://github.com/kubernetes/kubernetes/blob/HEAD/docs/api-reference/v1/definitions.html to find if a field is mutable. Usage $ patch (-f FILENAME | TYPE NAME) -p PATCH

options

Print flags inherited by all commands kubectl options Print the list of flags inherited by all commands Usage $ options

cluster-info

Print the address of the master and cluster services kubectl cluster-info Display addresses of the master and services with label kubernetes.io/cluster-service=true To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. Usage $ cluster-info

version

Print the client and server versions for the current context kubectl version Print the client and server version information for the current context Usage $ version

api-resources

Print the supported API Resources kubectl api-resources Print the supported API Resources with more information kubectl api-resources -o wide Print the supported namespaced resources kubectl api-resources --namespaced=true Print the supported non-namespaced resources kubectl api-resources --namespaced=false Print the supported API Resources with specific APIGroup kubectl api-resources --api-group=extensions Print the supported API resources on the server Usage $ api-resources

api-versions

Print the supported API versions kubectl api-versions Print the supported API versions on the server, in the form of "group/version" Usage $ api-versions

auth reconcile

Reconcile rbac resources from a file kubectl auth reconcile -f my-rbac-rules.yaml Reconciles rules for RBAC Role, RoleBinding, ClusterRole, and ClusterRole binding objects. This is preferred to 'apply' for RBAC resources so that proper rule coverage checks are done. Usage $ reconcile -f FILENAME

config rename-context

Rename the context 'old-name' to 'new-name' in your kubeconfig file kubectl config rename-context old-name new-name Renames a context from the kubeconfig file. CONTEXT _NAME is the context name that you wish change. NEW _NAME is the new name you wish to set. Note: In case the context being renamed is the 'current-context', this field will also be updated. Usage $ rename-context CONTEXT_NAME NEW_NAME

replace

Replace a pod using the data in pod.json. kubectl replace -f ./pod.json Replace a pod based on the JSON passed into stdin. cat pod.json | kubectl replace -f - Update a single-container pod's image version (tag) to v4 kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f - Force replace, delete and then re-create the resource kubectl replace --force -f ./pod.json Replace a resource by filename or stdin. JSON and YAML formats are accepted. If replacing an existing resource, the complete resource spec must be provided. This can be obtained by $ kubectl get TYPE NAME -o yaml Please refer to the models in https://htmlpreview.github.io/?https://github.com/kubernetes/kubernetes/blob/HEAD/docs/api-reference/v1/definitions.html to find if a field is mutable. Usage $ replace -f FILENAME

rollout resume

Resume an already paused deployment kubectl rollout resume deployment/nginx Resume a paused resource Paused resources will not be reconciled by a controller. By resuming a resource, we allow it to be reconciled again. Currently only deployments support being resumed. Usage $ resume RESOURCE

logs

Return snapshot logs from pod nginx with only one container kubectl logs nginx Return snapshot logs from pod nginx with multi containers kubectl logs nginx --all-containers=true Return snapshot logs from all containers in pods defined by label app=nginx kubectl logs -lapp=nginx --all-containers=true Return snapshot of previous terminated ruby container logs from pod web-1 kubectl logs -p -c ruby web-1 Begin streaming the logs of the ruby container in pod web-1 kubectl logs -f -c ruby web-1 Display only the most recent 20 lines of output in pod nginx kubectl logs --tail=20 nginx Show all logs from pod nginx written in the last hour kubectl logs --since=1h nginx Return snapshot logs from first container of a job named hello kubectl logs job/hello Return snapshot logs from container nginx-1 of a deployment named nginx kubectl logs deployment/nginx -c nginx-1 Print the logs for a container in a pod or specified resource. If the pod has only one container, the container name is optional. Usage $ logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER]

rollout undo

Rollback to the previous deployment kubectl rollout undo deployment/abc Rollback to daemonset revision 3 kubectl rollout undo daemonset/abc --to-revision=3 Rollback to the previous deployment with dry-run kubectl rollout undo --dry-run=true deployment/abc Rollback to a previous rollout. Usage $ undo (TYPE NAME | TYPE/NAME) [flags]

rollout

Rollback to the previous deployment kubectl rollout undo deployment/abc Check the rollout status of a daemonset kubectl rollout status daemonset/foo Manage the rollout of a resource. Valid resource types include: deployments daemonsets statefulsets Usage $ rollout SUBCOMMAND

plugin

Runs a command-line plugin. Plugins are subcommands that are not part of the major command-line distribution and can even be provided by third-parties. Please refer to the documentation and examples for more information about how to install and write your own plugins. Usage $ plugin NAME

scale

Scale a replicaset named 'foo' to 3. kubectl scale --replicas=3 rs/foo Scale a resource identified by type and name specified in "foo.yaml" to 3. kubectl scale --replicas=3 -f foo.yaml If the deployment named mysql's current size is 2, scale mysql to 3. kubectl scale --current-replicas=2 --replicas=3 deployment/mysql Scale multiple replication controllers. kubectl scale --replicas=5 rc/foo rc/bar rc/baz Scale statefulset named 'web' to 3. kubectl scale --replicas=3 statefulset/web Set a new size for a Deployment, ReplicaSet, Replication Controller, or StatefulSet. Scale also allows users to specify one or more preconditions for the scale action. If --current-replicas or --resource-version is specified, it is validated before the scale is attempted, and it is guaranteed that the precondition holds true when the scale is sent to the server. Usage $ scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)

set image

Set a deployment's nginx container image to 'nginx:1.9.1', and its busybox container image to 'busybox'. kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1 Update all deployments' and rc's nginx container's image to 'nginx:1.9.1' kubectl set image deployments,rc nginx=nginx:1.9.1 --all Update image of all containers of daemonset abc to 'nginx:1.9.1' kubectl set image daemonset abc *=nginx:1.9.1 Print result (in yaml format) of updating nginx container image from local file, without hitting the server kubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml Update existing container image(s) of resources. Possible resources include (case insensitive): pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), replicaset (rs) Usage $ image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N

set resources

Set a deployments nginx container cpu limits to "200m" and memory to "512Mi" kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi Set the resource request and limits for all containers in nginx kubectl set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi Remove the resource requests for resources on containers in nginx kubectl set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0 Print the result (in yaml format) of updating nginx container limits from a local, without hitting the server kubectl set resources -f path/to/file.yaml --limits=cpu=200m,memory=512Mi --local -o yaml Specify compute resource requirements (cpu, memory) for any resource that defines a pod template. If a pod is successfully scheduled, it is guaranteed the amount of resource requested, but may burst up to its specified limits. for each compute resource, if a limit is specified and a request is omitted, the request will default to the limit. Possible resources include (case insensitive): Use "kubectl api-resources" for a complete list of supported resources.. Usage $ resources (-f FILENAME | TYPE NAME) ([--limits=LIMITS & --requests=REQUESTS]

config set-credentials

Set only the "client-key" field on the "cluster-admin" # entry, without touching other values: kubectl config set-credentials cluster-admin --client-key=~/.kube/admin.key Set basic auth for the "cluster-admin" entry kubectl config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif Embed client certificate data in the "cluster-admin" entry kubectl config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true Enable the Google Compute Platform auth provider for the "cluster-admin" entry kubectl config set-credentials cluster-admin --auth-provider=gcp Enable the OpenID Connect auth provider for the "cluster-admin" entry with additional args kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar Remove the "client-secret" config value for the OpenID Connect auth provider for the "cluster-admin" entry kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret- Sets a user entry in kubeconfig Specifying a name that already exists will merge new fields on top of existing values. Client-certificate flags: --client-certificate=certfile --client-key=keyfile Bearer token flags: --token=bearer_token Basic auth flags: --username=basic_user --password=basic_password Bearer token and basic auth are mutually exclusive. Usage $ set-credentials NAME [--client-certificate=path/to/certfile] [--client-key=path/to/keyfile] [--token=bearer_token] [--username=basic_user] [--password=basic_password] [--auth-provider=provider_name] [--auth-provider-arg=key=value]

config set-cluster

Set only the server field on the e2e cluster entry without touching other values. kubectl config set-cluster e2e --server=https://1.2.3.4 Embed certificate authority data for the e2e cluster entry kubectl config set-cluster e2e --certificate-authority=~/.kube/e2e/kubernetes.ca.crt Disable cert checking for the dev cluster entry kubectl config set-cluster e2e --insecure-skip-tls-verify=true Sets a cluster entry in kubeconfig. Specifying a name that already exists will merge new fields on top of existing values for those fields. Usage $ set-cluster NAME [--server=server] [--certificate-authority=path/to/certificate/authority] [--insecure-skip-tls-verify=true]

set-last-applied

Set the last-applied-configuration of a resource to match the contents of a file. kubectl apply set-last-applied -f deploy.yaml Execute set-last-applied against each configuration file in a directory. kubectl apply set-last-applied -f path/ Set the last-applied-configuration of a resource to match the contents of a file, will create the annotation if it does not already exist. kubectl apply set-last-applied -f deploy.yaml --create-annotation=true Set the latest last-applied-configuration annotations by setting it to match the contents of a file. This results in the last-applied-configuration being updated as though 'kubectl apply -f ' was run, without updating any other parts of the object. Usage $ set-last-applied -f FILENAME

config set-context

Set the user field on the gce context entry without touching other values kubectl config set-context gce --user=cluster-admin Sets a context entry in kubeconfig Specifying a name that already exists will merge new fields on top of existing values for those fields. Usage $ set-context NAME [--cluster=cluster_nickname] [--user=user_nickname] [--namespace=namespace]

config set

Sets an individual value in a kubeconfig file PROPERTY _NAME is a dot delimited name where each token represents either an attribute name or a map key. Map keys may not contain dots. PROPERTY _VALUE is the new value you wish to set. Binary fields such as 'certificate-authority-data' expect a base64 encoded string unless the --set-raw-bytes flag is used. Usage $ set PROPERTY_NAME PROPERTY_VALUE

config view

Show merged kubeconfig settings. kubectl config view Show merged kubeconfig settings and raw certificate data. kubectl config view --raw Get the password for the e2e user kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' Display merged kubeconfig settings or a specified kubeconfig file. You can use --output jsonpath={...} to extract specific values using a jsonpath expression. Usage $ view

top pod

Show metrics for all pods in the default namespace kubectl top pod Show metrics for all pods in the given namespace kubectl top pod --namespace=NAMESPACE Show metrics for a given pod and its containers kubectl top pod POD_NAME --containers Show metrics for the pods defined by label name=myLabel kubectl top pod -l name=myLabel Display Resource (CPU/Memory/Storage) usage of pods. The 'top pod' command allows you to see the resource consumption of pods. Due to the metrics pipeline delay, they may be unavailable for a few minutes since pod creation. Usage $ pod [NAME | -l label]

run

Start a single instance of nginx. kubectl run nginx --image=nginx Start a single instance of hazelcast and let the container expose port 5701 . kubectl run hazelcast --image=hazelcast --port=5701 Start a single instance of hazelcast and set environment variables "DNS_DOMAIN=cluster" and "POD_NAMESPACE=default" in the container. kubectl run hazelcast --image=hazelcast --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=default" Start a single instance of hazelcast and set labels "app=hazelcast" and "env=prod" in the container. kubectl run hazelcast --image=nginx --labels="app=hazelcast,env=prod" Start a replicated instance of nginx. kubectl run nginx --image=nginx --replicas=5 Dry run. Print the corresponding API objects without creating them. kubectl run nginx --image=nginx --dry-run Start a single instance of nginx, but overload the spec of the deployment with a partial set of values parsed from JSON. kubectl run nginx --image=nginx --overrides='{ "apiVersion": "v1", "spec": { ... } }' Start a pod of busybox and keep it in the foreground, don't restart it if it exits. kubectl run -i -t busybox --image=busybox --restart=Never Start the nginx container using the default command, but use custom arguments (arg1 .. argN) for that command. kubectl run nginx --image=nginx -- <arg1> <arg2> ... <argN> Start the nginx container using a different command and custom arguments. kubectl run nginx --image=nginx --command -- <cmd> <arg1> ... <argN> Start the perl container to compute π to 2000 places and print it out. kubectl run pi --image=perl --restart=OnFailure -- perl -Mbignum=bpi -wle 'print bpi(2000)' Start the cron job to compute π to 2000 places and print it out every 5 minutes. kubectl run pi --schedule="0/5 * * * ?" --image=perl --restart=OnFailure -- perl -Mbignum=bpi -wle 'print bpi(2000)' Create and run a particular image, possibly replicated. Creates a deployment or job to manage the created container(s). Usage $ run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=bool] [--overrides=inline-json] [--command] -- [COMMAND] [args...]

alpha

These commands correspond to alpha features that are not enabled in Kubernetes clusters by default. Usage $ alpha

proxy

To proxy all of the kubernetes api and nothing else, use: $ kubectl proxy --api-prefix=/ To proxy only part of the kubernetes api and also some static files: $ kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/ The above lets you 'curl localhost:8001/api/v1/pods'. # To proxy the entire kubernetes api at a different root, use: $ kubectl proxy --api-prefix=/custom/ The above lets you 'curl localhost:8001/custom/api/v1/pods' # Run a proxy to kubernetes apiserver on port 8011, serving static content from ./local/www/ kubectl proxy --port=8011 --www=./local/www/ Run a proxy to kubernetes apiserver on an arbitrary local port. # The chosen port for the server will be output to stdout. kubectl proxy --port=0 Run a proxy to kubernetes apiserver, changing the api prefix to k8s-api # This makes e.g. the pods api available at localhost:8001/k8s-api/v1/pods/ kubectl proxy --api-prefix=/k8s-api Creates a proxy server or application-level gateway between localhost and the Kubernetes API Server. It also allows serving static content over specified HTTP path. All incoming data enters through one port and gets forwarded to the remote kubernetes API Server port, except for the path matching the static content path. Usage $ proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix]

config unset

Unset the current-context. kubectl config unset current-context Unset namespace in foo context. kubectl config unset contexts.foo.namespace Unsets an individual value in a kubeconfig file PROPERTY _NAME is a dot delimited name where each token represents either an attribute name or a map key. Map keys may not contain dots. Usage $ unset PROPERTY_NAME

set subject

Update a ClusterRoleBinding for serviceaccount1 kubectl set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1 Update a RoleBinding 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 | kubectl set subject --local -f - --user=foo -o yaml Update User, Group or ServiceAccount in a RoleBinding/ClusterRoleBinding. Usage $ subject (-f FILENAME | TYPE NAME) [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run]

set env

Update deployment 'registry' with a new environment variable kubectl set env deployment/registry STORAGE_DIR=/local List the environment variables defined on a deployments 'sample-build' kubectl set env deployment/sample-build --list List the environment variables defined on all pods kubectl set env pods --all --list Output modified deployment in YAML, and does not alter the object on the server kubectl set env deployment/sample-build STORAGE_DIR=/data -o yaml Update all containers in all replication controllers in the project to have ENV=prod kubectl set env rc --all ENV=prod Import environment from a secret kubectl set env --from=secret/mysecret deployment/myapp Import environment from a config map with a prefix kubectl set env --from=configmap/myconfigmap --prefix=MYSQL_ deployment/myapp Import specific keys from a config map kubectl set env --keys=my-example-key --from=configmap/myconfigmap deployment/myapp Remove the environment variable ENV from container 'c1' in all deployment configs kubectl set env deployments --all --containers="c1" ENV- Remove the environment variable ENV from a deployment definition on disk and # update the deployment config on the server kubectl set env -f deploy.json ENV- Set some of the local shell environment into a deployment config on the server env | grep RAILS_ | kubectl set env -e - deployment/registry Update environment variables on a pod template. List environment variable definitions in one or more pods, pod templates. Add, update, or remove container environment variable definitions in one or more pod templates (within replication controllers or deployment configurations). View or modify the environment variable definitions on all containers in the specified pods or pod templates, or just those that match a wildcard. If "--env -" is passed, environment variables can be read from STDIN using the standard env syntax. Possible resources include (case insensitive): pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), job, replicaset (rs) Usage $ env RESOURCE/NAME KEY_1=VAL_1 ... KEY_N=VAL_N

taint

Update node 'foo' with a taint with key 'dedicated' and value 'special-user' and effect 'NoSchedule'. # If a taint with that key and effect already exists, its value is replaced as specified. kubectl taint nodes foo dedicated=special-user:NoSchedule Remove from node 'foo' the taint with key 'dedicated' and effect 'NoSchedule' if one exists. kubectl taint nodes foo dedicated:NoSchedule- Remove from node 'foo' all the taints with key 'dedicated' kubectl taint nodes foo dedicated- Add a taint with key 'dedicated' on nodes having label mylabel=X kubectl taint node -l myLabel=X dedicated=foo:PreferNoSchedule Update the taints on one or more nodes. A taint consists of a key, value, and effect. As an argument here, it is expressed as key=value:effect. The key must begin with a letter or number, and may contain letters, numbers, hyphens, dots, and underscores, up to 253 characters. Optionally, the key can begin with a DNS subdomain prefix and a single '/', like example.com/my-app The value must begin with a letter or number, and may contain letters, numbers, hyphens, dots, and underscores, up to 63 characters. The effect must be NoSchedule, PreferNoSchedule or NoExecute. Currently taint can only apply to node. Usage $ taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N

annotate

Update pod 'foo' with the annotation 'description' and the value 'my frontend'. # If the same annotation is set multiple times, only the last value will be applied kubectl annotate pods foo description='my frontend' Update a pod identified by type and name in "pod.json" kubectl annotate -f pod.json description='my frontend' Update pod 'foo' with the annotation 'description' and the value 'my frontend running nginx', overwriting any existing value. kubectl annotate --overwrite pods foo description='my frontend running nginx' Update all pods in the namespace kubectl annotate pods --all description='my frontend running nginx' Update pod 'foo' only if the resource is unchanged from version 1. kubectl annotate pods foo description='my frontend running nginx' --resource-version=1 Update pod 'foo' by removing an annotation named 'description' if it exists. # Does not require the --overwrite flag. kubectl annotate pods foo description- Update the annotations on one or more resources All Kubernetes objects support the ability to store additional data with the object as annotations. Annotations are key/value pairs that can be larger than labels and include arbitrary string values such as structured JSON. Tools and system extensions may use annotations to store their own data. Attempting to set an annotation that already exists will fail unless --overwrite is set. If --resource-version is specified and does not match the current resource version on the server the command will fail. Use "kubectl api-resources" for a complete list of supported resources. Usage $ annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

label

Update pod 'foo' with the label 'unhealthy' and the value 'true'. kubectl label pods foo unhealthy=true Update pod 'foo' with the label 'status' and the value 'unhealthy', overwriting any existing value. kubectl label --overwrite pods foo status=unhealthy Update all pods in the namespace kubectl label pods --all status=unhealthy Update a pod identified by the type and name in "pod.json" kubectl label -f pod.json status=unhealthy Update pod 'foo' only if the resource is unchanged from version 1. kubectl label pods foo status=unhealthy --resource-version=1 Update pod 'foo' by removing a label named 'bar' if it exists. # Does not require the --overwrite flag. kubectl label pods foo bar- Update the labels on a resource. A label key and value must begin with a letter or number, and may contain letters, numbers, hyphens, dots, and underscores, up to 63 characters each. Optionally, the key can begin with a DNS subdomain prefix and a single '/', like example.com/my-app If --overwrite is true, then existing labels can be overwritten, otherwise attempting to overwrite a label will result in an error. If --resource-version is specified, then updates will use this resource version, otherwise the existing resource-version will be used. Usage $ label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

wait

Usage $ wait resource.group/name [--for=delete|--for condition=available]

config use-context

Use the context for the minikube cluster kubectl config use-context minikube Sets the current-context in a kubeconfig file Usage $ use-context CONTEXT_NAME

view-last-applied

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.yaml -o json View the latest last-applied-configuration annotations by type/name or file. The default output will be printed to stdout in YAML format. One can use -o option to change output format. Usage $ view-last-applied (TYPE [NAME | -l label] | TYPE/NAME | -f FILENAME)

rollout history

View the rollout history of a deployment kubectl rollout history deployment/abc View the details of daemonset revision 3 kubectl rollout history daemonset/abc --revision=3 View previous rollout revisions and configurations. Usage $ history (TYPE NAME | TYPE/NAME) [flags]

rollout status

Watch the rollout status of a deployment kubectl rollout status deployment/nginx Show the status of the rollout. By default 'rollout status' will watch the status of the latest rollout until it's done. If you don't want to wait for the rollout to finish then you can use --watch=false. Note that if a new rollout starts in-between, then 'rollout status' will continue watching the latest revision. If you want to pin to a specific revision and abort if it is rolled over by another revision, use --revision=N where N is the revision you need to watch for. Usage $ status (TYPE NAME | TYPE/NAME) [flags]

top node

node Show metrics for all nodes kubectl top node Show metrics for a given node kubectl top node NODE_NAME Display Resource (CPU/Memory/Storage) usage of nodes. The top-node command allows you to see the resource consumption of nodes. Usage $ node [NAME | -l label]

secret docker-registry

secret docker-registry If you don't already have a .dockercfg file, you can create a dockercfg secret directly by using: kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL Create a new secret for use with Docker registries. Dockercfg secrets are used to authenticate against Docker registries. When using the Docker command line to push images, you can authenticate to a given registry by running: '$ docker login DOCKER_REGISTRY_SERVER --username=DOCKER_USER --password=DOCKER_PASSWORD --email=DOCKER_EMAIL'. That produces a ~/.dockercfg file that is used by subsequent 'docker push' and 'docker pull' commands to authenticate to the registry. The email address is optional. When creating applications, you may have a Docker registry that requires authentication. In order for the nodes to pull images on your behalf, they have to have the credentials. You can provide this information by creating a dockercfg secret and attaching it to your service account. Usage $ docker-registry NAME --docker-username=user --docker-password=password --docker-email=email [--docker-server=string] [--from-literal=key1=value1] [--dry-run]

set serviceaccount

serviceaccount Set Deployment nginx-deployment's ServiceAccount to serviceaccount1 kubectl set serviceaccount deployment nginx-deployment serviceaccount1 Print the result (in yaml format) of updated nginx deployment with serviceaccount from local file, without hitting apiserver kubectl set sa -f nginx-deployment.yaml serviceaccount1 --local --dry-run -o yaml Update ServiceAccount of pod template resources. Possible resources (case insensitive) can be: replicationcontroller (rc), deployment (deploy), daemonset (ds), job, replicaset (rs), statefulset Usage $ serviceaccount (-f FILENAME | TYPE NAME) SERVICE_ACCOUNT

set selector

set the labels and selector before creating a deployment/service pair. kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f - kubectl create deployment my-dep -o yaml --dry-run | kubectl label --local -f - environment=qa -o yaml | kubectl create -f - Set the selector on a resource. Note that the new selector will overwrite the old selector if the resource had one prior to the invocation of 'set selector'. A selector must begin with a letter or number, and may contain letters, numbers, hyphens, dots, and underscores, up to 63 characters. If --resource-version is specified, then updates will use this resource version, otherwise the existing resource-version will be used. Note: currently selectors can only be set on Service objects. Usage $ selector (-f FILENAME | TYPE NAME) EXPRESSIONS [--resource-version=version]