Synopsis Attach to a process that is already running inside an existing container. kubectl attach (POD | TYPE/NAME) -c CONTAINER Examples # Get output from running pod mypod; use the 'kubectl.kubernetes.io/default-container' annotation # for selecting the container to be attached or the first container in the pod will be chosen kubectl attach mypod # Get output from ruby-container from pod mypod kubectl attach mypod -c ruby-container # Switch to raw terminal mode; sends stdin to 'bash' in ruby-container from pod mypod # and sends stdout/stderr from 'bash' back to the client kubectl attach mypod -c ruby-container -i -t # Get output from the first pod of a replica set named nginx kubectl attach rs/nginx Options -c, --container string Container name.

Synopsis Modify certificate resources. kubectl certificate SUBCOMMAND Options -h, --help help for certificate --as string Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --as-group strings Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --as-uid string UID to impersonate for the operation. --cache-dir string     Default: "$HOME/.kube/cache" Default cache directory --certificate-authority string Path to a cert file for the certificate authority

Details of the metric data that Kubernetes components export.

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 serviceaccount 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 Create a deployment with the specified name. kubectl create deployment NAME --image=image -- [COMMAND] [args...] Examples # Create a deployment named my-dep that runs the busybox image kubectl create deployment my-dep --image=busybox # Create a deployment with a command kubectl create deployment my-dep --image=busybox -- date # Create a deployment named my-dep that runs the nginx image with 3 replicas kubectl create deployment my-dep --image=nginx --replicas=3 # Create a deployment named my-dep that runs the busybox image and expose port 5701 kubectl create deployment my-dep --image=busybox --port=5701 # Create a deployment named my-dep that runs multiple containers kubectl create deployment my-dep --image=busybox:latest --image=ubuntu:latest --image=nginx 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 LoadBalancer service with the specified name. kubectl create service loadbalancer NAME [--tcp=port:targetPort] [--dry-run=server|client|none] Examples # Create a new LoadBalancer service named my-lbs kubectl create service loadbalancer my-lbs --tcp=5678:8080 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. --dry-run string[="unchanged"]     Default: "none" Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it.

This page outlines the differences in how resources are managed between Linux and Windows. On Linux nodes, cgroups are used as a pod boundary for resource control. Containers are created within that boundary for network, process and file system isolation. The Linux cgroup APIs can be used to gather CPU, I/O, and memory use statistics. In contrast, Windows uses a job object per container with a system namespace filter to contain all processes in a container and provide logical isolation from the host.

This page shows how to access clusters using the Kubernetes API. Before you begin You 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:

FEATURE STATE: Kubernetes v1.26 [stable] Kubernetes keeps many aspects of how pods execute on nodes abstracted from the user. This is by design. However, some workloads require stronger guarantees in terms of latency and/or performance in order to operate acceptably. The kubelet provides methods to enable more complex workload placement policies while keeping the abstraction free from explicit placement directives. For detailed information on resource management, please refer to the Resource Management for Pods and Containers documentation.

The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs. The additional APIs can either be ready-made solutions such as a metrics server, or APIs that you develop yourself. The aggregation layer is different from Custom Resources, which are a way to make the kube-apiserver recognise new kinds of object. Aggregation layer The aggregation layer runs in-process with the kube-apiserver.