在 KubeSphere 中使用 APISIX Ingress 閘道器接入自定義監控

KubeSphere發表於2021-12-01

KubeSphere 3.2.0 釋出了!為專案閘道器增配了整套監控及管理頁面,同時引入了叢集閘道器來提供叢集層面全域性的 Ingress 閘道器能力。當然,我們還是可以部署使用第三方 Ingress Controller,本文將以 Apache APISIX Ingress Controller 為例介紹如何通過 KubeSphere 快速為 Kubernetes 叢集使用兩種不同型別的閘道器,同時對它們的使用狀態進行監控。

本文將分為一下幾部分展開:

  • KubeSphere 專案閘道器的新管理介面的應用展示
  • 通過 KubeSphere 的應用管理能力快速使用 Apache APISIX Ingress Controller
  • 利用 KubeSphere 的自定義監控能力獲取 Apache APISIX 閘道器的執行指標

準備工作

安裝 KubeSphere

安裝 KubeSphere 有兩種方法。一是在 Linux 上直接安裝,可以參考文件:在 Linux 安裝 KubeSphere; 二是在已有 Kubernetes 中安裝,可以參考文件:在 Kubernetes 安裝 KubeSphere

KubeSphere 最小化安裝版本已經包含了監控模組,因此不需要額外啟用,可以通過「系統元件」頁面中的「監控」標籤頁確認安裝狀態。

部署 httpbin 演示應用

由於需要演示閘道器的訪問控制能力,我們必須要先有一個可以訪問的應用作為閘道器的後臺服務。這裡我們使用 httpbin.org 提供的 kennethreitz/httpbin 容器應用作為演示應用。

在 KubeSphere 中,我們可以先建立新的專案或使用已有的專案,進入專案頁面後,選擇「應用負載」下的「服務」直接建立無狀態工作負載並生成配套的服務。

使用 kennethreitz/httpbin 容器預設的 80 埠作為服務埠,建立完成後確保在「工作負載」和「服務」頁面下都可以看到 httpbin 的對應條目,如下圖所示。

專案閘道器的新面貌

專案閘道器 是 KubeSphere 3.0 以來就有的功能:“KubeSphere 專案中的閘道器是一個 NGINX Ingress 控制器。KubeSphere 內建的用於 HTTP 負載均衡的機制稱為 應用路由,它定義了從外部到叢集服務的連線規則。如需允許從外部訪問服務,使用者可建立路由資源來定義 URI 路徑、後端服務名稱等資訊。”

下面我們首先進入已部署了 httpbin 服務的專案,在「專案設定」中開啟「閘道器設定」頁面,然後執行「開啟閘道器」操作。方便起見,直接選擇 NodePort 作為「訪問方式」即可。

確定後回到閘道器頁面,稍等片刻後重新整理頁面,可以得到如下圖這樣的部署完成狀態,可以看到 NodePort 預設被賦予了兩個節點埠。下面我們通過右上角的「管理」按鈕「檢視詳情」。

此時我們看到的便是 3.2.0 新帶來的專案/叢集閘道器的新監控頁面!但是現在顯然是沒有資料的,因為我們還沒有任何流量從閘道器產生。那麼下面我們就需要為 httpbin 服務建立應用路由。

從「應用負載」進入「應用路由」頁面,開始「建立」路由。為路由取名為 httpbin 後,我們指定一個方便測試的域名,並設定「路徑」為 /, 選擇「服務」httpbin 和「埠」80

直接下一步跳過高階設定後完成路由建立,可以得到如下圖這樣的一條新的 httpbin 應用路由項。

下面我們可以通過專案閘道器的 NodePort 地址及指定的域名(如這裡是 http://httpbin.ui:32516)來訪問 httpbin 應用服務,隨意重新整理或操作一下頁面的請求生成功能,再進入閘道器的詳情頁面,便可以看到在「監控」皮膚上已經出現了閘道器的一些內建的監控指標展示。

為閘道器指定 NodePort 節點埠

對於公有云環境,如果使用 NodePort 方式向外暴露訪問能力,開放埠通常是有限且受控的,因此對於閘道器所使用的 NodePort 我們需要能夠對它進行修改。

由於閘道器是被 KubeSphere 統一管理的,要修改閘道器服務的 NodePort,需要具備訪問 kubesphere-controls-system 專案的許可權。進入改專案後,通過「應用負載」的「服務」頁面即可找到命名為 kubesphere-router-<project-namespace> 形式且外部訪問已開放 NodePort 的閘道器服務。NodePort 服務埠需要通過「編輯 YAML」來直接修改。

開始使用叢集閘道器

在 KubeSphere 3.1 中只支援專案級別的閘道器,如果使用者的專案過多,勢必會造成資源的浪費。而且不同的企業空間中的閘道器都是相互獨立的。

KubeSphere 3.2.0 開始支援叢集級別的全域性閘道器,所有專案可共用同一個閘道器,之前已建立的專案閘道器也不會受到叢集閘道器的影響。也可以統一納管所有專案的閘道器,對其進行集中管理和配置,管理員使用者再也不需要切換到不同的企業空間中去配置閘道器了。

進入 KubeSphere 3.2.0 版本之後,我們更推薦大家使用叢集閘道器的功能來統一整個叢集的應用路由。要啟用叢集閘道器其實也非常簡單:使用具備叢集管理許可權的賬號,進入其可管理的某個叢集(如我們這裡以 default 叢集為例),在「叢集設定」的「閘道器設定」中即可「開啟閘道器」,同時檢視「專案閘道器」。

叢集閘道器開啟的方式以及對齊 NodePort 訪問埠的修改和之前專案閘道器的操作基本上是完全一樣的,所以這裡對過程就不做過多贅述了。

⚠️ 有一點需要特別注意的是:叢集閘道器開啟後,已經開啟的專案閘道器還會保留;但尚未建立閘道器的專案是無法再建立單獨的閘道器的,會直接使用叢集閘道器。

下圖展示了已建立閘道器的專案,在同時擁有專案及叢集閘道器後,在「閘道器設定」頁面所呈現的所有閘道器概覽。

快速使用 Apache APISIX Ingress Controller

Apache APISIX 是一款開源的高效能、動態雲原生閘道器,由深圳支流科技有限公司於 2019 年捐贈給 Apache 基金會,當前已經成為 Apache 基金會的頂級開源專案,也是 GitHub 上最活躍的閘道器專案。Apache APISIX 當前已經覆蓋了 API 閘道器,LB,Kubernetes Ingress,Service Mesh 等多種場景。

社群之前也介紹過如何 使用 Apache APISIX 作為 Kubernetes 的 Ingress Controller,本文講更多側重介紹前文未涉及之細節,並結合 KubeSphere 的一些新功能加以具像化。

部署 Apache APISIX Ingress Controller

首先還是先要新增 Apache APISIX Helm Chart 倉庫,推薦用這種自管理的方式來保障倉庫內容是得到及時同步的。我們選定一個企業空間後,通過「應用管理」下面的「應用倉庫」來新增如下一個 Apache APISIX 的倉庫(倉庫 URL:https://charts.apiseven.com)。

接下來我們建立一個名為 apisix-system 的專案。進入專案頁面後,選擇在「應用負載」中建立「應用」的方式來部署 Apache APISIX,並選擇 apisix 應用模版開始進行部署。

為何是部署 Apache APISIX 應用的 Helm Chart,而不是直接部署 Apache APISIX Ingress Controller?

這是因為 Apache APISIX Ingress Controller 目前和 Apache APISIX 閘道器是強關聯的(如下圖所示),且目前通過 Apache APISIX Helm Charts 同時部署 Apache APISIX Gateway + Dashboard + Ingress Controller 是最方便的,因此本文推薦直接使用 Apache APISIX 的 Helm Chart 進行整套元件的部署。

將應用命名為 apisix 以避免多個元件(Gateway, Dashboard, Ingress Controller)的工作負載及服務名稱產生不匹配的情況;在安裝步驟中編輯的「應用設定」的部分,請參照以下配置進行填寫(請特別注意帶有【注意】標記的註釋部分的說明,其餘可以按需自行編輯修改)。

global:
  imagePullSecrets: []
  
apisix:
  enabled: true
  customLuaSharedDicts: []
  image:
    repository: apache/apisix
    pullPolicy: IfNotPresent
    tag: 2.10.1-alpine
  replicaCount: 1
  podAnnotations: {}
  podSecurityContext: {}
  securityContext: {}
  resources: {}
  nodeSelector: {}
  tolerations: []
  affinity: {}
  podAntiAffinity:
    enabled: false
    
nameOverride: ''
fullnameOverride: ''

gateway:
  type: NodePort
  externalTrafficPolicy: Cluster
  http:
    enabled: true
    servicePort: 80
    containerPort: 9080
  tls:
    enabled: false
    servicePort: 443
    containerPort: 9443
    existingCASecret: ''
    certCAFilename: ''
    http2:
      enabled: true
  stream:
    enabled: false
    only: false
    tcp: []
    udp: []
  ingress:
    enabled: false
    annotations: {}
    hosts:
      - host: apisix.local
        paths: []
    tls: []
    
admin:
  enabled: true
  type: ClusterIP
  externalIPs: []
  port: 9180
  servicePort: 9180
  cors: true
  credentials:
    admin: edd1c9f034335f136f87ad84b625c8f1
    viewer: 4054f7cf07e344346cd3f287985e76a2
  allow:
    ipList:
      - 0.0.0.0/0
      
plugins:
  - api-breaker
  - authz-keycloak
  - basic-auth
  - batch-requests
  - consumer-restriction
  - cors
  - echo
  - fault-injection
  - grpc-transcode
  - hmac-auth
  - http-logger
  - ip-restriction
  - ua-restriction
  - jwt-auth
  - kafka-logger
  - key-auth
  - limit-conn
  - limit-count
  - limit-req
  - node-status
  - openid-connect
  - authz-casbin
  - prometheus
  - proxy-cache
  - proxy-mirror
  - proxy-rewrite
  - redirect
  - referer-restriction
  - request-id
  - request-validation
  - response-rewrite
  - serverless-post-function
  - serverless-pre-function
  - sls-logger
  - syslog
  - tcp-logger
  - udp-logger
  - uri-blocker
  - wolf-rbac
  - zipkin
  - traffic-split
  - gzip
  - real-ip
  #【注意】新增此外掛以配合 Dashboard 展示服務資訊
  - server-info

stream_plugins:
  - mqtt-proxy
  - ip-restriction
  - limit-conn

customPlugins:
  enabled: true
  luaPath: /opts/custom_plugins/?.lua
  #【注意】如下配置保障 Prometheus 外掛可對外暴露指標
  plugins:
      - name: prometheus
        attrs:
          export_addr:
            ip: 0.0.0.0
          port: 9091
      configMap:
          name: prometheus
        mounts: []

dns:
  resolvers:
    - 127.0.0.1
    - 172.20.0.10
    - 114.114.114.114
    - 223.5.5.5
    - 1.1.1.1
    - 8.8.8.8
  validity: 30
  timeout: 5

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  targetMemoryUtilizationPercentage: 80

configurationSnippet:
  main: ''
  httpStart: ''
  httpEnd: ''
  httpSrv: ''
  httpAdmin: ''
  stream: ''

etcd:
  enabled: true
  host:
    - 'http://etcd.host:2379'
  prefix: /apisix
  timeout: 30
  auth:
    rbac:
      enabled: false
      user: ''
      password: ''
    tls:
      enabled: false
      existingSecret: ''
      certFilename: ''
      certKeyFilename: ''
      verify: true
  service:
    port: 2379
  replicaCount: 3

dashboard:
  enabled: true
  #【注意】為 Dashboard 開啟 NodePort 方便後續使用
  service:
      type: NodePort

ingress-controller:
  enabled: true
  config:
    apisix:
        #【注意】一定要設定 gateway 所在的 namespace
      serviceNamespace: apisix-system
  serviceMonitor:
    enabled: true
    namespace: 'apisix-system'
    interval: 15s

部署成功後,點選應用名稱進入詳情頁面,可以在「資源狀態」標籤頁下看到如下的服務部署和工作狀態執行狀態展示。

? Apache APISIX 專案另有的兩個 Helm Chart 對應的預設配置引數可以分別參考:DashboardIngress Controllervalues.yaml

使用 Apache APISIX Dashboard 瞭解系統資訊

Apache APISIX 應用部署完成後,首先我們通過 Apache APISIX Dashboard 來檢驗一下 Apache APISIX 閘道器的當前狀態。從「應用負載」的「服務」頁面,我們可以找到 apisix-dashboard 的服務,由於我們在應用配置中已經為 Dashboard 開啟了 NodePort,所以這裡我們可以直接通過 NodePort 埠來訪問 Dashboard。

使用預設的使用者名稱及密碼 admin 登入 Apache APISIX Dashboard,可以進入「系統資訊」頁面即可檢視到我們當前連線管理的「Apache APISIX 節點」的資訊。

使用 Apache APISIX Ingress Controller

讓我們回到「應用路由」頁面,另外新建一個路由(如 apisix-httpbin),設定路徑為 /* httpbin 80 併為其新增 kubernetes.io/ingress.class: apisix 的鍵值。

建立完成後如何驗證應用路由生效呢?首先,我們可以回到 Apache APISIX Dashboard,進入「路由」頁面,可以看到新建的應用路由已經被 Apache APISIX Ingress Controller 識別之後自動新增到了 Apache APISIX 閘道器中,在「上游」頁面也可以看到自動建立的一個上游條目。

然後我們回到 apisix-system 專案的「服務」頁面,找到 apisix-gateway 服務對應的埠,由此訪問 <apisix-httpbin 應用路由指定的域名>:<apisix-gateway 外部訪問埠>(例如此處為 httpbin.ui:30408)即可訪問到 apisix-httpbin 應用路由所關聯的後臺服務。

自定義監控 Apache APISIX 閘道器

Apache APISIX 閘道器可用之後其實是缺少像原生叢集或專案閘道器這樣自帶的狀態監控能力的,但這個我們也可以通過 Apache APISIX 的 Prometheus 外掛以及 KubeSphere 自帶的自定義監控能力來彌補。

暴露 Apache APISIX 閘道器的 Prometheus 監控指標

由於我們在部署 Apache APISIX 應用時已經開啟了 Prometheus 外掛,所以這裡我們只需要把 Prometheus 監控指標的介面暴露出來即可。進入 apisix-system 專案,在「工作負載」頁面找到 apisix 並進入部署詳情頁面,隨後在左側操作皮膚的「更多操作」中選擇「編輯設定」。

在彈出的「編輯設定」皮膚中,進入到 apisix 容器的編輯介面,找到「埠設定」,新增一個新的名為 prom 的埠對映到容器的 9091 埠,儲存後 apisix 工作負載會重啟。

為 Apache APISIX 閘道器監控指標建立 ServiceMonitor

下面我們需要將已暴露的指標介面接入到 KubeSphere 自帶的 Prometheus 中使之可被訪問(被抓取指標資料),由於 KubeSphere 是通過 Prometheus Operator 來維護內部的 Prometheus 系統的,所以最方便的方式自然是直接建立一個 ServiceMonitor 資源來實現指標介面的接入。

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: apisix
  namespace: apisix-system
spec:
  endpoints:
    - scheme: http
        #【注意】使用上一步中工作負載暴露的容器埠名稱
        targetPort: prom
        #【注意】需要正確繫結 apisix 對應的指標介面路徑
        path: /apisix/prometheus/metrics
      interval: 15s
  namespaceSelector:
    matchNames:
      - apisix-system
  selector:
    matchLabels:
      app.kubernetes.io/name: apisix
      app.kubernetes.io/version: 2.10.0
      helm.sh/chart: apisix-0.7.2

使用 kubectl apply -f your_service_monitor.yaml 建立這個 ServiceMonitor 資源。建立成功後,如果有叢集管理許可權,也可以在叢集的 CRD 管理頁面中搜尋檢視 ServiceMonitor 資源並找到名為 apisix 的自定義資源,也可以在這裡做後續的 YAML 修改。

將 Apache APISIX 閘道器指標接入自定義監控皮膚

下面我們在專案左側選單列表中找到「監控告警」中的「自定義監控」,開始「建立」自定義監控皮膚。

在彈出視窗中填入「名稱」,選擇「自定義」監控模版,並進入「下一步」的監控皮膚建立。

進入編輯頁面後現在左側點選 + 區域,在右側的「資料」區域進行 Prometheus 監控指標的配置,例如這裡我們可以用 sum(apisix_nginx_http_current_connections) 來統計 Apache APISIX 閘道器實時的連線總數。

儲存後在頁面右下角找到「+ 新增監控項」,我們選擇「折線圖」來建立一個 Nginx connection state 指標:使用 sum(apisix_nginx_http_current_connections) by (state) 作為指標、{{state}} 用作圖例名稱、選擇「圖例型別」為堆疊圖,即可得到類似如下的圖表顯示效果。儲存模版後即可得到您的第一個自定義監控皮膚!

Apache APISIX 閘道器目前提供的 Prometheus 指標可以參見官方文件的 可有的指標 部分。

由於指標配置起來還是比較麻煩的,推薦在叢集層面的「自定義監控」中直接匯入 Apache APISIX Grafana 模版(下載 JSON 通過「本地上傳」進行匯入)。

建立完成後可以直接得到一個非常豐富的 Apache APISIX 閘道器監控皮膚。KubeSphere 也同時在 積極推進 將 Grafana 模版匯入的功能引入到專案的自定義監控能力中去,敬請期待!

至此,我們瞭解了 KubeSphere 3.2.0 中新的專案及叢集閘道器的更豐富的狀態資訊展示能力;同時也完成了 Apache APISIX Ingress 閘道器接入 KubeSphere 並對其使用自定義監控。讓我們開啟 KubeSphere 應用閘道器的奇妙旅程吧~

本文由部落格一文多發平臺 OpenWrite 釋出!

相關文章