VirtualBox、VMware 是將作業系統虛擬化，而 Docker 是將應用程式虛擬化。

為什麼想針對應用程式虛擬化呢？我們知道軟體工程強調模組化，如果我們能將大型系統模組化，可以帶來
許多好處，例如更好維護、更易於重複使用、易於更新、除錯。將應用程式虛擬化就如同模組化的概念，我
們期望系統更加容易維運與佈署，例如我可以把購物網站拆解成處理購物交易的金流服務、處理貨運狀況的
物流服務、處理訂單的服務。如此一來我們可以讓數個系統共用同一個金流服務，不管是 A,B,C 店家的金流
服務或者另外建構了一個線上付費課程平台，都可以使用同一個金流服務，不必重複開發，並且我可以更容
易地把服務複製成好幾個，以便服務不同地區的使用者，增加系統的負載能力。

換言之，一個大型系統，其實可以拆解成數個應用程式或服務，如果是作業系統等級的虛擬化技術，我們只
能針對整個系統進行虛擬化，也就是複製整個系統包含硬體資源(CPU、Memory)來增加負載能力。會需要
耗費較大的記憶體資源與運算資源，我們沒辦法只增加系統中某個子服務或應用的實體數量。

一個應用程式有許多相依性的程式庫與執行環境(Bins/Libs)，Docker 將應用程式與這些相依性資源封裝成
一個 Container，像圖中就有綠色、橘色和紅色三種 Container，這些 Container 必須執行在 Docker Engine
這個環境上，就如同上圖右邊的傳統虛擬化技術必須有一層 Hypervisor，可在其上運行虛擬化的作業系
統。

我們看上圖的 App 7，就是一般的作業系統虛擬化技術之應用情境，我們必須先決定 App 7 要在幾核的

CPU 下、多少 RAM、多少硬碟空間，或使用哪一種 OS，而 App7 佔用了 OS 的所有資源，不管它是不是需
要這麼多的 CPU 運算能力、儲存空間與記憶體大小，他可能佔用了 App 4 ~ App 6 需要的硬體資源，卻不
事生產。容器化後的 App 1~App 3 可以共用 OS 的硬體資源，因此更加彈性。
基本架構

組件解釋

Kubernetes 是幹啥的我就不講了。

etcd 是負責設定檔同步的。

flanneld 是負責私有網路的。

說白了，Kubernetes 很多事情都不負責，都是由其他開源軟體來做

名詞解釋

- node，集群中的物理節點，可以理解為一台主機。當然，我們的試驗中都是虛擬機器。一個集群中一般存在很多
node 。

- pod，集群中的虛擬節點，簡單理解的話，其實就是 「一個 docker 容器」。一個集群中真正負責給使用者提供功

能服務的就是這些 pod。

- deployment，部署 pod 用的。deployment 對部署在哪個 node 上不關心，只關心 pod, 這也就意味著，使用

deployment 部署給使用者提供服務

- daemonset，同樣是部署 pod 用的。daemonset 在所有（或指定的）node 上運行，一個 node 上只運行一個 pod，

使用 daemonset 部署用於給 Kubernetes 服務的服務，比如監控和負載均衡。

- svc，全稱 service，負責將一組相同的 pod 提供的服務進行抽象。由 deployment 部署的一組 Pod，他們都提供相

應的服務。在任意 node 上，都可以通過 pod-ip 進行訪問。然而 pod-ip 是動態生成的，且每個 pod 都有自己的
pod-ip，不方便調用。service 將這些 pod-ip 抽象為統一的 CLUSTER-IP。注意 pod 的 pod-ip 和 service 的
CLUSTER-IP 都不是真實存在的 IP，只是由 iptables 中轉出來的，所以只在 node 上可以直接訪問，離對外提供服務
還有一段距離。

- traefik，Kubernetes-ingress 為 Kubernetes 存在的負載均衡場景。traefik 則可以把所有跑著 pod 的 node 的 service

匯總為統一一個對外服務。我們從外部發起的請求，首先由 traefik 接收，再尤其進行負載均衡，將流量轉發到
node 上，再進入 node 上的 service，最終進入 pod。經過 traefik 之後，就可以通過訪問任何一個 node 上對應的
埠，訪問 pod 提供的服務。當然，只指定一個 node 作為對外服務的話，會出現單點故障，所以最外層還需要一層
負載均衡才可以，不過這就不是 Kubernetes 要負責的事情了。
實戰架設

下載解壓拷貝
首先解壓壓縮包，之後修改 list-master.list 和 list-node.list 。請保證 master 只有一台，node 至少三台。
之後執行 s0-deploy-to-master.sh ，將所需檔複製到 master 。

Master 節點上
登錄到 master，進入 /root/kubernetes/ ，執行 s1-ssh-nopasswd-copy.sh ，將創建免密登錄金鑰，並複製到所有 node 節點上，這
樣接下來所有遠端執行命令都不需要再輸入金鑰了。
執行 s2-sync-scripts.sh ，將所需文件部署到 node。
執行 mastery.sh ，腳本將在 master 和所有 node 上一次執行 x01.sh 至 x07.sh 腳本（部分腳本只在 master 上或 node 上執
行）。

執行完成後，Kubernetes 集群就創建好了。

很方便吧。

當然，還是需要簡單描述下這些腳本都執行了啥。

腳本簡述

x01.sh 至 x07.sh

這些腳本只是引用了其他腳本。
00.全域環境變數

00-0-env-global.sh，所有全域變數都保存於此檔。其他檔均使用 source 引用此檔中的變數。

01.二進位檔案和鏡像文件部署

01-1-env-setup.sh，負責集群上二進位檔案的安裝，Docker.service 的更新，並將 Kubernetes 可執行檔添加進 .bashrc

的 $PATH。

注：$PATH 只寫入檔，不立即生效。想要生效就得觸發一次 .bashrc。很多腳本寫的不是絕對路徑，所以在 $PATH 未生

效之前可能會執行失敗。

01-2-image-load.sh，導入必要的 Docker 鏡像文件。與 Docker 不同的是，Kubernetes 默認使用穀歌的鏡像倉庫，這會

產生什麼問題你懂的。所以我在打包時已經提前引入的所需的鏡像檔，這樣即使在無網路環境下也可能部署伺服器，用
於學習。

02.證書 CA 文件

Kuberentes 很多地方都使用 HTTPS 雙向認證。雖然使用 Token 是未來趨勢，不過至少現在還做不完全。所以這步得

做。

HTTPS 證書靠 cloudflare 提供的工具就能做，這一步只做 CA 檔，後面每個會使用證書的工具都會生成對應的證書。

證書 CA 檔只需要生成一份就行，本次只需要在 Master 上運行。

03.etcd 集群創建

etcd 是 Kubernetes 的後端存儲。etcd 集群獨立於 Kubernetes。

04.kubectl 部署

本步驟生成並部署 kubeconfig，給 kubectl 用。

kubectl 是負責控制 Kubernetes 的命令。本專案為了簡單，在所有節點上都安裝了 kubectl，方便控制。也就是說，你

可以在任何一台機器上，不論是 master 還是 node，都可以執行 kubectl。

05.flanneld

Flannel 是一個可以用於 Kubernetes 的 overlay 網路提供者。

06.kube-apiserver 和 kube-controller-manager 和 kube-scheduler

這些名詞都已經講過了。

本步驟只在 Master 安裝 kube-apiserver，kube-controller-manager，kube-scheduler-systemd”

07.kubelet

kubelet 是真正幹活的。

本步驟是在節點安裝 kubelet、kube-proxy。

集群功能驗證

my-php-test

my-php-test 是我製作的一個包含 Apache 和 PHP 的測試用鏡像，裡面只包含一個 index2.php 文件。index2.php 可以用

來檢測伺服器的部分資訊。
注：my-php-test 項目中包含一個 MYSQL 連接，默認位址是 127.0.1.1，是 pod 自身。這個連接是肯定會失敗的，會報錯
Failed to connect to MySQL: (2002) Connection refused。之所以要這麼做，是為了展示 deployment 設定檔中的環境變
數。如果你有可用的 MYSQL Server，可以修改 deployment 設定檔，測試連接。

本文只著重於對 Kubernetes 的服務端建設。對於 Kubernetes 的使用，請參考其它文檔。

安裝 my-php-test

首先在 Master 上執行 ./t1.sh ，在所有 node 上導入鏡像 php-www-data_20180717170240。

進入 my-php-test 目錄，執行 apply-my-php-test.sh ，my-php-test 就可以部署完成。

驗證

首先在節點上執行 kubectl get pods -o wide 查看各 pod 的資訊。之後在節點上訪問 pod-ip，查看訪問效果

在節點上可以直接訪問 pod。當然，再次強調下，pod-ip 並不存在於網卡之上，也不存在于集群上任何一個物理位置。
之所以可以訪問，都是 iptables 的功勞。
接下來執行 kubectl get svc 查看 service 的資訊，之後在節點上訪問 CLUSTER-IP，查看訪問效果

在節點上同樣可以直接訪問 service 。同樣 CLUSTER-IP 並不存在於網卡之上，也不存在于集群上任何一個物理位置。

這同樣是 iptables 的功勞。

到這裡，Kubernetes 集群功能就算是能用了。

試試直接訪問 node-ip ，可以發現是不能直接訪問的。

traefik

就如同我前文說的一樣，kubernetes 集群是架好了，但是從外網是看不到 pod-ip 和 CLUSTER-IP 。不可以每次都依靠在

外部主機上以寫 iptables 或 靜態路由的方式來將流量引入 kubernetes 集群，因為 Kubernetes 集群生成的 pod-ip 和
CLUSTER-IP 都是動態的。

所有可以確定的東西，除了設定檔，就是 Node-IP 了。設定檔是為了部署我們的產品應用而存在的，所以應專注于應用

的配置。

所以按理來講，直接訪問 Node-IP 才更符合使用習慣。

traefik 正是做這個的。

嚴格來講，本步驟是將 traefik 作為 Kubernetes Ingress Controller 使用。

traefik 的安裝，已經在本文中 Kubernetes 伺服器安裝過程中完成了，所以我們這裡只需要使用即可。

進入 traefik 目錄，執行 traefik-test.sh 即可。

traefik 當然是要以 daemonset 的方式執行，而且由於這玩意的意義不一樣，所以還要有不同的安全措施。具體細節請

參考 traefik 的官方文檔。
執行 ./get-namespace-kube-system.sh 檢查 traefik 的運行狀態

執行 ./get-ingress.sh 檢查 ingress 狀態

從可以訪問集群的任意位置，訪問 noded-ip。
好了，能用了。

從外部訪問

直接將請求流量引入到單個 Node 是不好的，別光說單點故障，動態遷移，後期維護，以及安全性，都是問題。

有個最為簡單的方案，如果是自建機房的話，在網路最外層，是必須買硬體防火牆的，可以將請求負載均衡到所有節點
上。如果防火牆沒有這個功能，則最好再自建負載均衡伺服器，這方面的方案非常多，就不介紹了。

出口負載均衡或者出口防火牆如果故障了，那就是活該斷網。

實踐方案建議

當然了，還有很多可選方案，但對於一般開發者來講，降低學習難度和維護成本是第一目的，所以：
 服務應用採用容器

 資料庫採用現成的分散式資料庫方案

 檔存儲採用現成的物件存儲

當然，你要是真打算自己做檔同步和資料庫同步，就是擺明瞭要做 技術流氓，要跟公司做 技術綁架，就看是你先把公

司耗死，還是公司資金鏈先斷裂。反正都是死路一條，現在去工商局排隊都能排一天呢。
Ref: https://blog.catscarlet.com/201902243302.html

負載均衡/高可用方案 (HAproxy + KeepAlived + Nginx)

安裝 haproxy
$ yum install -y haproxy

配置 haproxy

由於集群內部有的組建是通過非安全埠訪問 apiserver 的，有的是通過安全埠訪問 apiserver 的，所以我們要配置 http 和 https 兩種代

理方式，設定檔 /etc/haproxy/haproxy.cfg：

listen stats

bind *:9000

mode http

stats enable

stats hide-version

stats uri /stats

stats refresh 30s

stats realm Haproxy\ Statistics

stats auth Admin:Password

frontend k8s-api

bind 192.168.1.137:443

mode tcp

option tcplog

tcp-request inspect-delay 5s

tcp-request content accept if { req.ssl_hello_type 1 }

default_backend k8s-api

backend k8s-api

mode tcp

option tcplog

option tcp-check

balance roundrobin

default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 250 maxqueue 256 weight 100

server k8s-api-1 192.168.1.137:6443 check

server k8s-api-2 192.168.1.138:6443 check

frontend k8s-http-api

bind 192.168.1.137:80

mode tcp

option tcplog

default_backend k8s-http-api

backend k8s-http-api

mode tcp

option tcplog

option tcp-check

balance roundrobin

default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 250 maxqueue 256 weight 100

server k8s-http-api-1 192.168.1.137:8080 check

server k8s-http-api-2 192.168.1.138:8080 check

通過上面的設定檔我們可以看出通過 https 的訪問將請求轉發給 apiserver 的 6443 埠了，http 的請求轉發到了 apiserver 的 8080

埠。

啟動 haproxy
$ sudo systemctl start haproxy

$ sudo systemctl enable haproxy

$ sudo systemctl status haproxy

然後我們可以通過上面 9000 埠監控我們的 haproxy 的運行狀態(192.168.1.137:9000/stats):

haproxy stats
問題

上面我們的 haproxy 的確可以代理我們的兩個 master 上的 apiserver 了，但是還不是高可用的，如果 master01 這個節點 down 掉

了，那麼我們 haproxy 就不能正常提供服務了。這裡我們可以使用兩種方法來實現高可用

方式 1：使用阿裡雲 SLB

這種方式實際上是最省心的，在阿裡雲上建一個內網的 SLB，將 master01 與 master02 添加到 SLB 機器組中，轉發 80(http)和

443(https)埠即可（注意下面的提示）

注意：阿裡雲的負載均衡是四層 TCP 負責，不支援後端 ECS 實例既作為 Real Server 又作為用戶端向所在的負載均衡實例發送請求。

因為返回的資料包只在雲伺服器內部轉發，不經過負載均衡，所以在後端 ECS 實例上去訪問負載均衡的服務位址是不通的。什麼意
思？就是如果你要使用阿裡雲的 SLB 的話，那麼你不能在 apiserver 節點上使用 SLB（比如在 apiserver 上安裝 kubectl，然後將
apiserver 的位址設置為 SLB 的負載位址使用），因為這樣的話就可能造成回環了，所以簡單的做法是另外用兩個新的節點做 HA 實
例，然後將這兩個實例添加到 SLB 機器組中。

方式 2：使用 keepalived

KeepAlived 是一個高可用方案，通過 VIP（即虛擬 IP）和心跳檢測來實現高可用。其原理是存在一組（兩台）伺服器，分別賦予

Master、Backup 兩個角色，預設情況下 Master 會綁定 VIP 到自己的網卡上，對外提供服務。Master、Backup 會在一定的時間間隔
向對方發送心跳資料包來檢測對方的狀態，這個時間間隔一般為 2 秒鐘，如果 Backup 發現 Master 宕機，那麼 Backup 會發送 ARP
包到閘道，把 VIP 綁定到自己的網卡，此時 Backup 對外提供服務，實現自動化的容錯移轉，當 Master 恢復的時候會重新接管服
務。非常類似于路由器中的虛擬路由器冗餘協議（VRRP）

開啟路由轉發，這裡我們定義虛擬 IP 為：192.168.1.139

$ vi /etc/sysctl.conf

# 添加以下內容

net.ipv4.ip_forward = 1

net.ipv4.ip_nonlocal_bind = 1

# 驗證並生效

$ sysctl -p

# 驗證是否生效

$ cat /proc/sys/net/ipv4/ip_forward

安裝 keepalived:

$ yum install -y keepalived

我們這裡將 master01 設置為 Master，master02 設置為 Backup，修改配置：

$ vi /etc/keepalived/keepalived.conf
! Configuration File for keepalived

global_defs {

notification_email {

router_id kube_api

vrrp_script check_haproxy {

# 自身狀態檢測

script "killall -0 haproxy"

interval 3

weight 5

vrrp_instance haproxy-vip {

# 使用單播通信，默認是組播通信

unicast_src_ip 192.168.1.137

unicast_peer {

192.168.1.138

# 初始化狀態

state MASTER

# 虛擬 ip 綁定的網卡 （這裡根據你自己的實際情況選擇網卡）

interface eth0

# 此 ID 要與 Backup 配置一致

virtual_router_id 51

# 默認啟動優先順序，要比 Backup 大點，但要控制量，保證自身狀態檢測生效

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

virtual_ipaddress {

# 虛擬 ip 位址

192.168.1.139

}
 track_script {

check_haproxy

virtual_server 192.168.1.139 80 {

delay_loop 5

lvs_sched wlc

lvs_method NAT

persistence_timeout 1800

protocol TCP

real_server 192.168.1.137 80 {

weight 1

TCP_CHECK {

connect_port 80

connect_timeout 3

virtual_server 192.168.1.139 443 {

delay_loop 5

lvs_sched wlc

lvs_method NAT

persistence_timeout 1800

protocol TCP

real_server 192.168.1.137 443 {

weight 1

TCP_CHECK {

connect_port 443

connect_timeout 3

統一的方式在 master02 節點上安裝 keepalived，修改配置，只需要將 state 更改成 BACKUP，priority 更改成 99，unicast_src_ip 與

unicast_peer 地址修改即可。
啟動 keepalived:

$ systemctl start keepalived

$ systemctl enable keepalived

# 查看日誌

$ journalctl -f -u keepalived

驗證虛擬 IP:

# 使用 ifconfig -a 命令查看不到，要使用 ip addr

$ ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

link/ether 00:16:3e:00:55:c1 brd ff:ff:ff:ff:ff:ff

inet 192.168.1.137/24 brd 192.168.1.255 scope global dynamic eth0

valid_lft 31447746sec preferred_lft 31447746sec

inet 192.168.1.139/24 brd 192.168.1.255 scope global secondary eth0-vip

valid_lft forever preferred_lft forever

到這裡，我們就可以將上面的 6443 埠和 8080 埠去掉了，可以手動將 kubectl 生成的 config 檔(~/.kube/config)中的 server 地址

6443 埠去掉，另外 kube-controller-manager 和 kube-scheduler 的–master 參數中的 8080 埠去掉了，然後分別重啟這兩個元件
即可。

驗證 apiserver：關閉 master01 節點上的 kube-apiserver 進程，然後查看虛擬 ip 是否漂移到了 master02 節點。

然後我們就可以將第一步在/etc/hosts 裡面設置的功能變數名稱對應的 IP 更改為我們的虛擬 IP 了

master01 與 master 02 節點都需要安裝 keepalived 和 haproxy，實際上我們虛擬 IP 的自身檢測應該是檢測 haproxy，腳本大家可以

自行更改

kube-apiserver ha

這樣我們就實現了接入層 apiserver 的高可用了，一個部分是多活的 apiserver 服務，另一個部分是一主一備的 haproxy 服務。

kube-controller-manager 和 kube-scheduler 的高可用

Kubernetes 的管理層服務包括 kube-scheduler 和 kube-controller-manager。kube-scheduler 和 kube-controller-manager 使用一

主多從的高可用方案，在同一時刻只允許一個服務處以具體的任務。Kubernetes 中實現了一套簡單的選主邏輯，依賴 Etcd 實現
scheduler 和 controller-manager 的選主功能。如果 scheduler 和 controller-manager 在啟動的時候設置了 leader-elect 參數，它們
在啟動後會先嘗試獲取 leader 節點身份，只有在獲取 leader 節點身份後才可以執行具體的業務邏輯。它們分別會在 Etcd 中創建
kube-scheduler 和 kube-controller-manager 的 endpoint，endpoint 的資訊中記錄了當前的 leader 節點資訊，以及記錄的上次更新時
間。leader 節點會定期更新 endpoint 的資訊，維護自己的 leader 身份。每個從節點的服務都會定期檢查 endpoint 的資訊，如果
endpoint 的資訊在時間範圍內沒有更新，它們會嘗試更新自己為 leader 節點。scheduler 服務以及 controller-manager 服務之間不會
進行通信，利用 Etcd 的強一致性，能夠保證在分散式高併發情況下 leader 節點的全域唯一性。整體方案如下圖所示：

img

當集群中的 leader 節點服務異常後，其它節點的服務會嘗試更新自身為 leader 節點，當有多個節點同時更新 endpoint 時，由 Etcd 保

證只有一個服務的更新請求能夠成功。通過這種機制 sheduler 和 controller-manager 可以保證在 leader 節點宕機後其它的節點可以
順利選主，保證服務故障後快速恢復。當集群中的網路出現故障時對服務的選主影響不是很大，因為 scheduler 和 controller-
manager 是依賴 Etcd 進行選主的，在網路故障後，可以和 Etcd 通信的主機依然可以按照之前的邏輯進行選主，就算集群被切分，
Etcd 也可以保證同一時刻只有一個節點的服務處於 leader 狀態。

負載均衡/高可用方案 (K8s)
其核心思想是讓 k8s master 節點中的各類組件具備高可用性，消除單點故障。

- kube-apiserver - 對外暴露了 k8s API，是整個集群的訪問入口。由於 apiserver 本身無狀態，可以通過啟動多個實例並結合負載均衡

器實現高可用。

- etcd - 用於存儲 k8s 集群的網絡配置和對象的狀態信息，是整個集群的數據中心。可以通過啟動奇數個 etcd 實例建立一個冗餘

的，可靠的數據存儲層。

- kube-scheduler - 為新創建的 pod 選擇一個供他們運行的節點。一個集群只能有一個活躍的 kube-scheduler 實例，可以同時啟動多

個 kube-scheduler 並利用領導者選舉功能實現高可用。

- kube-controller-manager - 集群內部的管理控制中心。一個集群只能有一個活躍的 kube-controller-manager 實例，可以同時啟動多

個 kube-controller-manager 並利用領導者選舉功能實現高可用。

原文網址：https://kknews.cc/code/l9yjbmg.html

該架構有如下特點：
- 集群中的各個組件均通過容器方式啟動，並且設置重啟策略為 always。這樣當他們出現故障意外退出後，能被自動拉起。

- Master 節點上的 kube-scheduler、kube-controller-manager 直接和本機的 API server 通信。

- Worker 節點上的 nginx-proxy 擁有 API server 的地址列表，負責代理 kubelet、kube-proxy 發往 API server 的請求。

- 為了讓集群具有災備能力，master 節點上的 etcd-rolling-snapshots 會定期保存 etcd 的快照至本地目錄/opt/rke/etcd-snapshots 中。

原文網址：https://kknews.cc/code/l9yjbmg.html

配置負載均衡器

在完成了集群部署後，可以通過 API server 訪問 k8s。由於環境中啟動了多個 kube-apiserver 實例以實現高可用，需要為這些實例架設

一個負載均衡器。這裡在 192.168.0.10 上部署了一台 nginx 實現了負載均衡的功能，nginx.conf 的具體配置如下。

...

stream {

upstream apiserver {

server 192.168.0.11:6443 weight=5 max_fails=3 fail_timeout=60s;

server 192.168.0.12:6443 weight=5 max_fails=3 fail_timeout=60s;

server 192.168.0.13:6443 weight=5 max_fails=3 fail_timeout=60s;

server {

listen 6443;

proxy_connect_timeout 1s;

proxy_timeout 10s;

proxy_pass apiserver;

...

這時，通過負載均衡器提供的埠訪問 API server 會出現異常 Unable to connect to the server: x509: certificate is valid for xxx, not
192.168.0.10。這裡需要將負載均衡器的 IP 地址或域名加入到 API server 的 PKI 證書中，可以通過 cluster.yml 中的 authentication 配置項
完成此功能。

authentication:

strategy: x509

sans:

- "192.168.0.10"

修改完 cluster.yml 後，運行命令 rke cert-rotate。

驗證
在完成上述所有步驟後，可以通過命令 kubectl get nodes 查看節點狀態。如果所有節點的狀態均為 Ready，則表示集群部署成功。

NAME STATUS ROLES AGE VERSION

192.168.0.11 Ready controlplane,etcd 1d v1.13.5

192.168.0.12 Ready controlplane,etcd 1d v1.13.5

192.168.0.13 Ready controlplane,etcd 1d v1.13.5

192.168.0.14 Ready worker 1d v1.13.5

192.168.0.15 Ready worker 1d v1.13.5

192.168.0.16 Ready worker 1d v1.13.5

192.168.0.17 Ready worker 1d v1.13.5

總結

Rancher Kubernetes Engine（RKE）為用戶屏蔽了創建 k8s 集群的複雜細節，簡化了部署步驟，降低了構建門檻。對於那些有自建 k8s 集

群需求的企業是一個不錯的選擇。

原文網址：https://kknews.cc/code/l9yjbmg.html

Summary:

K8S – HA on master Node

Nginx – HA on worker Node (No more than 100 pods per node)

k8s 监控方案调研

 1、cAdvisor + InfluxDB + Grafana

 2、Heapster + InfluxDB + Grafana

 3、Promethus + kube-state-metrics + Grafana

 Grafana: 開源 DashBoard，後端支援多種資料庫，如：Influxdb、Prometheus…，外掛程式也比較多，功能強大。非常適合

用於做展示。

 InfluxDB: 開源時間序列資料庫，性能高效


 cAdvisor: 來自 Google 的容器監控工具，也是 Kubelet 內置的容器資源收集工具。它會自動收集本機容器 CPU、記憶體、

網路和檔案系統的資源佔用情況，並對外提供 cAdvisor 原生的 API。隨 kubelet 啟動 –cadvisor-port = 1

 Heapster: 由於 cAdvisor 只提供了單機的容器資源佔用情況，而 Heapster 則提供了整個集群的資源監控（kubernetes 1.11 之

前，hpa 都是從 heapster 獲取資料），並支援持久化資料存儲到 InfluxDB

 Promethues: 提供強大的資料獲取、資料存儲、資料展示、告警等，天生完美支持 kubernetes，CNCF 基金會的第二個成員，

第一個是 Kubernetes。而且 Prometheus 裡面很多思想都來源於 Google 內部的監控系統 Borgmon，可以說是 Google 的乾兒

子。

https://www.servicemesher.com/blog/prometheus-monitor-k8s-1/