The host nginx

Generally, nGINx serves as the reverse proxy (gateway) of the host

Upstream order {server 192.168.1.10:5001; Server 192.168.1.11:5001; } server { listen 80; server_name order.example.com; access_log /var/log/nginx/order.example.com-access.log;
    error_log     /var/log/nginx/order.example.com-error.log;
    location / {
        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme; proxy_pass http://order; }}Copy the code

Where 192.168.1.10:5001, 192.168.1.10:5001, we call them endpoints, which are called specific services, such as the order service.

pod nginx-ingress

Nginx-ingress is also an agent. It is a POD through which external data is uniformly transmitted and then transmitted to each service Endpoint through the internal NGINx direction of the POD. Nginx-ingress is one of the ingress controller plugins. There are many plugins, such as istio-ingressGateway.

1, the Pod

Nginx-ingress Pod has two functions, controller and nginx:

Controller: communicates with the Kubernetes API to update nginx configurations in real timeCopy the code

Unlike the host nginx, the Pod Nginx-ingress runs in a Pod. When defining the reverse proxy configuration file, the host needs to listen on an open port, such as port 80. So how is the Nginx port configured in pod? We found deployment.yaml for Nginx-Ingress on Github

https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml
Copy the code

One of the segment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      # wait up to five minutes for the drain of connectionsterminationGracePeriodSeconds: 300 serviceAccountName: nginx-ingress-serviceaccount containers: - name: Nginx ingress - controller image: quay. IO/kubernetes - ingress - controller/nginx - ingress - controller: 0.26.1... . . ports: - name: http containerPort: 80 - name: https containerPort: 443Copy the code

We see

- name: http
  containerPort: 80
- name: https
  containerPort: 443
Copy the code

By default, ports 80 and 443 are listened on externally, which means that web services can be performed externally with these two ports.

2. Ingress resources

Ingress resources are managed through YAML, such as:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: order
spec: 
  rules:
  - host: order.example.com
    http:
      paths: /
      backend: 
        serviceName: order
        servicePort: 80
Copy the code

Above we define a single rule ingress. This POD (nginx-ingress) receives all external requests and will be sent to port 80 of the internal Order service. How can pod (nginx-ingress) convert ingress resources into nginx reverse proxy configuration files

upstream order{ server order:80; } server { listen 80; server_name order.example.com; . . location / { proxy_pass_header Server; proxy_set_header Host$http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;
        proxy_pass http://order; # Ingress resource name: order}}Copy the code

If the ingress contains HTTPS, it will convert port 443 of nginx and the contents of the certificate configuration file.

Then, how can a single rule ingress resource proxy multiple services (such as order service, product service) or multiple Ingress resource files be converted to nGINx configuration? Guess, in fact, is transformed into multiple

upstream order{
    server order:80;
}
Copy the code

Of course, the converted nginx configuration files are much more complex than these, and are said to be written in Lua scripts that are as flexible as OpenResty.

3. Nginx-ingress provides external services

Generally speaking, there are only two ways for POD to directly provide services to external users:

  • Create a service that leaks the nodePort
  • The forward mapping

We usually use the first one. Nginx-ingress is also a POD. Therefore, in order to enable external access through the POD agent, nginx-ingress also needs to provide a nodePort service. I’m not going to write this service anymore.

4. Nginx-ingress workflow