作者:范桂飓
来源:CSDN 博客
前言
今天笔者有幸受邀参加了亚马逊云科技中国峰会(上海站)的 “开发者之家《观点碰撞》” 活动,与诸位亚马逊云科技的技术专家们一同对话 “容器混合云会是未来的答案吗”?
坦诚地说,笔者每年大大小小都会参加不少各式各样的科技行业活动,但此次 “上海之行” 还是给了我非常大的惊喜。最直观的感受就是 “内容丰富而充实,很好的兼具了商业与技术的交流氛围”。也见到了很多新老朋友,收获颇丰。
下述 Q&A 内容,是笔者为了此次活动准备的一些内容,记录下来,以便将来温故而知新,也欢迎朋友们讨论指正。
Q1:容器混合云为什么会出现?其能够为开发者解决的核心问题是哪些?
混合云的定义是:首先要区别混合云和多云的概念。目前大多数厂商和用户都认为 混合云的特征是必须要同时拥有公有云和私有云,这也是中国信息通信研究院曾经提出的观点.
混合云出现的原因是:单纯的公有云或私有云都无法满足企业的生产业务需求,那么混合云就是企业 IT 能力适应企业业务发展的唯一方向。混合云结合了私有云与公有云的优势,最典型的就是 “数据安全” 与 “成本效益” 的 “两全其美”。
尤其在成本效益方面。以往,在单体服务器时代有 “摩尔定律”,那么现在云计算时代有 “贝索斯定律”,每隔 3 年,云计算单位计算能力的价格将下降 50%。
在每年的混合云发展趋势报告中我们也可以了解到,国内受访的企业中,有 50% 以上的企业是因为成本效益才选择了建设混合云。
另外,公有云的 IT 技术堆栈也会作为企业业务创新的土壤,例如:存储云服务、AI 云服务、专家系统云服务、多媒体流云服务、CDN 云服务、SaaS 云服务、PaaS 云服务等。
最后,容器混合云出现的原因是:容器作为一种不可变基础设施,天然具有 “跨平台迁移、自动伸缩” 的特性,非常适用于作为混合云的一种计算承载。
Q2:容器混合云目前在部署的过程中面临哪些挑战?其未来的核心发展路径是怎样的?
面临的挑战有:
跨云间的网络连接质量,依旧是企业采用混合云面临的首要问题。特别需要注意的是,建设混合云的前提是网络互联,基于网络支持跨云间的应用数据共享、灵活迁移、自动部署、和按需扩展。只有私有云和公有云互联互通之后,混合云才能发挥作用。但是,目前双活高可用,且保障高质量 QoS 的 VPN 和专线还是比较贵的。
建设统一的混合云管理平台。包括两朵云之间的:身份认证、授权、鉴权的集成,网络服务开通的集成,资源调度的集成等等。如果公有云、私有云没有统一的 Dashboard 的话,在运维运营方面的成本、以及事故率都会比较高。
应用负载的跨云迁移:场景化的私有云负载如何平滑迁移到公有云资源池也是一个问题。
对应的,核心发展路径:
SD-WAN,往大了说就是云网融合。在交付云的同时,也要交付网。目标是低成本、快速部署、高效运维,只需要交付一个 CPE 小盒子设备就可以完成整个 WAN 的配置和上线。
CMP 多云管理平台的产品化,运维运营人员可以在同一个的 Dashboard 完成对不同云资源的 Workflow(工作流),例如:资产管理、自服务管理、资源调度管理、配额计费管理等。
Q3:容器集群的控制也是一个比较麻烦的点,尤其是在云服务器使用时如何高效的控制容器集群呢?
云厂商应该要提供一种 Kubernetes Cluster Controller,且具备以下功能,包括:
1.基础设施的定制化,包括:CPU、GPU、DPU、FPGA 等异构计算能力的定制化,故障域隔离的定制化,多网络平台的定制化,网络 QoS 的定制化等等。
2.集群的自动化部署,包括:单个集群,或联邦集群的自动化配置等。
3.维护一个统一的北向 Kubernetes Federation API,作为跨云集群的一个管理接口,也可以用于与自动化的 Pipeline 进行集成。
Q4:面对 k8s 在不同场景中部署的复杂性,容器混合云能够提供哪些帮助?
同上,容器混合云平台应该提供一种 Kubernetes as a Service 的服务化能力,为用户屏蔽掉底层 IaaS、CaaS 等基础架构的部署配置的复杂性。用户可以简易的在云有云上获得与私有云兼容的基础设备,然后平滑的完成应用负载的迁移。
Q5:容器混合云平台中,企业应当如何完成计算资源和存储资源的选型?
资源选型主要还是考虑业务类型和应用场景。例如,比较常见的应用场景有:
1.主备容灾:私有云 DC 为主,公有云为备。主集群出现问题后,切换到备集群。这种场景主要对网络配置有要求,一方面要尽量缩短应用状态数据同步的窗口期,另一方面可能需要与运营商的 Local DNS 服务结合,进行流量切换。
2.数据备份:单纯的进行周期性数据备份,不考虑高可用的话,这种场景对低成本大容量的存储空间有要求。
3.云爆发、负载扩容:这种场景对计算资源有要求,可以考虑 FaaS(Funcation as a Service)这种计算类型。
4.DevOps 沙箱环境:这种场景对资源组合的灵活性有要求,例如:被测程序需要分别在 x86 货 ARM 上进行验证。目标是低成本的完成应用程序在各种不同运行环境中的开发测试。
Q6:现在越来越多的企业开始使用微服务拆分,那么容器混合云针对这些场景化需求能够提供哪些帮助?
当我们将大型的单体应用拆解为多个微服务时,也一定会伴随着增加了 IT 研发协同、软件交付、部署运维的复杂性。所以,企业的微服务化演进的进程中也往往会伴随着 DevOps 文化及体系的建立。
近两年,我们可以观察到微服务架构的整体趋势是从 “传统的微服务框架” 向 “云原生的微服务框架” 演进的。由 Kuberbetes 和 Service Mesh 组成的 CaaS 平台,就是一个天然的云原生微服务框架。
IaaS:提供了资源能力(计算、存储、网络)。
CaaS:提供容器编排能力。
Service Mesh:提供微服务间的东西向流量互通。
APIGW:提供对外暴露服务的南北向流量互通。
云原生的使命之一,就在于帮助微服务应用程序解决生命周期管理、以及运维管理上的难题。但是,我们也要了解到单纯的 CaaS,其实并未能完全满足 DevOps 的闭环需求。那么,容器混合云平台能够提供的帮助就是在 CaaS 的基础之上,进一步提供具备 DevOps 能力的 PaaS 平台。这是一个包含了 “研发、测试、安全、部署” 的 Pipeline。
Q7:企业从原有业务迁移到容器混合云时,有哪些需要注意的难点?云厂商能够为之提供哪些帮助?
需要注意的难点:
1.需要具备分阶段上公有云的专业规划:常见的,第一阶段是非核心业务上云;第二阶段是企业办公应用系统上云;第三阶段才是考虑核心系统上云。
2.需要具备长期的多云策略规划:一个是,上云的短期内不一定可以看见显着的成本效益,因为里面伴随着企业数字化转型的成本,但从长远来说,上云能够增强企业业务创新方面的竞争力;另一个是,既要如何上云也要考虑如何下云,这也是一个比较中肯的经验。
云厂商应该提供的帮助:
1.定制化的解决方案、以及技术咨询服务。
2.也应该提供自动化的云迁移工具,包括:代码翻译工具、数据块级别的数据迁移工具、应用级别的数据迁移工具等。那么,对于本身就是容器技术体系的用户来说,也许就是简单的镜像打包了。
3.最后云厂商应该说也有义务帮助企业客户进行创新,需要帮助培养企业的开发者。
笔者曾经服务过的 HyperMotion 就是一个非常棒的自动化云迁移平台,“三步点击” 即可完成自动化迁移。
Q8:容器混合云在面对多个独立的 K8s 集群时,底层该如何部署以实现故障隔离?
故障隔离域通常划分为以下几类,安全系数由高到低:
1.数据中心层级的故障隔离。
2.可用域层级的故障隔离。
3.机柜层级的故障隔离。
4.服务器层级的故障隔离。
服务化的 Kubernetes Cluster Controller 要实现多层级的故障隔离,就需要有 2 个技术支撑:
1.物理基础设施管理能力。用户可以订购不同层级故障隔离域的 VPC 基础设施。
2.基于 Overlay 的大二层网络,保证跨物理空间的网络联通性。
Q9:容器混合云在边缘计算领域中有什么应用场景?
边缘计算在去年迎来了爆发,主要是因为 5G 的到来,万物互联。目前,边缘计算的发展方向主要有 3 个:
1.公有云计算节点下沉的云边缘。
2.5G 网络节点下沉的 MEC + 边缘云。
3.边缘网关设备。
其中,容器混合云目前主要是应用在 5G MEC + 边缘云的场景中。
首先可以确定的是,ICT 融合是 5G 核心网技术的大势趋。表现在几个方面:
1.5G 核心网采用了 SBA 微服务化的架构,这是一种向云原生演进的架构。
2.NFV 技术体系的 VNF 也随之向着 CNF(云原生网元)的形态演进。
3.MEC 技术体系强调要突破物理空间的限制,让应用程序的计算和存储能力,能够在中心和边缘之间,在边缘与另一个边缘之间无缝流转,通过网络能力来进行联接。
由此,我们行业内也基于云原生的理念提出了边缘原生的一种倡导,让应用生长在标准化边缘基础设施的土壤上,来满足低延时、数据安全驻留、带宽节省等等 5G 的应用场景。
那么,容器混合云所包含的两个基本特征:“不可变基础设备” 和 “云网融合”,恰好与边缘原生的技术需求、以及商业需求都是非常匹配的。
所以,目前在国内外,我们也看到了大量的基于容器混合云落地的 5G MEC 解决方案。前段时间,我也发表过一遍《公有云上的 5G 专网》文章更详细的描述了这个发展现象,欢迎大家讨论指正。
原文链接:
https://blog.csdn.net/Jmilk/article/details/118892881
Kubernetes 诞生七年,凭什么成为主流?揭秘百度微服务监控:百度游戏服务监控的演进MongoDB 5.0 来了,原生时序、版本化 API 新特性悉数登场