容器存儲廠商Portworx公司首席技術官兼聯合創始人Gou Rao說，“越來越多的團隊開始在生產中使用Kubernetes來運行其容器化工作負載和應用程序。當零停機時間和安全性至關重要時，Kubernetes迅速成為在生產中運行大規模復雜應用程序的最簡單方法。Kubernetes很復雜，以至于并不適合所有人，但是對于需要跨多個云平臺和數據中心運行的具有高度規模和復雜性的應用程序，Kubernetes并非遙不可及。”
但Kubernetes并不是一個一成不變的工具，無論其具有多么強大的自動化能力。很多企業正在實施的管理任務值得關注。
Harness公司DevOps技術傳播者Ravi Lachhman說，“與任何平臺一樣，Kubernetes也需要管理和維護。”
與此同時，Red Hat公司安全策略師Kirsten Newcomer說，“安全性應該盡早將其納入企業的流程中。新技術可以挑戰現有的安全方法。例如，數據收集和網絡安全解決方案需要適應應用程序運行的環境。最佳實踐是永遠不要修補正在運行的容器。如果這樣做，則下次從映像部署該容器實例時，這個修補程序將會丟失。這意味著企業需要重新評估其對DevOps的投資以及加強安全性。”
長期管理Kubernetes的7個技巧
行業專家可以為企業團隊和從業人員提供有關管理Kubernetes的7個建議：
1.企業必須將Kubernetes視為一項重大投資
企業在筆記本電腦或沙箱環境中修改Kubernetes是一回事(許多團隊都是從這種方式開始的，而Minikube和類似的工具使這種方式相對簡單)，而在生產環境中運行是另一種回事。
Rao說，“正確地采用Kubernetes要求企業認真對待它。確實，所有技巧實質上都源于此。”他認為，這是一個功能強大的軟件引擎，因此需要認真對待它。
Rao說，“這個引擎希望能夠根據企業提供的參數，隨時隨地運行、移動和重新移動應用程序。企業需要采用Kubernetes做什么，如何實現。如果要從這種運營效率中受益，則需要為其提供有效運行的環境。”
這意味著企業需要擁有合適的人員、基礎設施、流程和文化。很多企業希望Kubernetes能夠解決現有的結構問題，這些問題會使其環境管理變得混亂。
2.即使協調者也需要管理和維護
一些團隊(尤其是剛起步的團隊)可能認為Kubernetes會自己運行。考慮到協調者的聲明性和對自動化的重視，這個實際上具有一種偽基準。但是Kubernetes像其他系統一樣需要一些管理和維護。
Lachhman說：“每個企業都是不同的，并且初次掌握新的知識和經驗將對其組織產生長期的影響。”
Lachhman指出了常見維護和管理任務的示例，例如：
•修補或升級集群及其基礎設施;
•添加和減去工作節點;
•插入新功能，例如Istio和Traefik等服務網格工具;
•建立明確定義的命名空間分類法，尤其是隨著越來越多的團隊開始使用Kubernetes。
為什么名稱空間很重要?它們有助于保護多個用戶之間對容器中資源的訪問。
3. Kubernetes需要適當的基礎設施才能成功
長期成功管理Kubernetes的基本需求之一是采用適當的基礎設施，例如混合云和多云環境。
Rao說，“我看到團隊犯下的錯誤正在轉向Kubernetes，因為他們想要敏捷性，但隨后又影響了Kubernetes提供推動其最初決策的運營成果的能力。這種做法有些自欺欺人。任何系統都只有其最小敏捷性元素才具有敏捷性，因此，如果在靜態數據中心環境中運行Kubernetes，而該環境中存儲的硬件和軟件為不那么敏捷的虛擬機環境提供了相同的硬件和軟件，如果企業沒有認真對待Kubernetes，那么不會獲得所追求的好處。”
Zettaset公司工程副總裁Maksim Yankovskiy表示，存儲是基礎設施的一個特定子集，可能需要進行規劃。例如，有狀態容器帶有特殊的存儲注意事項。
Yankovskiy說，“為工作負載規劃存儲至關重要。某些工作負載可能需要專門的存儲或按應用程序調整存儲參數。并非所有存儲都應該由Kubernetes管理。”
Rao還以存儲為例，這是團隊在采用Kubernetes時可能會忽略的特定領域的示例，該過程旨在變得更加敏捷，而這將會在管理方面引起麻煩。
Rao說，“與許多與在Kubernetes上運行數據服務的客戶合作，而我一直聽到的一句話是‘我曾嘗試在Kubernetes上運行MongoDB，但SAN一直存在問題。’可以采用SAN，但是它們并不是為Kubernetes的規模、密度和動態性而設計的。為了充分利用Kubernetes，企業需要為其提供有效運行所需的基礎設施。如果只為其提供靜態基礎設施，它將無法發揮其作用。”
4. Kubernetes的可靠性會讓企業過分自信
正如Rao一開始指出的那樣，Kubernetes的自我修復和可靠性功能是其具有吸引力的重要組成部分，只是不要以它們為借口而忽略其運行狀況。例如，仍然需要確保有適當的監視。
Yankovskiy說：“不要依靠Kubernetes的可靠性功能來解決錯誤的服務。僅僅因為Kubernetes出色地完成了自動重啟失敗的Pod的工作，并不意味著不應該監視應用程序的運行時錯誤。”
隨著企業的發展和成長，日志記錄是另一個重要的管理需求。
Yankovskiy說：“Kubernetes集群是高度分布式的，因此，部署Kubernetes集群的第一步應包括計劃集中式日志記錄設施。在監視性能或診斷問題時訪問單個節點上的日志是不可擴展的。出色的日志管理系統是強大的Kubernetes管理的基礎之一。”
Red Hat公司技術傳道者Gordon Haff補充說：“部署到Kubernetes的云原生應用程序基本上是分布式應用程序，IT商店習慣于運行整體程序的架構可能沒有很多經驗。Kubernetes軌道上的開源項目生態系統包括監視、日志記錄、分布式跟蹤等。但是企業可能想要一個已經將該工具與Kubernetes集成在一起的平臺，而不是著手進行大型的DIY項目。企業的員工也可能會從新的云原生應用程序開發實踐培訓中受益。”
總的來說，當團隊將Kubernetes視為一種靈丹妙藥，而不是像其他任何重要系統一樣必須維護和改進的工具時，團隊往往會遇到問題。
Lachhman說：“企業可能會有多位管理員和一個定期更改的拓撲結構，并且在使用Kubernetes時不受網絡延遲的影響。”
5.實驗和無聊之間需要定期調整
Lachhman指出，使用Kubernetes本身已不再具有實驗性的資格。該項目開展了將近5年，如今已成為一個穩定可靠的平臺。也就是說，生態系統正在不斷發展：考慮諸如運算符、集群API、GitOps和上述服務網格工具之類的事情。 Lachhman說，Kubernetes團隊將需要決定如何在創新和控制之間進行切換，這是企業管理層的考慮。
一方面，大多數團隊可能會因為在“無聊”方面犯錯誤，特別是在采用的早期階段。
Lachhman說：“通過保持簡單的方法，需要了解不在CNCF中的最新測試版或特殊興趣小組(SIG)上對企業的Kubernetes工作負載沒有損害。另一方面，企業不想錯過可能解決實際問題的新功能。因此，企業必須確定適合自己的方法，在Kubernetes內部權衡更多經過實踐檢驗的方法與新方法的選擇。”
6.剛性開發在容器和編排中不能很好地發揮作用
現代IT工具最適合現代IT慣例和文化。這既可能是人員管理問題，也可能是技術管理問題。
Zettaset公司的Yankovskiy說：“ Kubernetes就是關于快速開發和部署的。一些組織可能需要過渡到DevOps模式，以實現Kubernetes的全部利益。”
這一原則也適用于應用程序本身。并不是所有的東西都適合容器和編排，“提升和轉移”并不總是將傳統應用程序遷移到容器并與Kubernetes一起運行的最佳策略。事實上，更好的選擇可能是根本不遷移這個應用程序。
Yankovskiy說，“并不是所有事情都必須在Kubernetes上運行，Kubernetes是工作的工具。它對很多事情都有好處，但是隨著許多傳統應用程序遷移到容器中，重要的是要了解并非所有內容都必須在容器中運行。”
7.量力而行
企業善于學習是一件好事，但了解自己的局限性也是件好事。否則，長期管理Kubernetes可能會面臨一些問題，因此需要知道何時尋求外部幫助。
Lachhman建議說：“企業避免尋求獲得更多的技能，并且知道何時將復雜性轉移出去。而從頭開始構建自己的集群，并在每次部署時運行一致性測試，這似乎是一個黃金標準，但對于大多數工作負載來說，將這種復雜性交給PaaS或Kubernetes供應商并不是一個壞主意。”
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號