Ingress

Applications in Kubernetes can be exposed outside of the cluster in several ways, such as via NodePort or LoadBalancer type services, or via ingress controllers or gateways.

NodePort services expose the service directly via a port on each of the nodes, which can then be manually managed by firewall rules or external load balancers.

LoadBalancer services require something that can provide indvidual load balancers for each service, which could be native load balancers provided by the underlying cloud (see the relevant Cloud Integration section of the docs) or something like MetalLB.

Ingress controllers provide a single point of entry instead of needing to deal with multiple individual service addresses, and then use rules or path matching to direct traffic appropriately. The ingress endpoint itself still needs to be exposed via one of the above methods but can provide feature-rich management of traffic routing into the cluster.

NGINX Ingress

By default, Charmed Kubernetes sets up the NGINX Ingress Controller, which can be customized via the config options on the worker charm. Ingress resources can then be used to configure routes for specific applications.

Istio Ingress

By deploying the Istio bundle into your cluster, you can use the Istio traffic management features. You can then relate Kubernetes charms which support the ingress relation to automatically manage VirtualServices, manually manage VirtualServices for your applications, or even use Ingress resources.

Multiple Ingress Controllers

Multiple ingress controllers or gateways can be used at the same time, typically with different configuration or exposure. The networking.k8s.io/v1 defines an IngressClass resource to select between controllers, but some controllers may rely on annotations, such as Istio’s kubernetes.io/ingress.class annotation.