 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
A project four years in the making, the Kubernetes Gateway API has reached production status, finally offering a standardized way to manage network traffic going in and out of Kubernetes clusters.
“This has been an absolutely massive effort from so many people. I think this may be the most collaborative API in Kubernetes history,” wrote Rob Scott, Google staff engineer in charge of Kubernetes networking, in a short message announcing the release.
Initially, Kubernetes provided outside access through Ingress or Customer Resource Definitions. Each approach had its limitations, and varied greatly from deployment to deployment. The Gateway API was conceived to standardize these networking services.
In this release, several of the key APIs have solidified into general availability (GA), meaning that they can be baked into systems without fear of them being changed again.
The APIs for Gateway (for configuration), GatewayClass (for cluster-level operations), and HTTPRoute (for routing of HTTP traffic) have all graduated to GA, according to the documentation.
In addition to finalizing the core technologies listed above, this release also introduces some experimental features.
BackendTLSPolicy will provide a way for the gateway to validate certificates. HTTPRoute will support preset timeouts. A number of additional protocols are also being supported: HTTP/2 over clear text (kubernetes.io/h2c), WebSocket over clear text and over TLS (kubernetes.io/wss). The ability to specify protocols will be supported through the Backend Protocol Selection.
Going forward, all work on the gateway API will be done through two channels, basic and experimental.
This release also comes with a new (very Beta) command line interface tool for interacting the Gateway API: gwctl. For its initial capability, gwctl will provide information on which policies are available in a cluster. More capabilities for gwctl will be forthcoming in future releases.
The specification itself now comes with an Implementer’s Guide, which promises “everything you wanted to know about building a Gateway API implementation but were too afraid to ask.”
Those going to KubeCon + CloudNativeCon (and the related Contributor Summit) next week in Chicago can also learn more about the Gateway API in the following sessions:
KubeCon:
Contributor Summit:
Lastly, this week The New Stack kicks off a six-part series on understanding the Kubernetes Gateway API, starting today with “Ingress Controllers or the Kubernetes Gateway API? Which Is Right for You?” and will continue into next week. The series, funded by NGINX, and authored by Robert Kimani, will cover topics such as using the gateway API for microservices, multicluster deployment, traffic management, security and more.
