Kubernetes Interview Questions

Summary

The control plane holds the cluster's desired state and makes decisions: the API server (the only component that talks to etcd), etcd (the key-value store), the scheduler (assigns pods to nodes) and the controller manager (reconciliation loops such as Deployments and nodes); cloud setups add the cloud controller manager. Each worker node runs the kubelet (starts and monitors the node's pods through the container runtime), a container runtime such as containerd, and usually kube-proxy for Service networking.

Longer Answer

Everything goes through the API server: kubectl, controllers, the scheduler and kubelets all read and write objects there, and components watch for changes rather than calling each other directly. That design is what makes Kubernetes declarative: you store desired state, and independent controllers keep moving actual state towards it.

etcd is the only stateful component, so its backups and health are critical. Managed services (EKS, GKE, AKS) run the control plane for you; you still own nodes, add-ons and workloads.

Key Points

• API server is the hub; only it talks to etcd.
• Scheduler, controller manager, cloud controller manager.
• Nodes: kubelet, container runtime, kube-proxy.
• Components watch the API; nothing calls each other directly.

Summary

kubectl sends the manifest to the API server, which authenticates and authorises the request, runs admission controllers (mutating, then validating), validates the object and stores it in etcd. The Deployment controller creates a ReplicaSet, the ReplicaSet controller creates Pods, the scheduler assigns each Pod to a node, and that node's kubelet pulls images and starts the containers through the runtime, then reports status back.

Longer Answer

Then: the kubelet runs probes; when readiness passes, the EndpointSlice controller adds the pod's IP to the Service's endpoints, and kube-proxy (or the CNI's eBPF data path) routes Service traffic to it. During an update, the Deployment controller scales a new ReplicaSet up and the old one down within maxSurge and maxUnavailable.

Knowing this chain tells you where to look when something is stuck: admission rejection (API error), Pending (scheduling), ContainerCreating or ImagePullBackOff (kubelet/runtime), not ready (probes).

Key Points

• API server: authn, authz, admission, etcd.
• Deployment then ReplicaSet then Pods.
• Scheduler binds; kubelet starts containers.
• Readiness adds the pod to Service endpoints.

Summary

Deployment for stateless, interchangeable replicas (web apps, APIs); StatefulSet for pods needing stable identity and their own storage (databases, Kafka, ZooKeeper); DaemonSet for one pod per node (log collectors, node exporters, CNI agents); Job for run-to-completion tasks; CronJob for Jobs on a schedule.

Longer Answer

• Deployment manages ReplicaSets and supports rolling updates and rollbacks; pods are fungible.
• StatefulSet gives pods stable names (db-0, db-1), stable DNS through a headless Service, ordered startup and shutdown, and a PersistentVolumeClaim per pod from volumeClaimTemplates.
• DaemonSet schedules onto every node (or selected nodes), including new nodes as they join.
• Job retries failed pods up to backoffLimit, can run in parallel, and supports indexed completions.
• CronJob creates Jobs on a cron schedule; set concurrencyPolicy and startingDeadlineSeconds, and make the work idempotent because runs can be missed or duplicated.

Key Points

• Deployment: stateless replicas.
• StatefulSet: identity + per-pod storage.
• DaemonSet: one per node.
• Job/CronJob: run to completion; idempotent work.

Summary

A rolling update creates a new ReplicaSet and shifts pods from old to new gradually, limited by maxSurge (extra pods allowed above the desired count) and maxUnavailable (pods allowed to be unavailable). New pods only count as available once they pass readiness (and minReadySeconds). Roll back with kubectl rollout undo or, better, by reverting the manifest in Git.

Longer Answer

progressDeadlineSeconds marks a rollout as failed if it stalls (for example, new pods never become ready), but Kubernetes does not roll back automatically; tools such as Argo Rollouts or Flagger add automated canary analysis and rollback.

A rolling update only works safely when old and new versions can run side by side (backward-compatible APIs and database schema) and when readiness probes reflect real readiness. maxUnavailable: 0 with maxSurge: 25% keeps full capacity during the rollout at the cost of temporary extra pods.

Key Points

• New ReplicaSet scaled up, old scaled down.
• maxSurge / maxUnavailable control pace.
• Readiness gates progress.
• No automatic rollback; use undo, Git revert or Argo Rollouts.

Summary

A Service gives a stable virtual IP and DNS name in front of a changing set of pods selected by labels. ClusterIP is reachable only inside the cluster; NodePort also opens a port on every node; LoadBalancer provisions a cloud load balancer; ExternalName is a DNS alias to an outside name; a headless Service (clusterIP: None) returns the pod IPs directly in DNS, used by StatefulSets.

Longer Answer

Endpoints are maintained as EndpointSlices containing only ready pods. kube-proxy (iptables, IPVS or nftables mode) or an eBPF data path (such as Cilium) translates the virtual IP to pod IPs on each node.

For HTTP from outside, you usually expose many Services through one Ingress or Gateway rather than one cloud load balancer per Service, which costs more. externalTrafficPolicy: Local preserves the client IP and avoids an extra hop, but only nodes with local pods receive traffic.

Key Points

• Stable VIP and DNS for a label selector.
• ClusterIP, NodePort, LoadBalancer, ExternalName.
• Headless returns pod IPs.
• EndpointSlices hold only ready pods.

Summary

Both hold configuration that pods consume as environment variables or mounted files. Secrets are intended for sensitive data, but by default they are only base64-encoded, stored in etcd, and readable by anyone with get secrets permission in the namespace.

Longer Answer

Harden secrets: enable encryption at rest for etcd (managed services often use a KMS provider), restrict RBAC on secrets tightly (listing secrets is as good as reading them), avoid environment variables for very sensitive values (they leak into crash dumps and child processes; mounted files can also be rotated), and source secrets from a manager (AWS Secrets Manager, Vault, Google Secret Manager) through the External Secrets Operator or the Secrets Store CSI driver. Never commit plain secrets to Git; use Sealed Secrets or SOPS if they must live in a repository.

Mounted ConfigMaps and Secrets update in place (eventually), but environment variables only change when the pod restarts; many apps also need a reload or a rollout to pick up changes.

Key Points

• Base64 is not encryption.
• Encrypt etcd at rest; tight RBAC.
• External secret managers via operators/CSI.
• Env vars need a restart to change.

Summary

The scheduler filters nodes that can run the pod (enough unreserved CPU and memory for its requests, matching node selectors and affinity, tolerated taints, available volumes and ports) and then scores the remaining nodes (spreading, affinity preferences, resource balance) to pick the best.

Longer Answer

• Requests reserve capacity for scheduling; a pod with no requests can be packed onto overloaded nodes.
• nodeSelector / node affinity attract pods to nodes with certain labels (GPU nodes, a specific zone); required... is a hard rule, preferred... a soft one.
• Taints on nodes repel pods unless the pods have matching tolerations: reserve GPU or system nodes, or evict pods from nodes with problems (NoExecute).
• Pod affinity/anti-affinity co-locate or separate pods; topology spread constraints spread replicas evenly across zones or nodes.

A pod stuck in Pending usually means no node passes the filters; kubectl describe pod shows the reasons.

Key Points

• Filter then score.
• Requests reserve capacity.
• Affinity attracts; taints repel unless tolerated.
• Topology spread for zones; describe Pending pods.

Summary

Requests are what the scheduler reserves and what the pod is guaranteed; limits are the maximum it may use. Exceeding the memory limit gets the container OOM-killed; exceeding the CPU limit gets it throttled. QoS classes follow from them: Guaranteed (requests equal limits for all containers), Burstable (some requests or limits set), BestEffort (none), and under node memory pressure BestEffort pods are evicted first.

Longer Answer

Practical guidance many teams follow: always set memory requests and limits (often equal, since memory cannot be throttled), always set CPU requests, and be careful with CPU limits, because CFS quotas throttle bursts in short periods and cause latency spikes even when the node has idle CPU. Size requests from observed usage (VPA recommendations, metrics), not guesses.

Namespaces can enforce defaults and caps with LimitRange and ResourceQuota.

Key Points

• Requests: scheduling and guarantees.
• Limits: memory OOM-kill, CPU throttling.
• Guaranteed, Burstable, BestEffort.
• Careful with CPU limits; size from metrics.

Summary

Readiness decides whether a pod receives traffic; liveness decides whether the container is restarted; a startup probe holds off the other two until a slow-starting app is up. Readiness may reflect whether the instance can serve; liveness should only detect a stuck process and must not depend on external systems.

Longer Answer

If liveness checks the database, a database blip restarts every pod at once and turns a partial outage into a full one. Other tips: give probes realistic timeouts and failure thresholds; use a startup probe instead of a huge initialDelaySeconds; make readiness fail during graceful shutdown so the pod leaves the endpoints; and keep probe endpoints cheap.

Missing readiness probes mean pods receive traffic before they can serve, causing errors during every rollout.

Key Points

• Readiness = traffic; liveness = restart; startup = slow boot.
• No dependency checks in liveness.
• Realistic thresholds; startup probe for slow apps.
• Missing readiness = errors during rollouts.

Deep dive: Site Reliability Engineering interview questions

Summary

When a pod is deleted, Kubernetes marks it terminating, removes it from Service endpoints, runs any preStop hook, sends SIGTERM to the containers and, after terminationGracePeriodSeconds (30 by default), SIGKILL. Endpoint removal and SIGTERM happen in parallel, so the app must keep serving briefly after SIGTERM, finish in-flight requests, then exit.

Longer Answer

Checklist: the application handles SIGTERM (stops accepting new work, drains in-flight requests and background jobs, closes connections); the process actually receives the signal (exec-form ENTRYPOINT, an init such as tini if needed, not a shell that swallows it); a short preStop sleep (a few seconds) covers the delay before load balancers and kube-proxy stop sending traffic; and the grace period is long enough for the longest request or job.

Without this, every deploy, scale-in and node drain produces a burst of 502s.

Key Points

• Endpoint removal and SIGTERM race.
• Handle SIGTERM: drain, then exit.
• preStop sleep for load balancer lag.
• Grace period >= longest request.

Summary

The container starts and exits repeatedly, and Kubernetes backs off between restarts. Check kubectl describe pod (exit code, last state, events), kubectl logs <pod> --previous (logs from the crashed container), and then the usual causes: application error at startup, missing configuration or secret, wrong command, failing liveness probe, or OOMKilled.

Longer Answer

Exit codes help: 137 is SIGKILL (often OOMKilled, or a liveness failure), 143 is SIGTERM, 1 is an application error, 127 is command not found. If the container exits too quickly to inspect, run it with an overridden command (sleep infinity) or use kubectl debug to start an ephemeral debug container or a copy of the pod. Compare with the last working version: what changed in the image, config or dependencies?

Key Points

• describe + logs --previous.
• Exit codes: 137, 143, 1, 127.
• Config, command, probes, OOM.
• kubectl debug / override command to inspect.

Summary

The Horizontal Pod Autoscaler changes the number of replicas based on metrics (CPU, memory, or custom and external metrics); the Vertical Pod Autoscaler recommends or sets CPU and memory requests; the Cluster Autoscaler and Karpenter add and remove nodes so pending pods can be scheduled and empty nodes are removed.

Longer Answer

• HPA needs the metrics server (or a metrics adapter such as Prometheus Adapter or KEDA for queue length and other event sources). CPU-based HPA only works if CPU requests are set and CPU reflects load.
• VPA and HPA should not both act on the same resource metric for the same workload.
• Cluster Autoscaler scales predefined node groups; Karpenter provisions right-sized nodes directly from pending pods' requirements and consolidates under-used nodes, which is often faster and cheaper (mainly on AWS, also on other clouds through providers).

Scaling chains add latency: a traffic spike must be detected, pods created, nodes provisioned (minutes) and images pulled, so keep headroom or over-provision with low-priority placeholder pods.

Key Points

• HPA: replicas; VPA: requests; CA/Karpenter: nodes.
• HPA needs metrics and requests.
• KEDA for event-driven scaling.
• Node scaling takes minutes; keep headroom.

Summary

Roles (namespaced) and ClusterRoles (cluster-wide) list allowed verbs on resources; RoleBindings and ClusterRoleBindings grant them to users, groups or ServiceAccounts. Everything is deny-by-default and permissions are additive.

Longer Answer

Least-privilege practice: give each workload its own ServiceAccount with only the permissions it needs (most apps need none, so disable token automounting); bind people through groups from the identity provider; avoid cluster-admin bindings and wildcard verbs; and audit regularly (kubectl auth can-i --list --as=..., tools such as rbac-lookup or kubectl-who-can).

Dangerous permissions to watch: get/list secrets, create pods (can mount any secret or ServiceAccount in the namespace), escalate/bind/impersonate, and nodes/proxy.

Key Points

• Roles + bindings; deny by default.
• One ServiceAccount per workload.
• No cluster-admin or wildcards.
• Watch secrets, pod create, escalate/impersonate.

Summary

Run containers as non-root, drop Linux capabilities, disallow privilege escalation, use a read-only root filesystem and a seccomp profile, and enforce these with the Pod Security Standards (privileged, baseline, restricted) through Pod Security Admission labels on namespaces, or with a policy engine.

Longer Answer

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities: { drop: ["ALL"] }
  seccompProfile: { type: RuntimeDefault }

PodSecurityPolicy was removed in Kubernetes 1.25; Pod Security Admission replaced it (pod-security.kubernetes.io/enforce: restricted on a namespace). For custom rules (approved registries, required labels, no latest tags) use Kyverno, OPA Gatekeeper, or built-in ValidatingAdmissionPolicy. Add image scanning and signing, NetworkPolicies, and RBAC for defence in depth.

Key Points

• Non-root, drop capabilities, read-only FS, seccomp.
• Pod Security Admission levels per namespace.
• PSP removed in 1.25.
• Kyverno/Gatekeeper/ValidatingAdmissionPolicy for custom rules.

Summary

GitOps uses Git as the source of truth for desired cluster state: changes are made by pull request, and an in-cluster agent (Argo CD or Flux) continuously pulls the repository and reconciles the cluster to match, reporting and optionally correcting drift.

Longer Answer

Benefits: audit trail and review for every change, easy rollback (revert a commit), no CI system holding cluster-admin credentials (pull rather than push), and self-healing against manual changes. Typical setup: CI builds and pushes an image, then updates the image tag in the environment's manifests (or an image updater does it); Argo CD syncs.

Design points: repository structure (app repos versus config repos, environments as directories or branches), secrets (External Secrets, Sealed Secrets, SOPS), progressive delivery (Argo Rollouts, Flagger), and handling drift alerts rather than letting people kubectl edit in production.

Key Points

• Git as source of truth; pull-based agents.
• PR review, audit, easy rollback.
• No cluster credentials in CI.
• Plan repo layout and secrets.

Summary

You declare the desired state of objects (three replicas of this image), and controllers run loops that observe the actual state, compare it with the desired state, and act to close the gap. You do not issue step-by-step commands; you change the desired state and the system converges.

Longer Answer

A Deployment controller creates a ReplicaSet; the ReplicaSet controller creates or deletes pods until the count matches; the scheduler binds unscheduled pods to nodes; the kubelet starts their containers. If a node dies, the pods disappear and the ReplicaSet controller creates replacements, with no human involved.

Consequences: operations should be idempotent and retried; kubectl apply of manifests from Git (GitOps) fits naturally; and manual kubectl edit changes drift from the source of truth and get overwritten. Operators extend the same pattern to your own resources.

Key Points

• Desired state stored in the API.
• Controllers observe, diff, act, repeat.
• Self-healing comes from reconciliation.
• Operators apply the pattern to custom resources.

Summary

An Ingress defines HTTP routing rules (hosts, paths, TLS) implemented by an ingress controller. The Gateway API is its successor: role-oriented resources (GatewayClass, Gateway, HTTPRoute, GRPCRoute) with richer, portable features such as header matching, traffic splitting and cross-namespace delegation, without controller-specific annotations.

Longer Answer

Ingress remains supported but frozen; most advanced behaviour lived in vendor annotations, which made configurations non-portable. Gateway API splits responsibilities: platform teams own Gateways (listeners, certificates), application teams own Routes. Implementations include Envoy Gateway, Istio, Cilium, NGINX Gateway Fabric, and cloud load-balancer controllers.

The community ingress-nginx controller, once the most common choice, has been retired by the Kubernetes project, so new clusters generally adopt a Gateway API implementation or a maintained vendor controller, and existing ingress-nginx users plan a migration.

Key Points

• Ingress: host/path rules via a controller.
• Gateway API: role-based, portable, richer.
• Annotations made Ingress non-portable.
• Plan migrations off retired ingress-nginx.

Summary

NetworkPolicies are firewall rules for pods: they select pods by label and allow specific ingress and egress traffic by pod selector, namespace selector, IP block and port. By default all pods can talk to all pods; once a policy selects a pod, only explicitly allowed traffic for that direction is permitted.

Longer Answer

A common baseline: a default-deny policy for ingress and egress in each namespace, then allow-list what each app needs (from the ingress controller to the web pods, from web to the API, from the API to the database, egress to DNS on port 53). Forgetting DNS egress is the usual first mistake.

Policies are enforced by the CNI plugin; with a CNI that does not support them, they are silently ignored. Plain NetworkPolicy works at L3/L4; for L7 rules or DNS-name-based egress, use CNI-specific policies (Cilium, Calico) or a service mesh.

Code Example

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

Key Points

• Pod-level firewall rules by label.
• Default allow until a policy selects a pod.
• Default-deny, then allow-list; remember DNS.
• Needs a CNI that enforces them.

Summary

A PersistentVolumeClaim is a pod's request for storage (size, access mode); a PersistentVolume is the actual piece of storage; a StorageClass describes how to provision volumes dynamically, through a CSI (Container Storage Interface) driver for the backing system (EBS, Persistent Disk, Ceph, NFS).

Longer Answer

Details that matter: access modes (ReadWriteOnce attaches to one node; ReadWriteMany needs shared file storage such as EFS or NFS); volumeBindingMode: WaitForFirstConsumer provisions the volume in the zone where the pod is scheduled, avoiding zone mismatches; reclaimPolicy decides whether the disk is deleted with the claim; volume expansion and snapshots depend on the driver.

Block volumes are zonal, so a StatefulSet pod tied to a volume in one zone cannot move to another zone. Back up data independently of Kubernetes objects.

Key Points

• PVC = request; PV = storage; StorageClass = provisioning.
• CSI drivers implement backends.
• Access modes; WaitForFirstConsumer.
• Zonal volumes pin pods to zones.

Summary

A CRD adds a new resource type to the Kubernetes API (for example PostgresCluster or Certificate). An operator is a controller that watches those custom resources and reconciles real systems to match them, encoding operational knowledge such as provisioning, failover, backups and upgrades.

Longer Answer

Examples: cert-manager (Certificate to TLS secrets via ACME), CloudNativePG, the Prometheus Operator, Argo CD, Crossplane (cloud resources as Kubernetes objects). Operators are usually built with Kubebuilder or Operator SDK (Go), or frameworks in other languages.

Evaluate third-party operators like any critical dependency: maintenance activity, upgrade path, RBAC permissions they require, and what happens to your resources if the operator is removed.

Key Points

• CRDs extend the API.
• Operators reconcile custom resources.
• Encode operations knowledge.
• Evaluate permissions and maintenance.

Summary

Helm packages manifests as charts with Go templating, values files, versioning, dependencies and release history; Kustomize keeps plain YAML and applies overlays and patches per environment without templating (built into kubectl). Many teams use Helm for third-party software and Kustomize (or Helm) for their own apps.

Longer Answer

Helm strengths: distributing software, parameterisation, helm rollback, a huge chart ecosystem. Weaknesses: complex templates are hard to read and review, and values can hide what is actually deployed (render with helm template in CI to review diffs).

Kustomize strengths: what you see is valid YAML, small patches per environment, easy reviews. Weaknesses: less suited to distributing configurable packages.

GitOps tools (Argo CD, Flux) support both. Whatever you choose, keep manifests in Git and review the rendered output.

Key Points

• Helm: templated, packaged charts.
• Kustomize: overlays on plain YAML.
• Helm for third-party, either for own apps.
• Review rendered output in CI.

Summary

Upgrade one minor version at a time: check deprecated and removed APIs first, upgrade the control plane, then add-ons (CNI, CoreDNS, kube-proxy, CSI drivers, ingress), then nodes, by replacing or draining them in batches while PodDisruptionBudgets keep apps available.

Longer Answer

Preparation: read the changelog, find removed APIs in your manifests and Helm charts (tools such as pluto or kubent), confirm add-on compatibility, and test in a non-production cluster. Version skew rules allow kubelets to be a few minor versions behind the API server but never ahead.

Node upgrades: prefer creating new node groups and moving workloads (blue/green nodes) over in-place upgrades; make sure workloads have multiple replicas, PDBs and graceful shutdown. Kubernetes minor versions are supported for roughly a year, so upgrades are a regular, planned activity rather than a rare event.

Key Points

• One minor version at a time.
• Find removed APIs first.
• Control plane, add-ons, then nodes.
• PDBs, replicas, graceful shutdown; plan regular upgrades.

Summary

Collect metrics with Prometheus (kube-state-metrics for object state, node exporter for nodes, cAdvisor via kubelet for containers, and application metrics), visualise and alert with Grafana and Alertmanager, ship logs with a DaemonSet agent (Fluent Bit, Vector, OpenTelemetry Collector) to a log store, and add tracing with OpenTelemetry.

Longer Answer

Alert on what matters: application SLOs first, then platform signals such as pods crash-looping, deployments not progressing, nodes not ready, persistent volume space, certificate expiry, CPU throttling, OOM kills, and the control plane (API latency, etcd). Watch metric cardinality: labels such as pod name multiply series. Managed options exist on every cloud (Amazon Managed Prometheus, Google Managed Prometheus, Grafana Cloud).

Key Points

• Prometheus + kube-state-metrics + node exporter.
• Logs via DaemonSet agents.
• Tracing with OpenTelemetry.
• Alert on SLOs first, then platform signals.

Deep dive: Observability and Operations

Summary

Look at readiness and shutdown behaviour first: pods receiving traffic before they are ready (missing or wrong readiness probe), pods killed while the load balancer still routes to them (no SIGTERM handling, no preStop delay, too-short grace period), and keep-alive connections held to terminating pods. Then check rollout settings and capacity.

Longer Answer

Checklist: does readiness reflect real readiness (warm-up, connections established)? Does the app drain on SIGTERM? Is there a preStop sleep long enough for endpoint propagation and the external load balancer's deregistration delay? Does maxUnavailable drop capacity too far? Are idle timeouts of the load balancer and the app aligned (the app's keep-alive timeout should be longer than the load balancer's)? Correlate error timestamps with pod lifecycle events.

Key Points

• Readiness before traffic.
• Graceful shutdown + preStop delay.
• Keep-alive and idle timeout alignment.
• Rollout capacity settings.

Deep dive: Resilience Patterns

Summary

Kubernetes adds substantial operational complexity: networking, security, upgrades, observability and a large ecosystem to learn. For a small team with a few services, a PaaS, serverless functions, or a simpler container service (ECS, Cloud Run, App Runner) often delivers the same outcome with far less work.

Longer Answer

Kubernetes pays off with many services and teams, a need for portability, custom scheduling (GPUs, batch), or a platform team that builds paved roads on top of it. It does not by itself make applications scalable or reliable: stateless design, health checks, graceful shutdown and good observability still matter. A balanced answer shows you have run it and know its costs.

Key Points

• Significant operational overhead.
• Simpler options for small teams.
• Pays off at scale or with platform teams.
• Not a substitute for good app design.

Summary

Right-size requests from real usage (requests drive node count), use autoscaling at both the pod and node level, bin-pack with tools such as Karpenter consolidation, run interruption-tolerant workloads on spot or preemptible nodes, scale non-production environments down outside working hours, and allocate costs per team with labels and tools such as OpenCost or Kubecost.

Longer Answer

Over-requesting is the biggest waste: pods requesting 2 CPU and using 0.2 keep nodes half empty. Other wins: ARM-based nodes where images support them, removing orphaned volumes and load balancers, limiting log and metric volume, and avoiding one cloud load balancer per Service. Measure before and after, and keep reliability headroom.

Key Points

• Right-size requests.
• Autoscale pods and nodes; consolidate.
• Spot for tolerant workloads; schedule non-prod down.
• Cost allocation by labels (OpenCost).

Summary

kubectl get (status), describe (configuration and events), logs (--previous, -f, -c container), exec (shell into a running container), debug (ephemeral debug container or a copy of a pod or node), top (resource usage from metrics-server), get events --sort-by=.lastTimestamp, rollout status/history/undo, and port-forward for direct access.

Longer Answer

Useful habits: start from events and status conditions, use -o yaml to see the full object including status, kubectl auth can-i for permission problems, and kubectl get endpointslices -l kubernetes.io/service-name=<svc> when a Service routes nowhere (usually a selector mismatch or no ready pods). Minimal images often lack a shell, which is exactly what kubectl debug with a tooling image solves.

Key Points

• get, describe, logs, events first.
• exec / debug for inspection.
• top for usage; rollout for deploys.
• Empty endpoints = selector or readiness issue.

Summary

Start from the developer experience and guardrails: standard templates (golden paths) for services, GitOps deployment, built-in observability, secrets integration, policy enforcement, autoscaling, and clear ownership. Underneath: managed clusters per environment (and sometimes per region), infrastructure as code, a tested upgrade process and cost visibility.

Longer Answer

Components typically include: a managed control plane; node provisioning with autoscaling; a CNI with NetworkPolicy; ingress or Gateway API with cert-manager; External Secrets; Prometheus/Grafana/OpenTelemetry; Argo CD or Flux; Kyverno or Gatekeeper; backup with Velero; and an internal developer portal (Backstage) with templates. Define SLOs for the platform itself, document the paved road, and treat the platform as a product with users.

Key Points

• Golden paths and guardrails.
• Managed clusters, IaC, regular upgrades.
• GitOps, observability, policy, secrets built in.
• Platform as a product with SLOs.