自動化測試在 Kubernetes Operator 開發中的應用
背景
最近在給 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@latestkind 使用
在開始前還是先預習下 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-selecttests/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:
- --cnotallow=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 中進行查看。
參考鏈接：
