kubernetes

kubectl apply -f cluster.yaml When you apply this manifest, a complete Kubernetes workload cluster appears within minutes. There is no single “cluster-creation controller” or master provisioning engine running behind the scenes. Instead of a central orchestrator executing procedural scripts, independent controllers converge asynchronously through shared Kubernetes API state. Each controller reconciles its own slice of resources in etcd, updates status conditions, and reacts when prerequisite fields populated by neighboring controllers appear....

clusterctl manages and bootstraps the CAPI management environment; controllers manage workload-cluster lifecycle. clusterctl ↓ setup / templates / provider lifecycle / inspection CAPI controllers ↓ continuous reconciliation clusterctl is a client-side CLI executed on demand. It does not run continuously, poll cloud APIs, or reconcile infrastructure drift. Once providers and manifests are written to Kubernetes, in-cluster controllers handle continuous reconciliation. Here is the practical reference for the commands an engineer actually needs....

You do not need a cloud account to get hands-on experience with Cluster API (CAPI). Using kind (Kubernetes in Docker) and the Docker infrastructure provider (CAPD), you can run a complete, multi-cluster management and workload setup on a single workstation in about 15 to 20 minutes. This lab focuses strictly on practical execution and reproducible steps. These notes walk you through provisioning a local management cluster, deploying a workload cluster, watching resource expansion, and tearing everything down cleanly....

Kubernetes has spent years getting very good at answering one fundamental question: Where should this Pod run? For a large class of traditional applications, that is exactly the right question. A stateless Deployment with ten API replicas usually does not care if replica seven starts 20 seconds after replica six. Each Pod makes progress independently. The scheduler evaluates them one at a time, finds a feasible Node, binds the Pod, and moves to the next item in its queue....

When inspecting a Cluster API (CAPI) management cluster with kubectl, the number of Custom Resource Definitions (CRDs) can feel overwhelming: Cluster, Machine, MachineDeployment, KubeadmControlPlane, and various provider objects. You do not need to master the entire specification to navigate with confidence. Cluster API organizes resources into a predictable hierarchy. By understanding the core resource graph, you can inspect any running cluster with kubectl, recognize what each object does, and understand how the pieces connect....

Managing Kubernetes clusters declaratively requires orchestrating very different systems: allocating cloud compute, provisioning virtual networks, injecting bootstrapping scripts, and managing etcd quorum. A single monolithic controller handling all of these concerns across dozens of cloud platforms and operating systems would be brittle and unmaintainable. Cluster API (CAPI) solves this by decomposing cluster lifecycle into modular, cooperating controllers that run inside a dedicated management cluster. Instead of tightly coupling these controllers through direct RPCs or internal APIs, Cluster API uses the Kubernetes API itself as its coordination backbone....

Introduction Kubernetes excels at managing containerized applications. When you deploy a service, you declare desired state in a manifest: replica counts, container images, resource limits, and network ports. You submit that manifest to the API server, and controllers reconcile reality. If a pod crashes, a controller replaces it. If a node fails, the scheduler moves pods elsewhere. You declare target state once, and Kubernetes continuously reconciles actual state to match....

Walk into any AI infrastructure discussion and you’ll hear the same question: What’s your GPU utilization? It’s become the infrastructure equivalent of asking a web service for its CPU utilization. The assumption is simple: higher utilization is better. After all, GPUs are expensive, and a cluster running at 90% utilization sounds far more impressive than one running at 50%. For a long time, I believed that too. Then I spent more time working on GPU scheduling and multi-tenant AI workloads....

I used to think DNS was boring. You ask for a name, you get an IP, the application connects. That was my entire mental model, until a bug dismantled it completely. The service worked when addressed by IP but failed with a hostname. It worked from one machine and failed from another. Then, oddly, it started working the moment I added a trailing dot to the domain name. That day I learned that DNS is never simple, not because it is poorly designed, but because decades of accumulated behaviour are hiding behind what looks like a plain string....