部署kubernetes1.8.3高可用集群

Kubernetes作为容器应用的管理平台，通过对pod的运行状态进行监控，并且根据主机或容器失效的状态将新的pod调度到其他node上，实现了应用层的高可用。

针对kubernetes集群，高可用性还包含以下两个层面的考虑：

• etcd存储的高可用
• master节点的高可用

在开始之前，先贴一下架构图：

etcd作为kubernetes的中心数据库，必须保证其不是单点。不过etcd集群的部署很简单，这里就不细说了，之前写过一键部署脚本，有兴趣的同学可以往前翻。

在k8s全面容器化加上各种验证机制之前，master节点的高可用部署还算简单，现在k8s有了非常复杂的安全机制，在运维上增加了不小难度。

在kubernetes中，master扮演着总控中心的角色，主要有三个服务apiserver、controller-manager、scheduler，这个三个服务通过不断与node节点上的kubelet、kube-proxy进行通信来维护整个集群的健康工作状态，如果master的服务无法访问到某个node，则会将该node标记为不可用，不再向其调度pod。

Master的三个组件都以容器的形式启动，启动他们的基础工具是kubelet，他们都以static pod的形式启动，并由kubelet进行监控和自动启动。而kubelet自身的自启动由systemd完成。

APIserver作为集群的核心，负责集群各功能模块之间的通信，集群内的各个功能模块通过apiserver将信息存入etcd，当需要获取和操作这些数据时，则通过apiserver提供的rest接口来实现，从而实现各模块之间的信息交互。

APIserver最主要的rest接口是资源对象的增删查改，除此之外，它还提供了一类很特殊的rest接口KubernetesProxyAPI接口，这类接口的作用是代理rest请求，即apiserver把收到的rest请求转发到某个node上的kubelet守护进程的rest端口上，由该kubelet进程负责响应。在kubernetes集群之外访问某个pod容器的服务（http服务）时，可以用proxyAPI实现，这种场景多用于管理目的。

每个node节点上的kubelet每隔一个时间周期，就会调用一次apiserver的rest接口报告自身状态，apiserver接收到这些信息后，将节点状态信息更新到etcd。此外，kubelet也通过apiserver的watch接口监听pod信息，如果监听到新的pod副本被调度绑定到本节点，则执行pod对应的容器的创建和启动逻辑；如果监听到pod对象被删除，则删除本节点上的响应的pod容器；如果监听到修改pod信息，则kubelet监听到变化后，会相应地修改本节点的pod容器。

ControllerManager作为集群内部的管理控制中心，负责集群内的node、pod副本、endpoint、namespace、serviceaccount、resourcequota等得管理，当某个node意外宕机时，ControllerManager会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态。ControllerManager内部包含多个controller，每种controller都负责具体的控制流程。

ControllerManager中的NodeController模块通过apiserver提供的watch接口，实时监控node的信息，并做相应处理。Scheduler通过apiserver的watch接口监听到新建pod副本信息后，它会检索所有符合该pod要求的node列表，开始执行pod调度逻辑，调度成功后将pod绑定到目标节点上。

一般来说，智能系统和自动系统通常会通过一个被称为操作系统的机构来不断修正系统的工作状态。在kubernetes集群中，每个controller都是这样一个操作系统，它们通过APIserver提供的接口实时监控整个集群里的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试着将系统状态从“现有状态”修正到“期望状态”。

Scheduler的作用是将待调度的pod，包括通过apiserver新创建的pod及rc为补足副本而创建的pod等，通过一些复杂的调度流程计算出最佳目标节点，然后绑定到该节点上。

以master的三个组件作为一个部署单元，使用至少三个节点安装master，并且需要保证任何时候总有一套master能正常工作。

三个master点，两个lvs节点。

master01, etcd0  uy05-13  192.168.5.42
master02, etcd1  uy08-07  192.168.5.104
master03, etcd2  uy08-08  192.168.5.105

lvs01  uy-s-91  192.168.2.56
lvs02  uy-s-92  192.168.2.57

kubernetes version: 1.8.3
docker version: 17.06.2-ce
etcd version: 3.2.9
OS version: debian stretch

使用lvs+keepalived对apiserver做负载均衡和高可用。

由于controller-manager和scheduler会修改集群的状态信息，为了保证同一时间只有一个实例可以对集群状态信息进行读写，避免出现同步问题和一致性问题，这两个组件需要开启选举功能，并选举出一个leader，k8s采用的是租赁锁（lease-lock)。并且，apiserver希望这两个组件工作在同一个节点上，所以这两个组件需要监听127.0.0.1。

1、安装kubeadm、kubectl、kubectl。

# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

# aptitude update
# aptitude install -y kubelet kubeadm kubectl

2、部署第一个master节点，我直接使用了kubeadm来初始化，kubeadm的使用其实有一些技巧，这里我使用了一个配置文件：

# cat kubeadm-config.yml
apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
api:
  advertiseAddress: "192.168.5.42"
etcd:
  endpoints:
  - "http://192.168.5.42:2379"
  - "http://192.168.5.104:2379"
  - "http://192.168.5.105:2379"
kubernetesVersion: "v1.8.3"
apiServerCertSANs:
- uy05-13
- uy08-07
- uy08-08
- 192.168.6.15
- 127.0.0.1
- 192.168.5.42
- 192.168.5.104
- 192.168.5.105
- 192.168.122.1
- 10.244.0.1
- 10.96.0.1
- kubernetes
- kubernetes.default
- kubernetes.default.svc
- kubernetes.default.svc.cluster
- kubernetes.default.svc.cluster.local
tokenTTL: 0s
networking:
  podSubnet: 10.244.0.0/16

执行初始化：

# kubeadm init --config=kubeadm-config.yml
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.8.3
[init] Using Authorization modes: [Node RBAC]
[preflight] Running pre-flight checks
[preflight] WARNING: docker version is greater than the most recently validated version. Docker version: 17.06.2-ce. Max validated version: 17.03
[preflight] Starting the kubelet service
[kubeadm] WARNING: starting in 1.8, tokens expire after 24 hours by default (if you require a non-expiring token use --token-ttl 0)
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [uy05-13 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local uy05-13 uy08-07 uy08-08 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.5.42 192.168.6.15 127.0.0.1 192.168.5.42 192.168.5.104 192.168.5.105 192.168.122.1 10.244.0.1 10.96.0.1]
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated sa key and public key.
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] This often takes around a minute; or longer if the control plane images have to be pulled.
[apiclient] All control plane components are healthy after 29.002676 seconds
[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[markmaster] Will mark node uy05-13 as master by adding a label and a taint
[markmaster] Master uy05-13 tainted and labelled with key/value: node-role.kubernetes.io/master=""
[bootstraptoken] Using token: 2a8d9c.9b5a1c7c05269fb3
[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: kube-dns
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run (as a regular user):

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  http://kubernetes.io/docs/admin/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join --token 2a8d9c.9b5a1c7c05269fb3 192.168.5.42:6443 --discovery-token-ca-cert-hash sha256:ce9e1296876ab076f7afb868f79020aa6b51542291d80b69f2f10cdabf72ca66

kubeadm自动