漫画| 一图带你看懂云原生
感受科技之美
智领云成立于2016年,是一家数据中台服务商,专注于利用云原生技术将企业大数据系统各项组件容器化和服务化,打通企业内部数据孤岛,为企业提供全局、标准化的数据基础架构,帮助企业快速落地数据中台,使企业可以快速实施、开发、应用及管理其数据应用及资产,*终实现高效的数字化运营。
智领云联合创始人兼CEO彭锋对36氪表示,智领云创始团队曾负责Twitter、EA内部数据平台的搭建,看到了云原生技术、数据驱动能力对企业运营效率的提升。而且,团队在和一些国内头部客户的深度交流中,发现这些头部客户目前碰到的很多数据痛点都是团队在以前的工作中遇到和解决过的问题。
因此,在创立之初,智领云就是以企业内部如何实现数据共享和复用以及提高数据系统ROI(Return On Investment)为出发点,希望将每个企业所必需的这种数据能力平台产品化和普及化。
智领云还判断,企业未来的数据架构是会基于容器、DevOps、微服务等云原生技术来搭建的。所以,智领云选择从搭建*底层的云原生PaaS平台及容器大数据平台开始,再逐步向上完善。目前,智领云自下而上形成了包括云原生PaaS平台、容器大数据平台、数据集成开发平台和数据资产运营平台在内的产品体系。
其中,*底层的云原生PaaS平台采用Mesos+Docker+Kubernetes 技术作为底层架构,以此为基础实现分布式集群管理、容器定时任务调度、应用全生命周期管理、多用户管理和安全运维监控等功能。
彭锋表示,实现数据中台高扩展性的关键点在于降低系统耦合度,而容器技术则是解耦的核心手段。因此,智领云对主流使用的Hadoop、Hive、Spark、Kafka等多种大数据技术组件进行了容器化集成,实现大数据应用与底层运行环境之间的解耦。
在传统IT架构下企业的大数据组件只能在指定主机上运行,在系统集成时很可能与其他大数据组件发生冲突,升级运维流程复杂。而容器大数据平台解决了大数据组件安装、发布和管理复杂且低效的问题,各类大数据组件及应用之间可实现混合编排及运行。容器大数据平台同时具有统一账户、监控及日志管理等功能,方便企业实现统一的安全管理。同时企业各部门团队可以对所有组件实现单点登录,而无需登录不同账号来调用不同组件。
此外,企业除了调用大数据组件外,还会频繁使用爬虫、数据服务等常规数据采集或处理程序,然而传统IT架构下,两者无法混合运行,致使计算资源利用率不高。经过容器化集成后,在智领云容器化数据平台上,大数据组件和常规数据应用之间也可以实现混合编排运行,将传统架构下15%左右的集群使用率提高到云原生架构下的60%-70%,同时也降低了企业的运维成本。
企业在推行大数据架构时,往往发现在安装各类组件如Hadoop、Spark后并不能立即实现相应的数据能力。针对这一痛点,智领云推出数据集成开发平台,支持企业对包括业务数据、日志数据、第三方数据等在内的多类型内外部数据进行采集和处理,同时为企业客户提供从数据的采集到数据建模,数据开发,再到数据服务和可视化等一系列完整的数据流水线实施工具。
目前很多企业虽然掌握着规模庞大的数据资产,但往往很难掌握数据资产的全景,也无法快速厘清数据间的关联,更无法准确得知数据和应用建设的投入产出比(ROI)是多少。为此,智领云在前三层产品体系上推出数据运营管理平台,使企业可以以数据门户的形式来管理数据及应用资产。
彭锋表示,在底层,数据运营管理平台运用图数据库发现并记录数据之间的关系,比如数据和应用之间的生产和引用关系及应用和应用之间的关系,并记录数据应用的元数据,从而使得企业可快速定位所需的数据源,实时掌握数据资产及ROI的情况。
该平台也是企业内部数据资产的搜索引擎,企业通过它可以清晰快速地查询到各类数据,例如业务应用的调用次数、核心指标的计算方式等数据细节。在实现微服务基础上,企业可以通过API任意地调用相关的数据“积木”来实时搭建数据报表及应用。
截至目前,智领云已经通过直接对接或与行业软件开发商合作的方式服务了数十家用户,标准化产品的客单价约为50万元,客户复购率为100%,具体项目交付实施周期在三个月左右。智领云产品可以以工具形式与企业现有的平台对接,也可以独立发布端到端的大数据平台,根据大数据集群规模和系统集成的复杂度来核算价格。
在直接实际交付终端客户时,智领云会针对企业的痛点进行定制化服务。例如,智领云的某行业用户同时开展了线上线下业务,但各部门间和第三方间形成了数据孤岛,导致该客户无法实现用户的精准触达和验证广告渠道的真实效果。智领云将客户的内外部数据应用打通,实现对广告渠道的实时自动检测和用户画像的自动生成,快速解决该客户*迫切的需求,然后在同一平台上逐步扩展其它数据中台应用。
36氪此前也有报道同赛道的其他企业,如时速云、云徙科技、袋鼠云等。彭锋表示,通常的技术中台或业务中台侧重强调提高企业应用开发管理及运维效率,而智领云更侧重于帮助企业实现内部的数据共享、复用,快速开发管理以底层数据为驱动的各类应用。此外,智领云是从底层的云原生PaaS平台和容器大数据平台搭建起来,这也与同类数据中台企业大都选择由上层应用向底层架构延伸的路线不同。
至于未来发展规划,智领云希望进一步完善产品体系,逐步将各行业的场景模式,包括行业数据模型和数据能力应用,沉淀在平台产品上,使得企业客户可以自助式地使用智领云平台产品,快速搭建数据中台。同时,智领云将进一步扩展合作伙伴网络,明年预计将拓展100个合作伙伴,与更多业务软件开发商进行合作,实现快速市场拓展。
团队方面,联合创始人兼CEO彭锋为美国马里兰大学计算机博士,曾担任Twitter大数据架构师及大数据平台负责人、Ask.com工程总监;联合创始人兼CTO宋文欣为美国纽约州立石溪大学计算机博士,曾任EA大数据平台组高级研发经理、Ask.com Analytics团队技术经理。
在传统的研发中,我们经常关注的「安全」包括代码安全、机器(运行环境)安全、网络运维安全,而随着云原生时代的到来,如果还按原有的几个维度切分的话,显然容易忽略很多云原生环境引入的新挑战,我们需要基于网络安全*佳实践——纵深防御原则,来逐步剖析「云原生的安全」,并且对不同层次的防御手段有所了解,从而建立自己的云原生安全理念,真正搭建一个内核安全的云原生系统。
注:“纵深防御”,指在计算机系统中的多个层面使用多种网络安全技术,从而减少攻击者利用关键业务资源或信息泄露到系统外部的总体可能性。在消息传递和协作环境中,纵深防御体系可以确保恶意攻击活动被阻止在基础结构内的多个检查点,降低了威胁进入内部网络的可能性。
以 玉符 IDaaS 系统为例,我们把一个云原生系统安全模型分为 4 个层面,由外至内分别是:云/数据中心/网络层、集群层、容器层、代码层,如下图所示:
对于这里安全模型的每一层,都是单向依赖于外层的。也就是说,外层的云、集群、容器安全如果做得好,代码层的安全就可以受益,而反过来,我们是无法通过提高代码层的安全性来弥补外层中存在的安全漏洞或问题。
基于上述这一点原理,我们的纵深防御策略是「自外而内」地进行“设防”。
云/数据中心/网络层安全
这一层也可以称之为基础设施安全,不管从何角度,公有或私有云或企业数据中心以及对应的网络安全,是 K8s 集群*根本的安全基础,如果这一层存在安全漏洞或者过于脆弱,则整个系统都不能在此基础上保证组件的安全。
1. 不允许在 Internet 上公开对 Kubernetes 管理平台(Control Plane)的所有访问,同时仅开放部分可信 IP 可以访问 Kubernetes 管理 API。
2. 所有节点只暴露指定的端口,包括对管理平台的内部端口和来自 NodePort 和 LoadBalancer 类型的 Kubernetes 服务的连接,并且不应该直接暴露到 Internet。
3. 通过云提供商或机房的网络层安全组(例如 AWS 的 Security Group)对管理平台以及节点授予*小权限控制:
4. 对etcd(Kubernetes 的基础存储)的访问进行严格控制(仅允许来自集群管理平台的访问),应强制所有连接都使用TLS,并确保所有信息都是在持久化层被加密的(Encryption at rest)。
集群层
保护 Kubernetes 集群有两个主体需要关注:
针对这两个主体的保护,我们的保护可以分为 4 大块:管理 API 的访问控制、Kubelet 的访问控制、Runtime(运行时)工作负载或用户功能的访问控制、集群组件的安全漏洞防护,如下图所示。
1. 管理 API 的访问控制
a. 强制 TLS 保护传输层
b. 强制 API 认证
c. 强制 API 授权机制(RBAC)
2. Kubelet 的访问控制
a. 生产环境启用身份验证
b. 身份授权(RBAC)
c. 强制 TLS 保护传输层
3. Runtime(运行时)工作负载或用户功能的访问控制
a. 限制使用特权容器
b. 合理限制资源负载
c. 防止加载非必要内核模块
d. 限制 Pod 越权访问其他节点
e. 基础数据凭证的访问控制
4. 集群组件的安全漏洞防护
a. 禁止未授权访问 etcd
b. 启用审核日志记录
c. 定期轮换基础架构凭证
d. 定期升级修复漏洞
容器层
到了这一层,由于跟 Kubernetes 特性不是强相关,我们能提供一些通用的安全措施和建议:
代码层
程序代码层是*容易受攻击,但也是*可控的部分之一。虽然一般负责这块安全的人员不一定是运维开发(DevOps),可能是专门的安全工程师(Sec Eng),但有一些基本共性理念和建议是可以互相借鉴的。
总体来说,云原生时代的这四层架构:云/数据中心/网络层、集群层、容器层、代码层,与传统架构比起来更加细化和更易受攻击。自外而内地践行每一层的安全*佳实践,我们的纵深防御才能算是成功的,每个在云原生技术上想长期获益的团队需要对此有共识。
作者介绍:
陈伟嘉,毕业于加州大学尔湾分校,曾就职于Facebook、Splunk,现任玉符科技 CTO,负责玉符 IDaaS 技术架构设计和实现,带领研发团队从 0 到 1 实现产品自主研发,搭建无状态化支持、轻量化容器打包、运维自动化等微服务架构。
大约十年前,Netflix公司首次提出了“云原生”,这是一项关于云和计算的技术。这项技术推动了Netflix的发展,帮助他们从一家邮购公司发展成为了全球*受信任以及*大的消费者按需内容提供商之一。Netflix率先开发了云原生技术,并为所有软件开发的重塑、转型和扩展方面提供了宝贵的经验。
Netflix借助云原生技术,更快地向客户提供更多功能,从那时起,每家与软件打交道的公司都希望借鉴Netflix的云原生技术。云原生能够有效地提高业务速度,并可利用容器、Docker、Kubernetes等云原生技术提供自动化和可扩展性。
云原生之旅可以归结为三个关键性的决策,而这些决策都可以通过云原生得到解决。
基础设施的基本要求之一是计算机必须具有弹性。此外,基础设施还需要支持其他功能,例如可观察性、可见性、若干托管的服务等。基础设施是一个广泛讨论的话题,我不打算在本文中详细讨论。
云原生平台的选择比较容易,因为基本上Kubernetes已成为运行容器化微服务的默认平台。
这是一个复杂的决定,一般我会推荐Helm。Helm能够帮助你以更简单且可重用的方式安装Kubernetes的服务。以上我推荐的选择都是为了帮助开发人员专注于业务问题,而不必担心平台要求的负担等。
以上就是三个你需要做出的关键决策,而这就是你云原生之旅的起点。
各个公司可以采取多个步骤来推进这段旅程。
云原生的基本原则包括可扩展的应用、弹性架构以及频繁变更的能力。
在这段旅程中,有三个阶段需要注意:
● *个阶段:主要面向开发人员、采用容器。
● 第二个阶段:主要面向开发运维、部署应用程序。
● 第三个阶段:主要面向业务(端到端)、智能运营。
Vodafone 在“云原生世界”大会上展示了他们的云原生之旅。
在云原生之旅的中间,Vodafone将“为云做好准备”作为一个中间步骤。
“为云做好准备”的步骤包括向以API为中心转变,自动化应用构建和运行,消除对操作系统的依赖,并通过API实现基础设施即代码(Infrastructure as a Code,即IaaC)。
Vodafone的IT方面似乎比网络方面更成熟。大多数IT功能已经处于“为云做好准备”阶段,但是重新架构VNF以实现容器化,并让它们成为云原生是一项具有挑战性的任务。
保护网络安全是重中之重。拥有一个VPC,使用NAT(NAT用于控制出口,确保没有P地址、节点或对象被泄漏I)。使用RBAC,专用网络等,为了确保每个人都无法访问在Kubernetes集群中运行的API服务器,这些都是必需的。在Kubernetes上运行容器化微服务时,需要使用命名空间。因此,一切都可以归结为监视和控制入口点。
敏感信息非常重要,因此需要加密,因此我们需要使用机密数据。一个很好模式是在计划或设计Helm Chart时,将机密数据放到外部。然后使用约束,约束是限制集群滥用资源的关键,然后还有安全上下文,它应该是一组指定的策略。*后还有网络策略也是遏制滥用的另一种方式。
如果你在选定的平台和选定的基础设施上运行微服务,那么可以通过Helm Chart来部署应用程序,从而掌握所有的微服务。有些Pod是单独的,你可以在Pod中建立一个主容器和一个初始化容器,还可以运行一个sidercar。你可以为这些Pod建立多个副本,而且也可以具有依赖项。也许你需要运行一个数据库,也许你需要在同一个集群中运行另一个微服务,而且该依赖项可能也有一个主容器和一个sidercar容器。
微服务是云原生架构的基础,但是当你拆分单例应用程序时,可能会创建数十个、甚至数百个微应用程序。这些微应用程序中的每一个都需要进行观察和监视,这是一个很大的挑战。
由于许多微服务都涉及构建现代云原生应用程序,因此快速配置、部署、连续交付、严格的开发运维实践以及整体的监视和可观察性都是必要的。
你可以通过可观察性监视微服务的状况,确保它们的性能和行为。通过工具来掌握系统整体的运行状况和功能非常重要。
自从编程问世以来,日志记录一直被当作可观察性和监视指标的常规方法,但这对于云原生应用程序还不够。
重要的是你能够观察到系统的当前状况。你必须拥有现代化的监视工具SLA,并了解服务水平的稳健程度,以及解决问题和警告的平均时间。
GoCenter、ChartCenter等社区中心都建立了许多微服务。所有这些服务都默认在代码中加入了健康检查,并以此作为提高可观察性的良好实践。
假设我们在Kubernetes集群上安装了Redis,那么问题就是,我是否可以重用我的安装程序,运行100次,仍然可以获得相同的输出?如果答案是否定的,则表明你的系统存在安全隐患。除了安全问题之外,这也是维护的噩梦。对于微服务,可重用性是关键,而且不知道依赖关系来自何处,那么问题就很严重了。
那么,如何解决这个问题呢?答案很简单:使用包管理器,使用Helm。Helm可以提高可重用性以及可重复性。因此,Helm Chart和Helm Chart的各个版本都可以实现可重复性。
但是,这是真的吗?Helm生态系统是否保证可重复性?
上面提到的是一些严重的问题,并且与安全问题有很多的联系。因此,Helm生态系统虽然有其一定优势,同时也存在严重的弊端。
随着Kubernetes成为企业在云原生世界默认的容器编排平台,Helm可以帮助我们更轻松地重复安装和升级应用程序。尽管“ Kubernetes + Helm”组合是云原生的入门方法之一,但是仍然缺乏安全性,而ChartCenter满足了持续保护云原生生态系统的需求。
ChartCenter可以作为一种解决方案,帮助大家以可重复的方式提供公共的Helm Chart,从而确保云原生生态系统的安全,同时可以遏制日益增长的安全隐患。
ChartCenter可以为公开的K8s应用程序的Helm Chart提供安全可靠的来源。目前还没有标准规定生产者如何与云原生生态系统中的消费者共同承担安全隐患,也没有任何咨询说明。为了解决这个问题,我们提出了一个标准,该标准可帮助生产者使用Helm Chart提供安全缓解信息。
下面是一些ChartCenter的独特之处:
1. 中心存储库可以帮助用户轻松地设置客户端,并保持可追溯性。
2. 高可用性和可扩展性服务保障了可靠的生产服务。不可变性可以更进一步确保你放心地使用Chart,即便作者删除了Chart,你依然可以访问。
3. 出色的搜索功能,能够根据命名空间、名称、描述和标签快速找到合适的Chart。
4. 上游依赖:安装Helm Chart会拉取容器镜像以及其他子Chart,其中可能包含关系到安全和许可证的问题,因此我们不建议你使用被弃用或过时的依赖库。生产部署随时可以接收到这些重要的信息,这一点非常关键。
5. 随着Chart快速地发展,了解谁可能会受到更改的影响有助于增进稳定性和信任度。Chart的作者认为在支持向后兼容性和管理重大更改时,该功能非常有帮助性。
6. 安全扫描:ChartCenter会针对存储库中的1.2万个Docker镜像中包含的1.8M个组件进行连续扫描,这些镜像被3万多个Helm Chart版本引用。
现如今,每家公司都希望以高质量和高可靠性来巩固自家的软件产品。云原生之路让各个公司充满信心,相信他们可以快速地发布高质量的产品。Kubernetes和Helm等平台已经发展了很长一段时间,能够帮助软件公司利用云原生原则的力量,例如现代CI/CD、微服务等。希望本文提到的技术能够帮助你克服重重困难,顺利地完成云原生之旅。
原文链接:
https://dzone.com/articles/securing-your-cloud-native-journey
近日,CNCF发布了2020年云原生领域所有工作的年度总结[1],在疫情流行的形势下,我们度过了坚实的一年,希望读者朋友们阅读该报告。本文将分享我对云原生在2021年及以后发展方向及趋势的想法。
云原生IDE
未来,开发生命周期(代码、构建、调试)将主要发生在云上,而不是本地Emacs或VSCode。每个PR都会有完整的开发和部署环境,以满足开发和调试的需求。
目前,GitHub代码空间和GitPod都是这一技术的具体示例。虽然GitHub代码空间还在测试阶段,但您可以尝试使用GitPod。以Prometheus为例,在大约一分钟左右的时间里,您就拥有了一个完整的在线开发环境,包括编辑器和预览环境。*疯狂的是,这个开发环境(工作区)是用代码来描述的,并且像其他代码中间件一样可以与团队中的其他开发人员共享。
我期望未来能看到云原生IDE继续不可思议的创新,特别是GitHub代码空间结束测试阶段被广泛使用,这样开发者就可以体验到这个新概念并爱上它。
边缘Kubernetes
Kubernetes诞生于海量数据中心,但Kubernetes会像Linux一样演进到新的环境。Linux的*终结果是,*终用户扩展了内核,以支持不同领域下各种新的部署方案,包括移动端、嵌入式等。
我坚信Kubernetes会经历类似的演进,我们已经看到运行商(和初创企业)将Kubernetes作为边缘平台,通过KubeEdge、k3s、k0s、LFEdge、Eclipse ioFog等开源项目将VNF改造成CNFs(Cloud Native Network Function) 。超大规模云对运营商和边缘场景的支持,对云原生软件的复用能力,以及基于目前庞大的云原生生态系统的构建能力,这些推动力都在巩固着Kubernetes在未来几年作为边缘计算的主导平台的地位。
云原生+WASM
Web汇编(WASM)是一项刚刚起步的技术,但我希望它能成为云原生生态系统中日益重要的角色,特别是随着WASI的成熟,以及Kubernetes更多被用作上文描述的边缘协同器。一个用例是为扩展机制提供动力,就像LuaJIT和Envoy所做的那样。与其直接处理Lua,您可以使用支持多种编程语言的小型优化运行时。
Envoy项目目前正处于采用WASM的征程中,我期望任何环境都遵循类似的模式,而作为流行扩展机制的脚本语言,将来会被WASM完全取代。
在Kubernetes方面,有一些像微软的Krustlet这样的项目正在探索如何在Kubernetes中支持基于WASI的运行时。这应该不会太令人惊讶,因为Kubernetes已经通过CRD和其他机制来扩展,以运行不同类型的工作负载,比如VM (KubeVirt)等。另外,如果您是WASM的新手,我推荐这门来自Linux基金会的入门课程:
https://www.edx.org/course/introduction-to-webassembly-runtime。
FinOps 的崛起(CFM)
新型冠状病毒的爆发加速了向云原生的转变,至少有一半的公司正在危机中加速他们的云计划……近60%的受访者表示,由于COVID-19大流行(2020年云状况报告https://info.flexera.com/SLO-CM-REPORT-State-of-the-Cloud-2020),云使用率将超过先前的计划。*重要的是,云财务管理(FinOps)是一个日益增长的问题,也是许多公司所关心的问题。
老实说,在过去六个月中,我和一些公司在云原生旅程中进行了大约一半的讨论。你也可以说,云提供商并没有被激励去简化云财务管理,因为那样会让客户更轻松地减少开支。真正痛苦的是云财务管理缺乏开源创新和标准化(所有云的成本管理方式都不一样),CNCF中没有多少开源项目试图让FinOps更简单,目前的KubeCost项目还很年轻。
此外,Linux基金会*近推出了FinOps基金会,推动该领域的创新,他们在这个领域有许多介绍材料值得一读(https://www.edx.org/course/introduction-to-finops)。我希望在未来几年里,在FinOps领域看到更多的开源项目和规范。
更多的云原生Rust项目
Rust仍然是一种年轻而小众的编程语言,特别是如果你以Redmonk的编程语言排名为例。然而,我的感觉是,在未来一年,你会看到Rust在更多的云原生项目中,因为已经有少数CNCF项目开始利用Rust的优势,如microvm Firecracker。虽然CNCF目前*大部分的项目是用Golang编写的,但我期望在Rust社区成熟后的几年内,基于Rust的项目将与基于Go的项目持平。
GitOps + CD/PD大幅增长
GitOps是云原生技术的运营模型,提供一套统一应用部署、管理和监控的*佳实践(*初由来自Weaveworks的Alexis Richardson提出)。
GitOps*重要的方面是描述通过声明方式在Git中进行版本化的期望系统状态,这实际上使一组复杂的系统更改能够正确应用,然后进行验证(通过Git和其他工具启用的审计日志)。
从实用的角度来看, GitOps提升了开发者体验,随着Argo、GitLab、Flux等项目的不断增长,我预计GitOps工具今年将会对企业产生更多冲击。如果你看看GitLab的数据,GitOps仍然是一个新兴的实践,大多数公司尚未探索它,但随着越来越多的公司开始大规模采用云原生软件,GitOps的发展自然会如我所言。
服务目录2.0:云原生开发者看板
服务目录的概念并不是什么新东西,对于我们这些在ITIL时代长大的老人们来说,你可能会记得CMDB之类的东西,但是随着微服务的兴起和云原生的发展,对服务和各种实时服务元数据进行编目和索引的能力对于推动开发人员自动化至关重要。这可能包括使用服务目录来了解处理事件管理、管理SLO等的所有权。
将来,您将看到开发人员仪表板不仅仅是一个服务目录,而且能够通过各种自动化功能来扩展。典型的开源例子是Lyft的Backstage和Clutch,但是,任何应用云原生的公司往往都有一个试图构建类似的东西的平台基础架构团队。随着拥有大型插件生态系统的开源仪表盘的成熟,您将会看到越来越多平台工程团队加速使用他们。
跨云不再是梦想
Kubernetes和云原生运动已经证明,在生产环境中,云原生和多云方法是可能的。数据表明,93%的企业有使用微软、亚马逊和谷歌等多个云厂商的服务(2020年云状况报告https://info.flexera.com/SLO-CM-REPORT-State-of-the-Cloud-2020)。
随着云市场的不断成熟,Kubernetes有望开启编程式的跨云管理服务。一个具体例子体现在Crossplane项目中,它利用Kubernetes API的扩展性,提供一个开源的跨云控制平面,实现跨云工作负载管理(参见https://thenewstack.io/gitlab-deploys-the-crossplane-control-plane-to-offer-multicloud-deployments)。
eBPF成为主流
eBPF允许您在Linux内核中运行程序,而无需更改内核代码或加载模块,您可以将其视为沙箱扩展机制。eBPF允许新一代软件扩展Linux内核的行为,以支持各种不同的功能,包括改进的网络、监控和安全。eBPF的缺点是,它需要一个高版本的内核版本来利用它,而且在很长一段时间里,这对许多公司来说并不是一个现实的选择。
然而,情况正在改变,甚至较新版本的RHEL开始支持eBPF ,您将看到更多的项目使用它。如果你看看Sysdig的*新容器报告(https://sysdig.com/blog/sysdig-2021-container-security-usage-report/),你可以看到利用eBPF进行容器安全检查的Falco使用率正在大幅增长。因此,请继续关注并寻找更多基于eBPF的项目!
相关链接:
[1] CNCF 2020年度报告原文:
https://www.cncf.io/blog/2020/12/29/2020-cncf-annual-report
在都在说云原生,它的技术图谱你真的了解吗?中,我们对 CNCF 的云原生技术生态做了整体的介绍。从本篇开始,将详细介绍云原生全景图的每一层。
云原生全景图的*底层是供应层(provisioning)。这一层包含构建云原生基础设施的工具,如基础设施的创建、管理、配置流程的自动化,以及容器镜像的扫描、签名和存储等。供应层也跟安全相关,该层中的一些工具可用于设置和实施策略,将身份验证和授权内置到应用程序和平台中,以及处理 secret 分发等。
接下来让我们看一下供应层的每个类别,它所扮演的角色以及这些技术如何帮助应用程序适应新的云原生环境。
自动化和配置
是什么
自动化和配置工具可加快计算资源(虚拟机、网络、防火墙规则、负载均衡器等)的创建和配置过程。这些工具可以处理基础设施构建过程中不同部分的内容,大多数工具都可与该空间中其他项目和产品集成。
解决的问题
传统上,IT 流程依赖高强度的手动发布过程,周期冗长,通常可达 3-6 个月。这些周期伴随着许多人工流程和管控,让生产环境的变更非常缓慢。这种缓慢的发布周期和静态的环境与云原生开发不匹配。为了缩短开发周期,必须动态配置基础设施且无需人工干预。
如何解决问题
供应层的这些工具使工程师无需人工干预即可构建计算环境。通过代码化环境设置,只需点击按钮即可实现环境配置。手动设置容易出错,但是一旦进行了编码,环境创建就会与所需的确切状态相匹配,这是一个巨大的优势。
尽管不同工具实现的方法不同,但它们都是通过自动化来简化配置资源过程中的人工操作。
对应工具
当我们从老式的人工驱动构建方式过渡到云环境所需的按需扩展模式时,会发现以前的模式和工具已经无法满足需求,组织也无法维持一个需要创建、配置和管理服务器的 7×24 员工队伍。Terraform 之类的自动化工具减少了扩展数服务器和相关网络以及防火墙规则所需的工作量。Puppet,Chef 和 Ansible 之类的工具可以在服务器和应用程序启动时以编程方式配置它们,并允许开发人员使用它们。
一些工具直接与 AWS 或 vSphere 等平台提供的基础设施 API 进行交互,还有一些工具则侧重于配置单个计算机以使其成为 Kubernetes 集群的一部分。Chef 和 Terraform 这类的工具可以进行互操作以配置环境。OpenStack 这类工具可提供 IaaS 环境让其他工具使用。
从根本上讲,在这一层,你需要一个或多个工具来为 Kubernetes 集群搭建计算环境、CPU、内存、存储和网络。此外,你还需要其中的一些工具来创建和管理 Kubernetes 集群本身。
在撰写本文时,该领域中有三个 CNCF 项目:KubeEdge(一个沙盒项目)以及 Kubespray 和 Kops(后两个是 Kubernetes 子项目,虽然未在全景图中列出,但它们也属于 CNCF)。此类别中的大多数工具都提供开源和付费版本。
Container Registry
是什么
在定义 Container Registry 之前,我们首先讨论三个紧密相关的概念:
回到 Container Registry,这是分类和存储仓库的专用 Web 应用程序。
镜像包含执行程序(在容器内)所需的信息,并存储在仓库中,仓库被分类和分组。构建、运行和管理容器的工具需要访问(通过引用仓库)这些镜像。
解决的问题
云原生应用程序被打包后以容器的方式运行。Container Registry 负责存储和提供这些容器镜像。
如何解决
通过在一个地方集中存储所有容器镜像,这些容器镜像可以很容易地被应用程序的开发者访问。
对应工具
Container Registry 要么存储和分发镜像,要么以某种方式增强现有仓库。本质上,它是一种 Web API,允许容器引擎存储和检索镜像。许多 Container Registry 提供接口,使容器扫描/签名工具来增强所存储镜像的安全性。有些 Container Registry 能以特别有效的方式分发或复制图像。任何使用容器的环境都需要使用一个或多个仓库。
该空间中的工具可以提供集成功能,以扫描,签名和检查它们存储的镜像。在撰写本文时,Dragonfly 和 Harbor 是该领域中的 CNCF 项目,而 Harbor *近成为了*个遵循 OCI 的仓库。主要的云提供商都提供自己的托管仓库,其他仓库可以独立部署,也可以通过 Helm 之类的工具直接部署到 Kubernetes 集群中。
安全和合规
是什么
云原生应用程序的目标是快速迭代。为了定期发布代码,必须确保代码和操作环境是安全的,并且只能由获得授权的工程师访问。这一部分的工具和项目可以用安全的方式创建和运行现代应用程序。
解决什么问题
这些工具和项目可为平台和应用程序加强、监控和实施安全性。它们使你能在容器和 Kubernetes 环境中设置策略(用于合规性),深入了解存在的漏洞,捕获错误配置,并加固容器和集群。
如何解决
为了安全地运行容器,必须对其进行扫描以查找已知漏洞,并对其进行签名以确保它们未被篡改。Kubernetes 默认的访问控制比较宽松,对于想攻击系统的人来说, Kubernetes 集群很容易成为目标。该空间中的工具和项目有助于增强群集,并在系统运行异常时提供工具来检测。
对应工具
为了在动态、快速发展的环境中安全运行,我们必须将安全性视为平台和应用程序开发生命周期的一部分。这部分的工具种类繁多,可解决安全领域不同方面的问题。大多数工具属于以下类别:
其中的一些工具和项目很少会被直接使用。例如 Trivy、Claire 和 Notary,它们会被 Registry 或其他扫描工具所利用。还有一些工具是现代应用程序平台的关键强化组件,例如 Falco 或 Open Policy Agent(OPA)。
该领域有许多成熟的供应商提供解决方案,也有很多创业公司的业务是把 Kubernetes 原生框架推向市场。在撰写本文时,Falco、Notary/TUF 和 OPA 是该领域中仅有的 CNCF 项目。
密钥和身份管理
是什么
在进入到密钥管理之前,我们首先定义一下密钥。密钥是用于加密或签名数据的字符串。和现实中的钥匙一样,密钥锁定(加密)数据,只有拥有正确密钥的人才能解锁(解密)数据。
随着应用程序和操作开始适应新的云原生环境,安全工具也在不断发展以满足新的需求。此类别中的工具和项目可用于安全地存储密码和其他 secrets(例如 API 密钥,加密密钥等敏感数据)、从微服务环境中安全删除密码和 secret 等。
解决的问题
云原生环境是高度动态的,需要完全编程(无人参与)和自动化的按需 secret 分发。应用程序还必须知道给定的请求是否来自有效来源(身份验证),以及该请求是否有权执行操作(授权)。通常将其称为 AuthN 和 AuthZ。
如何解决
每个工具或项目实施的方法不同,但他们都提供:
对应的工具
此类别中的工具可以分为两组:
拿 Vault 来说,它是一个通用的密钥管理工具,可管理不同类型的密钥。而 Keycloak 则是一个身份代理工具,可用于管理不同服务的访问密钥。
在撰写本文时,SPIFFE/SPIRE 是该领域中唯一的 CNCF 项目。
供应层专注于构建云原生平台和应用程序的基础,其中的工具涉及基础设施供应、容器注册表以及安全性。本文是详细介绍了云原生全景图的*底层。在下一篇文章中,我们将重点介绍运行时层,探索云原生存储、容器运行时和网络的相关内容。
原文链接:https://thenewstack.io/the-cloud-native-landscape-the-provisioning-layer-explained/
随着Kubernetes已经成为容器编排和调度的事实标准,各大公有云厂商都已经基于Kubernetes提供了完善的Kubernetes云上托管服务。同时也看到越来越多的企业、行业开始在生产中使用Kubernetes, 拥抱云原生。在各行各业数字化转型和上云过程中,公有云厂商也在主动拥抱传统线下环境,在思考各种各样的解决方案使云上能力向边缘(或线下)延伸。
而Kubernetes由于屏蔽了底层架构的差异性,可以帮助应用平滑地运行在不同的基础设施上的特性,云上的Kubernetes服务也在考虑拓展其服务边界,云原生和边缘计算结合的想法自然就呼之欲出了。
目前国内各个公有云厂商也都开源了各自基于Kubernetes的边缘计算云原生项目。如华为云的KubeEdge,阿里云的OpenYurt,腾讯云的SuperEdge。目前网上很少有从技术视角来介绍这几个项目优缺点的文章,本文试着从技术视角,从开源视角来分析这几个项目,希望可以给大家做项目选型时提供一些借鉴。
比较思路
这几个项目都是云边一体,云边协同的架构,走的是Kubernetes和边缘计算结合的路数,因此决定从以下几点比较:
(1) 各个项目的开源状况:比如开源项目的背景、开源的时间、是否进入了CNCF等;
(2)Kubernetes架构:
(3)对边缘计算场景支持能力:
接下来以项目的开源顺序,从上述几个方面来介绍各个项目。
边缘云原生开源项目对比
2.1 KubeEdge
(1)开源状况
KubeEdge是华为云于2018年11月份开源的,目前是CNCF孵化项目。其架构如下:
(2)与Kubernetes的架构差异
首先从架构图可以看到,云端(k8s master)增加了Cloud Hub组件和各类controller,而在边缘端(k8s worker)没有看到原生的kubelet和kube-proxy,而是一个对原生组件进行重写了EdgeCore组件。
从架构图看EdgeCore是基于kubelet重构的,为了保证轻量化,裁剪了原生kubelet的部分能力,同时也增加了很多适配边缘场景的能力。具体如下:
上述的架构设计,对比Kubernetes的能力增强点主要有:
架构差异可能带来的影响:
因为目前云边通信链路是kube-apiserver –> controller –> Cloud Hub –>EdgeHub –>MetaManager等,而原生Kubernetes运维操作(如kubectl proxy/logs/exec/port-forward/attch等)是kube-apiserver直接请求kubelet。目前KubeEdge社区*新版本也仅支持kubectl logs/exec/metric,其他运维操作目前还不支持。
边缘计算场景支持能力
2.2 OpenYurt
(1)开源状况
OpenYurt是阿里云于2020年5月份开源的,目前是CNCF沙箱项目。架构如下:
(2)与Kubernetes的架构差异
OpenYurt的架构设计比较简洁,采用的是无侵入式对Kubernetes进行增强。在云端(K8s Master)上增加Yurt Controller Manager, Yurt App Manager以及Tunnel Server组件。而在边缘端(K8s Worker)上增加了YurtHub和Tunnel Agent组件。从架构上看主要增加了如下能力来适配边缘场景:
上述的架构设计,对比Kubernetes的能力增强点主要有:
架构差异可能带来的影响:
边缘计算场景
2.3 SuperEdge
(1)开源状况
SuperEdge是腾讯云于2020年12月底开源的,目前还是开源初期阶段。其架构如下:
(2)与Kubernetes的架构差异
SuperEdge的架构设计比较简洁,也是采用的无侵入式对Kubernetes进行增强。在云端(K8s Master)上增加Application-Grid Controller, Edge-Health Admission以及Tunnel Cloud组件。而在边缘端(K8s Worker)上增加了Lite-Apiserver和Tunnel Edge,Application-Grid Wrapper组件。从架构上看主要增加了如下能力来适配边缘场景:
与OpenYurt对比
2.4 对比结果一览
根据上述的对比分析,结果整理如下表所示:
项目 | 华为KubeEdge | 阿里OpenYurt | 腾讯SuperEdge |
是否CNCF项目 | 是(孵化项目) | 是(沙箱项目) | 否 |
开源时间 | 2018.11 | 2020.5 | 2020.12 |
侵入式修改Kubernetes | 是 | 否 | 否 |
和Kubernetes无缝转换 | 无 | 有 | 未知 |
边缘自治能力 | 有(无边缘健康检测能力) | 有(无边缘健康检测能力) | 有(安全及流量消耗待优化) |
边缘单元化 | 不支持 | 支持 | 支持(只支持Deployment) |
是否轻量化 | 是(节点维度待确认) | 否 | 否 |
原生运维监控能力 | 部分支持 | 全量支持 | 全量支持(证书管理及连接管理待优化) |
云原生生态兼容 | 部分兼容 | 完整兼容 | 完整兼容 |
系统稳定性挑战 | 大(接入设备数量过多) | 大(大规模节点并且云边长时间断网恢复) | 大(大规模节点并且云边长时间断网恢复) |
设备管理能力 | 有(有管控流量和业务流量耦合问题) | 无 | 无 |
各个开源项目,整体比较下来的发现
KubeEdge和OpenYurt/SuperEdge的架构设计差异比较大,相比而言OpenYurt/SuperEdge的架构设计更优雅一些。而OpenYurt和SuperEdge架构设计相似,SuperEdge的开源时间晚于OpenYurt,项目成熟度稍差。
如果打算选择一个边缘计算云原生项目用于生产,我会从以下角度考虑:
云原生(Cloud Native)是*近技术圈一个比较火的名词,相信大家或多或少都听说过。不过对于大多数普通研发朋友来说,”云原生”这个词多少可能还是有些陌生,以至于刚开始听到这个词时可能还会一脸懵逼的问”这到底是一个什么技术,我用过吗?”这样的问题。
其实这并不奇怪,因为对于*大多数普通开发者来说,我们大部分时间都是在别人构建的基础设施里专注于业务代码的开发,而很少关心业务应用运行所依赖的基础设施环境,但这恰恰也是构建云原生应用的核心意义所在。在今天的文章中,就和大家聊一聊关于云原生的话题!
云原生的概念
什么是云原生?对于这个问题我们需要理解,云原生并不是指某一项具体的技术,而是一组技术体系、概念及系统设计原则的集合。例如我们常讨论的微服务架构、Kubernetes容器编排、Devops等内容都是云原生体系的组成部分。
从这个角度看,对于目前已经实现了云服务部署、Spring Cloud微服务架构体系、Kubernetes容器化部署、且构建起了一套自动化发布系统的公司来说,事实上就已经是在践行云原生架构理念了。所以,你看是不是很多公司其实都已经在实施云原生架构了呢?
根据CNCF(云原生计算基金会)的官方描述,云原生技术是指有利于在公有云、私有云或混合云等新型动态环境下,实现应用可弹性伸缩部署的技术体系。云原生的代表技术主要包括容器、服务网格、微服务、不可变基础设施及声明式API。利用这些技术可以构建出容错性更好、更易于管理和观察的松耦合系统,再加上一些可靠的自动化技术及完备的监控预警体系,云原生技术将使开发人员能更快速、轻松地迭代和交付软件系统。
所以从上述描述看,云原生技术实际上并不是突然才流行起来的概念,而是随着云计算、微服务架构、服务网格等分布式应用架构技术普及流行,以及在以Docker、Kubernetes为代表的容器化技术的推动下,逐步被业界所认可的一种系统架构理念及设计原则的抽象总结。
云原生技术图谱
这里我总结了一份关于云原生架构的技术图谱供大家参考,如下图所示:
如上图所示,你会发现所谓的云原生简直就是一个技术大杂烩,它几乎囊括目前大部分流行的后端技术,甚至还延伸到了AI、机器学习、边缘计算等领域。但从实际应用场景来说云原生架构主要特征还是体现在云端环境、微服务架构、服务网格、Devops自动化交付、容器化部署这几个方面。
云端环境就是要使用云服务器,对于大部分公司来说就是使用阿里云、腾讯云之类的公有云服务来部署应用,而不是自己在额外维护一套复杂服务器机房。这样做的好处就在于利用云服务的弹性及分布式优势,可以大大降低运维成本,并且提升服务的稳定性。
而面向微服务的架构,能将原先耦合度高的单体系统,在遵循软件“高内聚、低耦合”设计原则的前提下,以独立业务能力为边界拆分为一个个原子系统。这样做的好处是,每个子系统都可以独立交付部署,从而能实现更敏捷的软件迭代效果。目前以Spring Cloud为代表的微服务技术,几乎已成为事实上的软件构建标准;而以Istio、Linkerd为代表的下一代服务网格技术也在快速发展,这一切都为云原生架构理念的普及作了有效地铺垫。
关于Devops,它强调的是以开发运维的视角,去构建一套高效完备的CI/CD流程,并通过自动化构建工具及发布系统,来实现软件生命周期的管理。从而使得普通开发人员,能够更快、更频繁地交付更加稳定的软件代码。例如我在本专栏发表的<<Kubernetes微服务自动化发布系统>>实际上就是一种Devops思想的具体实践案例,感兴趣的朋友可以参考下。
此外基于Kubernetes的容器化编排技术,已经事实上成为微服务运行的标准基础架构环境,也正是Kubernetes的流行,才真正推动了云原生架构理念的普及,Kubernetes可以说就是云原生架构的核心承载平台。关于Kubernetes的基本原理及具体实践本专栏也有一些文章可供参考,感兴趣的朋友可以阅读下。
总结
以上内容给大家大致介绍了下云原生的概念,并总结了目前云原生所涉及的主流技术栈图谱。从宏观上看云原生架构是一个非常庞大的体系,它几乎能包含目前软件后端技术领域的方方面面,但从细节上看它却又是我们现阶段工作中都多少能接触到的技术,例如Spring Cloud微服务、服务熔断限流、Kubernetes容器编排等等。
所以从某种程度上讲,云原生是一个抽象又具体的存在。它不是一个具体的产品,而是一套技术体系和一套方法论,随着围绕着云原生架构的各类开源技术的进一步发展,云原生技术体系必将成为主流,进而影响到每一个技术人员、每一个企业和行业。
WHAT:云原生是什么?
它有啥前世今生?
简单说,云原生(Cloud Native)是在云上构建和运行系统的方法论。*早移植上云的“非原住民”应用程序,往往还沿用私有化部署的技术架构,无法充分发挥云基础设施的优势。随着客户应用的深入,系统必须按照IaaS和PaaS的原理进行重构,以便跟上业务的爆炸性增长。
按照CNCF(Cloud Native Computing Foudation)定义,云原生一般包含CI/CD(持续集成持续交付)、容器化、微服务、存储计算分离、跨云多域、元数据管理等技术要素。
图源:CNCF
老实讲,从我这种从业 20 年数据技术老兵看来,这又是一波 buzzword,很多东西二十年前就有了,十几年前就已经成为互联网技术团队的标配。例如,2007 年 Google 已向 Linux 内核社区贡献 cgroup 补丁;再如,2008 年腾讯阿里招收计算机专业的应届生的面试题里就有 CI/CD 的问题;2013 年我在阿里云 ODPS 团队时,ODPS 的调度器和执行器已加上了 cgroup 能力;6 年前我*次创业,凭借 docker 容器化这个特点拿到了天使轮。
WHY:投资人不傻,为什么这些概念在创投领域突然变火?
云原生暗合当前行业的发展逻辑,才会受“追捧”。我猜所有重要的创新都要被“发明”两次,一次是从无到有生出来,一次是出圈。
*近业界有个新闻,2020 年,中国 IT 预算里超过 50% 的钱花在了云上。这是一个里程碑时刻,在中国这个喜欢私有化部署的市场里,云终于赢了。
大量的应用在云上,就遇到成本和效率的问题。举2个例子:
*个例子,云和大数据运维技术含量较高,很多看机房重启机器的传统运维工程师无力承担。但是线上数据、计算和应用规模还在以每年N倍的速度增长。如果不采用 CI/CD 而是坚持传统的人肉运维,先别说这种运维工程师的薪酬很高,你可能都招不到这么多合适的人。
第二个例子,客户如果把 Hadoop 不加修改直接部署到 ECS 节点上,数据通过HDFS存在云磁盘上成本会非常昂贵。客户必须修改 HDFS 底层,把数据存到对象存储上去。
成本和效率问题推动智能数据平台必须走向云原生,从而为用户带来如下收益:
1. 提高研发效率
通过微服务、CI/CD、对象体系、DevOps等一系列技术,提高代码开发、测试、发布效率,降低迭代成本。
2. 降低运维成本
同样,上面这些技术也可以实现开发及运维高效协同,有效提升对故障的响应速度,实现持续集成和交付,使得快速部署应用成为业务流程和企业竞争力的重要组成部分。
3. 降低存算成本
大数据基础设施的存储计算成本惊人。存算分离和容器化能够更高效地使用IaaS资源,降低存储成本。存储和计算节点分离后,可以在不对存储进行扩容的情况下快速增加计算资源。另一方面,单个容器的启动时间更快,占用空间更小,而且可以根据实际应用的大小来弹性分配资源,无需额外采购服务器。
4. 提高治理效率
数据治理是非常重要但“脏”且繁琐的工作。使用跨云治理、元数据管理等技术,会大幅度提高企业积累数据资产的效率,降低安全风险,提高供应商的多样化。
WHO:所有人都在阐释云原生,哪个更符合客户诉求?
到底是“谁的云原生”?
讨论云原生时,应该问清楚:“谁的云原生?”
AWS、阿里云、微软云、腾讯云、华为云、京东云、Google 云……每一家都推出了自己云原生技术,以吸引客户搬上自己的云。但技术接口的中立性和跨平台性被有意无意忽略了。
奇点云作为“AI 驱动的数据中台”创导者,是标准的乙方数据智能技术供应商,服务于泛零售、金融、电信等行业,其中不乏各行业的头部企业。所以我们有动力做下面两件事:
总而言之,和客户站在一起。
你会发现,在美国,尽管 AWS 的产品非常强大,但是 snowflake 和 databricks 依旧服务了很多世界五百强企业。原因就是这些头部企业需要把自己的 IaaS 供应商多样化。逻辑很类似。
所以“奇点云的云原生”,相比常规定义,多强调了几个因素:对象体系、跨平台、自主可控。我们的产品支持 AWS、阿里云、微软云、腾讯云、华为云、京东云、Google 云,并实现跨云的多 workspace 管理,能实现客户数据与应用的跨云治理和迁移。而且系统基本的架构体系设计更开放、更安全、更容易集成。
HOW:对于云原生,数据领域有什么倾向?
具体通过哪些技术要素实现云原生?
我们先回顾一下数据技术的演进阶段:
阶段 #1
关系性数据库出现,SQL 统一数据开发工业标准,开始区分 OLTP 和 OLAP。
问题:随着业务成长,数据量爆炸,尤其是互联网影响的深入,传统关系型数据库逐渐扛不住海量数据的压力。
阶段 #2
大数据技术出现,支撑海量数据的处理,OLAP 本身又被分成了离线和实时。
问题:针对不同场景的各种大数据引擎不断出现,反过来又刺激了更多数据的生成。海量数据的成本开始变成沉重的负担,如果不能把数据变成“资产”,帮助业务赚钱或省钱,就没法持续支撑大数据基础设施的持续投入。
阶段 #3
数据中台出现,提出一系列的业务方法论,强调积累数据资产。
问题:数据中台在互联网公司的实践获得了相当大的成功。但是在其他行业,如果纯粹 100% 生硬照搬互联网的业务架构和产品形态,会遇到很多水土不服。举个例子,传统行业的企业有大量的线下场景,需要考虑很多数据集成、跨平台治理、数据安全、自主可控的问题。
阶段 #4
数据智能深入场景,AI 成为数据中台的入口和出口,业务和数据上云趋势加快,多域数据治理成为刚需,国内用户愿意为自主可控技术买单。
你可以看到,每一阶段技术都是为了解决上一代问题诞生的。
所以,大数据领域的业务特点会推导对云原生的一些倾向性:
1. 数据中台存储海量数据,且作业高吞吐高并发,对存算分离的各项指标要求明显高于其他领域的应用;
2. 大数据集群规模大进程多,天然需要微服务治理和其他智能运维技术;
3. 客户对数据安全、数据确权*其关注,加上toB的分级多域数据治理场景非常复杂,产生了对跨平台技术、数据安全技术、合规数据合作技术的强烈需求;
4. 由于目前的国际政经形势,自主可控的大数据引擎,对国内企业而言是一个刚需。
想清楚了这些,“奇点云的云原生”具体做了如下的研发:
# 容器化编排:容器化本质上是一种虚拟化技术,一台主机可虚拟出上千个容器。单个容器的启动时间更快,占用空间更小,而且可以根据实际应用的大小来弹性分配资源,无需额外采购服务器,加快研发速度。
# 对象体系:根据现有业务抽象出核心对象,以标准RESTful风格提供API服务,解耦核心对象与业务层服务,以应对不同环境、不同业务场景的需求。这一系列正交的核心对象就构成了平台对象体系,上层业务可在此基础上构建应用,高效演进。
# CI/CD:通过版本管理系统和DevOps基础设施,实现自动化测试和持续集成。一个典型流程是,程序员提交代码到特定的tag,触发测试接口自动化测试脚本+开发单测脚本(偏提交代码新功能的)执行并发送报告。由此实现测试、发布和部署自动化。在此基础上构建特定的数据环境,对重要接口和链路进行自动化检测。
# 存算分离:如果把Hadoop、Spark等常规开源大数据引擎直接应用于云主机,海量数据带来的存储成本和吞吐压力,会很快“压垮”客户。因此,必须引入中间缓存实现计算存储分离,将数据存储到对象存储上,同时兼容HDFS协议,能够根据业务需求进行弹性扩容,就能大幅度降低成本,提高集群性能。
# 跨云治理:在AWS、阿里云、华为云、腾讯云、京东云等平台,实现统一账号、权限和审计的多workspace的兼容管理,并进一步提供数据安全和可信计算方案,从而提高基础设施的可控性和安全性。
# 元数据管理:对数据的结构、指标、标签、权限、上下游血缘、生产作业等元信息进行规范化管理,建立智能数据治理体系,支持数据盘点、安全审计、血缘分析、关键分级等应用,*终实现数据资产化。
WHERE:客户在哪些场景用上了云原生数据中台?
简单举几个客户应用我们的云原生数据中台DataSimba的例子吧(均为真实案例,保密原因,不能指明):
案例 #1
某互联网APP,在海内外都很受欢迎。由于地域和法规的要求,他们必须在多个国家的多种IaaS上实现数据生产和合规隔离,例如:在印度部署1个workspace在孟买AWS上,在美国部署1个workspace在Oracle云上,在中国部署1个workspace在阿里云上……同时又实现账号权限、数据审计和安全策略的全局管理。
案例 #2
某大型电子设备制造公司,由于战略和业务的原因,必须把自己IaaS供应商多样化:部署1个workspace在华为云上,以便对接政企系统;部署1个workspace在AWS上,以便满足海外客户的审计需求;再部署1个workspace在阿里云上,以便支持和阿里云的战略合作……同时又要进行全局的数据资产管理。
案例 #3
某大型零售品牌集团,本身就有多个互相竞争的子品牌,彼此要求数据做必要隔离和客户隐私保护,同时总部又要进行全面的数据拉通。另一方面,该品牌商会对接多个流量电商平台:在阿里云放一个workspace支持双11,在京东云放一个workspace支持618。再加上几十个线上线下系统的数据的集成和拉通,形成了很复杂的分级多workspace的云原生数据治理体系。
案例 #4
某流通业的大型集团,各个分公司比较独立,IT经费充足。这时候总部上一个分级数据治理的多workspace数据中台,旗下比较大的分公司有自己独立机房的可以单独部署workspace,而小一些的公司在阿里云或华为云上开通workspace。总部对所有workspace拥有账号管理和审计的权利,同时控制住数据建模规范标准和指标的版本发布。
不同行业的不同企业,搭建出不一样的云原生跨平台数据治理体系,这其中的业务逻辑复杂微妙。我们再对比一下互联网大厂的数据平台——大一统式的数据打通,跑在几千台节点集群上,就可以发现两边产品上的着眼点并不相同。
伴随云计算的滚滚浪潮,云原生(Cloud Native)的概念应运而生,云原生很火,火得一塌糊涂,都9102年了,如果你还不懂云原生,那真的Out了。
大家言必称云原生,却鲜少有人告诉你到底什么是云原生,若是找资料来看,读完大多会感觉云绕雾罩,一知半解,总之虚得很;
甚至会让你一度怀疑自己的智商,不过我对于读不懂的文章,一律归因于写文章的人太蠢,当然这不一定是事实,但这样的思考方式能让我避免陷入自我怀疑的负面情绪。
云原生之所以解释不清楚,是因为云原生没有确切的定义,云原生一直在发展变化之中,解释权不归某个人或组织所有。
技术的变革,一定是思想先行,无产阶级革命事业兴旺发达也是因为有战无不胜的马指导。
何谓云原生?
云原生是一种构建和运行应用程序的方法,是一套技术体系和方法论。云原生(CloudNative)是一个组合词,Cloud+Native。
Cloud表示应用程序位于云中,而不是传统的数据中心;Native表示应用程序从设计之初即考虑到云的环境,原生为云而设计,在云上以*佳姿势运行,充分利用和发挥云平台的弹性+分布式优势。
Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念;2015年,云原生刚推广时,Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征:12因素、微服务、自敏捷架构、基于API协作、扛脆弱性;
到了2017年,Matt Stine在接受媒体采访时又改了口风,将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质;而Pivotal*新官网对云原生概括为4个要点:DevOps+持续交付+微服务+容器。
2015年云原生计算基金会(CNCF)成立,CNCF掺和进来后,*初把云原生定义为包括:容器化封装+自动化管理+面向微服务;
到了2018年,CNCF又更新了云原生的定义,把服务网格(Service Mesh)和声明式API给加了进来。
可见,不同的人和组织对云原生有不同的定义,相同的人和组织在不同时间点对云原生也有不同的定义,真是乱的一匹,搞得鄙人非常晕菜,我的应对很简单,选一个我*容易记住和理解的定义:DevOps+持续交付+微服务+容器。
总而言之,符合云原生架构的应用程序应该是:采用开源堆栈(K8S+Docker)进行容器化,基于微服务架构提高灵活性和可维护性,借助敏捷方法、DevOps支持持续迭代和运维自动化,利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
云原生构建应用简便快捷,部署应用轻松自如、运行应用按需伸缩。优点不一而足,缺点微乎其微;秒杀传统Web框架,吊打祖传IT模式,实在是保命装逼、评优晋级不可多得的终**密武器。
云元素的四要素
微服务:
几乎每个云原生的定义都包含微服务,跟微服务相对的是单体应用,微服务有理论基础,那就是康威定律,指导服务怎么切分,很玄乎,凡是能称为理论定律的都简单明白不了,不然就忒没b格,大概意思是组织架构决定产品形态,不知道跟马克思的生产关系影响生产力有无关系。
微服务架构的好处就是按function切了之后,服务解耦,内聚更强,变更更易;另一个划分服务的技巧据说是依据DDD来搞,不过鄙人对DDD知之甚少。
容器化:
Docker是应用*为广泛的容器引擎,在思科谷歌等公司的基础设施中大量使用,是基于LXC技术搞的,容器化为微服务提供实施保障,起到应用隔离作用,K8S是容器编排系统,用于容器管理,容器间的负载均衡,谷歌搞的,Docker和K8S都采用Go编写,都是好东西。
DevOps:
这是个组合词,Dev+Ops,就是开发和运维合体,不像开发和产品,经常刀刃相见,实际上DevOps应该还包括测试,DevOps是一个敏捷思维,是一个沟通文化,也是组织形式,为云原生提供持续交付能力。
持续交付:
持续交付是不误时开发,不停机更新,小步快跑,反传统瀑布式开发模型,这要求开发版本和稳定版本并存,其实需要很多流程和工具支撑。
如何云原生?
首先,云原生借了云计算的东风,没有云计算,自然没有云原生,云计算是云原生的基础。
随着虚拟化技术的成熟和分布式框架的普及,在容器技术、可持续交付、编排系统等开源社区的推动下,以及微服务等开发理念的带动下,应用上云已经是不可逆转的趋势。
云计算的3层划分,即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引,真正的云化不仅仅是基础设施和平台的变化,应用也需要做出改变,摈弃传统的土方法,在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点,重新设计,从而建设全新的云化的应用,即云原生应用。
可见,要转向云原生应用需要以新的云原生方法开展工作,云原生包括很多方面:基础架构服务、虚拟化、容器化、容器编排、微服务。
幸运的是,开源社区在云原生应用方面做出了大量卓有成效的工作,很多开源的框架和设施可以通过拿来主义直接用,2013年Docker推出并很快成为容器事实标准,随后围绕容器编排的混战中,2017年诞生的k8s很快脱颖而出,而这些技术*大的降低了开发云原生应用的技术门槛。
虽说云原生的推介文档有引导之嫌,但面对它列举的优点,作为杠精的我亦是无可辩驳。这么说的话,云原生也忒好了吧,应用是不是要立刻马上切换到云原生架构?
我的观点是:理想很丰满,现实经常很骨感,需从应用的实际需要出发,目前的问题是否真的影响到业务发展,而推倒重来的代价能否承受得来。
技术的趋势和影响
软件设计有两个关键目标:高内聚、低耦合,围绕这2个核心目标,又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、*少知识等设计原则。
软件工程师一直都在为这两个目标而努力奋斗,以求把软件编写得更加清晰、更加健壮、更加易于扩展和维护。
但后来,人们发现有更多的诉求,希望开发软件变得更简单、更快捷,程序员希望更少编写代码,非专业人员也希望能开发程序,于是,更多的更傻瓜的编程语言被发明出来,更多的编程技术和编程思想被发明出来,比如库、组件、云基础设施。
于是很多技术变成了屠龙之技,比如汇编,时代变了,建国后动物不能成精了,没有龙可以宰了,然后很多软件工程师摇身一变成了调参工程师、Call API砖家、用库包能手、拼组件达人,这是效率分工的结果,也是技术发展的使然。
纵观近二十年的科技互联网发展历程,大的趋势是技术下沉,特别是近些年,随着云计算的发展和普及,基础设施越来越厚实,业务开发变得越来越容易,也越来越没有技术含量,而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在,这不禁让互联网行业的油腻大叔们噤若寒蝉,仿佛分分钟就要被卷入历史洪流而万劫不复。
虽然不可否认技术的重要性在降低,但也还不至于那么悲观。遥想PC时代,当VB、Delphi、MFC出现的时候,也有类似论调,所见即所得,点点鼠标,就可以开发PC桌面程序,是不是很高端?
那时候码农的担心相比现在恐怕是只多不少吧,但后来随着互联网兴起,出现了后端开发这个工种,码农很快找到了新的战场,网络、分布式、数据库、海量服务、容灾防错,于是又玩出一堆新花样。
如果说PC时代的基础设施是控件库,互联网时代的基础实施是云,那AI时代基础设施是什么?又有什么高端玩法?
友情链接: SITEMAP | 旋风加速器官网 | 旋风软件中心 | textarea | 黑洞加速器 | jiaohess | 老王加速器 | 烧饼哥加速器 | 小蓝鸟 | tiktok加速器 | 旋风加速度器 | 旋风加速 | quickq加速器 | 飞驰加速器 | 飞鸟加速器 | 狗急加速器 | hammer加速器 | trafficace | 原子加速器 | 葫芦加速器 | 麦旋风 | 油管加速器 | anycastly | INS加速器 | INS加速器免费版 | 免费vqn加速外网 | 旋风加速器 | 快橙加速器 | 啊哈加速器 | 迷雾通 | 优途加速器 | 海外播 | 坚果加速器 | 海外vqn加速 | 蘑菇加速器 | 毛豆加速器 | 接码平台 | 接码S | 西柚加速器 | 快柠檬加速器 | 黑洞加速 | falemon | 快橙加速器 | anycast加速器 | ibaidu | moneytreeblog | 坚果加速器 | 派币加速器 | 飞鸟加速器 | 毛豆APP | PIKPAK | 安卓vqn免费 | 一元机场加速器 | 一元机场 | 老王加速器 | 黑洞加速器 | 白石山 | 小牛加速器 | 黑洞加速 | 迷雾通官网 | 迷雾通 | 迷雾通加速器 | 十大免费加速神器 | 猎豹加速器 | 蚂蚁加速器 | 坚果加速器 | 黑洞加速 | 银河加速器 | 猎豹加速器 | 海鸥加速器 | 芒果加速器 | 小牛加速器 | 极光加速器 | 黑洞加速 | movabletype中文网 | 猎豹加速器官网 | 烧饼哥加速器官网 | 旋风加速器度器 | 哔咔漫画 | PicACG | 雷霆加速 |