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

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

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

下面，我將和您討論在生產(chǎn)環(huán)境中，可遵循的Kubernetes各種優(yōu)秀實踐與探索。

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

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

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

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

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

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

資源管理

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

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

啟用RBAC

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

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

群集配置和負載平衡

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

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

將標簽附加到Kubernetes對象

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

設(shè)置網(wǎng)絡(luò)策略

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

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

集群監(jiān)控和日志記錄

集群監(jiān)控，對于確保生產(chǎn)環(huán)境中Kubernetes的配置、性能和流量等方面的安全性，都是至關(guān)重要的。同時，我們有必要在系統(tǒng)架構(gòu)的每一層上設(shè)置日志功能。這些生成的日志將有助于我們通過安全工具，來執(zhí)行分析和審計功能?？梢哉f，沒有日志和監(jiān)控，我們就不可能診斷出發(fā)生的問題，也就無法確保合規(guī)性。具體內(nèi)容請參見--https://dzone.com/articles/logging-amp-monitoring-of-kubernetes-applications。

從無狀態(tài)的應(yīng)用開始

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

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

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

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

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

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

持續(xù)評估

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

保護那些重要的服務(wù)

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

零停機時間

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

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

小結(jié)

綜上所述，為了交付出平穩(wěn)可靠的應(yīng)用服務(wù)，我們從可用性、可擴展性、安全性、負載平衡、資源管理、以及監(jiān)控等方面，深入討論了在生產(chǎn)環(huán)境中，可以遵循的Kubernetes各種優(yōu)秀實踐。

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

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