自動化測試在 Kubernetes Operator 開發中的應用：以 OpenTelemetry 為例

crossoverJie發表於2024-05-28

背景

最近在給 opentelemetry-operator提交一個標籤選擇器的功能時，因為當時修改的函式是私有的，無法新增單測函式，所以社群建議我補充一個 e2e test.

因為在當前的版本下，只要給 deployment 打上了 instrumentation.opentelemetry.io/inject-java: "true" 這類註解就會給該 deployment 注入 agent。
但沒辦法指定不同的 agent 版本（或者不同的環境變數），所以希望可以新增一個選擇器，同時可以針對不同的 deployment 維護不同版本的 Instrumentation(是用於控制需要注入 deployment 的資源)；這樣就可以靈活控制了。

在這之前我其實也很少做 kubernetes 的 operator 開發，對如何做 kubernetes 的 e2e 測試也比較陌生，好在社群提供了詳細的貢獻文件。

安裝

簡單來說需要兩個關鍵元件：

  • kind: kubernetes in docker，是可以在本地利用 docker 啟動一個 kubernetes 叢集的工具，通常用於在本地進行開發、測試關於 kubernetes 相關的功能。
    • 安裝 kind 的前提是本地已經安裝好了 docker。
  • chainsaw: 一個 e2e 測試框架，提供了宣告式的方式定義測試用例，也有著豐富斷言功能。

他們的安裝都很簡單，只要本地安裝好了 golang，直接使用 go install 即可：

go install sigs.k8s.io/kind@v0.22.0
go install github.com/kyverno/chainsaw@latest

kind 使用

在開始前還是先預習下 kind 的基本使用。

安裝好 kind 之後，使用 create cluster 命令可以在本地建立一個 kubernetes 叢集。

kind create cluster -h
Creates a local Kubernetes cluster using Docker container 'nodes'

Usage:
  kind create cluster [flags]


之後只需要等待叢集安裝成功即可，它會在我們的 cat ~/.kube/config 檔案中追加剛才新建叢集的連線資訊。

k config get-contexts
k config use-context xxx

這樣就可以使用這兩個命令來檢視和切換不同的叢集了，雖說是一個本地模擬的 kubernetes 叢集，但他的核心功能和一個標準的叢集沒有什麼區別。

kind delete clusters --all

使用完成之後可以使用這個命令將所有叢集都刪除掉。

準備叢集資料

在 opentelemetry-operator 中有給我們準備好一個 make 命令: make prepare-e2e ；使用它會幫我們將 operator 的測試環境初始化好。

大概分為以下幾步：

  • 安裝 chainsaw
  • 修改 controller 的映象為我們本地構建的映象名稱
  • 本地 docker 映象打包
  • 安裝 cert-manager
  • 安裝 Operator 需要的 CRD
  • 部署 Operator deployment
  • 等待 Operator 啟動成功

不過這裡的安裝過程可能會遇到問題（本質上都是我們的網路問題）：


這種情況可以想辦法手動先把映象拉取到本地，然後 kubernetes 就會從本地倉庫獲取到這個映象。

e2e test

通常我們需要將同一類的測試功能放到一個資料夾裡，比如這樣：

預設情況下 Chainsaw 會查詢目錄下名為 chainsaw-test.yaml 作為引導檔案。

apiVersion: chainsaw.kyverno.io/v1alpha1  
kind: Test  
metadata:  
  creationTimestamp: null  
  name: instrumentation-java  
spec:  
  steps:  
  - name: step-00  
    try:   
    - command:  
        entrypoint: kubectl  
        args:  
        - annotate  
        - namespace  
        - ${NAMESPACE}  
        - openshift.io/sa.scc.uid-range=1000/1000  
        - --overwrite  
    - command:  
        entrypoint: kubectl  
        args:  
        - annotate  
        - namespace  
        - ${NAMESPACE}  
        - openshift.io/sa.scc.supplemental-groups=3000/3000  
        - --overwrite  
    - apply:  
        file: 00-install-collector.yaml  
    - apply:  
        file: 00-install-instrumentation-select.yaml  
  - name: step-01  
    try:  
    - apply:  
        file: 01-install-app-select.yaml  
    - assert:  
        file: 01-assert*.yaml  
    catch:  
      - podLogs:  
          selector: app=my-java-select

tests/e2e-instrumentation/instrumentation-select
├── 00-install-collector.yaml
├── 00-install-instrumentation-select.yaml
├── 01-assert-select.yaml
├── 01-assert-without-select.yaml
├── 01-install-app-select.yaml
└── chainsaw-test.yaml

以我這裡的這份檔案為例，在其中定義了幾個步驟：

  • 初始化環境資訊，包含建立 namespace
  • 安裝我們測試所需要的資源
    • 00-install-collector.yaml：這裡主要是安裝一個 OpenTelemetry 的 collector
    • 00-install-instrumentation-select.yaml：安裝 Instrumentation 注入資源
    • 01-install-app-select.yaml：應用一個我們需要測試的 deployment 資源
    • 01-assert*.yaml：最後對最終生成的 yaml 資源與 assert*.yaml 的進行斷言匹配，只有匹配成功後才能測試成功。

這裡的測試目的主要是完成一個完整的 Java 應用的 deployment 注入 OpenTelemetry 的 agent 過程還有一些與 OpenTelemetry 相關的環境變數。

以 00-install-instrumentation-select.yaml 檔案為例：

apiVersion: opentelemetry.io/v1alpha1  
kind: Instrumentation  
metadata:  
  name: java-select  
spec:  
  selector:  
    matchLabels:  
      app: my-java-select  
  env:  
    - name: OTEL_TRACES_EXPORTER  
      value: otlp  
    - name: OTEL_EXPORTER_OTLP_ENDPOINT  
      value: http://localhost:4317  
  exporter:  
    endpoint: http://localhost:4317  
  propagators:  
    - jaeger  
    - b3  
  sampler:  
    type: parentbased_traceidratio  
    argument: "0.25"  
  java:  
    env:  
    - name: OTEL_JAVAAGENT_DEBUG  
      value: "true"

它的預期效果是選擇 app: my-java-select 的 deployment 將這些環境變數都注入進去，同時預設也會在 deployment 的容器中掛載一個 javaagent.jar:

ls /otel-auto-instrumentation-java/
javaagent.jar

而我們的 01-assert-select.yaml:

apiVersion: v1  
kind: Pod  
metadata:  
  annotations:  
    instrumentation.opentelemetry.io/inject-java: "true"  
    sidecar.opentelemetry.io/inject: "true"  
  labels:  
    app: my-java-select  
spec:  
  containers:  
  - env:  
    - name: OTEL_JAVAAGENT_DEBUG  
      value: "true"  
    - name: JAVA_TOOL_OPTIONS  
      value: ' -javaagent:/otel-auto-instrumentation-java/javaagent.jar'  
    - name: OTEL_TRACES_EXPORTER  
      value: otlp  
    - name: OTEL_EXPORTER_OTLP_ENDPOINT  
      value: http://localhost:4317    
    - name: OTEL_TRACES_SAMPLER  
      value: parentbased_traceidratio  
    - name: OTEL_SERVICE_NAME  
      value: my-java-select   
    - name: OTEL_PROPAGATORS  
      value: jaeger,b3  
    - name: OTEL_RESOURCE_ATTRIBUTES  
    name: myapp  
  - args:  
    - --config=env:OTEL_CONFIG  
    name: otc-container  
  initContainers:  
  - name: opentelemetry-auto-instrumentation-java  
status:  
  containerStatuses:  
  - name: myapp  
    ready: true  
    started: true  
  initContainerStatuses:  
  - name: opentelemetry-auto-instrumentation-java  
    ready: true  
  phase: Running

最終就是把實際的 deployment 的 yaml 內容和這份檔案進行對比。

所以這個 e2e 測試就有點類似於整合測試，不會測試具體的功能函式，只需要最終結果能匹配就可以。

當然這個和單元測試也是相輔相成的，缺一不可，不能完全只依賴 e2e 測試，也有可能是機率原因導致最終生成的資源相同；單元測試可以保證函式功能與預期相同。

都準備好之後便可以進行測試了，測試的時候也很簡單，只需要執行以下命令即可：

chainsaw test --test-dir ./tests/e2e-multi-instrumentation

這樣它就會遍歷該目錄下的 chainsaw-test.yaml檔案進行測試，執行我們上面定義的那些步驟，最終輸出測試結果：

同時 Chainsaw 也提供了 Github action，可以方便的讓我們和 github CI 進行整合。

jobs:
  example:
    runs-on: ubuntu-latest

    permissions: {}

    name: Install Chainsaw
    steps:
      - name: Install Chainsaw
        uses: kyverno/action-install-chainsaw@v0.1.0
        with:
          release: v0.0.9
      - name: Check install
        run: chainsaw version

這樣我們就可以在 github 中檢視我們的測試結果了：

總結

最後不得不感嘆作為 CNCF 下面的專案 OpenTelemetry 的開發者體驗真好，只要我們跟著貢獻者文件一步步操作都能順利透過 CI 測試，同時還能避免一些 Code Review 過程中的低階錯誤。


比如我第一次提 PR 的時候沒有新增 changlog 檔案，後面在貢獻者手冊裡發現只需要執行 make chlog-new 就會基於當前分支資訊幫我們生成一個 changelog 檔案模板，然後只需要往裡面填寫內容即可。

這些工具鏈讓不同開發者提交的程式碼和流程都符合規範，同時也降低了貢獻難度。

以上所有的相關原始碼都可以在 https://github.com/open-telemetry/opentelemetry-operator 中進行檢視。

參考連結：

  • https://github.com/open-telemetry/opentelemetry-operator/pull/2778
  • https://kind.sigs.k8s.io/
  • https://kyverno.github.io/chainsaw/latest/
  • https://github.com/open-telemetry/opentelemetry-operator/blob/main/CONTRIBUTING.md

相關文章