云原生实践（一）：双活中心网络接入动手实验

天助强者

已于 2022-08-31 16:41:39 修改

阅读量887

点赞数

分类专栏：云原生文章标签：云原生运维 azure

于 2022-08-25 15:57:47 首次发布

本文链接：https://blog.csdn.net/mayong43111/article/details/126518392

版权

云原生专栏收录该内容

4 篇文章 1 订阅

订阅专栏

背景

前段时间做了一些项目，现在总结一下。当前用户主要业务是面对互联网用户，而且是24小时提供不间断的服务，对于系统的SLA、RTO要求比较高。应用的 SLA 要求达到 99.99%，RTO < 1分钟。目前采用本地IDC + 公有云的方式部署，主要服务已经进行了容器化的改造，部署在本地和公有云的 kubernetes 中。本次主要改造内容是同城的双活的优化。

设计思路

借鉴微软参考体系结构中关于多区域负载均衡中的设计，最终来实现我们的优化方案。

在这个参考方案中，通过基于 DNS 的流量负载均衡器实现了流量的调度，使用DNS的方式将客户端请求定向到合适的服务总结点。

使用DNS做负载的好处是可以降低负载均衡设备的压力，和跨region的网络传输压力，但也由于是基于 DNS ，因此它仅在域级别进行负载均衡。同时它无法快速进行故障转移，因为存在 DNS 缓存和部分系统不采用 DNS TTL 的常见问题。

所以在每个区域的应用程序网关，增加了流量的转发功能。当区域故障的时候（网络设备正常情况下）,首先触发 DNS 的调整，用户在刷新DNS后，新的请求会发送到非故障区域。在 DNS 缓存期间，即使有部分流量发送到故障区域，通过应用程序网关将流量通过专线转发到非故障区域。如果区域故障包括了网络设备，由于DNS TTL 设置为60秒，大部分用户在60秒后都可以正常刷新 DNS，所以基本满足 RTO < 1分钟的要求。最后大概示意图如下：

动手实验-环境准备

由于准备IDC环境有困难，所以使用了2个不同区域的公有云，其中一个区域的服务假设为 IDC。

1. 创建资源组。准备创建三个资源组，其中2个用于承载应用，另一个作为承载公共服务的。由于后期还准备计划做蓝绿发布测试，所以起名为blue、green 和 common。

2. 分别在 blue 和 green 创建 vnet ，其中 blue 的地址空间为 10.1.0.0/16 ，而 green 的地址空间为 10.2.0.0/16。在 common 下创建 Azure Virtual WAN，用于连接管理不同区域的网络。整个网络采用中心辐射型体系结构设计，类似下图的模式：

本次设计通过 Azure Virtual WAN 进行路由和 Hub 的管理。在2个区域创建 Hub，并且和 blue 、green 区域 vnet 建立链接。如果是本地 IDC，可以使用 ER 专线或者 VPN 的方式接入。

将 vnet 连接到 hubs 后，可以从我在 common 资源组创建的一台 VM 来查看路由，发现已经自动维护好路由表。可以看到如果访问 10.1.0.0/16 时，会路由到 virtual network gateway。

3. 创建 Kubernetes 集群，目前各大公有云平台都有相应的 PaaS 服务，不需要自己手动搭建。利用 AKS 分别创建 blue 和 green 集群。

4. 创建 API Gateway，这里使用了 Application Gateway 来做7层的Web 流量负载均衡器，用于管理 Web 应用程序的流量，同时如果需要的话，还可以开启 WAF 功能。

当我们在 Kubernetes 中创建一个 ingress 时，我们希望通过这个App Gateway发布出去。每个区域都有自己的 App Gateway。我们希望当创建 ingress 时，自动更新 App Gateway 的配置，而不需要手动去维护。

5. 启动 AGIC 功能。应用程序网关入口控制器 (AGIC) 是一个 Kubernetes 应用程序。Azure Kubernetes 可以利用应用程序网关 L7 负载均衡器向 Internet 公开服务。使用 AGIC，就不需在 AKS 群集前面设置另一个负载均衡器/公共 IP，避免在请求到达 AKS 群集之前在数据路径中设置多个跃点，改进部署性能。

当然这个不是必须的，或者使用其它一些应用程序网关也可以做到。我们目前添加了2个应用程序网关，获得了2个公网的 IP 地址。下午是其中的一个公网地址。

6. 在 AKS 集群中部署示例代码，我们直接使用 samples:aspnetapp 镜像。同时 ingress 这里直接声明使用 App Gateway服务。

apiVersion: v1
kind: Pod
metadata:
  name: aspnetapp
  labels:
    app: aspnetapp
spec:
  containers:
  - image: "mcr.microsoft.com/dotnet/core/samples:aspnetapp"
    name: aspnetapp-image
    ports:
    - containerPort: 80
      protocol: TCP

---

apiVersion: v1
kind: Service
metadata:
  name: aspnetapp
spec:
  selector:
    app: aspnetapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
spec:
  rules:
  - http:
      paths:
      - path: /
        backend:
          service:
            name: aspnetapp
            port:
              number: 80
        pathType: Exact

更新完 Kubernetes 集群后，我们可以从 App Gateway 的 Rules 中看到已经自动生成了配置。

通过前端 IP 访问应用，可以反到返回结果。其中一个如下图所示，可以看到其 IP 地址在 10.2.0.0/16 这个地址段，而访问另一个地址可以看到 IP 地址在 10.1.0.0/16 地址段。

6. 创建 Traffic Manager profile ，并且使用 Public IP 的当时将之前创建的 Gateway 添加到 EndPoint 中。 Azure Traffic Manager 可以根据配置（比如权重）进行流量的分配。

这里我使用了加权的方式路由的方式，2 个 Gateway 设为同样的权重。当用户请求 DNS 时，会返回不同的 IP 地址（添加在 Endpoints 中）。另外还可以根据性能、地址等方式进行智能 DNS 解析。通过一些在线 DNS 测试，我们可以看到结果如下：

动手实验-切换验证

我们假设当 blue 区域发生了故障（或者执行蓝绿部署），首先我们打开 ATM (Traffic Manager) 找 blue endpoint，选择禁用并保存。

我们这时如果继续使用 DNS 测试工具，会发现并没有立刻生效。这是因为我们 DNS TTL 设置为 60 秒。从理论上来说，我们可以设置成 0 秒，但是更高的 TTL 可以给我们带来：

更高的 TTL 可以减少进入流量管理器 DNS 服务器的查询数目，从而又可以降低客户的成本，因为根据查询数目提供服务是要收费的。
更高的 TTL 可能会减少执行 DNS 查找所需的时间。
较高的 TTL 还意味着数据不会反应最新的运行状况信息，流量管理器已通过其探测代理获取了该信息。

经过大概 60 秒，我们再使用 DNS 测试工具可以看到基本上全部更新成 green 区 Gateway 的 IP 地址了。如果继续等待，最终所有的 DNS 都刷新成 green gateway 的地址。

这里我刻意找了一个存在特例的时候截图。可以看到，即使经过了 60 秒的等待，依然有一些解析并没有正确解析到 green 区域，这就是我之前提到的问题

因为存在 DNS 缓存和部分系统不采用 DNS TTL 的常见问题。

所以我们还需要一个补偿手段，来防止用户在 DNS 缓存期间，或者由于其它原因不采用 DNS TTL 时，依然可以正确将请求发送到 green 区域。这个时候我们就可以通过在 blue 区 App Gateway 中进行设置，将流量进行转发。当然这些假设是 blue 虽然区域故障，但是并没有影响网络设备的使用。