Unlike Deployments and StatefulSets—which are designed to keep long-running processes alive indefinitely—Jobs and CronJobs are designed for run-to-completion batch tasks. When the workload process terminates with exit code 0, Kubernetes marks the Pod as Completed.
Containers are designed to be stateless and ephemeral. To run stateful applications like PostgreSQL, MySQL, Redis, or Elasticsearch, Kubernetes provides storage abstractions that decouple persistent storage infrastructure from application workload definitions.
The Twelve-Factor App methodology mandates strict separation of application code from configuration settings. ConfigMaps store non-sensitive configuration data (URLs, log levels), while Secrets store sensitive values (passwords, API tokens, TLS keys).
While L4 Kubernetes Services handle IP and port-level load balancing, modern web applications require Layer 7 HTTP/HTTPS routing features: URL path matching (/api vs /app), hostname routing (api.example.com), SSL/TLS termination, and header rewriting. This is handled by Ingress.
Pods are ephemeral—they are created, destroyed, and rescheduled dynamically, causing their IP addresses to change constantly. A Kubernetes Service provides a stable, persistent virtual IP (VIP), DNS name, and load balancing frontend across a dynamic set of backend Pods.
Operating a multi-cluster architecture introduces a massive observability challenge. If a Kratix Pipeline fails, the logs are in the Platform cluster. If the physical database fails, the logs are in the Worker cluster. In this episode, we build a centralized monitoring stack using Prometheus and Grafana.
If your organization prefers Flux over ArgoCD, Kratix supports it natively without any modifications to the Platform Cluster. Because Kratix simply writes standard YAML to a Git repository, any GitOps controller can act as the delivery agent. In this episode, we configure FluxCD on the Worker Cluster.
In this episode, we learn HOW to execute the GitOps pull model in practice. We will configure ArgoCD on a Worker Cluster to continuously sync the Redis StatefulSet YAML generated by our Kratix Pipeline, ensuring you understand the mechanics of the State Store.
Enough theory. It’s time to look at the YAML. In this episode, we build the E-Commerce Redis Promise line-by-line. We will examine the API schema, the Pipeline configuration, and the Destination selectors that make multi-cluster deployment possible, ensuring you understand exactly how Kratix executes your logic.
YAML is excellent for configuration, but terrible for programming. As your Platform scales, you will inevitably need for loops, complex if/else logic, and external API calls. In this final intermediate episode, we introduce Composition Functions—the architecture that allows you to write Crossplane logic in Turing-complete languages.
