The Gateway API, now part of the core Kubernetes distribution, provides Gateway resources that facilitate Kubernetes service networking through extensible, role-oriented, and expressive interfaces. Gateway API was created to replace the Ingress API and has since been extended. The SIG-NETWORK community manages this open-source project.
Gateway API extends the scope of Kubernetes’ underlying network gateways and proxy servers to support many more vendors and industries. It supports commonly-used networking protocols like HTTP, TCP, TLS, and UDP. You can leverage it to manage the lifecycle of all network gateways as a Kubernetes API.
API Gateway and the Kubernetes Observability Stack
Modern software architecture can be complex, with high security, reliability, and availability demands. Managing microservices and containers at scale requires metrics, traces, and logs to observe, debug, and maintain applications and systems.
The Kubernetes dashboard is a web UI for deploying, troubleshooting, and managing container-based applications. It lets you manage resources for Kubernetes clusters, providing an overview of the applications running on each cluster. The dashboard provides resource state and error data. A log viewer lets you search logs related to a given pod.
Jaeger is a distributed tracing system for monitoring and troubleshooting microservices in distributed environments. It focuses on context propagation, transaction monitoring, root cause and service dependency analysis, and performance and latency optimization.
Grafana
Grafana helps you visualize observability data by processing the raw metrics into a human-readable form.
The ELK Stack
ELK stands for Elasticsearch, Logstash, and Kibana. It combines these open-source projects to help you analyze Kubernetes logs. Elasticsearch is an analytics tool and search engine, Logstash is a log ingestion pipeline, and Kibana is a visualization solution.
Kubernetes Gateway API Concepts
Here are some design features behind the Gateway API that show how it improves on existing standards, such as Ingress:
Role-oriented networking—the Kubernetes gateway API includes resources for modeling organizational roles to consume and configure a network of services.
Portable specification—this feature does not improve on Ingress but maintains the same standard. The API’s design prioritizes portability, with support from various implementations.
New phenotypes—the API resources enable core features like traffic weighting and header-based matching. These features were unavailable in Ingress, except via custom annotations.
Extensibility—the Kubernetes gateway API enables you to assign custom resources from different API layers. It lets you customize the API structure at a granular level.
The Kubernetes gateway API also includes the following features:
Gateway classes—formalize the load balancing implementation to provide users with a clear understanding of Kubernetes’ resource model’s different features.
Shared gateway—allows multiple teams to work together.
Support across namespaces—enables the separation of development teams based on distinct responsibilities.
Formatted back ends and routes—support TCPRoute, HTTPRoute, TLS, and UDPRoute, including all protocols.
How Gateway API Differs from Ingress
Gateway API and Ingress API both attempt to provide functionality through APIs for Kubernetes applications, but in different ways.
Why you need APIs
Deploying a Kubernetes application requires exposing it to end-users, typically through an inlet controller configuration for north-south traffic flow. The Ingress object can define the routing and mapping of this external traffic flowing to your Kubernetes service, providing load balancing, name-based virtual hosting, and SSL termination.
Commercial controllers, like NGINX Ingress and HAProxy, help implement the Ingress API interface. Each controller differs, providing various features like advanced load balancing through vendor extensions. However, Ingress is limited and does not offer portability for the ecosystem.
Gateway API vs. Ingress
Gateway API was created to replace Ingress to provide advanced, Kubernetes-native functionality. Ingress vendors provide features that enable this functionality, but through private extensions that are not coordinated with those provided by other vendors. Gateway API solves this problem by implementing multiple vendors according to a single specification.
Unlike Ingress, Gateway API supports traffic segmentation and HTTP and TCP routing. It employs a role-oriented approach that enables you to focus on configuration related to your responsibilities.
Kubernetes API Gateway Design Principles
Here are some design principles implemented in this API.
Single-Resource Consistency
The Kubernetes gateway API ensures consistency at a single-resource level, avoiding the issues associated with complex resource graphs. It enables simple syntax checks and synchronicity, avoiding the broken links between Kubernetes resources and mismatched configurations.
Configuration Conflicts
Separating responsibilities across teams can result in configuration conflicts, such as two application teams inadvertently submitting the configuration for one HTTP path.
Usually, fields prone to conflicts have documentation offering guidance for resolving the conflicts. If there is no prescribed conflict resolution, use the following general principles:
Avoid breaking anything that works.
Avoid dropping too much traffic.
Prioritize a consistent user experience.
Clarify the selected path when identifying a conflict.
Prioritize specific matches.
Prioritize resources with older creation timestamps.
Future API Version Handling
It is important to consider how the API might change over time. Like the older Ingress API, various products in a cluster can implement the gateway API. Thus, the current version could be different from the version used to develop the implementation. To avoid breaking the implementation, it must have the following capabilities:
Handling fields with loosened validation.
Handling previously required fields that have become optional.
CRD and Webhook Validation Limitations
This validation is not a final validation enforcing the schema—it provides quick feedback when users submit invalid configurations. It is best to write code defensively for cases when invalid input reaches the controller. Neither Webhook nor CRD validation is fully reliable.
It is important to ensure that the implementation is secure even if the API encounters unexpected values. The validation should reject malformed configurations and notify users via status block conditions. API maintainers can avoid duplication by adding a shared validation package.
Conclusion
In this article, I provided an in-depth look at the Kubernetes API Gateway project and its context within the Kubernetes ecosystem. In summary, these are the core aspects added by Kubernetes API Gateway, which were not covered by the original Kubernetes Ingress:
Role-oriented networking
Flexible specification
New traffic management features, including traffic weighting and header-based matching
Ability to assign custom resources from different API layers
I hope this will help you gain a better understanding of the new project and evaluate it for use in your Kubernetes clusters.
Disclaimer: The author is completely responsible for the content of this article. The opinions expressed are their own and do not represent IEEE’s position nor that of the Computer Society nor its Leadership.
What Is Kubernetes API Gateway?
