-- 原文出處：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自動化方面的靈活性和易用性，也可以成爲雲原生編排相關的理想的輔助工具。