Kubernetes Ingress Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 29: Line 29:


<syntaxhighlight lang='yaml'>
<syntaxhighlight lang='yaml'>
apiVersion: networking.k8s.io/v1beta1
apiVersion: extensions/v1beta1
kind: Ingress
kind: Ingress
metadata:
metadata:
Line 35: Line 35:
     kubernetes.io/ingress.class: nginx
     kubernetes.io/ingress.class: nginx
   name: example
   name: example
  namespace: test-namespace
spec:
spec:
   rules:
   rules:
    - host: a.local
  - host: a.local
      http:
    http:
        paths:
      paths:
          - path: /
      - path: /
            backend:
        backend:
              serviceName: target-service-a
          serviceName: a
              servicePort: 80
          servicePort: 80
    - host: b.local
       
      http:
  - host: b.local
        paths:
    http:
          - path: /
      paths:
            backend:
      - path: /
              serviceName: target-service-b
        backend:
              servicePort: 80
          serviceName: b
          servicePort: 80
   # This section is only required if TLS is to be enabled for the Ingress
   # This section is only required if TLS is to be enabled for the Ingress
   tls:
   tls:

Revision as of 02:33, 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:

ingress-nginx

Once installed, the access to the ingress controller pod(s) is performed via its own LoadBalancer/NodePort/ClusterIP service.

To access a service through an its external name, the external service DNS name must resolve to the public IP address of the load balancer deployed by the ingress controller's LoadBalancer service.

Ingress API Resource

https://kubernetes.io/docs/concepts/services-networking/ingress/

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: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  name: example
spec:
  rules:
  - host: a.local
    http:
      paths:
      - path: /
        backend:
          serviceName: a
          servicePort: 80
        
  - host: b.local
    http:
      paths:
      - path: /
        backend:
          serviceName: b
          servicePort: 80
  # This section is only required if TLS is to be enabled for the Ingress
  tls:
    - hosts:
        - a.local
      secretName: example-tls-a

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>