【51CTO.com快譯】根據Gartner的一項預測：到2022年，全球將有超過75%的組織，會在生產環境中運行容器化的應用(如今該比例不到30%)。而到2025年，該比例將會超過85%。由于云原生應用需要基礎架構的高度自動化，目前以Docker和Kubernetes為代表的DevOps實現平臺，正在以容器編排工具的形式，讓更多的公司能夠以更快的速度，構建、發布和交付其軟件產品。

總的說來，Kubernetes具有支持自動擴展、零停機時間部署、服務發現、自動部署、以及回滾等出色且豐富的功能，非常適合于大規模的容器部署與管理。雖然Kubernetes能夠靈活地分配資源和工作負載，但是具有復雜而陡峭的學習曲線。為了省時省力，您當然可以將其外包給KaaS提供商。不過，如果您需要對生產環境中的Kubernetes具有全面的掌控能力，那么就需要花費一些時間，來掌握Kubernetes的可觀察性、日志記錄、集群監控、以及安全性配置等方面。

與此同時，由于在生產環境中運行容器往往需要大量的計算資源與能力，因此人們紛紛選用各種基于云的編排平臺。不過，這其中也潛在著一些安全問題。例如：Kubernetes Pod雖然可以在所有基礎架構中快速啟動，但是隨著其Pod之間內部流量的增加，Kubernetes的攻擊面會逐漸增大，安全隱患隨之增多。此外，Kubernetes固有的高度動態、且短暫的運行環境，往往無法與傳統的安全工具完美融合。我們亟待開發出一種能夠滿足存儲安全性、網絡監控與治理、容器生命周期管理、以及平臺選擇等需求的Kubernetes配置策略。

下面，我將和您討論在生產環境中，可遵循的Kubernetes各種優秀實踐與探索。

使用就緒且存活的探針(Probes)進行健康檢查

對于線上業務而言，保證服務的正常穩定是重中之重。而對于故障服務的及時處理，避免影響業務，以及快速恢復一直是DevOps的難點。在管理大型且分布式的系統時，為了確保應用實例的正常運行，我們需要提前設置好Kubernetes的運行狀況檢查。

您可以根據目標環境與需求，來創建并定制各種運行狀況檢查項。例如，我們可以用到WeaveWorks。它能夠創建一個虛擬的網絡，以網絡交換機的方式，連接到部署在多臺主機上的Docker容器，便于應用無需逐個配置端口映射和鏈接等信息。具體內容請參見--https://www.weave.works/blog/resilient-apps-with-liveness-and-readiness-probes-in-kubernetes。

值得注意的是，那些就緒(Readiness)的探針可以讓Kubernetes知曉應用是否已準備好了為流量提供對應的服務。也就是說，在分配服務并將流量發送給Pod之前，Kubernetes需要始終確保擁有正常的就緒探針。

那么，我們又該如何獲悉應用的有效性呢?在此，我們需要通過存活(Liveliness)探針，以確保應用一旦失效，Kubernetes會立即刪除舊的Pod，并將其替換為新的Pod。

通過上述對于Kubernetes的健康檢查，我們可以及時對于檢測到的故障服務，采取自動下線，或重啟服務的方式，使其自行恢復。

資源管理

通常，我們需要為單個容器指定或限制資源的請求數，將Kubernetes所處的環境分為不同的命名空間(namespace)，以供不同的團隊、部門、應用、以及客戶來使用。具體請參見--http://blog.kubecost.com/blog/requests-and-limits/。

值得一提的是，此處的Kubernetes資源使用情況是指在生產環境中，容器與Kubernetes Pod的資源被使用的數量。據此，我們可以合理地控制好在轉化時所需的成本。此外，通常運營團隊還需要獲悉容器的CPU平均使用率，以及Pod所消耗的資源百分比，進而判定目前的Kubernetes生產環境是否處于已被優化的最佳狀態。

啟用RBAC

RBAC(基于角色的訪問控制)是一種許可或限制用戶和應用，對于系統和網絡訪問的方法。Kubernetes從1.8版開始便引入了RBAC。我們可以通過rbac.authorization.k8s.io API組，來創建各種授權策略，限制能夠訪問目標生產環境和群集的用戶與進程。

可以說，RBAC為Kubernetes集群增加了一個額外的安全層。您可以在Kubernetes中對某些帳戶的權限進行添加或刪除，以及設置具體的訪問規則。具體內容請參見--https://medium.com/@danielckv/what-is-rbac-in-kubernetes-c54457eff2dc

群集配置和負載平衡

要滿足生產環境級別，Kubernetes架構需要具備高可用性、multi-master、以及multi-etcd群集等特性。在實際應用中，我們往往會使用諸如Terraform、Ansible之類的工具，來配置群集。

一旦我們設置好了所有的集群，并為正在運行的應用創建了Pod，那么我們就該考慮為這些Pod配備負載平衡器，以便將各種網絡流量路由到對應的服務處。不過，開源的Kubernetes項目并不會默認提供負載均衡器。因此，我們需要與諸如NGINX Ingress controller、HAProxy或ELB之類的工具，或是針對Kubernetes的插件，來實現負載平衡的功能。具體內容請參見--https://medium.com/avmconsulting-blog/external-ip-service-type-for-kubernetes-ec2073ef5442。

將標簽附加到Kubernetes對象

我們可以將諸如鍵/值對(key/value pairs)之類的標簽，作為某種屬性附加到Pod等對象上。在生產環境中，我們可以通過標簽，對Kubernetes對象進行識別，分組，批量查詢，以及其他操作。例如：我們可以根據容器所屬的應用，對容器進行分組。當然，團隊可以事先建立好任意數量的標簽約定。具體內容請參見--https://theithollow.com/2019/01/31/kubernetes-services-and-labels/。

設置網絡策略

網絡策略能夠方便我們通過明確的聲明，來決定哪些流量適合通過，進而讓Kubernetes能夠阻止所有不合格(non-conforming)或不需要的流量。例如，作為基本的安全措施，我們可以在群集中定義和限制某些網絡流量。

實際上，Kubernetes中的每個網絡策略都可以被定義為一個授權連接的列表。根據已創建的網絡策略，只有滿足條件的Pod才有資格接受既定的連接。簡而言之，網絡策略會根據白名單，來授權和允許“從”或“向”Pod建立的連接。具體內容請參見--https://theithollow.com/2019/10/21/kubernetes-network-policies/。

集群監控和日志記錄

集群監控，對于確保生產環境中Kubernetes的配置、性能和流量等方面的安全性，都是至關重要的。同時，我們有必要在系統架構的每一層上設置日志功能。這些生成的日志將有助于我們通過安全工具，來執行分析和審計功能。可以說，沒有日志和監控，我們就不可能診斷出發生的問題，也就無法確保合規性。具體內容請參見--https://dzone.com/articles/logging-amp-monitoring-of-kubernetes-applications。

從無狀態的應用開始

由于運行無狀態應用要比有狀態的應用容易得多，因此對于剛上手K​​ubernetes的團隊而言，他們可以使用無狀態的后端，通過避免建立長期運行(long-running)的連接，輕松地根據業務的需求，按需進行靈活的遷移和擴展。此外，通過使用無狀態，開發人員還可以在零停機時間狀態下，更有效地部署應用程序。

啟用自動擴展插件(Auto Scaler)

Kubernetes提供三種用于部署的自動擴展功能，即：水平Pod自動擴展插件(HPA)、垂直Pod自動擴展插件(VPA)、以及群集自動擴展。其中：

• 水平Pod自動擴展插件，會根據感知到的CPU利用率，自動擴展部署、復制控制器、副本(replica)集、以及狀態集的數量。
• 垂直Pod自動擴展插件，會為CPU和內存的請求數和限定數設置合適的值，并且可以自動更新這些值。
• 群集自動擴展，可以擴展和收縮Worker節點池的大小，并能夠根據當前的利用率，來調整Kubernetes集群的大小。

控制運行時(run times)的各種源頭

如果您只允許Pod從公共資源中提取鏡像，那么您可能對運行時一無所知。因此，我們需要對群集中的所有容器進行源頭控制。通過在注冊表上應用策略，我們就可以從受信任的注冊表中提取安全、且經過認證的鏡像。

持續評估

我們需要不斷評估目標應用的狀態，以及設置的合理性。例如，我們可以通過查看某個容器的歷史內存使用情況，從長遠的角度來分配更少、卻又更加合理的內存數量，以節省成本。

保護那些重要的服務

通過使用Pod優先級，您可以對不同服務的重要程度進行設置。例如，為了獲得更好的穩定性，您可以將RabbitMQ Pod設置得比其他應用Pod更為重要;或者通過把Ingress Controller Pod的重要性設置得優先于數據處理Pod，進而保持那些面對用戶的服務的可用性。

零停機時間

說到可用性，我們還可以通過設置群集和服務的HA(高可用性)，來確保零宕機時間。例如，使用Pod的反親和性(Pod anti affinity)，我們可以確保在不同節點上，分配一個Pod的多個副本，并通過計劃內和計劃外的群集節點中斷，來確保服務的可用性。

此外，通過使用Pod的中斷預算(Pod disruption budgets)，我們也能夠確保副本數量最少。

小結

綜上所述，為了交付出平穩可靠的應用服務，我們從可用性、可擴展性、安全性、負載平衡、資源管理、以及監控等方面，深入討論了在生產環境中，可以遵循的Kubernetes各種優秀實踐。

原文標題：Kubernetes in Production: Best Practices to Follow，作者: Pavan Belagatti

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】