Kubernetes集群管理

由于之前搭建的Kuberntes集群是单Master的，且存在高可用风险，故在此基础上升级Kubernetes版本的同时搭建Kubernetes高可用集群。同时为了后续管理方便，再额外部署Metrics Server和dashboard。

一、高可用集群模型

1.1 堆叠etcd

这是kubeadm部署Kubernetes集群的默认拓扑(也是此次使用的)。在此架构中，每个Master节点均部署一个etcd，这个etcd仅与本地的API Server进行通信。这种拓扑将控制平面和 etcd 成员耦合在同一节点上。与使用外部 etcd 集群相比，设置起来更简单，而且更易于副本管理。然而堆叠集群存在耦合失败的风险。如果一个节点发生故障，则 etcd 成员和控制平面实例都将丢失，并且冗余会受到影响。可以通过添加更多控制平面节点来降低此风险。应该为 HA 集群运行至少三个堆叠的控制平面节点（防止脑裂）。

1.2 外部etcd

在此架构中，etcd分布式数据存储集群在独立于控制平面节点之外的其它节点运行，每个etcd都与每个控制平面节点的API Server通信。这种拓扑结构解耦了控制平面和 etcd 成员。但是，由于etcd单独运行在其它节点，故此拓扑需要两倍于堆叠 HA 拓扑的主机数量。

二、高可用平面部署架构

首先使用一个FQDN作为API Server的接入点，在加入集群之前每个Node节点都将该FQDN解析至首个Master节点。在加入集群之后，每个Master都将FQDN解析至自身的IP地址。之后，在每个Node节点部署Nginx/Haproxy对多个API Server进行代理(这里的做法)，当然也可以借助keepalived为Master节点做一个漂移IP，同时在Master节点部署Nginx/Haproxy配合使用。

三、高可用集群搭建过程

3.1 Kubernetes版本升级

升级之前记得先禁止调度器调度过来新的Pod，还要驱逐要升级节点上的Pod。

kubectl cordon && kubectl drain

检查集群是否可升级，并获取升级的版本。

kubeadm upgrade plan

这里获取到最新版本为v1.27.4。执行上面的kubeadm upgrade apply命令

kubeadm upgrade apply v1.27.4

执行过程中报了这么一个错误：

FATAL: the --version argument is invalid due to these errors:
 - Specified version to upgrade to "v1.27.4" is higher than the kubeadm version "v1.27.1". Upgrade kubeadm first using the tool you used to install kubeadm

原因是升级的版本高于kubeadm的版本，所以我们升级的版本一定要与kubeadm版本保持一致。

这里先安装kubectl、kubeadm、kubelet这些组件的最新版(Master、Node节点都执行)

apt -y update && apt -y install kubelet kubeadm kubectl

再次kubeadm upgrade apply命令就成功了。

3.2 加入Master节点

在192.168.131.12、192.168.131.13(两台新加入的master节点)执行加入Master节点命令：

kubeadm join kubeapi.wxd.com:6443 --token fd6tqp.22mkd4b0c5t69osd --discovery-token-ca-cert-hash sha256:1d3734d0ccd815b02083a8340dc4240cbe4eb65c8b016c5680652bdee0811836 --control-plane --certificate-key b479316972c25df29e279af561ceea3baa6c6d0fbdc79a726c4bf1f787f686a0 --cri-socket unix:///run/cri-dockerd.sock

加入主节点时又出现如下错误：

error execution phase kubelet-start: error uploading crisocket: Unauthorized

解决方法：
      先重置集群

kubeadm reset --cri-socket unix:///run/cri-dockerd.sock && rm -rf /etc/kubernetes/ /var/lib/kubelet /var/lib/dockershim /var/run/kubernetes /var/lib/cni /etc/cni/net.d

之后根据提示执行如下命令

iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X 或者
ipvsadm --clear

之后再加入主节点就成功了。

由于Pod网络的地址范围(--pod-network-cidr)设为10.244.0.0/16，正好是Flannel网络插件的默认值，接下来就直接部署Flannel网络插件即可(每个master节点)。具体参考https://blog.51cto.com/u_15796303/6236894

3.3 加入Node节点

在Node节点执行如下操作：

kubeadm join kubeapi.wxd.com:6443 --token fd6tqp.22mkd4b0c5t69osd --discovery-token-ca-cert-hash sha256:1d3734d0ccd815b02083a8340dc4240cbe4eb65c8b016c5680652bdee0811836 --cri-socket unix:///run/cri-dockerd.sock

3.4 设置将对应的域名解析至Master节点本身

此时，解析kubeapi.wxd.com仍然指向第一个Master节点的IP。这里在每个Master节点将kubeapi.wxd.com解析至Master自身IP地址。比如，在192.168.131.12的/etc/hosts做如下解析(同样的，其它两个Master节点也将自身IP映射到kubeapi.wxd.com这个域名)，这样就可以使用自身的API Server。

192.168.131.12 k8s-master2 kubeapi.wxd.com

3.5 Node节点配置Nginx

在nginx.conf添加如下配置：

stream {
        upstream apiservers {
                server k8s-master1:6443 max_fails=2 fail_timeout=30s;
                server k8s-master2:6443 max_fails=2 fail_timeout=30s;
                server k8s-master3:6443 max_fails=2 fail_timeout=30s;
        }
        server {
                listen 6443;
                proxy_pass apiservers;
        }
}

由于这里监听的是0.0.0.0:6443，不是本机(127.0.0.1)的6443端口，这里就将kubeapi.wxd.com映射到Node节点的IP上(方法与上面的域名解析至Master节点相同，确保kubeapi.wxd.com解析到本地)。此时Node节点向API Server发起请求是借助于本地的Nginx来完成的，由Nginx反代给三个API Server以完成通信。

四、部署Metrics Server

在新版的Kubernetes中，系统资源的采集均使用Metrics-Server服务，可以通过Metrics-Server服务采集节点和Pod的内存、磁盘、CPU和网络的使用率等信息。
       Kubernetes提供了 top 命令可用于统计资源使用情况，它包含有 node 和 pod 两个子命令，分别显示Node 节点和 Pod 对象的资源使用信息。
       kubectl top 命令依赖于 metrics 接口。k8s 系统默认未安装该接口，需要单独部署。

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

此时，用describe查看Pod详情，发现探针问题：Readiness probe 500错误

查看Pod日志，发现x509: cannot validate certificate这个问题。可以确定pod异常是因为：Readiness Probe 探针检测到 Metris 容器启动后对 http Get 探针存活没反应。具体原因是x509: cannot validate certificate for 192.168.131.14 because it doesn't contain any IP SANs" node="k8s-node1"

查看Metrics Server的说明，有这么一段内容：

Kubelet certificate needs to be signed by cluster Certificate Authority (or disable certificate validation by passing --kubelet-insecure-tls to Metrics Server)

意思是：Kubelet证书需要由集群证书颁发机构签名（或通过向Metrics Server传递参数--kubelet-insecure-tls来禁用证书验证）

下载这个components.yaml，在components.yaml的139 行的位置追加参数：--kubelet-insecure-tls

再次apply之后查看Pod详情，发现Pod就能正常运行，kubectl top命令也可以运行了。

五、部署dashboard

wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

打开recommended.yaml，做如下配置：

kubectl apply -f recommended.yaml

此时，访问https://NodeIP:NodePort即可看到登录界面。需要我们配置kubeconfig或输入token，这里我们选择后者，通过以下命令获取输出的token。

#创建dashboard管理用户
kubectl create serviceaccount dashboard-admin -n kube-system
#绑定集群角色
kubectl create clusterrolebinding dashboard-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin
#获取用户token
kubectl create token dashboard-admin -n kube-system

之后使用生成的token登录dashboard即可。