← Blog
#Kubernetes#Docker#CloudInfrastructure#DevOps#Containers

Kubernetes v1.36 and Docker Kanvas: Tackling Container Complexity in 2026

webhani·

Kubernetes v1.36 reached General Availability on April 24, 2026, with fine-grained kubelet API authorization as its most security-relevant graduation. Around the same time, Docker launched Kanvas as an extension available through Docker Hub — positioning it as a bridge between local Docker Compose workflows and Kubernetes production deployments.

Both developments address the same underlying problem: Kubernetes is powerful, but its operational complexity continues to outpace teams' capacity to run it well. According to Cast AI's 2026 State of Kubernetes Optimization Report, average CPU utilization across clusters sits at 8%, down from 10% a year earlier. GPU utilization for AI/ML workloads averages 5%.

Kubernetes v1.36: Fine-Grained kubelet Authorization GA

Before v1.36, access to the kubelet API was essentially binary — you either had access or you didn't. This was a meaningful attack surface in multi-tenant clusters: a compromised workload with kubelet access could enumerate Pods and potentially extract sensitive data across namespaces.

With the GA of fine-grained kubelet API authorization, you can now control access at the Node and Pod level using webhook authorization:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authorization:
  mode: Webhook
  webhook:
    cacheAuthorizedTTL: 5m
    cacheUnauthorizedTTL: 30s

With webhook mode, authorization decisions are delegated to your existing RBAC infrastructure (typically via the Kubernetes API server), giving you consistent policy enforcement across the cluster.

This is a direct upgrade for production clusters running with strict security requirements. The migration path is straightforward for clusters already using webhook authentication.

AWS's Approach: Karpenter + Kro + Cedar

At KubeCon CloudNativeCon Europe 2026, AWS outlined how Karpenter, Kro, and Cedar work together to reduce Kubernetes operational overhead.

Karpenter handles node lifecycle: rather than managing static Node Groups, it provisions nodes in real time based on pending Pod requirements and decommissions them when no longer needed:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
      nodeClassRef:
        apiVersion: karpenter.k8s.aws/v1
        kind: EC2NodeClass
        name: default
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized

The WhenEmptyOrUnderutilized consolidation policy is the lever most teams underuse — it actively removes nodes that are empty or below a utilization threshold, which directly addresses the 8% CPU utilization problem.

Docker Kanvas: Compose-to-Kubernetes Without the Helm Learning Curve

Kanvas converts Docker Compose files into Kubernetes manifests and manages the deployment lifecycle. The appeal is that teams already writing Compose files can move to Kubernetes without learning Helm or Kustomize first.

A typical Compose service definition:

services:
  app:
    image: myapp:latest
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=${DATABASE_URL}
  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

Kanvas translates this into Deployments, Services, and PersistentVolumeClaims and handles the deployment to a connected cluster through the Docker Hub extension UI.

Where Kanvas fits: Teams in the transition phase — using Docker Compose locally but needing to ship to Kubernetes — benefit most. It removes the initial investment in Helm chart authorship.

Where it doesn't fit: Complex applications with custom CRDs, multi-cluster configurations, or teams already operating mature Helm or GitOps workflows. Kanvas doesn't yet cover those scenarios, and introducing it to replace existing tooling would be a step backwards.

Addressing the Utilization Problem

The 8% CPU and 5% GPU utilization numbers represent real cost waste. Practical approaches:

  1. Enable Karpenter consolidation: The WhenEmptyOrUnderutilized policy with sensible thresholds is the highest-leverage single change for most EKS clusters.

  2. Deploy VPA alongside HPA: Vertical Pod Autoscaler adjusts resource requests based on actual usage history, shrinking the gap between requested and used resources. Running it alongside Horizontal Pod Autoscaler requires care to avoid conflicts — use VPA in Off mode first to observe recommendations before enabling automatic updates.

  3. Separate workload classes: Spot/preemptible instances for stateless workloads (web frontends, API replicas) and on-demand for stateful workloads (databases, queues). Karpenter's capacity-type requirement makes this straightforward.

Takeaway

The kubelet authorization GA in v1.36 is the most actionable change for security-conscious teams — review your clusters' kubelet authorization configuration and move to webhook mode if you haven't already. Docker Kanvas is a useful onramp for teams new to Kubernetes, not a replacement for established tooling. The cluster efficiency problem is real and addressable with Karpenter consolidation and VPA — the tooling exists, most teams just haven't applied it yet.

← Back to Blog