This page explains two different approaches to setting up a highly available Kubernetes cluster using kubeadm: With stacked control plane nodes. This approach requires less infrastructure. The etcd members and control plane nodes are co-located. With an external etcd cluster. This approach requires more infrastructure. The control plane nodes and etcd members are separated. Before proceeding, you should carefully consider which approach best meets the needs of your applications and environment.

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 tutorial provides an introduction to managing applications with StatefulSets. It demonstrates how to create, delete, scale, and update the Pods of StatefulSets. Before you begin Before you begin this tutorial, you should familiarize yourself with the following Kubernetes concepts: Pods Cluster DNS Headless Services PersistentVolumes PersistentVolumes Provisioning The kubectl command line tool You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.

Extend kubectl by creating and installing kubectl plugins.

This page shows you how to configure a Pod to use a PersistentVolumeClaim for storage. Here is a summary of the process: You, as cluster administrator, create a PersistentVolume backed by physical storage. You do not associate the volume with any Pod. You, now taking the role of a developer / cluster user, create a PersistentVolumeClaim that is automatically bound to a suitable PersistentVolume. You create a Pod that uses the above PersistentVolumeClaim for storage.

This page shows how to configure Pods so that they will be assigned particular Quality of Service (QoS) classes. Kubernetes uses QoS classes to make decisions about evicting Pods when Node resources are exceeded. When Kubernetes creates a Pod it assigns one of these QoS classes to the Pod: Guaranteed Burstable BestEffort Note:Kubernetes assigns the QoS class when the Pod is created, and it remains unchanged for the lifetime of the Pod.

This page provides an overview of authentication in Kubernetes, with a focus on authentication to the Kubernetes API. 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.

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, and how to (optionally) bind a ServiceAccount's validity to the lifetime of an API object.

FEATURE STATE: Kubernetes v1.22 [stable](enabled by default) 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.

FEATURE STATE: Kubernetes v1.35 [beta](disabled by default) Kubernetes relies on API data being actively re-written, to support some maintenance activities related to at rest storage. Two prominent examples are the versioned schema of stored resources (that is, the preferred storage schema changing from v1 to v2 for a given resource) and encryption at rest (that is, rewriting stale data based on a change in how the data should be encrypted).