在多主模式下运行Kubernetes

时间:2017-07-26 10:24:47

标签: kubernetes kubelet

我在控制平面中设置了一个带有三台服务器的kubernetes(版本1.6.1)群集。 Apiserver使用以下配置运行:

/usr/bin/kube-apiserver \
  --admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota \
  --advertise-address=x.x.x.x \
  --allow-privileged=true \
  --audit-log-path=/var/lib/k8saudit.log \
  --authorization-mode=ABAC \
  --authorization-policy-file=/var/lib/kubernetes/authorization-policy.jsonl \
  --bind-address=0.0.0.0 \
  --etcd-servers=https://kube1:2379,https://kube2:2379,https://kube3:2379 \
  --etcd-cafile=/etc/etcd/ca.pem \
  --event-ttl=1h \
  --insecure-bind-address=0.0.0.0 \
  --kubelet-certificate-authority=/var/lib/kubernetes/ca.pem \
  --kubelet-client-certificate=/var/lib/kubernetes/kubernetes.pem \
  --kubelet-client-key=/var/lib/kubernetes/kubernetes-key.pem \
  --kubelet-https=true \
  --service-account-key-file=/var/lib/kubernetes/ca-key.pem \
  --service-cluster-ip-range=10.32.0.0/24 \
  --service-node-port-range=30000-32767 \
  --tls-cert-file=/var/lib/kubernetes/kubernetes.pem \
  --tls-private-key-file=/var/lib/kubernetes/kubernetes-key.pem \
  --token-auth-file=/var/lib/kubernetes/token.csv \
  --v=2 \
  --apiserver-count=3 \
  --storage-backend=etcd2

现在我正在使用以下配置运行kubelet:

/usr/bin/kubelet \
  --api-servers=https://kube1:6443,https://kube2:6443,https://kube3:6443 \
  --allow-privileged=true \
  --cluster-dns=10.32.0.10 \
  --cluster-domain=cluster.local \
  --container-runtime=docker \
  --network-plugin=kubenet \
  --kubeconfig=/var/lib/kubelet/kubeconfig \
  --serialize-image-pulls=false \
  --register-node=true \
  --cert-dir=/var/lib/kubelet \
  --tls-cert-file=/var/lib/kubernetes/kubelet.pem \
  --tls-private-key-file=/var/lib/kubernetes/kubelet-key.pem \
  --hostname-override=node1 \
  --v=2

只要kube1正在运行,这就很有效。如果我将kube1关闭,则节点不与kube2或kube3通信。它始终占用传递给--api-servers标志的第一个apiserver,并且在第一个apiserver崩溃时不会进行故障转移。 如果其中一个apiserver失败,那么进行故障转移的正确方法是什么?

2 个答案:

答案 0 :(得分:0)

不推荐使用--api-servers标志。它已不在documentation中。 kubeconfig是将kubelet指向kube-apiserver的全新方式。

今天做到这一点的犹太方法是在每个工作节点(即运行kubelet的节点)上部署一个带有nginx的Pod,它在3个kube-apiservers之间进行负载平衡。 nginx会知道一个主站何时发生故障并且没有将流量路由到它;这是它的工作。 kubespray项目使用这种方法。

第二种,不太好的方法,是使用DNS RR。创建一个DNS" A"记录3个主人的IP。将kubelet指向此RR主机名而不是3x IP。每次kubelet与主设备联系时,它将被路由到RR列表中的IP。此技术不健全,因为流量仍将路由到被击落的节点,因此群集将经历间歇性中断。

第三种更复杂的方法是使用keepalived。 keepalived使用VRRP确保至少一个节点拥有虚拟IP(VIP)。如果主人失败,另一位主人将劫持VIP以确保连续性。这种方法的坏处是负载平衡不是默认的。所有流量将路由到1个主站(即主VRRP节点),直到它发生故障。然后,辅助VRRP节点将接管。你可以看到nice write-up I contributed at this page:)

有关kube-apiserver HA here的更多详细信息。祝你好运!

答案 1 :(得分:0)

目前,直到1.8,最好的解决方案似乎是使用负载平衡器,如已经建议的那样。

请参阅https://github.com/sipb/homeworld/issues/10