為什麼容器和 Kubernetes 有潛力執行一切
不僅可以部署簡單的應用程式，還可以用 Kubernetes 運維器應對第 2 天運營。
在我的第一篇文章 為什麼說 Kubernetes 是一輛翻鬥車 中，我談到了 Kubernetes 如何在定義、分享和執行應用程式方面很出色，類似於翻鬥車在移動垃圾方面很出色。在第二篇中，如何跨越 Kubernetes 學習曲線，我解釋了 Kubernetes 的學習曲線實際上與執行任何生產環境中的應用程式的學習曲線相同，這確實比學習所有傳統元件要容易（如負載均衡器、路由器、防火牆、交換機、叢集軟體、叢集檔案系統等）。這是 DevOps，是開發人員和運維人員之間的合作，用於指定事物在生產環境中的執行方式，這意味著雙方都需要學習。在第三篇
在這最後一篇文章中，我會分享我為什麼對在 Kubernetes 上執行應用程式的未來如此興奮的原因。
從一開始，Kubernetes 就能夠很好地執行基於 Web 的工作負載（容器化的）。Web 伺服器、Java 和相關的應用程式伺服器（PHP、Python等）之類的工作負載都可以正常工作。該平臺處理諸如 DNS、負載平衡和 SSH（由 kubectl exec
但是，如果你需要執行具有複製功能的多主 MySQL，會發生什麼情況？使用 Galera 的冗餘資料呢？你如何進行快照和備份？那麼像 SAP 這樣複雜的工作呢？使用 Kubernetes，簡單的應用程式（Web 伺服器等）的第 0 天（部署）相當簡單，但是沒有解決第 2 天的運營和工作負載。這並不是說，具有複雜工作負載的第 2 天運營要比傳統 IT 難解決，而是使用 Kubernetes 並沒有使它們變得更容易。每個使用者都要設計自己的天才想法來解決這些問題，這基本上是當今的現狀。在過去的五年中，我遇到的第一類問題是複雜工作負載的第 2 天操作。（LCTT 譯註：在軟體生命週期中，第 0 天是指軟體的設計階段；第 1 天是指軟體的開發和部署階段；第 2 天是指生產環境中的軟體運維階段。）
值得慶幸的是，隨著 Kubernetes 運維器的出現，這種情況正在改變。隨著運維器的出現，我們現在有了一個框架，可以將第 2 天的運維知識彙總到平臺中。現在，我們可以應用我在 Kubernetes 基礎：首先學習如何使用 中描述的相同的定義狀態、實際狀態的方法，現在我們可以定義、自動化和維護各種各樣的系統管理任務。
（LCTT 譯註： Operator 是 Kubernetes 中的一種可以完成運維工程師的特定工作的元件，業界大多沒有翻譯這個名詞，此處仿運維工程師例首倡翻譯為“運維器”。）
我經常將運維器稱為“系統管理機器人”，因為它們實質上是在第 2 天的工作中整理出一堆運維知識，該知識涉及主題專家（SME、例如資料庫管理員或系統管理員）針對的工作負載型別（資料庫、Web 伺服器等），通常會記錄在 Wiki 中的某個地方。這些知識放在 Wiki 中的問題是，為了將該知識應用於解決問題，我們需要：
- 生成事件，通常監控系統會發現故障，然後我們建立故障單
- SME 人員必須對此問題進行調查，即使這是我們之前見過幾百萬次的問題
- SME 人員必須執行該知識（執行備份/還原、配置 Galera 或事務複製等）
通過運維器，所有這些 SME 知識都可以嵌入到單獨的容器映象中，該映象在有實際工作負荷之前就已部署。 我們部署運維器容器，然後運維器部署和管理一個或多個工作負載例項。然後，我們使用“運維器生命週期管理器”（Katacoda 教程）之類的方法來管理運維器。
因此，隨著我們進一步使用 Kubernetes，我們不僅簡化了應用程式的部署，而且簡化了整個生命週期的管理。運維器還為我們提供了工具，可以管理具有深層配置要求（群集、複製、修復、備份/還原）的非常複雜的有狀態應用程式。而且，最好的地方是，構建容器的人員可能是做第 2 天運維的主題專家，因此現在他們可以將這些知識嵌入到操作環境中。
本系列的總結
Kubernetes 的未來是光明的，就像之前的虛擬化一樣，工作負載的擴充套件是不可避免的。學習如何駕馭 Kubernetes 可能是開發人員或系統管理員可以對自己的職業發展做出的最大投資。隨著工作負載的增多，職業機會也將增加。因此，這是駕駛一輛令人驚歎的 在移動垃圾時非常優雅的翻鬥車……
你可能想在 Twitter 上關注我，我在 @fatherlinux 上分享有關此主題的很多內容。
via: opensource.com/article/19/…
作者：Scott McCarty 選題：lujun9972 譯者：wxy 校對：wxy