The kubectl command-line tool is the primary interface to the Kubernetes API, and a working knowledge of its verbs and flags is essential. kubectl get lists resources, with flags like -A for all namespaces, -o wide for additional columns such as node and IP, -o yaml or -o json for full output, --show-labels for inspecting labels, and -o jsonpath for scripted field extraction. kubectl describe shows detailed status including events, which makes it the first stop when debugging image pull failures, OOMKilled events, or probe failures. kubectl logs retrieves container output with -f to follow, --tail=N for the last N lines, -c to target a specific container in a multi-container Pod, --previous for the previous instance's logs, and -l to select by label. kubectl exec runs commands inside a container, supporting interactive shells with -it and multi-container targeting with -c, while kubectl cp moves files in and out using tar streams, kubectl port-forward opens local ports to Pods or Services for debugging, and kubectl debug launches an ephemeral container in a running Pod, the only way to shell into distroless images.
Lifecycle management uses kubectl apply -f to create or update resources from declarative manifests, kubectl delete -f or kubectl delete
Cluster access is configured through kubeconfig files in ~/.kube/config that bundle clusters (apiserver URL and CA cert), users (certificates, tokens, or OIDC), and contexts (cluster + user + namespace triples), and kubectl config use-context switches between them while --as and --as-group impersonate users for permission debugging. For node maintenance, kubectl cordon marks a node unschedulable without evicting workloads, kubectl drain safely evicts Pods while respecting PodDisruptionBudgets and is often combined with --ignore-daemonsets and --force for bare Pods, kubectl uncordon reverses the operation, and kubectl taint applies and removes taints; kubectl label and kubectl annotate manage metadata, while kubectl explain provides inline documentation for any resource field. Beyond the core CLI, kubectl proxy exposes a local HTTP proxy to the apiserver, and kubectl api-resources plus kubectl api-versions list everything the cluster supports.
The Kubernetes API itself is the central REST interface that all components use. It is organized into API groups such as apps/v1, batch/v1, and networking.k8s.io/v1, with core resources like Pod and Service in the core group. API versions progress through alpha (disabled by default, may break), beta (enabled by default, more stable), and GA/stable (versioned like v1, safe for production), with deprecated APIs eventually removed. Custom Resources extend the API with new object types you define yourself, and a CustomResourceDefinition registers a new kind with the apiserver. Combined with a custom controller, a CRD becomes a control loop, and this Operator pattern encodes operational knowledge such as backups, upgrades, scaling, and healing for specific applications; examples include etcd-operator, postgres-operator, and cert-manager. The Operator Framework provides tooling like the Operator SDK for scaffolding, the Operator Lifecycle Manager for installation and upgrades, and OperatorHub.io as a public registry. Observability typically combines the Metrics Server for short-term resource usage feeding the HPA and kubectl top, kube-state-metrics for raw object state metrics consumed by Prometheus, and the apiserver's audit log for security-relevant events when --audit-policy-file and --audit-log-path are configured.