产品如何做Kubernetes一致性认证

Certified Kubernetes是CNCF基金会在2018年推出的Kubernetes一致性认证计划。它由CNCF基金会提供的一套诊断测试工具(Sonobuoy)并运行在Kubernetes中。各云厂商如果需要将自己产品纳入到Certified Kubernetes当中,就需要按照操作指导进行自身测试,并将测试结果上传给CNCF社区,当报告审核通过,交付一定的费用(CNCF Members免费)后,就会得到CNCF基金会给企业颁发一个Certified Kubernetes的认证。也就是说得到认证后企业就能在自己的产品宣传上使用CNCF基金会的Certified Kubernetes商标和在产品中使用带Kubernetes字样的名称。Certified Kubernetes Logo大概长这个样子。

产品如何做Kubernetes一致性认证_第1张图片

Certified Kubernetes好处

  • 一致性

    只要获得了一致性认证,用户在对任何Kubernetes厂商发行版进行安装或交互时,得到的和原生Kuberentes功能几乎一致的体验

  • 及时更新

    为了保持认证,CNCF基金会要求厂商需要每年或更频繁地提供对最版本的Kubernetes支持。通常情况下来说,厂商提交的产品适配的版本,为官方最新的次要发型版本(x.y)以及最近的两个发行版(x.y-1 和 x.y-2)

    例子。在Kubernetes v1.23发布后,新的合格产品最初可以针对Kubernetes v1.23、v1.22或v1.21进行自我认证,但不能针对v1.20再进行测试。

    了解Kubernetes的同学都知道,K8S几乎每年会以3-4个大版本进行迭代,这样就等于让各大厂商必须跟这个K8S的迭代进行适配。也侧面上加强了社区对于各大厂商的控制
  • 可确认性

    任何终端用户都可以通过运行用于认证的相同的开源一致性应用程序(Sonobuoy)来确认他们的发行版或平台仍然符合要求,以免用户被厂商锁定。

Sonobuoy

Sonobuoy 是一个诊断工具,通过它我们可以访问且以非破坏性的方式运行一组插件(其中包括Kubernetes一致性认证的测试)使我们更轻松地了解 Kubernetes 集群的状态。同时Sonobuoy 也是一种可定制、可扩展和黑盒的方式生成有关Kubernetes集群的相关报告工具。

我们可以用Sonobuoy来对Kubernetes内的资源做如下用例测试:

  • 集成的端到端 (e2e) 一致性测试
  • 工作负载调试
  • 扩展插件来采集自定义数据

环境准备

在使用Sonobuoy之前我们需要准备好如下环境:

  • 一个可以正常访问的Kubernetes集群
  • 拥有被测试Kubernetes集群的ADMIN权限,以及它的kubeconfig文件
  • kubectl命令(某些告警场景会用,Certified Kubernetes不需要)
  • sonobuoy的docker镜像
  • 本地的私有化镜像仓库(强烈建议要有!!!)

安装

在下述链接中下载最新版本的Sonobuoy二进制文件,将它解压后,并把可执行文件sonobuoy路径添加到系统的PATH环境变量下即可。

https://github.com/vmware-tan...

运行测试

标准的一致性测试集目前是由 kubernetes e2e套件中的 [Conformance] 标签定义的。所以我们需要使用如下命令进行部署。

$ sonobuoy run --mode=certified-conformance
INFO[0000] created object                                name=sonobuoy namespace= resource=namespaces
INFO[0000] created object                                name=sonobuoy-serviceaccount namespace=sonobuoy resource=serviceaccounts
INFO[0001] created object                                name=sonobuoy-serviceaccount-sonobuoy namespace= resource=clusterrolebindings
INFO[0001] created object                                name=sonobuoy-serviceaccount-sonobuoy namespace= resource=clusterroles
INFO[0001] created object                                name=sonobuoy-config-cm namespace=sonobuoy resource=configmaps
INFO[0001] created object                                name=sonobuoy-plugins-cm namespace=sonobuoy resource=configmaps
INFO[0001] created object                                name=sonobuoy namespace=sonobuoy resource=pods
INFO[0001] created object                                name=plugin-e2e-cm namespace=sonobuoy resource=configmaps
INFO[0001] created object                                name=sonobuoy-aggregator namespace=sonobuoy resource=services

当sonobuoy容器正常运后,它就会开始创建e2e容器和systemd-log容器开始进行相关的测试和日志收集。

$ kubectl get pod -n sonobuoy                                                                                                                                                                             
NAME                                                      READY   STATUS    RESTARTS   AGE   IP               NODE              NOMINATED NODE   READINESS GATES
sonobuoy                                                  1/1     Running   0          31s   192.169.15.126   k8s-master3-123              
sonobuoy-e2e-job-23d08735503942f5                         2/2     Running   0          27s   192.169.15.86    k8s-master3-123              
sonobuoy-systemd-logs-daemon-set-c7fe30c923a848d5-c7wvz   2/2     Running   0          27s   172.16.23.123    k8s-master3-123              
sonobuoy-systemd-logs-daemon-set-c7fe30c923a848d5-d28gr   2/2     Running   0          27s   172.16.23.122    k8s-master2-122              
sonobuoy-systemd-logs-daemon-set-c7fe30c923a848d5-q25t8   2/2     Running   0          27s   172.16.23.124    k8s-node1-124                
sonobuoy-systemd-logs-daemon-set-c7fe30c923a848d5-wkd4f   2/2     Running   0          27s   172.16.23.125    k8s-node2-125                
sonobuoy-systemd-logs-daemon-set-c7fe30c923a848d5-z829h   2/2     Running   0          27s   172.16.23.121    k8s-master1-121              

在测试的进行过程中,我们可以使用sonobuoy status命令进行查看当前任务的执行状态,可以用sonobuoy logs来查看用例的执行日志。

产品如何做Kubernetes一致性认证_第2张图片

提示: certified-conformance测试通常会跑1 - 2个小时

当我们用sonobuoy status发现状态都为completed时,就代表一致性测试运行完成。

定制镜像(可选)

如果你的Kubernetes网络足够科学可以跳过此步骤。

众所周知,Docker Hub在今年开启了对Pull镜像的请求限制,而我们运行sonobuoy是,有大量用例都会从Docker Hub或者gcr.io上去拉取镜像,如果网络不稳定的话,整个测试时间会被拉的非常长,且极容易出现用例执行超时失败的现象。所以我们需要将线上镜像离线到本地镜像仓库,以加速镜像的下载。

好在sonobuoy提供了修改插件镜像地址的方式来让我们配置。

私有测试用例镜像仓库

  • 下载测试用例所需的镜像列表
$ sonobuoy  images  pull
INFO[0000] e2e image to be used: k8s.gcr.io/conformance:v1.18.16
INFO[0005] Pulling image: gcr.io/authenticated-image-pulling/alpine:3.7 ...
ERRO[0010] failed with following error after 1 retries:
ERRO[0010] Error response from daemon: unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication
INFO[0014] Pulling image: invalid.com/invalid/alpine:3.1 ...
ERRO[0016] failed with following error after 1 retries:
ERRO[0016] Error response from daemon: Get https://invalid.com/v2/: remote error: tls: handshake failure
INFO[0017] Pulling image: gcr.io/authenticated-image-pulling/windows-nanoserver:v1 ...
ERRO[0020] failed with following error after 1 retries:
ERRO[0020] Error response from daemon: unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication
INFO[0023] Pulling image: gcr.io/k8s-authenticated-test/agnhost:2.6 ...
ERRO[0027] failed with following error after 1 retries:
ERRO[0027] Error response from daemon: unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication
ERRO[0027] couldn't pull image: gcr.io/authenticated-image-pulling/alpine:3.7: exec: already started
ERRO[0027] couldn't pull image: invalid.com/invalid/alpine:3.1: exec: already started
ERRO[0027] couldn't pull image: gcr.io/authenticated-image-pulling/windows-nanoserver:v1: exec: already started
ERRO[0027] couldn't pull image: gcr.io/k8s-authenticated-test/agnhost:2.6: exec: already started
在运行上述命令时,可能会看到一些类似 镜像不存在或者 无权限pull镜像的错误。这是正常的,因为有些镜像被一些端到端测试所引用,但不被一致性测试所引用。
  • 创建镜像仓库列表
$ sonobuoy gen default-image-config > custom-repo-config.yaml
$ cat ./custom-repo-config.yaml

dockerLibraryRegistry: docker.io/library
e2eRegistry: gcr.io/kubernetes-e2e-test-images
gcRegistry: k8s.gcr.io
googleContainerRegistry: gcr.io/google-containers
sampleRegistry: gcr.io/google-samples
  • 修改custom-repo-config.yaml为你的本地仓库
$ cat ./custom-repo-config.yaml

dockerLibraryRegistry: xxx.yyy.zzz/library
e2eRegistry: xxx.yyy.zzz/library
gcRegistry: xxx.yyy.zzz/library
googleContainerRegistry: xxx.yyy.zzz/library
sampleRegistry: xxx.yyy.zzz/library
  • 推送镜像到本地仓库
sonobuoy images push --e2e-repo-config 

私有Sonobuoy镜像

Sonobuoy提供几个参数让我们来制定私有镜像启动

--systemd-logs-image     #指定日志采集镜像
--sonobuoy-image          # 指定Sonobuoy镜像
--e2e-repo-config           # 指定Sonobuoy用例镜像配置

那么最后我们可以用如下命令就能在自己私有化环境里面进行测试了

$ sonobuoy run \
--mode=certified-conformance \
--sonobuoy-image=xxx.yyy.zzz/library/sonobuoy:v0.53.2 \
--kubernetes-version=v1.18.16 \
--systemd-logs-image=xxx.yyy.zzz/library/systemd-logs:v0.3 \
--e2e-repo-config conformance-image-config.yaml

提取结果

运行命令sonobuoy retrieve就会把当前跑完的测试结果以tar包的方式保存在当前目录,对它进行解压就得到了类似如下目录结构的文件

$ tree -L 2
.
├── 202108180508_sonobuoy_ff7aa0c1-34cb-4375-a09e-153235a96d34.tar.gz
├── hosts
│   ├── k8s-master1-121
│   ├── k8s-master2-122
│   ├── k8s-master3-123
│   ├── k8s-node1-124
│   └── k8s-node2-125
├── meta
│   ├── config.json
│   ├── info.json
│   ├── query-time.json
│   └── run.log
├── plugins
│   ├── e2e
│   └── systemd-logs
├── podlogs
│   └── sonobuoy
├── resources
│   ├── cluster
│   └── ns
├── servergroups.json
└── serverversion.json

需要提交给CNCF社区的两个文件就位于plugins/e2e/results/global/{e2e.log,junit_01.xml}

上传结果

在Github上Fork社区的[cncf/k8s-conformance]到自己的仓库,并在指定的Kubernetes目录下创建一个目录。目录要求是一个简短的产品名称。同时将e2e.logjunit_01.xml两个文件伙同产品描述文件(PRODUCT.yaml)一起保存在目录下。

PRODUCT.yaml的内容描述

字段 Description
vendor 认证的法律实体的名称。该实体必须有一份在CNCF备案的参与表格。
name 被Certified Kubernetes认证的产品名称
version 被Certified Kubernetes认证的产品版本(非Kubernetes版本)
website_url 产品介绍地址
repo_url 如果产品是开源的,就必须指向包含源代码的主要GitHub repo地址。也是可以接受Docker镜像地址。可选的
documentation_url 产品文档地址
product_logo_url 产品Logo地址(必须是 SVG、AI 或者 EPS 格式,且需包含产品名称),如果没有则使用公司的Logo
type 产品类型,包含三种 发行版( product a distribution), 托管平台(hosted platform) 或者安装器(installer)
description 一句话的产品描述文字

如下就是一个样例

vendor: Yoyodyne
name: Turbo Encabulator
version: v1.7.4
website_url: https://yoyo.dyne/turbo-encabulator
repo_url: https://github.com/yoyo.dyne/turbo-encabulator
documentation_url: https://yoyo.dyne/turbo-encabulator/docs
product_logo_url: https://yoyo.dyne/assets/turbo-encabulator.svg
type: distribution
description: 'The Yoyodyne Turbo Encabulator is a superb Kubernetes distribution for all of your Encabulating needs.'

接下来我们就可以提交一个PR来让CNCF社区人员来进行复核了,通常情况下会在提交后的3个工作日内回复。

清理环境

运行sonobuoy delete 命令即可完成整个测试过程中产生的K8S资源。

不过如果sonobuoy的测试用例执行失败后不会自动清除,需要用户执行清理残留资源

总结

本文主要讲述了小白对CNCF社区对Kubernetes一致性认证的理解,以及如何利用Sonobuoy工具来对自己的Kubernetes集群做集成测试。Sonobuoy是一个非常好的集成测试工具,它除了能做Kubernetes一致性测试外,还能做性能测试存储测试以及厂商自定义的测试。同时,本文还对提交Certified Kubernetes做了一个简单的流程说明。如果有读者的公司正在做相关的工作的话,希望能够帮到你。


「云原生小白」

你可能感兴趣的:(kubernetescncf)