← Blog
#kubernetes#aws#devops#cloud#platform-engineering

Invisible Kubernetes: How Karpenter, kro, and Cedar Shift Where Complexity Lives

webhani·

The direction: make Kubernetes disappear

At KubeCon + CloudNativeCon Europe 2026 (Amsterdam), the Amazon EKS team gave a talk titled "From Complexity to Clarity: Engineering an Invisible Kubernetes." The thesis is clean. Kubernetes has matured, but its complexity has become a cognitive load on application developers. So rather than remove the complexity, move it somewhere developers cannot see it.

Three CNCF-adjacent projects were named as the load-bearing pieces of that direction: Karpenter, kro, and Cedar. All originate at AWS but have grown as community-driven efforts. In supporting client Kubernetes platforms, webhani has found that the design decision "which complexity do you hide, and from whom" matters more every year. This post reads those three through the lens of where they shift the center of gravity in operations.

Karpenter: from declared node groups to just-in-time nodes

Karpenter handles node lifecycle management, autoscaling in particular. The classic Cluster Autoscaler scaled within predefined node groups. Karpenter's key move is provisioning the nodes a workload needs in real time, based on pending pod requirements. Developers are freed from designing node groups at all.

# Karpenter NodePool: declare which nodes are acceptable and let
# Karpenter decide when and how many to launch based on demand
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["arm64", "amd64"]
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m

The consolidationPolicy automatically folds up underused nodes to cut cost. The "hidden complexity" here is capacity planning itself. Operators declare only the acceptable constraints and delegate when and how much to provision.

kro: fold many resources into one API

kro (Kubernetes Resource Orchestrator) bundles multiple Kubernetes resources and exposes them as a single higher-level API. Instead of asking application developers to write Deployment, Service, Ingress, and HPA separately, you hand them one abstraction — "a web app" — and kro expands the underlying resources.

# ResourceGraphDefinition: show developers a simple input and
# synthesize Deployment/Service/etc. internally (conceptual)
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
  name: webapp
spec:
  schema:
    apiVersion: v1alpha1
    kind: WebApp
    spec:
      image: string
      replicas: integer | default=2
  # resources: generate Deployment / Service / Ingress from the spec above

This is a core platform-engineering pattern. The operations team defines a "golden path" as a ResourceGraphDefinition, and developers self-serve safely within it. Combined with GitOps, both infrastructure and application configuration become version-controlled, auditable, and reproducible.

Cedar: turn authorization into policy-as-code

Cedar is an AWS-open-sourced authorization policy language and evaluation engine. You express who can access what as fine-grained, context-aware rules that are automatically validated and auditable. It gives you a practical foundation for zero-trust across clusters and services in Kubernetes.

// Example Cedar policy: allow writes to the production namespace
// only for on-call engineers coming from the corporate network
permit(
  principal in Role::"platform-engineer",
  action == Action::"k8s:write",
  resource in Namespace::"production"
) when {
  principal.oncall == true &&
  context.source_network == "corp-vpn"
};

Where RBAC is a static mechanism that binds permissions to roles, Cedar folds context — time, network, state — into the conditions. Its strength is expressing authorization complexity as a single policy rather than scattered configuration.

webhani's take: complexity is moved, not deleted

What the three projects share is a mindset of relocating complexity to the right owner rather than erasing it. Capacity planning goes to Karpenter, composition goes to kro (that is, the platform team), authorization decisions go to Cedar policy. Complexity becomes "invisible" from the developer's viewpoint, but it has not vanished.

That distinction matters for adoption decisions. Laying an abstraction on top means the responsibility to maintain that abstraction concentrates in the platform team. In a small organization with light Kubernetes usage, the cost of abstraction can outweigh the benefit. Conversely, in organizations where multiple teams share one platform and standardizing golden paths is the challenge, these tools start to pay off.

AWS has also stated it will contribute $3 million in cloud credits to the CNCF for 2026, backing these upstream projects financially so they do not close around a single vendor. When selecting tools, keep EKS-specific features distinct from portable OSS features so you preserve room to migrate later.

Takeaways

"Invisible Kubernetes" is not about simplifying Kubernetes; it is a design philosophy that reassigns who owns the complexity. Karpenter takes capacity, kro takes composition, and Cedar takes authorization out of the developer's field of view.

We advise treating these not as "magic that makes everything easier" but as "a decision to concentrate complexity." Only when the platform team that inherits it has the operational strength to match does Kubernetes truly become invisible to developers. Starting with Karpenter to automate node operations, then expanding to kro and Cedar once the need for standardization is clear, is the sustainable path.

← Back to Blog