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

77次阅读

共计 8027 个字符，预计需要花费 21 分钟才能阅读完成。

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-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   <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  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 <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: 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 做了一个简略的流程阐明。如果有读者的公司正在做相干的工作的话，心愿可能帮到你。

「云原生小白」

正文完
kubernetes
发表至： kubernetes
2021-08-19
 0
关于kubernetes:kubestatemetrics在kubernetes集群下的分片机制
关于kubernetes:Helm-安装-Prometheus-详解-以及-问题解决
关于kubernetes:tke-1206升级到1225的一点小插曲
关于kubernetes:分享画的-Kubernetes-的源码架构图