关于kubernetes:产品如何做Kubernetes一致性认证

Certified Kubernetes是CNCF基金会在2018年推出的Kubernetes一致性认证打算。它由CNCF基金会提供的一套诊断测试工具（Sonobuoy）并运行在Kubernetes中。各云厂商如果须要将本人产品纳入到Certified Kubernetes当中，就须要依照操作领导进行本身测试，并将测试后果上传给CNCF社区，当报告审核通过，交付肯定的费用（CNCF Members收费）后，就会失去CNCF基金会给企业颁发一个Certified Kubernetes的认证。也就是说失去认证后企业就能在本人的产品宣传上应用CNCF基金会的Certified Kubernetes商标和在产品中应用带Kubernetes字样的名称。Certified Kubernetes Logo大略长这个样子。

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-conformanceINFO[0000] created object                                name=sonobuoy namespace= resource=namespacesINFO[0000] created object                                name=sonobuoy-serviceaccount namespace=sonobuoy resource=serviceaccountsINFO[0001] created object                                name=sonobuoy-serviceaccount-sonobuoy namespace= resource=clusterrolebindingsINFO[0001] created object                                name=sonobuoy-serviceaccount-sonobuoy namespace= resource=clusterrolesINFO[0001] created object                                name=sonobuoy-config-cm namespace=sonobuoy resource=configmapsINFO[0001] created object                                name=sonobuoy-plugins-cm namespace=sonobuoy resource=configmapsINFO[0001] created object                                name=sonobuoy namespace=sonobuoy resource=podsINFO[0001] created object                                name=plugin-e2e-cm namespace=sonobuoy resource=configmapsINFO[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 GATESsonobuoy                                                  1/1     Running   0          31s   192.169.15.126   k8s-master3-123   <none>           <none>sonobuoy-e2e-job-23d08735503942f5                         2/2     Running   0          27s   192.169.15.86    k8s-master3-123   <none>           <none>sonobuoy-systemd-logs-daemon-set-c7fe30c923a848d5-c7wvz   2/2     Running   0          27s   172.16.23.123    k8s-master3-123   <none>           <none>sonobuoy-systemd-logs-daemon-set-c7fe30c923a848d5-d28gr   2/2     Running   0          27s   172.16.23.122    k8s-master2-122   <none>           <none>sonobuoy-systemd-logs-daemon-set-c7fe30c923a848d5-q25t8   2/2     Running   0          27s   172.16.23.124    k8s-node1-124     <none>           <none>sonobuoy-systemd-logs-daemon-set-c7fe30c923a848d5-wkd4f   2/2     Running   0          27s   172.16.23.125    k8s-node2-125     <none>           <none>sonobuoy-systemd-logs-daemon-set-c7fe30c923a848d5-z829h   2/2     Running   0          27s   172.16.23.121    k8s-master1-121   <none>           <none>

在测试的进行过程中，咱们能够应用sonobuoy status命令进行查看当前任务的执行状态，能够用sonobuoy logs来查看用例的执行日志。

提醒：certified-conformance测试通常会跑1 - 2个小时

当咱们用sonobuoy status发现状态都为completed时，就代表一致性测试运行实现。

定制镜像（可选）

如果你的Kubernetes网络足够迷信能够跳过此步骤。

家喻户晓，Docker Hub在往年开启了对Pull镜像的申请限度，而咱们运行sonobuoy是，有大量用例都会从Docker Hub或者gcr.io下来拉取镜像，如果网络不稳固的话，整个测试工夫会被拉的十分长，且极容易呈现用例执行超时失败的景象。所以咱们须要将线上镜像离线到本地镜像仓库，以减速镜像的下载。

好在sonobuoy提供了批改插件镜像地址的形式来让咱们配置。

公有测试用例镜像仓库

下载测试用例所需的镜像列表

$ sonobuoy  images  pullINFO[0000] e2e image to be used: k8s.gcr.io/conformance:v1.18.16INFO[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-authenticationINFO[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 failureINFO[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-authenticationINFO[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-authenticationERRO[0027] couldn't pull image: gcr.io/authenticated-image-pulling/alpine:3.7: exec: already startedERRO[0027] couldn't pull image: invalid.com/invalid/alpine:3.1: exec: already startedERRO[0027] couldn't pull image: gcr.io/authenticated-image-pulling/windows-nanoserver:v1: exec: already startedERRO[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.yamldockerLibraryRegistry: docker.io/librarye2eRegistry: gcr.io/kubernetes-e2e-test-imagesgcRegistry: k8s.gcr.iogoogleContainerRegistry: gcr.io/google-containerssampleRegistry: gcr.io/google-samples

批改custom-repo-config.yaml为你的本地仓库

$ cat ./custom-repo-config.yamldockerLibraryRegistry: xxx.yyy.zzz/librarye2eRegistry: xxx.yyy.zzz/librarygcRegistry: xxx.yyy.zzz/librarygoogleContainerRegistry: xxx.yyy.zzz/librarysampleRegistry: xxx.yyy.zzz/library

推送镜像到本地仓库

sonobuoy images push --e2e-repo-config <path/to/custom-repo-config.yaml>

公有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.log和junit_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: Yoyodynename: Turbo Encabulatorversion: v1.7.4website_url: https://yoyo.dyne/turbo-encabulatorrepo_url: https://github.com/yoyo.dyne/turbo-encabulatordocumentation_url: https://yoyo.dyne/turbo-encabulator/docsproduct_logo_url: https://yoyo.dyne/assets/turbo-encabulator.svgtype: distributiondescription: '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做了一个简略的流程阐明。如果有读者的公司正在做相干的工作的话，心愿可能帮到你。

「云原生小白」