Kubernetes is on the cusp of a series of new developments that will change the way networking works in cloud native deployments.

Kubernetes organizes its development efforts into various Special Interest Groups (SIGs) for specific topics. In session at the Cloud Native Computing Foundation (CNCF‘s) Kubecon conference this week in Amsterdam (and streamed virtually) SIG-Network project leads detailed a series of upcoming innovations that are currently being developed for Kubernetes networking. The innovations could have a dramatic impact on the way that organizations are able to connect cloud native environments with each other as well as the rest of the internet.

Since the earliest days of Kubernetes, the Ingress API has been one of the primary ways that a cloud native environment has been able to get access to services outside of a cluster. While the Ingress API is broadly deployed today, it has a series of limitations that were outlined by Shane Utt , staff software engineer at Kong, a chair of Kubernetes SIG Network and a maintainer of Gateway API.

Among the limitations is what Utt referred to as a 'wild west' of annotations and extensions that aren't all compatible with each other.

"Basically for everything that an Ingress controller would want to do, you'd end up with a custom annotation for it," Utt said. "It just kind of kept going into this situation we have today where no two ingresses do anything remotely similar to each other."

Other limitations of the Ingress API outlined by Utt include an insufficient permissions model and a focus largely only on HTTP traffic. The challenges of the Ingress API have been well known in the cloud native community for several years, which has led to the development of a replacement known as the Gateway API.

Gateway API which is currently in beta development is intended to be the successor to the Ingress API, providing a host of additional features.

For one, the Gateway API is role-oriented, which means that resources are connected to user and entity roles and permissions. Beyond just handling HTTP traffic, the Gateway API can also handle other protocols including  gRPC, tcp, udp and tls. Scalability is another key attribute of the Gateway API, with the ability to have multiple gateways connecting to each other.

"When you start with the Gateway API, you tend to create a gateway class," Utt explained. "This effectively lets the resources understand what controller is responsible for provisioning those resources and handling their lifecycle."

As a sub-project of the Gateway API, SIG-Networking is currently developing a Kubernetes native service mesh capability. The service mesh project is known as Gateway API for Mesh Management and Administration (GAMMA) and will initially enable a service mesh for HTTP traffic inside of a Kubernetes cluster.

There are also efforts underway to help improve Kubernetes network policy and security.

Surya Seetharaman, senior software engineer at Red Hat, explained that Network Policy is a subgroup inside of the SIG-Network project. She explained that the existing Network Policy API in Kubernetes helps application owners to control traffic to and from their workloads.

What has been missing is a higher level policy for network administrators. That's now changing with the development of an Admin Network Policy API. The goal of the new API is to help administrators enforce policies across a whole cloud native cluster.

The Admin Network Policy API is still in early development, with a beta currently expected by the end of 2023.