当设置具有多个控制平面的集群时,可以通过将 API Server 实例置于负载均衡器后面并在运行 kubeadm init 以便新集群使用它时使用 --control-plane-endpoint 选项来实现更高的可用性。
当然,负载均衡器本身也应该具有高可用性。这通常是通过向负载均衡器添加冗余来实现的。为此,需要建立一个管理虚拟 IP 的主机集群,每个主机都运行一个负载均衡器实例,以便始终使用当前持有 vIP 的主机上的负载均衡器,而其他主机则处于备用状态。
在某些环境中,例如在具有专用负载平衡组件(例如由某些云提供商提供)的数据中心中,此功能可能已经可用。如果不是,可以使用用户管理的负载平衡。在这种情况下,在引导集群之前需要进行一些准备。
由于这不是 Kubernetes 或 kubeadm 的一部分,因此必须单独处理。在以下部分中,我们给出了对某些人有效的示例,当然还有可能有数十种其他可能的配置。
为了从虚拟 IP 提供负载平衡,keepalived 和 haproxy 的组合已经存在很长时间了,并且可以被认为是众所周知且经过充分测试的:
此组合可以作为操作系统上的服务运行,也可以作为控制平面主机上的静态 Pod 运行。两种情况下的服务配置是相同的。
keepalived 配置由两个文件组成:服务配置文件和健康检查脚本,该脚本将定期调用以验证持有虚拟 IP 的节点是否仍在运行。
假定这些文件位于 /etc/keepalived 目录中。但请注意,某些 Linux 发行版可能会将它们保留在其他地方。以下配置已成功用于 keepalived 版本 2.0.17:
! /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
router_id LVS_DEVEL
}
vrrp_script check_apiserver {
script "/etc/keepalived/check_apiserver.sh"
interval 3
weight -2
fall 10
rise 2
}
vrrp_instance VI_1 {
state ${STATE}
interface ${INTERFACE}
virtual_router_id ${ROUTER_ID}
priority ${PRIORITY}
authentication {
auth_type PASS
auth_pass ${AUTH_PASS}
}
virtual_ipaddress {
${APISERVER_VIP}
}
track_script {
check_apiserver
}
}
bash 变量样式中有一些占位符需要填写:
上面的 keepalived 配置使用健康检查脚本 /etc/keepalived/check_apiserver.sh 负责确保在持有虚拟 IP 的节点上 API Server 可用。该脚本可能如下所示:
#!/bin/sh
errorExit() {
echo "*** $*" 1>&2
exit 1
}
curl --silent --max-time 2 --insecure https://localhost:${APISERVER_DEST_PORT}/ -o /dev/null || errorExit "Error GET https://localhost:${APISERVER_DEST_PORT}/"
if ip addr | grep -q ${APISERVER_VIP}; then
curl --silent --max-time 2 --insecure https://${APISERVER_VIP}:${APISERVER_DEST_PORT}/ -o /dev/null || errorExit "Error GET https://${APISERVER_VIP}:${APISERVER_DEST_PORT}/"
fi
bash 变量样式中有一些占位符需要填写:
haproxy 配置由一个文件组成:服务配置文件,假定驻留在 /etc/haproxy 目录中。但请注意,某些 Linux 发行版可能会将它们保留在其他地方。以下配置已成功用于 haproxy 版本 2.1.4:
# /etc/haproxy/haproxy.cfg
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
log /dev/log local0
log /dev/log local1 notice
daemon
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 1
timeout http-request 10s
timeout queue 20s
timeout connect 5s
timeout client 20s
timeout server 20s
timeout http-keep-alive 10s
timeout check 10s
#---------------------------------------------------------------------
# apiserver frontend which proxys to the control plane nodes
#---------------------------------------------------------------------
frontend apiserver
bind *:${APISERVER_DEST_PORT}
mode tcp
option tcplog
default_backend apiserver
#---------------------------------------------------------------------
# round robin balancing for apiserver
#---------------------------------------------------------------------
backend apiserver
option httpchk GET /healthz
http-check expect status 200
mode tcp
option ssl-hello-chk
balance roundrobin
server ${HOST1_ID} ${HOST1_ADDRESS}:${APISERVER_SRC_PORT} check
# [...]
同样,bash 变量样式中有一些占位符可以扩展:
为了在操作系统上运行这两个服务,可以使用各自发行版的包管理器来安装软件。如果它们将在不属于 Kubernetes 集群的专用主机上运行,那么这是有意义的。
现在安装了上述配置,可以启用并启动服务。在最近的基于 RedHat 的系统上,systemd 将用于此目的:
# systemctl enable haproxy --now
# systemctl enable keepalived --now
服务启动后,现在可以使用 kubeadm init 引导 Kubernetes集群。
如果 keepalived 和 haproxy 将在控制平面节点上运行,则可以将它们配置为作为静态 Pod 运行。这里所需要做的就是在引导集群之前将相应的清单文件放置在 /etc/kubernetes/manifests 目录中。在引导过程中,kubelet 会启动进程,以便集群在启动时可以使用它们。这是一个优雅的解决方案,特别是使用堆叠控制平面和 etcd 节点中描述的设置。
对于此设置,需要在 /etc/kubernetes/manifests 中创建两个清单文件(首先创建目录)。
keepalived 的清单 /etc/kubernetes/manifests/keepalived.yaml:
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
name: keepalived
namespace: kube-system
spec:
containers:
- image: osixia/keepalived:2.0.17
name: keepalived
resources: {}
securityContext:
capabilities:
add:
- NET_ADMIN
- NET_BROADCAST
- NET_RAW
volumeMounts:
- mountPath: /usr/local/etc/keepalived/keepalived.conf
name: config
- mountPath: /etc/keepalived/check_apiserver.sh
name: check
hostNetwork: true
volumes:
- hostPath:
path: /etc/keepalived/keepalived.conf
name: config
- hostPath:
path: /etc/keepalived/check_apiserver.sh
name: check
status: {}
haproxy 的清单 /etc/kubernetes/manifests/haproxy.yaml:
apiVersion: v1
kind: Pod
metadata:
name: haproxy
namespace: kube-system
spec:
containers:
- image: haproxy:2.1.4
name: haproxy
livenessProbe:
failureThreshold: 8
httpGet:
host: localhost
path: /healthz
port: ${APISERVER_DEST_PORT}
scheme: HTTPS
volumeMounts:
- mountPath: /usr/local/etc/haproxy/haproxy.cfg
name: haproxyconf
readOnly: true
hostNetwork: true
volumes:
- hostPath:
path: /etc/haproxy/haproxy.cfg
type: FileOrCreate
name: haproxyconf
status: {}
请注意,这里需要再次填写占位符:${APISERVER_DEST_PORT} 需要保持与 /etc/haproxy/haproxy.cfg 中相同的值(见上文)。
该组合已成功地与示例中使用的版本一起使用。其他版本可能也可以工作,或者可能需要更改配置文件。
服务启动后,现在可以使用 kubeadm init 引导 Kubernetes 集群。