做项目，有人陪跑，有人陪笑。
潭主呢，陪练。
距离上一次跟阿里云亲密接触已经过去了两年。
一日不见，如隔三秋，何况两年乎。
最近，潭主突发奇想跑去阿里云，无意间发现了“ACK One”。
很好奇，就去研习了一下，有些收获。
K8S，单集群与多集群
当年搞OpenShift V3，那时K8S部署门槛很高，搭一个OCP环境都很有挑战。
后来VMware推出TanZu时，K8S的部署已经自动化，鼠标右键就能轻松搞定，部署成本降为零。
也就是那时起，在潭主的认知里，K8S成了一个资源颗粒度。
当下的云原生时代，KaaS（K8S as a Service）彻底沦为了标配。
遗憾的是，OpenShift之后，潭主少了K8S的实操经验。
多集群管理那点儿事
相比OpenShift的单集群模式，SuSE的Rancher好像一开始走的就是类似DBasS的云管模式。
如今，随着云原生的广泛应用，企业要没些个K8S集群都不好意思出来打招呼。
相应地，多集群管理也带来了一些问题和挑战，尤其是业务流量的多集群路由和容灾。
反正，潭主搞IT运维和灾备多年，对K8S的多集群，尤其是“联邦”有一种执念。
一图了解ACK One
从之前的KubeFed，到如今的OCM和Karmada，开源社区也在不断探索多集群的管理。
既然云厂商有了各自的K8S发行版，自然也要有相应的多集群管理方案才能实现闭环管理。
于是乎，阿里云有了ACK One。
阿里云称ACK One为分布式云容器平台，主打混合云、多集群、容灾等场景。
不过，不同厂商的多集群管理实现方法不完全一样。
如图所示，阿里云的ACK One Fleet（舰队）是基于开源OCM（Open Cluster Management）构建的。
反正就是甭管客户K8S环境多复杂，云上云下、核心边缘、甚至友商异构，咱ACK都能用One搞定。
此外，ACK One还基于Argo CD实现了面向多云、混合云的多集群GitOps能力。
在潭主看来，ACK One更像对标是Rancher容器云平台，而Fleet作为ACK One的一部分，则专注于多集群的流量管理和应用分发。
多集群网关那点儿事
ACK One多集群网关是ACK One为多云、多集群环境提供的云原生网关。
多集群网关的特性：
Region级的Global Ingress，统一管理多集群的南北7层流量
通过Fleet，统一进行多集群Ingress规则设置（兼容Nginx Ingress），无需单独操作每个K8S（安装Ingress Controller和创建Ingress资源）
托管的MSE网关跨AZ高可用，免运维
Fallback延迟低，集群故障时，网关平滑迁移流量到其他后端
通过托管MSE Ingress，ACK One支持HTTP路由、流量切分和镜像、以及基于副本数的流量负载均衡，从而构建出同城容灾、标签路由、权重路由等能力。
与多集群网关配套的还有多集群服务。
ACK One Fleet通过K8S社区标准的MCS（Multi-Cluster Service） API，实现了跨集群的K8S服务注册和发现。
除了ClusterSet、msc-controller等概念外，最重要的是以下两个CRD。
ServiceExport
ServiceImport
Fleet中的msc-controller负责管理关联K8S集群的服务导出与导入。
导出服务时，获取service后端，在导入服务时将这些后端创建于EndpointSlice中，与ServiceImport进行关联。
导入服务时，创建amcs-为前缀的服务amcs-service1，与EndpointSlice关联。
对于保险IT，当下除了信创，就是如何在云原生架构下，平滑升级现有的两地三中心体系。
下面，就来看看ACK One对同城容灾的支持。
ACK One同城容灾方案
阿里云给出了两个方案架构：
基于ACK One ALB多集群网关
基于ACK One MSE多集群网关
整体上，ACK One与DNS流量分发方案相比，有几点优势：
LB的数量：网关的LB是Per Region级的，仅需一个IP，而DNS方案的LB是Per Cluster的，需多个IP
七层路由转发：多集群网关容灾支持，而DNS方案不支持
切换延迟：ACK One流量切换延迟低，而DNS方案通常会受到客户端缓存的影响
看看下面的架构图，感觉会清晰一些。
方案一：ALB方案架构
通过ACK One Fleet的AlbConfig资源创建ALB多集群网关。
有了ALB多集群网关后，通过创建Ingress来实现按权重路由流量、根据Header将流量路由到指定集群，当一个集群异常时，流量将自动路由到另一个集群。
注：ACK One GitOps将应用分发到ACK1和ACK2两个集群。
方案二：MSE方案架构
在ACK One Fleet中通过MseIngressConfig资源来创建MSE网关。
之后，通过在网关设置流量规则可以实现按权重路由流量、根据Header将流量路由到指定集群，这样，即便集群故障，也能实现流量切换。
同样，Fleet的GitOps负责将应用分发到ACK1和ACK2中。
两个方案在架构上相似，具体细节还得从产品侧区分，比如使用MSE网关，需要开通MSE微服务引擎。
看过了阿里云的ACK One，新鲜感也逐渐消退，不过也引发了潭主的一些思考，很多细节指的推敲。
瑶池的蟠桃，好吃不好摘
之前学习OB Cloud时，潭主写过一篇《阿里云，脚踩两只船》，看见了OB Cloud和PolarDB的相爱相杀。
这次，潭主无意间看到ACK One，又不免拿去跟SOFAStack做比较。
潭主觉得，ACK One更像是开源的集成与自研，而蚂蚁的SOFAStack，虽然也开源，但显然不是一个套路。
如果仅从PaaS层的同城容灾来看，ACK One跟SOFAStack的方案有很大的不同。
SOFAStack通过对环境（Environment）的定义，直接涵盖了容灾和双活设计，而应用发布则集成在了Cafe当中，虽然也纳管底层ACK，但感觉封装做得还算自然。
不过，ACK One更多聚焦于K8S，显然比SOFAStack更轻巧。
目前，ACK One属于公有云服务，对于专有云是否支持还有待确认。
可能是先入为主的原因，潭主还是更习惯蚂蚁的套路。
阿里云，到处是“备胎”
之前对阿里云的经验更多沉淀在阿里云底座、蚂蚁SOFAStack和OceanBase上，潭主称之为阿里三剑客。
现如今，厂商在云底座IaaS层的基础功能上差异并不大，更多的差异来自于云底座的架构。
反倒是，PaaS层的差异更显著。
对于阿里系，多品牌战略好像也没啥问题，反正阿里擅长卷。
但对客户来说，多品牌显然是个问题，尤其是杂牌战略。
没有对比就没有伤害，没有选择就没有备胎。
不过，如果拿ACK One去跟Rancher这类的容器云平台竞争，或者用PolarDB去PK华为，潭主相信，阿里云的“备胎”们一样能打。
上云就上阿里云
过往，潭主曾和国内几大云厂商做过切磋，从产品侧看，阿里云相比友商还是领先不少的。
这次的ACK One让潭主对阿里云又多了一点儿认识，也顺道更新了一些K8S的进展。
少了实操，产品理解上难免有局限性，文中的错误和不足之处，还请读者见谅。
突然想起阿里云的一条广告，“上云就上阿里云”，相信不少人都见过。
学习云嘛，自然也上阿里云。
信创时代，学习就像买彩票。这一轮，潭主押宝式学习阿里云。
你说，潭主能押中吗？
- END -
感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。
公众号所有文章仅代表个人观点，与供职单位无关。
推荐阅读
