首页 > 其他分享 >自动化测试在 Kubernetes Operator 开发中的应用:以 OpenTelemetry 为例

自动化测试在 Kubernetes Operator 开发中的应用:以 OpenTelemetry 为例

时间:2024-05-28 10:36:24浏览次数:22  
标签:instrumentation java name Kubernetes 为例 OpenTelemetry yaml install select

背景

最近在给 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/[email protected]
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/[email protected]
        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 中进行查看。

参考链接:

标签:instrumentation,java,name,Kubernetes,为例,OpenTelemetry,yaml,install,select
From: https://www.cnblogs.com/crossoverJie/p/18191262

相关文章

  • Kubernetes(k8s) v1.30.1 本地集群部署 安装metallb 支持LoadBalancer 生产环境 推荐
    1 metallb安装参考:Kubernetes(k8s)v1.30.1本地集群部署默认不支持LoadBalancermetallb来解决-CSDN博客2 删除Layer2模式配置kubectldelete-fIPAddressPool.yamlkubectldelete-fL2Advertisement.yamlkubectldelete-fdiscuz-srv.yaml3配置k8sMeta......
  • Kubernetes中Pod容器的资源限制和探针配置
    前言在Kubernetes中,定义Pod时可以选择性地为每个容器设定所需要的资源数量。最常见的可设定资源是CPU和内存大小,以及其他类型的资源;另一方面,通过配置探针,可以确保容器在运行时保持健康,并且只有在准备好接收流量时才会被负载均衡器引导流量。从而提高应用程序的可靠性和......
  • 改造 Kubernetes 自定义调度器
    原文出处:改造Kubernetes自定义调度器|Jayden'sBlog(jaydenchang.top)OverviewKubernetes默认调度器在调度Pod时并不关心特殊资源例如磁盘、GPU等,因此突发奇想来改造调度器,在翻阅官方调度器框架[1]、调度器配置[2]和参考大佬的文章[3]后,自己也来尝试改写一下。环境......
  • Kubernetes Service 之原理与 ClusterIP 和 NodePort 用法
    KubernetesService之原理与ClusterIP和NodePort用法Service定义在Kubernetes中,由于Pod是有生命周期的,如果Pod重启它的IP可能会发生变化以及升级的时候会重建Pod,我们需要Service服务去动态的关联这些Pod的IP和端口,从而使我们前端用户访问不受后端变更......
  • 部署kubernetes集群机器
    前言:部署Kubernetes集群机器是一项涉及多个步骤和要求的重要任务。以下是一些关于部署Kubernetes集群机器前言的要点:简介:Kubernetes(通常简称为K8s)是一个开源的容器编排系统,用于自动化部署、扩展和管理容器化应用程序。通过Kubernetes,您可以轻松地在集群中运行和管理多个容器......
  • 对话阿里云云原生产品负责人李国强:推进可观测产品与OpenTelemetry开源生态全面融合
    5月22日,在最新一期的飞天发布时刻上,阿里云宣布多款可观测产品全面升级,其中一项是应用实时监控服务ARMS在业内率先推进了与OpenTelemetry开源生态的全面融合,极大丰富了可观测的数据类型及规模,大幅增强了ARMS核心能力。本次阿里云ARMS产品全面升级的背景是什么?为什么会......
  • 【K8s】专题八:Kubernetes 安装方法之 RKE
    以下内容均来自个人笔记并重新梳理,如有错误欢迎指正!如果对您有帮助,烦请点赞、关注、转发!欢迎扫码关注个人公众号!一、RKE简介RKE即 RancherKubernetesEngine,是由Rancher发布的一个极其简单、快速的Kubernetes安装程序,简化了Kubernetes集群的部署过程。RKE经过......
  • kubernetes部署mongoDB 单机版 自定义配置文件、密码、日志路径等
    官方镜像地址:https://hub.docker.com/_/mongo?tab=descriptiondocker版的mongo移除了默认的/etc/mongo.conf,修改了db数据存储路径为/data/db.创建configmap配置,注意不能加fork=true,否则Pod会变成Completed。apiVersion:v1kind:ConfigMapmetadata:name:mongodb-confdat......
  • Kubernetes-ConfigMap详解
    简介:一、ComfigMap的创建1.使用目录创建2.使用文件创建3.使用命令行创建二、Pod中使用ConfigMap1.使用ConfigMap代替环境变量2.使用ConfigMap设置命令行参数3.使用ConfigMap用做数据卷插件三、ConfigMap的热更新简介:ConfigMap功能在Kubernetes1.2版本中引入,许......
  • kubernetes——资源管理
    Kubernetes资源管理介绍kubernetes中,所有的内容都抽象为资源,用户需要通过操作资源来管理kubernetes。kubernetes的最小管理单元是pod而不是容器,所以只能将容器放在pod中,而kubernetes一般也不会直接管理pod,而是通过pod控制器来管理pod的。pod可以提供服务之后,就要考虑如何访......