2021: Kubernetes必备工具
原文地址
摘要
在这篇文章中，我将总结我最喜欢的Kubernetes工具，并特别指出那些我认为可能会流行的最新但不太知名的工具。
这是根据个人经验来总结的工具，为了避免个人偏见，我也会对每种工具的可替代选择进行介绍，可以根据自己需要来判断选择。我将尽可能使本文简短些，文中会提供每个工具的链接可以自行探索。我的目标是通过介绍不同的软件开发任务来回答"如何在kubernetes进行X工作？"
K3D
K3D是我在笔记本电脑上运行Kubernetes(K8s)集群最喜欢的方式，非常轻量快速。它是使用docker基于K3S封装来的。因此你只需要使用dokcer来运行即可，占用资源非常少。唯一的问题是它不完全兼容K8s的，但这对本地开发不是一个问题。对于测试环境，您可以使用其他解决方案。K3D比Kind快，但Kind完全兼容。
替代方案
Krew
Krew是管理Kubectl插件的必备工具，这是K8s用户必须拥有的。我不会介绍超过145个可用插件的细节，至少要安装kubens和kubectx。
Lens
Lens是面向SREs、Ops和开发者的K8s的IDE。它适用于任何Kubernetes发行版:on-prem或在云端。它快速，易于使用，并提供实时观测。使用Lens可以很容易地管理多个集群。如果您是集群管理者，这是必须具备的。
可替代方案
- 对于那些喜欢轻便终端的人来说，K9s是一个很好的选择。K9s不断地监视Kubernetes的变化，并提供后续命令来与您观察到的资源交互。
Helm
Helm应该不需要介绍，它是Kubernetes最著名的包管理器。是的，您应该在K8s中使用包管理器，就像您在编程语言中使用包一样。Helm允许您在Charts中打包您的应用，将复杂的应用程序抽象为易于定义、安装和更新的可重用的简单组件。
它还提供了一个强大的模板引擎。Helm是成熟的，有很多预先定义的charts，强大的支持，它很容易使用。
可替代方案
- Kustomize是一个比较新的可替代Helm工具，它不使用模板引擎，而用overlay引擎，可以实现基本定义和在此基础上叠加。
ArgoCD
我相信GitOps是过去十年中最好的创意。在软件开发中，我们应该使用单一的真实来源来跟踪构建软件所需的所有移动部分，而Git是一个完美的工具。其想法是拥有一个Git存储库，其中包含应用程序代码和基础设施(IaC)的声明性描述（用于构建生产环境状态）；以及一个使所需环境与存储库中描述的状态相匹配的自动化过程。
GitOps:在声明性基础设施之上的版本化CI/CD。停止编写脚本并开始交付。
虽然使用Terraform或类似工具，您可以将基础设施作为代码(IaC)，但这还不足以将您想要的Git状态与生产同步。我们需要一种方法来连续监控环境，并确保没有配置漂移。使用Terraform，你必须编写运行Terraform应用的脚本，并检查状态是否与Terraform状态匹配，但这是乏味的，很难维护。
Kubernetes从一开始就以控制循环的思想实现，这意味着Kubernetes一直在观察集群的状态，以确保它与期望的状态相匹配，例如，运行的副本数量与期望的副本数量相匹配。GitOps的理念是将此扩展到应用程序，因此您可以将服务定义为代码，例如，通过定义Helm Charts，并使用一个工具来利用K8s功能来监控应用程序的状态并相应地调整集群。也就是说，如果更新您的代码仓库，或更新Heml chart，生产集群也将更新。这就是真正的持续部署。核心原则是应用程序部署和生命周期管理都是自动化的、可审计的和易于理解的。
对我来说，这个想法是革命性的，如果使用得当，将使组织更多地关注业务特性，而较少地关注为自动化编写脚本。这个概念可以扩展到软件开发的其他领域，例如，您可以在代码中存储文档，以跟踪变更的历史，并确保文档是最新的；或使用ADRs跟踪架构决策。
在我看来，Kubernetes中最好的GitOps工具是ArgoCD。点击这里阅读更多文档。ArgoCD是Argo生态系统的一部分，其中包括其他一些很好的工具，稍后会讨论其中一部分。
使用ArgoCD，您可以在代码库中定义每个环境的所有配置。Argo CD可以在指定的目标环境中自动部署所需的应用程序状态。
Argo CD架构
Argo CD是作为一个kubernetes控制器来实现的，它持续监控运行中的应用程序，并将当前的活动状态与所需的目标状态(如Git repo中所指定的)进行比较。Argo CD报告和可视化差异，并可以自动或手动同步活动状态到所需的目标状态。
可替代方案
- Flux刚刚发布了一个有很多改进的新版本。它提供了非常类似的功能。
Argo workflows和Argo Events
在Kubernetes中，您可能需要运行批处理作业或复杂的工作流。这可能是数据pipeline、异步进程甚至CI/CD的一部分。最重要的是，您可能需要运行甚至驱动微服务来响应这些事件，比如上传文件或向队列发送消息。对于所有这些，我们有Argo workflow和Argo Events。尽管它们是独立的项目，但它们往往被部署在一起。
Argo workflow是一个与Apache Airflow类似的编排引擎，但它是Kubernetes的原生引擎。它使用自定义CRDs来定义复杂的工作流，使用步骤或使用YAML格式的DAGs定义工作流，这些在K8s中更自然。它有一个很好的UI、重试机制、基于cron的作业、输入和输出跟踪等等。您可以使用它来编排数据pipeline、批处理作业等等。
有时候，你可能想要将你的pipeline与异步服务集成，比如Kafka、队列、webhook或深度存储服务等流式引擎。例如，您可能希望对上传到S3的文件等事件作出反应。为此，您将使用Argo Events。
Argo Events
这两个工具组合为您的所有pipeline需求提供了一个简单而强大的解决方案，包括CI/CD pipeline，它将允许您在Kubernetes中原生地运行您的CI/CD。
可替代方案
Kanico
我们刚刚看到了如何使用Argo工作流运行Kubernetes原生CI/CD。一个常见的任务是构建Docker镜像，这在Kubernetes中通常是乏味的，因为构建过程实际上是在容器本身上运行的，你需要使用其他方法来使用主机的Docker引擎。
底线是，你不应该使用Docker来构建你的镜像：使用Kanico代替。Kaniko不依赖Docker守护进程，并且完全在用户空间中执行Dockerfile中的每个命令。这使得可以在不能轻松或安全地运行Docker守护进程的环境中构建容器镜像，比如标准的Kubernetes集群。这消除了与在K8s集群中构建镜像有关的所有问题。
Istio
Istio是目前市面上最著名的服务网络，开源的，非常受欢迎。我不会详细关于什么是服务网格，因为它是一个巨大的话题，但是如果你正在构建微服务，也许你应该，需要一个服务网格来管理交互、可观察性、错误处理、安全和其他微服务架构内容。与其用重复的逻辑污染每个微服务的代码，不如利用服务网格来为你做这件事。
Istion架构
简而言之，服务网格是可以添加到应用程序中的专用基础设施层。它允许您透明地添加诸如可观察性、流量管理和安全性等功能，而无需将它们添加到您自己的代码中。
如果使用Istio运行微服务，尽管您可以在任何地方运行Istio并使用微服务，但Kubernetes已多次被证明是运行istio的最佳平台。Istio还可以将您的K8s集群扩展到其他服务，如虚拟机，从而允许您拥有Hybrid环境，这在迁移到Kubernetes时非常有用。
可替代方案
- Linkerd是一个更轻，可能更快的服务网络。Linkerd从一开始就是为安全而构建的，包括默认mTLS、用Rust构建的数据平面，rust是内存安全语言以及定期的安全审计等功能。
- Consul是为任何运行时和云提供商构建的服务网格，因此它非常适合跨K8s和云提供商的混合部署。如果不是所有的工作负载都运行在Kubernetes上，那么它是一个很好的选择。
Argo Rollouts
我们已经提到，您可以使用Kubernetes运行您的CI/CD pipeline，使用Argo工作流或类似工具，并使用Kanico来构建镜像。下一个步骤是持续部署。这是极具挑战性的一个真实的场景由于风险较高，这也就是为什么大多数公司只做持续交付，这意味着他们有自动化，但他们仍需手工审批和验证，手动步骤是造成团队不能完全信任自动化原因。
那么，您如何建立这种信任，从而能够摆脱所有脚本，并从源代码到生产环境完全自动化？答案是：可观测性。您需要将资源更多地集中在指标上，并收集能准确表示应用程序状态所需的所有数据。我们的目标是使用一组指标来建立这种信任。如果在Prometheus中有所有的数据，那么就可以自动化部署，因为您可以基于这些指标来实现应用自动化发布过程。
简而言之，您需要比K8s提供的滚动更新更高级的部署技术。我们需要使用金丝雀部署逐步交付。其目标是逐步将流量路由到应用程序的新版本，等待指标被收集，分析它们，并根据预定义规则匹配它们。如果一切顺利，我们增加流量；如果有任何问题，我们将回滚部署。
要在Kubernetes中做到这一点，您可以使用Argo rollout，它提供Canary发行版和更多内容。
Argo rollout是Kubernetes控制器和一组CRDs，提供先进的部署能力，如蓝绿、金丝雀、金丝雀分析、实验和逐步交付Kubernetes的特性。
虽然像Istio这样的Service Meshes提供Canary release，但是Argo rollout使得这个过程更加容易，并且以开发人员为中心，因为它是专门为此目的构建的。最重要的是，Argo rollout可以与任何服务网集成。
Argo Rollouts包含特性：
- 蓝绿更新策略
- 金丝雀更新策略
- 细粒度的、加权的流量转移
- 自动回滚、升级或手动判断
- 可定制的指标查询和业务kpi分析
- Ingress控制器集成：NGINX和ALB
- 服务网格集成:Istio, Linkerd, SMI
- 指标提供商集成:Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs
Crossplane
Crossplane是我最喜欢的K8s工具，我对这个项目感到非常兴奋，因为它给Kubernetes带来了一个重要的缺失部分：像管理K8s资源一样管理第三方服务。这意味着，您可以使用YAML像定义K8s资源一样来提供AWS RDS或GCP cloud SQL这样的云提供商数据库。
有了Crossplane，就不需要使用不同的工具和方法来分离基础设施和代码。您可以使用K8s资源定义所有内容。这样，你就不需要学习像Terraform这样的新工具，并将它们分开使用。
Crossplane是一个开源的Kubernetes插件，它允许平台团队组装来自多个供应商的基础设施，并公开更高级别的自服务api供应用团队使用，而无需编写任何代码。
-----------------------未完待续---------------------------
