Kubernetes Ingress Concepts: Difference between revisions
| Line 19: | Line 19: | ||
The ingress controller is the process - most likely running as a pod or pods inside the Kubernetes cluster itself - that accepts the HTTP connections, distributes traffic, terminates SSL connections, etc. Some Kubernetes distributions provide an ingress controller as an "add-on". For example, minikube provides to "minikube addons enable ingress" command. If the ingress controller is not provided as add-on, it can be installed. There is a default "ingress-nginx" ingress controller that can be installed in any Kubernetes instance. More details: {{Internal|ingress-nginx|ingress-nginx}} | The ingress controller is the process - most likely running as a pod or pods inside the Kubernetes cluster itself - that accepts the HTTP connections, distributes traffic, terminates SSL connections, etc. Some Kubernetes distributions provide an ingress controller as an "add-on". For example, minikube provides to "minikube addons enable ingress" command. If the ingress controller is not provided as add-on, it can be installed. There is a default "ingress-nginx" ingress controller that can be installed in any Kubernetes instance. More details: {{Internal|ingress-nginx|ingress-nginx}} | ||
Once installed, the access to the ingress controller pod(s) is performed via | Once installed, the access to the ingress controller pod(s) is performed via its own LoadBalancer/NodePort/ClusterIP service. | ||
=Ingress API Resource= | =Ingress API Resource= | ||
Revision as of 21:41, 25 September 2020
External
Internal
Overview
An Ingress is a mechanism that operates at the application layer of the network stack (HTTP) and brings layer 7 features such as host and path-based routing and cookie-based session affinity to services. Ingress cooperates with services to distribute load to pods. It exposes multiple services through a single IP address, and its implementation differs fundamentally from the implementation of ClusterIP, NodePort and LoadBalancer services. The reasons to use an Ingress include:
- One Ingress can serve multiple services, behind a single public IP address, while each LoadBalancer requires its own native load balancer, each of them requiring their own public IP address.
- Host, paths and cookies can be used to route the request.
The Ingress mechanism consists of an Ingress controller and an Ingress resource.
Ingress Controller
The ingress controller is the process - most likely running as a pod or pods inside the Kubernetes cluster itself - that accepts the HTTP connections, distributes traffic, terminates SSL connections, etc. Some Kubernetes distributions provide an ingress controller as an "add-on". For example, minikube provides to "minikube addons enable ingress" command. If the ingress controller is not provided as add-on, it can be installed. There is a default "ingress-nginx" ingress controller that can be installed in any Kubernetes instance. More details:
Once installed, the access to the ingress controller pod(s) is performed via its own LoadBalancer/NodePort/ClusterIP service.
Ingress API Resource
An Ingress is the Kubernetes API resource that manages access to level 4 services in a cluster.