In this video, we explore popular options for exposing workloads in Google Kubernetes Engine (although the concepts are relatively portable to other Kubernetes environments). The examples are chosen to demonstrate and contrast: cluster-local ingresses, cloud-native ingresses, and the new Gateway API. More broadly, the demonstrated use cases, domains/certs, and evaluated options are selected based on their applicability and popularity for real production scenarios.
- HTTP-to-HTTPS use cases heavily suggest Nginx Ingress or GCE Ingress approaches
- For advanced routing use cases, Nginx Ingress or the Gateway API are often preferable
- Cloud Armor can be used in connection with GCE Ingress (only) to add security, and a very wide variety of redirection use cases
- Gateway API (in OSS Kubernetes) is in some ways the future replacement for ingresses
- Nginx Ingresses are ran on the cluster, instead of propagated to GCP distributed/global infrastructure (could be good or bad based on your use case)
- The ingress-nginx project is open source and highly configurable, whereas GCE Ingress and Gateway API are more turnkey (lower control and configurability - inherits the limitations and advantages of GCP’s Cloud Load Balancing)
- The connection of public IPs to routing/backends is worst with Nginx Ingress and best with Gateway API