Kubernetes Ingress through the eyes of a novice

    What is ingress?

    Ingress is the base type of the resource in the file object. If you simply declare an object of type Ingress in cubicles, then nothing will happen.

    In order for this resource to start working in a cluster of cubnettes, the Ingress Controller must be installed, which will configure the reverse proxy according to the Ingress object.

    Ingress Controller consists of 2 components - a reverse proxy and a controller that communicates with the API server of the cuberettes. A reverse proxy listens for incoming traffic on ports that are specified in the settings (usually only port 80 is specified in the default settings). The controller can be either a separate daemon (as in nginx) or embedded in a proxy (as in traefik).

    Not all cloud providers in Curnertes pre-install Ingress Controller by default.

    Controllers can run as either DaemonSet or Deployment. DaemonSet is ideally used as the only Ingress Controller, so that the reverse proxy listens on all IP addresses of workers. Deployment is great if there is a balancer in front of the Ingress controller - from the provider of cubernetis (GKE, AKS), MetalLB if it is a preamp or the usual haproxy / nginx installed on the server (manual configuration is required). With this installation it is possible to install several Ingress Controller.

    How incoming traffic hits Ingress Controller

    In all cases, the reverse proxy in Ingress Controller listens to ports where it expects an http / https connection.

    Traffic to these ports can come in three ways:

    • NodePort (on random ports in the range 30000-32767)
    • HostPort (can be hung on ports 80, 443)
    • Host network - Pod pledges its ports on the public network interface (i.e. all container ports will be open)


    Placing an Ingress Controller on a NodePort without LoadBalancer makes little sense, since the URL will include the port that is specified in the NodePort http://domain.example.org:32200/ .

    For this option it is better to use Deployements. This will make it easier to scale the number of pods responsible for incoming traffic, assign nodeAffinity to them and run several ingress controller (for example, for production and staging).


    When using HostPort, the port is forwarded from the host where it is launched under this very Pod. LoadBalancer is not needed to enter, but for the operation of the site in DNS you need to specify that the domain address is on all nodes.

    DNS configuration example for 3 workers:

    ingress.example.org A
    ingress.example.org A
    ingress.example.org A
    www.example.org CNAME ingress.example.org

    For this installation, it is best to use DaemonSet. it allows you to run no more than one Pod on a host. Deployment is possible, but it makes little sense. It is necessary to register affinity so that 2 Pods are not assigned to one host, otherwise there will be a conflict over the ports.

    Configuration example for traefik
    kind: DaemonSet
    apiVersion: extensions/v1beta1
      name: traefik-ingress-controller
      namespace: traefik
        k8s-app: traefik-ingress-lb
            k8s-app: traefik-ingress-lb
            name: traefik-ingress-lb
            namespace: traefik
          serviceAccountName: traefik-ingress-controller
          terminationGracePeriodSeconds: 60
          - image: traefik:1.7.6
            name: traefik-ingress-lb
            - name: http
              containerPort: 80
              hostPort: 80
            - name: https
              containerPort: 443
              hostPort: 443
            - name: admin
              containerPort: 8080
              hostPort: 8080
                - ALL
                - NET_BIND_SERVICE
            - --api
            - --kubernetes
            - --logLevel=DEBUG
            - --entrypoints=Name:https Address::443 TLS
            - --entrypoints=Name:http Address::80
            - --defaultentrypoints=http

    Host network

    When launching Ingress Controller in a shared network with a host, no forwarding of ports is required, but in this case all ports that are open in the Pod will be accessible from the Internet. For start it is better to use DaemonSet. The reasons are the same as with HostPort - to avoid port conflicts.

    What to choose

    If there is a LoadBalancer at the entrance - NodePort, if not - HostPort + DNS Round Robin. For experiments, you can try the Host network, but this is not safe.

    Also popular now: