通过 DaoCloud DCE 的场景化应用看容器云平台的核心能力（一）

以下场景来自DaoCloud官方文档场景化视频，这里以文字形式简单提取下要点，包括操作步骤和一些问题。

目前我对容器生态的了解有限，博客的主要目的是想通过对这些典型场景提出问题的方式拓展眼界，希望有机会完全理解这些场景。

一共13个场景，本篇包含4个：1.单云应用一键转换为多云应用、2.在DCE5.0中部署混合云应用、3.传统微服务治理（南北向流量）、4.传统微服务治理（东西向流量）。

1. 单云应用一键转换为多云应用

使用DCE托管AWS K8s集群C1，新增托管华为云K8s集群C2，将部署于C1的应用扩展至C2。明确几个概念，相同云厂商支持的私有云与公有云结合为混合云，多个云厂商结合为多云，混合多云是前两者的结合。采用混合多云有几个显而易见的驱动因素，例如监管、可用性、成本、弹性，从数据上看它也是目前主流的云采用方式，市场占比高达43%（数据来自于什么是多云编排），因此支持多云是容器云平台的一个关键特性。CNCF项目Karmada用于多云多集群K8s编排，DCE的具体实现需要参考这个项目，它完全兼容了K8s的原生对象，也就有了这个场景中的一键转换为多云对象。

操作步骤：

1. 接入已经创建的集群C1、C2；
2. 创建多云实例M1，将C1、C2加入M1，由此构建混合云，此时应用（Frontend-proxy+Frontend+Productcatalog，均为2副本Deployment）仅在C1中运行；
3. 在M1的多云编排中将C1中的Frontend Deployment转换为多云负载，更新此多云负载的配置，以复制的方式调度至C1和C2集群，调度完成后，Frontend应用分别在两个集群中以Deployment形式运行；
4. 分别从C1、C2访问完整的服务。

问题：

1. 应用完成多云升级后，拥有独立的公网访问入口，可能涉及到DNS的配置变更，这部分会涉及云厂商API的集成吗？
2. C2集群中的Frontend服务需要访问C1中的Productcatalog服务，属于东西向流量，如何在公网打通呢，这部分是否会涉及云厂商的API集成？
3. 第2个问题实际上涉及多云架构下如何设计部署架构，不可能让一次交易的流量多次跨越不同云厂商的网络，又怎样看待有状态应用呢？
4. 可观测性以及流量治理从DCE提供的界面实施吗？似乎云厂商只需要提供一个符合规范的K8s集群，其他的比如阿里云微服务引擎MSE还能够发挥作用吗？
5. 镜像仓库需要在不同的云中本地化吗？

在常见问题中有对于以上部分问题的解答，似乎翻阅官方文档能够得到大部分问题的答案，这里暂时不尝试回答，但是通过这些问题已经能够感知到容器云生态的复杂性，学习云原生似乎必须熟悉Go语言，因为大概率需要翻阅代码了解细节。

2. 在DCE5.0中部署混合云应用

在OpenShift（OpenShift是红帽维护的基于K8s的容器管理平台）本地集群C1和华为CCE集群C2构成的混合云平台上部署应用。从图中可以清晰地看到不同集群通过Istio东西向网关打通了跨集群网络，这个例子也演示了单集群故障时业务自动恢复的过程。从场景一提出的多云部署架构问题来看，上图中入流量从C1到C2再回到C1的做法似乎并不合理，暂时将它仅作为一个演示来看吧。

操作步骤：

1. 在多云实例中，将Frontend应用部署在C2中的多云命名空间N1中，创建ClusterIP类型的Service暴露应用；
2. 使用同样的方式将Productcatalog应用部署到C1；
3. 将C1、C2接入同一个服务网格，接入网格后应用Pod将被注入Sidecar，然后创建应用到网关（frontendproxy）的虚拟服务，将所有流量指向Frontend；
4. 通过C1、C2的LB地址（istio-ingressgateway）可成功访问页面；
5. 为C2添加Outbound规则断开控制面（6443端口）和数据面（15443端口）的连接，模拟C1集群断开，Productcatalog服务自动在C2重建，期间用Jmeter请求页面，通过响应观察故障转移过程；

问题：

1. DCE使用的网格是Istio官方版本吗？
2. 虚拟服务设置中的可用网关frontendproxy是什么，它处于网络中的什么位置？
3. Istio东西向网关具体是怎样打通网络的，是否需要配置网络可达作为前提？
4. 跨集群的流量调度细节是怎样的？看到使用开源方案Karmada+Flomesh实现工作负载和流量的共同调度，倒是可以从这里入手进行了解；

虽然这个场景演示的功能很漂亮，但是如果不了解细节，出问题之后一定更糟糕，容器云引入的复杂性以一种更直观的方式显现，从感受来看，DCE的文档似乎远远达不到帮助用户理解这种复杂性的水平，它对用户的认知要求很高吗？再延申一下，类似Kubevela这种屏蔽底层细节的应用交付平台就顺理成章了。

3. 传统微服务治理（南北向流量）

使用DCE托管Nacos替换原始外置Nacos（非托管则为外置），从而将服务导入DCE网关，实现应用接入。

操作步骤：

1. 在微服务引擎中创建托管Nacos单实例，访问方式为节点；
2. 替换Adservice、Dataservice配置文件中的Nacos地址为托管实例的域名，之后可以看到服务注册至托管Nacos中；
3. 在微服务引擎中创建微服务网关，创建域名并配置HTTPS和安全认证；
4. 将托管Nacos中的Adservice服务导入服务网关，配置协议、地址、端口；
5. 在微服务网关中创建Adservice服务的API，目标服务可选后端服务、重定向、直接返回，服务列表中的服务支持权重配置，支持十几种API策略控制访问流量；
6. 应用API策略控制访问流量，路由改写、访问黑白名单；

问题：

1. 传统方式下Nacos可以部署于K8s，K8s对于微服务仅仅相当于一个自动化框架，似乎无法应用其内置的服务发现能力；
2. DCE托管Nacos的作用是什么，只是为网关提供获取服务列表的通道吗？
3. DCE微服务网关是通过服务网格实现能力的吗？

参考创建托管注册中心，其中：

• 涉及问题2，使用Nacos的传统微服务应用中嵌入了Nacos SDK，流量权重设置、配置管理等行为本身由Nacos实现，因此只能更好得集成Nacos；

4. 传统微服务治理（东西向流量）

将传统SpringCloud、Dubbo微服务云原生化，通过启用Mesh插件注入SideCar启用东西向流量治理能力：流量、安全、监控，应该是通过Mesh替换传统框架中的相关组件实现，比如SpringCloud中的Sentinel。

操作步骤：

1. 示例应用注册到托管Nacos中，将入口应用接入云原生网关，将集群接入网格等待SideCar就绪；
2. 在托管配置中心开启Mesh治理插件，插件自动将Nacos映射为Istio的虚拟服务；
3. 在Istio中为示例应用的入口服务配置虚拟服务，暴露访问入口，此时能够通过云原生网关访问示例应用；
4. 通过Istio注入延时故障、查看由Istio生成的服务拓扑；

问题：

1. 传统微服务并不是没有治理需要的组件，在接入网格云原生化之前不需要清理引入的相关依赖吗，直接代理是不是显得粗暴？