Synopsis Create an ingress with the specified name. kubectl create ingress NAME --rule=host/path=service:port[,tls[=secret]] Examples # Create a single ingress called 'simple' that directs requests to foo.com/bar to svc # svc1:8080 with a TLS secret "my-cert" kubectl create ingress simple --rule="foo.com/bar=svc1:8080,tls=my-cert" # Create a catch all ingress of "/path" pointing to service svc:port and Ingress Class as "otheringress" kubectl create ingress catch-all --class=otheringress --rule="/path=svc:port" # Create an ingress with two annotations: ingress.

Synopsis Create a priority class with the specified name, value, globalDefault and description. kubectl create priorityclass NAME --value=VALUE --global-default=BOOL [--dry-run=server|client|none] Examples # Create a priority class named high-priority kubectl create priorityclass high-priority --value=1000 --description="high priority" # Create a priority class named default-priority that is considered as the global default priority kubectl create priorityclass default-priority --value=1000 --global-default=true --description="default priority" # Create a priority class named high-priority that cannot preempt pods with lower priority kubectl create priorityclass high-priority --value=1000 --description="high priority" --preemption-policy="Never" 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 Request a service account token. kubectl create token SERVICE_ACCOUNT_NAME Examples # Request a token to authenticate to the kube-apiserver as the service account "myapp" in the current namespace kubectl create token myapp # Request a token for a service account in a custom namespace kubectl create token myapp --namespace myns # Request a token with a custom expiration kubectl create token myapp --duration 10m # Request a token with a custom audience kubectl create token myapp --audience https://example.

FEATURE STATE: Kubernetes v1.18 [stable] This page shows how to configure Group Managed Service Accounts (GMSA) for Pods and containers that will run on Windows nodes. Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources.

Kubernetes offers two distinct ways for clients that run within your cluster, or that otherwise have a relationship to your cluster's control plane to authenticate to the API server. A service account provides an identity for processes that run in a Pod, and maps to a ServiceAccount object. When you authenticate to the API server, you identify yourself as a particular user. Kubernetes recognises the concept of a user, however, Kubernetes itself does not have a User API.

FEATURE STATE: Kubernetes v1.35 [stable](enabled by default) This page shows you how to allocate devices to your Pods by using dynamic resource allocation (DRA). These instructions are for workload operators. Before reading this page, familiarize yourself with how DRA works and with DRA terminology like ResourceClaims and ResourceClaimTemplates. For more information, see Dynamic Resource Allocation (DRA). About device allocation with DRA As a workload operator, you can claim devices for your workloads by creating ResourceClaims or ResourceClaimTemplates.

This page explains how to add versioning information to CustomResourceDefinitions, to indicate the stability level of your CustomResourceDefinitions or advance your API to a new version with conversion between API representations. It also describes how to upgrade an object from one version to another. 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.

FEATURE STATE: Kubernetes v1.19 [stable] Seccomp stands for secure computing mode and has been a feature of the Linux kernel since version 2.6.12. It can be used to sandbox the privileges of a process, restricting the calls it is able to make from userspace into the kernel. Kubernetes lets you automatically apply seccomp profiles loaded onto a node to your Pods and containers. Identifying the privileges required for your workloads can be difficult.

This page shows how to manually rotate the certificate authority (CA) certificates. 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:

Configure and manage huge pages as a schedulable resource in a cluster.