Kubernetes has a built-in configuration object for HTTP load balancing called Ingress.
It defines rules for external connectivity to the pods represented by one or more Kubernetes services.
Ingress can provide SSL termination and name-based virtual hosting.
The traffic routing is controlled by rules defined on the Ingress resource.
--- apiVersion: extensions/v1beta1 kind: Ingress metadata: name: app-ingress spec: rules: - http: paths: - backend: serviceName: app-service servicePort: 80 path: /
Ingress resource solely supports rules for steering communications protocol (HTTP)traffic. The Ingress specification has all the data required to put together a load balancer or proxy server. most significantly, it contains a listing of rules matched against all incoming requests.
Each HTTP rule contains an optional host, a list of paths each of which has an associated backend defined with a serviceName and service port.
If the traffic path is not matched to any rules, then traffic sends to the default backend.
The default backend is often a configuration possibility of the Ingress controller and isn’t laid out in your Ingress resources. If none of the hosts or methods match the HTTP request within the Ingress objects, the traffic is routed to your default backend.
Types of Ingress
Single Service Ingress
It doesn’t have any rules and it sends traffic to a single service. You can use this to create a default backend with no rules.
--- apiVersion: extensions/v1beta1 kind: Ingress metadata: name: frontend-ingress spec: backend: serviceName: frontend-service servicePort: 80
A fanout configuration routes traffic to more than one service, based on the HTTP URI being requested.
--- apiVersion: extensions/v1beta1 kind: Ingress metadata: name: simple-fanout-example spec: rules: - host: shopping.example.com http: paths: - backend: serviceName: clothes-service servicePort: 8080 path: /clothes - backend: serviceName: House-service servicePort: 8081 path: /kitchen
Name-based virtual hosting
Name-based virtual hosts support routing HTTP traffic to multiple hostnames.
--- apiVersion: extensions/v1beta1 kind: Ingress metadata: name: name-virtual-host-ingress spec: rules: - host: shopping.example.com http: paths: - backend: serviceName: clothes-service servicePort: 8080 path: /clothes - backend: serviceName: House-service servicePort: 8081 path: /kitchen - host: music.example.com http: paths: - backend: serviceName: Hindi-service servicePort: 9090 path: /hindhi - backend: serviceName: English-service servicePort: 9091 path: /english
In order to work the ingress resource, the Kubernetes cluster must have an ingress controller running.
It runs as part of the Kube-controller-manager and is typically started automatically with a cluster.
There are so many ingress controller implementations and choices that best fit your cluster.
Additional controllers include:
NGINX, Inc. provides overall maintenance and customer support for the NGINX controller for K8s. Contour is an associate Envoy primarily based ingress controller provided and supported by Heptio.
Traefik is a fully-featured ingress controller (Let’s Encrypt, secrets, http2, WebSocket), and it also comes with commercial support by Continuous.
Ambassador API Gateway is an Envoy based ingress controller with the community or commercial support from Datawire.
Citrix provides an Ingress Controller for its hardware (MPX), virtualized (VPX), and free containerized (CPX) ADC for bare-metal and cloud deployments.
F5 Networks always provides support and maintenance for the F5 BIG-IP Controller for K8s clusters. Gloo is an open-source ingress controller supported Envoy that offers API entranceway practicality with enterprise support from solo.io. HAProxy based mostly ingress controller DevOps/ ha proxy-ingress that is mentioned on the weblog post-HAProxy Ingress Controller for Kubernetes. HAProxy Technologies offers support and maintenance for HAProxy Enterprise and therefore the ingress controller DevOps/ha proxy-ingress.
Istio based ingress controller Control Ingress Traffic.
You can deploy multiple ingress controllers within a cluster.
When you create an ingress resource, you should annotate each ingress with the appropriate ingress.
Ex: Ingress with Nginx ingress controller:
--- metadata: annotations: kubernetes.io/ingress.class: nginx name: my-ingress
If you do not define ingress.class, your cloud provider will use a default ingress provider.
The Tech Platform