Kubernetes 1.37 stable Metrics API and rootless Kubelet for African enterprises

What the new stable Metrics API and rootless Kubelet actually change

Kubernetes 1.37, code‑named “Garhwal”, announced that the metrics.k8s.io API is now generally available and that the Kubelet can run in user namespaces by default InfoQ. Both items are aimed at stability, security and cost control, areas that matter a lot to African public‑sector and donor‑funded projects.

Why the stable Metrics API matters for monitoring and autoscaling

The GA Metrics API gives a single, supported endpoint for node and pod health data. It powers the Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA) and the kubectl top command. The API is served by the standard metrics‑server component, so existing tooling continues to work. Because the API is now stable, you can bake it into your runbooks and expect the same request/response shape across future releases.

For many Kenyan ministries and NGOs, the ability to scale‑to‑zero (now beta‑default) is a direct cost‑saving lever for workloads that sit idle for long periods, such as batch‑oriented AI/ML jobs that run on GPUs. The API also makes it easier to integrate with existing monitoring stacks that already understand the metrics.k8s.io schema.

Rootless Kubelet and security for on‑prem and cloud nodes

Running the Kubelet as a non‑root process is enabled by the KubeletInUserNamespace feature gate, which is on by default in 1.37. This means the node‑side component that talks to the API server no longer needs full root privileges. The practical effect is a smaller attack surface: a container‑escape exploit would be confined to the unprivileged user namespace rather than the whole host.

In environments where servers sit in data centres with limited physical security or where power interruptions are common, reducing the privileges of core components can support data‑protection best practices by limiting exposure of sensitive data.

Implications for procurement and compliance in Kenya

When a public‑sector agency issues a tender for a new Kubernetes‑based platform, the specification can now reference a stable Metrics API as a mandatory capability. This removes the risk of later “feature‑freeze” disputes that often stall contracts. Likewise, the rootless Kubelet can be listed as a security hardening requirement, satisfying auditors who look for “least‑privilege” controls.

Because Afriq Silicon stays on for the operating life of a system, we can embed these capabilities during the product‑design‑implementation phase and then hand over a documented, monitored system that aligns with local data‑protection expectations our process page.

Practical steps to adopt Kubernetes 1.37 in an African context

1. Run a short proof‑of‑concept, Before signing a contract, ask the vendor to spin up a single‑node 1.37 cluster and demonstrate kubectl top returning pod metrics and a Kubelet running without root. This follows our “technical validation” step our process page.

2. Enable the feature gates, In the kubelet config, set featureGates: {KubeletInUserNamespace: true}. The flag is already on default, but confirming it avoids surprises on older base images.

3. Update your monitoring configuration, Adjust your monitoring tools (e.g., Prometheus, Grafana) to collect metrics from the cluster as appropriate. Ensure dashboards continue to display the required data after the upgrade.

4. Plan for scale‑to‑zero, Review any HPA objects that use minReplicas: 0. The beta default means you can start using it immediately, but test the wake‑up latency for your critical services.

5. Document the handover, Include the Metrics API version, the Kubelet user‑namespace configuration and any CI/CD pipelines (Docker, GitHub Actions, Pulumi) that build and deploy the cluster. This aligns with our “handover of a documented, monitored system” practice our services page.

Quick checklist before you upgrade

If you already have a running cluster on an older version, the upgrade path is the same as any minor version bump: back up your etcd, test the upgrade in a staging environment, and roll out using two‑week sprints as described in our process our process page.

For deeper guidance on building AI‑ready cloud infrastructure, see our earlier post Building Ai Ready Cloud Infrastructure For African Enterprises. For a broader view of scaling infrastructure in low‑connectivity environments, check Scalable IT Infrastructure What It Actually Takes To Build Systems That Grow With Your Business.

Sources

• Kubernetes 1.37 stable metrics API and rootless kubelet for African enterprise infrastructure, original news story

You’ve just learned what the stable Metrics API and rootless Kubelet bring to your African enterprise stack, talk to our team about it.

Photo by Field Engineer on Pexels.