
一般 nginx 做主机反向代理(网关)有以下配置
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;
    }
}其中192.168.1.10:5001,192.168.1.10:5001我们把他们称为 Endpoint,就是所谓的具体的服务,比如 order 订单服务。
nginx-ingress 也是一种代理,是一个 pod,外部的数据统一经过(必经)这个 pod,然后通过该 pod 内部的 nginx 方向代理到各服务(Endpoint)。nginx-ingress 是 ingress 控制器插件的一种,这些插件有很多,比如 istio-ingressgateway。
nginx-ingress pod 有两个功能,controller 和 nginx:
controller:和kubernetes api通讯实时更新nginx配置(就是ingress yaml资源了)
nginx:正常的反向代理与主机 nginx 的区别是,该 pod nginx-ingress 是运行在 pod 里。主机在定义反向代理配置文件时,需要监听一个对外开放的端口,比如上边的 80 端口。那么 pod 中的 nginx 端口是如何配置的呢?
我们在 github 上找到了 nginx-ingress 的 deployment.yaml
https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml其中一段
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 connections
      terminationGracePeriodSeconds: 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: 443我们看到
- name: http
  containerPort: 80
- name: https
  containerPort: 443默认对外监听了两个端口 80 和 443,也就是说,有这两个端口对外就可以 web 服务了。
ingress 资源通过 yaml 进行管理的,比如以下:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: order
spec: 
  rules:
  - host: order.example.com
    http:
      paths: /
      backend: 
        serviceName: order
        servicePort: 80以上我们定义了一个单一规则的 ingress,该 pod(nginx-ingress)接收到外部所有的请求,将被发送到内部 order 服务的 80 端口上。
接下来我们看 pod(nginx-ingress)如何把 ingress 资源转化为该 pod 中的 nginx 反向代理配置文件:
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 资源 name: order
    }
}当然 ingress 如果包含 https,那么会转化 nginx 对应的 443 端口及证书的配置文件内容,这里就不写了。
那么,单一个规则的 ingress 资源代理多个服务(比如 order 服务,product 服务)或者多个 ingress 资源文件如何转化为 nginx 配置?猜测,其实就是转化成了多个。
upstream order{
    server order:80;
}当然,被转化的 nginx 配置文件要比这些复杂的多,据说还是用 lua 脚本写的,灵活如 openresty。
一般来讲,pod 直接对外提供服务就只有两种方式:
我们一般采用第一种。
nginx-ingress 也是一个 pod,所以,为了能使外部通过该 pod 代理访问,还需要 nginx-ingress 对外提供一个 nodePort 的 service。这个 service 这里也不再写了。

我们可以看到,因为 nginx-ingress 这个 pod 做了所有 service 的代理,在高并发情况下将承受巨大压力,我们可以增加多个 pod 实例。
作者:dakesolo 链接:https://juejin.cn/post/6844903957479817230