Home
Download
Document
Forum
Video
Donate
Source Code
Sponsors
AI 助理
Products
Swoole-Compiler
CRMEB 新零售社交电商系统
Vprix 远程桌面系统
Login
Register
全部
提问
分享
讨论
建议
公告
开发框架
CodeGalaxy
发表新帖
CodeGalaxy K8s 云原生高可用架构介绍
从 `CodeGalaxy` 平台`5月初`上线至今已经`2个月`的时间,在这`2个月`中有累计 `316` 个项目部署到了我们的平台,正在的运行的实例超过了`560`个,近`200`多个域名接入。随着用户逐渐将一些实际项目部署到 `CodeGalaxy` 平台,大家对于 `CodeGalaxy` 的`K8s` 云原生架构高可用问题越来越关注,`CodeGalaxy` 是如何保证系统的可靠性、稳定性的,另外相比于传统基于 `ECS` 云主机 `Nginx + PHP/Golang/Java` 的架构,`K8s` 有哪些优势也是大家非常关心的问题。本文会详细讲述 `CodeGalaxy K8s` 云原生高可用架构设计的细节,让各位开发者对云原生技术有一个更深入的理解,更好地使用 `CodeGalaxy K8s` 云原生技术构建企业的系统架构。 CodeGalaxy 系统官网:https://code-galaxy.net/ ## 整体架构 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c67f525e382.png) 1. DNS 解析为 `SLB IP` 地址,由 SLB 进行四层代理负载均衡,将 TCP 连接和数据转发给 K8s 集群中的 `Ingress Controller` 2. `Ingress Controller` 作为七层代理,解析 HTTP 协议,根据不同的 `Host` 将请求负载均衡转发给 K8s 集群中对应的`WorkLoad`,也就是 CodeGalaxy 应用的具体实例 3. 工作负载一般多有多个 Pod,请求会随机转发给其中一个 Pod 进行处理 4. Pod 处理过程中会再次请求其他的 Service 或者读取后端数据库存储、缓存或其他中间件 ## SLB(`Server Load Balancer`) CodeGalaxy 在接入层使用了云厂商(阿里云、腾讯云等)的 SLB 服务作为四层代理和负载均衡器,边缘网络请求应用前,先通过域名解析获得 SLB 的 IP 地址。SLB 一般是使用 `LVS + KeepAlived` 实现,虽然 SLB 解析出来的 IP 只有一个,但实际上 SLB 是一个集群,以保证高可用,SLB 集群当前的节点不可用时,会自动通过 IP 漂移切换到另外一台机器,实现故障转移。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6806ae8309.png) `SLB` 会将收到的请求负载均衡到后端服务器(`Real Sever`)。在 `Code-Galaxy K8s` 架构中, `Real Server` 就是 K8s 集群的 Node 节点。在每个 `K8s Node` 上都部署了 `Nginx Ingress Controller` 来作为七层代理,处理 `HTTP/WebSocket` 请求。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c680795ea70.png) ## Ingress Controller CodeGalaxy 使用 `Nginx Ingress Controller` 作为七层代理,转发请求给 K8s 集群的实例 Pod 容器组。K8s 集群的所有节点默认都会启动 `Nginx Ingress Controller` 实例,并自动注册到 SLB ,作为 `SLB` 的 `Real Server` 节点。`Nginx Ingress Controller` 使用了 `K8s Host Network`,直接使用宿主机的物理网卡监听端口,中间没有任何流量转发器,减少了性能损耗。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6809f72ae8.png) 当`Nginx Ingress Controller` 集群中的某个节点故障不可用时,会被 `SLB` 将自动剔除,保证了高可用。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c680cc2fcfa.png) ## K8s 集群 `K8s 集群`由 `Master 集群` 和 `Worker 集群` 组成,`Master 集群`为控制面(`Control Plane`),`Worker 集群`为数据面(`Data Plane`)。所有 `K8s 集群` 的元数据都会保存在 `ETCD` 分布式存储中,默认 `Master 集群`的每个节点都会部署 `ETCD`,也可以配置使用外部的 `ETCD` 集群。为了保证高可用,`Master 集群`至少要有`3`台以上机器。`ETCD` 使用 `Raft` 协议实现了分布式数据一致性。当某个节点出现故障时,数据不会丢失。集群依然可以运行。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6810602f8a.png) 应用实例的容器组(`Pod`)会被调度到 `Worker 集群`去执行。当 `Worker 集群` 中的一个节点机器出现故障时,`K8s` 会在`Worker 集群` 其他存活的节点上重新启动 `Pod`,保证高可用。 ## 应用实例 CodeGalaxy 平台应用的实例使用了 `K8s` 的 `Deployment` 来管理`Pod`。实例的 `Pod` 会被 `K8s` 根据节点负载状况随机调度到任意一个 `K8s`的 `Worekr 集群` 节点上启动。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c68121ccded.png) 每个实例对外使用 `Service` 地址作为服务入口,并作为`Ingress Controller`的`Upstream`,当请求应用绑定的域名时,会自动转发给对应的`Service`。 实例至少要设置 `2` 个或以上副本。当其中一个 `Pod` 发生故障或者崩溃退出时,`Service` 会停止向不可用的 `Pod` 发送请求。与此同时`K8s` 会重新调度,启动新的 `Pod` 。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c68135ac0c9.png) ## 弹性伸缩 除了固定副本的模式外,CodeGalaxy 也提供了 K8s 弹性伸缩(`HPA`)的功能,具体技术细节可以查看 K8s HPA的相关文档。在一些突发事件带来大量请求的情况下,当前的 `Pod` 数量无法支撑如此大的请求量。这时就会出现大量 `502/503` 错误。导致 `Web` 应用的服务不可用。这时可以启用弹性伸缩功能解决问题。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6814fdf5a1.png) 进入应用的实例中,选择“设置伸缩”,可以选择一个已有的弹性伸缩模版,如果没有合适的模版,也可以创建一个新的弹性伸缩模版。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6815c083f3.png) 弹性伸缩的参数设置可以参考 K8s HPA 文档。通过设置弹性伸缩模版就可以在实例的 `Pod` 负载过高,`CPU`和`内存`超过一定水位线后自动扩容,增加更多 `Pod`,提供更强的处理能力。在 Pod 负载降低后又会自动减少 `Pod` 数量。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6816b3043f.png) ## 配置和环境变量 在服务端应用中我们经常需要读取一些配置文件,例如`MYSQL`数据库主机和端口、用户名、密码,`Redis`服务器的地址等等。在没有使用`K8s`之前,很多项目会将配置以文件的方式保存在服务器上,或者存入`MySQL`数据库,使用时进行读取,还有一些项目使用 `Nacos`、`Apollo`等配置中心服务来管理配置。 在使用`K8s`架构之后,可以直接使用`K8s ConfigMap/Secret` 来存储配置,然后通过持久存储卷(`Persistent Volumn`),将配置映射为一个磁盘文件。也可以把配置作为环境变量传递给应用层。 在 CodeGalaxy 系统中,可以在实例中直接设置环境变量,应用程序中可以使用 `getenv` 系统调用获取配置。也可以在持久化存储中选择新建 `ConfigMap/Secret`,并映射为磁盘文件,挂载到系统中,应用程序中可以通过读取文件的方式获得配置。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c68250e0a56.png) ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6826cd6438.png) 环境变量、`ConfigMap`、`Secret`底层实现上是保存在了 `K8s` 的 `ETCD 分布式存储`中,可以保证数据可用性。 ## PVC 持久化存储 在 K8s 中 Pod 是非持久化的,当容器崩溃或者发生调度时 Pod 的生命周期就结束了,容器内的所有文件系统内容将会被丢弃,Pod 重启之后仍然会恢复到镜像中的内容。如果实例希望持久化存储文件内容,就需要使用 K8s 提供的PVC(`Persistent Volume Claim`)。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c68d5d44445.png) CodeGalaxy 系统使用云厂商提供的`NFS`服务作为 PVC 的存储后端,保证了文件内容的可靠性。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c682982e66d.png) 创建 PVC 之后,挂载到实例中即可。所有 Pod 均可读取 PVC 中的数据,内容是共享的。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c682a205bd6.png) ## 结语 `K8s`云原生技术提供了一套以云为基础、天然的分布式架构。使用`K8s`可以帮助企业建立高可用的服务端架构,高效率、低成本、规范的`IT`研发系统。 `Code-Galaxy`在`K8s`技术之上整合了多个开源项目,提供了简单易用的用户界面,使得`K8s`使用起来更简单。基于`Code-Galaxy`系统可以在没有任何`K8s`技术积累的团队也可以快速落地`K8s`云原生技术架构方案,让用户可以零成本升级到`K8s`云原生架构,快速体验云原生技术带来的高效、便捷。 ## 参考: 1. 阿里云 SLB:https://help.aliyun.com/document_detail/27544.html 2. k8s-集群里的三种IP:https://blog.csdn.net/qq_21187515/article/details/101363521 3. NGINX Ingress Controller:https://www.nginx.com/products/nginx-ingress-controller/ 4. K8s高可用集群架构搭建详解:https://blog.csdn.net/weixin_44310047/article/details/119488131 5. 在K8s中使用PVC持久卷:https://blog.csdn.net/m0_48898914/article/details/120200312 6. K8S-PV和PVC简介:https://www.cnblogs.com/rtnb/p/15664690.html
发布于2年前 · 25 次浏览 · 来自
Rango
从 `CodeGalaxy` 平台`5月初`上线至今已经`2个月`的时间,在这`2个月`中有累计 `316` 个项目部署到了我们的平台,正在的运行的实例超过了`560`个,近`200`多个域名接入。随着用户逐渐将一些实际项目部署到 `CodeGalaxy` 平台,大家对于 `CodeGalaxy` 的`K8s` 云原生架构高可用问题越来越关注,`CodeGalaxy` 是如何保证系统的可靠性、稳定性的,另外相比于传统基于 `ECS` 云主机 `Nginx + PHP/Golang/Java` 的架构,`K8s` 有哪些优势也是大家非常关心的问题。本文会详细讲述 `CodeGalaxy K8s` 云原生高可用架构设计的细节,让各位开发者对云原生技术有一个更深入的理解,更好地使用 `CodeGalaxy K8s` 云原生技术构建企业的系统架构。 CodeGalaxy 系统官网:https://code-galaxy.net/ ## 整体架构 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c67f525e382.png) 1. DNS 解析为 `SLB IP` 地址,由 SLB 进行四层代理负载均衡,将 TCP 连接和数据转发给 K8s 集群中的 `Ingress Controller` 2. `Ingress Controller` 作为七层代理,解析 HTTP 协议,根据不同的 `Host` 将请求负载均衡转发给 K8s 集群中对应的`WorkLoad`,也就是 CodeGalaxy 应用的具体实例 3. 工作负载一般多有多个 Pod,请求会随机转发给其中一个 Pod 进行处理 4. Pod 处理过程中会再次请求其他的 Service 或者读取后端数据库存储、缓存或其他中间件 ## SLB(`Server Load Balancer`) CodeGalaxy 在接入层使用了云厂商(阿里云、腾讯云等)的 SLB 服务作为四层代理和负载均衡器,边缘网络请求应用前,先通过域名解析获得 SLB 的 IP 地址。SLB 一般是使用 `LVS + KeepAlived` 实现,虽然 SLB 解析出来的 IP 只有一个,但实际上 SLB 是一个集群,以保证高可用,SLB 集群当前的节点不可用时,会自动通过 IP 漂移切换到另外一台机器,实现故障转移。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6806ae8309.png) `SLB` 会将收到的请求负载均衡到后端服务器(`Real Sever`)。在 `Code-Galaxy K8s` 架构中, `Real Server` 就是 K8s 集群的 Node 节点。在每个 `K8s Node` 上都部署了 `Nginx Ingress Controller` 来作为七层代理,处理 `HTTP/WebSocket` 请求。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c680795ea70.png) ## Ingress Controller CodeGalaxy 使用 `Nginx Ingress Controller` 作为七层代理,转发请求给 K8s 集群的实例 Pod 容器组。K8s 集群的所有节点默认都会启动 `Nginx Ingress Controller` 实例,并自动注册到 SLB ,作为 `SLB` 的 `Real Server` 节点。`Nginx Ingress Controller` 使用了 `K8s Host Network`,直接使用宿主机的物理网卡监听端口,中间没有任何流量转发器,减少了性能损耗。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6809f72ae8.png) 当`Nginx Ingress Controller` 集群中的某个节点故障不可用时,会被 `SLB` 将自动剔除,保证了高可用。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c680cc2fcfa.png) ## K8s 集群 `K8s 集群`由 `Master 集群` 和 `Worker 集群` 组成,`Master 集群`为控制面(`Control Plane`),`Worker 集群`为数据面(`Data Plane`)。所有 `K8s 集群` 的元数据都会保存在 `ETCD` 分布式存储中,默认 `Master 集群`的每个节点都会部署 `ETCD`,也可以配置使用外部的 `ETCD` 集群。为了保证高可用,`Master 集群`至少要有`3`台以上机器。`ETCD` 使用 `Raft` 协议实现了分布式数据一致性。当某个节点出现故障时,数据不会丢失。集群依然可以运行。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6810602f8a.png) 应用实例的容器组(`Pod`)会被调度到 `Worker 集群`去执行。当 `Worker 集群` 中的一个节点机器出现故障时,`K8s` 会在`Worker 集群` 其他存活的节点上重新启动 `Pod`,保证高可用。 ## 应用实例 CodeGalaxy 平台应用的实例使用了 `K8s` 的 `Deployment` 来管理`Pod`。实例的 `Pod` 会被 `K8s` 根据节点负载状况随机调度到任意一个 `K8s`的 `Worekr 集群` 节点上启动。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c68121ccded.png) 每个实例对外使用 `Service` 地址作为服务入口,并作为`Ingress Controller`的`Upstream`,当请求应用绑定的域名时,会自动转发给对应的`Service`。 实例至少要设置 `2` 个或以上副本。当其中一个 `Pod` 发生故障或者崩溃退出时,`Service` 会停止向不可用的 `Pod` 发送请求。与此同时`K8s` 会重新调度,启动新的 `Pod` 。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c68135ac0c9.png) ## 弹性伸缩 除了固定副本的模式外,CodeGalaxy 也提供了 K8s 弹性伸缩(`HPA`)的功能,具体技术细节可以查看 K8s HPA的相关文档。在一些突发事件带来大量请求的情况下,当前的 `Pod` 数量无法支撑如此大的请求量。这时就会出现大量 `502/503` 错误。导致 `Web` 应用的服务不可用。这时可以启用弹性伸缩功能解决问题。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6814fdf5a1.png) 进入应用的实例中,选择“设置伸缩”,可以选择一个已有的弹性伸缩模版,如果没有合适的模版,也可以创建一个新的弹性伸缩模版。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6815c083f3.png) 弹性伸缩的参数设置可以参考 K8s HPA 文档。通过设置弹性伸缩模版就可以在实例的 `Pod` 负载过高,`CPU`和`内存`超过一定水位线后自动扩容,增加更多 `Pod`,提供更强的处理能力。在 Pod 负载降低后又会自动减少 `Pod` 数量。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6816b3043f.png) ## 配置和环境变量 在服务端应用中我们经常需要读取一些配置文件,例如`MYSQL`数据库主机和端口、用户名、密码,`Redis`服务器的地址等等。在没有使用`K8s`之前,很多项目会将配置以文件的方式保存在服务器上,或者存入`MySQL`数据库,使用时进行读取,还有一些项目使用 `Nacos`、`Apollo`等配置中心服务来管理配置。 在使用`K8s`架构之后,可以直接使用`K8s ConfigMap/Secret` 来存储配置,然后通过持久存储卷(`Persistent Volumn`),将配置映射为一个磁盘文件。也可以把配置作为环境变量传递给应用层。 在 CodeGalaxy 系统中,可以在实例中直接设置环境变量,应用程序中可以使用 `getenv` 系统调用获取配置。也可以在持久化存储中选择新建 `ConfigMap/Secret`,并映射为磁盘文件,挂载到系统中,应用程序中可以通过读取文件的方式获得配置。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c68250e0a56.png) ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c6826cd6438.png) 环境变量、`ConfigMap`、`Secret`底层实现上是保存在了 `K8s` 的 `ETCD 分布式存储`中,可以保证数据可用性。 ## PVC 持久化存储 在 K8s 中 Pod 是非持久化的,当容器崩溃或者发生调度时 Pod 的生命周期就结束了,容器内的所有文件系统内容将会被丢弃,Pod 重启之后仍然会恢复到镜像中的内容。如果实例希望持久化存储文件内容,就需要使用 K8s 提供的PVC(`Persistent Volume Claim`)。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c68d5d44445.png) CodeGalaxy 系统使用云厂商提供的`NFS`服务作为 PVC 的存储后端,保证了文件内容的可靠性。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c682982e66d.png) 创建 PVC 之后,挂载到实例中即可。所有 Pod 均可读取 PVC 中的数据,内容是共享的。 ![](https://wenda-1252906962.file.myqcloud.com/uploads/202207/1_62c682a205bd6.png) ## 结语 `K8s`云原生技术提供了一套以云为基础、天然的分布式架构。使用`K8s`可以帮助企业建立高可用的服务端架构,高效率、低成本、规范的`IT`研发系统。 `Code-Galaxy`在`K8s`技术之上整合了多个开源项目,提供了简单易用的用户界面,使得`K8s`使用起来更简单。基于`Code-Galaxy`系统可以在没有任何`K8s`技术积累的团队也可以快速落地`K8s`云原生技术架构方案,让用户可以零成本升级到`K8s`云原生架构,快速体验云原生技术带来的高效、便捷。 ## 参考: 1. 阿里云 SLB:https://help.aliyun.com/document_detail/27544.html 2. k8s-集群里的三种IP:https://blog.csdn.net/qq_21187515/article/details/101363521 3. NGINX Ingress Controller:https://www.nginx.com/products/nginx-ingress-controller/ 4. K8s高可用集群架构搭建详解:https://blog.csdn.net/weixin_44310047/article/details/119488131 5. 在K8s中使用PVC持久卷:https://blog.csdn.net/m0_48898914/article/details/120200312 6. K8S-PV和PVC简介:https://www.cnblogs.com/rtnb/p/15664690.html
赞
0
分享
收藏
提问
分享
讨论
建议
公告
开发框架
CodeGalaxy
评论
还没有评论!
微信公众号
热门内容
作者其它话题
- CodeGalaxy K3s 轻量集群节点之间如何实现负载均衡
- 有没有办法判断当前是否运行在swoole守护进程里面?
暂无回复的问答
- CodeGalaxy K3s 轻量集群节点之间如何实现负载均衡
- 关于openssl CURL WARNING swSSL_connect: SSL_connect(fd=69) failed. Error: error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small[1|394]
- 多个模型如何进行事务异常回退?
- websocket开启wss报错
- 协程tcp服务器如何使用多进程?recv()方法接收信息,打印出来的pid一直是同一个。没用使用到多进程啊。