While Pods are the basic building blocks of Kubernetes, you should rarely deploy bare Pods directly. Instead, production applications use Deployments, a higher-level abstraction that manages ReplicaSets to guarantee high availability, self-healing, and seamless scaling.
The kubectl command-line interface is the primary tool platform engineers and developers use to interact with Kubernetes clusters. In this episode, we’ll configure kubectl and deploy our first atomic Kubernetes primitive: the Pod.
A Kubernetes cluster consists of two primary logical layers: the Control Plane (the cluster’s brain) and Worker Nodes (the muscle that runs application containers). Understanding how these components communicate is crucial for cluster administration and troubleshooting.
The evolution of modern infrastructure has transitioned from physical bare-metal servers to Virtual Machines (VMs), lightweight OCI Containers, and ultimately automated Container Orchestration platforms like Kubernetes.
We have spent 7 episodes architecting a massively scalable, secure backend. But if the Developer Experience (DX) is terrible, no one will use it. In this episode, we switch personas to the Application Developer and explore the day-to-day workflow of consuming a Kratix Platform.
Crossplane uses GitOps to provision AWS infrastructure. Kratix uses GitOps to orchestrate Promises. This frequently leads to severe architectural confusion for teams adopting Platform Engineering. In this episode, we define the exact boundary between the two tools and learn how they complement each other in a Production IDP.
In this episode, we deeply analyze the ‘Where’ of the 5W1H framework. We will map out the Hub and Spoke topology, learn why Kratix intentionally isolates the Platform Cluster from the Worker Clusters for security, and explore how traditional Infrastructure-as-Code (like Terraform) executes inside this GitOps-driven model.
In Episode 4, we built an API (XRD) but it didn’t actually create any AWS infrastructure. In this final fundamental episode, we write a Composition. This is the ’translation engine’ that instructs Crossplane exactly which physical Managed Resources to create when a developer requests our custom API.
Managed Resources (MRs) are too low-level for application developers. In this episode, we learn how to define a Composite Resource Definition (XRD). This allows Platform Engineers to design a brand new, highly abstracted Custom Kubernetes API tailored exactly to their company’s needs.
A Managed Resource (MR) is the foundational building block of Crossplane. It is a 1-to-1 representation of a physical cloud object (like an S3 Bucket or an RDS Instance) stored as a Custom Resource in Kubernetes. In this episode, we provision our first AWS resource directly via kubectl.
