Kubernetes 集群高可用代理實踐之路

作者：鄒俊豪 2022-07-08 14:17:18

系統 Linux

本文介紹了雙機主備方式和雙主機方式兩種方案來解決代理的高可用。

前言

在 Kubernetes 集群的高可用拓撲選項[1] 中，介紹了集群高可用的兩個方案：

使用堆疊（stacked）控制平面節點，其中 etcd 節點與控制平面節點共存

使用外部 etcd 節點，其中 etcd 在與控制平面不同的節點上運行

我們知道實現高可用架構的本質就是在做冗余。

對于 Kubernetes 集群的高可用架構：

應用層：Pod 的高可用性由 Kubernetes 自行保證。主要通過健康檢查和重啟策略實現 Pod 的故障自我修復能力，通過調度算法實現 Pod 分布式部署，通過副本數監控機制，保障 Pod 的實時運行副本。
worker node ：工作節點負責運行工作負載，可以任意橫向擴展，隨時加入新節點，不需要考慮高可用架構。
etcd ：作為集群狀態信息存儲組件，可組建 etcd 集群方式實現高可用，對于 Kubernetes 集群有 stacked etcd 和 external etcd 兩種方案。
control plane node ：控制平面節點即 master 節點，負責與工作節點上的 kubelet 和 kube-proxy 進行通信來維護整個集群的健康工作狀態。

其中控制平面節點的三個核心組件：

kube-controller-manager 和 kube-scheduler ：只要部署多 master 實例，即可通過自身選舉機制實現高可用。
kube-apiserver ：apiserver 服務器是無狀態的，負責提供 Kubernetes 的 API 服務，是整個集群控制的入口。

可見，kube-apiserver 的高可用性將決定整個集群的高可用（etcd 高可用同樣極其重要，但不在本文探討范圍內）。

由于 apiserver 本質上是一個無狀態的 HTTP API 服務，因此，實現 apiserver 的高可用性，本質上就是實現 web 服務器的高可用性，可以通過為其增加可水平擴容的負載均衡器（load balancer ，簡稱 lb ）。

后續用戶（ kubectl 、 dashbaord 等其他客戶端）和集群內部的組件都將通過訪問 lb 來訪問 apiserver 。

這下問題就變成了如何實現 lb 的高可用。

先來看 lb 的選型，可以采用硬件負載均衡（F5），這是最好但也是最昂貴的做法：

也可以使用代理軟件（nginx/haproxy 等[2]），采用軟件負載均衡的做法：

今天本文的分享內容便是對代理軟件高可用的實踐。

代理軟件

對于代理軟件的選型，可以根據實際需求決定，不會影響本文的高可用實踐（目前對于集群代理主流使用的是 haproxy ）。

本文將以 nginx 為例，并使用 Docker 部署：

$ docker run --name nginx -d -v $PWD/default.conf:/etc/nginx/conf.d/default.conf -p 80:80 nginx

對應的 default.conf 配置示例如下：

upstream cluster {
   server 192.168.19.160:8080;
   server 192.168.19.160:8081;
   server 192.168.19.160:8082;
}
server {
   listen       80;
   server_name  localhost;
   location / {
       proxy_pass http://cluster;
   }
}

為了方便我們后續的測試，其中代理的三個后端服務是我們模擬的三個 web 服務（實際使用時替換為集群 apiserver 即可）。

高可用的核心也是第一步就是冗余，為了提升代理服務器的高可用，我們需要冗余一個實例，按照剛才的教程需要在主機 lb1 和 lb2 同時部署 nginx （也就是說有兩臺機子運行著 nginx 代理）：

IP	主機名	代理端口	默認主從
192.168.19.158	lb1	80	MASTER
192.168.19.159	lb2	80	BACKUP

測試這兩個代理服務器，請求將會均衡到三個后端服務中的任意一個。

代理測試

接下來就該考慮如何實現服務器的自動故障轉移，即 lb1 掛了之后，冗余的 lb2 如何快速頂上來使用，這一功能也稱作：雙機熱備。

雙機熱備

一圖秒懂雙機熱備[3]

所謂雙機熱備，即主機和從機通過 TCP/IP 網絡連接，正常情況下主機處于工作狀態，從機處于監視狀態，一旦從機發現主機異常，從機將會在很短的時間之內代替主機，完全實現主機的功能。

我們現在的需求很明確，即 lb1 作為主代理服務器提供給外部訪問，lb2 作為從代理服務器，一旦 lb1 發生故障，lb2 可以立即頂替上去，以實現代理的高可用。

lb1 和 lb2 是不同主機，不同 IP 的，而我們又必須對外部訪問端透明，只能有一個 IP 給到外部。

只給外部一個 IP ，這個 IP 能不能正常情況下屬于 lb1 節點，當 lb1 節點掛了之后又變成屬于 lb2 節點的呢。

這就引出了 Virtual IP （虛擬 IP，簡稱 VIP ）的概念了。

我們可以創建一個 VIP 為 192.168.19.200 ，正常情況下，該 VIP 綁定到 lb1 上，一旦 lb1 發生故障，VIP 立即漂移到 lb2 。對于外部訪問端，就只需要調用 192.168.19.200 這個 VIP 就可以了，無需理會代理服務器究竟是 lb1 還是 lb2 。

這個 VIP 的漂移機制實現也有現成的工具：keepalived 。

keepalived

keepalived 是一個基于 VRRP 協議實現的 Web 服務高可用方案，可以利用其避免單點故障。

可以在 lb1 節點部署 keepalived 作為主服務器（MASTER），在 lb2 節點部署 keepalived 作為備服務器（BACKUP），對外表現為一個 VIP （默認綁定在 MASTER 所在節點）。

keepalived MASTER 會發送特定消息給 keepalived BACKUP ，當 BACKUP 收不到消息時（即 MASTER 宕機或發生故障）， BACKUP 就會接管 VIP 。

keepalived 需要注意腦裂問題的發生，即：MASTER 和 BACKUP 同時占用了 VIP

接下來我們就利用 keepalived 來實現雙機熱備機制以保障代理的高可用。

本文實驗機環境：CentOS Linux release 7.9.2009 (Core)

在 lb1 和 lb2 節點都部署上 keepalived ：

[root@lb1 ~]# yum -y install keepalived

[root@lb2 ~]# yum -y install keepalived

lb1 節點修改 keepalived 的配置文件：

[root@lb1 ~]# cd /etc/keepalived/
[root@lb1 keepalived]# pwd
/etc/keepalived
[root@lb1 keepalived]# vi keepalived.conf

lb1 節點 keepalived.conf 內容如下：

! Configuration File for keepalived
global_defs {
   # # 通知郵件服務器的配置
   # notification_email {
   #     # 當 master 失去 VIP 的時候，會發一封通知郵件到 your-email@qq.com
   #     your-email@qq.com
   # }
   # # 發件人信息
   # notification_email_from keepalived@qq.com
   # # 郵件服務器地址
   # smtp_server 127.0.0.1
   # # 郵件服務器超時時間
   # smtp_connect_timeout 30
   # 唯一 id ，通常設置為 hostname
   router_id lb1
}
# 檢查nginx是否存活
vrrp_script check_nginx {
   script "/etc/keepalived/nginx_check.sh"
   interval 2 # 檢測時間間隔
   weight -20 # 檢測失敗（腳本返回非0）則權重 -20
}
# 定義虛擬路由，VI_1 為虛擬路由的自定義標識符
vrrp_instance VI_1 {
   state MASTER # 主節點為 MASTER ，備份節點為 BACKUP
   priority 100 # 節點優先級，MASTER 比 BACKUP 高
   interface ens33 # 綁定虛擬 IP 的網絡接口
   virtual_router_id 101 # 虛擬路由的 id ，兩個節點設置必須一樣
   advert_int 1 # 心跳報文發送間隔，默認 1s
   # 默認組播模式下，keepalived 所有的信息都會向 224.0.0.18 的組播地址發送，產生眾多的無用信息，并且可能會產生干擾和沖突
   # 可以使用單播模式，這是一種安全的方法，避免局域網內有大量的 keepalived 造成虛擬路由 id 的沖突
   unicast_src_ip 192.168.19.158  # 配置單播的源地址，本機 IP
   unicast_peer {
       192.168.19.159       # 配置單播的目標地址，其它 IP
   }
   # 設置驗證信息，兩個節點必須一致
   authentication {
       auth_type PASS
       auth_pass 123456
   }
   track_script {
       check_nginx # 執行 Nginx 監控的服務
   }
   # 虛擬 IP 池, 兩個節點設置必須一樣
   virtual_ipaddress {
       192.168.19.200 # 虛擬 ip，可以定義多個
   }
}

同樣的步驟，修改 lb2 節點的 keepalived.conf 內容為：

[root@lb2 keepalived]# cat keepalived.conf
! Configuration File for keepalived
global_defs {
   # # 通知郵件服務器的配置
   # notification_email {
   #     # 當 master 失去 VIP 的時候，會發一封通知郵件到 your-email@qq.com
   #     your-email@qq.com
   # }
   # # 發件人信息
   # notification_email_from keepalived@qq.com
   # # 郵件服務器地址
   # smtp_server 127.0.0.1
   # # 郵件服務器超時時間
   # smtp_connect_timeout 30
   # 唯一 id ，通常設置為 hostname
   router_id lb2
}
# 檢查nginx是否存活
vrrp_script check_nginx {
   script "/etc/keepalived/nginx_check.sh"
   interval 2 # 檢測時間間隔
   weight -20 # 檢測失敗（腳本返回非0）則權重 -20
}
# 定義虛擬路由，VI_1 為虛擬路由的自定義標識符
vrrp_instance VI_1 {
   state BACKUP # 主節點為 MASTER ，備份節點為 BACKUP
   priority 50 # 節點優先級，MASTER 比 BACKUP 高
   interface ens33 # 綁定虛擬 IP 的網絡接口
   virtual_router_id 101 # 虛擬路由的 id ，兩個節點設置必須一樣
   advert_int 1 # 心跳報文發送間隔，默認 1s
   # 默認組播模式下，keepalived 所有的信息都會向 224.0.0.18 的組播地址發送，產生眾多的無用信息，并且可能會產生干擾和沖突
   # 可以使用單播模式，這是一種安全的方法，避免局域網內有大量的 keepalived 造成虛擬路由 id 的沖突
   unicast_src_ip 192.168.19.159  # 配置單播的源地址，本機 IP
   unicast_peer {
       192.168.19.158       # 配置單播的目標地址，其它 IP
   }
   # 設置驗證信息，兩個節點必須一致
   authentication {
       auth_type PASS
       auth_pass 123456
   }
   track_script {
       check_nginx # 執行 Nginx 監控的服務
   }
   # 虛擬 IP 池, 兩個節點設置必須一樣
   virtual_ipaddress {
       192.168.19.200 # 虛擬 ip，可以定義多個
   }
}
[root@lb2 keepalived]#

在 global_defs 全局配置中，可以配置郵件通知，一旦 VIP 發生漂移（意味著主代理服務器發生了故障）就會發送郵箱通知我們去解決修復，而此時因為還有備代理服務器可以使用，不至于服務對外不可用。

整個配置的核心是在 vrrp_instance 虛擬路由的定義上，interface 指定綁定的網卡（節點 IP 所在的網卡）；keepalived 默認為組播模式，我們為其更改為了單播；virtual_ipaddress 定義了需要生成的 VIP 列表（指定了 192.168.19.200）。

而 track_script 則是我們 VIP 漂移得以正常運作的關鍵，我們設定了每 2s 就去執行一次 /etc/keepalived/nginx_check.sh 腳本：

#!/bin/bash
if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
killall keepalived
fi

腳本實際就是檢測代理軟件（nginx）是否存活，如果掛了，就執行 killall keepalived 將自身停止，相當于將 VIP 讓位給備服務器。

通常腳本里還會嘗試重啟一下代理軟件，如果重啟失敗，再考慮執行 kill

先給腳本執行權限，然后啟動 lb1 的 keepalived 服務：

[root@lb1 keepalived]# ls
keepalived.conf  nginx_check.sh
[root@lb1 keepalived]# chmod 744 nginx_check.sh
[root@lb1 keepalived]# systemctl start keepalived
[root@lb1 keepalived]# ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   inet 192.168.19.158/24 brd 192.168.19.255 scope global noprefixroute dynamic ens33
   inet 192.168.19.200/32 scope global ens33
[root@lb1 keepalived]#

啟動 lb2 的 keepalived 服務：

[root@lb2 keepalived]# ls
keepalived.conf  nginx_check.sh
[root@lb2 keepalived]# chmod 744 nginx_check.sh
[root@lb2 keepalived]# systemctl start keepalived
[root@lb2 keepalived]# ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   inet 192.168.19.159/24 brd 192.168.19.255 scope global noprefixroute dynamic ens33
[root@lb2 keepalived]#

可以從 ip a 命令看到，當前 VIP 192.168.19.200 位于 lb1 節點上。

此時訪問 VIP 192.168.19.200 ，相當于訪問 lb1 節點：

接著模擬故障，模擬當 lb1 代理服務掛掉后，lb2 能不能頂替上來使用，我們可以手動停止 lb1 節點的 nginx ：

[root@lb1 keepalived]# docker stop nginx
nginx
[root@lb1 keepalived]# ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   inet 192.168.19.158/24 brd 192.168.19.255 scope global noprefixroute dynamic ens33
[root@lb1 keepalived]#

此時發現，lb1 已經失去了 VIP 192.168.19.200 ，繼續看 lb2 ：

[root@lb2 keepalived]# ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   inet 192.168.19.159/24 brd 192.168.19.255 scope global noprefixroute dynamic ens33
   inet 192.168.19.200/32 scope global ens33
[root@lb2 keepalived]#

和預期一致，VIP 192.168.19.200 漂移到了 lb2 節點上。

再次訪問 VIP 192.168.19.200 ，服務依然可以正常調用，但是現在相當于在訪問 lb2 節點：

借助 keepalived ，我們成功實現了 nginx 代理的高可用，但是現在這種方案還是有缺陷的。

其實當前我們使用的是雙機主備方式（Active-Standby 方式），即備用服務器在正常情況下一直處于閑置狀態，這種方式不太經濟實惠。

對于雙機熱備，其實就是雙機高可用，還有另一種方案：雙主機方式（Active-Active 方式），即兩臺服務器互為主備狀態，任意一臺故障后，另一臺可以接管其流量。

雙主機方式

我們還是利用 keepalived 來實現雙主機方式。和之前的雙機主備方式不同的是，現在需要兩個 VIP 。

比如我們還是創建一個 VIP 為 192.168.19.200 ，正常情況下，該 VIP 綁定到 lb1 上；但是額外再創建一個 VIP 為 192.168.19.201 ，正常情況下，該 VIP 綁定到 lb2 上。

一旦 lb1 發生故障，VIP 192.168.19.200 立即漂移到 lb2 上；同樣的，lb2 發生故障，VIP 192.168.19.201 則立即漂移到 lb1 上。

而對于外部訪問端，我們可以適當分配，一部分客戶端調用 192.168.19.200 這個 VIP ，另一部分調用 192.168.19.201 。lb1 和 lb2 任意一個發生故障，對于外部訪問端都是可用狀態。

修改 lb1 節點的 keepalived.conf ：

! Configuration File for keepalived
global_defs {
   # # 通知郵件服務器的配置
   # notification_email {
   #     # 當 master 失去 VIP 的時候，會發一封通知郵件到 your-email@qq.com
   #     your-email@qq.com
   # }
   # # 發件人信息
   # notification_email_from keepalived@qq.com
   # # 郵件服務器地址
   # smtp_server 127.0.0.1
   # # 郵件服務器超時時間
   # smtp_connect_timeout 30
   # 唯一 id ，通常設置為 hostname
   router_id lb1
}
# 檢查nginx是否存活
vrrp_script check_nginx {
   script "/etc/keepalived/nginx_check.sh"
   interval 2 # 檢測時間間隔
   weight -20 # 檢測失敗（腳本返回非0）則權重 -20
}
# 定義虛擬路由，VI_1 為虛擬路由的自定義標識符
vrrp_instance VI_1 {
   state MASTER # 主節點為 MASTER ，備份節點為 BACKUP
   priority 100 # 節點優先級，MASTER 比 BACKUP 高
   interface ens33 # 綁定虛擬 IP 的網絡接口
   virtual_router_id 101 # 虛擬路由的 id ，兩個節點設置必須一樣
   advert_int 1 # 心跳報文發送間隔，默認 1s
   # 默認組播模式下，keepalived 所有的信息都會向 224.0.0.18 的組播地址發送，產生眾多的無用信息，并且可能會產生干擾和沖突
   # 可以使用單播模式，這是一種安全的方法，避免局域網內有大量的 keepalived 造成虛擬路由 id 的沖突
   unicast_src_ip 192.168.19.158  # 配置單播的源地址，本機 IP
   unicast_peer {
       192.168.19.159       # 配置單播的目標地址，其它 IP
   }
   # 設置驗證信息，兩個節點必須一致
   authentication {
       auth_type PASS
       auth_pass 123456
   }
   track_script {
       check_nginx # 執行 Nginx 監控的服務
   }
   # 虛擬 IP 池, 兩個節點設置必須一樣
   virtual_ipaddress {
       192.168.19.200 # 虛擬 ip，可以定義多個
   }
}
vrrp_instance VI_2 {
   state BACKUP
   priority 50
   interface ens33
   virtual_router_id 102
   advert_int 1
   unicast_src_ip 192.168.19.158
   unicast_peer {
       192.168.19.159
   }
   authentication {
       auth_type PASS
       auth_pass 123456
   }
   track_script {
       check_nginx
   }
   virtual_ipaddress {
       192.168.19.201
   }
}

lb2 節點的 keepalived.conf ：

! Configuration File for keepalived
global_defs {
   # # 通知郵件服務器的配置
   # notification_email {
   #     # 當 master 失去 VIP 的時候，會發一封通知郵件到 your-email@qq.com
   #     your-email@qq.com
   # }
   # # 發件人信息
   # notification_email_from keepalived@qq.com
   # # 郵件服務器地址
   # smtp_server 127.0.0.1
   # # 郵件服務器超時時間
   # smtp_connect_timeout 30
   # 唯一 id ，通常設置為 hostname
   router_id lb2
}
# 檢查nginx是否存活
vrrp_script check_nginx {
   script "/etc/keepalived/nginx_check.sh"
   interval 2 # 檢測時間間隔
   weight -20 # 檢測失敗（腳本返回非0）則權重 -20
}
# 定義虛擬路由，VI_1 為虛擬路由的自定義標識符
vrrp_instance VI_1 {
   state BACKUP # 主節點為 MASTER ，備份節點為 BACKUP
   priority 50 # 節點優先級，MASTER 比 BACKUP 高
   interface ens33 # 綁定虛擬 IP 的網絡接口
   virtual_router_id 101 # 虛擬路由的 id ，兩個節點設置必須一樣
   advert_int 1 # 心跳報文發送間隔，默認 1s
   # 默認組播模式下，keepalived 所有的信息都會向 224.0.0.18 的組播地址發送，產生眾多的無用信息，并且可能會產生干擾和沖突
   # 可以使用單播模式，這是一種安全的方法，避免局域網內有大量的 keepalived 造成虛擬路由 id 的沖突
   unicast_src_ip 192.168.19.159  # 配置單播的源地址，本機 IP
   unicast_peer {
       192.168.19.158       # 配置單播的目標地址，其它 IP
   }
   # 設置驗證信息，兩個節點必須一致
   authentication {
       auth_type PASS
       auth_pass 123456
   }
   track_script {
       check_nginx # 執行 Nginx 監控的服務
   }
   # 虛擬 IP 池, 兩個節點設置必須一樣
   virtual_ipaddress {
       192.168.19.200 # 虛擬 ip，可以定義多個
   }
}
vrrp_instance VI_2 {
   state MASTER
   priority 100
   interface ens33
   virtual_router_id 102
   advert_int 1
   unicast_src_ip 192.168.19.159
   unicast_peer {
       192.168.19.158
   }
   authentication {
       auth_type PASS
       auth_pass 123456
   }
   track_script {
       check_nginx
   }
   virtual_ipaddress {
       192.168.19.201
   }
}

其實就是在之前的基礎上增加了 VI_2 虛擬路由，創建 VIP 192.168.19.201 ，lb2 為主服務器，lb1 為備服務器。

重啟 lb1 節點的 keepalived 服務：

[root@lb1 keepalived]# systemctl restart keepalived
[root@lb1 keepalived]# ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   inet 192.168.19.158/24 brd 192.168.19.255 scope global noprefixroute dynamic ens33
   inet 192.168.19.200/32 scope global ens33
[root@lb1 keepalived]#

lb2 節點的 keepalived 服務：

[root@lb2 keepalived]# systemctl restart keepalived
[root@lb2 keepalived]# ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   inet 192.168.19.159/24 brd 192.168.19.255 scope global noprefixroute dynamic ens33
   inet 192.168.19.201/32 scope global ens33
[root@lb2 keepalived]#

對兩個 VIP 進行測試：

故障模擬，停止 lb2 節點的 nginx 代理服務：

[root@lb2 keepalived]# docker stop nginx
nginx
[root@lb2 keepalived]# ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   inet 192.168.19.159/24 brd 192.168.19.255 scope global noprefixroute dynamic ens33
[root@lb2 keepalived]#

查看 lb1 IP 信息，發現 VIP 192.168.19.201 已漂移到 lb1 上：

[root@lb1 keepalived]# ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   inet 192.168.19.158/24 brd 192.168.19.255 scope global noprefixroute dynamic ens33
   inet 192.168.19.200/32 scope global ens33
   inet 192.168.19.201/32 scope global ens33
[root@lb1 keepalived]#

再次對兩個 VIP 進行測試，仍然處于可用狀態：

到此，我們也實現了基于雙主機方式的高可用代理方案。

總結

高可用的核心就是做 “冗余” ，有了 “冗余” 后就得考慮做自動故障轉移，使 “冗余” 的實例可以快速頂替使用。

本文介紹了雙機主備方式和雙主機方式兩種方案來解決代理的高可用。但是軟件開發沒有銀彈，因為這兩種方案都是在一個局域網內進行的，還是有很大的不可控風險，如果再繼續優化，就得考慮同城雙活、異地雙活直至異地多活，而這些就必須得靠強大的基礎設施能力來支撐了。

責任編輯：龐桂玉來源：奇妙的Linux世界