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 set up a reverse proxy in accordance with the Ingress object.

The 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 cuberates (GKE, AKS), MetalLB if it has a prescription 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 the 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)

NodePort

Putting 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 controllers (for example, for production and staging).

Hostport

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 10.0.0.1 ingress.example.org A 10.0.0.2 ingress.example.org A 10.0.0.3 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.

 kind: DaemonSet apiVersion: extensions/v1beta1 metadata: name: traefik-ingress-controller namespace: traefik labels: k8s-app: traefik-ingress-lb spec: template: metadata: labels: k8s-app: traefik-ingress-lb name: traefik-ingress-lb namespace: traefik spec: serviceAccountName: traefik-ingress-controller terminationGracePeriodSeconds: 60 containers: - image: traefik:1.7.6 name: traefik-ingress-lb ports: - name: http containerPort: 80 hostPort: 80 - name: https containerPort: 443 hostPort: 443 - name: admin containerPort: 8080 hostPort: 8080 securityContext: capabilities: drop: - ALL add: - NET_BIND_SERVICE args: - --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.