KRO
Kubernetes is the undisputed standard for container orchestration, but its complexity can be overwhelming. Platform teams are therefore constantly looking for ways to hide that underlying complexity so that developers can focus entirely on writing code. The Kube Resource Orchestrator (kro) project is one of the newest and most promising solutions to this challenge.
What is KRO?
KRO is an open-source controller that runs in your Kubernetes cluster and acts as an abstraction layer. Instead of manually managing individual Deployments, Services, and Ingress rules, KRO allows you to bundle them into a single logical, reusable unit: a ResourceGraphDefinition (RGD).
Think of an RGD as the “blueprint” of your application. Once you deploy this code into the cluster, KRO takes over and automates the work that would normally have to be done manually.
- Automatic Creation of CRDs: KRO generates the necessary Custom Resource Definitions (CRDs) based on your definition.
- A smart in-cluster controller: A dedicated controller monitors the entire application and ensures all resources remain up to date.
- Intelligent dependency handling: KRO understands the relationships and knows exactly in which order resources must be created. This prevents annoying race conditions common in manual deployments.
- Flexible configuration: With CEL, you can pass default values, dependent fields, and even values across different resources, making your manifests more reusable.
KRO uses CEL (Common Expression Language), which ensures more predictable and secure results than Helm’s Go templating language. This is a deliberate choice: Go templating can execute arbitrary logic (with the associated risks), while CEL evaluates only simple, safe expressions. As a result, the system is fundamentally more secure, and the outcomes of deployments are highly predictable. This approach significantly lowers the barrier to entry and makes implementing operators much easier.
Future outlook
KRO sounds promising and has the potential to drastically reduce the complexity of application deployments. However, there is one important caveat: KRO is still under active development and should be considered an alpha version. Although it is not yet suitable for mission-critical production environments, it does provide a clear glimpse into the simplification it can bring to the Kubernetes ecosystem.
Talos Linux
Another standout is the rising popularity of Talos Linux from Sidero Labs, a Linux distribution purpose-built for running Kubernetes. With Talos, Linux management is no longer required, letting you fully focus on managing Kubernetes.
A few key takeaways:
- Immutable: There is no SSH daemon running on the host, so you cannot log in. The node is configured via a declarative YAML file. After that, the node is immutable. Every node in your cluster remains identical, preventing “configuration drift.” Of course, you can still access the node for reboots and other necessary actions. This marks the shift from “pets” to “cattle.”
- API-driven: Instead of logging in to a server, you manage nodes via the Kubernetes API. This aligns directly with the way you already work with Kubernetes. All management and maintenance tasks, including updates and reboots, are performed via API calls. This simplifies automation and enables an Infrastructure as Code approach.
- Safer and more predictable: Talos’s minimalist design ensures a very small attack surface. Fewer components and services mean fewer vulnerabilities. No shell or SSH access means that many common attack vectors simply do not exist. Updates are atomic, which reduces the likelihood of errors. The result is a more reliable and predictable platform, with less chance of human error.
Presentations and real-world examples clearly show that many organizations use Talos as a solid foundation for their clusters. It eliminates node-specific configuration quirks. Instead, you get a clean, reliable OS that does exactly what’s needed and nothing more. By choosing Talos Linux, you eliminate the complexity of Linux management and can focus entirely on running Kubernetes workloads efficiently.
Gateway API
Next was the Traefik Labs talk on the Gateway API, a fascinating, future-focused topic. Until now, Ingress has been the way to expose your applications in Kubernetes. It works, but quickly requires complicated annotations. The result: sprawling rules in a single file, leading to chaos and confusion.
Until now, Ingress was the standard way to make applications available within Kubernetes. It works, but quickly requires complex annotations. The result: sprawling lines of code in a single file, leading to chaos and confusion.
The Gateway API is the successor and solves this problem once and for all. Here's why it's the future:
- Clear roles: Responsibilities are separated. Admins manage infrastructure (Gateway), developers manage routes to their apps (HTTPRoute). No more debates about who does what.
- Standardization: Vendor-specific annotations are gone. Gateway API defines standard rules for features like traffic splitting and header-based routing. Configurations become portable across vendors.
- Better control: Gateway API gives more detailed control over all traffic, both incoming and outgoing.
Traefik Labs fully embraces the Gateway API. This approach eliminates the complexity of Ingress and makes cloud native networking simpler and more secure. Compared to a CNI solution like Cilium, which integrates the Gateway API into a comprehensive networking platform, Traefik focuses on what it does best: a specialized, intelligent, and user-friendly reverse proxy.
Common Expression Language (CEL)
CEL has been a hot topic since the introduction of ValidatingAdmissionPolicies and MutatingAdmissionPolicies in Kubernetes.
These new, native features run directly on the API server, thereby eliminating the risks associated with external webhooks. Policies can now be managed declaratively using the Common Expression Language (CEL).
Examples of this include blocking :latest images or enforcing resource limits and labels. Security and efficiency are significantly improved.
A more advanced example is setting a limit on the number of replicas, as shown below.
It’s a big step forward, but for complex scenarios, you’ll still need tools like Kyverno, OPA Gatekeeper, and Kubewarden. At the same time, one thing is clear: for basic policy management, Kubernetes itself will soon be sufficient.
CEL ensures a future for Kubernetes security that is lighter, safer, and more integrated than ever before.
See you next year!
ContainerDays once again confirmed that the Kubernetes community never stands still. From making our clusters fundamentally more secure with Talos Linux and CEL to simplifying deployments with KRO: we’re ready for the next phase of cloud native engineering. These insights form the foundation for our upcoming projects and ensure that the platforms we build are future-proof and of the highest quality. It was an incredible few days. See you next year!
To learn how SUE sets up and manages Kubernetes clusters, visit the Kubernetes page. The Kubernetes guide covers everything from setting up your first cluster to production.
