摘要： 云原生技术和云市场一直成熟，多云、多集群部署曾经成为常态，将来将是编程式多云治理服务的时代。
本文分享自华为云社区《华为云 MCP 多云跨云的容器治理与实际》，原文作者：技术火炬手。
在华为开发者大会（Cloud）2021 上，华为云 CTO 张宇昕发表多云容器编排我的项目 Karmada 正式开源。4 月 26 日，华为云原生开源负责人王泽锋与华为云高级工程师徐中虎发表了《华为云 MCP 多云跨云的容器治理与实际》主题演讲，分享了华为云 MCP 的的倒退状况与 Karmada 我的项目的外围黑科技。
演讲次要蕴含五个方面的内容：
1）云原生多云现状及挑战
2）华为云 MCP 历程
3）Karmada 我的项目
4）多集群服务治理
5）小结与瞻望
云原生多云现状及挑战
依据最新的调查报告显示，超过 93% 的企业正同时应用多个云厂商的服务。云原生技术和云市场一直成熟，多云、多集群部署曾经成为常态，将来将是编程式多云治理服务的时代。而业务部署到多云或多集群，它其实是分几个阶段的:
典型阶段 1：多云多地部署，对立治理运维，缩小重复劳动
第一个阶段，咱们认为是多地部署对立运维治理，能够了解为是多个互操作的孤岛，互操作意味着在不同的环境，不同的云上，所用软件的技术站是一套标准化的，在进行私有云、私有云 1、私有云 2 相互切换时，操作命令所输出的命令申请都是一样的，但其之间没有任何业务相关性或业务相关性十分弱，此时去做对立的利用交付，比方部署运维，要么手动执行反复的命令或者脚本化，或者最简略的用一套 CI/CD 的零碎堆上去即可。因为在这个阶段大部分的业务相对来说比拟固定，部署在哪个私有云、哪个数据中心，哪个机房，不须要太多的动态性和变动性。
典型阶段 2：多云对立资源池，应答业务压力稳定
第二个阶段为对立资源池，则会对资源池的动态性有肯定的诉求。一般来说，在此处咱们所认为的利用交付并不是一个简略的 CI/CD，因为咱们心愿动态性之后，流量也可能随之迁徙。在这种状况下，下面的利用交付就须要具备主动调度的能力，流量能够依据实例数的散布状况本人去获取。当然也会有其余状况，比方用一些简略的脚本化来解决你的流量，也能够认为达到了第二个阶段。当然现实的状态下，咱们认为这些应该是全自动化的。
典型阶段 3：多云协同，对立利用平台，业务跨云部署
第三个阶段是咱们认为以后可预见到的一个多云和多集群的最终状态，也是咱们所认为一个现实中的状态。其实不管用集群、Kubernetes 或以前的虚拟机，从整个云计算的倒退历史来看，其实始终在一直的冲破边界，或者说从新去定义边界。比方最早的时候装一些新的利用、部署新的服务，须要一台物理服务器，而边界十分不灵便，当起初有了虚机、容器，颗粒度变小了，但在跨机器跨环境的拜访状态下，又产生了很多新的挑战，所以 Kubernetes 的呈现其实在产生了这么多细腻度的容器之后，从新画一个大的集群作为边界。
而多云其实是在这些一直演进的边界根底上，当在倒退到肯定的阶段受到数据中心或云的限度，能够用多云的技术来冲破云的边界，冲破集群的边界，真正的做到业务的利用能够自在的在集群、在云之间灵便的部署和迁徙。
但其实在云原生话题下，多云依然存在十分多的挑战，起因有以下几点：
- 集群繁多：繁琐反复的集群配置、云厂商的集群治理差别、碎片化的 API 拜访入口
- 业务扩散：利用在各集群的差异化配置、业务跨云拜访、集群间的利用同步
- 集群的边界限度：资源调度受限于集群、利用可用性受限于集群、弹性伸缩受限于集群
- 厂商绑定：业务部署的“黏性”、短少主动的故障迁徙、短少中立的开源多集群编排我的项目
华为云 MCP 历程
在 Kubernetes 外面，多集群的概念呈现十分早，华为也是作为最早的发动的单位之一，2015 年咱们在社区提出了 Federation 的概念，Federation 的 v1 版本是在 2016 年启动开发，在 2017 年将其独立，作为 Kubernetes 的独立子项目来研发。2017 年中, 咱们启动了 Federation v2 的开发。商业化的话，其实华为是在 2018 年中启动整个商业化的大平台，并且在年底提供了商用的能力，但咱们在长期服务于客户的过程中也发现一些问题，因而在 2020 年，咱们启动了全新的引擎 Karmada。
Karmada 是基于 Kubernetes Federation v1 和 v2 开发，它能够跨多个 Kubernetes 集群和云运行云原生应用程序，而无需对应用程序进行更改。通过间接应用 Kubernetes 原生 API 并提供高级调度性能，Karmada 能够实现真正的开放式多云 Kubernetes。
Karmada 我的项目
上图为咱们认为应该在开源社区所要出现的多云多集群的技术站视角，图中灰色框也是 Karmada 要笼罩的所有的能力范畴。从数据面、存储以及运维相干的维度来看，咱们向上要去解决容器网络的多云多集群，服务发现的多云多集群甚至流量治理，原数据的长久化，这些将会 Karmada 我的项目在社区里所要涵盖的范畴。
在起步阶段，咱们次要会关注几个方面，一是兼容 K8s 原生 API，这个个性其实是原来 Federation 的 v2 一个略微比拟大的妨碍，因为大家都习惯去应用 k8s 的 API 而不是新的 API，所以咱们在做全新的 Karmada 我的项目时，间接采纳原生的 API 来提供多集群的利用部署的能力。
在集群同步方面，咱们会反对多种网络模式，包含管制面在私有云，子集群在公有云或者是反过来，甚至是边缘的场景，也都能够用 Karmada 这个我的项目去笼罩，并且咱们会内置开箱即用的能力来实现最低老本的适配。
Karmada 架构图下面有一个对立的管制面，咱们其实有一个独立的 API-server 来出 Kubernetes 原生 API 也会出 Karmada 提供的额定策略 API 的能力，来做辅助的高级调度的外围性能。在集群同步方面，咱们有核心式的 Controller 和 Agent 两种模式，别离对应于管制面和子集群在公私有云或倒置的状况。
另外一类是大边缘的场景，它在云边的网络环境下，须要治理一个边缘的集群，所以咱们会联合 KubeEdge 在整个网络环境下的优化来提供针对边缘的集群治理能力。
Karmada 我的项目外围价值：
- K8s 原生 API 兼容，丰盛云原生生态
- 内嵌策略，开箱即用
- 丰盛的多集群调度反对
- 集群资源空间隔离
- 多种模式集群同步，屏蔽地区、网络限度
多集群利用部署
1）零革新 — 应用 K8s 原生 API 部署一个多集群利用
示例策略：为所有 deployment 配置多 AZ 的 HA 部署计划
应用规范的 K8s API 定义部署利用
kubectl create -f nginx-deployment.yaml
2）Propagation Policy: 可重用的利用多集群调度策略
resourceSelector
- 反对关联多种资源类型
- 反对应用 name 或 labelSelector 进行对象筛选
placement
clusterAffinity:
- 定义偏向调度的指标集群
- 反对通过 names 或 labelselector 筛选
clusterTolerations:
相似单集群中 Pod tolerations 和 node taints
spreadConstraints:
- 定义利用散发的 HA 策略
- 反对对集群动静分组：按 Region、AZ、个性 label 分组，实现不同层级的 HA
3）Override Policy: 跨集群可重用的差异化配置策略
resourceSelector
- 反对应用 name 或 labelSelector 进行对象筛选
overriders
- 反对多种 override 插件类型
- plainTextOverrider : 根底插件，纯文本操作替换
- imageOverrider: 针对容器镜像的差异化配置插件
多集群服务治理
多集群服务治理要解决的问题
- 服务发现
- DNS 解析
- 负载平衡、熔断、故障注入，流量切分等高级流量治理
- 跨云的拜访安全性
ServiceMesh 的劣势
上图是 Istio ServiceMesh 典型的架构图，Istio 是一个齐全无侵入式的，通过主动注入 Certificate 的形式去拦挡利用收回来的流量，并通过 Certificate 治理利用的流量。
Istio 的基本功能：
1）流量治理
- 通过 Resilience（熔断、超时、重试、故障注入等 )，进步整个零碎的韧性
- 灰度公布：不便咱们去更快的部署上线新版本
- 负载平衡、路由匹配，基本上能够取代原来的那种微服务治理的框架
2）平安：数据加密、认证、鉴权
3）可观测：可观测性是更加不便利用运维人员去诊断系统的故障，这里的典型的三个可观测性的指标有 Metrics、Traces（调用链）、Access Log（拜访日志）。
多集群多云场景下，如何进行服务网格的技术选型？
接下来，将从上面这三个维度来进行技术细节的具体阐明:
- 扁平网络 vs 非扁平网络
- 单服务网格 vs 多服务网格
- 单管制面 vs 多管制面
1）多集群服务网格 - 扁平网络
劣势：
- 东西向服务拜访提早低
毛病：
- 组网复杂性
- 安全性：所有的工作负载在同一网络中.
- Scalability: pod、service IP 地址不抵触
2）多集群服务网格 - 非扁平网络
劣势：
- 网络隔离，安全性绝对更高
- 组网简略
- Scalability: pod/service 网络地址能够重叠
毛病：
- 跨集群服务拜访须要通过东西向网关
- Gateway 工作依赖 TLS Auto Passthrough
3）非扁平网络 - 单管制面
- 单个管制面（能够部署在用户集群或者齐全托管）
- 服务发现
- 配置发现
- Split Horizon EDS
- 东西向网关
4）非扁平网络 - 多管制面
- 管制面部署在每个集群
- 服务发现
- 配置发现
- Sidecar 连贯本集群内的 Istio 管制面，与单管制面相比，有更好的性能和可用性
5）非扁平网络 - 东西向网关
- 网关地址获取
- Split horizon EDS:
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: cross-network-gateway
namespace: istio-system
spec:
selector:
istio: eastwestgateway
servers:
- hosts:
- '*.local'
port:
name: tls
number: 15443
protocol: TLS
tls:- mode: AUTO_PASSTHROUGH
Network filter:“envoy.filters.network.sni_cluster”
附：Karmada 社区技术交换地址
我的项目地址： https://github.com/karmada-io…
Slack 地址： https://karmada-io.slack.com
点击关注，第一工夫理解华为云陈腐技术~