Being layer 7, Ingress is capable of things not possible with services:
- Name-based virtual hosting using the
- Path-based routing.
- URL rewrites.
- SSL/TLS termination.
- In some Controllers, session persistence ("sticky sessions").
Ingress resources are managed by an Ingress Controller which configures resources, either internal to or external from the cluster, which perform matching of requests against a set of resources and reverse proxies traffic to a matching Pod's endpoint.
Unlike most resources in the cluster, no Ingress Controller is configured by default. This is similar to the approach taken for CNI and CRI: good implementations exist externally and there's enough differentiation between them that there's value in letting the user choose.
Controllers implement a well-defined specification and can be either in or adjacent to the cluster:
- In-cluster deployments might use a reverse proxy.
- Hardware load balancers such as F5 or Citrix.
- Cloud deployments might opt to use the provider's native load balancer resources.
A manifest for an Ingress resource performing both name- and path-based routing:
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: ingress spec: rules: - host: my-company.com http: paths: /portal backend: serviceName: my-service servicePort: 80 - host: my-marketing-site.com http: backend: serviceName: my-mktg-site servicePort: 80 backend: serviceName: my-404-intercept servicePort: 80
First, create a secret containing the key pair:
kubectl create secret tls tls-secret --key tls.key --cert tls.crt
Now create a deployment:
# Inside an Ingress.spec: tls: - secretName: tls-secret hosts: - tls.example.com
`cert-manager` can provide end-to-end automation of the TLS certificate.
- AWS Elastic Load Balancer
- Azure Application Gateway
- Azure Load Balancer
- Google Cloud HTTP(S) Load Balancer (Private)