Kubernetes Ingress Concepts: Difference between revisions
Line 55: | Line 55: | ||
The ingress must be deployed in the same namespace as the services it serves. | The ingress must be deployed in the same namespace as the services it serves. | ||
==TLS Support== | ==TLS Support== |
Revision as of 02:23, 26 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. The target service is selected by host, path.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
name: example
namespace: test-namespace
spec:
rules:
- host: www.example.com
http:
paths:
- path: /
backend:
serviceName: target-service
servicePort: 80
# This section is only required if TLS is to be enabled for the Ingress
tls:
- hosts:
- www.example.com
secretName: example-tls
Some cloud providers require that the ingress points to a NodePort service, but this is not a Kubernetes requirement.
The ingress must be deployed in the same namespace as the services it serves.
TLS Support
If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:
apiVersion: v1
kind: Secret
type: kubernetes.io/tls
metadata:
name: example-tls
namespace: test-namespace
data:
tls.crt: <base64 encoded cert>
tls.key: <base64 encoded key>