-- 原文出处：https://www.ansible.com/blog/how-useful-is-ansible-in-a-cloud-native-kubernetes-environment

-- 译者注：这其实也是我自己曾经的困惑，在K8S的环境中是否还需要Ansible来辅助运维，这篇文章正好解答了这个问题。译者水平有限的套话也要说一下，因为确实如此，不是谦虚。

前言

最近经常被问到这么一个问题：在K8S项目中你为啥还在用Ansible呢？下一个问题往往是：既然你已经开始用K8S,为啥还要写《Ansible for Kubernetes》这么一本书呢？

我花了点时间思考了下这些问题，以及问题背后的原因，就决定为此写篇博客。因为看起来有很多人可能对K8S是什么和Ansible能干什么有些困惑，有必要解释一下为什么Ansible在当前越来越多的业务往云原生的技术栈做迁移的时候仍然是很有用的一项技术。

我先从我的书中引用一段说明：
-- 虽然Ansible技术上几乎可以做任何事情，但它不一定是最适合某个具体的IT基础设施的自动化框架。可能有其他的工具能更好的契合你的应用的开发流程，或者能从vendor那里获得更多更好的支持。

首先我们需要避免黄金大锤谬论(Goldend Hammer Fallacy)。没有一种基础工具（甚至是最好的K8S-AAS platform）能完全满足一整套完整的IT自动化操作流程。实际上Ansible能融入云原生架构的管理流程的很多领域，这里我着重讲主要的3点，也就是Container Builds（容器构建）, Cluster Management（集群管理）, 和 Application Lifecycles（应用生命周期管理）。

在此我想给那些一头扎进K8S但没有采用更广泛的自动化策略的团队提个醒，K8S不会管理你的应用的整个生命周期，也不负责自启动，你不应该满足于通过手工的方式构建和管理K8S集群，那样是非常危险的，尤其是有多个集群需要管理的情况，实际上K8S的最佳实践就是要有多个集群（至少要有staging+production两个集群，或者内部私有集群+公共对外集群）。

容器构建（Container Build）

在过去十数年来，服务器管理和应用部署已经越来越自动化了。自动化技术变得越来越直观，可维护性越来越好，尤其是在引入一些优秀的配置管理和编排工具后，譬如CFEngine, Puppet, Chef, 和Ansible等工具。

但是，没有一种单一的工具能满足不同应用的部署自动化要求。不同类型的应用的部署技术差异很大，Java有war包和VM虚拟机，Python有自己的虚拟环境，PHP有自己的脚本和多个执行引擎，Ruby也有它自己的执行环境。希望高效的管理5个，10个或更多开发栈的服务和部署是极具挑战的，这还不算一个开发栈可能有多个版本的情况，譬如Java可能有Java7，Java8，Java11等多个版本呢。

幸运的是，容器技术能很好的解决这个问题。开发工程师可以直接交付一个在当前大多数系统服务器环境上都能运行的container, 代替交付源代码和在不同环境上部署的错综复杂的操作指令。

但在某些方面，容器构建领域的自动化有点停滞不前。容器构建的Dockerfile, 通过DSL语言和inline command组成的脚本还是很晦涩难懂但仍被大量使用。这里Ansible可以做得更好！Ansible也支持用Dockerfile构建容器，但与Ansible的容器构建工具ansible-bender整合的轻量的开源工具Buildah能够用更加可描述的和可维护性更好的Ansible Playbooks来构建容器，甚至可以不用安装Docker!

虽然还有其他一些工具能辅助构建容器，但实际上，还是有很多开发工程师和系统运维人员仍在使用原始的Dockfile构建关键性的基础架构组件的容器，而没有采用像Ansible这样的描述性更好，可维护性更好，更通用的工具，我对此深感痛惜！

集群管理（Cluster Management）

K8S集群不是凭空产生的，它们需要做升级和集成的管理工作，具体因不同的集群类型而异。集群管理是比较容易引发问题的，尤其是同时管理多个集群的情况。实际上大部分组织恰恰都是这种情况，可以有多个生产集群，可能有QA集群和staging集群，等等。

如果你在使用私有云或者裸的物理机服务器，你需要一个方式来安装K8S和管理集群里的各个机器。Ansible已经证明了能很好的编排管理多服务器应用，而K8S本身就是一个多服务器应用（它又能通过容器技术管理一个到成百上千个其他的多服务器应用）。Kubespray等项目已经在使用Ansible进行K8S集群的定制化构建，已经被使用在很多基于K8S的基础架构上。

假如你在使用托管的K8S，譬如AKS, EKS, 和GKE等等，Ansible有专门的针对性的module（譬如azure_rm_aks, aws_eks_cluster, gcp_container_cluster等）来辅助管理集群，当然还有成百上千的其他Ansible module可以用来简化集群管理，及标准化不同云服务提供商的集群管理。

即使你不需要管理有多重云的集群，Ansible也提供了一些很有用的工具，譬如可以用cloudformation module来管理AWS上的CloudFormation模板部署，可以用terraform module做Terraform的部署。

极少有应用是完全独立的在K8S集群内运行而不需要和一些外部的资源（譬如网络设备，存储，数据库服务等）打交道的。如果幸运的话，可能有现成的K8S Operator可以用来和这些外部资源集成，但是很多时候你会发现并没有这样的K8S Operator。这时Ansible就能派上用场了，Ansible可以通过和云原生通用的YAML语言编辑Playbooks来管理K8S集群和外部资源。

我想重复一下上面说过的话：你不应该满足于通过手工的方式构建和管理K8S集群，尤其是有多个集群需要管理的情况。

应用生命周期管理（Application Lifecycles）

最后一个Ansible能发挥重要价值的领域是管理K8S上应用的生命周期。你可以使用Ansible基于Operator SDK构建operator, 对应用的生命周期管理进行编码，包括部署，升级，备份等等，然后应用到各个K8S集群。光是这一项Ansible的作用就够大的了。

相比于开发和运维人员不得不学习Go语言或其他专门的语言来维护operator, 采用YAML/Ansible可能是一个更好的选择。基于Operator SDK的现状，在一些高级的使用场景可能不得不回退到使用Go语言来开发opertor，Ansible还是会有很多能发挥作用的场景。

结语

如果团队已经在使用Ansible, 显然可以把现有的Ansible的积累，roles/modules/Playbooks等迁移到K8S管理的Playbooks和基于Ansible的Operator。如果是还没有使用Ansible的团队，Ansible因为其出色的IT自动化方面的灵活性和易用性，也可以成为云原生编排相关的理想的辅助工具。