【k8s 系列】k8s 学习二十七 - 7,k8s 自身原理之高可用

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 说到高可用,咱们在使用主机环境的时候(非 k8s),咱做高可用有使用过这样的方式:• 服务器做主备部署,当主节点和备节点同时存活的时候,只有主节点对外提供服务,备节点就等着主节点挂了之后,立刻补位

【k8s 系列】k8s 学习二十七 - 7,k8s 自身原理之高可用

说到高可用,咱们在使用主机环境的时候(非 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 的简图

image.png

从 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 选项 , 默认会进行选主,谁是主,谁就做实际的动作,做监听之后需要做的事情,其他的就等着这个主 寿终正寝

好了,今天就是这样

今天就到这里,学习所得,若有偏差,还请斧正


欢迎点赞,关注,收藏

朋友们,你的支持和鼓励,是我坚持分享,提高质量的动力

image.png

好了,本次就到这里

技术是开放的,我们的心态,更应是开放的。拥抱变化,向阳而生,努力向前行。

我是阿兵云原生,欢迎点赞关注收藏,下次见~

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
1月前
|
存储 Kubernetes 持续交付
k8s学习
【10月更文挑战第1天】
84 4
|
22天前
|
Kubernetes 关系型数据库 MySQL
Kubernetes入门:搭建高可用微服务架构
【10月更文挑战第25天】在快速发展的云计算时代,微服务架构因其灵活性和可扩展性备受青睐。本文通过一个案例分析,展示了如何使用Kubernetes将传统Java Web应用迁移到Kubernetes平台并改造成微服务架构。通过定义Kubernetes服务、创建MySQL的Deployment/RC、改造Web应用以及部署Web应用,最终实现了高可用的微服务架构。Kubernetes不仅提供了服务发现和负载均衡的能力,还通过各种资源管理工具,提升了系统的可扩展性和容错性。
62 3
|
1月前
|
Kubernetes 应用服务中间件 nginx
k8s学习--YAML资源清单文件托管服务nginx
k8s学习--YAML资源清单文件托管服务nginx
k8s学习--YAML资源清单文件托管服务nginx
|
1月前
|
Kubernetes 监控 测试技术
k8s学习--基于Ingress-nginx实现灰度发布系统
k8s学习--基于Ingress-nginx实现灰度发布系统
106 2
k8s学习--基于Ingress-nginx实现灰度发布系统
|
1月前
|
Prometheus Kubernetes 监控
k8s学习--kubernetes服务自动伸缩之水平伸缩(pod副本伸缩)HPA详细解释与案例应用
k8s学习--kubernetes服务自动伸缩之水平伸缩(pod副本伸缩)HPA详细解释与案例应用
107 1
k8s学习--kubernetes服务自动伸缩之水平伸缩(pod副本伸缩)HPA详细解释与案例应用
|
1月前
|
存储 Kubernetes 调度
|
1月前
|
Kubernetes Cloud Native 微服务
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
110 1
|
1月前
|
Kubernetes API 调度
k8s学习--pod的所有状态详解(图例展示)
k8s学习--pod的所有状态详解(图例展示)
142 1
|
1月前
|
Kubernetes JavaScript 前端开发
k8s学习--chart包开发(创建chart包)
k8s学习--chart包开发(创建chart包)
102 1
|
1月前
|
Kubernetes 应用服务中间件 nginx
k8s学习--Traffic Shifting 流量接入
k8s学习--Traffic Shifting 流量接入
下一篇
无影云桌面