将端到端 Kubernetes 测试带到 Azure（第 1 部分）

在AppFormix，持续集成测试是我们文化的一部分。我们认为定期运行端到端测试有很多好处，包括最大限度地减少回归并确保我们的软件作为一个整体协同工作。为了确保为客户提供高质量的体验，我们不仅需要对我们的应用程序，还需要对整个编排堆栈进行端到端测试的能力。我们的客户正在选择Kubernetes作为他们的容器编排技术，他们要求在容器执行地点上拥有选择权，从私有基础设施到公共提供商，包括Azure。经过几周的工作，我们很高兴地宣布，我们正在贡献一个每晚运行的持续集成作业，该作业在Azure平台上执行e2e测试。在仅仅几周的每晚e2e测试运行后，我们已经在Kubernetes中发现并修复了两个问题。我们希望我们贡献的e2e作业将帮助社区在Kubernetes发展过程中继续支持Azure平台。

在这篇博客文章中，我们描述了我们为Azure平台实现部署脚本所经历的旅程。部署脚本是我们正在贡献的e2e测试作业的先决条件，因为这些脚本使得我们的e2e测试作业能够测试Kubernetes主分支的最新提交。在随后的博客文章中，我们将详细描述有助于维护Azure平台支持的e2e测试，以及如何将联合e2e测试结果贡献给Kubernetes项目。

背景

虽然Kubernetes被设计为在任何IaaS上运行，并且存在针对许多平台（包括Google Compute Engine、AWS、Azure和Rackspace）的解决方案指南，但Kubernetes项目将这些称为“版本化发行版”，因为它们只针对特定的Kubernetes二进制版本进行测试。另一方面，“开发发行版”每天被用于针对最新Kubernetes源代码的自动化e2e测试，并作为代码提交的门控检查。

当我们首次调查Kubernetes在Azure上的现有支持时，我们发现了使用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日（commit 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网络配置 |

未来工作 随着部署脚本的实现，一部分e2e测试用例已在Azure平台上通过。每晚的结果都会发布到Kubernetes测试历史仪表板。Weixu Zhuang在Kubernetes GitHub上提交了一个拉取请求，我们正在积极与Kubernetes社区合作，以合并每晚e2e测试作业所需的Azure集群部署脚本。部署脚本为Azure上的Kubernetes提供了一个最小的工作环境。接下来还有几个步骤需要继续这项工作，我们希望社区能参与进来以实现这些目标。

• 只有一部分e2e场景通过，因为Azure尚未实现一些云提供商接口，例如负载均衡器和实例信息。为此，我们寻求社区的意见和帮助，以定义云提供商接口 (pkg/cloudprovider/) 的 Azure 实现。这些接口将启用 Kubernetes Pod 暴露到外部网络和集群 DNS 等功能。
• Azure有与服务交互的新API。提交的脚本目前使用已弃用的Azure服务管理API。部署脚本应该使用Azure资源管理器API。AppFormix团队很高兴能为Kubernetes社区贡献对Azure的支持。我们期待收到关于我们如何共同改进Azure上Kubernetes的反馈。

编者按：想要为 Kubernetes 贡献力量，请点击这里参与。如果您有自己的 Kubernetes 故事想分享，请告诉我们！

第二部分可在此处获取。

• ←上一篇
• 下一篇→