開發(fā)者的Kubernetes懶人指南

作者：岱軍 2024-02-01 09:37:42

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

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

譯自Kubernetes for Lazy Developers。作者 marcobehler 。

介紹

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

快速問題：為什么將 Kubernetes 縮寫為 K8s？

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

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

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

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

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

java -jar myNewAIStartup.jar

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

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

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

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

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

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

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

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

Docker、Docker Compose和Swarm：回顧

向Docker致敬！

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

你將源代碼構(gòu)建為可部署的文件，例如jar文件。
你另外構(gòu)建一個新的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)用程序制作成了一個 Docker 鏡像。但是這個 Docker 鏡像最終是如何在目標(biāo)部署服務(wù)器上運(yùn)行的呢？

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

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

docker login mysupersecret.registry.com

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

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


//....
SUCCESS!

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

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

Docker Compose 來拯救。你將在一個傳統(tǒng)而又經(jīng)典的 YAML 文件，即compose.yaml文件中定義所有服務(wù)及其之間的依賴關(guān)系（運(yùn)行這個或那個先）。以下是一個定義兩個服務(wù)的示例，一個是 Web 服務(wù)，另一個是 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，整個環(huán)境（由所有獨(dú)立服務(wù)在單獨(dú)的 Docker 容器中運(yùn)行組成）將被啟動。請注意，這意味著所有容器將在同一臺機(jī)器上運(yùn)行。如果要將其擴(kuò)展到多臺機(jī)器上，您將需要使用Docker Swarm。

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

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

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

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

那么我為什么需要 Kubernetes 呢？

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

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

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

圖片

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

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

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

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

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

（小貼士：一個小映射表）

非 Kubernetes	Kubernetes 術(shù)語
軟件/應(yīng)用	工作負(fù)載
機(jī)器	節(jié)點(diǎn)
（1-多個）容器	Pod
部署	調(diào)度

控制平面

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

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

Pods 與 Nodes

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

集群 & 云

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

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

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

擴(kuò)展

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

最重要的是，對于開發(fā)人員來說，有一個Web UI/Dashboard，你可以使用它來基本管理你的集群。

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

請，讓我們停止 Kubernetes 101

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

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

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

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

我從哪里獲取 kubectl？

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

我如何讀 kubectl？?

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

kubectl 要如何工作？

你需要一個配置文件，一個名為 kubeconfig 的文件，它允許你訪問你的 Kubernetes 集群。

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

我從哪里獲取 kubeconfig 文件？

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

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

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

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

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

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

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

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

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 做什么呢？記住，一開始我們說你的目標(biāo)是擁有一個 Pod（n+ 個容器），并在節(jié)點(diǎn)（服務(wù)器）上調(diào)度它（運(yùn)行它們）。

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

Pod 清單

例如，你可以創(chuàng)建一個名為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)用這個 yaml 文件會做什么呢？嗯，讓我們逐步了解：

Kubernetes 知道各種所謂的對象，Pod 是其中之一，你稍后會遇到其他對象。簡單來說，這個 .yaml 文件描述了我們要部署的 Pod。

metadata:
  name: marcocodes-web

Kubernetes 中的每個對象，因此每個 .yaml 文件都充滿了metadata標(biāo)簽。在這種情況下，我們?yōu)槲覀兊?pod 指定了名稱，值為marcocodes_web。這個 metadata 有什么用呢？簡單來說，Kubernetes 需要以某種方式唯一標(biāo)識集群中的資源：我是否已經(jīng)運(yùn)行了一個名稱為marcocodes_web的 pod，還是我需要啟動一個新的 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+ 個容器，因此你可以在 YAML 文件中指定容器的列表，盡管通常你只指定一個。

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

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

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

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

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

說到存儲...

資源和卷

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

# ....
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)一個 pod 被刪除或容器重新啟動時，容器文件系統(tǒng)中的數(shù)據(jù)也將被刪除。為了避免這種情況，你可能想要將數(shù)據(jù)存儲在持久卷上。

# ....
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
# ....

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

有什么要注意的嗎？

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

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

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

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

ReplicaSet

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

Kubernetes 的ReplicaSet來拯救我們！

讓我們看一個定義了這樣一個最小 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"

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

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

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

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

kubectl apply -f marcocodes-rs.yaml

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

ReplicaSet：總結(jié)

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

因此，我們需要一個新的概念來幫助我們管理新版本的發(fā)布。見識一下：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 個 YAML 鍵值對，而我們已經(jīng)在本文中進(jìn)行了相當(dāng)長時間的探討。其要點(diǎn)是：Kubernetes 允許你使用不同的軟件發(fā)布策略（rollingUpdate或recreate）。

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

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

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

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

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

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

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

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

因此，請注意營銷材料，它們向你推銷簡單的滾動更新 - 它們真正的挑戰(zhàn)與 Kubernetes 無關(guān)。

附注：自愈能力

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

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

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

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

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

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

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

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

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

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

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

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

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

Kubernetes：附加主題

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

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

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

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

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

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

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

簡而言之，使用 Helm 的工作流程如下：

安裝 Helm 客戶端
安裝你喜歡的 chart - 第一部分

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

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

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

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

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...

注意：你還可以使用 helm 來升級你的安裝?？梢陨壍?chart 的新版本（考慮新的發(fā)布），或者通過helm upgrade命令升級安裝的配置。

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

什么是 Kustomize？

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

Kustomize的開發(fā)人員選擇了不同的路徑：它允許你通過將額外的更改層疊在原始清單之上來創(chuàng)建清單的自定義版本。因此，與其創(chuàng)建模板并在其中放置 "占位符"，你最終會得到一個文件結(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)化，可以查看這里。

哪個更好：Helm 還是 Kustomize？

我們都喜歡 Reddit 上的意見，盡管有爭議：https://www.reddit.com/r/kubernetes/comments/w9xug9/helm_vs_kustomize/。

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

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

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

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

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

對于本地開發(fā)，你基本上有兩個選擇。

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

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

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

我真的需要所有這些嗎？

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

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

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

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

常見的 Kubectl 命令

如果有任何對開發(fā)人員可能需要的kubectl命令感興趣的話，請?jiān)谙旅媪粞裕視⒆畛Ｓ玫拿钐砑拥竭@里，作為一個整齊分組/排序的列表。

為什么 Kubernetes 被縮寫為 K8s

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

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

結(jié)束語

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

感謝閱讀。

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

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

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

致謝與參考

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

責(zé)任編輯：武曉燕來源：云云眾生s