Kubernetes 大規模使用過的都說簡單，沒有用過清一色的都是使用復雜、概念晦澀難懂，因此即使是那些具有一定服務器端知識的人也可能會感到困惑。讓我在這里嘗試一些不同的東西。與其解釋一個不熟悉的問題（如何在 Kubernetes 中運行 Web 服務？）和另一個（你只需要一個清單，三個 sidecar 和一堆 gobbledygook），我將嘗試揭示 Kubernetes 技術發展趨勢。

如果您已經知道如何使用虛擬機運行服務，希望您會發現最終并沒有太大區別。如果您對大規模運營服務完全不熟悉，那么跟隨技術的發展可能會幫助您了解當代方法。

像往常一樣，這篇文章并不全面。相反，它試圖總結我的個人經歷以及計算機多年來虛擬化是如何形成的。

如何使用虛擬機部署服務

早在 2010 年，當我剛剛開始我的軟件工程師職業生涯時，使用虛擬機（或有時是裸機）部署應用程序非常普遍。

你需要一個臨時的 Linux 虛擬機，將 Nginx 或 Apache 反向代理放在它前面，然后在它旁邊運行一堆守護進程和 cronjobs。

這樣的機器將代表服務的單個實例，打個比方，就類似于一個盒子，而服務本身將只是分布在網絡上的一組命名的相同機器。根據您的業務規模，您可能只有幾個、幾十個、幾百個甚至幾千個盒子分布在為生產流量提供服務的多個盒子中。

服務的抽象將應用程序的復雜性隱藏在單個入口點之后

使用虛擬機部署服務帶來的挑戰

通常，機器群的大小將定義配置（安裝操作系統和軟件包）、擴展（產生相同的盒子）、服務發現（將一組盒子隱藏在一個名稱后面）和部署（運送新版本的代碼）的方式到盒子）完成了。

如果你是一個只有幾個類似寵物的盒子的公司，您可能會發現自己很少半手動地配置新盒子。這通常意味著總線系數低（由于缺乏自動化）、安全狀況差（由于缺乏定期補丁更新）以及可能更長的災難恢復。從好的方面來說，管理成本會非常低，因為不需要擴展，您的部署會很簡單（只需幾個盒子來交付代碼），而且服務發現會很簡單（由于相當靜態地址池）。

對于擁有大量盒子的公司來說，現實情況會有所不同。大量機器通常會導致更頻繁地需要配置新盒子（更多的盒子意味著更多的破損）。你會投資自動化（投資回報率會很高），最終得到許多牛一樣的盒子。作為不斷重新創建盒子的副產品，您將增加總線因素并改善安全狀況（將自動更新和安裝補丁）。在它的反面，會存在低效的擴展（由于每日/每年的流量分布不均勻），過于復雜的部署（很難將代碼快速交付到許多機器上），以及脆弱的服務發現（您是否嘗試過大規模運行consul或zookeeper？）會導致更高的運營成本。

Amazon Elastic Compute Cloud (EC2) 等早期云產品允許更快地啟動（和關閉）機器；使用packer制作并使用cloud-init自定義的機器鏡像，使配置稍微容易一些；puppet和ansible等自動化工具支持應用基礎架構更改并大規模交付新版本的軟件。但是，仍有很大的改進空間。

Docker 容器解決了什么問題

在過去，擁有不同的生產和開發環境是很常見的。這將導致應用程序可能在您安裝的 Debian 機器上本地運行，但由于缺少依賴項而無法在生產中的 vanilla CentOS 上啟動。相反，在本地安裝應用程序的依賴項可能會遇到一些麻煩，但由于資源需求高，為每個服務運行預配置的虛擬機進行開發將是不可行的。

即使在生產中，虛擬機的龐大也是一個問題。每個服務擁有一個虛擬機可能會導致低于最佳資源利用率和/或相當大的存儲和計算開銷，但是將多個服務放在一個盒子中可能會使它們發生資源搶占沖突。

世界顯然需要一個更輕量級的盒子。

容器 - 單個應用程序的盒子

這就是容器的用武之地。就像允許將裸機服務器分割成幾臺更小（更便宜）的機器的虛擬機一樣，容器將一個 Linux 機器分割成數十個甚至數百個獨立的環境。

在一個容器中，您可能會覺得您擁有自己的虛擬機，以及您最喜歡的 Linux 發行版。好吧，至少乍一看。從外部看，容器只是在主機操作系統上運行并共享其內核的常規進程。

打包應用程序及其所有依賴項（包括特定版本的操作系統用戶空間和庫）的能力，將其作為容器鏡像發送，并在安裝了 Docker（或類似工具）的任何位置的標準化執行環境中運行，極大地提高了工作負載的可重復性.

由于容器邊界的輕量級實現，計算開銷顯著降低，允許單個生產服務器運行可能屬于多個（微）服務的數十個不同容器。當然，這可能以降低安全性為代價。

由于不可變和共享的鏡像層，鏡像存儲和分發也變得更加高效。

在某種程度上，容器也改變了供應的方式。使用（粗心編寫的）Dockerfiles 和ko和Jib之類的（神奇的）工具，責任極大地轉移到了開發人員身上，簡化了生產 VM 的要求——從開發人員的角度來看，你只需要一個 Docker-（或更高版本的 OCI-）兼容應用程序的運行時，因此您不會再因為要求安裝某個版本的 Linux 或系統包而惹惱您的運維朋友。

最重要的是，容器加速了運行服務的替代方式的開發。現在有 17 種方法可以在 AWS 上運行容器https://www.lastweekinaws.com/blog/the-17-ways-to-run-containers-on-aws/，其中大部分是完全無服務器的，在足夠簡單的情況下，您可以使用 Lambda 或 Fargate 并從牛一樣的盒子中受益！

容器不能解決什么問題

容器被證明是一個非常方便的開發工具。構建容器鏡像也比構建 VM 更簡單、更快捷。再加上如何有效分離團隊之間職責的老組織問題，導致典型企業的平均服務數量顯著增加，每個服務的盒子數量也有類似的增加。

Docker 普及的容器形式實際上具有很強的欺騙性。乍一看，每個服務實例都有一個便宜的專用 VM。但是，如果這樣的實例需要sidecar（例如在您的 Web 應用程序前面運行的本地反向代理來終止 TLS 連接或加載秘密和/或預熱緩存的守護程序），您會立即感覺到疼痛，這就是容器與虛擬機的本質區別。

Docker 容器被刻意設計為只包含一個應用程序。一個容器——一個 Nginx；一個容器 - 一個 Python Web 服務器；一個容器 - 一個守護進程。容器的生命周期將綁定到該應用程序的生命周期。并且特別不鼓勵將像systemd這樣的 init 進程作為頂級入口點運行。

因此，要從本文開頭的圖表重新創建一個 VM-box，您需要擁有三個具有共享網絡堆棧的協調容器-box（嗯，至少localhost需要相同）。要運行該服務的兩個實例，您需要三個三個一組的六個容器！

從擴展的角度來看，這意味著我們需要一起擴展（和縮減）一些容器。部署也需要同步進行。新版本的 Web 應用程序容器可能會開始使用新的端口號，并與舊版本的反向代理容器不兼容。

我們顯然在這里錯過了一個抽象，它與容器一樣輕量級，但與原始 VM 盒子一樣富有表現力。

此外，容器本身也沒有提供任何將盒子分組為服務的方法。但他們促成了箱子人數的增加！Docker 競相用它的 Swarm 產品解決這些問題，但另一個系統贏了……

Kubernetes 解決了這一切……還是沒有？

Kubernetes 設計師顯然沒有發明新的運行容器的方法，而是決定重新創建良好的舊的基于 VM 的服務架構，但使用容器作為構建塊。好吧，至少這是我的看法。

但對我來說，作為以前有 VM 經驗的人，一旦我了解了新術語并弄清楚了類似的概念，許多最初的 Kubernetes 想法就會開始看起來很熟悉。

Kubernetes Pod 是新的虛擬機

讓我們從 Pod 抽象開始。Pod 是您可以在 Kubernetes 中運行的最小的東西。最簡單的 Pod 定義如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.20.1
    ports:
    - containerPort: 80

乍一看，上面的清單只是說明要運行什么鏡像（以及如何命名）。但是請注意containers屬性是一個列表！現在，回到那個nginx + web app例子，在 Kubernetes 中，您可以簡單地將反向代理和應用程序本身放在一個盒子中，而不是為 Web 應用程序容器運行額外的 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: foo-instance-1
spec:
  containers:
  - name: nginx            # <-- sidecar container
    image: nginx:1.20.1
    ports:
    - containerPort: 80
  - name: app              # <-- main container
    image: app:0.3.2

然而，Pod 不僅僅是一組容器。Pod 中容器之間的隔離邊界被削弱。就像在 VM 上運行的常規進程一樣，Pod 中的容器可以通過localhost或使用傳統的 IPC 方式自由通信。同時，每個容器仍然有一個獨立的根文件系統，以保持打包應用程序及其依賴項的好處。對我來說，這看起來像是在嘗試同時利用 VM 和容器世界的最佳部分：

擴展和部署 Pod 很簡單

現在，當我們得到新的盒子時，我們如何運行多個它們來組成一個服務？換句話說，如何在 Kubernetes 中進行擴展和部署？

事實證明，它非常簡單，至少在基本場景中是這樣。Kubernetes 引入了一個方便的抽象，稱為 Deployment。最小的 Deployment 定義由名稱和 Pod 模板組成，但指定所需的 Pod 副本數量也很常見：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: foo-deployment-1
  labels:
    app: foo
spec:
  replicas: 10
  selector:
    matchLabels:
      app: foo
  template:
    metadata:
      labels:
        app: foo
    spec:
      <...Pod definition comes here>

Kubernetes 的偉大之處在于，作為開發人員，您并不關心服務器（或 Kubernetes 術語中的節點）。您根據 Pod 組進行思考和操作，它們會自動調動（和重新分布）到集群節點：

這使得 Kubernetes 更像是一種無服務器技術。但同時，Pod 的外觀和行為與過去熟悉的 VM 非常相似（除了您不需要管理它們），因此您可以在熟悉的抽象中設計和推理您的應用程序：

內置服務發現

Kubernetes Service - 一組命名的 Pod。

Kubernetes 設計人員肯定知道，僅僅創建 N 個盒子的副本并將其稱為服務是不夠的。客戶端應該能夠使用單個（可能是邏輯的）名稱訪問服務，并且服務發現系統應該能夠將該名稱轉換為特定的 IP 地址（類似于我們理解的負載均衡器，服務于特定的實例） ）。

過去，您需要一個單獨的（并且要求非常高的）解決方案。但是，Kubernetes 內置了這個功能，而且默認實現還不錯！它還可以使用Linkerd或Istio等服務網格進行擴展，使其更加強大。

將一組 Pod 轉換為服務唯一需要做的就是創建一個 Service 對象（不是真正的創建服務，只是一個網絡層面的抽象）。

下面是一個簡單的 Kubernetes Service 定義的樣子：

apiVersion: v1
kind: Service
metadata:
  name: foo
spec:
  selector:
    app: foo
  ports:
    - protocol: TCP
      port: 80

上面的清單允許app=foo使用defaultDNS 名稱（如foo.default.svc.cluster.local. 而且這一切都沒有在集群中安裝任何額外的軟件！

請注意 Service 定義在任何地方都沒有提到 Deployment。就像 Deployment 本身一樣，它根據 Pod 和標簽運行，這使它非常強大！例如，Kubernetes 中良好的藍/綠或金絲雀部署可以通過讓兩個 Deployment 對象在單個 Service 選擇具有公共標簽的 Pod 后運行不同版本的應用程序鏡像來實現：

現在，最有趣的部分 - 你注意到 Kubernetes 服務與我們舊的基于 VM 的服務沒有什么區別了嗎？

Kubernetes 即服務

那么，Kubernetes 是不是就像 VM 一樣，但更簡單？嗯，是的，但也不是。因為他跟虛擬機存在本質上的差別，套用Kelsey Hightower的話，我們應該區分駕駛汽車的復雜性和修理汽車的復雜性。我們中的許多人會開車，但很少有人擅長修理發動機。幸運的是，有專門的商店！這同樣適用于 Kubernetes。

使用 EKS 或 GKE 等托管 Kubernetes 產品運行服務確實很相似，但比使用 VM 簡單得多。但如果你必須維護 Kubernetes 集群背后的實際服務器，那就完全不同了……，所以僅僅使用 Kubernetes 和維護 Kubernetes 是兩碼事。

總結

為了改善在 VM 上運行服務的體驗，容器改變了我們打包軟件的方式，大大降低了對服務器配置的要求，并啟用了替代方法來部署我們的工作負載。但就其本身而言，容器并沒有成為大規模運行服務的解決方案。頂部仍然需要額外的編排層。

Kubernetes 作為容器原生編排系統之一，使用容器作為基本構建塊重新創建了過去熟悉的架構模式。Kubernetes 還通過提供用于擴展、部署和服務發現的內置方法來解決傳統方案的痛點。