Creating Secret objects using kubectl command line.

FEATURE STATE: Kubernetes v1.33 [beta](enabled by default) This page shows how to configure a user namespace for pods. This allows you to isolate the user running inside the container from the one in the host. A process running as root in a container can run as a different (non-root) user in the host; in other words, the process has full privileges for operations inside the user namespace, but is unprivileged for operations outside the namespace.

FEATURE STATE: Kubernetes v1.34 [stable] This page shows how to assign extended resources to a Container. 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:

In Kubernetes, some objects are owners of other objects. For example, a ReplicaSet is the owner of a set of Pods. These owned objects are dependents of their owner. Ownership is different from the labels and selectors mechanism that some resources also use. For example, consider a Service that creates EndpointSlice objects. The Service uses labels to allow the control plane to determine which EndpointSlice objects are used for that Service.

This page explains how to set a Pod's hostname, potential side effects after configuration, and the underlying mechanics. Default Pod hostname When a Pod is created, its hostname (as observed from within the Pod) is derived from the Pod's metadata.name value. Both the hostname and its corresponding fully qualified domain name (FQDN) are set to the metadata.name value (from the Pod's perspective) apiVersion: v1 kind: Pod metadata: name: busybox-1 spec: containers: - image: busybox:1.

FEATURE STATE: Kubernetes v1.11 [beta] Cloud infrastructure technologies let you run Kubernetes on public, private, and hybrid clouds. Kubernetes believes in automated, API-driven infrastructure without tight coupling between components. The cloud-controller-manager is a Kubernetes control plane component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that only interact with your cluster.

This document describes projected volumes in Kubernetes. Familiarity with volumes is suggested. Introduction A projected volume maps several existing volume sources into the same directory. Currently, the following types of volume sources can be projected: secret downwardAPI configMap serviceAccountToken clusterTrustBundle podCertificate All sources are required to be in the same namespace as the Pod. For more details, see the all-in-one volume design document. Example configuration with a secret, a downwardAPI, and a configMap pods/storage/projected-secret-downwardapi-configmap.

Node affinity is a property of Pods that attracts them to a set of nodes (either as a preference or a hard requirement). Taints are the opposite -- they allow a node to repel a set of pods. Tolerations are applied to pods. Tolerations allow the scheduler to schedule pods with matching taints. Tolerations allow scheduling but don't guarantee scheduling: the scheduler also evaluates other parameters as part of its function.

Kubernetes provides a built-in admission controller to enforce the Pod Security Standards. You can configure this admission controller to set cluster-wide defaults and exemptions. Before you begin Following an alpha release in Kubernetes v1.22, Pod Security Admission became available by default in Kubernetes v1.23, as a beta. From version 1.25 onwards, Pod Security Admission is generally available. To check the version, enter kubectl version. If you are not running Kubernetes 1.

A HorizontalPodAutoscaler (HPA for short) automatically updates a workload resource (such as a Deployment or StatefulSet), with the aim of automatically scaling the workload to match demand. Horizontal scaling means that the response to increased load is to deploy more Pods. This is different from vertical scaling, which for Kubernetes would mean assigning more resources (for example: memory or CPU) to the Pods that are already running for the workload.