【51CTO.com快譯】根據Gartner的一項預測：到2022年，全球將有超過75%的組織，會在生產環境中執行容器化的應用(如今該比例不到30%)。而到2025年，該比例將會超過85%。由於雲原生應用需要基礎架構的高度自動化，目前以Docker和Kubernetes為代表的DevOps實現平臺，正在以容器編排工具的形式，讓更多的公司能夠以更快的速度，構建、釋出和交付其軟體產品。
網站開發專案
總的說來，Kubernetes具有支援自動擴充套件、零停機時間部署、服務發現、自動部署、以及回滾等出色且豐富的功能，非常適合於大規模的容器部署與管理。雖然Kubernetes能夠靈活地分配資源和工作負載，但是具有複雜而陡峭的學習曲線。為了省時省力，您當然可以將其外包給KaaS提供商。不過，如果您需要對生產環境中的Kubernetes具有全面的掌控能力，那麼就需要花費一些時間，來掌握Kubernetes的可觀察性、日誌記錄、叢集監控、以及安全性配置等方面。
與此同時，由於在生產環境中執行容器往往需要大量的計算資源與能力，因此人們紛紛選用各種基於雲的編排平臺。不過，這其中也潛在著一些安全問題。例如：Kubernetes Pod雖然可以在所有基礎架構中快速啟動，但是隨著其Pod之間內部流量的增加，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需要始終確保擁有正常的就緒探針。
透過上述對於Kubernetes的健康檢查，我們可以及時對於檢測到的故障服務，採取自動下線，或重啟服務的方式，使其自行恢復。
資源管理通常，我們需要為單個容器指定或限制資源的請求數，將Kubernetes所處的環境分為不同的名稱空間(namespace)，以供不同的團隊、部門、應用、以及客戶來使用。具體請參見--http://blog.kubecost.com/blog/requests-and-limits/。
值得一提的是，此處的Kubernetes資源使用情況是指在生產環境中，容器與Kubernetes Pod的資源被使用的數量。據此，我們可以合理地控制好在轉化時所需的成本。此外，通常運營團隊還需要獲悉容器的CPU平均使用率，以及Pod所消耗的資源百分比，進而判定目前的Kubernetes生產環境是否處於已被最佳化的最佳狀態。
啟用RBACRBAC(基於角色的訪問控制)是一種許可或限制使用者和應用，對於系統和網路訪問的方法。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。
從無狀態的應用開始由於執行無狀態應用要比有狀態的應用容易得多，因此對於剛上手Kubernetes的團隊而言，他們可以使用無狀態的後端，透過避免建立長期執行(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)，我們也能夠確保副本數量最少。