本文超过一年。较旧的文章可能包含过 outdated 的内容。请检查页面中的信息自发布以来是否已变得不正确。
将端到端 Kubernetes 测试引入 Azure（第一部分）
在 AppFormix，持续集成测试是我们文化的一部分。我们看到定期运行端到端测试的许多好处，包括最大限度地减少回归并确保我们的软件作为一个整体协同工作。为了确保为客户提供高质量的体验，我们不仅需要能够为我们的应用程序运行端到端测试，还需要能够为整个编排堆栈运行端到端测试。我们的客户正在采用 Kubernetes 作为他们首选的容器编排技术，并且他们要求在容器执行位置方面有选择权，从私有基础设施到公共提供商，包括 Azure。经过几周的工作，我们很高兴地宣布，我们正在贡献一个夜间持续集成作业，该作业在 Azure 平台上执行端到端测试。在每晚运行端到端测试仅仅几周后，我们已经在 Kubernetes 中发现并修复了两个问题。我们希望我们对端到端作业的贡献将有助于社区在 Kubernetes 发展过程中维护对 Azure 平台的支持。
在这篇博文中，我们将描述我们为 Azure 平台实现部署脚本的过程。部署脚本是我们正在贡献的端到端测试作业的先决条件，因为脚本使我们的端到端测试作业能够测试 Kubernetes master 分支的最新提交。在后续的博文中，我们将描述有助于维护 Azure 平台支持的端到端测试的详细信息，以及如何将联合端到端测试结果贡献给 Kubernetes 项目。
背景
虽然 Kubernetes 旨在在任何 IaaS 上运行，并且存在许多平台的解决方案指南，包括 Google Compute Engine、AWS、Azure 和 Rackspace，但 Kubernetes 项目将这些称为“版本化发行版”，因为它们仅针对 Kubernetes 的特定二进制版本进行测试。另一方面，“开发发行版”每天都被最新的 Kubernetes 源代码的自动化端到端测试使用，并作为代码提交的入口检查。
当我们第一次调查 Azure 上对 Kubernetes 的现有支持时，我们发现了使用 CoreOS 和 Weave 在 Azure 上运行 Kubernetes 的文档。该文档包括部署脚本，但这些脚本不符合“开发发行版”所需的用于自动集群创建的 cluster/kube-up.sh 框架。此外，不存在利用这些脚本使用端到端测试场景（Kubernetes 存储库中 test/e2e 中的那些场景）验证 Kubernetes 的持续集成作业。
通过对项目历史进行一些额外的调查（旁注：git log --all --grep='azure' --oneline 非常有用），我们发现以前存在一组与 cluster/kube-up.sh 框架集成的脚本。这些脚本在 2015 年 10 月 16 日被丢弃（提交 8e8437d），因为这些脚本自 Kubernetes 1.0 版本之前就一直无法工作。以这些提交作为起点，我们着手更新脚本，并创建一个受支持的持续集成作业，这将有助于持续维护。
集群部署脚本
为了在 Azure 上使用 Ubuntu 虚拟机设置 Kubernetes 集群，我们遵循了先前放弃的提交奠定的基础，并尝试尽可能多地利用现有代码。该解决方案使用 SaltStack 进行部署，使用 OpenVPN 进行主节点和从节点之间的联网。SaltStack 还被其他几种解决方案用于配置管理，例如 AWS、GCE、Vagrant 和 Vsphere。恢复被丢弃的提交是一个起点，但我们很快意识到需要关注几个关键要素
- 使用 SaltStack 在节点上安装 Docker 和 Kubernetes
- 配置服务的身份验证
- 配置网络
集群设置脚本确保安装了 Docker，将 Kubernetes Docker 镜像复制到主节点和从节点，并加载镜像。在主节点上，SaltStack 启动 kubelet，kubelet 又启动在容器中运行的以下 Kubernetes 服务：kube-api-server、kube-scheduler 和 kube-controller-manager。在每个从节点上，SaltStack 启动 kubelet，kubelet 启动 kube-proxy。
Kubernetes 服务在相互通信时必须进行身份验证。例如，从节点向主节点上的 kube-api 服务注册。在主节点上，脚本生成 kube-api 用于 TLS 的自签名证书和密钥。从节点配置为跳过 kube-api 的（自签名）TLS 证书的验证。我们将服务配置为使用用户名和密码凭据。用户名和密码由集群设置脚本生成，并存储在每个节点上的 kubeconfig 文件中。
最后，我们实现了网络配置。为了使脚本参数化并最大限度地减少对目标环境的假设，脚本创建了一个新的 Linux 网桥设备 (cbr0)，并确保所有容器都使用该接口访问网络。为了配置网络，我们使用 OpenVPN 在主节点和从节点之间建立隧道。对于每个从节点，我们保留一个 /24 子网用于其 pod。Azure 为每个节点分配了自己的 IP 地址。我们还添加了此网桥使用 OpenVPN 接口所需的路由表条目。这是确保不同主机中的 pod 可以相互通信所必需的。主节点和从节点上的路由如下
主节点
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.244.1.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.244.2.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 cbr0
从节点 1
10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.244.1.0 0.0.0.0 255.255.255.0 U 0 0 0 cbr0
10.244.2.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
从节点 2
10.8.0.0 10.8.0.9 255.255.255.0 UG 0 0 0 tun0
10.8.0.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.244.1.0 10.8.0.9 255.255.255.0 UG 0 0 0 tun0
10.244.2.0 0.0.0.0 255.255.255.0 U 0 0 0 cbr0
| | 图 1 - OpenVPN 网络配置 |
未来工作 随着部署脚本的实现，一部分端到端测试用例在 Azure 平台上通过。 nightly 测试结果发布到 Kubernetes 测试历史记录面板。Weixu Zhuang 在 Kubernetes GitHub 上提交了一个 拉取请求，我们正在积极与 Kubernetes 社区合作，以合并 nightly 端到端测试作业所需的 Azure 集群部署脚本。部署脚本为 Azure 上的 Kubernetes 提供了最小的工作环境。还有几个后续步骤可以继续这项工作，我们希望社区能够参与进来并实现它们。
- 只有一部分端到端场景通过，因为某些云提供商接口尚未针对 Azure 实现，例如负载均衡器和实例信息。为此，我们寻求社区的意见和帮助，以定义 cloudprovider 接口 (pkg/cloudprovider/) 的 Azure 实现。这些接口将启用 Kubernetes Pod 暴露到外部网络和集群 DNS 等功能。
- Azure 具有用于与服务交互的新 API。提交的脚本当前使用 Azure 服务管理 API，这些 API 已被弃用。部署脚本中应使用 Azure 资源管理器 API。AppFormix 团队很高兴为 Kubernetes 社区提供 Azure 支持。我们期待收到有关如何共同改进 Azure 上 Kubernetes 的反馈。
编者注：想要*为 Kubernetes 做贡献*，请参与 这里。如果您有自己的 Kubernetes 故事想分享，请 告诉我们！
第二部分 在此处。