This page contains a list of commonly used kubectl commands and flags. Note:These instructions are for Kubernetes v1.34. To check the version, use the kubectl version command. Kubectl autocomplete BASH source <(kubectl completion bash) # set up autocomplete in bash into the current shell, bash-completion package should be installed first. echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell. You can also use a shorthand alias for kubectl that also works with completion:

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.

Synopsis Create a ClusterIP service with the specified name. kubectl create service clusterip NAME [--tcp=<port>:<targetPort>] [--dry-run=server|client|none] Examples # 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" 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. Only applies to golang and jsonpath output formats.

Synopsis Set 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. kubectl config 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] [--exec-command=exec_command] [--exec-api-version=exec_api_version] [--exec-arg=arg] [--exec-env=key=value] Examples # Set only the "client-key" field on the "cluster-admin" # entry, without touching other values kubectl config set-credentials cluster-admin --client-key=~/.

FEATURE STATE: Kubernetes v1.30 [stable] This page provides an overview of Validating Admission Policy. What is Validating Admission Policy? Validating admission policies offer a declarative, in-process alternative to validating admission webhooks. Validating admission policies use the Common Expression Language (CEL) to declare the validation rules of a policy. Validation admission policies are highly configurable, enabling policy authors to define policies that can be parameterized and scoped to resources as needed by cluster administrators.

In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes control plane components, specifically kube-apiserver. In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly recommend using client TLS certificates on nodes. The normal process of bootstrapping these components, especially worker nodes that need certificates so they can communicate safely with kube-apiserver, can be a challenging process as it is often outside of the scope of Kubernetes and requires significant additional work.

FEATURE STATE: Kubernetes v1.33 [beta] Kubernetes 1.34 includes optional declarative validation for APIs. When enabled, the Kubernetes API server can use this mechanism rather than the legacy approach that relies on hand-written Go code (validation.go files) to ensure that requests against the API are valid. Kubernetes developers, and people extending the Kubernetes API, can define validation rules directly alongside the API type definitions (types.go files). Code authors define pecial comment tags (e.

Note This tutorial applies only for new clusters. Pod Security Admission is an admission controller that applies Pod Security Standards when pods are created. It is a feature GA'ed in v1.25. In this tutorial, you will enforce the baseline Pod Security Standard, one namespace at a time. You can also apply Pod Security Standards to multiple namespaces at once at the cluster level. For instructions, refer to Apply Pod Security Standards at the cluster level.

This page contains an overview of the client libraries for using the Kubernetes API from various programming languages. To write applications using the Kubernetes REST API, you do not need to implement the API calls and request/response types yourself. You can use a client library for the programming language you are using. Client libraries often handle common tasks such as authentication for you. Most client libraries can discover and use the Kubernetes Service Account to authenticate if the API client is running inside the Kubernetes cluster, or can understand the kubeconfig file format to read the credentials and the API Server address.

The Kubernetes model for connecting containers Now that you have a continuously running, replicated application you can expose it on a network. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. Kubernetes gives every pod its own cluster-private IP address, so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT.