Applications in Kubernetes can be exposed outside of the cluster in several ways, such
LoadBalancer type services, or via ingress controllers or
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.
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
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 for your applications, or even use
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