摘要：簡稱，是在年發(fā)布的一個(gè)開源項(xiàng)目。網(wǎng)絡(luò)要能夠通信，必須部署網(wǎng)絡(luò)，是其中一個(gè)可選方案。最常使用，可以管理多個(gè)副本，并確保按照期望的狀態(tài)運(yùn)行，底層調(diào)用。用于每個(gè)最多只運(yùn)行一個(gè)副本的場景。

Kubernetes 簡稱 k8s，是 google 在 2014 年發(fā)布的一個(gè)開源項(xiàng)目。

Kubernetes 解決了哪些問題？

真實(shí)的生產(chǎn)環(huán)境應(yīng)用會(huì)包含多個(gè)容器，而這些容器還很可能會(huì)跨越多個(gè)服務(wù)器主機(jī)部署。Kubernetes 提供了為那些工作負(fù)載大規(guī)模部署容器的編排與管理能力。Kubernetes 編排讓你能夠構(gòu)建多容器的應(yīng)用服務(wù)，在集群上調(diào)度或伸縮這些容器，以及管理它們隨時(shí)間變化的健康狀態(tài)。

kubernetes 基礎(chǔ)

kubernetes 優(yōu)化

kubernetes 實(shí)戰(zhàn)

Kubernetes 基礎(chǔ)概念很多，第一次接觸容易看暈，如果是新手，建議直接看實(shí)戰(zhàn)部分，先跑起來再說。

k8s 中有幾個(gè)重要概念。

Cluster 代表一個(gè) k8s 集群，是計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源的集合，k8s 利用這些資源運(yùn)行各種基于容器的應(yīng)用。

Master 是 cluster 的大腦，運(yùn)行著的服務(wù)包括 kube-apiserver、kube-scheduler、kube-controller-manager、etcd 和 pod 網(wǎng)絡(luò)。

kube-apiserver

apiserver 是 k8s cluster 的前端接口，提供 restful api。各種客戶端工具以及 k8s 其他組件可以通過它管理 cluster 中的各種資源。

kube-scheduler

負(fù)責(zé)決定將 pod 放在哪個(gè) node 上運(yùn)行，scheduler 在調(diào)度時(shí)會(huì)充分考慮 cluster 中各個(gè)節(jié)點(diǎn)的負(fù)載，以及應(yīng)用對高可用、性能、數(shù)據(jù)親和性的需求。

kube-controller-manager

負(fù)責(zé)管理 cluster 各種資源，保證資源處理預(yù)期狀態(tài)。controller-manager 由多種 controller 組成，包括 replication controller，endpoint controller，namespace controller，serviceaccount controller 等。

不同的 controller 管理不同的資源，例如：replication controller 管理 deployment ，statefulset，damonset 的生命周期，namespace controller 資源管理 namespace 資源。

etcd（分布式 key-value 存儲(chǔ)庫）

負(fù)責(zé)保存 cluster 的配置信息和各種資源的狀態(tài)信息。當(dāng)數(shù)據(jù)發(fā)生變化時(shí)，etcd 會(huì)快速地通知 k8s 相關(guān)組件。

pod 網(wǎng)絡(luò)

pod 要能夠通信，cluster 必須部署 pod 網(wǎng)絡(luò)，flannel 是其中一個(gè)可選方案。

Node 節(jié)點(diǎn) 是 pod 運(yùn)行的地方。node 節(jié)點(diǎn)上運(yùn)行的 k8s 組件有 kubelet、kube-proxy 和 pod 網(wǎng)絡(luò)。

kubelet

kubelet 是 node 節(jié)點(diǎn)的代理，當(dāng) master 節(jié)點(diǎn)中 kube-scheduler 確定在某個(gè) node 節(jié)點(diǎn)上運(yùn)行 pod 后，會(huì)將 pod 的具體配置信息發(fā)送給該節(jié)點(diǎn)的 kubelet，kubelet 根據(jù)這些信息創(chuàng)建和運(yùn)行容器，并向 master 節(jié)點(diǎn)報(bào)告運(yùn)行狀態(tài)。

kube-proxy

每個(gè) node 節(jié)點(diǎn)都會(huì)運(yùn)行 kube-proxy 服務(wù)，它負(fù)責(zé)將訪問 service 的請求轉(zhuǎn)發(fā)到后端的容器。如果有多個(gè)副本，kube-proxy 會(huì)實(shí)現(xiàn)負(fù)載均衡。

pod 網(wǎng)絡(luò)

pod 要能夠相互通信，k8s cluster 必須部署 pod 網(wǎng)絡(luò)，flannel 是其中一個(gè)可選方案。

每一個(gè) pod 包含一個(gè)或多個(gè) container，pod 中的容器作為一個(gè)整體被 master 調(diào)度到 node 節(jié)點(diǎn)上運(yùn)行。

為什么 k8s 使用 pod 管理容器，而不是直接操作容器？

1、因?yàn)橛行┤萜魈焐褪切枰o密的聯(lián)系，放在一個(gè) pod 中表示一個(gè)完整的服務(wù)，k8s 同時(shí)會(huì)在每個(gè) pod 中加入 pause 容器，來管理內(nèi)部容器組的狀態(tài)。

2、Pod 中的所有容器共享 ip，共享 volume，方便進(jìn)行容器之間通信和數(shù)據(jù)共享。

什么時(shí)候需要在 pod 中定義多個(gè)容器？

答：這些容器聯(lián)系非常緊密，而且需要直接共享資源，例如一個(gè)爬蟲程序，和一個(gè) web server 程序。web server 強(qiáng)烈依賴爬蟲程序提供數(shù)據(jù)支持。

Label 是一個(gè) key = value 的鍵值對，其中 key 和 value 都由用戶自己指定。

Label 的使用場景：

kube-controller

通過 label selecter 篩選出要監(jiān)控的 pod 副本，使 pod 副本數(shù)量符合預(yù)期。

kube-proxy

通過 label selecter 選擇對應(yīng)的 pod，自動(dòng)建立每個(gè) service 到對應(yīng) pod 的請求轉(zhuǎn)發(fā)路由表，從而實(shí)現(xiàn) service 的智能負(fù)載均衡機(jī)制。

通過對 node 定義 label，在 pod 中使用 node selector 匹配，kube-scheduler 進(jìn)程可以實(shí)現(xiàn) pod 定向調(diào)度的特性。

總之，label 可以給對象創(chuàng)建多組標(biāo)簽，label 和 label selecter 共同構(gòu)建了 k8s 系統(tǒng)中核心的應(yīng)用模型，使得被管理對象能夠被精細(xì)地分組管理，同時(shí)實(shí)現(xiàn)了整個(gè)集群的高可用性。

k8s 通常不會(huì)直接創(chuàng)建 pod，而是通過 controller 來管理 pod。controller 中定義了 pod 的部署特性，比如有幾個(gè)副本，在什么樣的 node 上運(yùn)行等。為了滿足不同的業(yè)務(wù)場景，k8s 提供了多種類型的 controller。

Deployment

最常使用，可以管理 pod 多個(gè)副本，并確保 pod 按照期望的狀態(tài)運(yùn)行，底層調(diào)用 ReplicaSet。

ReplicaSet

實(shí)現(xiàn) pod 的多副本管理，通常使用 Deployment 就夠了。

DaemonSet

用于每個(gè) node 最多只運(yùn)行一個(gè) pod 副本的場景。

使用場景

在集群的每個(gè)節(jié)點(diǎn)上運(yùn)行存儲(chǔ) Daemon，比如 glusterd 或 ceph。

在每個(gè)節(jié)點(diǎn)上運(yùn)行日志搜集 Daemon，比如 flunentd 或 logstash。

在每個(gè)節(jié)點(diǎn)上運(yùn)行監(jiān)控，比如 Prometheus Node Exporter 或 collected。

StatefuleSet

能夠保證 pod 的每個(gè)副本在整個(gè)生命周期中名稱是不變的，而其他 controller 不提供這個(gè)功能。

Job

用于運(yùn)行結(jié)束就刪除的應(yīng)用，而其他 controller 中的 pod 通常是長期持續(xù)運(yùn)行。

提示
使用 deployment controller 創(chuàng)建的用例，如果出現(xiàn)有 pod 掛掉的情況，會(huì)自動(dòng)新建一個(gè) pod，來維持配置中的 pod 數(shù)量。

容器按照持續(xù)運(yùn)行時(shí)間可分為兩類：服務(wù)類容器和工作類容器。

服務(wù)類容器通常持續(xù)提供服務(wù)，需要一直運(yùn)行，比如 http server。工作類容器則是一次性任務(wù)，比如批處理程序，完成后容器就退出。

Controller 中 deployment、replicaSet 和 daemonSet 類型都用于管理服務(wù)類容器，對于工作類容器，我們使用 job。

Service 是可以訪問一組 pod 的策略，通常稱為微服務(wù)。具體訪問哪一組 pod 是通過 label 匹配出來的。service 為 pod 提供了負(fù)載均衡，原理是使用 iptables。

為什么要用 service ？

pod 是有生命周期的，它們可以被創(chuàng)建，也可以被銷毀，然而一旦被銷毀生命就永遠(yuǎn)結(jié)束。而 pod 在一個(gè) k8s 集群中可能經(jīng)常性的創(chuàng)建，銷毀，每一次重建都會(huì)產(chǎn)生一個(gè)新的 ip 地址。

service 從邏輯上代表了一組 pod，具體是哪些 pod 是由 label 來挑選的。service 有自己的 ip，而且這個(gè) ip 是不變的，客戶端只需要訪問 service 的 ip，k8s 則負(fù)責(zé)建立和維護(hù) service 與 pod 的映射關(guān)系，無論 pod 如何變化，對客戶端不會(huì)有任何影響，因?yàn)?service 沒有變。

外網(wǎng)如何訪問 service？

ClusterIP：通過集群的內(nèi)部 ip 暴露服務(wù)，選擇該值，服務(wù)只能夠在集群內(nèi)部可以訪問，這也是默認(rèn)的 ServiceType。

NodePort：通過每個(gè) node 上的 ip 和端口（NodePort）暴露服務(wù)。NodePort 服務(wù)會(huì)路由到 ClusterIP 服務(wù)，這個(gè) ClusterIP 服務(wù)會(huì)自動(dòng)創(chuàng)建。通過請求 nodeip:nodeport，可以從集群的外部訪問一個(gè) service 服務(wù)。

LoadBalancer：使用云提供商的負(fù)載局衡器，可以向外部暴露服務(wù)。外部的負(fù)載均衡器可以路由到 NodePort 服務(wù)和 ClusterIP 服務(wù)。

ExternalName：通過返回 CNAME 和它的值，可以將服務(wù)映射到 externalName 字段的內(nèi)容（例如， foo.bar.example.com）。 沒有任何類型代理被創(chuàng)建，這只有 k8s 1.7 或更高版本的 kube-dns 才支持。

如果有多個(gè)用戶使用同一個(gè) k8s cluster，如何將他們創(chuàng)建的 controller，pod 等資源分開呢？

答：使用 namespace。

如果將物理的 cluster 邏輯上劃分成多個(gè)虛擬 cluster，每個(gè) cluster 就是一個(gè) namespace，不同 namespace 里的資源是完全隔離的。

k8s 默認(rèn)創(chuàng)建了兩個(gè) namespace。

default 創(chuàng)建資源時(shí)如果不指定，將會(huì)放到這個(gè) namespace 中。

kube-system 存放 k8s 自己創(chuàng)建的系統(tǒng)資源。

健康檢查

數(shù)據(jù)管理

密碼管理

集群監(jiān)控

強(qiáng)大的自愈能力是 k8s 這類容器編排引擎的一個(gè)重要特性。自愈的默認(rèn)實(shí)現(xiàn)方式是自動(dòng)重啟發(fā)生故障的容器。除此之外，用戶還可以利用 liveness 和 readiness 探測機(jī)制設(shè)置更精細(xì)的健康檢查，進(jìn)而實(shí)現(xiàn)如下需求：

零停機(jī)部署

避免部署無效的鏡像

更加安全的滾動(dòng)升級(jí)

默認(rèn)情況下，只有容器進(jìn)程返回值非零，k8s 才會(huì)認(rèn)為容器發(fā)生了故障，需要重啟。如果我們想更加細(xì)粒度的控制容器重啟，可以使用 liveness 和 readiness。

liveness 和 readiness 的原理是定期檢查 /tmp/healthy 文件是否存在，如果存在即認(rèn)為程序沒有出故障，如果文件不存在，則會(huì)采取相應(yīng)的措施來進(jìn)行反饋。

liveness 采取的策略是重啟容器，而 readiness 采取的策略是將容器設(shè)置為不可用。

如果需要在特定情況下重啟容器，可以使用 liveness。
如果需要保證容器一直可以對外提供服務(wù)，可以使用 readiness。

我們可以將 liveness 和 readiness 配合使用，使用 liveness 判斷容器是否需要重啟，用 readiness 判斷容器是否已經(jīng)準(zhǔn)備好對外提供服務(wù)。

上文說道，pod 可能會(huì)被頻繁地銷毀和創(chuàng)建，當(dāng)容器銷毀時(shí)，保存在容器內(nèi)部文件系統(tǒng)中的數(shù)據(jù)都會(huì)被清除。為了持久化保存容器的數(shù)據(jù)，可以使用 k8s volume。

Volume 的生命周期獨(dú)立于容器，pod 中的容器可能被銷毀和重建，但 volume 會(huì)被保留。實(shí)質(zhì)上 vloume 是一個(gè)目錄，當(dāng) volume 被 mount 到 pod，pod 中的所有容器都可以訪問到這個(gè) volume。

Volume 支持多種類型。

emptyDir

數(shù)據(jù)存放在 pod 中，對 pod 中的容器來說，是持久的，只要 pod 還在數(shù)據(jù)就還在。

hostPath

數(shù)據(jù)存在主機(jī)上，主機(jī)在數(shù)據(jù)就在。

AWS Elastic Block Store

數(shù)據(jù)存在云服務(wù)器上。

Persistent Volume

自定義一塊外部存儲(chǔ)空間 Persistent Volume，然后在創(chuàng)建 pod 時(shí)使用 PersistentVolumeClaim（PVC）去申請空間，并進(jìn)行存儲(chǔ)。

Volume 提供了對各種類型的存放方式，但容器在使用 volume 讀寫數(shù)據(jù)時(shí)，不需要關(guān)心數(shù)據(jù)到底是存放在本地節(jié)點(diǎn)的系統(tǒng)中還是云硬盤上。對容器來說，所有類型的 volume 都只是一個(gè)目錄。

應(yīng)用程序在啟動(dòng)過程中可能需要一些敏感信息，比如訪問數(shù)據(jù)庫的用戶名和密碼。將這些信息直接保存在容器鏡像中顯然不妥，k8s 提供的解決方案是 secret。

secret 會(huì)以密文的方式存儲(chǔ)數(shù)據(jù)，避免直接在配置文件中保存敏感信息。secret 會(huì)以 volume 的形式被 mount 到 pod，容器可通過文件的方式使用 secret 中的敏感數(shù)據(jù)，此外容器也可以按環(huán)境變量的形式使用這些數(shù)據(jù)。

使用配置文件創(chuàng)建 mysecret.yaml：

apiVersion: v1
kind Secret
metadata:
  name:mysecret
data:
  username:admin
  password:123

保存配置文件后，然后執(zhí)行kubectl apply -f mysecret.yaml進(jìn)行創(chuàng)建。

在 pod 中使用創(chuàng)建好的 secret：

# mypod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mypod
      image: yhlben/notepad
  volumeMounts:
    - name: foo
      mountPath: "etc/foo"
      readOnly: true
  volumes:
    - name: foo
      secret:
        secretName: mysecret

執(zhí)行kubectl apply -f mypod.yaml 創(chuàng)建 pod，并使用 secret。創(chuàng)建完成后，secret 保存在容器內(nèi) /etc/foo/username ，/etc/foo/password 目錄下。

創(chuàng)建 k8s 集群并部署容器化應(yīng)用只是第一步。一旦集群運(yùn)行起來，我們需要確保集群一切都是正常的，這就需要對集群進(jìn)行監(jiān)控。

常用的可視化監(jiān)控工具如下。

Weave Scope

Heapster

Prometheus Operator

具體的使用步驟就直接看文檔了，這里不詳細(xì)說明。

通過集群監(jiān)控我們能夠及時(shí)發(fā)現(xiàn)集群出現(xiàn)的問題，但為了方便進(jìn)一步排查問題，我們還需要進(jìn)行進(jìn)行日志記錄。

常用的日志管理工具如下。

Elasticsearch 負(fù)責(zé)存儲(chǔ)日志并提供查詢接口。

Fluentd 負(fù)責(zé)從 k8s 搜集日志并發(fā)送給 Elasticsearch。

Kibana 提供一個(gè)可視化頁面，用戶可以瀏覽和搜索日志。

我們來實(shí)戰(zhàn)部署一個(gè) k8s 記事本項(xiàng)目，項(xiàng)目使用 yhlben/notepad 鏡像進(jìn)行構(gòu)建，該鏡像在部署后會(huì)在 8083 端口上提供一個(gè) web 版記事本服務(wù)，查看演示。

為了避免安裝 k8s 出現(xiàn)的各種坑，這里使用 Play with Kubernetes進(jìn)行演示。

首先在 Play with Kubernetes 上創(chuàng)建 3 臺(tái)服務(wù)器，node1 作為 master 節(jié)點(diǎn)，node2 和 node3 作為工作節(jié)點(diǎn)。接下來進(jìn)行以下操作；

創(chuàng)建一個(gè)集群 cluster

加入 node 節(jié)點(diǎn)

初始化 cluster 網(wǎng)絡(luò)

創(chuàng)建 controller

創(chuàng)建 service

執(zhí)行部署

在 node1 上運(yùn)行 kubeadm init 即可創(chuàng)建一個(gè)集群。

kubeadm init --apiserver-advertise-address $(hostname -i)

執(zhí)行完成后會(huì)生成 token，這樣其他節(jié)點(diǎn)就可以憑借這個(gè) token 加入該集群。

在 node2 和 node3 機(jī)器上，分別執(zhí)行以下命令，加入到 node1 的集群。

kubeadm join 192.168.0.8:6443 --token nfs9d0.z7ibv3xokif1mnmv 
    --discovery-token-ca-cert-hash sha256:6587f474ae1543b38954b0e560832ff5b7c67f79e1d464e7f59e33b0fefd6548

命令執(zhí)行完畢后，即可看到 node2，node3 已經(jīng)加入成功。

在 node1 節(jié)點(diǎn)上，執(zhí)行以下命令。

kubectl get node

可以看到，集群中存在 node1 ，node2，node3 這 3 個(gè)節(jié)點(diǎn)，但這 3 個(gè)節(jié)點(diǎn)的都是 NotReady 狀態(tài)，為什么？

答：因?yàn)闆]有創(chuàng)建集群網(wǎng)絡(luò)。

執(zhí)行以下代碼創(chuàng)建集群網(wǎng)絡(luò)。

kubectl apply -n kube-system -f 
    "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 |tr -d "
")"

執(zhí)行命令后，稍等一下，然后查看 node 狀態(tài)，可以看到，集群中的 3 個(gè)節(jié)點(diǎn)都是 Ready 狀態(tài)了。

我們通過配置文件來創(chuàng)建 deployment，新建 deployment.yaml 文件，內(nèi)容如下：

# 配置文件格式的版本
apiVersion: apps/v1
# 創(chuàng)建的資源類型
kind: Deployment
# 資源的元數(shù)據(jù)
metadata:
  name: notepad
# 規(guī)格說明
spec:
  # 定義 pod 數(shù)量
  replicas: 3
  # 通過 label 找到對應(yīng)的 pod
  selector:
    matchLabels:
      app: mytest
  # 定義 pod 的模板
  template:
    # pod 的元數(shù)據(jù)
    metadata:
      # 定義 pod 的 label
      labels:
        app: mytest
    # 描述 pod 的規(guī)格
    spec:
      containers:
        - name: notepad
          image: yhlben/notepad
          ports:
            - containerPort: 8083

文件創(chuàng)建之后，執(zhí)行命令：

kubectl apply -f ./deployment.yaml
# deployment.apps/notepad created

查看部署的 pod。

可以看到，我們使用 deployment 類型的 controller 創(chuàng)建了 3 個(gè) pod，分別運(yùn)行在 node2 和 node3 機(jī)器上，如果有更多的機(jī)器，也會(huì)自動(dòng)負(fù)載均衡，合理地分配到每個(gè)機(jī)器上。

創(chuàng)建 service 和 deployment 類似，新建 service.yaml 文件，內(nèi)容如下：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  # 在節(jié)點(diǎn)上部署訪問 pod 的端口
  type: NodePort
  ports:
    - port: 80
      # service 代理的端口
      targetPort: 8083
      # node 節(jié)點(diǎn)上提供給集群外部的訪問端口
      nodePort: 30036
  # 匹配 pod
  selector:
    app: mytest

文件創(chuàng)建之后，執(zhí)行命令：

kubectl apply -f ./service.yaml
# service/my-service created

使用 kubectl get deployment 和 kubectl get service 查看創(chuàng)建結(jié)果。

可以看到，deployment 和 service 均創(chuàng)建成功，并且已知 service 暴露的 ip 地址為：10.106.74.65，端口號(hào)為 80，由于設(shè)置了 targetPort，service 在接收到請求時(shí)，會(huì)自動(dòng)轉(zhuǎn)發(fā)到 pod 對應(yīng)的 8083 端口上。

部署成功后，我們可以通過兩種方式進(jìn)行訪問：

集群內(nèi)：通過 service 的 clusterIp + port 端口進(jìn)行訪問。

集群外：通過任意一個(gè) node 節(jié)點(diǎn) + nodePort 端口進(jìn)行訪問。

# 集群內(nèi)訪問
curl 10.106.74.65
# 集群外訪問
# 192.168.0.12 是 node2 節(jié)點(diǎn)的ip
# 192.168.0.11 是 node3 節(jié)點(diǎn)的ip
curl 192.168.0.12:30036
curl 192.168.0.11:30036

集群內(nèi)訪問。

集群外訪問。

到這里，已經(jīng)算部署成功了，大家肯定有疑問，部署一個(gè)如此簡單的 web 應(yīng)用就這么麻煩，到底 k8s 好在哪里？我們接著往下看。

項(xiàng)目已經(jīng)部署，接下來來實(shí)戰(zhàn)一個(gè)運(yùn)維，感受一下 k8s 帶給我們的便利。

公司要做雙 11 活動(dòng)，需要至少 100 個(gè)容器才能滿足用戶要求，應(yīng)該怎么做？

首先，應(yīng)該盡可能利用當(dāng)前擁有的服務(wù)器資源，創(chuàng)建更多的容器來參與負(fù)載均衡，通過 docker stats 可以查看容器占用的系統(tǒng)資源情況。如果充分利用后仍然不能滿足需求，就根據(jù)剩余需要的容器，計(jì)算出需要購買多少機(jī)器，實(shí)現(xiàn)資源的合理利用。

購買服務(wù)器，將服務(wù)器作為 node 節(jié)點(diǎn)，join 到集群中。

執(zhí)行擴(kuò)容命令。

執(zhí)行以下命令就能將容器擴(kuò)展到 100 個(gè)。

kubectl scale deployments/notepad --replicas=100

如圖，擴(kuò)展 10 個(gè) pod 的情況，node2 和 node3 節(jié)點(diǎn)共同分擔(dān)負(fù)載。

也可以通過修改 deployment.yaml 中的 replicas 字段，執(zhí)行 kubectl apply -f deployment.yaml去執(zhí)行擴(kuò)展。如果活動(dòng)結(jié)束了，只需要將多余的服務(wù)器刪除，縮減容器數(shù)量即可還原到之前的效果。

雙 11 活動(dòng)很火爆，但突然加了需求，需要緊急上線，如果實(shí)現(xiàn)滾動(dòng)更新？

滾動(dòng)更新就是在不宕機(jī)的情況下，實(shí)現(xiàn)代碼更新。執(zhí)行以下命令，修改 image 即可。

kubectl set image deployments/notepad notepad=yhlben/notepad:new

也可以通過修改 deployment.yaml 中的 image 字段，執(zhí)行 kubectl apply -f deployment.yaml去執(zhí)行升級(jí)。

如果更新出了問題，k8s 內(nèi)置了一鍵還原上個(gè)版本的命令：

kubectl rollout undo deployments/notepad

通過這 2 個(gè)案例，感覺到了 k8s 給運(yùn)維帶來了很大的便利：快速高效地部署項(xiàng)目，支持動(dòng)態(tài)擴(kuò)展、滾動(dòng)升級(jí)，同時(shí)還能按需優(yōu)化使用的硬件資源。

本文的目的就是入門 k8s，通過一個(gè)簡單的集群來實(shí)現(xiàn)這一點(diǎn)，但其中也踩了好多坑，具體如下：

使用 minikube 搭建項(xiàng)目

能快速搭建一個(gè)單節(jié)點(diǎn) k8s 環(huán)境。

但在本地使用 minikube 搭建一套 k8s 集群，很多包裝不上，全局代理也不行。

使用 google clould 上的服務(wù)器

在 gogole clould 上，解決了網(wǎng)絡(luò)問題，需要安裝的包都能裝上。

但由于是新服務(wù)器，需要各種安裝環(huán)境，docker，kubeadm，kubectl 等，安裝過程繁瑣，還可能會(huì)遇到報(bào)錯(cuò)。

不知道哪天手滑了一下，試用賬號(hào)變成了付費(fèi)賬號(hào)，贈(zèng)金 $300 就這樣沒了