Manage security and best-practices with policies.

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.

Removed feature PodSecurityPolicy was deprecated in Kubernetes v1.21, and removed from Kubernetes in v1.25. Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using either or both: Pod Security Admission a 3rd party admission plugin, that you deploy and configure yourself For a migration guide, see Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller. For more information on the removal of this API, see PodSecurityPolicy Deprecation: Past, Present, and Future.

In a Kubernetes cluster, a node can be shut down in a planned graceful way or unexpectedly because of reasons such as a power outage or something else external. A node shutdown could lead to workload failure if the node is not drained before the shutdown. A node shutdown can be either graceful or non-graceful. Graceful node shutdown The kubelet attempts to detect node system shutdown and terminates pods running on the node.

This page explains how to upgrade a Linux Worker Nodes created with kubeadm. Before you begin You need to have shell access to all the nodes, 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. To check the version, enter kubectl version.

Production-Grade Container Orchestration

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.

Concepts and resources behind networking in Kubernetes.

This document catalogs the communication paths between the API server and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider). Node to Control Plane Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminates at the API server.

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.