etcd就不说了,奇数个副本,可以坏(n-1)/2个,但是不可能同时坏那么多,这里不讨论etcd单独不单独跑。
先说说k8s组件,kubelet和kube-proxy啥的肯定写LB或者VIP:HA_port,如官方的图sched
官方文档这说得基本有疑问的都写清楚了,前期scheduler和controller不支持ha,后来增加了选举功能,他俩连apiserver的ip写127.0.0.1和负载均衡器都可以
apiserver这块介绍比较少,但是可以根据kubeadm部署的推理一些猜测。
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
certSANs:
- "LOAD_BALANCER_DNS"
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
controlPlaneEndpoint
:应匹配负载均衡器的地址或DNS和端口
而这个controlPlaneEndpoint
实际上最终会取ip(注意不带端口)写到kube-apiserver的选项--advertise-address
作为值。
默认情况下--advertise-address
不配置将会和--bind-address
一样。它的作用就是宣告,在etcd启动后kube-apiserver初次起来后会创建一个svc名叫kubernetes
,而这个svc的endpoints就是选项--advertise-address
的ip,port则是apiserver的--secure-port
。假设用户配置的--secure-port
为6443,所以一般云上SLB的话那这个宣告可以填写LB的ip,然后默认的kubernetes的endpoints是<SLB_IP>:6443。
截止到现在似乎都没有啥坑,但是这几天写生产环境的部署方案的时候,因为考虑到多网卡,而kubeadm部署的默认很多组件是bind 0.0.0.0的会导致所有网卡的ip的请求都会监听。于是我--bind-address
写网卡ip例如三台分别是172.16.1.2、3、4,HA用的keepalived+haproxy,vip是5。因为master
而坑就是宣告,我仿照官方意见--advertise-address
写了VIP(带不了端口,否则报错)。启动了apiserver后默认宣告kubernetes的ep是VI
写node的网卡ip后,apiserver存活期间会去更新ep的ttl,只要apiserver 宕了它的ep会因为没有刷新ttl而被自动剔除。这个想法是issue里看到别人提到
[[email protected] ~]# systemctl stop kube-apiserver
[[email protected] ~]# kubectl get ep
NAME ENDPOINTS AGE
kubernetes 172.16.1.3:6443,172.16.1.4:6443 24h
[[email protected] ~]# kubectl get ep
NAME ENDPOINTS AGE
kubernetes 172.16.1.3:6443,172.16.1.4:6443 24h
[[email protected] ~]# kubectl get ep
NAME ENDPOINTS AGE
kubernetes 172.16.1.3:6443,172.16.1.4:6443 24h
[[email protected] ~]# systemctl restart kube-apiserver
[[email protected] ~]# kubectl get ep
NAME ENDPOINTS AGE
kubernetes 172.16.1.10:6443,172.16.1.3:6443,172.16.1.4:6443 24h
参考文献
https://github.com/etcd-io/etcd/tree/master/Documentation/op-guide
https://kubernetes.io/zh/docs/admin/high-availability/#%E8%BF%9B%E8%A1%8Cmaster%E9%80%89%E4%B8%BE%E7%9A%84%E7%BB%84%E4%BB%B6
https://kubernetes.io/docs/setup/independent/high-availability/
正看得欢 , 发现看到末尾戛然而止