The dependency graph
The dependency graph: When one resource references another in Kix, that reference also records a dependency. This single graph drives deploy order, network policies, and change detection.
Explanation
Explanation
Explanation pages cover the ideas and tradeoffs behind Kix. Read these when you want a clear mental model of how a feature works under the hood, rather than step-by-step instructions for a specific task.
Core architecture and mental models
Section titled “Core architecture and mental models”Packages and clusters
Packages and clusters: Why Kix separates reusable application packages from cluster configuration and environment flavors, and why Kix stays close to standard Kubernetes schemas.
Dependency contracts
Dependency contracts: How shared kix.contracts.* interfaces let applications swap between in-cluster operators and external cloud services without changing application config.
Availability levels
Availability levels: Instead of tuning replica counts and pod anti-affinity on every Deployment by hand, you tell Kix what kind of failure a cluster should survive (none, pod, node, or zone).
Compilation, policy, and operations
Section titled “Compilation, policy, and operations”Network policy
Network policy: Because Kix already knows which workloads talk to which Services, it can generate matching ingress and egress firewall rules automatically.
Helm integration
Helm integration: You do not need to rewrite existing Helm charts or migrate a whole cluster at once. Kix can render Helm charts at build time and link to services managed outside Kix.
Scorecard levels
Scorecard levels: Kix separates always-on structural validation from configurable policy scorecards, and runs scorecard checks at four different scopes.
Server-side apply and drift
Server-side apply and drift: How Kix shares Kubernetes objects safely with in-cluster controllers like HorizontalPodAutoscalers, and why image digests live in committed files.