Synopsis Execute a command in a container. kubectl exec (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...] Examples # Get output from running the 'date' command from pod mypod, using the first container by default kubectl exec mypod -- date # Get output from running the 'date' command in ruby-container from pod mypod kubectl exec mypod -c ruby-container -- date # 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 exec mypod -c ruby-container -i -t -- bash -il # List contents of /usr from the first container of pod mypod and sort by modification time # If the command you want to execute in the pod has any flags in common (e.

Synopsis 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. kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] Examples # To proxy all of the Kubernetes API and nothing else kubectl proxy --api-prefix=/ # To proxy only part of the Kubernetes API and also some static files # You can get pods info with 'curl localhost:8001/api/v1/pods' kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/ # To proxy the entire Kubernetes API at a different root # You can get pods info with 'curl localhost:8001/custom/api/v1/pods' kubectl proxy --api-prefix=/custom/ # Run a proxy to the Kubernetes API server on port 8011, serving static content from .

Synopsis Create a role with single rule. kubectl create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run=server|client|none] Examples # 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.

Synopsis Display events. Prints a table of the most important information about events. You can request events for a namespace, for all namespace, or filtered to only those pertaining to a specified resource. kubectl events [(-o|--output=)json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file] [--for TYPE/NAME] [--watch] [--types=Normal,Warning] Examples # List recent events in the default namespace kubectl events # List recent events in all namespaces kubectl events --all-namespaces # List recent events for the specified pod, then wait for more events and list them as they arrive kubectl events --for pod/web-pod-13je7 --watch # List recent events in YAML format kubectl events -oyaml # List recent only events of type 'Warning' or 'Normal' kubectl events --types=Warning,Normal Options -A, --all-namespaces If present, list the requested object(s) across all namespaces.

Alongside the PR Wrangler, formal approvers, reviewers and members of SIG Docs take week-long shifts triaging and categorising issues for the repository. Duties Each day in a week-long shift the Issue Wrangler will be responsible for: Triaging and tagging incoming issues daily. See Triage and categorize issues for guidelines on how SIG Docs uses metadata. Keeping an eye on stale & rotten issues within the kubernetes/website repository. Maintenance of the Issues board.

This page shows how to build the Kubernetes component and tool reference pages. Before you begin Start with the Prerequisites section in the Reference Documentation Quickstart guide. Follow the Reference Documentation Quickstart to generate the Kubernetes component and tool reference pages. What's next Generating Reference Documentation Quickstart Generating Reference Documentation for kubectl Commands Generating Reference Documentation for the Kubernetes API Contributing to the Upstream Kubernetes Project for Documentation

Synopsis View previous rollout revisions and configurations. kubectl rollout history (TYPE NAME | TYPE/NAME) [flags] Examples # 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 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 Experimental: Wait for a specific condition on one or many resources. The command takes multiple resources and waits until the specified condition is seen in the Status field of every given resource. Alternatively, the command can wait for the given set of resources to be deleted by providing the "delete" keyword as the value to the --for flag. A successful message will be printed to stdout indicating when the specified condition has been met.

FEATURE STATE: Kubernetes v1.25 [stable] You can customize the behavior of the kube-scheduler by writing a configuration file and passing its path as a command line argument. A scheduling Profile allows you to configure the different stages of scheduling in the kube-scheduler. Each stage is exposed in an extension point. Plugins provide scheduling behaviors by implementing one or more of these extension points. You can specify scheduling profiles by running kube-scheduler --config <filename>, using the KubeSchedulerConfiguration v1 struct.

The Kubernetes documentation follows several types of page content: Concept Task Tutorial Reference Content sections Each page content type contains a number of sections defined by Markdown comments and HTML headings. You can add content headings to your page with the heading shortcode. The comments and headings help maintain the structure of the page content types. Examples of Markdown comments defining page content sections: <!-- overview --> <!-- body --> To create common headings in your content pages, use the heading shortcode with a heading string.