Synopsis Roll back to a previous rollout. kubectl rollout undo (TYPE NAME | TYPE/NAME) [flags] Examples # Roll back to the previous deployment kubectl rollout undo deployment/abc # Roll back to daemonset revision 3 kubectl rollout undo daemonset/abc --to-revision=3 # Roll back to the previous deployment with dry-run kubectl rollout undo --dry-run=server deployment/abc 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 Describe fields and structure of various resources. This command describes the fields associated with each supported API resource. Fields are identified via a simple JSONPath identifier: <type>.<fieldName>[.<fieldName>] Information about each field is retrieved from the server in OpenAPI format. Use "kubectl api-resources" for a complete list of supported resources. kubectl explain TYPE [--recursive=FALSE|TRUE] [--api-version=api-version-group] [--output=plaintext|plaintext-openapiv2] Examples # Get the documentation of the resource and its fields kubectl explain pods # Get all the fields in the resource kubectl explain pods --recursive # Get the explanation for deployment in supported api versions kubectl explain deployments --api-version=apps/v1 # Get the documentation of a specific field of a resource kubectl explain pods.

Stateless Applications Exposing an External IP Address to Access an Application in a Cluster Example: Deploying PHP G...

This tutorial shows you how to build and deploy a simple (not production ready), multi-tier web application using Kubernetes and Docker. This example consists of the following components: A single-instance Redis to store guestbook entries Multiple web frontend instances Objectives Start up a Redis leader. Start up two Redis followers. Start up the guestbook frontend. Expose and view the Frontend Service. Clean up. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.

This page provides an overview of authentication. Users in Kubernetes All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users. It is assumed that a cluster-independent service manages normal users in the following ways: an administrator distributing private keys a user store like Keystone or Google Accounts a file with a list of usernames and passwords In this regard, Kubernetes does not have objects which represent normal user accounts.

FEATURE STATE: Kubernetes v1.22 [stable] (enabled by default: true) Kubernetes supports multiple appliers collaborating to manage the fields of a single object. Server-Side Apply provides an optional mechanism for your cluster's control plane to track changes to an object's fields. At the level of a specific resource, Server-Side Apply records and tracks information about control over the fields of that object. Server-Side Apply helps users and controllers manage their resources through declarative configuration.

A ServiceAccount provides an identity for processes that run in a Pod. A process inside a Pod can use the identity of its associated service account to authenticate to the cluster's API server. For an introduction to service accounts, read configure service accounts. This task guide explains some of the concepts behind ServiceAccounts. The guide also explains how to obtain or revoke tokens that represent ServiceAccounts. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.

Synopsis Update the user, group, or service account in a role binding or cluster role binding. kubectl set subject (-f FILENAME | TYPE NAME) [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none] Examples # Update a cluster role binding for serviceaccount1 kubectl set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1 # Update a role binding 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=client | kubectl set subject --local -f - --user=foo -o yaml Options --all Select all resources, in the namespace of the specified resource types

Synopsis Restart a resource. Resource rollout will be restarted. kubectl rollout restart RESOURCE Examples # Restart all deployments in the test-namespace namespace kubectl rollout restart deployment -n test-namespace # Restart a deployment kubectl rollout restart deployment/nginx # Restart a daemon set kubectl rollout restart daemonset/abc # Restart deployments with the app=nginx label kubectl rollout restart deployment --selector=app=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 Display resource (CPU/memory) usage. The top command allows you to see the resource consumption for nodes or pods. This command requires Metrics Server to be correctly configured and working on the server. kubectl top [flags] Options -h, --help help for top --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.