Kubernetes Ingress in 5 min

Welcome to this brief description of Kubernetes Ingress in 5 min. Reader would need some understanding of Kubernetes Services and YAML.

Ingress is mainly use to enable your web applications running in the cluster to be accessible from outside. We can say it’s an API object that manage this external access.

Ingress can’t expose ose any kind of port. Only web apps (other ports will require NodePort/LB)

Ingress brings: 

  • Load balancing
  • SSL termination
  • Name based virtual hosting (layer 7)

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster (i.e. ClusterIP). Traffic routing is controlled by rules defined on the Ingress resource

You can’t define an ingress service without an ingress controller. that’s actually a pod. There are many options for Ingress controllers. The most used is NGINX and it’s also maintained as part of the kubernetes project.

Here you have a minimal definition of a ingress service from kubernes.io documentation:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: wordpress.wordpress.10.10.10.22.xip.io
    http:
      paths:
      - path: /wordpress
        pathType: Prefix
        backend:
          service:
            name: wordpress
            port:
              number: 80

Let’s check some of the metadata and specs values:

  • metadata.annotations depends on the selected ingress controller. On this case we are using “nginx.ingress.kubernetes.io/rewrite-target” which is a target URI where the traffic must be redirected. Check for more details in github doc of the project .
  • In this example, optionally, you can specify a host value: wordpress.wordpress.10.10.10.22.xip.io. If no host is specified, the rule applies to all inbound HTTP traffic through the IP address specified.
  • List of paths that have an associated to a specific service.name and service.port (i.e. ClusterIP)

Optionally you can define a DefaultBackend. If none of the hosts or paths match the HTTP request in the Ingress objects, the traffic is routed to your default backend.

Here you have an example of a Ingress YAML file for a wordpress deployed in Rancher. In this case Rancher has created a ClusterIP automagically called ingress-6ceab33cd0a940c89e275cc1a505d1eb for my replicas of wordpress.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    field.cattle.io/publicEndpoints: '[{"addresses":["10.10.10.22"],"port":80,"protocol":"HTTP","serviceName":"wordpress:wordpress","ingressName":"wordpress:wordpress","hostname":"wordpress.wordpress.10.10.10.22.xip.io","path":"/","allNodes":true}]'
  creationTimestamp: "2020-09-02T23:19:12Z"
  generation: 5
  labels:
    app.kubernetes.io/instance: wordpress
    app.kubernetes.io/managed-by: Tiller
    app.kubernetes.io/name: wordpress
    helm.sh/chart: wordpress-9.0.3
    io.cattle.field/appId: wordpress
  managedFields:
  - apiVersion: networking.k8s.io/v1beta1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .: {}
          f:app.kubernetes.io/instance: {}
          f:app.kubernetes.io/managed-by: {}
          f:app.kubernetes.io/name: {}
          f:helm.sh/chart: {}
          f:io.cattle.field/appId: {}
    manager: Go-http-client
    operation: Update
    time: "2020-09-02T23:19:12Z"
  - apiVersion: extensions/v1beta1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:field.cattle.io/publicEndpoints: {}
      f:spec:
        f:rules: {}
    manager: Go-http-client
    operation: Update
    time: "2020-09-04T14:03:20Z"
  - apiVersion: networking.k8s.io/v1beta1
    fieldsType: FieldsV1
    fieldsV1:
      f:status:
        f:loadBalancer:
          f:ingress: {}
    manager: nginx-ingress-controller
    operation: Update
    time: "2020-09-04T14:03:20Z"
  name: wordpress
  namespace: wordpress
  resourceVersion: "3836011"
  selfLink: /apis/extensions/v1beta1/namespaces/wordpress/ingresses/wordpress
  uid: 8f9da23f-dd75-41c2-9542-c3181e5d6730
spec:
  rules:
  - host: wordpress.wordpress.10.10.10.22.xip.io
    http:
      paths:
      - backend:
          serviceName: ingress-6ceab33cd0a940c89e275cc1a505d1eb
          servicePort: 8080
        path: /
        pathType: ImplementationSpecific

This is it. Thanks and don’t forget to comment.

Source:

Official Kubernetes Documentation: Ingress

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

Stack Overflow – Ingress vs LoadBalancer

https://stackoverflow.com/questions/45079988/ingress-vs-load-balancer

Blog at WordPress.com.