发表新帖

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

发布于4年前 · 29 次浏览 · 来自

Rango