This task shows you how to delete a StatefulSet. Before you begin This task assumes you have an application running on your cluster represented by a StatefulSet. Deleting a StatefulSet You can delete a StatefulSet in the same way you delete other resources in Kubernetes: use the kubectl delete command, and specify the StatefulSet either by file or by name. kubectl delete -f <file.yaml> kubectl delete statefulsets <statefulset-name> You may need to delete the associated headless service separately after the StatefulSet itself is deleted.

Kubernetes lets you configure single-stack IPv4 networking, single-stack IPv6 networking, or dual stack networking with both network families active. This page explains how.

You can visualize and manage Kubernetes objects with more tools than kubectl and the dashboard. A common set of labels allows tools to work interoperably, describing objects in a common manner that all tools can understand. In addition to supporting tooling, the recommended labels describe applications in a way that can be queried. The metadata is organized around the concept of an application. Kubernetes is not a platform as a service (PaaS) and doesn't have or enforce a formal notion of an application.

The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your cluster, and helps you obtain a deeper understanding of how Kubernetes works.

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.

Deploy the web UI (Kubernetes Dashboard) and access it.

Different ways to change the behavior of your Kubernetes cluster.

FEATURE STATE: Kubernetes v1.31 [alpha] (enabled by default: false) Kubernetes 1.31 includes an alpha feature that allows control plane components to deterministically select a leader via coordinated leader election. This is useful to satisfy Kubernetes version skew constraints during cluster upgrades. Currently, the only builtin selection strategy is OldestEmulationVersion, preferring the leader with the lowest emulation version, followed by binary version, followed by creation timestamp. Enabling coordinated leader election Ensure that CoordinatedLeaderElection feature gate is enabled when you start the API Server: and that the coordination.

Automatically manage the nodes in your cluster to adapt to demand.

Custom resources are extensions of the Kubernetes API. Kubernetes provides two ways to add custom resources to your cluster: The CustomResourceDefinition (CRD) mechanism allows you to declaratively define a new custom API with an API group, kind, and schema that you specify. The Kubernetes control plane serves and handles the storage of your custom resource. CRDs allow you to create new types of resources for your cluster without writing and running a custom API server.