说到高可用，咱们在应用主机环境的时候（非 k8s），咱做高可用有应用过这样的形式：
- 服务器做主备部署，当主节点和备节点同时存活的时候，只有主节点对外提供服务，备节点就等着主节点挂了之后，立即补位
- 另外为了提供服务的可用性，做了异地多活，减少服务的接入节点，对流量进行分流等
- 对于数据库同样也是做备份，定期同步，热备或者冷备
那么后面分享了那么多的对于 k8s 本身组件的原理，咱们能够回过来头看，咱们为什么要抉择 k8s ？
简略来说还是因为 k8s 本身的个性：
- 本身满足负载平衡
- 服务自愈
- 治理的服务还可横向扩容
- 降级的时候，可能滚动降级，平滑过渡，整个降级过程可能做到十分的丝滑，
- 若两头呈现降级异样，还能够一键回滚，在回滚过程中，亦不影响原有服务
这所有的所有，咱们在主机环境都是须要消耗很大的人力老本去做的事件，因此，最终才会抉择服务部署在 k8s 下面，能够极大的缩小开发和运维的心智累赘和运维老本
那么上述说的这么好， k8s 是如何保障高可用的呢？
高可用咱们能够从哪些方面思考呢？
从 pod 来看
从 pod 来看高可用的话，后面咱们有说到 pod 能够通过应用高级资源 Deployment 来进行治理，创立，更新，删除 pod ，应用 Deployment 都能够进行平滑的降级和回滚
当然默认说的这种形式是无状态的 pod
如果咱们是的服务是有状态的，运行在 pod 中，咱们依然能够应用 Deployment ，然而只能有 1 个正本，否则会有影响
如果带有数据卷的时候，咱们也能够应用 StatefulSet 资源来进行治理
然而若咱们的 pod 挂掉，咱们在 pod 重启到能够对外提供服务的过程中，服务会中断一段时间
有状态服务，无奈程度扩大的高可用形式
有状态的服务，无奈程度扩大，咱们也能够像最开始我说到的应用主备的这种做法来进行解决
相似的，咱们能够应用领导选举机制，来将多个同样的有状态服务中选举一个服务来对外解决申请
直到这个服务出现异常而宕机之后，应用同样的形式，来在剩下的服务中选举出一个无效的服务，来解决外来申请
具体的算法和 k8s 中的实现形式，我会在前面的文章中进行分享
从 etcd 来看
etcd ，咱们是应用主机环境的时候也有应用过 etcd
次要是用来寄存服务配置，和用来做服务发现的，key 值是服务的目录或者带有 / 的字符串， value 的话，则是服务的 ip 和 端口
etcd 自身就被设计成一个分布式的零碎，自身就能够运行多个 etcd 实例，天生做高可用就是很容易的事件
个别做集群，咱们会部署 3 个，5个 或者是 7 个，起因的话，能够尝试去看看 redis 集群部署一章的分享
能够看这个简图：
多 master ，多 worker 的简图
从 ApiServer 来看
从 ApiServer 来看的话，那就更简略的
这个组件自身无状态，且不缓存数据，他会间接和 本人独立的 etcd 进行通信，对于节点外面的组件，申请给到哪一个 master 外面的 ApiServer 都是能够的
因为 ApiServer 前面的 etcd 组件是分布式的，他们的数据是会跨实例复制数据的
在多 master 的时候，worker 和主节点通信的时候，是要通过一个负载均衡器的，这能够让多个节点的流量进行分流，同时还能够保障 worker 的申请能够正确的打到衰弱的 ApiServer 上
从 调度器 scheduler 和控制器管理器 controller manager 来看
对于 scheduler 和控制器管理器绝对就没有 ApiServer 那么简略和不便，因为他们会波及资源管理的抵触
对于他们来说，他们大部分都是在做监听工作，当有多个控制器监听了到 ApiServer 的中的资源变动
那么，例如 3 个 ReplicaSet 控制器，都监听了 ApiServer 将其对应的正本数减少 2 个
这个时候，3 个 ReplicaSet 控制器 都监听了，为了满足冀望，他们便会做满足冀望的事件，最终，环境外面会新产生 6 个 pod
天然，这是咱们所不期待的，这样搞岂不是乱套了，浪费资源
因而 对于控制器管理器和调度器和他们都会踊跃的监听集群的状态，为了防止不良竞争，还是要选用上述的相似主备的思维
给他们应用 --leader-elert 选项 ， 默认会进行选主，谁是主，谁就做理论的动作，做监听之后须要做的事件，其余的就等着这个主 死于非命
好了，明天就是这样
明天就到这里，学习所得，若有偏差，还请斧正
欢送点赞，关注，珍藏
敌人们，你的反对和激励，是我保持分享，提高质量的能源
好了，本次就到这里
技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。
我是阿兵云原生，欢送点赞关注珍藏，下次见~