运维复盘—高可用K8S的VIP原理

在项目的开发运维过程中，我们定期查看环境运行的状态，发现K8S集群的命令全部出现了问题，通过问题定位发现是许可问题，问题到位后对其加以解决。

对于运维或者开发项目来说，定期地查看环境的状态格外重要，因此我们要早发现、早定位、早解决。现对这次环境的深入了解进行详细记录，输出为文档，也为后续的工作做出沉淀。

1事情经过

通过使用UMC产品发现很多集群的信息都消失不见了，产品无法部署和查看日志，虽然这个问题很难定位，但是经过层层处理，最后解决了这个问题。

1.1情况反馈

在使用UMC产品时，我们的开发人员反馈UMC上关于集群的信息都消失了，并且对于容器的创建、删除和更新操作也都没有反应，因为环境为开发环境，所以这个情况非常紧急，需要尽快解决。

1.2问题定位

因为产品没法启动，点击操作也没有反应，因此第一次我怀疑可能是许可问题，因为产品还是在集群上运行，只是没法查看信息，但是这个集群已经做过了K8S集群到期时间的延长操作，我也怀疑可能是K8S延长操作没有做全面。

输入命令查看授权文件的日志发现没有到期，所以我在这里重启了K8S集群和docker镜像库，这时发现命令已经全部好用。

1.3后续规划

虽然已经解决了问题，但是解决的过程也是非常惊险的，因为目标环境是正在运行的生产环境，如果操作不当会造成不可挽回的损失，也暴露出来自己对集群的了解还是不够，难以快速定位问题。

2升级许可 

之前的文件有着很多漏洞，尽管给许可进行过升级但还是时间过期，所以对之前的许可升级进行补充。 

2.1许可查看 

首先输入如下命令进行许可的查看，After是许可到期的时间： 

2.2许可替换 

1.首先进行许可文件备份，防止操作不当难以还原： 

2.到/usr/bin目录，上传替换kubeadm： 

3.给kubeadm进行授权： 

4.更新证书： 

5.再次检查当前K8S证书有效期，查看After时间： 

2.3生成证书 

1.虽然kubeadm文件已经替换了但是证书并没有生成，所以我们还需要重新生成证书。 

其他master也是这样操作。 

2.最后进行docker和K8S的重启，这样才能让证书生效： 

3遇到问题 

在本次对项目环境的调整中，出现不少的问题，但是其实有很多问题都是可以避免的，以下进行具体讲解。 

3.1授权问题 

在初次发现问题时，已经进行了kubeadm的替换，但是没有进行证书的生成，admin文件主要控制权限相关，并没有重新生成，所以导致K8S命令失效。 

运行如下命令进行证书的重新生成： 

然后进行docker和K8S的重启就能解决问题。 

3.2地址问题 

1.重新生成的admin.conf文件指向的地址是master1的地址，如果是三台的环境还好说，因为不存在高可用的情况，但是五台或者多台就不一样了，所以我们首先创建K8S重新生成的配置文件： 

2.红色的信息为K8S的版本和地址，然后运行如下命令，指定特定的ip加端口生成配置文件： 

3.指定文件后便会生成特定ip加端口的地址。 

3.3命令问题 

1.admin文件主要存放两个位置，一个是初始化的位置，主要控制root用户的权限问题，另一个放置主要控制非root用户的权限问题。 

2.在生成admin文件后，我们发现在cmd上运行命令都是可以的，但是在UMC上调用api接口执行命令和远程执行命令都是失败的，因为我们并没有给.kube文件夹的admin文件进行替换。 

首先创建./kube文件夹，把admin.conf文件复制到文件夹中，最后进行文件的授权，这时候我们会发现非root用户也是可以运行命令。 

4集群相关 

因为项目的环境是五台的一个高可用的环境，通过本次的运维也对集群高可用的原理进行了解。 

4.1授权文件 

kubeclt通过授权文件连接K8S集群。 

1.K8S开放两个端口一个是8080端口，另一个是6443端口，8080 这个端口是K8S api（kube-apiserver非安全端口）的端口，在master上面可以执行成功其实走的是配置文件，对外端口是6443，这个是kube-apiserver监听的端口，即masterip:6443安全端口。 

2.Context指定上下文，和指定当前使用哪个上下文。 

3.在配置文件当中可能会存在多个集群，现在只有一个集群是我刚刚搭建的，如果再搭建一个集群是可以将两个配置文件进行合并的，将两个配置文件合并在一个配置文件里面。合并在一起后就可以使用这一个配置文件去切换着连接两个不同的集群，切换的操作实际上就是指定上下文的操作。（上下文引用了集群信息和客户端信息）。 

4.2集群高可用 

K8S通过虚拟ip和haproxy进行高可用和负载均衡。 

1.keepalived提供虚拟ip，虚拟ip指向一个真实的ip，虽然可以实现高可用，但是并没有实现负载均衡，当访问量大的时候只会有一台机器进行访问。 

2.并且我们需要haproxy进行负载均衡，K8S开放6443端口，haproxy代理master节点的ip和6443端口。 

3.Haproxy开放16443端口，再通过虚拟ip实现高可用和负载均衡，让每一台服务器的性能得到最优化。 

4.3系统组件 

1.kube-apiserver：kube-apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制，负责接收、解析、处理请求。它公开了Kubernetes API是Kubernetes master节点的前端，kube-apiserver被设计成可以进行自动扩缩容。 

2.kube-scheduler：kube-scheduler主要是负责pod的调度，用来监视已经被创建但是没有调度到node节点的pod，然后按照预定的调度策略（如亲和性，反亲和性等）将Pod调度到相应的node节点上。 

3.kube-controller-manager：控制器管理器，用来检测控制器健康状态的，控制器是负责维护集群的状态，检查pod的健康状态，比如故障检测、自动扩展、滚动更新等一些操作。 

4.etcd：是一个key/value形式的键值存储数据库，保存了整个kubernetes集群的各种对象的状态和元信息配置状态，在kubernetes中使用etcd时，需要对etcd做备份，保证高可用。kubernetes系统中一共有两个服务需要用到etcd，用etcd来协同和存储配置。 

5.kube-proxy：K8S代理，是在集群中的每个节点上运行的网络代理，kube-proxy负责请求转发，一旦发现了某一个Service关联的Pod信息发生了改变（如IP、Port等），由Kube-Proxy就会把变化后的service转换成IPVS或IPtables规则中，完成对后端pod的负载均衡。 

6.cordns：coredns是一个DNS服务器，能够为Kubernetes services提供DNS记录。 

5心得总结 

接下来我会从个人理解、个人收获和心得总结三个方面介绍本次运维的心得体会。 

5.1个人理解 

通过此次的运维让我学到面对项目的问题时应该怎么应对，尽管本次处理的并不是那么得心应手，但是我也在能力方面有了很大的提升，也让我对项目有了更深的理解，同时也让我以后面对问题时也不那么胆怯了。 

5.2个人收获 

在本次的运维中，让我通过项目进一步地学习升级许可文件的步骤，并且也让我更加懂得了k8S集群的高可用的原理和负载均衡的原理，以及怎么利用keepalived和harpoxy进行实现。 

5.3心得总结 

通过此次的运维和学习也让我感受到了自己的不足，对于技术只是知道往往是不够的，还需要精通，要从多方面进行考虑，不能太局限，要学会从场景入手，慢慢的便能对这方面得心应手。 

在后续的工作中，要学会沉淀，光学不练假把式，了解某个知识点就要盘根问底，熟练地掌握才会提高自己的工作效率，也会让自己在后续处理问题时能够更加得心应手。