雲原生之旅 – 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,詳見://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 變化的動態配置及主動健康檢查等功能。

 
關鍵詞:Ingress nginx入門,Ingress nginx安裝,同一集群多Ingress Nginx安裝,Ingress nginx使用
 

安裝

測試環境

  • 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

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

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

build and apply

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

kubectl apply -f ~/deploy.yaml

 

多個 Ingress Nginx Controller 部署

同一個cluster 如果要安裝另一個ingress nginx controller,比如作為內部API網關,該怎麼實現呢?

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

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

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

 

總結

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

 

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