Modernizing Kubernetes for Evolving Cloud-Native Architectures
This article highlights critical architectural shifts in Kubernetes v1.35, specifically the deprecation of cgroups v1 and Ingress-NGINX, and the emergence of Gateway API as the new standard for ingress. It emphasizes the need for DevOps engineers and architects to adopt modern Kubernetes patterns for service exposure, security, and scalability, providing practical steps to set up a future-ready local development environment.
Read original on DZone MicroservicesKubernetes continues to evolve rapidly, introducing significant architectural changes that demand attention from system designers and DevOps engineers. Version 1.35 marks a pivotal moment, deprecating established components like cgroups v1 and the Ingress-NGINX controller, and pushing the Gateway API as the standardized, extensible approach for managing external access to services. These shifts are not minor updates but fundamental changes affecting how applications are deployed, exposed, and observed in a cloud-native environment.
Key Architectural Shifts in Kubernetes v1.35
- Gateway API Adoption: The most significant change is the move from the monolithic Ingress-NGINX controller to the more flexible, role-oriented Gateway API. This new standard provides a hierarchical structure (Gateway, HTTPRoute) and explicit role separation, allowing infrastructure and application developers to manage their respective concerns more effectively.
- Runtime Modernization: cgroups v1 is deprecated, requiring Linux nodes to support cgroup v2 for kubelet v1.35+. Similarly, IPVS is being superseded by nftables for kube-proxy, promising better performance at scale. Containerd 2.0 also becomes the new baseline, necessitating validation against its schemas.
- Enhanced Observability and Resilience: Tracing for kubelet and API server is now generally available, providing native control plane insights. Improvements in kubelet restart behavior and in-place Pod vertical scaling (GA) enhance application resilience and resource efficiency.
Understanding the Gateway API's Impact
The Gateway API fundamentally changes how L7 routing is handled in Kubernetes. Its hierarchical structure separates concerns, allowing platform teams to manage network infrastructure (Gateways) and application teams to define routing rules (HTTPRoutes). This offers greater flexibility, extensibility through Custom Resources, and improved RBAC controls compared to the older Ingress model.
Practical Adoption for System Design
For system architects, these updates translate into critical decisions regarding ingress strategies, container runtime environments, and observability tooling. Migrating to the Gateway API is crucial for long-term support and leveraging advanced routing capabilities. Ensuring underlying infrastructure (OS, container runtime) aligns with cgroup v2 and containerd 2.0 is essential for stability and performance.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: echo-route
spec:
parentRefs:
- name: api-gateway
sectionName: http
rules:
- matches:
- path:
type: PathPrefix
value: /echo
backendRefs:
- name: echo-server
port: 8080