使用ChatGPT实现同城双活部署

原创

远远小七宝

修改于 2023-01-09 12:08:48

3.4K0

修改于 2023-01-09 12:08:48

文章被收录于专栏：泛互云原生

前言

今天老板让我写一篇腾讯云云原生的微服务项目部署实践，还要实现同城双活。听说ChatGPT已经“出圈”了，无所不能，还可以帮人写文章，刚好最近比较懒，看看他能否帮我写完这篇实践，并教会我实现同城双活部署。

ChatGPT介绍

先来看看我的助手，是如何介绍自己的

看起来技术、学术、文化无所不知，很强大，那话不多说，开始干活！

项目介绍

需要部署的项目，是一个基于Dubbo的微服务系统——Q云书城（QCBM），它由多个功能模块组成，比如收藏、购买、用户管理和订单查询。

计划从数据层，应用层和接入层，对项目进行依次部署，其中：

数据层使用腾讯云 MYSQL 和腾讯云 Redis 搭建，保存书城信息，选择跨区高可用版本，提供灾备切换能力。
应用层采用容器方式，在腾讯云 TKE 中进行部署，包括以下单元：

QCBM-Gateway：Dubbo网关服务，接受前端REST请求，转化为Dubbo调用。
User-Service：提供用户注册、登录、鉴权等功能。
Favorites-Service ：提供用户图书收藏功能。
Order-Service ：提供用户订单生成和查询等功能。
Store-Service ：提供图书信息的存储等功能。

3. 接入层使用腾讯云 CLB，结合 K8S Ingress 和 Service 实现流量接入和转发，采用跨区高可用模式部署。整体架构图如下所示：

数据层部署

首先开通多可用区版本的MySQL、Redis和Nacos，跨区部署可以提供访问连续性保证，这里记录下IP、账号和密码，为后续部署做准备。

应用层部署

开始第一个挑战，首先部署应用层的各业务模块，看看ChatGPT状态如何。

他好像忘记把ConfigMap和Secret给我了，提醒他一下

从TKE上开启集群后，按照ChatGPT给我的方案，替换configMap和secret里的值和数据，填入云上开通的MySQL、Redis和Nacos端口和地址。接着，创建包含登录名和密钥的secret，因为其他服务，也需要复用这里的configMap和secret，我对资源名称进行了修改。ChatGPT还提示secret需要使用base64编码后的字符串，非常贴心。

完成configMap和secret的部署后，开始下发deployment。ChatGPT提供的YAML文件很准确，基本没有什么需要修改的，从user-service模块开始，直接复制粘贴操作。

没有意外，运行成功。接下来按照同样的方法，修改favorite-service，store-service及order-service的image及name，依次下发，4个服务都正常启动。

接入层部署

完成4个业务模块的部署后，开始部署qcbm-gateway。qcbm-gateway为接入层访问模块，需要同时包含depolyment，service和ingress三部分。

当然，我们已经完成了configMap的部署，这里直接复用，只需要下发qcbm-gateway的deployment和service文件。

接下来，暴露网站的7层访问接口。

在ChatGPT给出的答案基础上，添加腾讯云ingress annotation，创建公网CLB类型的ingress，该annotation如下所示：

kubernetes.io/ingress.class: qcloud

为了让CLB具备跨区高可用特性，将它同时部署在北京5区和北京7区，也是采用annotation的方式，如下所示：

kubernetes.io/ingress.extensiveParameters: '{"AddressIPVersion":"IPV4","MasterZoneId":"ap-beijing-5","SlaveZoneId":"ap-beijing-7"}'

部署完成后，通过公网CLB地址，查看我们的云书城网站，访问成功！

同城双活改造

基础资源的部署，可能对ChatGPT来说有些简单，接下来，给他一些挑战，给我们提供一个应用层的跨区高可用方案。

为了实现同城双活，我们已经做了如下动作：数据层的MySQL、Redis和Nacos，开通多可用区版本；在申请Ingress时，加入了多可用区部署annotation。现在只剩下应用层还是单可用区部署。

我们希望只用一套TKE集群实现同城双活，最大程度的节约成本。理论上，将node开在不同的可用区，deployment多副本pod分散到不同可用区的node上，一旦出现单区故障，业务仍然可以提供连续性保证

之前在网上看过podantiaffinity的用法，但只是收藏，忘了阅读。不知道ChatGPT能不能基于这个方法，帮我完成应用层的改造工作。

ChatGPT给了我们两个备选项：nodeSelector肯定不行，因为他会把所有pod都调度到同一个node上，这不符合我们打散pod的要求。podantiaffinity的方案和我们的预期一致，来详细看看这一部分是如何实现的。

看起来可以满足我的需求，决定按照这个方式尝试一下。考虑到ChatGPT的资源来自2019年前的资料，且语句中涉及到beta字眼。查询K8S官网，发现failure-domain.beta.kubernetes.io/zone已经被deprecated，建议使用最新的topology.kubernetes.io/zone。

另外，我们的deployment可能存在多个副本，但只想开通两个可用区的node资源。所以把requiredDuringSchedulingIgnoredDuringExecution修改为preferredDuringSchedulingIgnoredDuringExecution，避免大于2个副本的depolyment无法被调度。

加上官网的示例，我们对ChatGPT的答案进行一些修改，得到了正确的affinity语句：

 affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - user-service
              topologyKey: topology.kubernetes.io/zone
            weight: 100

因为是云原生部署，腾讯云TKE集群会每个node节点自动打上topology.kubernetes.io/zone的标签，所以无需再额外操作node资源文件了。