Streaming Was Only Half the Fix: Retrofitting a Stable gRPC API - Sohan Kunkerkar, Red Hat

Don't miss out! Join us at our next KubeCon + CloudNativeCon event in Salt Lake City, United States (Nov 9–12, 2026). Connect with our current graduated, incubating, and sandbox projects as the community gathers to further the education and advancement of cloud native computing. Learn more at https://kubecon.io Streaming Was Only Half the Fix: Retrofitting a Stable gRPC API - Sohan Kunkerkar, Red Hat The Kubernetes Container Runtime Interface is a gRPC API on every node. Its list operations used unary RPCs. That worked until nodes accumulated thousands of completed and failed containers. At that density, responses cross the receive limit, producing ResourceExhausted errors. Raising the limit only postpones the failure and does nothing about unbounded result sets. The fix was adding six streaming RPCs to CRI and implementing them in CRI-O, with UNIMPLEMENTED-based fallback to unary during mixed-version rollout. But streaming did not fix everything. gRPC provides flow control through HTTP/2, but the first implementation gathers the full result set before calling Send. Messages are smaller on the wire, but server memory stays roughly the same because flow control cannot help if everything is materialized first. This case study from the CRI-O maintainer covers why unary broke, how rollout worked, and what pipeline streaming requires on the server side.