你可以將本文作為開(kāi)發(fā)者快速了解 Kubernetes 的指南。從基礎(chǔ)知識(shí)到更高級(jí)的主題，如 Helm Chart，以及所有這些如何影響你作為開(kāi)發(fā)者。

譯自Kubernetes for Lazy Developers。作者 marcobehler 。

介紹

如果你是一位開(kāi)發(fā)者，要么從未使用過(guò) Kubernetes，要么想要復(fù)習(xí) Kubernetes 知識(shí)，以便讓你的 DevOps 同事對(duì)你刮目相看，那么這份指南適合你。

快速問(wèn)題：為什么將 Kubernetes 縮寫(xiě)為 K8s？

答案：它將在本指南末尾神奇地揭示，但僅在你完全閱讀完之后。所以，讓我們不再浪費(fèi)時(shí)間。

我們是如何到達(dá)這里的？

我在整個(gè)職業(yè)生涯中遇到的許多開(kāi)發(fā)者，對(duì)于他們應(yīng)用程序生命周期的“現(xiàn)在我已經(jīng)編寫(xiě)了代碼，它還需要在某個(gè)地方運(yùn)行”的部分并不一定關(guān)心。（根據(jù)你的公司對(duì) DevOps 這個(gè)詞的定義和認(rèn)知程度，這可能有所不同）。

但讓我們慢慢開(kāi)始。運(yùn)行一個(gè)應(yīng)用程序?qū)嶋H上意味著什么？

這在一定程度上取決于你所使用的編程語(yǔ)言生態(tài)系統(tǒng)。例如，在Java和現(xiàn)代Web應(yīng)用程序方面，你可以將所有源代碼編譯成一個(gè)單一的可執(zhí)行 .jar 文件，然后通過(guò)簡(jiǎn)單的命令運(yùn)行它。

java -jar myNewAIStartup.jar

對(duì)于生產(chǎn)部署，通常你也會(huì)希望有一些屬性，用于設(shè)置數(shù)據(jù)庫(kù)憑據(jù)或其他秘密。在上述的Java Spring Boot情況下，最簡(jiǎn)單的方式是擁有一個(gè)application.properties文件，但你也可以使用外部的秘密管理服務(wù)。

無(wú)論如何，上述的命令實(shí)際上是你需要運(yùn)行的所有內(nèi)容，用于部署你的應(yīng)用程序 - 無(wú)論你是在裸金屬上、虛擬機(jī)上、Docker容器中、有或沒(méi)有Kubernetes，甚至是你的Java驅(qū)動(dòng)的烤面包機(jī)。

僅運(yùn)行一個(gè)命令肯定不夠。哪里是問(wèn)題的瓶頸？

關(guān)于部署應(yīng)用程序時(shí)可能出現(xiàn)的問(wèn)題已經(jīng)在網(wǎng)絡(luò)上寫(xiě)了很多：

• 如果我的DEV環(huán)境和PRD環(huán)境之間存在庫(kù)/操作系統(tǒng)/基礎(chǔ)設(shè)施/某些版本不兼容怎么辦？
• 如果某些必需的操作系統(tǒng)軟件包丟失了怎么辦？
• 如果我們不想將應(yīng)用程序部署到云服務(wù)，而是部署到潛水艇上怎么辦？

對(duì)于這些問(wèn)題，根據(jù)你使用的編程語(yǔ)言生態(tài)系統(tǒng)，解決方法可能會(huì)有很大的不同 - 這是在線討論中經(jīng)常被忽視的一個(gè)主題。

對(duì)于純粹的Java Web應(yīng)用程序，上述提到的問(wèn)題（不包括潛水艇或更明智的基礎(chǔ)設(shè)施部分，比如你的數(shù)據(jù)庫(kù)），在很大程度上并不是問(wèn)題。你在服務(wù)器/虛擬機(jī)/容器/潛水艇上安裝JDK，運(yùn)行java -jar，然后幸福地生活在一起。

對(duì)于PHP、Python、咳咳，Node，情況就不同了，你很容易在開(kāi)發(fā)、測(cè)試或生產(chǎn)環(huán)境之間遇到版本不兼容的問(wèn)題。因此，人們渴望一種解決方案來(lái)擺脫這些煩惱：容器。

Docker、Docker Compose和Swarm：回顧

向Docker致敬！

很有可能你已經(jīng)知道Docker是什么，以及如何使用它。（如果不知道，并且想看一個(gè)特定于Docker的指南，請(qǐng)?jiān)谙旅嬖u(píng)論！需求越多 → 發(fā)布越快）。簡(jiǎn)短的總結(jié)是：

• 你將源代碼構(gòu)建為可部署的文件，例如jar文件。
• 你另外構(gòu)建一個(gè)新的Docker鏡像，其中包含你的jar文件。
• 該Docker鏡像還包含運(yùn)行成功所需的所有附加軟件和配置選項(xiàng)。

→ 你不再部署你的.jar文件，而是部署你的Docker鏡像并運(yùn)行Docker容器。

這樣做的美妙之處在于：只要在目標(biāo)機(jī)器上安裝了Docker（并且你的主機(jī)操作系統(tǒng)與Docker容器兼容內(nèi)核），你就可以運(yùn)行任何Docker鏡像。

docker run --name my-new-ai-startup -p 80:8080 -d mynewaistartup


// yay, your application is deployed


// This will start a Docker container based on the `_mynewaistartup_` Docker image.
// That image will, that other things, contain your e.g. -jar file,
// a web application which runs on port 8080, as well as instructions on how to run it.
// Hint: These instructions are `_java -jar mynewaistartup.jar_`.

什么是 'deploying' Docker 鏡像？

你或者你的 CI/CD 服務(wù)器設(shè)法將你的應(yīng)用程序制作成了一個(gè) Docker 鏡像。但是這個(gè) Docker 鏡像最終是如何在目標(biāo)部署服務(wù)器上運(yùn)行的呢？

你理論上可以將 Docker 鏡像保存為 .tar 文件，復(fù)制到最終服務(wù)器上并在那里加載它。但更現(xiàn)實(shí)的情況是，你會(huì)將 Docker 鏡像推送到一個(gè) Docker Registry，無(wú)論是dockerhub、Amazon ECR還是其他像GitLab的數(shù)不勝數(shù)的自托管容器 Registry 之一。

一旦你的鏡像成功上傳到 Registry，你可以在目標(biāo)服務(wù)器上登錄到該注冊(cè)表。

docker login mysupersecret.registry.com

一旦你在 Registry 上登錄成功，你的 docker run 就能找到你的自定義鏡像了。

docker run --name my-new-ai-startup -p 80:8080 -d mynewaistartup


//....
SUCCESS!

Docker Compose：同時(shí)運(yùn)行多個(gè)容器

如果你的應(yīng)用程序不僅僅包含一個(gè)單獨(dú)的 Docker 容器，比如說(shuō)，因?yàn)槟阈枰\(yùn)行98354 個(gè)微服務(wù)？

Docker Compose 來(lái)拯救。你將在一個(gè)傳統(tǒng)而又經(jīng)典的 YAML 文件，即compose.yaml文件中定義所有服務(wù)及其之間的依賴(lài)關(guān)系（運(yùn)行這個(gè)或那個(gè)先）。以下是一個(gè)定義兩個(gè)服務(wù)的示例，一個(gè)是 Web 服務(wù)，另一個(gè)是 Redis 服務(wù)。

services:
  web:
    build: .
    ports:
      - "8000:5000"
    volumes:
      - .:/code
      - logvolume01:/var/log
    depends_on:
      - redis
  redis:
    image: redis
volumes:
  logvolume01: {}

然后只需運(yùn)行docker compose up，整個(gè)環(huán)境（由所有獨(dú)立服務(wù)在單獨(dú)的 Docker 容器中運(yùn)行組成）將被啟動(dòng)。請(qǐng)注意，這意味著所有容器將在同一臺(tái)機(jī)器上運(yùn)行。如果要將其擴(kuò)展到多臺(tái)機(jī)器上，您將需要使用Docker Swarm。

雖然Docker Compose可能主要用于快速啟動(dòng)開(kāi)發(fā)或測(cè)試環(huán)境，但它實(shí)際上也適用于（單主機(jī)）生產(chǎn)部署。如果你的應(yīng)用程序…

• 沒(méi)有特定的高可用性要求
• 你不介意一些手動(dòng)操作（ssh 登錄，docker compose up/down）或使用輔助工具如Ansible
• 或者你只是不想在 DevOps 團(tuán)隊(duì)上投入巨額資金

…使用 Docker Compose 進(jìn)行生產(chǎn)部署將大有裨益。

Kubernetes 101: 基礎(chǔ)和概念

那么我為什么需要 Kubernetes 呢？

當(dāng)你想要開(kāi)始運(yùn)行數(shù)百、數(shù)千（或是它們的倍數(shù)）的容器時(shí)，事情變得有趣起來(lái)。如果你不關(guān)心或者不想知道這些容器將在哪臺(tái)具體的硬件/主機(jī)上運(yùn)行，但仍然希望能夠合理地管理所有這些，那么 Kubernetes 就派上用場(chǎng)了！

（注：相當(dāng)長(zhǎng)時(shí)間以前，我讀過(guò)一本關(guān)于 Kubernetes 的書(shū)，在介紹中他們規(guī)定了運(yùn)行 Kubernetes 開(kāi)始變得有意義的下限數(shù)字，我記得它從數(shù)百到數(shù)千開(kāi)始，盡管我無(wú)法找到那本確切的書(shū)了。）

讓我們快速了解一下 Kubernetes 的基礎(chǔ)概念。

圖片

（工作，Worker）節(jié)點(diǎn)

你的軟件（或者在 Kubernetes 術(shù)語(yǔ)中稱(chēng)為工作負(fù)載）必須在某個(gè)地方運(yùn)行，無(wú)論是虛擬機(jī)還是物理機(jī)器。在 Kubernetes 中，這個(gè)地方被稱(chēng)為節(jié)點(diǎn)（Node）。

此外，Kubernetes 部署和運(yùn)行容器：你好，Docker，我的老朋友！（注：Kubernetes 支持許多容器運(yùn)行時(shí)，包括containerd、CRI-O、Docker Engine等，盡管 Docker 是最常用的）

實(shí)際上，這并不完全正確。在 Kubernetes 的術(shù)語(yǔ)中，你部署（調(diào)度）Pods，一個(gè) Pod 包含一個(gè)或多個(gè)容器。

好吧，我們?cè)诠?jié)點(diǎn)上運(yùn)行Pods，但是誰(shuí)控制這些節(jié)點(diǎn)，以及你在這些節(jié)點(diǎn)上如何決定運(yùn)行什么呢？

（小貼士：一個(gè)小映射表）

控制平面

認(rèn)識(shí)控制平面。為簡(jiǎn)單起見(jiàn)，我們可以將其視為控制節(jié)點(diǎn)的一個(gè)組件（與其包含的大約 9472 個(gè)組件相對(duì)）。控制平面，除了其他許多功能…

• 讓你運(yùn)行調(diào)度你的應(yīng)用程序，即讓你將一個(gè) Pod 放到一個(gè)節(jié)點(diǎn)上。
• 檢查所有的 Pod 是否處于期望的狀態(tài)，例如它們是否響應(yīng)，或者其中一個(gè)是否需要重新啟動(dòng)？
• 實(shí)現(xiàn)每個(gè)工程師的幻想：“我們終于需要擴(kuò)展 10 倍了，讓我們快速啟動(dòng) n 個(gè)更多的 Pod！”

Pods 與 Nodes

如果Pods和Nodes之間的區(qū)別還有點(diǎn)不清楚。Kubernetes 有一個(gè)所謂的調(diào)度器。每當(dāng)調(diào)度器發(fā)現(xiàn)新的 Pod（== 容器（們））需要調(diào)度時(shí)（耶！），它會(huì)嘗試找到 Pod 的最佳節(jié)點(diǎn)。這意味著很有可能多個(gè) Pod 在同一節(jié)點(diǎn)上運(yùn)行，或者在不同節(jié)點(diǎn)上運(yùn)行。如果你想深入了解這個(gè)主題，你可能需要閱讀有關(guān) "節(jié)點(diǎn)選擇" 以及如何影響它的官方文檔。

集群 & 云

取多個(gè)節(jié)點(diǎn)和你的控制平面，你就有了一個(gè)集群。

取多個(gè)集群，你可以分隔你的開(kāi)發(fā)、測(cè)試和生產(chǎn)環(huán)境，或者團(tuán)隊(duì)、項(xiàng)目或不同類(lèi)型的應(yīng)用程序 - 這取決于你。

再進(jìn)一步，嘗試進(jìn)行多云 Kubernetes，跨越不同的私有和/或公有云平臺(tái)運(yùn)行多個(gè)集群（祝賀！你所取得的成就絕非易事。）

擴(kuò)展

還有許多Kubernetes 擴(kuò)展。

最重要的是，對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，有一個(gè)Web UI/Dashboard，你可以使用它來(lái)基本管理你的集群。

如果你沒(méi)有自托管你的 Kubernetes 設(shè)置，你可以簡(jiǎn)單地使用云供應(yīng)商提供的任何 UI，比如Google Cloud、AWS或其他眾多云供應(yīng)商提供的 UI。

請(qǐng)，讓我們停止 Kubernetes 101

上面的那四個(gè) 101 部分將（希望）為你提供足夠的心智模型，讓你開(kāi)始使用 Kubernetes，我們將在概念上結(jié)束。

說(shuō)實(shí)話(huà)，如果你在https://learning.oreilly.com上搜索 "Kubernetes"，你會(huì)感到震驚。你將獲得成千上萬(wàn)的學(xué)習(xí)資源結(jié)果，其中許多書(shū)籍都超過(guò) 500 頁(yè)長(zhǎng)。這對(duì)于一個(gè)下雨天的冬天是很好的閱讀！好消息是：作為開(kāi)發(fā)人員，你不必關(guān)心這些書(shū)中大多數(shù)內(nèi)容，這些書(shū)教你如何設(shè)置、維護(hù)和管理你的集群，盡管了解所有這些的復(fù)雜性是有幫助的。

我需要做什么才能看到所有這些在運(yùn)行中的情況？

• Kubernetes 安裝（我們稍后會(huì)更詳細(xì)地討論）
• YAML，YAML，YAML！
• 與你的 Kubernetes 集群交互的工具：kubectl

我從哪里獲取 kubectl？

你可以下載kubectl，這本質(zhì)上是用于與你的 Kubernetes 集群做任何你想做的事情的 CLI工具。該頁(yè)面列出了為你的特定操作系統(tǒng)安裝 kubectl 的各種方法。

我如何讀 kubectl？?

參見(jiàn)https://www.youtube.com/watch?v=9oCVGs2oz28。它的發(fā)音是 "Kube Control"。

kubectl 要如何工作？

你需要一個(gè)配置文件，一個(gè)名為 kubeconfig 的文件，它允許你訪問(wèn)你的 Kubernetes 集群。

默認(rèn)情況下，該文件位于~/.kube/config。值得注意的是，這個(gè)配置文件也被你喜愛(ài)的集成開(kāi)發(fā)環(huán)境（如IntelliJ IDEA）讀取，以正確設(shè)置其 Kubernetes 功能。

我從哪里獲取 kubeconfig 文件？

選項(xiàng) 1如果你正在使用托管的 Kubernetes 安裝（EKS、GKE、AKS），請(qǐng)查看相應(yīng)的文檔頁(yè)面。是的，只需點(diǎn)擊鏈接，我已經(jīng)為你鏈接到正確的頁(yè)面。簡(jiǎn)而言之，你將使用它們的 CLI 工具為你生成/下載該文件。

選項(xiàng) 2如果你本地安裝了Minikube，它將自動(dòng)為你創(chuàng)建一個(gè) kubeconfig 文件。

選項(xiàng) 3如果你碰巧知道你的 Kubernetes 主節(jié)點(diǎn)并可以通過(guò) SSH 登錄，運(yùn)行：cat /etc/kubernetes/admin.conf或cat ~/.kube/config

kubeconfig 文件還有其他需要知道的嗎？

一個(gè) kubeconfig 文件由傳統(tǒng)的 YAML 組成，它可以包含許多內(nèi)容（clusters、users、contexts）。對(duì)于有興趣的人，請(qǐng)查閱官方文檔。

目前，我們可以忽略 users 和 contexts，并且簡(jiǎn)化為 kubeconfig 文件包含你可以連接的集群，例如development或test。

以下是一個(gè)示例 kubeconfig 文件，摘自官方 Kubernetes 文檔。

（別擔(dān)心，你不必逐行理解這個(gè)文件，它只是為了讓你感受一下這些文件的樣子）

apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
- cluster:
    insecure-skip-tls-verify: true
    server: https://5.6.7.8
  name: test
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: test
    namespace: default
    user: experimenter
  name: exp-test
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file
- name: experimenter
  user:
    # Documentation note (this comment is NOT part of the command output).
    # Storing passwords in Kubernetes client config is risky.
    # A better alternative would be to use a credential plugin
    # and store the credentials separately.
    # See https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins
    password: some-password
    username: exp

Kubectl 101

你現(xiàn)在可以用 Kubectl 做什么呢？記住，一開(kāi)始我們說(shuō)你的目標(biāo)是擁有一個(gè) Pod（n+ 個(gè)容器），并在節(jié)點(diǎn)（服務(wù)器）上調(diào)度它（運(yùn)行它們）。

方法是將 yaml 文件（耶）帶有集群期望狀態(tài)的文件輸入到 kubectl 中，它將愉快地將你的集群設(shè)置為期望的狀態(tài)。

Pod 清單

例如，你可以創(chuàng)建一個(gè)名為marcocodes-pod.yaml的文件，內(nèi)容如下…

apiVersion: v1
kind: Pod
metadata:
  name: marcocodes-web
spec:
  containers:
    - image: gcr.io/marco/marcocodes:1.4
      name: marcocodes-web
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP

…并使用以下 kubectl 命令將其輸入到你的 Kubernetes 集群中：

kubectl apply -f marcocodes-pod.yaml

應(yīng)用這個(gè) yaml 文件會(huì)做什么呢？嗯，讓我們逐步了解：

Kubernetes 知道各種所謂的對(duì)象，Pod 是其中之一，你稍后會(huì)遇到其他對(duì)象。簡(jiǎn)單來(lái)說(shuō)，這個(gè) .yaml 文件描述了我們要部署的 Pod。

metadata:
  name: marcocodes-web

Kubernetes 中的每個(gè)對(duì)象，因此每個(gè) .yaml 文件都充滿(mǎn)了metadata標(biāo)簽。在這種情況下，我們?yōu)槲覀兊?pod 指定了名稱(chēng)，值為marcocodes_web。這個(gè) metadata 有什么用呢？簡(jiǎn)單來(lái)說(shuō)，Kubernetes 需要以某種方式唯一標(biāo)識(shí)集群中的資源：我是否已經(jīng)運(yùn)行了一個(gè)名稱(chēng)為marcocodes_web的 pod，還是我需要啟動(dòng)一個(gè)新的 pod？這就是 metadata 的作用。

spec:
  containers:
    - image: gcr.io/marco/marcocodes:1.4
      name: marcocodes-web
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP

你需要告訴 Kubernetes 你的 pod 應(yīng)該是什么樣的。記住，它可以是 n+ 個(gè)容器，因此你可以在 YAML 文件中指定容器的列表，盡管通常你只指定一個(gè)。

你將指定一個(gè)特定的 Docker 鏡像，包括其版本，并通過(guò) http 在該容器上暴露端口 8080。就是這樣。

這個(gè) yaml 文件到底發(fā)生了什么？

長(zhǎng)話(huà)短說(shuō)，當(dāng)你運(yùn)行 kubectl apply 時(shí)，你的 yaml 文件將被提交到 Kubernetes API 服務(wù)器，最終我們的 Kubernetes 系統(tǒng)將安排一個(gè) pod（帶有 marcocodes 1.4 容器）在我們集群中的一臺(tái)健康、可行的節(jié)點(diǎn)上運(yùn)行。

更技術(shù)性地說(shuō)，Kubernetes 有一個(gè)協(xié)調(diào)循環(huán)的概念，一個(gè)調(diào)度器能夠說(shuō)的花哨點(diǎn)的術(shù)語(yǔ)：

"這是我的當(dāng)前 Kubernetes 集群狀態(tài)，這是用戶(hù)的 yaml 文件，讓我協(xié)調(diào)這兩者。用戶(hù)想要一個(gè)新的 pod 嗎？我會(huì)創(chuàng)建它。用戶(hù)想要存儲(chǔ)嗎？我會(huì)將其附加到容器上，等等。

說(shuō)到存儲(chǔ)...

資源和卷

僅指定容器鏡像并不是你所能做的全部。首先，你可能想要處理容器的資源消耗：

# ....
spec:
  containers:
    - image: gcr.io/marco/marcocodes:1.4
      resources:
        requests:
          cpu: "500m"
          memory: "128Mi"
# ....

這確保你的容器至少獲得 500m（即 0.5）的 CPU 和 128 MB 的內(nèi)存（你還可以指定永遠(yuǎn)不可突破的上限）。

此外，當(dāng)一個(gè) pod 被刪除或容器重新啟動(dòng)時(shí)，容器文件系統(tǒng)中的數(shù)據(jù)也將被刪除。為了避免這種情況，你可能想要將數(shù)據(jù)存儲(chǔ)在持久卷上。

# ....
spec:
  volumes:
    - name: "marcocodes-data"
      hostPath:
        path: "/var/lib/marcocodes"
  containers:
    - image: gcr.io/marco/marcocodes:1.4
      name: marcocodes
      volumeMounts:
        - mountPath: "/data"
          name: "marcocodes-data"
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP
# ....

我們將擁有一個(gè)名為marcocodes-data的卷，它將被掛載到容器上的/data目錄下，并存在于主機(jī)機(jī)器上的/var/lib/marcocodes下。

有什么要注意的嗎？

你剛學(xué)到有 pod，它們由一個(gè)或多個(gè) Docker 鏡像組成，以及資源消耗規(guī)則和卷定義。

有了所有這些 YAML，我們成功地安排了一個(gè)單一的、靜態(tài)的、一次性的 pod。問(wèn)題來(lái)了：與僅運(yùn)行docker run -d --publish 8080:8080 gcr.io/marco/marcocodes:1.4相比，有何優(yōu)勢(shì)？

嗯，實(shí)際上目前并沒(méi)有。

這就是為什么我們需要更深入地了解ReplicaSet和Deployment概念的原因。

ReplicaSet

我們要謙卑一點(diǎn)。一開(kāi)始我們不需要自動(dòng)縮放，但擁有應(yīng)用程序的冗余實(shí)例和一些負(fù)載平衡會(huì)很不錯(cuò)，這樣我們的部署會(huì)顯得更專(zhuān)業(yè)，不是嗎？

Kubernetes 的ReplicaSet來(lái)拯救我們！

讓我們看一個(gè)定義了這樣一個(gè)最小 ReplicaSet 的marcocodes-replica.yaml文件。

apiVersion: apps/v1
kind: ReplicaSet
# metadata:
# ...
spec:
  replicas: 2
  selector: "you will learn this later"
  # ...
  template:
    metadata: "you will learn this later"
      # ...
    spec:
      containers:
        - name: marcocodes-web
          image: "gcr.io/marco/marcocodes:3.85"

我省略了這個(gè) YAML 文件中的很多行（和復(fù)雜性），但現(xiàn)在最有趣的是這兩個(gè)變化：

這個(gè) .yaml 現(xiàn)在描述的是一個(gè) ReplicaSet，而不再是一個(gè) Pod。

這是重點(diǎn)：我們希望始終有 2 個(gè)副本 == pod 在任何給定的時(shí)間運(yùn)行。如果我們?cè)谶@里填入 10，Kubernetes 將確保同時(shí)運(yùn)行 10 個(gè) pod。

當(dāng)我們現(xiàn)在應(yīng)用這個(gè) .yaml 文件...

kubectl apply -f marcocodes-rs.yaml

Kubernetes 將從 Kubernetes API 獲取一個(gè) Pod 清單（并根據(jù)metadata過(guò)濾結(jié)果），根據(jù)返回的 pod 數(shù)量，Kubernetes 將啟動(dòng)或停止額外的副本。就是這么簡(jiǎn)單。

ReplicaSet：總結(jié)

ReplicaSet幾乎是你想要的，但它們存在一個(gè)問(wèn)題：它們與特定版本的容器鏡像綁定（在我們的例子中為 3.85），而這些實(shí)際上不應(yīng)該更改。而且 ReplicaSets 也不能幫助你完成軟件的滾動(dòng)發(fā)布過(guò)程（考慮零停機(jī)時(shí)間）。

因此，我們需要一個(gè)新的概念來(lái)幫助我們管理新版本的發(fā)布。見(jiàn)識(shí)一下：Deployment（部署）。

apiVersion: apps/v1
kind: Deployment
metadata: "ignore for now"
  # ...
spec:
  progressDeadlineSeconds: 600
  replicas: 2
  revisionHistoryLimit: 10
  selector: "ignore for now"
    # ...
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
     "ignore for now"
    # ...

你還需要學(xué)習(xí) Deployments 的其他 92387 個(gè) YAML 鍵值對(duì)，而我們已經(jīng)在本文中進(jìn)行了相當(dāng)長(zhǎng)時(shí)間的探討。其要點(diǎn)是：Kubernetes 允許你使用不同的軟件發(fā)布策略（rollingUpdate或recreate）。

• Recreate（重新創(chuàng)建）將終止所有舊版本的 pod，并使用新版本重新創(chuàng)建它們：這會(huì)導(dǎo)致用戶(hù)經(jīng)歷停機(jī)時(shí)間。
• RollingUpdate（滾動(dòng)更新）將在仍然通過(guò)舊 pod 提供流量的情況下執(zhí)行更新，因此通常更受青睞。

K8s 的靜態(tài)本質(zhì)

請(qǐng)注意，到目前為止，你所看到的一切基本上是靜態(tài)的。你有 YAML 文件，即使使用上面的 Deployment 對(duì)象，如果你有一個(gè)新版本的容器，你需要編輯 .yaml 文件，保存并應(yīng)用它 - 這涉及相當(dāng)多的手動(dòng)工作。

如果你希望事情變得更加動(dòng)態(tài)，你將需要使用額外的工具，比如https://helm.sh/，我們將在下面討論。

滾動(dòng)更新：過(guò)于美好而不真實(shí)

雖然我們正在談?wù)摬渴鹑萜鞯男掳姹?..

一如既往，魔鬼在細(xì)節(jié)中。滾動(dòng)更新在 Kubernetes 存在之前很久就已經(jīng)完成了，即使只是批處理腳本觸發(fā) SSH 命令。

坦率地說(shuō)，問(wèn)題并不是能夠關(guān)閉并啟動(dòng)應(yīng)用程序的新實(shí)例，而是在短時(shí)間內(nèi)（在部署期間）你的應(yīng)用程序基本上需要優(yōu)雅地支持兩個(gè)應(yīng)用程序版本 - 這總是一個(gè)有趣的問(wèn)題，特別是涉及數(shù)據(jù)庫(kù)或前后端 API 之間進(jìn)行了重大重構(gòu)的情況。

因此，請(qǐng)注意營(yíng)銷(xiāo)材料，它們向你推銷(xiāo)簡(jiǎn)單的滾動(dòng)更新 - 它們真正的挑戰(zhàn)與 Kubernetes 無(wú)關(guān)。

附注：自愈能力

在類(lèi)似的背景下，同樣適用于“self-healing”（自愈）一詞。Kubernetes 能夠執(zhí)行健康檢查，然后終止無(wú)響應(yīng)的 pod，安排啟動(dòng)一個(gè)新的。這也是某種形式上一直存在的功能。你喜歡的 Linux 發(fā)行版本質(zhì)上一直能夠通過(guò)各種方式監(jiān)視并重新啟動(dòng)服務(wù) - 盡管限于當(dāng)前機(jī)器。

Kubernetes 不能自動(dòng)處理錯(cuò)誤的數(shù)據(jù)庫(kù)遷移導(dǎo)致的應(yīng)用程序錯(cuò)誤，然后通過(guò)神奇的方式自愈集群，即修復(fù)損壞的數(shù)據(jù)庫(kù)列。

我只是覺(jué)得關(guān)于自愈系統(tǒng)的討論通常在某種程度上含有后者的意味（也許在管理層之間），而實(shí)際上它是更基本的功能。

服務(wù)發(fā)現(xiàn)、負(fù)載均衡和 Ingress

到目前為止，我們討論了動(dòng)態(tài)生成 pod，但從未討論過(guò)網(wǎng)絡(luò)流量如何實(shí)際到達(dá)你的應(yīng)用程序。Kubernetes 本質(zhì)上是動(dòng)態(tài)的，這意味著你可以在任何時(shí)候生成新的 pod 或關(guān)閉它們。

Kubernetes 有一些概念可以幫助你解決這個(gè)問(wèn)題，從 Service 對(duì)象（允許將集群的部分暴露給外部）到 Ingress 對(duì)象（允許進(jìn)行 HTTP 負(fù)載均衡）。同樣，這將涉及大量的 YAML 和相當(dāng)多的閱讀，但在一天結(jié)束時(shí)，Kubernetes 允許你將應(yīng)用程序接收到的任何流量路由到你的集群，反之亦然。

（有趣的 Ingress 事實(shí)：您將需要安裝 Ingress 控制器（Kubernetes 沒(méi)有內(nèi)置標(biāo)準(zhǔn)控制器），它將為您執(zhí)行負(fù)載平衡。選擇很多：在像 AWS 這樣的平臺(tái)上，您可以簡(jiǎn)單地使用 ELB，如果使用裸金屬 Kubernetes，則可以使用Contour，等等。）

最后但同樣重要的是：ConfigMap 和 Secret 管理

除了您已經(jīng)看到 Kubernetes 執(zhí)行的各種任務(wù)之外，您還可以使用它存儲(chǔ)配置鍵值對(duì)，以及秘密（考慮數(shù)據(jù)庫(kù)或 API 憑據(jù)）。

（默認(rèn)情況下，Secrets 以未加密的形式存儲(chǔ)，因此有必要遵循此頁(yè)面上“安全使用 Secrets” 部分的建議，甚至可以完全插入外部 Secrets 存儲(chǔ)，從 AWS、GCP 和 Azure 的解決方案到HashiCorp 的 Vault。）

夠了！這些 YAML 文件難道不會(huì)變得混亂嗎？

嗯...如果您考慮使用 Kubernetes 部署WordPress等應(yīng)用，那么您將需要一個(gè) Deployment，以及一個(gè)ConfigMap和可能還有Secret。然后還有一些其他服務(wù)和我們尚未涉及的對(duì)象。這意味著，您最終將得到成千上萬(wàn)行的 YAML。這并不是本質(zhì)上的混亂，但在這個(gè)小階段，已經(jīng)涉及了大量的 DevOps 復(fù)雜性。

然而，您也是一名開(kāi)發(fā)人員，希望不一定是那位在維護(hù)這些文件的人。

只要有需要，使用你的 IDE 的 Kubernetes 支持（在我這里是IntelliJ IDEA）對(duì) Helm charts、Kustomize 文件等進(jìn)行編碼支持，會(huì)極大地幫助你。哦，我們還沒(méi)有談?wù)撨^(guò)它們。讓我們來(lái)談?wù)?。這里有一段視頻，會(huì)讓你迅速了解IntelliJ 的 Kubernetes 插件。

Kubernetes：附加主題

什么是 Helm？Helm Chart 又是什么？

你可以把 Helm 想象成 Kubernetes 的包管理器。讓我們了解一些概念：

正如我們上面提到的，僅僅在 Kubernetes 集群中安裝 WordPress 就會(huì)導(dǎo)致成千上萬(wàn)行的 YAML 代碼。如果你不必親自編寫(xiě)這些 YAML 代碼，而是可以使用預(yù)先構(gòu)建的軟件包，途中只需替換一些變量，那將是非常好的。

這就是Helm Chart，一堆 YAML 文件和模板，按照特定的目錄結(jié)構(gòu)布局。當(dāng)你開(kāi)始安裝一個(gè)特定的 chart 時(shí)，Helm 將下載它，解析它的模板，并與你的值一起生成經(jīng)典的 Kubernetes YAML 文件/清單，然后將其發(fā)送到你的 Kubernetes。

以下是一個(gè)這種模板文件的小片段（用于 Deployment 清單），包括一些占位符：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myChart.name" . }}
  labels:
    {{- include "myChart.labels" . | nindent 4 }}

你可以將這些 chart 分享到倉(cāng)庫(kù)中。并沒(méi)有單一的默認(rèn) chart 倉(cāng)庫(kù)。一個(gè)查找流行 chart 倉(cāng)庫(kù)的好地方是https://artifacthub.io/。

簡(jiǎn)而言之，使用 Helm 的工作流程如下：

1. 安裝 Helm 客戶(hù)端
2. 安裝你喜歡的 chart - 第一部分

helm install my-release oci://registry-1.docker.io/bitnamicharts/wordpress

這條命令會(huì)從流行的 bitnami chart 倉(cāng)庫(kù)安裝 wordpress chart 到你的集群，最終結(jié)果是一個(gè)運(yùn)行中的 WordPress 安裝。如果你想知道 OCI 是什么：你可以將 Helm charts 托管在支持Open Containers Initiative標(biāo)準(zhǔn)的容器 Registry 中（比如 Amazon ECR、Docker Hub、Artifactory 等）。

3. 安裝你喜歡的 chart - 第二部分

由于幾乎總是需要覆蓋一些配置值（在 WordPress 的情況下，可以在這里查看參數(shù)的巨大列表），你會(huì)想要向安裝命令提供你的具體值。你可以通過(guò)一個(gè)命名為 values.yaml 的 YAML 文件傳遞值，或者直接使用命令行標(biāo)志。因此，安裝命令可能會(huì)像這樣：

helm install my-release oci://registry-1.docker.io/bitnamicharts/wordpress --values values.yaml


// OR
helm install my-release oci://registry-1.docker.io/bitnamicharts/wordpress --set wordpressUsername=m4rc0 // etc...

4. 注意：你還可以使用 helm 來(lái)升級(jí)你的安裝。可以升級(jí)到 chart 的新版本（考慮新的發(fā)布），或者通過(guò)helm upgrade命令升級(jí)安裝的配置。

如果你想深入了解 Helm，我強(qiáng)烈推薦你閱讀《學(xué)習(xí) Helm》一書(shū)。

什么是 Kustomize？

在前文中，你了解到 Helm 使用模板生成 Kubernetes 清單。這意味著有人需要將 Kubernetes 清單制作成 Helm 模板，進(jìn)行維護(hù)，然后作為最終用戶(hù)，你可以使用 helm 命令行客戶(hù)端來(lái)應(yīng)用它們。

Kustomize的開(kāi)發(fā)人員選擇了不同的路徑：它允許你通過(guò)將額外的更改層疊在原始清單之上來(lái)創(chuàng)建清單的自定義版本。因此，與其創(chuàng)建模板并在其中放置 "占位符"，你最終會(huì)得到一個(gè)文件結(jié)構(gòu)，例如：

├── deployment.yaml   // your original Kubernetes manifest filef
└── kustomization.yaml //


// (in more relalistic scenarios, you'deven have 'overlays' subfolders for different environments, like development/staging/prod etc

然后，你可以運(yùn)行kustomize build，以便 Kustomize 應(yīng)用你的覆蓋層，并渲染最終的 YAML 結(jié)果，你可以直接輸入kubectl命令（或直接運(yùn)行kubectl apply -k）。

kustomize build . | kubectl apply -f -

如果你想了解 kustomization.yaml 文件需要如何結(jié)構(gòu)化，可以查看這里。

哪個(gè)更好：Helm 還是 Kustomize？

我們都喜歡 Reddit 上的意見(jiàn)，盡管有爭(zhēng)議：https://www.reddit.com/r/kubernetes/comments/w9xug9/helm_vs_kustomize/。

什么是 Terraform 以及與 Kubernetes 的區(qū)別是什么？

感謝上帝，我們接近本指南的結(jié)束，我不必再在 Terraform 上花費(fèi)另外一千字（提示：一如既往，你會(huì)在 Terraform 上找到很多書(shū)籍和學(xué)習(xí)資源），所以我會(huì)盡量簡(jiǎn)短：

Kubernetes 是關(guān)于容器編排的。"讓我告訴你我在這個(gè) YAML 文件中想要的：為我運(yùn)行我的容器！"

Terraform 是關(guān)于基礎(chǔ)設(shè)施的創(chuàng)建： "讓我告訴你我在這些 HashiCorp 配置語(yǔ)言（HCL，.tf）文件中想要的！請(qǐng)為我創(chuàng)建五個(gè)服務(wù)器，幾個(gè)負(fù)載均衡器，兩個(gè)數(shù)據(jù)庫(kù)，幾個(gè)隊(duì)列，以及例如我選擇的云中的監(jiān)控設(shè)施。" 或者："請(qǐng)為我在 AWS 上設(shè)置這些 Kubernetes 集群（EKS）"。

我如何在本地使用 Kubernetes 進(jìn)行開(kāi)發(fā)？

對(duì)于本地開(kāi)發(fā)，你基本上有兩個(gè)選擇。

你可以運(yùn)行一個(gè)本地的 Kubernetes 集群，并將你的應(yīng)用程序部署到其中。你可能會(huì)使用Minikube來(lái)實(shí)現(xiàn)這一點(diǎn)。由于整個(gè) "我的應(yīng)用程序發(fā)生了變化 - 現(xiàn)在讓我們構(gòu)建一個(gè)容器鏡像 - 然后讓我們將其部署到我的集群" 這個(gè)流程手動(dòng)執(zhí)行起來(lái)相當(dāng)繁瑣，因此你可能還想使用類(lèi)似Skaffold的工具來(lái)幫助你。查看這個(gè)教程以了解如何開(kāi)始使用這個(gè)工作流。盡管這種設(shè)置是有效的，但它伴隨著相當(dāng)多的復(fù)雜性和/或資源消耗。

這就是第二種選擇，解決方案的地方。對(duì)于本地開(kāi)發(fā)，你基本上會(huì)忽略 Kubernetes，將你需要的任何配置克隆到你自己的 docker-compose.yml 文件中，然后簡(jiǎn)單地運(yùn)行它。這是一個(gè)更簡(jiǎn)單的設(shè)置，但它的缺點(diǎn)是必須維護(hù)兩套配置（docker-compose.yml + 你的 K8s 清單文件）。

如果您已經(jīng)在使用 Kubernetes，請(qǐng)?jiān)谙旅娴脑u(píng)論部分告訴我您是如何處理本地開(kāi)發(fā)的。

我真的需要所有這些嗎？

這是一個(gè)很好的問(wèn)題，現(xiàn)在是撒些真實(shí)的 Kubernetes 軼事的絕佳時(shí)機(jī)：系統(tǒng)管理員限制資源以至于 Pod 的啟動(dòng)時(shí)間變得非常長(zhǎng) - 長(zhǎng)到它們被標(biāo)記為不健康并被終止，導(dǎo)致無(wú)休止的 Pod 創(chuàng)建和終止循環(huán)，但我們將長(zhǎng)篇的解釋留到另一個(gè)時(shí)候。

作為開(kāi)發(fā)者，通常您無(wú)法決定，但以下是大局觀：

正如本文早些時(shí)候提到的，關(guān)于僅“托管” Kubernetes 集群的學(xué)習(xí)材料是無(wú)窮無(wú)盡的，我們不僅僅是在談?wù)撛诼憬饘偕线M(jìn)行“自托管”，還有使用任何托管 Kubernetes 變體的情況。如果您有內(nèi)部專(zhuān)業(yè)知識(shí)：

• 處理所有這些額外的復(fù)雜性
• 您可以向所有開(kāi)發(fā)人員更詳細(xì)地解釋本文中描述的所有概念
• 而且首先而且首要的是您確實(shí)有管理數(shù)百或數(shù)千個(gè)容器的合法需求（不，不算神奇的突然擴(kuò)展需求） - 那就選擇 Kubernetes 吧。但我相信很多公司通過(guò)采用更簡(jiǎn)單的方法而不是幻想擁有 Google 規(guī)模的基礎(chǔ)架構(gòu)挑戰(zhàn)，可以節(jié)省大量的時(shí)間、金錢(qián)和壓力。

常見(jiàn)的 Kubectl 命令

如果有任何對(duì)開(kāi)發(fā)人員可能需要的kubectl命令感興趣的話(huà)，請(qǐng)?jiān)谙旅媪粞?，我?huì)將最常用的命令添加到這里，作為一個(gè)整齊分組/排序的列表。

為什么 Kubernetes 被縮寫(xiě)為 K8s

我想你可能現(xiàn)在已經(jīng)忘記了！這里是直接摘自 Kubernetes 文檔的一段引用：

“Kubernetes 的名稱(chēng)源自希臘語(yǔ)，意為舵手或領(lǐng)航員。K8s 作為縮寫(xiě)是因?yàn)樵凇癒”和“s”之間有八個(gè)字母。Google 在2014年開(kāi)源了 Kubernetes 項(xiàng)目?！?/p>

結(jié)束語(yǔ)

到目前為止，您應(yīng)該對(duì) Kubernetes 有了相當(dāng)好的概述。反饋、更正和隨機(jī)的意見(jiàn)都是受歡迎的！只需在下面留下評(píng)論。

感謝閱讀。

下一個(gè)版本的計(jì)劃

在評(píng)論部分投票，如果您希望以下任何一項(xiàng)或所有這些都發(fā)生：

• 提供復(fù)制粘貼命令 * K8s 文件，以便讀者可以跟隨操作
• 可能的：kubectl 命令
• 可能的：Kubernetes vs Docker Compose 并排配置的示例
• 可能的：GitOps
• 建議：使用 Kubectl/K9s/Lens IDE 或 IntelliJ Kubernetes 插件連接到 Kubernetes
• 建議：使用 Istio 的服務(wù)網(wǎng)格 - 在處理微服務(wù)時(shí)的常見(jiàn)用例。

致謝與參考

感謝 Maarten Balliauw、Andreas Eisele、Andrei Efimov、Anton Aleksandrov、Garth Gilmour、Marit van Dijk、Paul Everitt、Mukul Mantosh 的評(píng)論、更正和討論。特別感謝《Getting Started with Kubernetes》和《Learning Helm》的作者們。