The official command-line client for Kubernetes is kubectl, which interacts with the API server to perform CRUD operations on resources and stream logs or exec sessions. Common commands include kubectl get, kubectl describe, kubectl create, kubectl apply, kubectl delete, kubectl edit, and kubectl patch. For example, kubectl apply -f file.yaml applies the configuration in the YAML file to the cluster, creating or updating the described resources to match the desired state. The flag kubectl get pods -A lists all Pods across all namespaces, and kubectl logs <pod> [-c <container>] retrieves container logs, with --previous showing prior runs and -f enabling live tailing. kubectl exec runs a new command in a container, while kubectl attach connects to the main process's STDIN/STDOUT. kubectl port-forward forwards a local port to a port in a Pod for debugging without exposing the Pod cluster-wide. Forceful deletion with --grace-period=0 --force removes a Pod from the API server immediately without sending SIGTERM, which can cause data loss or in-flight errors.
Kubernetes is extensible through Custom Resource Definitions (CRDs), which extend the API by defining new resource types with their own OpenAPI v3-validated schemas, and Operators, which package, deploy, and manage Kubernetes applications by combining CRDs with custom controllers that encode operational knowledge. Labels and annotations both attach key-value metadata to objects: Labels are identifying and used by selectors and Service meshes for grouping, while annotations are non-identifying and typically consumed by tools, libraries, or operators for configuration. For application packaging, Helm charts bundle pre-configured Kubernetes resources templated with Go templates and parameterized via a values.yaml file, and each installed chart becomes a Helm release with its own name, namespace, version history, and support for upgrades, rollbacks, and uninstalls.
Cluster bootstrapping is handled by kubeadm, the official tool that creates a minimum viable, conformant cluster, including certificate issuance, control plane initialization, and node join. The Kubernetes release cadence is approximately three minor releases per year, with each minor release supported for about 14 months (9 months active and 5 months of security-only support). Cluster state is held in etcd, which requires a quorum and serves as the source of truth for all Kubernetes objects, while the self-healing nature of the control loops continuously observes actual state versus desired state, replacing failed Pods, rescheduling workloads after node loss, and removing unready Pods from Service backends.