硬核干货| 利用K3s低成本在流水线中添加测试

作者介绍
Petro Kashlikov，AWS技术客户经理。十分热衷于容器技术，并与客户一起设计、部署和管理他们的工作负载/架构。

现代化的微服务应用程序堆栈、CI/CD流水线、Kubernetes作为编排引擎以及每天成千上百的部署……这些听起来十分美好，直到你发现你的Kubernetes开发或staging环境被这些部署弄得混乱不堪并且一个开发团队所做的更改会影响你的Kubernetes环境。在本文中，我们将了解为什么这些外部更改会影响我们的Kubernetes环境以及如何避免这一影响。

之所以会出现这一问题，是因为在将镜像推送到镜像仓库并部署我们的资源之前，我们在流水线中进行了各种代码检查和镜像扫描。但是，因为流水线内部没有可用的Kubernetes集群，因此在流水线本身中没有进行适当的集成或单元测试。实际上，我们是在部署后测试我们的更改。

面对这个问题，有一个解决方案就是在每次构建、测试更改时配置一个干净的Kubernetes集群，然后再将其清除。但是这十分耗时也不划算。相反，我们可以使用由Rancher Labs推出的开源、轻量级的Kubernetes发行版K3s，与Amazon和AWS CodePipeline一起解决这个问题。

什么是K3s？

K3s是一个开源、轻量的Kubernetes发行版，大小小于100MB，专为物联网、边缘和CI/CD环境设计。启动时间仅需40秒左右。

更有趣的是，对于CI/CD用例，我们可以在Docker容器内运行K3s。Rancher还提供了另一个名为k3d的工具，它是一个轻量级的wrapper，可以在Docker容器内运行K3s。在这种情况下，这个package的大小约为10MB，启动时间更快，约为15-20秒。

现在我们开始了解如何实现这一解决方案。

前期准备

要完成这一教程，我们需要：

• 一个AWS账号
• 一个Github账号
• 安装并配置AWS CLI、kubectl、eksctl功能。你可以根据以下链接指引安装eksctl：

https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html

配置Amazon EKS集群

有很多方法可以进行配置，包括使用AWS管理控制台、AWS CLI等。我们推荐使用eksctl，但不管你喜欢什么方式都可以使用，并根据你的喜好修改节点类型和区域。集群配置一般需要15分钟左右。

eksctl create cluster \
--name k3s-lab \
--version 1.16 \
--nodegroup-name k3s-lab-workers \
--node-type t2.medium \
--nodes 2 \
--alb-ingress-access \
--region us-west-2

在本练习中，我们使用 t2.medium 实例系列。如果你在生产环境中启动Amazon EKS集群，请记住使用适当的实例类型。

集群配置完成后，我们使用命令来验证它是否已经启动，以及是否正确配置了 kubectl：

kubectl get nodes

我们的输出应该如下所示：

NAME                             STATUS   ROLES     AGE       VERSION
ip-192-168-12-121.ec2.internal   Ready    <none>    82s       v1.16.8-eks-e16311
ip-192-168-38-246.ec2.internal   Ready    <none>    80s       v1.16.8-eks-e16311

设置AWS CodePipeline

1、 设置ACCOUNT_ID变量：

ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')

2、 在CodePipeline中，我们使用AWS CodeBuild来部署示例Kubernetes服务。这需要一个能与Amazon EKS