云原生之旅 - 8）云原生時代的網關 Ingress Nginx

前言

當我們在Kubernetes部署的服務需要暴露給外部用戶使用時，有三種選擇：LoadBalancer，NodePort， Ingress，

LoadBalancer型別得結合各個Cloud Provider提供的LB來使用，如果需要暴露的service很多，需要很多LB以及公網IP，比較浪費cost，

NodePort 方式一個埠只能一個服務使用，根據埠劃分服務，可用埠范圍：30000~32767， 同樣如果在暴露的servicie很多的情況下會導致節點要開的埠越來越多，不好管理，平時測驗可以用用，

Ingress是自kubernetes1.1版本后引入的資源型別，在這個資源中我們可以去配置我們的服務路由規則，但是要真正去實作識別這個 Ingress 并提供代理路由功能，還需要安裝一個對應的控制器Ingress controller才能實作，Ingress nginx controller 本質上就是kubernetes 部署的pod 里面有一個 Nginx container，只不過它能根據 Ingress 資源的定義動態生成 Nginx 的組態檔，然后動態 Reload，可以理解成 Ingress controller是由Kubernetes管理的負載均衡器，

Ingress controller是以一種插件的形式提供，有多種實作，有基于 Nginx 的，也有基于 HAProxy的，還有現在很流行的Envoy，詳見：https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/， 我后面文章也會介紹基于 Envoy的 Ingress controller，

本文使用Kubernetes 社區推出的 Ingress Controller: Ingress-nginx (github.com/kubernetes/ingress-nginx) 它是基于Nginx 的擴展版 OpenResty 及諸多第三方模塊構建的，其基于 OpenResty 的 Lua 嵌入式編程能力，擴展了 Nginx 的功能，并基于 balancer_by_lua 模塊實作了 Pod 變化的動態變更功能，

要注意區分另外一個名字相近由Nginx公司推出的Nginx ingress controller (github.com/nginxinc/kubernetes-ingress)，Nginx 官方版本提供其基于Go語言開發的 Ingress 控制器，并與 Nginx 集成分為 Nginx 開源版和 Nginx Plus 版，開源版僅基于 Nginx 的原始功能，不支持 Pod 變化的動態變更，Nginx Plus 版則提供了諸多完善的商業功能，其支持 Nginx 原生配置指令、JWT 驗證、Pod 變化的動態配置及主動健康檢查等功能，

安裝

測驗環境

• Kubernetes 1.22（GKE）
• Ingress Nginx 1.3.0
• Kustomize 3.10.0 

安裝及使用

安裝方式有多種，我這里介紹使用Kustomize 安裝， Kustomize入門可以參考我這篇文章【云原生之旅 - 6）不能錯過的一款 Kubernetes 應用編排管理神器 Kustomize】

k8s manifests 參考 my repo

根據需要修改自己所需，這里的例子是為 atlantis namespace 下面的 atlantis serivce 配置一個Ingress

由于Ingress controller 和 Ingress 均安裝在dmz namespace， 和 atlantis 不在同一個namespace下面，我們需要為atlantis serivce 加了一個 ExternalName 型別的service 相當于別名，

這樣dmz namespace 下面 Ingress 就指向 -> ExternalName 型別的service -> 指向 atlantis ns 下面  atlantis svc，

（Optional）Ingress 和 atlantis 放在同一個namespace 下面，就不需要多一個 ExernalName service了，

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: sre-ingress-resource
  annotations:
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "300"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "300"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
    nginx.ingress.kubernetes.io/proxy-body-size: 100m
    nginx.ingress.kubernetes.io/proxy-buffer-size: 512k
    nginx.ingress.kubernetes.io/client-body-buffer-size: 512k
    ingress.kubernetes.io/ssl-redirect: "true"
    ingress.kubernetes.io/force-ssl-redirect: "true"

spec:
  ingressClassName: nginx
  rules:
  - host: atlantis-demo.wadexu.cloud
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: atlantis-demo-ext-svc
            port:
              number: 8080
  tls:
  - hosts:
    - atlantis-demo.wadexu.cloud
    secretName: wade-tls-secret

---
apiVersion: v1
kind: Service
metadata:
  name:  atlantis-demo-ext-svc
spec:
  type: ExternalName
  externalName: atlantis.atlantis.svc.cluster.local
  ports:
  - name: http
    port: 8080
    targetPort: 4141
    protocol: TCP

build and apply

kustomize build ingress-nginx-public/sre-mgmt-dev/ > ~/deploy.yaml

kubectl apply -f ~/deploy.yaml

 因為用了 https ，所以需要加一個tls-secret

kubectl create secret -n dmz tls wade-tls-secret \
  --key ./xxx.key \
  --cert ./xxx.pem

多個 Ingress Nginx Controller 部署

同一個cluster 如果要安裝另一個ingress nginx controller，比如作為內部API網關，該怎么實作呢？

為了避免多個ingress controller 以一種困惑的方式同時爭搶更新 ingress status欄位，需要使用IngressClasses 官方檔案

另外還要注意資源重名的情況，需要改name，否則后部署的Ingress controller 會覆寫前者, 比如 ClusterRoleBinding

參考 my manifests 部署在app namespace的internal Ingress nginx 針對以上資源的修改，

如不了解 Kustomize build，請先參考入門檔案【云原生之旅 - 6）不能錯過的一款 Kubernetes 應用編排管理神器 Kustomize】

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
spec:
  controller: k8s.io/internal-ingress-nginx

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: app
commonLabels:
  app.kubernetes.io/name: internal-ingress-nginx
  app.kubernetes.io/instance: internal-ingress-nginx
resources:
- ../../base
patchesStrategicMerge:
- ingress-class-patch.yaml
patches:
  - target:
      kind: IngressClass
      name: nginx
    patch: |-
      - op: replace
        path: /metadata/name
        value: internal-nginx
  - target:
      kind: Deployment
      name: ingress-nginx-controller
    patch: |-
      - op: replace
        path: /metadata/name
        value: internal-ingress-nginx-controller
      - op: replace
        path: /spec/template/spec/containers/0/args/3
        value: "--controller-class=k8s.io/internal-ingress-nginx"
      - op: replace
        path: /spec/template/spec/containers/0/args/4
        value: "--ingress-class=internal-nginx"
  - target:
      kind: ClusterRoleBinding
      name: ingress-nginx
    patch: |-
      - op: replace
        path: /metadata/name
        value: internal-ingress-nginx
  - target:
      kind: ClusterRoleBinding
      name: ingress-nginx-admission
    patch: |-
      - op: replace
        path: /metadata/name
        value: internal-ingress-nginx-admission
  - target:
      kind: ValidatingWebhookConfiguration
      name: ingress-nginx-admission
    patch: |-
      - op: replace
        path: /metadata/name
        value: internal-ingress-nginx-admission

總結

一般來說，Ingress nginx 足以應付大部分場景了，除非你想用到一些高階功能，比如流量管理，熔斷等等，那么我會推薦 后起之秀基于Enovy的那些Ingress controller，比如Ambassador 現在叫Emissary， CNCF的incubating 專案，

感謝閱讀，如果您覺得本文的內容對您的學習有所幫助，您可以打賞和推薦，您的鼓勵是我創作的動力，

標籤：其他

上一篇：kubernetes之Ingress發布應用實作rewrite重寫并配置HTTPS；(二)

下一篇：常見的開源協議介紹和使用