关于cncf:扎根开源DatenLord正式成为CNCF云原生计算基金会银级会员

一、退出CNCF达坦科技(DatenLord)于往年9月份刚刚正式退出成为CNCF银级会员。其专一于打造新一代开源跨云存储平台,致力于解决跨云、跨数据中心场景下异构存储、数据对立治理等问题,满足不同行业客户对超大规模数据跨云、跨数据中心高性能拜访的需要。 DatenLord达坦科技打造的高性能分布式存储产品DatenLord,通过优化IO全门路各个环节,实现最大化升高由Linux操作系统内核带来的本地IO和网络IO的开销,再通过联合硬件加速技术取得数量级性能晋升。这种软硬件深度交融的解决方案,建设了一个对立的存储拜访层,为跨云的利用提供高性能和高安全性的存储反对,从而突破云的阻碍。 随着云计算的遍及和成熟,企业客户出于业务系统安全稳固的考量,或突发申请的解决,以及业务跨地区散布及其数据寰球部署等原因,IT架构从单数据中心向多数据中心演变,多地多核心部署的场景越来越广泛,这催生了跨云数据对立拜访的需要。DatenLord能够实现跨云数据对立治理,诸如自动化实现数据迁徙、备份、并对利用通明,不便企业应用上云和迁徙。特地的,对于常常拜访的、须要跨云共享的热数据,DatenLord还提供了高性能的一致性保障,确保热数据拜访的性能和正确性。 软硬件深度交融达坦科技采纳软硬件深度交融的形式来实现高性能跨云存储,由硬件来实现存储性能减速,由软件来实现分布式存储管理。首先,达坦科技自研存储专用的硬件加速器,实现硬件加速网络、加密、压缩和编码等分布式存储相干的性能。此外,达坦科技摸索新一代硬件麻利开发与验证方法论,交融函数式编程、形式化验证等前沿技术理念来落地硬件麻利开发。 同时,在软件算法层面达坦科技致力于摸索广域网分布式共识协定的实现。以后的分布式共识协定通常只限于在单个数据中心应用,跨数据中心的分布式共识协定只限于实践钻研。达坦科技致力于研发业界第一个基于广域网共识协定的跨云分布式一致性管理工具Xline,用于保障热数据跨云拜访的一致性。 开源的力量达坦科技置信开源的力量,DatenLord的软硬件实现全副开源,一方面心愿在分布式系统、Linux内核、开源硬件等组件方面能吸引到更多寰球人才,另一方面助推产品倒退的同时也回馈开源社区。 达坦科技心愿在打造跨云分布式存储系统的同时,推动云原生计算的可继续倒退,因而,退出CNCF这一兼具凋谢与单干的生态平台,心愿能够和其余具备雷同愿景的同道者一起助推云原生技术的倒退。 二、达坦科技开源我的项目DatenLordhttps://github.com/datenlord/... DatenLord 是专门为serverless、微服务场景打造的多集群分布式缓存零碎,目前提供了 Posix 兼容的文件拜访接口,反对多集群同时数据拜访,并且保障了数据的一致性。DatenLord 应用 S3 对象存储作为后端存储,反对海量数据的可拓展性。因为Posix 接口被应用程序宽泛应用,所以应用程序能够无缝对接 DatenLord,为用户提供了通明的、高性能多集群数据拜访解决方案。 Xlinehttps://github.com/datenlord/... Xline 是一个面向跨数据中心多集群场景的分布式 KV 存储引擎,用来管理系统的要害数据,如索引、配置等要害的元数据。Xline 使得跨数据中心多集群的元数据管理成为可能,Xline 能够实现跨云、跨数据中心场景下数据高性能拜访以及数据强一致性。目前Xline 兼容 etcd 接口,不便现有 etcd 用户能够无缝地切换到 Xline,以满足跨数据中心多集群利用场景的数据拜访需要。 Asnyc-rdmahttps://giithub.com/datenlord... Async-rdma 是用 Rust 语言封装的 RDMA SDK,采纳 Rust 语言的异步执行机制,为 RDMA 提供了平安高效的 Rust 接口。Async-rdma 在原始 RDMA 接口上提供了高层的语义形象,升高 RDMA 利用的开发难度,缩小了出错的可能性,同时大大简化出错之后排查问题的复杂度。

September 23, 2022 · 1 min · jiezi

关于cncf:DevStream-进入-CNCF-沙箱探索云原生时代的高效-DevOps-实践

2022 年 6 月 15 日,云原生计算基金会 (CNCF) 发表 DevStream 正式成为 CNCF 沙箱(Sandbox)我的项目。 DevStream 是一个开源的 DevOps 工具链管理器,能够通过一个简略的配置文件,将软件研发生命周期中各环节的 DevOps 工具对立治理起来,实现各工具的疾速装置部署、工具间整合、最佳实际配置等工作。 许多研发团队可能会在 DevOps 工具链治理中遇到挑战,例如: 不晓得如何抉择 DevOps 工具没有足够的人力、工夫去调研大量 DevOps 工具在 DevOps 工具链的整合和保护上力不从心DevStream 次要解决开源 DevOps 工具链落地难、保护难的痛点,一方面让开发者少在 DevOps 工具上踩坑,投入更多的精力在更重要的业务逻辑上;另一方面让研发团队不再受限于保护和替换老本,可能更自在地抉择最合适的工具组合,使效力最大化。 次要个性为了反对 DevOps 工具链的灵便高效治理,DevStream 具备以下个性: 配置代码化:对立治理 DevOps 各环节工具,工具链变更历史可回溯Core-Plugin 架构:内核与插件解耦,使 DevOps 工具链像乐高一样灵便可定制易于应用:最佳实际积淀为工具配置,不便用户开箱即用,例如 GitOps 工具链的疾速搭建 自 2022 年 2 月上线 v0.1.0 并开源以来,DevStream 高速迭代。在本次进入沙箱之前,DevStream 已于 5 月中旬退出 CNCF 云原生全景图的自动化和部署工具类别。 目前, DevStream 更新至 v0.6.1,并新增以下要害性能: 更丰盛的插件反对,已反对 JIRA/Trello 治理我的项目与事务并买通 GitHub/GitLab、Golang 脚手架生成、Jenkins/GitHub Actions/GitLab CI 治理 CI 流程等一系列工具插件,且还在继续新增中。更欠缺的命令集更成熟的插件治理逻辑,主动感知并评估工具的状态变更,可作为 single source of truth 一站式治理各工具插件更弱小的配置管理逻辑,反对插件之间的依赖治理与配置援用等 ...

June 17, 2022 · 1 min · jiezi

关于cncf:DevStream-成为-CNCF-Sandbox-项目啦-锣鼓喧天鞭炮齐鸣红旗招展忘词了

开局两张图,内容全靠“编”来,有图有假相! DevStream ❤️ CNCF CNCF Cloud Native Interactive Landscape 庄重版本,留给庄重的人我不代表 DevStream 团队官宣“DevStream 成为 CNCF Sandbox 我的项目”这个事。 咋说,毕竟, 官宣版本太庄重了,那不是我的格调。可能你看到我这篇“胡说八道”的时候,官宣版本也进去了。 庄重版本,留给庄重的人,我只代表本人掰扯这个事儿~ (尝试用这个旋律哼这句话:特地的爱,给特地的你,我的寂寞逃不过你的眼睛) 帷幄之中,笑看云卷云舒你永远猜不到某一天我在哪个“帷幄”。 我可能在“装土豪”,喝着咖啡听着歌,抿着洋酒敲键盘~ 也可能在“路边躺”,抱着一个死贵的 MacBook 和一瓶死便宜的矿泉水,像个乞丐席地坐,放飞自我,任别人来人去,看客回眸,指指点点~ 云来昨日,夜黑风高,万里无云,一声呐喊,划破了夜的沉寂... 啥?进啦? 进啦! 去验证一下,我晓得有个链接能够查问真伪。 看来是进去了! 看到这里,我只有一个想法:我如同缺一点发朋友圈的素材啊! 云卷素材这种货色,须要我去收集? 静坐三分钟,喝一杯咖啡,静候铁心的总结~ (没错,我晓得他肯定会去看一堆的英文资料,各种文档和视频,而后三分钟后就会发一个总结进去) 总结来~ 没错,不是吹的,就那么几分钟,DevStream 毫无悬念,就过了~ 就那么几分钟,根本都是在夸,我也不晓得在夸谁,多多少少,按理说,还是有夸到我的吧。算连带责任,额,不,连带夸赞。 如果你的 pc 是迷信的,点开这个链接,感受一下吧:https://www.youtube.com/watch... 激励 DevStream 社区所有小伙伴点开看看,你们都在被“连带夸赞”。 不要自豪,千万别自豪!自豪留到周五,也就是今天,咱去喝一杯! 云舒这一刻我没啥想总结的,万里长征不到半,进 Sandbox 远不是起点! 方才仿佛我放松了几分钟,微笑着抿了半杯咖啡了~ 放下马克杯,收起笑容,前面的路并不是毫无荆棘~ 在 DevStream 被退出 CNCF Landscape 那天,我在群里和大家说:“当初退出 DevStream,过几年,就能够吹牛逼:作为外围开发者参加 CNCF 我的项目的从啥也没有到毕业了。”(这句话被 Bird 记录在他的博客里了) 在 DevStream 被退出 CNCF Sandbox 那天,我还是在群里和大家说:“当初退出 DevStream,过几年,就能够吹牛逼:作为外围开发者参加 CNCF 我的项目的从 Sandbox 到毕业了。” ...

June 16, 2022 · 1 min · jiezi

关于cncf:CNCF-沙箱项目-OCM-Placement-多集群调度指南

简介:在这篇文章中,将介绍 Placement 如何抉择到所需的集群,Placement 能够提供的调度性能,以及一些场景下的最佳实际,使用者能够参考示例来编写合乎本人要求的 Placement。其余一些高级调度性能,如反对污点 (taints) 和容忍 (tolerations),以及拓扑抉择 (spread),正在 OCM 社区探讨中。 作者: 邱见|红帽资深软件工程师,Open Cluster Management (OCM) 社区发起人,负责人 郝青|红帽高级软件工程师,Open Cluster Management (OCM) 社区维护者 Open Cluster Management(OCM) 我的项目曾经在 2021 年 11 月 9 日成为 CNCF 的沙箱我的项目。OCM 作为一个社区驱动的我的项目,专一于 Kubernetes 应用程序的多集群和多云场景。 最新 OCM 社区版本 0.6.0 已于 2022 年 1 月 21 日正式公布。具体内容可拜访 Open Cluster Management 0.6 公布[1]。 在多集群环境中,不同角色的用户对多集群操作有着不同的需要。比方管理员等用户须要对指标集群进行一些配置, 应用程序开发人员可能心愿将工作负载部署到特定集群,这些工作负载能够是 Kubernetes 的 Service、Deployment、ConfigMap 或不同 Kubernetes 对象的捆绑包。这些用户对指标集群会有一些要求,比方: 我只想在 Amazon Web Services(AWS) 上配置集群。我只想将工作负载部署到标签为 group=dev 的集群上。我心愿工作负载始终在具备最大可分配内存的 3 个集群上运行。为了抉择出指标集群,能够抉择在部署管道 (deploy pipeline) 中对间接指定指标集群名称,或应用某种模式的标签选择器。对于对资源有要求的工作负载,须要一个细粒度的调度器来将工作负载散发到具备足够资源的群集。当群集属性更改时,调度后果应该放弃动静更新。 ...

April 22, 2022 · 7 min · jiezi

关于cncf:Carina-本地存储入选-CNCF-云原生全景图

近日,依据 CNCF 最新版本的云原生全景图(Cloud Native Landscape),Carina 本地存储我的项目已被纳入云原生存储(Cloud Native Storage)板块。 更多全景图信息,请见:https://landscape.cncf.io CNCF (Cloud Native Computing Foundation),是由 Google 牵头创建的云原生计算开源软件基金会。它致力于云原生 (Cloud Native) 技术的遍及和可继续倒退。2016 年 11 月,CNCF 开始保护 Cloud Native Landscape,汇总风行热门的云原生技术与工具,并加以分类,为企业构建云原生体系提供参考,在云生态研发、运维畛域具备宽泛影响力。 Carina 于 2021 年 10 月由博云正式开源(https://github.com/carina-io/...),是一款专一于本地存储的解决方案。Carina 基于 Kubernetes 及 LVM,提供了数据库与中间件等有状态利用在 Kubernetes 中运行所必须的高性能的本地存储能力,同时极大的缩小了存储系统的运维压力。 Carina 曾经迭代到了 0.9.1 版本,新增反对间接将裸盘划分分区提供给容器应用的性能,进一步倒退了本身性能。Carina 凭借着高性能和免运维的特点,为中间件、数据库等有状态服务提供了匹配本地磁盘的高 IOPS 和极低提早的性能指标,同时易装置、自运维能力又极大的加重了存储系统的运维压力。 另外,Carina 还提供了本地磁盘治理能力、PV 高级调度能力、PV 主动分层技术、卷拓扑能力、主动 failover 能力、动静 IO 限速、监控告警、多种存储供应能力等高级性能。 接下来,Carina 将持续对开源社区给予更多的投入与反对,专一于提供高性能、免运维的本地存储服务。

April 19, 2022 · 1 min · jiezi

关于cncf:应用运行时-Layotto-进入-CNCF-云原生全景图

2022 年 2 月 10 日, CNCF 公布了最新版本的 Landscape。 Layotto 正式退出 CNCF 云原生全景图! 分类在 Serverless framework 板块下 详情见 :https://l.cncf.io/serverless 意味着 Layotto 正式成为了CNCF 认可的构建云原生最佳实际中的一环。 CNCF 简介  云原生计算基金会(CNCF, Cloud Native Computing Foundation)致力于云原生技术的遍及和可继续倒退。 CNCF Landscape 用意从云原生的层次结构,以及不同的性能组成上,让用户理解云原生体系的全貌。同时,也受到宽广开发者和使用者对该项目标关注和器重。 Layotto 简介  Layotto(/let/) 是一款应用 Golang 开发的利用运行时, 旨在帮忙开发人员疾速构建云原生利用,帮忙利用和基础设施解耦。 它为利用提供了各种分布式能力,比方状态治理、配置管理、事件公布订阅等能力,以简化利用的开发。 更多对于 Layotto 的内容能够查看: 云原生运行时的下一个五年 MOSN 子项目 Layotto:开启服务网格+利用运行时新篇章 Layotto Star 一下✨:https://github.com/mosn/layotto 新的一年 Layotto 除了持续优化 service mesh 和 multi-runtime 方面的性能外,也会投入精力融入开源 serverless 生态。 接下来会和大家分享下 2021 年 Layotto 的落地总结,以及新一年的 roadmap,欢送关注~  Let's have fun together!  想要初步接触 Layotto 的技术同学,能够从咱们的技术工作动手,欢送大家一起来玩。 Layotto - Easy 为 actuator 模块增加单元测试 ...

February 18, 2022 · 1 min · jiezi

关于cncf:OpenYurt-联手-eKuiper解决-IoT-场景下边缘流数据处理难题

作者 | OpenYurt 社区 云计算的呈现促使物联网实现爆炸式增长。在设施规模和业务复杂度一直攀升的趋势之下,边缘计算因其可能将计算能力更凑近网络边缘和设施,从而带来云性能老本的升高,也在这波浪潮之下失去疾速倒退。 诚然,物联网边缘计算尚处倒退初期,有许多挑战须要被解决。比方在大量软件及通信协议极为简单的设施异构环境下,须要具备疾速解决业务数据,并对异常情况作出疾速响应的能力;另外,在大多数状况下,出于平安或其余思考,边缘节点在物理上无奈从云节点间接拜访,使部署变得艰难,也无奈实现云到边缘的治理。这些问题都使业务的连续性、稳定性和可用性蒙受威逼。 当初,企业和开发者通过开源社区就可能找到应答以上问题的解决方案。近日,OpenYurt 与开源我的项目 eKuiper 正式达成单干,实现了集成对接:从 v0.4.0 版本开始,OpenYurt 将正式反对部署和治理 eKuiper ,单方将独特帮忙开发者轻松、高效地解决物联网边缘计算场景下流式数据处理和运维挑战。 eKuiper:轻量级 IoT 数据分析和流解决开源软件 物联网边缘计算很多场景下须要流式数据处理能力。所谓流数据是指一组程序、大量、疾速、间断达到的数据序列。个别状况下,流数据可被视为一个随工夫连续而有限增长的动态数据汇合,它能够帮忙用户实时理解零碎设施的状态,并对异常情况做出疾速响应。 在边缘端,计算资源(CPU,内存等)不像在云端个别丰盛,因而传统的流式数据处理框架相似于 Apache Spark 或者 Apache Flink 等,因为其安装包过大,或者部署构造与过程过于简单、运行时的高耗费等起因,并不适宜于在这些资源受限的边缘设施(工控机、网关,或者配置不高的 X86 或者 ARM 服务器等设施)上运行。而 eKuiper 就是为了解决在物联网边缘设施上的这些问题而设计开发。 eKuiper 的前身是由开源物联网数据基础设施软件供应商 EMQ 于 2019 年正式开源的 Kuiper 我的项目。2021 年 6 月,Kuiper 我的项目退出 LF Edge 基金会并更名为 eKuiper,开始作为独立的我的项目经营。eKuiper 的实质是一个轻量级物联网数据分析和流处理软件,能够运行在各类资源受限的边缘设施上,心愿使边缘端的流式数据处理领有如 Spark 与 Flink 的能力。 如下图所示,eKuiper 整体架构大抵分为三局部: 左侧为 Sources,代表数据起源的地位,数据起源可能是 OpenYurt 里部署边缘端的 MQTT Broker,也可能是音讯队列、文件和数据库等;右侧为 Sinks,代表数据处理实现后所要存储的地位,也就是指标零碎,指标能够是 MQTT,能够将其存到文件、数据库外面,也能够调用 HTTP 服务;两头局部为 eKuiper 的运行时,最上层为数据业务逻辑解决,这个层面提供了 SQL 与规定解析器,SQL 处理器进行解决后并将其转化成 SQL 执行打算;上面层为流运行时和 SQL 运行时, 运行最终执行进去的执行打算;最底层为存储,存储在运行过程中须要长久化的一些信息。在 eKuiper 中,用户可通过治理仪表板来治理一个或多个 eKuiper 实例。通常,这些仪表板部署在云节点中,用于治理跨多个边缘节点的 eKuiper 实例。正如前文所述,因为大多数状况下边缘节点在物理上无奈从云节点拜访, 使得部署变得艰难,无奈进行高效的 eKuiper 云边治理。 ...

August 13, 2021 · 2 min · jiezi

关于cncf:KubeVela-成为-CNCF-沙箱项目让云端应用交付更加简单

简介: KubeVela 就是这样一个面向用户的下层平台我的项目。对于业务开发者来说,KubeVela 简略、易用,它能够让开发者以极低的心智累赘和上手老本在 Kubernetes 上定义与部署利用... 但更重要的是,对于平台团队来说,KubeVela 可不是一个简略的 PaaS 或者 Serverless,它是一个可能以 Kubernetes 原生的形式进行任意扩大的 PaaS 内核,平台工程师能够基于它构建出任意的垂直业务零碎。作者:KubeVela 社区 2021 年 6 月 22 日,在云原生计算基金会(CNCF)的 TOC 例会上投票决定通过,KubeVela 正式成为 CNCF 官网沙箱我的项目。通明、凋谢、开源中立的 KubeVela,将来将继续致力于打造对立、规范、跨云的利用治理和交付体验。 “KubeVela 就是这样一个面向用户的下层平台我的项目。对于业务开发者来说,KubeVela 简略、易用,它能够让开发者以极低的心智累赘和上手老本在 Kubernetes 上定义与部署利用... 但更重要的是,对于平台团队来说,KubeVela 可不是一个简略的 PaaS 或者 Serverless,它是一个可能以 Kubernetes 原生的形式进行任意扩大的 PaaS 内核,平台工程师能够基于它构建出任意的垂直业务零碎。” 张磊,CNCF TOC Member KubeVela 我的项目地址:ttps://github.com/oam-dev/kubevela 我的项目介绍云原生技术正在以 Kubernetes 作为通用形象层,朝着跨云谋求统一的利用交付迈进。Kubernetes 尽管在底层根底构造细节形象方面表现出色,但带来了额定的复杂性。基于 Kubernetes 打造的各类 PaaS 林立却又互不相通,导致服务利用开发的平台团队,没有一个适合的框架来构建用户敌对且高度可扩大的形象。与此同时,混合云、多云、分布式云这些日益简单的业务场景中,利用交付也在逐步变得碎片化。 用 Go 语言开发的利用交付引擎 KubeVela,能帮咱们克服以上所有难题。作为 OAM(Open Application Model)在 Kubernetes 上的实现,KubeVela 我的项目从 oam-kubernetes-runtime 演进至今,发展势头十分迅猛,不仅间断登上 GitHub Go 语言趋势榜首和 HackerNews 首页,更是迅速播种了包含 MasterCard、Springer Nature、第四范式、SILOT、Upbound 等来自世界各地、不同行业的终端用户,甚至还呈现了像 Oracle Cloud、Napptive 等基于它构建的商业化产品。就在 2021 年 3 月底,KubeVela 社区发表蕴含所有稳定版 API 的 v1.0版本 公布,正式开始向企业级生产可用迈进。 ...

July 12, 2021 · 2 min · jiezi

关于cncf:使用Lens管理多云Kubernetes

你填了吗? 10人将获赠CNCF商店$100美元礼券! 来参加2020年CNCF中国云原生考察 问卷链接(https://www.wjx.cn/jq/9714648...) 客座文章作者:Nimal Kunnath,Nutanix系统可靠性工程师 大量报告一直表明,明天的企业将混合和多云作为其首选的IT基础设施部署模式。依据IDG的一项考察,超过一半(55%)的组织目前应用多个私有云,21%的组织说他们应用三个或更多的私有云。 随着开发人员逐步适应构建和公布容器,Kubernetes显然已成为容器编排的首选。组织为什么要跨多个云供应商部署Kubernetes有很多起因: 云暴发 在多云基础设施中,“暴发(bursting)”波及应用一个云的资源来补充另一个云的资源。当应用公有云的组织达到100%的资源容量时,溢出的流量会被转移到私有云,防止业务中断。 劫难复原与备份 在实践中,你不心愿一个云提供商成为单点故障。通过在云上扩散复原资源,你能够取得比繁多云基础设施更大的弹性和可用性。 在所有这些基础设施就绪之后,IT经营团队治理多个集群十分具备挑战性。呈现了以下挑战: 要拜访集群,须要保护大量的kubectl和kubeconfig文件。对于不同的集群/我的项目,必须在它们之间进行上下文切换,而且跨云提供商拜访办法的不同减少了复杂性,这可能会很麻烦。尽管开发人员通常专一于编写代码,但当初他们学习应用程序的操作方面也并不常见。尽管Kubernetes旨在帮忙他们更快地公布和更新应用程序,但它自身就很简单。他们心愿可能放慢概念的学习速度,放慢学习曲线,这样他们就能够专一于最重要的货色:利用程序代码。在Kubernetes中进行故障排除并不是一项简略的工作。在调试过程中,管理员必须从pod日志和事件、pod状态等中辨认谬误。新管理员很容易破费大量贵重的工夫来找出正确的命令和日志,以查看对业务的不利影响。Kubernetes裸露了一个规范的仪表板,它提供了在集群上运行的应用程序的概览,但这是在单个集群级别上实现的。心愿有一个对立的治理解决方案来解决上述挑战。明天咱们将聚焦于开源解决方案Lens。 Lens是一个独立的应用程序,能够在MacOS、Windows和Linux上应用,这意味着你不须要在Kubernetes节点自身装置任何包。通过导入kubeconfig文件,单个IDE能够用于治理任何平台上的所有集群。让咱们一起来看看。 装置Lens 浏览Lens网页,在你喜爱的操作系统下载并装置。关上应用程序后,立刻点击“+”按钮增加集群。你能够导入kubeconfig文件或粘贴它,瞧!让魔法开始吧。 我曾经部署了两个集群,一个应用Karbon(Nutanix的Kubernetes治理解决方案)在Nutanix公有云上,另一个应用Azure Kubernetes服务。为AKS集群导入kubeconfig文件如下所示。 在集群概览中,你能够通过单个窗格玻璃看到所有可用的集群资源。你能够查看所有工作负载、它们的以后状态、任何相干事件,甚至能够通过命名空间对它们进行过滤。点击任何资源都会拉出它的所有细节-基本上,就像你从以下输入中看到的一样: kubectl get <daemonset|pod|deployment> -n <namespace> <name> -o yaml 部署应用程序 在这里,我增加了Karbon集群,以及Lens。让咱们持续并将Cassandra StatefulSet部署到这个集群上。 上面是我应用的YAML: apiVersion: v1kind: Servicemetadata: labels: app: cassandra name: cassandraspec: clusterIP: None ports: - port: 9042 selector: app: cassandra---apiVersion: apps/v1kind: StatefulSetmetadata: name: cassandra labels: app: cassandraspec: serviceName: cassandra replicas: 3 selector: matchLabels: app: cassandra template: metadata: labels: app: cassandra spec: terminationGracePeriodSeconds: 1800 containers: - name: cassandra image: gcr.io/google-samples/cassandra:v13 imagePullPolicy: Always ports: - containerPort: 7000 name: intra-node - containerPort: 7001 name: tls-intra-node - containerPort: 7199 name: jmx - containerPort: 9042 name: cql resources: limits: cpu: "500m" memory: 1Gi requests: cpu: "500m" memory: 1Gi securityContext: capabilities: add: - IPC_LOCK lifecycle: preStop: exec: command: - /bin/sh - -c - nodetool drain env: - name: MAX_HEAP_SIZE value: 512M - name: HEAP_NEWSIZE value: 100M - name: CASSANDRA_SEEDS value: "cassandra-0.cassandra.default.svc.cluster.local" - name: CASSANDRA_CLUSTER_NAME value: "K8Demo" - name: CASSANDRA_DC value: "DC1-K8Demo" - name: CASSANDRA_RACK value: "Rack1-K8Demo" - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP readinessProbe: exec: command: - /bin/bash - -c - /ready-probe.sh initialDelaySeconds: 15 timeoutSeconds: 5 volumeMounts: - name: cassandra-data mountPath: /cassandra_data volumeClaimTemplates: - metadata: name: cassandra-data spec: accessModes: [ "ReadWriteOnce" ] storageClassName: default-storageclass resources: requests: storage: 1Gi在利用之后,你能够看到通过Lens创立的StatefulSet、服务、pod和其余资源。 ...

January 7, 2021 · 2 min · jiezi

关于cncf:使用Kyverno自动标记Kubernetes资源

你填了吗? 10人将获赠CNCF商店$100美元礼券! 来参加2020年CNCF中国云原生考察 问卷链接(https://www.wjx.cn/jq/9714648...) 客座文章作者:Nirmata业务倒退和客户胜利副总裁Anubhav Sharma,最后在Nirmata的博客上发表。 介绍 随着Kubernetes曾经成为企业转向云原生的根本构建块,过来几年曾经呈现了许多简化集群创立过程的解决方案。然而,Kubernetes周边的Day-2经营依然是一个简单的过程,会减缓采纳速度,减少经营老本。Kubernetes的复杂性和技能差距依然是妨碍企业采纳Kubernetes的最大因素。 许多Day-2操作用例包含要求地方平台团队尽可能无效地向开发人员交付平安和兼容的环境,并事后配置必要的服务和最佳实际。这类用例的一些例子包含应用Kubernetes最佳实际(如资源配额、网络策略和pod安全性)来配置环境。这须要工具在环境创立时进行评估,而后依照地方平台团队定义的规范对环境进行配置。 Kyverno:一个针对K8s的灵便的操作工具 Kubernetes提供了弱小的结构,如准入管制webhook,能够用于验证和更改资源。Nirmata的Kyverno是专门设计用来应用申明式范式解决这些类型的用例的。Kyverno是一个为Kubernetes设计的开源策略引擎,它为用户提供了相熟的构造来编写定制规定,并可依据须要轻松实现验证、批改和生成新资源。 大规模地治理Kubernetes须要遵循最佳实际和跨配置利用标准化。其中一种模式是应用Kubernetes标签。在Kubernetes中,每个资源都能够有一个或多个标签,Kubernetes使应用标签查找和治理资源变得很容易。 Day-2操作的一个十分常见的用例是跨命名空间和pod治理标签,以便其余Kubernetes控制器和操作人员能够轻松地实现证书更新、自助日志/监控、备份等用例。 主动标记命名空间 上面是一个应用Kyverno在Kubernetes集群中创立命名空间时如何实现命名空间标记的示例。 在集群中装置Kyverno: kubectl create -f https://github.com/kyverno/kyverno/raw/master/definitions/install.yaml这里有具体的装置阐明。 上面是一个向命名空间增加标签的示例Kyverno策略: apiVersion: kyverno.io/v1kind: ClusterPolicymetadata: name: add-labelsspec: background: false rules: - name: add-ns-label match: resources: kinds: - Namespace exclude: clusterroles: ["cluster-admin"] mutate: patchStrategicMerge: metadata: labels: kyverno/user: "{{ request.userInfo.username }}" +(kyverno/network): "default"该策略插入一个标签'kyverno/user',其中蕴含收回API申请以创立命名空间的用户的值。该策略还会插入一个标签'kyverno/network',但只有在用户尚未指定标签时才会如此。这个简略的策略演示了Kyverno中的一些弱小性能,如变量替换和条件锚。 在集群中配置了策略之后,创立一个新的命名空间,并主动验证标签曾经增加到该命名空间。 创立一个新的命名空间: kubectl create ns test查看命名空间: kubectl get ns test -o yaml这应该显示相似于: apiVersion: v1kind: Namespacemetadata: labels: kyverno/network: default kyverno/user: docker-for-desktop当初,如果你想确保用户不能更新特定的标签,该怎么办呢? ...

January 5, 2021 · 1 min · jiezi

关于cncf:KubeVirt深度剖析系列之virtcontroller源码分析

2020年CNCF中国云原生考察邀你一起来参加! 问卷链接(https://www.wjx.cn/jq/9714648...) 廖旋威:目前就任于新华三云计算,次要从事云原生行业,对k8s和拟化相干有深入研究,善于Go/Java语言。 曾小波:一个十年一线架构研发工作的技术人员,目前在新华云计算从事云原生产品及社区相干工作。 kubevirt 简介kubevirt 是一个围绕kubernetes构建的虚拟机治理架构,次要用于技术起因无奈将虚拟机利用迁徙到容器平台的场景,它提供了欠缺的虚拟机生命周期治理、在kubernetes上虚拟机调度等能力。。新华三云原生团队在kubevirt我的项目成立初期就进行了钻研,并对kubevirt进行了革新实际,同时鉴于目前kubevirt深度剖析材料较为不足,因而咱们决定对kubevirt源码进行分析,以飨读者。本文是系列的第一篇:virt-controller源码剖析。 kubevirt 部署架构介绍由virt-controller,virt-api,virt-handler,virt-launcher四大组件组成,其核心思想是在通过kubernetes原生来治理虚拟机,为开发团队解决只能应用虚拟机的应用程序提供了可能。为了让读者可能更好了解virt-controller,咱们首先介绍一下kubevirt的部署架构,如图: 从架构图中能够看出: virt-controller,virt-api:集群层面上全局惟一,次要作用是通过与k8s api server 通信实现vmi资源创立、virt-lanucher pod 的创立及状态更新等。virt-handler:节点层面上惟一,负责与k8s api server、virt-lanucher通信来实现虚拟机的生命周期治理。virt-launcher:依据vmi 定义生成虚拟机模板,通过与libvirt api 通信提供虚拟机生命周期治理。上面咱们对virt-controller的源码进行剖析,加深大家对实现细节的了解。 kubevirt 资源类型VirtualMachineInstance简称VMI,能够简略与理论虚拟机一一对应。会创立一个蕴含virt-launcher的Pod,该Pod外面通过libvirt创立实在虚拟机。VMI的Spec字段指定虚拟机运行参数,Status字段记录虚拟机运行状况。VirtualMachine简称VM,能够治理和操作VMI对象。一个VM对象只能治理一个VMI对象VirtualMachineInstanceReplicaSet简称replicaset或rs,一个replicaset能够治理多个VMI对象,即一个ReplicaSet能够创立、批改、删除多个虚拟机。 VirtualMachineInstanceMigration简称Migration,在Migration对象的Spec字段外面指定要迁徙的VMI,而后kubevirt主动对该VMI实现迁徙。 virt-controller 源码剖析启动流程入口在kubevirt/cmd/virt-controller/virt-controller.go func main() { watch.Execute()}间接调用kubevirt/pkg/virt-controller/watch/application.go中的Execute函数启动virt-controller。上面次要剖析Execute函数中的内容。 获取leaderElectionConfiguration获取KubevirtClient获取informerFactory,并实例化一系列具体资源类型的Informer,例如crdInformer、kubeVirtInformer、vmiInformer、kvPodInformer、nodeInformer、vmInformer、migrationInformer等初始化一系列controller,包含vmiController、nodeController、migrationController、vmController、evacuationController、snapshotController、restoreController、replicaSetController、disruptionBudgetController通过leaderElector来启动virt-controller,并在leaderElector中启动各个controller的Run函数。VMController剖析代码位于kubevirt/pkg/virt-controller/watch/vm.go文件中。 监听VM对象、VMI对象、DataVolume对象并增加对应的EventHandler。收到Event事件之后退出到workQueue。 VM对象的Event事件间接退出workQueue。VMI对象的Event事件先判断是否由VM对象所管制,如果是则将该VM对象退出workQueue,否则找到匹配的VM,将匹配的VM退出到workQueue,尝试收养孤儿的VMI对象。DataVolume对象的Event事件先判断是否由VM对象所管制,如果是则将该VM对象退出workQueue,否则不解决。通过Run()->runWorker()->Execute()->execute(),从workQueue中取出对象的key,而后在execute中解决。execute()函数的解决逻辑 依据key,从Informer的本地缓存中获取VM对象。创立VirtualMachineControllerRefManager。依据key,从Informer的本地缓存中获取VMI对象如果获取VMI对象胜利,则VirtualMachineControllerRefManager尝试收养或遗弃VMI。依据Spec.DataVolumeTemplates,从Informer的本地缓存中获取dataVolumes。查看dataVolumes是否曾经ready,若曾经ready则调用startStop() RunStrategy==Always:虚拟机实例VMI应该总是存在,如果虚拟机实例VMI crash,会创立一个新的虚拟机。等同于spec.running:true。RunStrategy==RerunOnFailure:如果虚拟机实例VMI运行失败,会创立一个新的虚拟机。如果是由客户端被动胜利敞开,则不会再从新创立。RunStrategy==Manual:虚拟机实例VMI运行状况通过start/stop/restart手工来管制。RunStrategy==Halted:虚拟机实例VMI应该总是挂起。等同于spec.running:false。更新VMStatus 批改vm.Status.Created,vm.Status.Ready批改vm.Status.StateChangeRequests批改vm.Status.Conditions更新VMStatusVMIController剖析代码位于kubevirt/pkg/virt-controller/watch/vmi.go文件中。 监听VMI对象、Pod对象、DataVolume对象并增加对应的EventHandler。收到Event事件之后退出到workQueue。 VMI对象的Event事件间接退出workQueue。Pod对象的Event事件先判断是否由VM对象所管制,如果是则将该VM对象退出workQueue,否则不解决。DataVolume对象的Event事件,依据DataVolume的Namespace和Name获取匹配的vmis,而后将vmis对象顺次退出到workQueue。通过Run()->runWorker()->Execute()->execute(),从workQueue中取出对象的key,而后在execute中解决。execute()函数的解决逻辑 依据key,从Informer的本地缓存中获取VM对象。获取和以后vmi对象匹配的Pod。依据vmi.Spec.Volumes,获取匹配的DataVolumes对象。同步sync,若Pod不存在,则创立lanucher所在的Pod。更新vmi对象的status。MigrationController剖析代码位于kubevirt/pkg/virt-controller/watch/migration.go文件中。 监听Migration对象、VMI对象、Pod对象并增加对应的EventHandler。收到Event事件之后退出到workQueue。 VMI对象的Event事件间接退出workQueue。Pod对象的Event事件,依据Pod的Annotation中的migrationJonName来找到对应的migration对象,而后退出workQueue。VMI对象的Event事件,依据vmi的Namespace和Name获取匹配的Migration对象,而后退出到workQueue。通过Run()->runWorker()->Execute()->execute(),从workQueue中取出对象的key,而后在execute中解决。execute()函数的解决逻辑 依据key,从Informer的本地缓存中获取Migration对象。依据Migration.namespace和Migration对象.Spec.VMIName来获取VMI对象。获取迁徙指标Pod。同步sync。更新Migration对象的status,Migration.Status.Phase状态转换为:![Image](https://mmbiz.qpic.cn/mmbiz_png/GpkQxibjhkJwJqTYd1jNuyHSNgCkX8WpeRSCLglMQGDomqmiajjPCUVAslUmkW4hVic1L4CH6XswjTBPVjdticKgXA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1)ReplicaSetController剖析代码位于kubevirt/pkg/virt-controller/watch/replicaset.go文件中。 监听replicaSet对象、VMI对象并增加对应的EventHandler。收到Event事件之后退出到workQueue。 VMI对象的Event事件间接退出workQueue。。VMI对象的Event事件,先判断是否由replicaSet对象管制,如果是则将该replicaSet退出到workQueue,否则找到与该VMI对象匹配的replicaSets,而后将replicaSets顺次退出workQueue,尝试将该VMI对象收养。通过Run()->runWorker()->Execute()->execute(),从workQueue中取出对象的key,而后在execute中解决。execute()函数的解决逻辑 依据key,从Informer的本地缓存中获取Migration对象。依据namespaces获取vmis。依据获取replicaSet对象,创立VMControllerRefManager,而后尝试收养或遗弃vmis。将vmis分成两组finishedVmis和activeVmis。依据Spec.Replicas以及以后replicaset治理的activeVmis,对vmis进行扩容或者缩容。更新replicaSet的Status。总结本文章基于kubevirt 0.35版本,重点解说了kubevirt架构及对virt-controller源码设计进行剖析。因为篇幅无限,本文次要帮忙读者理清virt-controller的次要设计思路,起到穿针引线成果,下一篇咱们将对handler组件进行剖析。 点击达到KubeVirt网站。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

December 24, 2020 · 1 min · jiezi

关于cncf:使用Argo-CD和GitOps解决配置漂移问题

2020年CNCF中国云原生考察邀你一起来参加! 问卷链接(https://www.wjx.cn/jq/9714648...) 作者:Kostis Kapelonis Argo CD(Argo我的项目的一部分)是一个为Kubernetes而设的部署解决方案,遵循GitOps模式。 应用Argo CD部署到Kubernetes 在最根本的场景中,Argo CD应用Kubernetes清单继续监督Git仓库(也反对Helm和Kustomize)并监听提交事件。 当产生提交(通常是更新镜像工件版本的提交)时,Argo CD会启动一个“同步(synchronization)”过程,该过程负责使集群配置处于与Git中形容的雷同的状态。 当同步过程实现时,咱们晓得应用程序配置与Git清单完全相同。 Argo CD的部署过程体现了GitOps背地的核心理念: 所有应用程序配置都存储在Git中(通常在与源代码不同的存储库中)部署以一种“拉”形式进行,即集群从Git获取清单(而不是将更新“推”到集群的传统解决方案)。部署是两种状态之间的协调过程(Git中形容的状态与集群中部署的状态)只管同步过程对于执行应用程序的初始部署是至关重要的,但Argo CD真正的劣势之一是在部署实现后可能继续监控两个状态(集群和Git)。这种继续的监督对于解决配置漂移十分重要,配置漂移在具备大量部署指标的组织中是一个十分常见的问题。 不同Kubernetes集群之间的配置漂移 配置漂移是一个即便在传统虚拟机中也存在的问题,而且早在Kubernetes呈现之前,它就始终困扰着生产部署。当CI/CD平台执行到多个指标的部署并失败时,问题就会显现出来,因为一组本应类似的机器实际上配置不同。 在一些组织中,开发人员在应用程序部署到生产环境之前应用“登台(staging)”环境来测试其应用程序。现实状况下,登台环境应该与生产环境的配置相匹配,这样开发人员就能够确信他们在登台中执行的任何测试都将与生产环境严密匹配。 特地是在Kubernetes集群中,团队常常应用特地的命令(例如,通过kubectl)在一个齐全不在CI/CD过程之外的集群上执行更改。 这些特地的更改是应用程序部署的一个次要问题。配置上的差别是导致部署失败的最常见起因之一。在登台环境中胜利通过所有测试的应用程序在生产中会呈现中断状态,因为没有提供所需的设置或采纳预期的格局。 另一个由配置漂移引起的暗藏问题是,逐步失落了在机器/节点上部署了什么以及最初一次更改的确切工夫的常识。Argo CD解决了这个问题,它将Git作为以后部署和过来所有部署的实在起源。 在部署失败后,运营者和开发人员试图理解事变的起因,他们问的第一个问题是“这个集群最初产生的变动是什么”。如果集群在批准的CI/CD过程之外产生了未管制的更改,那么这个问题很难答复。 Argo CD如何检测配置漂移问题 Argo CD采纳了一种齐全不同的部署办法(“pull from Git”范式)。因为所有部署都能够追溯到Git提交,所以Git提交历史记录也是集群部署历史记录。 开发人员能够应用他们喜爱的Git工具来答复诸如“上周四集群上部署了什么?”或者“这周周一到周四之间产生了什么变动?” 让咱们假如团队中的一个人齐全绕过了Argo CD,并应用kubectl间接对集群进行手动更改。其余CI/CD解决方案将齐全疏忽此更改,这为配置漂移问题提供了环境。 Argo CD会了解集群上产生了变动,这两种状态(集群配置和Git清单)不再雷同。部署将立刻标记为“不同步(out-of-sync)”。 Argo CD也将开掘得更深刻,甚至提供了一个很好的差别概述,扭转了什么: 在下面的例子中,Argo CD检测到集群和Git之间服务的端口配置不再雷同。 当你检测到这样的差别,你能够手动使应用程序处于与Git雷同的状态(再次执行同步过程),或者批示Argo CD在检测到配置更改时主动进行本身的同步。 这意味着Argo CD配置的漂移(至多对Kubernetes应用程序而言)齐全打消了,特地是在启用了主动同步行为的状况下。 应用Argo CD的团队能够释怀地进行部署,因为他们晓得集群处于它应该处于的状态(该状态在Git清单中也有残缺的形容)。配置漂移不再是一个问题,放弃登台和生产过程尽可能靠近是一个非常简单的过程。 Argo与Devops平台的联合 除了Argo CD的次要我的项目,你可能也会发现Argo Rollouts我的项目很乏味。Argo Rollouts是Argo的另一个我的项目,用于对Kubernetes进行渐进式(蓝/绿/灰度)部署。 Argo CD和Argo Rollouts对于解决应用程序部署来说是十分好的,然而它们须要与一个残缺的自动化解决方案相结合,这个解决方案也将处理软件生命周期的所有其余方面,比方应用程序构建、单元测试、机密治理和拉取申请解决等。 Argo CD非常适合理论部署,但它假如工件曾经由另一个解决方案创立。这就是为什么咱们始终致力将Codefresh和Argo集成在一起,以笼罩整个软件生命周期,甚至笼罩主动将变更推送到Argo监控manifest的Git仓库的场景(即执行主动提交,从而实际继续部署)。 理解更多信息,请拜访Argo的主网站。 Kostis Kapelonis是Codefresh的开发者倡导者,Codefresh是一个为Kubernetes和容器构建的继续交付平台。Kostis以前是一名软件工程师,领有多年利用容器、构建CI/CD流水线和开发Java应用程序的教训。他住在希腊,喜爱滑旱冰。 ...

December 23, 2020 · 1 min · jiezi

关于cncf:Kyverno|为Kubernetes设计的策略引擎

客座文章作者:Jim Bugwadia,Nirmata创始人和首席执行官。最后在Nirmata的博客上发表。 图片由Pixabay的Dominic Wunderlich拍摄 Forrester在其最近的企业容器采纳报告中发现,86%的IT领导者优先思考减少容器的应用,以进步开发人员的敏捷性,改善IT经营团队和开发人员之间的合作。然而,报告也指出: 应用容器治理平台的公司在听从性(满足行业法规和施行政策)和可移植性(跨多个云环境构建和部署)方面遇到了难题。 让咱们摸索为什么Kubernetes配置管理能够被认为是简单的,而后探讨一个Kubernetes原生解决方案来解决这种复杂性。 容器独立于应用程序的编程语言或应用程序的架构,为应用程序提供通用的打包和运行时,从而简化了应用程序的治理。Kubernetes已迅速成为治理容器的事实上的规范,并在公共和公有云环境中失去宽泛采纳。 Kubernetes的一个要害准则是申明式配置管理。在编程实践中,有两种类型的编程语言:命令式(imperative)和申明式(declarative)。命令式语言是程序员批示零碎下一步要做什么的语言,而程序就是一系列这样的指令。而在申明式编程中,程序员指定冀望的后果,零碎决定实现冀望后果的最佳形式。 相似地,零碎接口和配置基础设施和零碎能够遵循这两种格调。在命令式接口中,操作员通知零碎如何执行一项工作。通过一个申明式接口,操作员通知零碎须要做什么,而后零碎决定执行必要工作的最佳形式。 Kubernetes是申明式的。开发人员和操作员指定所需的状态,Kubernetes控制器将尝试协调以后状态和所需状态。 尽管Kubernetes的申明式个性使其性能十分弱小,并提供了自我修复性能,但它也极大地减少了必须治理的配置数量。为了正确地申明和管制状态,Kubernetes提供了大量配置--随着新性能的增加,这些配置还会一直减少。另一个挑战是确定谁负责为安全性、最佳实际和标准化配置正确的设置。 此挑战的解决方案是应用策略来验证配置的最佳实际和安全性听从性,并在须要时主动批改和生成附加配置。 Kyverno(希腊语中的意思是“治理”)是一个Kubernetes策略引擎,它作为一个准入控制器运行,能够依据可定制的策略验证、批改和生成任何配置数据。当其余通用策略解决方案被革新到Kubernetes时,Nirmata团队为Kubernetes设计了Kyverno。和Kubernetes一样,Kyverno采纳了申明式治理范式。Kyverno策略只是Kubernetes资源,不须要学习一种新的语言。Kyverno能够很好地与kubectl、Kustomize和Git等Kubernetes现有的开发工具配合应用。 如果你正在操作Kubernetes环境,请查看Kyverno(https://kyverno.io),以帮忙解决Kubernetes复杂性,并轻松地跨集群和工作负载执行安全性和最佳实际策略。 Forrester从他们的钻研中得出结论,企业正在寻找“平安、牢靠、易用”的容器治理解决方案。咱们置信,Nirmata平台提供了一个云治理立体,并与Kyverno集成,是跨任何公共或公有云治理Kubernetes集群和工作负载的最灵便、易用和平安的形式。 点击浏览网站原文。 期待你来填:2020年CNCF中国云原生问卷 问卷链接(https://www.wjx.cn/jq/9714648...) CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

December 17, 2020 · 1 min · jiezi

关于cncf:云原生控制平面项目Crossplane发布10版本|定义你自己的云平台

期待你来填:2020年CNCF中国云原生问卷 问卷链接(https://www.wjx.cn/jq/9714648...) 作者:Phil Prasek Crossplane当初曾经正式公布了1.0版本,可能从Kubernetes API治理大量的云服务,并将它们组合成配置蓝图来定义你本人的云平台--所有这些都不须要编写代码。对于Crossplane社区来说,这是令人惊奇的一年,因为咱们独特致力于一个以API为核心的管制立体的将来! 咱们很快乐地发表Crossplane的v1.0版本,包含最终的v1 API、首领选举、所有二进制文件的Prometheus度量、加强的平台配置反对等等! 明天咱们在Crossplane社区日庆贺了1.0版本的公布,包含Kelsey Hightower、Joe Beda、Brendan Burns、Bassam Tabbara、Brian Grant等等--就在这个月早些时候,Crossplane刚过2岁生日!如果你不能参加,请查看YouTube重播视频--很快就有! Crossplane是CNCF的一个我的项目--由Rook的创建者创建,往年早些时候,它与Kubernetes自身、Prometheus和Envoy一起成为了一个毕业的CNCF我的项目。该社区围绕Crossplane汇集起来,其成员来自AWS、微软、阿里云、RedHat、Equinix、IBM Cloud、埃森哲、VSHN、Akiris等,而IBM Cloud明天正式退出Crossplane社区,减少了对超过85种IBM Cloud服务的反对 当初能够应用Crossplane将服务整合到你本人的云API中! 领有超过1000万的下载量,3300多GitHub星星和1000多名Slack会员,当初是成为成长中的Crossplane社区一员的激动人心的时刻,咱们心愿看到有大量的奉献。社区成员曾经逐渐成为子项目的保护人,比方crossplane/provider-aws,它反对比去年多3倍的AWS云服务,而且还在进行中! 咱们对社区如何受害于Crossplane的共同努力,以及联结工作以使AWS ACK和Azure ASO代码生成管道适应以收回原生Crossplane资源,以及应用无状态Terraform提供程序来减速Long Tail的覆盖范围感到高兴--旨在所有云和云服务的100%Crossplane Provider覆盖率。 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

December 17, 2020 · 1 min · jiezi

关于cncf:高可用性虚拟机的运行策略

作者:Stu Gott 为什么我的虚拟机没有运行? KubeVirt的API有一个长期存在的困惑。这个问题最近又被提了几次。这种混同源于VM标准中的“Running”字段,语言是有意义的。从外表上看,“Running”就是“Running”,这很天然,对吧?好吧,没那么快下结论。 标准和状态 KubeVirt对象遵循Kubernetes常规,因为它们通常有Spec(标准)和Status(状态)节。该标准是用户可配置的,容许用户以申明的形式批示集群所需的状态。同时,状态局部不是用户可配置的,它反映了集群中事物的理论状态。简而言之,用户编辑标准,控制器编辑状态。 回到Running字段上。在这种状况下,Running字段在VM的标准中,换句话说,运行(Running)VM是用户的用意。它不能反映虚拟机的理论运行(Running)状态。 RunStrategy 同样令人困惑的是,下面的内容也有另一方面:“Running”并不总是用户想要的。如果用户登录到一个VM并在客户端敞开它,KubeVirt会渎职地从新生成它!当然,在高可用性用例中,这是完全正确的反馈,但在大多数状况下,这只是简略的混同。关机不是重新启动啊! 咱们决定同时解决这两个问题--通过摒弃“Running”字段。如前所述,咱们本能够抉择一个更好的名字作为开始。通过应用“RunStrategy”这个名称,最终用户应该更分明地晓得他们在申请状态,这当然是齐全独立于零碎理论提供的状态的。RunStrategy有助于解决命名术语的混同,但它碰巧也是一个枚举值。因为Running是一个布尔值,它只能为真或假。咱们当初可能创立更有意义的状态来适应不同的用例。 目前存在四种运行策略: Always:如果一个VM因为任何起因被进行,一个新的实例将被派生。RerunOnFailure:如果VM在谬误状态下完结执行,将会产生一个新的实例。这就解决了下面所列的第二个问题。如果用户手动进行VM,则不会生成新的实例。Manual:这正是它的意思。KubeVirt不会尝试启动或进行VM。为了扭转状态,用户必须从API调用start/stop/restart。在virtctl命令行客户端中也有不便的函数。Halted:如果VM正在运行,它将被进行,并且将放弃敞开状态。在KubeVirt VM镜像应用模式中给出了一个应用RerunOnFailure运行策略的示例。 高可用性 如果不提到高可用性,对运行策略的探讨就不残缺。毕竟,在RerunOnFailure和Always运行策略背地的含意是,VM应该始终可用。在大多数状况下,这是完全正确的,但有一个重要的场景须要留神:如果一个节点齐全失败,例如网络或电源失落。如果没有自动检测节点不再流动的办法,KubeVirt将不晓得VM曾经失败。在应用启用了MachineHealthCheck(MHC)的IPI(Installer Provisioned Infrastructure)装置的OpenShift集群上,能够检测失败节点并重新安排运行在那里的工作负载。 无关IPI和MHC的模式材料可在此找到: https://docs.openshift.com/co... 点击浏览网站原文。 期待你来填:2020年CNCF中国云原生问卷 问卷链接(https://www.wjx.cn/jq/9714648...) CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

December 15, 2020 · 1 min · jiezi

关于cncf:Kubernetes-120Kubernetes卷快照提升到GA

你填了吗?2020年CNCF中国云原生问卷 问卷链接(https://www.wjx.cn/jq/9714648...) 作者:Xing Yang, VMware & Xiangqian Yu, Google Kubernetes卷快照个性当初在Kubernetes v1.20中是GA。它在Kubernetes v1.12中以alpha的模式引入,随后在Kubernetes v1.13中进行了第二次alpha,并在Kubernetes 1.17中降级为beta版本。这篇博客总结了从beta版到GA版的变动。 什么是卷快照? 许多存储系统(如谷歌云长久磁盘、Amazon弹性块存储和许多外部存储系统)都提供了创立长久卷的“快照”的能力。快照示意卷的工夫点正本。快照能够用于从新生成新卷(用快照数据预填充),也能够用于将现有卷复原到以前的状态(由快照示意)。 为什么要向Kubernetes增加卷快照? Kubernetes的指标是在分布式应用程序和底层集群之间创立一个形象层,以便应用程序能够不晓得它们运行的集群的具体情况,并且应用程序部署不须要“特定于集群的”常识。 Kubernetes Storage SIG将快照操作辨认为许多有状态工作负载的要害性能。例如,数据库管理员可能心愿在启动数据库操作之前快照数据库的卷。 通过提供在Kubernetes中触发卷快照操作的规范办法,该个性容许Kubernetes用户以可移植的形式在任何Kubernetes环境中合并快照操作,而不论底层存储是什么。 此外,这些Kubernetes快照个性/原语(primitive)充当根本构建块,开释了为Kubernetes开发高级企业级存储管理个性(包含应用程序或集群级备份解决方案)的能力。 beta之后有什么新个性吗? 随着卷快照晋升到GA,该个性在规范Kubernetes部署中默认启用,并且不能敞开。 曾经对该个性进行了许多加强,以进步其品质并使其达到生产级。 卷快照API和客户端库被挪动到独自的Go模块。增加了快照验证webhook来对卷快照对象执行必要的验证。更多细节能够在卷快照验证Webhook Kubernetes加强倡议中找到。与验证webhook一起,卷快照控制器将开始标记曾经存在的有效快照对象。这容许用户辨认、删除任何有效对象,并纠正他们的工作流。一旦API切换到v1类型,这些有效对象将不能从零碎中删除。为了更好地理解快照个性是如何执行的,在卷快照控制器中增加了一组初始操作指标。还有更多(在GCP上运行的)端到端测试,能够在真正的Kubernetes集群中验证该个性。引入了压力测试(基于谷歌长久磁盘和hostPath CSI驱动程序)来测试零碎的健壮性。除了引入了更严格的验证之外,v1beta1和v1 Kubernetes卷快照API之间没有任何区别。在这个版本中(应用Kubernetes 1.20),提供了v1和v1beta1,而存储的API版本依然是v1beta1。将来的版本将把存储的版本切换到v1,并逐步删除对v1beta1的反对。 哪些CSI驱动程序反对卷快照? 快照只反对CSI驱动程序,不反对树内或FlexVolume驱动程序。确保集群上部署的CSI驱动程序实现了快照接口。无关更多信息,请参见Kubernetes GA的容器存储接口(CSI)。 目前有50多个CSI驱动程序反对卷快照个性。GCE长久磁盘CSI驱动程序曾经通过了从卷快照beta降级到GA的测试。对其余CSI驱动程序的GA级反对应该很快就能够应用了。 谁应用卷快照构建产品? 在本博客公布之时,以下来自Kubernetes数据保护工作组的参与者正在应用Kubernetes卷快照构建产品或曾经构建了产品。 Dell-EMC: PowerProtectDruvaKasten K10Pure Storage (Pure Service Orchestrator)Red Hat OpenShift Container StorageTrilioVault for KubernetesVelero plugin for CSI如何部署卷快照? 卷快照性能蕴含以下组件: Kubernetes Volume Snapshot CRDsVolume snapshot controllerSnapshot validation webhookCSI Driver along with CSI Snapshotter sidecar强烈建议Kubernetes发行商捆绑并部署卷快照控制器、CRD和验证webhook,作为Kubernetes集群治理过程的一部分(独立于任何CSI驱动程序)。 ...

December 11, 2020 · 2 min · jiezi

关于cncf:为什么Linkerd不使用Envoy

你填了吗?2020年CNCF中国云原生问卷 问卷链接(https://www.wjx.cn/jq/9714648...) 作者:William Morgan (Photo by Paul Felberbauer on Unsplash) 在这篇文章中,我将形容为什么Linkerd不是建设在Envoy之上。 这是一篇写起来有点奇怪的文章。毕竟,Linkerd没有应用过上百万个我的项目,而且这些决策都不值得在博客上发表。然而Linkerd没有特地应用Envoy这一事实曾经成为一个足够常见的探讨话题,因而它可能值得一个很好的解释。 我还要申明,这不是一篇“蹩脚的Envoy”的博客文章。Envoy是一个平凡的我的项目,显然是许多人的抉择,咱们对从事这项工作的优良人士只有尊敬。咱们每天都向Linkerd用户举荐应用了Envoy的入口控制器,像Ambassador,而在世界各地的生产零碎中,你能够发现Envoy和Linkerd并肩工作。 然而咱们没有抉择在Envoy之上建设Linkerd。相同,咱们构建了一个专用的“微代理”,简称为Linkerd2-proxy,它是针对服务网格边车用例进行优化的。在日益拥挤的同类服务网格我的项目畛域,Linkerd在这方面自成一家。但咱们为什么要走这条路呢? 对这个问题的残缺答复实质上是细致入微的和技术性的--确切地说,就是那些在风行的、博客驱动的云原生利用世界中容易被吞没的内容。所以在这篇文章中,我将尽我最大的致力以一种坦白和专一于工程的形式来论述起因。毕竟,Linkerd是由工程师创立的,也是为工程师服务的,如果说有一件事让我感到自豪的话,那就是咱们是在工程衡量的根底上做出决定的,而不是市场压力。 简而言之:Linkerd不应用Envoy,因为应用Envoy不容许咱们建设世界上最轻、最简略、最平安的Kubernetes服务网格。 作为最轻、最简略、最平安的Kubernetes服务网格是Linkerd对用户的承诺,这也使得Linkerd在服务网格中举世无双:它非常简单,更轻,更平安。而咱们可能做到这一点的起因是--你猜对了--因为咱们建设在Linkerd2-proxy而不是Envoy的根底上。不是因为Envoy不好,而是因为Linkerd2-proxy更好--至多对于作为Kubernetes边车代理的十分具体和无限的用例来说。 让咱们来看看起因。 Linkerd2-proxy是什么? 在深刻探讨细节之前,有必要进一步理解一下Linkerd2-proxy。 Linkerd2-proxy是专门为服务网格边车用例设计的“微代理”。Linkerd2-proxy构建在大概2020年的世界上最古代的网络编程环境之上,并驱动了许多需要:Rust异步网络生态系统,包含像Tokio、Tower和Hyper这样的库。就纯正的技术提高而言,Linkerd2-proxy是整个CNCF景观中最先进的技术之一。 像Envoy一样,Linkerd2-proxy是一个100%开源的Apache v2 CNCF我的项目,其特点是定期的第三方审计,一个沉闷的社区,以及在世界各地的要害工作零碎中的大规模生产应用。与Envoy不同的是,Linkerd2-proxy仅设计用于一种用例:在从Linkerd管制立体接管配置的同时,将申请从一个Kubernetes pod代理到另一个Kubernetes pod。与Envoy不同的是,Linkerd2-proxy被设计成一个实现细节:它不是面向用户的,它不能作为一个通用的构建块应用,它有一个无聊的名字。这意味着Linkerd2-proxy往往会被忽视,只管咱们最近在一些文章中对其进行了深入研究,并在路线图中给出了一些解释。 那么,为什么叫“微代理(micro-proxy)”呢?只管咱们要在词典中引入另一个术语,但“代理”这个词并不能齐全代表Linkerd2-proxy。代理相似于Envoy、NGINX、Apache或httproxy。这些我的项目能够做各种各样的事件(“将带有匹配此通配符的门路的HTTP申请发送到尔后端,同时重写这些头文件、压缩任何Javascript文件和旋转拜访日志”),并且它们有一个配置和调优外表来匹配。在生产环境中应用代理须要大量的操作投资:如果你正在运行Apache,那么你将在某个中央找到Apache专家。 然而Linkerd2-proxy是不同的。它被设计成一个实现细节,不须要专门的常识或专门的操作投资(只管Linkerd作为一个整体,当然,的确须要投资)。没有面向用户的YAML;相同,通过注入时设置的大量环境变量和运行时由Linkerd管制立体主动配置Linkerd2-proxy。咱们将Linkerd2-proxy的调优范畴放弃在最低限度,以便最终用户很少须要间接接触它。简而言之:Linkerd2-proxy被设计成暗藏在幕后,作为一个实现细节,并且仅仅工作。 简而言之:Linkerd2-proxy与Envoy、NGINX和Apache等代理有很大的不同,“proxy”这个词并不能很好地代表它。 复杂性 那么为什么咱们要建设Linkerd2-proxy而不是Envoy呢?一个次要起因是复杂性。 Envoy是一种灵便的、通用的代理,这也是它受欢迎的次要起因。你能够应用Envoy作为一个入口,作为一个进口,作为一个服务网格边车,以及在许多其余形式。然而这种灵活性带来了复杂性。 作为一个比拟,截至2020年11月,Envoy仓库的C++代码为172 KLOC,“复杂性得分”(以分支和循环掂量)为19k。相比之下,Linkerd2-proxy只有30 KLOC,复杂度得分为1.5k。换句话说:Linkerd2-proxy代码基比Envoy小5倍,通过这种办法,它的复杂性比Envoy小10倍 当然,这不是一个苹果对苹果的计算。它不捕捉仓库之外的库或依赖项;复杂性分数不能在语言之间严格地移植;等等。但它能够让你大抵理解这些我的项目的绝对规模:就外部而言,Linkerd2-proxy比Envoy要小几个数量级,也要简略几个数量级。 这种复杂性是Envoy的失败吗?不。Envoy有很多简单的代码因为它能够做很多简单的事件。然而,这种复杂性是构建专一于简略性(尤其是操作简略性)的我的项目的十分艰难的根底。 简而言之:Envoy是瑞士军刀。Linkerd2-proxy是一根针。 资源耗费 对于任何基于边车的服务网格,有一点是分明的:你将会有很多代理。 这意味着数据立体耗费的CPU和内存是运行服务网格老本的要害组成部分,尤其是在应用程序扩大时。 应用Linkerd2-proxy容许咱们严格控制Linkerd的资源耗费。例如,在咱们应用Kinvolk的开源基准测试工具对Linkerd和Istio进行的外部基准测试中,以每秒4000个申请的接入流量,咱们看到Linkerd2-proxy实例的内存始终在14mb到15mb之间,而Istio的Envoy的内存在135mb到175mb之间,是这个大小的10倍。相似地,Linkerd2-proxy在测试运行中的CPU应用始终为每个实例15ms (CPU毫秒),而Istio的Envoy在22ms到156ms之间--多50%到多10倍。 同样,这不是一个齐全偏心的比拟。这些是针对特定应用程序和特定配置的外部基准测试,毫无疑问,Istio的一些设计决策在这里表演了重要角色。但Istio是由世界一流的工程师建造的,要害是:如果Linkerd是在Envoy上建造的,咱们将不得不本人做出许多同样的设计决定。 简而言之:在实践中,在服务网格上下文中,Linkerd2-proxy应用的系统资源只是Envoy所应用的系统资源的一部分。 平安 最初一点兴许是最富哲理的一点:平安。数据立体的安全性对于任何服务网络都是一个微小的问题。例如,Linkerd在世界各地的生产中被用于解决异样敏感的数据,从衰弱信息到集体可辨认的细节再到金融交易。 咱们没有理由认为Envoy是不平安的。然而从某种程度上说,它是平安的(特地是在C++代码的170+ KLOC的状况下),它是平安的,它是通过让许多十分聪慧的工程师应用它、查看它、归档CVEs、修复bug和反复的手工和低廉的过程来实现的。这是软件平安的“传统过程”,而且至多在适当的时候是无效的。它也很低廉、艰难而且容易失败。C++代码的安全性是出了名的难,即便对最有教训的程序员也是如此。 更重要的是,这不是咱们心愿Linkerd所依赖的平安模型,也不是咱们所置信的零碎编程平安的将来。咱们抉择Rust作为Linkerd2-proxy是无意为之的:Rust的内存安全性使咱们能够释怀地在Linkerd2-proxy中编写平安代码,从而将咱们对人类发现问题的依赖最小化。当然,这并不是说Linkerd2-proxy不存在安全漏洞!相同,它将领有更少的;咱们须要少依赖本人低微的能力来防止它们;咱们将不再常常要求咱们的用户对他们的零碎进行要害降级,以放弃平安。 简而言之:Linkerd2-proxy的Rust根底让咱们对Linkerd的数据立体的安全性有了信念。 Linkerd能够应用Envoy吗? 简略性、资源耗费和安全性是咱们决定不采纳Envoy的驱动因素。然而,咱们置信代理的抉择最终是一个实现细节。尽管咱们在Linkerd2-proxy上投入了大量的资金,但咱们也会定期从新评估Envoy。我能够明确地说,如果对咱们的用户来说,这个折衷方案对Envoy无利,咱们将毫无疑问地采纳它。 不过,咱们对将来的服务网络采纳者的倡议很简略:疏忽这些乐音。你的工作不是“应用服务网络”或“采纳Envoy”,甚至“只应用CNCF技术”。你的工作是分明地理解你要解决的问题,而后抉择最能解决它的解决方案。无论你抉择什么,你都将不得不承受它--所以确保你的决策是基于具体的需要和充沛了解的工程衡量,而不是基于时尚或趋势。 常见问题解答 那么为什么这么多的服务网格应用Envoy? 因为编写本人的古代、可伸缩、高性能网络(微)代理十分艰难。真的很难。在过来的几年里,构建Linkerd2-proxy和Rust网络库使之成为可能是许多人付出的微小致力。除非你的我的项目既具备技术实力,又有解决这一挑战的欲望,否则应用Envoy要容易得多。 然而Envoy不是服务网格的“规范”吗? 不是。一个规范是互操作性所必须的货色。对服务网格至关重要的规范是TCP或HTTP,或者像SMI这样容许在服务网格之上构建工具的规范。(例如,这是Argo通过SMI为canary公布驱动Linkerd的绝佳例子。) Envoy作为服务网格数据立体代理的广泛抉择并不是一个规范,而是一个简略的共性。Envoy成为一个“服务网格规范”意味着什么?咱们能够把数据立体保留在原来的地位,而后换掉管制立体?咱们能够用不同的管制立体操作同一个数据立体?这些都是穿凿附会的用例。 但如果咱们要求应用Envoy呢? 我认为这不是一个真正的要求。你的工作不是采纳某一特定的技术。你的工作是解决问题。 如果你的问题是“咱们须要建设一个牢靠的、平安的、可察看的Kubernetes平台,而不须要付出疯狂的复杂性老本”,那么我强烈建议你考虑看看Linkerd。 当初谁在生产中应用Linkerd2-proxy? ...

December 10, 2020 · 1 min · jiezi

关于cncf:Kubernetes-120最优秀美妙酷的版本

你填了吗?2020年CNCF中国云原生问卷 问卷链接(https://www.wjx.cn/jq/9714648...) 作者:Kubernetes 1.20公布团队 咱们很快乐地发表Kubernetes 1.20的公布,这是咱们在2020年公布的第三个也是最终的版本!这个版本蕴含了42个加强:11个加强曾经稳固,15个加强进入beta,16个加强进入alpha。 在上一个扩大的公布周期之后,1.20的公布周期又回到了11周的失常节奏。这是一段时间以来性能最密集的版本之一:Kubernetes的翻新周期仍呈上升趋势。这个版本更多的是alpha而不是稳固的加强,这表明在云原生生态系统中还有很多须要摸索的中央。 主题 卷快照操作趋于稳定 该个性提供了一种触发卷快照操作的规范办法,并容许用户以可移植的形式在任何Kubernetes环境和反对的存储提供程序上合并快照操作。 此外,这些Kubernetes快照原语(primitive)充当根本构建块,解除了为Kubernetes开发高级、企业级存储管理个性(包含应用程序或集群级备份解决方案)的能力。 请留神,快照反对要求Kubernetes发行版绑定快照控制器、快照CRD和验证webhook。还必须在集群上部署反对快照性能的CSI驱动程序。 Kubectl Debug降级到Beta kubectl alpha debug性能在1.20中降级到beta版,成为kubectl debug。该个性间接从kubectl提供了对常见调试工作流的反对。此版本kubectl反对的故障排除场景包含: 通过创立应用不同容器镜像或命令的pod副原本进行故障排除在启动时解体的工作负载。通过在pod的新正本中增加带有调试工具的新容器或应用长期容器来进行故障排除无源(distroless)容器的故障。(长期容器是一个alpha个性,默认状况下不启用。)通过创立在主机命名空间中运行并可能拜访主机文件系统的容器来对节点进行故障排除。留神,作为一个新的内置命令,kubectl debug优先于任何名为“debug”的kubectl插件。你必须重命名受影响的插件。应用kubectl alpha debug的调用当初被弃用,将在后续版本中删除。更新脚本以应用kubectl debug。无关kubectl debug的更多信息,请参见调试运行的Pod。 Beta:API优先级和公平性 在1.18中引入,Kubernetes 1.20当初默认反对API优先级和公平性(APF,API Priority and Fairness)。这容许kube-apiserver按优先级级别对传入申请进行分类。 Alpha更新:IPV4/IPV6 IPv4/IPv6双栈曾经从新实现,以反对基于用户和社区反馈的双栈服务。这容许将IPv4和IPv6服务集群的IP地址调配给单个服务,也容许将一个服务从单个IP栈转换为双IP栈,反之亦然。 GA:过程PID限度以提供稳定性 过程ID(pid)是Linux主机上的根本资源。达到工作限度而不涉及任何其余资源限度并导致主机不稳固是很简略的。 管理员须要一些机制来确保用户pod不会导致pid耗尽,从而阻止主机守护过程(运行时、kubelet等)运行。此外,务必确保在pod之间限度pid,以确保它们对节点上的其余工作负载的影响无限。在默认启用一年之后,SIG Node在SupportNodePidsLimit(pod到pod PID隔离)和SupportPodPidsLimit(限度每个pod PID的能力)上将PID限度转变为GA。 Alpha:优雅敞开节点 用户和集群管理员心愿pod恪守预期的pod生命周期,包含pod终止。以后,当一个节点敞开时,pod没有遵循预期的pod终止生命周期,并且不能失常终止,这可能会导致一些工作负载问题。GracefulNodeShutdown个性当初是Alpha。GracefulNodeShutdown使kubelet可能意识到节点零碎的敞开,从而在零碎敞开期间可能优雅地终止pod。 次要变动 Dockershim弃用 Dockershim,用于Docker的容器运行时接口(CRI)垫片正在被弃用。对Docker的反对已被弃用,并将在将来的版本中删除。Docker生成的镜像将持续在兼容CRI的运行时在你的集群中工作,因为Docker镜像遵循Open Container Initiative(OCI)镜像标准。Kubernetes社区曾经写了一篇对于弃用的具体博客文章,并有专门的FAQ页面。 执行探针超时解决 一个长期存在的对于可能影响现有pod定义的执行探测超时的谬误曾经失去修复。在此修复之前,执行探测不思考timeoutSeconds字段。相同,探测将无限期地运行,甚至超过配置的最初期限,直到返回后果为止。通过这个更改,如果没有指定一个值,将利用缺省值1秒,如果探测工夫超过1秒,现有的pod定义可能不再足够。在此修复中增加了一个名为ExecProbeTimeout的个性gate,它使集群操作者可能复原到以前的行为,但在后续版本中将锁定并删除该个性。为了复原到以前的行为,集群操作人员应该将此个性门设置为false。 请查看对于配置探针的更新文档以理解更多细节。 其余的更新 降级到稳固 RuntimeClassBuilt-in API Types DefaultsAdd Pod-Startup Liveness-Probe HoldoffSupport CRI-ContainerD On WindowsSCTP Support for ServicesAdding AppProtocol To Services And Endpoints显著的个性更新 ...

December 9, 2020 · 1 min · jiezi

关于cncf:使用Argo和Kubernetes构建Kubernetes集群

你填了吗?2020年CNCF中国云原生问卷 问卷链接(https://www.wjx.cn/jq/9714648...) 客座文章来自SAP高级零碎工程师Tomas Valasek。Tomas从2014年开始从事容器、云原生和云自动化方面的工作,同时也是SAP Concur公司Kubernetes的技术倡导者。在这篇文章中,他谈到了SAP Concur团队如何应用Argo Workflows、Argo Events、Helm和EKS来自动化创立、附加组件装置、应用前测试和最终的集群验证。原文连贯。 等等……什么?是的,当我第一次提出应用Kubernetes构建Kubernetes集群的想法时,我就听到了这种反馈。 然而,对于云基础设施自动化,我想不出比Kubernetes更好的工具了。咱们应用一个地方K8s集群构建和治理数百个其余K8s集群。在本文中,我将向你展现如何做到这一点。 留神:SAP Concur应用AWS EKS,相似的概念能够利用于谷歌的GKE,Azure的AKS,或任何其余云提供商的Kubernetes产品。 生产就绪 在任何次要的云提供商中构建一个Kubernetes集群素来没有这么容易过。使AWS EKS集群启动和运行就像: $ eksctl create cluster然而,要构建可用于生产的Kubernetes集群,还须要更多。尽管生产就绪的定义可能不同,但SAP Concur应用这4个构建阶段来构建和交付生产就绪的Kubernetes集群。 4个构建阶段 应用前测试:针对指标AWS环境的一组根本测试,以确保在咱们开始理论的集群构建之前所有需要都已就绪。例如:每个子网的可用IP地址、AWS导出、SSM参数或其余变量。EKS管制立体和节点组:这是一个理论的AWS EKS集群,带有附加的工作节点。插件装置:装璜。这就是让你的集群更甘甜的中央:-)装置像Istio、日志集成、autoscaler等插件。插件的列表是全面和齐全可选的。集群验证:在这个阶段,咱们从性能的角度验证集群(EKS外围组件和插件),而后再将其签名并移交。你写的测试越多,你的睡眠就越好。(尤其是当你是on-call的时候!)把它们粘合起来! 这4个构建阶段都应用不同的工具和技术(我将在前面形容)。咱们正在寻找一种工具,能够将它们粘合在一起,同时反对序列和并行性;API驱动;并且最好可能可视化每个构建。 瞧!咱们发现了Argo产品家族,特地是Argo Events和Argo Workflows。两者都作为CRD在Kubernetes上运行,并应用在其余Kubernetes部署中应用的YAML申明式概念。 咱们找到了完满的组合:命令式编排和申明式自动化 应用Argo Workflows构建的生产就绪的K8s集群 用Argo Workflows合成流程 Argo Workflows是一个开源的容器原生工作流引擎,用于在Kubernetes上编排并行作业。Argo Workflows实现为Kubernetes CRD。留神:如果你相熟K8s YAML,我保障这将很容易。 让咱们看看这4个构建阶段在Argo Workflows中是什么样的。 1. 应用前测试 应用前测试与失败时的重试并行运行 咱们应用BATS测试框架作为一个无效的工具来编写测试。编写一个应用前测试在BATS能够简略的如下: #!/usr/bin/env bats@test “More than 100 available IP addresses in subnet MySubnet” {AvailableIpAddressCount=$(aws ec2 describe-subnets --subnet-ids MySubnet | jq -r ‘.Subnets[0].AvailableIpAddressCount’) [ “${AvailableIpAddressCount}” -gt 100 ]}并行运行下面的BATS测试文件(available-ip-address.bats)和其余3个应用Argo Workflows的虚构BATS测试,会如下所示: ...

December 8, 2020 · 2 min · jiezi

关于cncf:Dockershim弃用常见问题解答

来奉献几分钟提交:2020年CNCF中国云原生问卷 问卷链接(https://www.wjx.cn/jq/9714648...) 本文介绍了一些常见的对于在Kubernetes v1.20版本中发表的Dockershim弃用的问题。对于弃用Docker作为Kubernetes kubelets的容器运行时的更多细节,以及这意味着什么,请查看博客文章《不要惊恐:Kubernetes和Docker》。 为什么dockershim被弃用? 保护dockershim已成为Kubernetes保护人员的沉重负担。创立CRI规范就是为了加重这种累赘,并容许不同容器运行时的顺畅互操作性。Docker自身目前没有实现CRI,这就是问题所在。 Dockershim始终是一种长期解决方案(因而得名:shim,垫片)。你能够在Dockershim移除Kubernetes加强倡议中浏览更多对于社区探讨和布局的内容。 此外,与dockershim不兼容的个性,如cgroups v2和用户命名空间,正在这些新的CRI运行时中实现。勾销对dockershim的反对将容许这些畛域的进一步倒退。 我还能够在Kubernetes 1.20应用Docker吗? 能够,在1.20中惟一扭转的是,如果应用Docker作为运行时,在kubelet启动时打印一个正告日志。 dockershim什么时候会被移除? 思考到此更改的影响,咱们应用了一个扩大的弃用工夫线。它不会在Kubernetes 1.22之前被删除,这意味着最早不应用dockershim的版本将是2021年底的1.23。咱们将与供应商和其余生态系统组织密切合作,以确保平稳过渡,并将依据状况的演变进行评估。 我现有的Docker镜像还能工作吗? 能够,从docker build产生的镜像将与所有CRI实现一起工作。你所有的现有镜像将依然完全相同的工作。 那么公有映像呢? 也能够。所有CRI运行时都反对Kubernetes中应用的雷同的pull secrets配置,无论是通过PodSpec还是ServiceAccount。 Docker和容器是同一回事吗? Docker遍及了Linux容器模式,并帮忙开发了底层技术,然而Linux中的容器曾经存在很长时间了。容器生态系统曾经倒退到比Docker更宽泛的范畴。像OCI和CRI这样的规范曾经帮忙许多工具在咱们的生态系统中成长和茁壮成长,一些代替了Docker的某些方面,而另一些则加强了现有的性能。 当初在生产环境中是否有应用其余运行时的例子? 所有Kubernetes我的项目生成的工件(Kubernetes二进制文件)都会在每个版本中进行验证。 此外,kind我的项目曾经应用containerd一段时间了,并且看到了其用例稳定性的改良。每天都要屡次应用Kind和containerd来验证对Kubernetes代码基的任何更改。其余相干我的项目也遵循相似的模式,演示了其余容器运行时的稳定性和可用性。比方OpenShift 4.x自2019年6月以来始终在生产中应用CRI-O运行时。 对于其余示例和参考,你能够查看containerd和cri-o的采纳者,这两个容器运行时托管在CNCF。 人们始终援用OCI,那是什么? OCI代表Open Container Initiative(凋谢容器倡导),它标准化了容器工具和技术之间的许多接口。它们保护了包装容器映像(OCI映像标准)和运行容器(OCI运行时标准)的标准规范。它们还以runc的模式保护运行时标准的理论实现,它是containerd和CRI-O的底层默认运行时。CRI构建在这些低层标准之上,为治理容器提供端到端规范。 我应该应用哪个CRI实现? 这是一个简单的问题,它取决于很多因素。如果Docker为你工作得很好,迁徙到containerd应该是一个绝对容易的替换,并且具备更好的性能和更少的开销。然而,咱们激励你摸索CNCF互动景观的所有选项,以防其余选项更适宜你的环境。 更改CRI实现时应该留神什么? 尽管Docker和大多数CRI(包含containerd)之间的底层容器化代码是雷同的,但在边缘有一些不同之处。迁徙时要思考的一些常见的事件是: 日志配置运行时资源限度节点配置脚本,调用docker或应用docker通过它的管制socket须要docker CLI或管制socket的Kubectl插件须要间接拜访Docker的Kubernetes工具(例如kube-imagepuller)配置注册镜像和不平安注册表等性能假如docker可用并在Kubernetes之外运行的其余反对脚本或守护过程(例如监督或平安代理)GPU或非凡硬件以及它们如何与运行时和Kubernetes集成如果你应用Kubernetes资源申请/限度(request/limit)或基于文件的日志收集DaemonSet,那么它们将持续以雷同的形式工作,然而如果你曾经定制了dockerd配置,则须要在可能的状况下为新的容器运行时进行调整。 另一件须要留神的事件是,在构建镜像时,任何心愿运行用于系统维护或嵌套在容器内的货色都将不再工作。对于前者,你能够应用crictl工具作为替换,对于后者,你能够应用较新的容器构建选项,如img、buildah或kaniko,它们不须要Docker。 对于containerd,你能够从它们的文档开始,看看在迁徙时有哪些配置选项可用。 无关如何将containerd和CRI-O与Kubernetes一起应用的阐明,请参阅Kubernetes对于容器运行时的文档 如果我还有问题怎么办? 如果你应用供应商反对的Kubernetes发行版,你能够询问他们对于其产品的降级打算。对于最终用户的问题,请发送到咱们的最终用户社区论坛。 你也能够看看这篇优良的博客文章:《等等,Docker曾经被Kubernetes弃用了吗?》对更改进行更深刻的技术探讨。 我能拥抱一下吗? 只有你违心,随时随地!???????? 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

December 4, 2020 · 1 min · jiezi

关于cncf:不要惊慌Kubernetes和Docker

来奉献几分钟提交:2020年CNCF中国云原生问卷 问卷链接(https://www.wjx.cn/jq/9714648...) 作者:Jorge Castro、Duffie Cooley、Kat Cosgrove、Justin Garrison、Noah Kantrowitz、Bob Killen、Rey Lejano、Dan "POP" Papandrea、Jeffrey Sica、Davanum "Dims" Srinivas Kubernetes在1.20版本之后将弃用Docker作为容器运行时。 你不须要惊恐。这并不像听起来那么戏剧化。 简略来讲:Docker作为底层运行时正在被弃用,取而代之的是应用为Kubernetes创立的CRI(Container Runtime Interface,容器运行时接口)的运行时。Docker生成的镜像将持续在你的集群中与所有运行时一起工作,就像它们始终那样。 如果你是Kubernetes的最终用户,那么不会有太多的变动。这并不意味着Docker的沦亡,也不意味着你不能或不应该再应用Docker作为开发工具。Docker依然是构建容器的有用工具,运行Docker build产生的镜像依然能够在Kubernetes集群中运行。 如果你正在应用像GKE或EKS这样的托管Kubernetes服务,那么在Kubernetes的将来版本中删除Docker反对之前,你须要确保你的工作节点应用的是受反对的容器运行时。如果你有节点自定义,则可能须要依据环境和运行时需要更新它们。请与你的服务提供商单干,以确保适当的降级测试和打算。 如果你在创立本人的集群,你还须要进行更改,以防止集群解体。在v1.20,你将收到Docker的弃用正告。当Docker运行时反对在Kubernetes的将来发行版(目前打算在2021年底的1.23发行版)中被移除时,它将不再受反对,你将须要切换到其余兼容的容器运行时,如containerd或CRI-O。只有确保你抉择的运行时反对你以后应用的docker守护过程配置(例如日志)。 那么,为什么会有这种困惑呢?每个人都在放心什么呢? 咱们在这里探讨的是两种不同的环境,这就造成了混同。在Kubernetes集群中,有一个称为容器运行时的货色,它负责提取和运行容器镜像。Docker是该运行时的风行抉择(其余常见选项包含containerd和CRI-O),然而Docker并不是被设计成嵌入到Kubernetes中,这就导致了一个问题。 你看,咱们称为“Docker”的货色实际上并不只是一个货色--它是一个残缺的技术堆栈,其中一部分是一个叫做“containerd”的货色,它自身是一个高级的容器运行时。Docker很酷,也很有用,因为它有很多UX加强,使得在咱们进行开发工作时很容易与人交互,然而这些UX加强对Kubernetes来说不是必须的,因为它不是人。 因为有了这个对人敌对的形象层,你的Kubernetes集群必须应用另一个称为Dockershim的工具来取得它真正须要的货色,它蕴含在其中。这不太好,因为它给了咱们另一个须要保护的货色,而且可能会损坏。这里理论产生的是,Dockershim最早将在v1.23版本就从Kubelet中删除了,从而勾销了对Docker作为容器运行时的反对。你可能会想,如果containerd蕴含在Docker堆栈中,为什么Kubernetes须要Dockershim呢? Docker与CRI(容器运行时接口)不兼容。如果是的话,咱们就不须要垫片了,这就不成问题了。但这并不是世界末日,你也不用惊恐--你只须要将容器运行时从Docker更改为另一个受反对的容器运行时。 须要留神的一点是:如果你当初在集群中依赖底层docker socket(/var/run/docker.sock)作为工作流程的一部分,迁徙到不同的运行时将会毁坏你应用它的能力。这种模式通常称为Docker in Docker。对于这个特定的用例,有很多抉择,包含kaniko、img和buildah。 然而,这种变动对开发人员意味着什么呢?咱们还在写Dockerfile吗?咱们还用Docker构建货色吗? 这一扭转解决了一个与大多数人应用Docker进行交互的不同环境。你在开发中应用的Docker装置与Kubernetes集群中的Docker运行时无关。我晓得这很令人困惑。作为一名开发人员,Docker依然对你很有用,就像在这项更改发表之前一样。Docker生成的镜像实际上并不是一个特定于Docker的镜像--它是一个OCI(Open Container Initiative)镜像。无论你应用什么工具构建它,任何合乎OCI规范的镜像在Kubernetes看来都是一样的。containerd和CRI-O都晓得如何提取这些镜像并运行它们。这就是为什么咱们有一个容器应该是什么样的规范。 所以,这种变动正在到来。这会给一些人带来问题,但这不是灾难性的,而且一般来说这是件坏事。取决于你如何与Kubernetes交互,这可能对你毫无意义,也可能意味着须要进行一些工作。从久远来看,这会让事件变得更简略。如果这依然让你感到困惑,那也没关系--这里产生了很多事件,Kubernetes有很多变动的局部,没有人是100%的专家。咱们激励任何和所有的问题,无论教训程度或复杂性!咱们的指标是确保每个人都尽可能多地理解行将到来的变动。咱们心愿这曾经答复了你的大部分问题,缓解了你的一些焦虑! 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

December 3, 2020 · 1 min · jiezi

关于cncf:在Vitess上运行Django应用程序

来奉献几分钟提交:2020年CNCF中国云原生问卷 问卷链接(https://www.wjx.cn/jq/9714648...) 作者:Alkin Tezuysal Django是Python应用程序开发人员罕用的框架。它蕴含的包能够简化受权和内容治理等工作。Django反对包含MySQL在内的许多数据库,这使得不须要批改利用程序代码就能够在Vitess上运行Django应用程序。让咱们看看如何联合这两个开放源码框架的长处。 咱们应用Vitess操作器构建这个示例。你能够在这篇博客文章中看到Vitess操作器实现的细节。 先决条件 本地Python环境(3.X)Kubernetes环境(minikube、GKE)通过Vitess反对Django ORM在本例中,咱们将在GKE应用一个现有的Kubernetes集群。你也能够通过本地的minikube来实现此操作。 咱们应用的Django示例是“天气应用程序”。咱们首先应用提供的配置启动vitess操作器。 以下局部包含这些步骤: 创立Vitess操作器pod构建Vitess集群组件(1x主tablet、1x复制tablet、3x etcd pod、1x vtgate、1x vtctld、1x vitessbackup)创立“weatherapp”数据库模式和用户。$ kubectl apply -f operator.yamlcustomresourcedefinition.apiextensions.k8s.io/etcdlockservers.planetscale.com createdcustomresourcedefinition.apiextensions.k8s.io/vitessbackups.planetscale.com createdcustomresourcedefinition.apiextensions.k8s.io/vitessbackupstorages.planetscale.com createdcustomresourcedefinition.apiextensions.k8s.io/vitesscells.planetscale.com createdcustomresourcedefinition.apiextensions.k8s.io/vitessclusters.planetscale.com createdcustomresourcedefinition.apiextensions.k8s.io/vitesskeyspaces.planetscale.com createdcustomresourcedefinition.apiextensions.k8s.io/vitessshards.planetscale.com createdserviceaccount/vitess-operator createdrole.rbac.authorization.k8s.io/vitess-operator createdrolebinding.rbac.authorization.k8s.io/vitess-operator createdpriorityclass.scheduling.k8s.io/vitess createdpriorityclass.scheduling.k8s.io/vitess-operator-control-plane createddeployment.apps/vitess-operator created$ kubectl get podsNAME READY STATUS RESTARTS AGEvitess-operator-7f9c9d58f6-q5zlf 1/1 Running 0 20s用一个名为“weatherapp”的示例数据库初始化这个集群,拜访它的用户/明码将嵌入到配置文件中。咱们基本上是在创立一个数据库,相似于Vitess中的密钥空间。 $ kubectl apply -f 101_initial_cluster.yaml.django$ kubectl get podsNAME READY STATUS RESTARTS AGEexample-90089e05-vitessbackupstorage-subcontroller 1/1 Running 0 94sexample-etcd-faf13de3-1 1/1 Running 0 94sexample-etcd-faf13de3-2 1/1 Running 0 94sexample-etcd-faf13de3-3 1/1 Running 0 94sexample-vttablet-zone1-1542279354-edf1c7bf 2/3 Running 1 94sexample-vttablet-zone1-3763665199-476cbd65 2/3 Running 2 94sexample-weatherapp-x-x-vtbackup-init-75efaeeb 0/1 Completed 0 74sexample-zone1-vtctld-1d4dcad0-67bfd56b8b-4dr9s 1/1 Running 2 94sexample-zone1-vtgate-bc6cde92-59b88bc8d8-6wz86 1/1 Running 2 94svitess-operator-7f9c9d58f6-q5zlf 1/1 Running 0 4m30s如你所见,这将带来一个功能齐全的托管Vitess集群,其中蕴含一个未分片的密钥空间,其中包含一个“主”和一个“正本”。 ...

December 2, 2020 · 3 min · jiezi

关于cncf:CNCF宣布etcd毕业

在过来的12个月中,宽泛应用的数据存储解决方案曾经有200位不同的贡献者 旧金山,加利福尼亚州--2020年11月24日--CNCF®(云原生计算基金会,Cloud Native Computing Foundation®),旨在为云原生软件构建可继续的生态系统,明天发表etcd毕业。从孵化到毕业阶段,etcd曾经被越来越多的人采纳、领有凋谢的治理过程、个性成熟度,以及对社区、可持续性和包容性的强烈承诺。 etcd是分布式的、牢靠的键值存储,它提供了牢靠的形式来存储须要由分布式系统或机器集群拜访的数据。任何简单的应用程序,从简略的web应用程序到Kubernetes,都能够从etcd读取数据并将数据写入其中。该我的项目于2013年在CoreOS创立,并于2018年12月作为孵化我的项目退出CNCF。 “etcd我的项目是Kubernetes外部的要害组件,其余许多我的项目都依赖etcd来实现牢靠的分布式数据存储。”CNCF CTO Chris Aniszczyk说:“咱们对etcd在规模上继续达到的里程碑和在最近的保安审计上的成熟解决形式留下深刻印象,咱们期待其作为毕业我的项目培养社区。” etcd被许多公司用于生产,包含阿里巴巴、亚马逊、百度、思科、EMC、谷歌、华为、IBM、红帽、Uber、Verizon等,以及Kubernetes、CoreDNS、M3、Rook和TiKV等我的项目。 “etcd作为咱们在Placement Driver中的元数据存储,以及咱们在生产中对Raft施行的灵感,曾经被证实是TiKV和TiDB的一个很好的抉择,能够确保跨TiDB集群的数据一致性和高可用性。”PingCAP联结创始人兼CTO Ed Huang说:“能参加到它的毕业旅程中来,咱们感到十分骄傲和快乐。将来咱们也违心更多地参加到它的生态系统开发中去。” 维护者团队目前由10名成员组成,代表的公司散布良好,包含阿里巴巴、亚马逊、Cockroach Labs、谷歌云、IBM,以及红帽。自从etcd成为孵化我的项目以来,曾经减少了三位新的维护者。在过来的12个月里,有200名不同的贡献者编写了pull request。 “通过七年的倒退,etcd曾经成熟,成为许多分布式系统的基石。它胜利的最重要的决定是退出了CNCF社区,并在许多组织中造就保护人员,”Xiang说,他是etcd维护者兼CNCF TOC成员,也是阿里云工程总监。“咱们很快乐看到它在CNCF毕业。etcd是撑持阿里云的容器服务和许多其余要害服务的外围。咱们期待着在将来进步其稳定性、可靠性和性能。” 由CNCF资助的第三方平安审计是在2020年7月通过Trail of Bits对etcd v3.4的最新次要发行版进行的。依据报告,etcd代码基是一个成熟的、被宽泛采纳的产品,在etcd的外围组件中没有发现显著的问题。在etcd网关中发现了一个重大的问题,该团队通过修复和向后移植到etcd反对的版本中解决了这个问题。 该我的项目还在2020年1月通过了Jepsen测试,该测试剖析了开源分布式系统,以查看它们是否实现了一致性保障。结果显示了我的项目性能的成熟度。Jepsen团队还指出了一些须要改良的中央,并由etcd团队实现。 “从一开始,etcd就被设计为简化统一存储操作,这使得它对于像Kubernetes这样的容器编排零碎的应用具备吸引力。etcd作为Kubernetes的管制立体存储被证实是十分适合的,两个我的项目曾经一起成长和成熟,”etcd维护者兼谷歌云软件工程师Joe Betz说。“咱们很快乐看到etcd在可靠性、可扩展性和品质方面的致力在本次毕业上失去CNCF的认可。明天的布告是etcd的成熟和它对生产工作负载的准备就绪的证实。” “明天etcd毕业的重要里程碑,没有社区的工作和CNCF的反对,是不可能实现的。”IBM凋谢技术高级软件工程师兼etcd维护者Sahdev Zala说:“etcd在提供分布式键值存储方面施展着关键作用,该存储具备高可用性,满足大规模Kubernetes集群的强一致性要求。” “开源软件在很多方面为咱们的生存提供了能源,”AWS Kubernetes总经理Bob Wise说。“从Linux到Kubernetes,各种规模的组织和各行各业的建设者们破费了大量的工夫创立和保护我的项目,这些我的项目撑持了咱们每天应用的互联网、电信、金融、交通、游戏、批发和医疗保健零碎。etcd是其中一个重要的我的项目,咱们很骄傲etcd作为Amazon EKS的外围局部,并参加帮忙这个我的项目成长和凋敝。咱们是etcd毕业的热心支持者,并期待与etcd和其余CNCF我的项目单干,构建平安、牢靠、弱小和可扩大的开放源码软件。” 为了从孵化阶段正式毕业,该我的项目取得了CII最佳实际徽章认证,实现了平安审计并解决了破绽,定义了本人的治理,并采纳了CNCF行为准则。 etcd背景 etcd是一个分布式的、牢靠的键值存储,用于分布式系统中最要害的数据,关注于: 简略:定义良好、面向用户的API(gRPC)平安:主动TLS与可选的客户证书身份验证疾速:基准测试10,000写/秒牢靠:应用Raft作正当散布要理解更多无关etcd的信息,请拜访:etcd.io。 点击浏览网站原文。 开始了!2020年CNCF中国云原生考察 问卷链接(https://www.wjx.cn/jq/9714648...) CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

November 25, 2020 · 1 min · jiezi

关于cncf:开始了2020年CNCF中国云原生调查

CNCF云原生考察把脉社区,以便更好地理解CNCF我的项目和云原生技术的采纳状况。 调查结果会载入报告和大家分享,突出咱们在各个行业中察看到的新的变化趋势。 问卷链接:https://www.wjx.cn/jq/9714648... 点击中转问卷链接。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

November 24, 2020 · 1 min · jiezi

关于cncf:集群的云原生安全

作者:Pushkar Joglekar 在过来的几年中,一个关注平安的小型社区始终在致力工作,以加深咱们对平安的了解,并给出了一直倒退的云原生基础设施和相应的迭代部署实际。为了可能与社区的其余成员共享这一常识,由Emily Fox领导的CNCF SIG Security的成员(一个向CNCF TOC回报的小组,他们也是Kubernetes SIG Security的敌人)在白皮书中概述了整体的云原生平安问题和最佳实际。在来自世界各地35个成员的1200多个评论、批改和探讨之后,咱们很骄傲地与大家分享云原生平安白皮书v1.0,它是企业、金融和医疗保健行业、学术界、政府和非营利组织的平安领导必备的浏览资料。 白皮书试图不关注任何特定的云原生我的项目。相同,其目标是将安全性建模并注入云原生利用生命周期的四个逻辑阶段:开发、散发、部署和运行时。 Kubernetes原生安全控制 当应用Kubernetes作为工作负载协调器时,这个版本的白皮书举荐的一些安全控制如下: Pod安全策略:为整个集群的“起码特权”工作负载实现一个实在源资源申请和限度:对共享资源(如内存和CPU)利用申请(软束缚)和限度(硬束缚)审计日志剖析:启用Kubernetes API审计和筛选与平安相干的事件管制立体身份验证和信赖的证书根:启用互相TLS身份验证,应用可信的CA在集群内进行通信机密治理:与内置或内部机密存储集成云原生互补安全控制 Kubernetes直接参与部署阶段,较少参加运行时阶段。为了使Kubernetes中的工作负载“默认状况下是平安的”,必须确保安全地开发和散发工件。在云原生应用程序生命周期的所有阶段,存在一些针对Kubernetes编排的工作负载的补充性安全控制,包含但不限于: 开发: 镜像签名与验证镜像破绽扫描器散发: 部署前查看是否存在适度特权启用可察看性和日志记录部署: 应用服务网格进行工作负载身份验证和受权通过网络插件为工作负载间通信强制执行“默认回绝”网络策略运行时: 为工作负载部署平安监督代理应用SELinux、AppArmor等隔离在同一节点上运行的应用程序。依据公认的平安基线扫描节点、工作负载和协调器的配置先理解,后平安 云原生形式(包含容器)为其用户提供了微小的平安劣势:不变性、模块化、更快的降级和跨环境的统一状态。意识到“做事形式”的这种根本性变动,促使咱们从云原生的角度来对待平安问题。对于白皮书作者来说不言而喻的一件事是,如果你不理解手头的工具、模式和框架,那么就如何以及哪些在云原生生态系统中进行爱护就很难做出更理智的决定(除了理解本人的重要资产之外)。因而,对于那些想要成为合作伙伴而不是在操作、产品开发和合规方面为敌人看门人的平安从业者来说,让咱们尝试学习更多常识以便更好地确保安全。 咱们举荐遵循这7步R.U.N.T.I.M.E.门路来开始云原生平安: 浏览(Run )白皮书和其中任何相干的资料理解(Understand)环境中的挑战和限度留神(Note)利用于环境的内容和控件和你的伙伴议论(Talk)你的察看让你的领导参加(Involve)进来,寻求帮忙基于现有的和缺失的安全控制,制作(Make)一个危险概要在适当的中央,破费(Expend)工夫、金钱和资源来改善平安情况并升高危险。鸣谢 感激Emily Fox、Tim Bannister(The Scale Factory)、Chase Pettet(Mirantis)和Wayne Haber(GitLab)为这篇博客提供的精彩倡议。 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

November 20, 2020 · 1 min · jiezi

关于cncf:CNCF最终用户技术雷达数据库存储2020年11月

明天,CNCF公布了季度第三期CNCF最终用户技术雷达;该技术雷达的主题是数据库存储。 6月,咱们推出了CNCF最终用户技术雷达,这是CNCF最终用户社区的一个新倡导。这是一个由超过140家顶级公司和初创公司组成的个人,他们定期开会讨论在采纳云原生技术时面临的挑战和最佳实际。CNCF最终用户技术雷达的指标是分享最终用户正在踊跃应用的工具、他们举荐的工具以及他们的应用模式。更多对于该办法的信息能够在这里找到。 到radar.cncf.io可寻到其余雷达、选票和代表的行业。 请锁定11月20日星期五下午4:00 ET时区的北美KubeCon + CloudNativeCon虚构大会,收看TechRadar与Cheryl Hung和Radar的编辑们的现场问答环节,将会听到他们对后果的更多想法和理解。 数据库存储的考察 在2020年10月,最终用户社区的成员被问及他们评估、试验并随后驳回了哪些数据库存储解决方案。总共273个数据点被排序和审查,以确定最终的地位。 这能够解读为: “驳回(Adopt)”中的六种工具被受访者宽泛驳回和举荐。“试验(Trial)”中的技术失去了一些最终用户的举荐,但他们要么没有失去足够的总体响应,要么只有多数人投了“驳回”票。“评估(Assess)”的我的项目不足明确的共识。对MariaDB、CockroachDB和Vitess有肯定理解,但只有多数用户举荐驳回。寻找新的数据库存储解决方案的组织在思考“评估”中的需要时应该思考到它们本人的需要。主题 主题形容了乏味的模式和编辑察看: 1. 公司对本人的数据很审慎,采纳新技术的速度也很慢。 新技术,如CockroachDB、TiDB和Vitess,还没有被许多作出回应的公司宽泛钻研。CockroachDB和Vitess最终呈现在“评估”。 一些不同的因素促使组织对他们的数据采取审慎的态度,但次要的起因是难以治理。在将大量数据(有时是tb或pb)从一种数据存储技术转移到另一种数据存储技术时,会产生大量的开销。要想口头有意义,收益必须大于老本。即便在从遗留解决方案过渡到云计算时,一些公司也会思考集成他们曾经领有的工具。 另一个因素可能是更难雇佣在这些新技术方面有特长的开发人员。“评估”中的所有我的项目(CockroachDB、MariaDB和Vitess)都与“驳回”中的技术具备API兼容性,因而组织能够在不转换到新工具的状况下集成元素。 乏味的是,etcd并没有呈现在雷达上。etcd的应用次要是由Kubernetes驱动的,因为它是惟一受反对的后端。公司很少应用etcd作为独立的数据托管抉择,这意味着从遗留基础设施过渡过去的公司不太可能有应用它的教训。 2. 抉择托管数据库服务在很大水平上取决于用例。 咱们诧异地看到云治理服务的使用率很低。这让咱们意识到,托管数据库服务的应用可能因用例的不同而差别很大--应用程序部署的地位、存储的数据量,以及是否曾经应用了云提供商。例如,如果一个公司有大量数据,那么应用托管数据库解决方案可能会带来微小的老本开销。 云治理数据库的应用可能会受到公司是否曾经在应用特定云提供商的影响。例如,如果一家公司只在其余云服务上应用AWS,那么他们很可能也会应用AWS相干的数据库技术。如果它们在本地运行,它们很可能不会只在云中运行数据库。 在其余状况下,决策可能由数据安全和爱护驱动。解决敏感数据的公司更有可能在外部建设数据库,甚至可能被要求这样做。 尽管咱们的确问过RDS,但它最终并没有呈现在雷达上。咱们删除了它,因为它的用法含糊不清,也不分明应用了什么非凡的技术。 3. 放弃凋谢的心态! 咱们发现,数据库存储依然是一个一直倒退的畛域。有些我的项目曾经存在了很长时间,这可能会进步它们的采用率,特地是思考到在大公司的应用。这些遗留技术中的许多都享有良好的名誉,因为它们是稳固的,并且被证实能够工作。 新的云原生我的项目正在呈现,其中许多更适宜新的用例。有一些具备非凡用例的新技术没有进入雷达;咱们没有看到任何图形数据库、指标的长期存储或无服务器数据库。 最终,你必须为你、你的团队和你的组织抉择正确的技术。应用一种你能够随时染指并替换的技术,与强制工程师去适应某种技术相比,是否更有意义?你正在思考的开源我的项目背地是否有一个蓬勃发展的社区?做你的钻研,做有意义的事件,然而不要胆怯尝试新事物! 编辑 Jackie Fong是Ticketmaster平台部门的工程主管,负责容器编排、CI/CD、察看能力和开发教训。在2020年初,Jackie在CNCF成立了一个服务网最终用户小组,并负责联结主席。 Smaine Kahlouch是Dailymotion的DevOps团队负责人。他领导了一个团队,负责构建一个牢靠的、可扩大的平台,以及公布治理。他是CNCF在巴黎meetup的组织者,也是CNCF在法国的大使。Twitter: smana Mya Pitzeruse是Indeed公司服务平台部门的首席工程师,负责设计和领导跨计算、存储和观测的云原生平台的开发。Twitter: myajpitz 浏览延长 案例钻研:理解京东、Slack和Square如何应用CNCF技术解决数据库存储。 接下来 下一个CNCF最终用户技术雷达将于2021年2月公布,关注的是云原生的一个不同主题。投票帮忙决定下一个CNCF最终用户技术雷达的主题。 退出CNCF最终用户社区: 找出到底是谁在应用每个我的项目,并浏览他们的评论。奉献和编辑将来的CNCF最终用户技术雷达。咱们很快乐向社区提供这份报告,咱们也很乐意听到你的想法。反馈邮件发送到info@cncf.io。 对于办法 2020年10月,CNCF最终用户社区的140家公司形容他们的公司对不同解决方案的倡议:暂缓、评估、试验或驳回。他们也能够给出更具体的评论。因为答案是通过谷歌电子表格提交的,所以在小组中既不窃密也不匿名。 29家公司提交了对于36个解决方案的273个数据点。这些被排序以确定最终的地位。最初,编辑编写主题以反映更宽泛的模式。 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

November 19, 2020 · 1 min · jiezi

关于cncf:TOC批准Buildpacks从沙箱提升到孵化阶段

明天,CNCF技术监督委员会(TOC)投票决定将云原生Buildpacks从CNCF沙箱晋升到孵化阶段。自2018年退出CNCF以来,Cloud Native Buildpacks我的项目曾经减少了超过15个新的生产用户和来自更多组织的新提交者,并定义了一个凋谢的治理流程和清晰的我的项目路线图。 Cloud Native Buildpacks(CNB)我的项目的指标是将源代码转换为容器镜像,重点关注开发人员的生产力、容器安全性和波及大规模容器化应用程序的操作。该我的项目还旨在将过来的构建包(buildpack)生态系统与古代云原生平台的定义良好的契约现实对立起来。 “云原生Buildpacks使开发人员可能在对他们最有生产力的形象层上工作,同时解决像软弱依赖和构建迟缓这样的大问题。”VMware的Buildpacks维护者和工程师Emily Casey说:“该我的项目弱小的标准和工具帮忙促成了可组合构建包的生态系统,能够与不同的平台互操作。随着Buildpacks进入孵化阶段,咱们很快乐能持续倒退社区。” “Heroku(Salesforce)在2012年开源了最后的Buildpacks我的项目,心愿它们能扩大到Heroku平台之外,”Buildpacks联结创始人兼Salesforce首席工程师Terence Lee说。“2018年,Heroku和Pivotal(VMware)单干创立了云原生Buildpacks,这是一个CNCF沙箱我的项目。从CNCF的沙箱到孵化阶段,Buildpacks正在实现这一愿景,同时应用OCI镜像规范,减少透明度,建设咱们的社区。咱们期待着与社区单干,开发新的性能,并取得更多用户的承受。” 2018年10月,云原生Buildpacks被CNCF沙箱承受。Buildpacks被最终用户组织用于生产,包含Greenhouse、Salesforce和VMware;云计算原生开源软件包含Cloud Foundry on K8s、谷歌Skaffold、Hashicorp Waypoint和kpack;商业产品包含DigitalOcean利用平台、谷歌云、Salesforce Evergreen和VMware Tanzu Build Service。 “HashiCorp Waypoint从第一天开始就设定应用Buildpacks。咱们心愿开发人员可能尽可能疾速、轻松地从编写代码到部署,而云原生Buildpacks提供了实现这一指标的规范、技术和社区,”HashiCorp创始人Mitchell Hashimoto说,“咱们期待持续投资和改良咱们的Buildpacks应用。” “开发人员不应该思考如何打包他们的应用程序来进行部署,所以我很快乐看到云原生Buildpacks被晋升为CNCF孵化我的项目。”谷歌云开发人员倡导者James Ward说:“在谷歌云,咱们曾经开源了咱们的Buildpacks,并将对它们的反对增加到许多产品中,包含Cloud Build、Cloud Run、App Engine、Cloud Functions、Cloud Code、云Shell和Skaffold。当初,从源代码到在云上运行就更容易了。” Buildpacks的次要个性: 标准--形容平台到Buildpacks契约的正式语言标准。实现--平台须要强壮的生命周期工具以增加应用Buildpacks构建镜像的反对。平台--间接向最终用户提供开发体验的组件,包含与风行构建工具和云平台的集成。里程碑亮点: 6名来自Salesforce和VMware的维护者20名提交者2k以上奉献简直5k提交超过1200万GitHub星星15名贡献者云原生Buildpacks我的项目是对其余CNCF我的项目的补充,包含Helm、Harbor和Kubernetes。云原生Buildpacks生成由Helm治理、存储在Harbor并部署到Kubernetes的OCI(Open Container Initiative,凋谢容器倡导)镜像。该项目标首要指标是提供一种牢靠、平安、模块化和疾速的办法来从源或输出工件构建OCI镜像。 “云原生Buildpacks提供了一种牢靠而无缝的形式来将代码转换为容器。”CNCF CTO兼OCI执行董事Chris Aniszczyk说:“这升高了开发人员利用云原生技术的阻碍,并改善了局部开发人员和云原生平台的开发体验。” “用户须要一种简略的形式来打包、提供和治理云原生应用程序。最后由Heroku或Cloud Foundry应用的Buildpacks当初曾经齐全云原生化,包含Kubernetes推广的要害模式。”Weaveworks首席执行官兼CNCF TOC前成员Alexis Richardson说,“这些都是作为GitOps外围的要害模式,联合应用它们,Weaveworks的客户能够降级和修补他们的利用部署。” 作为CNCF托管我的项目,退出孵化技术Argo、CloudEvents、CNI、Contour、Cortex、CRI-O、Dragonfly、etcd、Falco、gRPC、KubeEdge、Linkerd、NATS、Notary、OPA、OpenTracing、Operator Framework、Rook、SPIFFE、SPIRE和Thanos,Cloud Native Buildpacks是一个中立的基金会的一部分,该基金会与它的技术趣味保持一致,而更大的Linux基金会则提供了治理、市场反对和社区服务。每个CNCF我的项目都有一个相干的成熟度级别:沙箱、孵化或毕业级。无关每个等级的成熟度要求的更多信息,请参阅CNCF毕业规范。 要理解更多对于云原生Buildpacks的信息,请拜访buildpacks.io。我的项目维护者将在2020年北美KubeCon + CloudNativeCon虚构大会期间提供办公时间,答复无关该项目标任何问题。请务必在美国东部工夫11月20日星期五下午4:00注册并退出。 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

November 19, 2020 · 1 min · jiezi

关于cncf:Envoy-Mobile项目加入CNCF

Envoy我的项目文章,作者:Michael Schore 就在一年前,咱们公布了Envoy Mobile的首次开源预览。明天,咱们要分享一些激动人心的音讯:Envoy Mobile正式退出其母我的项目Envoy,成为CNCF的一部分!从一开始,咱们就承诺将Envoy Mobile开发为一个开源我的项目。咱们置信,作为挪动网络的一个模式,它有后劲开翻新的畛域,并且对围绕着Envoy成长起来的充满活力的社区的认可,使开源成为咱们明确的抉择。在过来的一年里,与社区的互动带来了微小的回报,因为咱们曾经从最早的概念验证阶段过渡到试验阶段,而后是生产解决方案,齐全公开。明天是一个重要的里程碑,咱们荣幸地加入了CNCF治理下的我的项目,就像Envoy、Kubernetes、gRPC等。 简史 Envoy我的项目之所以胜利,是因为它为一个由多种语言零碎组成的网络提供了一个独特的根底。部署Envoy意味着在整个机群中实现统一的可察看性、可配置性和可扩展性,而不思考单个服务的任何独特特色。Envoy的被动/被动健康检查模型和最终统一的路由配置,在面对不可预测的网络和软件故障时,提供了稳定性和可靠性。 Envoy Mobile我的项目始于一个问题:为什么咱们将挪动设施与后端基础设施中的节点区别对待?即便企业在这两个平台上运行要害软件,一个被视为外围基础设施,而另一个被视为独立的内部客户端。历史上默认的假如是,这两个组成部分是基本不同的。尽管的确存在差别,但挪动客户端遇到的许多挑战相似于咱们之前应用Envoy在服务器上解决的问题。 对许多组织来说,实现对挪动应用程序运行状况和性能的可见性是一项继续的奋斗。相似地,自定义运行时/动静配置解决方案是大规模部署应用程序的规范。思考到Android和iOS都必须同时反对,共享代码很艰难。此外,与后端基础设施相比,挪动客户端所面临的网络条件更不可预测,更容易呈现故障。咱们在后盾利用Envoy作为这些问题的独特解决方案。Envoy能成为挪动客户端的解决方案吗?咱们决定:“相对可能。”,Envoy Mobile呈现了。 挪动网络库 “Envoy曾经成为利用网络的通用可编程数据立体。咱们很快乐看到Envoy Mobile将Envoy的益处带到挪动生态系统中。咱们当初有能力向客户端应用程序提供可编程性,比方反对真正的端到端云原生服务的挪动应用程序。”-Anna Berenberg,谷歌云卓越工程师 在咱们开始这个旅程之前,咱们花了一些工夫来评估其余的可能性。有许多功能强大的挪动网络库,它们都有弱小的追随者。然而Envoy提供的一个要害区别是,它为分布式应用程序中的所有网络提供了一个公共层。最终,咱们得出结论,咱们在挪动客户端获得同样劣势的惟一路径就是应用Envoy自身。 当然,Envoy并不是设计成过程内库的,更不用说在挪动应用程序中运行了。然而它的许多设计决策使它可能十分好地适应这个新指标--从它的单线程代码库到它的缓冲区治理模型。咱们将在当前的文章中分享更多对于这方面的内容,但要深刻理解咱们是如何将Envoy变成一个库而不是一个服务器,请参阅咱们去年在KubeCon和EnvoyCon上的演讲(Envoy Mobile in Depth: From Server to Multi-platform Library - Jose Nino & Michael Schore, Lyft)。Envoy的古代架构和设计为证实咱们的想法的可行性提供了一个显著的开始。 开源 当咱们第一次公布Envoy Mobile仓库时,这个库仅仅是一个工作原型。Envoy运行并能够在iOS和Android上解决申请。咱们有个雄心勃勃的路线图,然而咱们并没有闭门执行我的项目,并且只有当咱们有一个生产就绪的解决方案时才分享它,咱们谨慎地决定不仅凋谢咱们的初始我的项目,而且凋谢路线图自身。咱们置信,Envoy Mobile背地的理念有可能从根本上扭转企业对待挪动客户端和物联网设施的形式,并与之互动。分享这个愿景和这个我的项目最早的版本,局部是咱们对这个信念的承诺,局部是对社区的承诺,咱们心愿为每个人实现这些益处。 一年过来了,Envoy Mobile被汇编到Lyft应用程序中,并发送咱们的生产流量。该库具备一流的绑定,并反对Swift、Kotlin、Objective-C和Java(Python开发中!)咱们当初曾经领有了一个真正的根底,能够构建将来的挪动网络。 下一步 “Envoy的社区增长和有数的应用案例持续超出我最疯狂的冀望。尽管Envoy对服务器端云原生分布式系统的构建形式有着深远的影响,但挪动客户端和物联网设施与服务器端设施存在雷同的问题,包含可察看性、容错、负载平衡和配置。Envoy Mobile进入CNCF将减速Envoy作为端到端云原生网络平台的采纳,使简单的分布式应用可能更强壮地部署。我太冲动了。”- Matt Klein,Envoy的创造者 有了跨客户端和后端服务的对立根底和公共网络形象,个性能够一次性创立并在任何中央应用。咱们有Envoy Mobile倒退的下一个篇章的雄伟打算。十分简短的亮点包含: 强类型API生成--容许应用IDL(如protocol buffer)定义API,并利用代码生成来打消样板文件和形象传输。通过API/IDL正文,抉择基于策略反对的网络个性--包含缓存、重试、提早API、流、推和优先级。先进的协定反对和网络优化--反对QUIC、HTTP/3、DNS代替、和自定义协定扩大,智能连贯加权和抉择。xDS--利用Envoy的配置发现API,通过与传统网格雷同的管制立体动静配置。要理解更多对于咱们的打算或奉献的机会,咱们的路线图也是开源的! Envoy Mobile退出CNCF的机会恰到好处。这个新的,中立的家园将使咱们更容易与其余组织单干,并承受来自其余组织的奉献。它还将使咱们更严密地与Envoy的开发周期保持一致,容许咱们执行共享的CI测试覆盖率,以及两个我的项目之间更严密集成的上游个性。通过这一步,咱们期待着与CNCF以及你们所有人一起从新定义咱们对客户端到服务器通信的认识。 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

November 18, 2020 · 1 min · jiezi

关于cncf:使用Prometheus和Linkerd建立Kubernetes服务水平目标SLO的指南

客座文章最后由Kevin LeimkuhLer在Buoyant的博客上公布 有了服务网格,SLO就容易多了 在本教程中,你将学习如何应用Prometheus(一个开源工夫序列数据库)和Linkerd(一个开源超轻服务网格)在Kubernetes上轻松创立服务运行状况SLO。你将看到如何应用服务网格解决SLO中最艰难的局部之一:为你想要度量的货色取得统一的度量规范。 但在咱们开始之前,让咱们先深刻理解一下为什么SLO和Kubernetes会携手并进。 Kubernetes和服务网格的一个SLO案例 SLO,或者服务级别指标(service level objective),最近曾经成为形容应用程序可靠性的风行工具。正如谷歌SRE书中所形容的,SLO是应用程序开发人员和SRE团队明确捕捉应用程序危险容忍度的一种办法,通过定义可承受的失败级别,而后依据该决策做出危险vs回报的决策。 对于平台所有者,他们较少关注应用程序,更多关注底层平台,SLO还有另一个用处:它们提供了一种办法,能够理解平台上运行的服务的健康状况,而无需理解任何无关其经营历史的信息。这在Kubernetes中特地有用,在Kubernetes中,你可能在几十个集群中运行数百或数千个服务。你不须要理解每个服务的操作上下文,而能够应用SLO作为取得上下文无关判断的一种办法。(参见SLO vs Kubernetes指标)。 令人高兴的是,在Kubernetes上取得服务运行状况方面的SLO比你设想的要容易得多。这是因为SLO最难的局部之一是取得统一的、对立的度量,而这正是服务网格所做的!例如,Linkerd为你所有的服务提供了一个对立的、统一的黄金度量层--成功率、提早、申请量--并且不须要任何配置。有了Linkerd的指标在手,取得根本的服务运行状况SLO就能够归结为做一些计算。 (当然,服务网格并不是SLO的残缺解决方案,因为它不能捕捉应用程序特定指标之类的货色。但对于常见的服务运行状况度量,如成功率和提早,至多能够通过提取服务网格数据轻松构建服务运行状况SLO。) 让咱们用一个演示用例来入手吧。 用Linkerd和Prometheus计算SLO 在本教程中,咱们将看到如何为在Kubernetes上运行的gRPC服务设置一个滚动窗口的根本成功率SLO。当然,咱们这里应用的技术同样实用于不同类型的指标和SLO。 首先,让咱们回顾一下Linkerd如何捕获它的黄金指标。当Linkerd被增加到服务中时,它会自动记录对服务pod的任何HTTP和gRPC调用。它记录这些调用的响应类和提早,并将它们聚合到Prometheus的一个外部实例中。这个Prometheus实例为Linkerd的仪表板和CLI提供能源,并蕴含所有网格服务的察看黄金指标 因而,为了达到咱们的指标,咱们须要将存储在Linkerd的Prometheus中的成功率指标转换为SLO。 装置:拜访Kubernetes集群并装置Linkerd CLI 让咱们从最根本的开始。咱们假如你有一个运行的Kubernetes集群和一个指向它的kubectl命令。在本节中,咱们将带你实现Linkerd入门指南的简化版,以在这个集群上装置Linkerd和一个演示应用程序。 首先,装置Linkerd CLI: curl -sL https://run.linkerd.io/install | shexport PATH=$PATH:$HOME/.linkerd2/bin(或者,间接从Linkerd发布页面下载。) 验证你的Kubernetes集群可能解决Linkerd;装置Linkerd;并验证装置: linkerd check --prelinkerd install | kubectl apply -f -linkerd check最初,装置咱们将要应用的“Emojivoto”演示应用程序: curl -sL https://run.linkerd.io/emojivoto.yml | linkerd inject - | kubectl apply -f -此时,咱们曾经筹备好取得一些理论的指标了。但首先,让咱们谈谈SLO中最重要的数字:谬误估算(error budge)。 谬误估算 谬误估算能够说是SLO中最重要的局部。但它到底是什么,咱们如何失去它? 让咱们从一个例子开始。假如在过来7天内,你曾经决定你的服务必须有80%的成功率。这是咱们的SLO。咱们能够将这个语句合成为三个根本组件:一个服务水平指示器(SLI),这是咱们的度量;指标,也就是咱们的门槛;还有工夫窗口。在这种状况下: SLI:服务成功率 指标:80% 工夫窗口:7天 这个SLO意味着在7天滚动周期内20%的申请可能会失败,而咱们并不认为这是一个问题。因而,咱们的谬误估算仅仅是掂量咱们在一段时间内“耗费”了20%中的多少。 例如,如果咱们在过来7天内胜利地提供了所有响应的100%,那么咱们的谬误估算将放弃100%—没有任何响应失败。另一方面,如果咱们在过来7天胜利地服务了80%的响应,那么咱们就有0%的谬误估算残余。如果咱们在这段时间内提供了少于80%的胜利回应,咱们的谬误估算就会是负的,咱们就违反了SLO。 谬误估算由下式计算: Error budget = 1-[(1-compliance)/(1-objective)] ...

November 17, 2020 · 1 min · jiezi

关于cncf:2019年CNCF中国云原生调查报告

中国72%的受访者生产中应用Kubernetes 在CNCF,为更好地理解开源和云原生技术的应用,咱们定期考察社区。这是第三次中国云原生考察,以中文进行,以便更深刻地理解中国云原生技术采纳的步调及如何在宏大且一直倒退的社区中赋能开发者并作出改革。本报告基于2018年3月和2018年11月公布的前两份中国报告。 中国云原生考察的重点 49%的受访者在生产中应用容器,另有32%打算这样做。与2018年11月相比,这是一个显着的增长,过后生产中仅20%应用容器。72%的受访者在生产中应用Kubernetes,高于2018年11月的40%。私有云的使用率从2018年11月的51%降落到了36%,取而代之的是应用39%的混合新选项。CNCF我的项目呈指数增长。CNCF现有四个在中国诞生并在该地区更宽泛应用的我的项目:孵化阶段的Dragonfly和KubeEdge,以及刚毕业的Harbor和TiKV。2019年中国云原生考察包含300名受访对象-其中97%来自亚洲,次要是中国。 容器应用 咱们晓得容器曾经扭转了基于云的基础架构,然而在过来的一年中,容器在生产中的应用已成为常态。依据咱们今年初公布的2019寰球云原生考察,84%的受访对象在生产中应用容器,使得容器在寰球范畴内无处不在。 中国考察表明,只管中国的容器应用落后于寰球,但其势头正在加强。在中国考察中,将近一半(49%)的受访对象在生产中应用容器–从2018年3月考察的32%和2018年11月的20%跃升至更高水平。 打算在生产中应用容器的中国会员越来越少-当初32%,2018年3月的考察中为57%,11月为40%。这意味着许多组织已将容器打算付诸实施,而不再处于打算阶段,但仍存在增长空间,心愿持续增长。 Your organization uses containers for 您的组织应用容器为了 …Proof of concept 概念验证Development 开发Test测试Production生产 随着生产中利用的减少,测试环境中容器缩小。约28%的中国考察受访者目前测试中应用容器-与2018年3月的24%相比略有回升,但与2018年11月的考察中的42%相比有所降落。 只管容器带来了惊人的劣势,但也带来了挑战。随着工夫的推移产生了变动,然而复杂性的挑战始终放弃不变。在中国考察中,53%的受访者将复杂性列为最大挑战。相比之下,2018年3月的考察中, 44%受访者认为复杂性是最大挑战,占比最高。2018年11月的考察中28%的受访者,占比排第三。 在挑战方面,安全性排名第二,受访者占比39%。平安首次被列为首要挑战。培训有余和网络并列第三,占比36%,而35%的考察受访者将可靠性和监控性作为部署挑战。 container challenges容器挑战complexity 复杂性security安全性lack of training培训有余networking 网络reliability可靠性monitoring监控service mash服务网络cultural changes w/development team文化扭转w/开发团队scaling deployments based upon the load基于负载的拓展部署difficulty in choosing an orchestration solution很难抉择编排流程解决方案 Kubernetes增长 Kubernetes作为一个容器编排通用平台正在行业中锋芒毕露并在中国的CNCF社区中的采用率也急剧回升。72%的受访者示意在生产中应用Kubernetes-与2018年11月的40%相比有了大幅增长。 因而,评估Kubernetes的人数从42%降至17%。 using in production 生产中应用evaluating 评估 咱们还看到Kubernetes的生产集群在部署范畴两端的增长。大部分中国考察的受访组织应用不到10个集群,然而运行50个以上的集群的组织有所增加。这可能是因为在生产中应用容器的新受访者数量减少,从而减少了集群。 36%的受访者领有2到5个集群,高于2018年11月的25%,一半的受访者应用1到5个集群,70%的受访者应用1到10个。只有13%多的受访者生产中有超过50个集群,而在2018年11月时仅有5%的受访者。 如果您应用Kubernetes,那么您有多少个生产集群? 打包 Helm是打包Kubernetes应用程序最受欢迎的办法,54%的受访者抉择了这种办法 入口 NGINX(54%)是应用最多的Kubernetes入口提供商,其次是HAProxy(18%),F5(16%)和Envoy(15%)。 拆散Kubernetes应用程序 在集群中治理对象是个挑战,然而命名空间通过按组过滤和管制来帮忙治理。71%的受访者用命名空间拆散Kubernetes应用程序。在多个团队中应用Kubernetes的考察对象中,有68%应用命名空间。 监控,日志和跟踪 对于那些应用监控,日志和跟踪解决方案的用户来说,本地运行还是通过近程服务器托管更广泛。46%的受访者应用本地监控工具,而20%的受访者通过近程服务运行。整体上应用日志和跟踪的受访者较少,然而26%的受访者在本地运行跟踪,而20%通过近程服务运行跟踪。21%的企业外部运行跟踪工具,另外21%的企业通过近程服务运行。 代码 因为继续集成(CI)和继续交付(CD)的反对,云和容器的弱小性能独特推动了中国的开发和部署速度。咱们的考察通过开发者将代码检入存储库的频率来量化开发速度。35%的受访对象每天屡次检入代码。43%的每周几次检入代码,16%的每月几次检入代码。 您检入代码的频率是?A few times a month 一月几次Multiple times a day一天几次A few times a week 一周几次 ...

November 13, 2020 · 2 min · jiezi

关于cncf:2011CNCF欢迎新沙箱项目

cert-manager针对Kubernetes的x509证书治理https://cert-manager.io/https://github.com/jetstack/c... Cloud Development Kit for Kubernetes (cdk8s)应用相熟的语言定义Kubernetes应用程序和组件https://cdk8s.io/https://github.com/awslabs/cdk8s KyvernoKubernetes原生策略管理https://kyverno.io/https://github.com/kyverno/ky... OpenKruise用于工作负载治理的Kubernetes自动化套件https://openkruise.io/https://github.com/openkruise... Pravega流作为一种新的软件定义的存储原语https://pravega.io/https://github.com/pravega/pr... SchemaHero 现代化的数据库模式迁徙https://schemahero.io/https://github.com/schemahero... Tinkerbell一个灵便的裸金属部署引擎https://tinkerbell.org/https://github.com/tinkerbell/ 点击达到沙箱网站。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

November 11, 2020 · 1 min · jiezi

关于cncf:Contour-1100发布支持Envoy-xDS-v3自定义日志与ARM

作者:Steve Sloka Contour持续增加新个性,以帮忙你更好地治理集群中的入口操作。咱们最新的个性版本,Contour 1.10.0,当初蕴含了对Envoy xDS v3的反对,对以后v2版本的反对将在2021年初勾销。Contour还减少了对多架构镜像的反对,容许在多个平台上部署,并扩大了对自定义JSON日志字段的反对。 Envoy xDS v3反对 Contour是Envoy的xDS控制器,它通过gRPC连贯向Envoy提供侦听器、路由、集群、端点和其余信息的动静更新。这些对象在xDS API中定义并进行版本控制。目前,Contour反对v2 xDS API。v2版本曾经被弃用,并且在2020年第一季度完结后不再承受新个性。此外,2021年第一季度,Envoy将不再应用v2 API。 Envoy中的一个要害组件,它与疏导配置文件中应用的xDS版本无关。这个文件由initContainer提供给Envoy,形容了在与Contour通信时要应用的传输和资源API版本。在Contour v1.9.0和晚期版本中,这个疏导配置没有指定版本,而后默认为v2。 在v1.10.0中新增了一个--xds-resource-version标记,能够在contour bootstrap命令中配置它,将配置文件中的疏导xDS资源和传输版本更改为v3,然而,v1.10.0版本的默认版本依然是v2。 这意味着用户能够将他们的Envoy实例从v2降级到v3,而不会失落任何连贯,因为Contour将同时提供v2和v3两个版本。 然而,须要留神的是,这是惟一反对这两个资源版本的版本。瞻望Contour v1.11.0,Contour将齐全删除v2反对,疏导配置将默认应用v3。须要执行就地降级的用户应该利用Contour v1.10.0作为进入新的xDS v3资源版本的跳板。 无关更多信息,请拜访降级指南以及从v2-\>v3迁徙指南。 自定义日志记录 随着越来越多的用户应用Contour作为他们的入口控制器(Ingress Controller),咱们发现他们须要更多的信息来解决他们的需要。其中一个申请就是在Envoy拜访日志中反对自定义JSON字段。 当初,Contour v1.10.0减少了对用户自定义拜访日志的反对。你能够在结构化JSON日志指南中理解到该个性的更多细节以及如何配置它。 感激@mike1808、@KauzClay和@XanderStrike设计和实现这个个性! 多架构镜像 与新的拜访日志性能相似,用户也要求更多的架构来运行Contour。Envoy从v1.16.0开始反对基于ARM的架构,而Contour也提供了多架构的构建,容许Contour和Envoy运行在非基于amd64的零碎上。 鸣谢社区! 咱们非常感谢所有社区的奉献,使Contour变得更好!对于版本1.10,特别感谢以下贡献者: @narahari92@yoitsro@mike1808@astrieanna@kauana@Glyphack@danehans@KauzClay@XanderStrike退出Contour社区吧! 退出Contour社区会议在Twitter上取得更新(@projectcontour)在Kubernetes Slack的#contour与咱们聊天在GitHub上与咱们合作点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

November 10, 2020 · 1 min · jiezi

关于cncf:KEDA宣布20版本|自动伸缩应用程序到下一个水平

阿里云应用了KEDA进行主动伸缩: “Alibaba’s Enterprise Distributed Application Service (EDAS) which is built with KubeVela project adopts KEDA as the implementation for its auto-scaling trait (see: trait system of Open Application Model) from mid of 2020. In Alibaba, EDAS has served more than 1000+ applications from both Alibaba Cloud’s customers and internal scenarios. EDAS’s KEDA based auto-scaling trait uses Alibaba’s ARMS (i.e. Application Real-Time Monitoring Service) as the trigger by default, and it’s also under integration with AIOps system of EDAS for advanced scenarios such as capacity diagnose based auto-scaling.” ...

November 5, 2020 · 2 min · jiezi

关于cncf:使用NATS的Synadia自适应边缘架构介绍

概述 在Synadia,咱们的指标是对立所有云、边缘和物联网通信。咱们疏导公司从当初开始,高效地运行平安和弹性的古代分布式通信零碎,并利用NATS.io我的项目,使他们通往那里。Derek Collison,NATS的创造者,创立了Synadia,负责NATS我的项目。 咱们看到用户以几个形式部署NATS--单个集群K8s部署、云中的NATS服务器集群、VM上或裸机上。随着公司的倒退,咱们看到许多多地区的部署在天文上分散开来,在数据中心,在云提供商之间,或者当初更常见的是混合部署。 最近,咱们看到呈现了一种模式,即由一组应用程序从边缘节点服务和接收数据。通常有来自边缘的遥测,有时边缘节点有他们本人的命令和管制服务和拜访本地数据。这并不常见--这是物联网模式下的联结边缘计算。 企业将计算推向了边缘时,真正乏味的是,咱们看到这种模式利用到许多不同的垂直市场。通常,用户将不同的技术与不同的平安域联合在一起,必然导致系统软弱、不平安且保护老本昂扬。应用咱们所谓的自适应边缘架构(Adaptive Edge Architecture)--一种笼罩NATS多租户平安模型的灵便部署拓扑--能够很好地防止这个问题。 平安 在NATS 2.0中,咱们围绕操作员(Operator)、帐户(Account)和用户(User)的概念加强了安全性。操作员是NATS部署的所有者,如公司、云提供商、CDN服务、边缘提供商或挪动运营商。操作员创立帐户--能够把帐户设想成“消息传递的容器”--真正的多租户。帐户可能蕴含代表一组应用程序、区域部署或业务单元的用户。留神,咱们正在走向零信赖,因而在操作员模式中,即便应用帐户和用户的概念,NATS零碎也不会存储或拜访公有NATS密钥。 当NATS客户端连贯时,它的凭证表明它属于一个特定的帐户。它的主题命名空间(它能够在其中发送和接收数据)只存在于它的帐户中。这意味着在默认状况下,数据永远不会穿梭帐户边界,客户端只能与同一帐户中的其余客户端间接通信,即便应用在其余帐户中发现的雷同主题。 然而,帐户能够与其余帐户一起导出和导入流(想想遥测)或服务(想想RPC),容许平安地共享特定数据和映射主题,无效地从应用程序主题命名空间拆散数据拜访。在部署中,流和服务能够对所有帐户进行公开导入,也能够为恪守最严格的安全策略而进行窃密。因为安全性的确与连贯拆散,帐户可能只存在于服务器的一个子集上,以创立数据竖井。 部署拓扑 除了NATS 2.0中的安全性之外,咱们还心愿解决轻松牢靠地将不同区域的NATS服务器集群连贯在一起的问题。在趣味流传方面,对于大多数用例来说,一个散布在不同区域的大型NATS集群过于通信量大,因而咱们创立了超级集群的概念,它通过网关连贯将许多集群连贯在一起。这种基于样条(spline)的架构具备多个连贯的弹性,同时对趣味流传进行智能解决,从而主动缩小冗余。这对于以当今的数据速率进行长距离传输或带宽较低的连贯来说是必要的优化。 在执行此操作时,Derek(NATS的创造者)提出了叶节点的概念,其中NATS服务器能够连贯到群集,并且比服务器更像是客户端,从而扩大了群集,从而有可能桥接平安域。同时在本地应用程序之间提供最佳提早。当与近程集群断开连接时,它依然能够工作。过后,咱们不能确切地确定叶子节点将如何被接管,但有一些迹象表明它可能是一个休眠节点。 事实证明,这比咱们设想的要弱小得多。而后,当与NATS 2.0安全性相结合时,咱们最终失去了个真正优雅的解决方案,能够应用边缘计算解决大规模联邦部署--自适应边缘架构。 应用NATS的Synadia自适应边缘架构 这是相当简略的。在后端建设许多NATS集群—-在数据中心、云、裸金属或混合—-这对NATS无关紧要。而后通过叶节点将连通性扩大到边缘,创立了一个宏大的数据连通性立体。这是第一层,就像数据的电网。安全性是下一个问题--将NATS安全性看作是一种开关,它准确地确定哪些数据能够流到哪里,应用程序连贯受到NATS帐户的限度,并且通过导入和导出流和服务来共享数据。将此部署模型与NATS多租户个性相结合,你就能够创立一个既可治理又平安的真正大型零碎。 因为帐户蕴含本人的主题命名空间,所以每个边缘部署看起来都完全相同,不会呈现主题抵触。不再须要有会议决定如何分层设置命名空间!它是隔离的,这意味着你的应用程序很容易加强,并且不会影响零碎的其余局部。导出和导入能够容许任何容许的NATS客户端平安地、无缝地与部署中的任何其余容许的NATS客户端交互。因为NATS服务器存在于边缘,所以当与网络拆散时,你的近程服务依然能够自主操作。 这还能够将基于SaaS的零碎与私人领有和经营的零碎混合匹配。咱们在NGS中看到了这种模式的回升趋势,用户运行叶节点用于本地装置,而后近程连贯以实现安全可靠的寰球通信。 无意的数据竖井 尽管你将领有残缺的连贯,但数据流应该受到限制,有时应该隔离在无限拜访的竖井中。人们可能会为了可管理性而这样做--在边缘汇集大量的传感器数据,而后应用AI以流的形式提供有意义的上下文。或者,你可能须要执行一些策略,比方在一组服务器中保留无关运行状况的医疗数据,以满足GDPR听从性。帐户设置将保证数据永远不会来到一个地位,除非它应该。 简略的客户端 不论安全性和部署拓扑如何,NATS客户端依然很简略,因为它们只关怀连贯、公布和/或接收数据。不保护任何服务器状态,容许你随时伸缩或更改NATS服务器部署,而不影响客户端,无效地验证你的技术解决方案的将来性。 示例用例--工业4.0 让咱们看一个制作用例。随着制造业持续向工业4.0过渡,与制作过程相干的元数据比以往任何时候都更有价值。IIoT的采纳发明了大量的数据。机器的温度稳定可用于预测故障剖析,而零部件的元数据可能须要存储数十年(例如航空)。其中大部分须要以极低的提早来解决,在这种状况下,向云中的后端或近程数据中心发送是站不住脚的。 工厂 咱们有一条工厂生产线,有设施、传感器、品质管制,有AR帮助工程师,有AI监督和智能聚合数据。顺便说一句,NATS在Unity平台上工作得十分好,后者正在利用于工业4.0。 总部、工厂和配送核心 从总体上看,咱们有总部、配送核心和工厂。留神,所有这些都是连贯的,数据通过NATS替换。尽管没有图,但数据的流和可用性是由帐户决定的。这只是一个简略的图表;能够应用自适应边缘架构提供供应链,以提供优化物流、库存等的服务。 利用于垂直市场 对于作者 我是Colin Sullivan,Synadia产品经理,也是NATS的长期维护者。 在Synadia,咱们每天都能看到新的用例,很快乐可能帮忙NATS用户。咱们投资于NATS,并乐于看到它帮忙解决日益广泛而又艰难的问题。如果你有趣味理解更多信息,请通过info@synadia.com分割咱们或通过colin@synadia.com分割我。 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

November 4, 2020 · 1 min · jiezi

关于cncf:Kubernetes-119流量入口和路由的未来

客座文章最后由eficode参谋Michael Vittrup Larsen在eficode博客上发表 Kubernetes社区正在放弃Ingress,并将从新设计流量路由,以更好地适应多团队和多角色。 Kubernetes 1.19和Ingress资源 在Kubernetes 1.19中,定义HTTP流量在Kubernetes中如何进入和路由的Ingress资源从beta降级为GA。当Ingress资源处于测试状态时,在引入主机名通配符的Kubernetes 1.18中能够看到些流动。我认为Kubernetes的流量接入和路由的将来倒退将应用其余资源类型。咱们在Kubernetes 1.18中看到的流动,以及在1.19中将Ingress降级到GA/v1,能够看作是在确定Ingress资源的设计之前解决最紧迫的问题。 固定的订正资源将只接管谬误修复和向后兼容的批改,所以未来咱们不太可能看到对Ingress资源的重大更改。在beta状态中破费的工夫缩短了,加上Ingress资源的宽泛应用,也意味着它曾经长时间处于defacto-GA状态,在不毁坏向后兼容性的状况下无奈显著改良。咱们能够称之为“修复,(遗记)并向前看”--锁定设计,只解决后退中的bug,并为改良的设计创立新的资源类型。 Ingress资源的问题是,如果没有从以后设计的重大转变,设计就不是真正的“可进化的”。这意味着,如果咱们想要翻新从而显著扭转Ingress资源,咱们将须要创立种新的资源类型。从Kubernetes service API SIG和Gateway API正在进行的工作中,这一点也很显著。 那么,Ingress资源的次要问题是什么?咱们应该冀望从Ingress资源类型的版本2中失去什么模型?Well,持续读上来…… Kubernetes Ingress资源 Kubernetes中的Ingress资源是公开基于HTTP的服务的正式形式。在过来的18个Kubernetes版本中,Ingress资源作为beta资源过着不确定的生存--是的,自从Kubernetes v1.1以来!作为beta API的工夫很长,以及用于扩大和批改Ingress资源行为的特定于Ingress控件的正文的激增,都阐明了Ingress资源的设计不如其余Kubernetes资源好。在下一节中,咱们将形容Ingress资源的可伸缩性问题和解决办法。 角色拆散 Ingress资源的一个问题是它将以下内容组合成一个资源定义: Identity-域名Authentication-TLS证书Routing-将哪些URL门路路由到哪些Kubernetes服务如果一个人治理个略微简单的站点,例如一个由多个独立团队治理的组件,咱们在现实状况下心愿将上述问题委托给不同的角色。例如: 平安/基础设施治理-治理域名和TLS证书站点治理-治理路由到由单个团队治理的组件/应用程序应用程序团队-治理路由到不同的应用程序版本,金丝雀(灰度公布),蓝/绿版本,等等。假如咱们有个站点example.com,它由两个组件组成,登录(login)和主站点(mainsite),每个组件由一个独自的团队治理。咱们能够演示不同的角色和流量路由,如下图所示。蓝框阐明一个角色,红框阐明一个流量路由定义。路由定义应用URL门路或HTTP头作为选择器。 这里的“平安管理员”角色通过域名和TLS证书(可能还包含DNS,这超出了本形容的范畴)治理站点标识。域名和TLS证书很少更改,对这个角色的拜访应该受到严格限度。如果应用Let's Encrypt来治理证书,那么拜访受限还意味着站点管理员或应用程序团队不能触发证书续订。这升高了达到Let's Encrypt证书速率限度的可能性,也就是说,不存在因为速率限度而无奈取得TLS证书的危险。 “站点治理”角色定义了顶级的路由,例如路由到咱们两个团队治理的两个应用程序。只有当咱们从站点增加或删除应用程序时,此路由才会扭转。 “应用程序团队”治理每个应用程序的子组件,包含测试部署。每个应用程序团队能够定义路由,例如测试实例来实现金丝雀,蓝/绿测试,等等。 在Kubernetes中,Ingress资源在单个对象中定义域名、TLS证书和到Kubernetes服务的路由。这样做的后果是,应用程序团队想要做的,例如金丝雀测试,将须要拜访批改整个站点的全局Ingress资源。这对安全性和稳定性都有影响--最显著的是,在Ingress资源中引入语法错误将导致整个站点不可拜访。 Kubernetes API SIG在Gateway API上的工作旨在反对这种多角色设置。尽管网关API的实现还不存在,但该API在很大水平上受到了Contour ingress控制器的API的启发。在上面的局部中,咱们将向你展现如何应用Contour实现这个多角色设置,从而理解Kubernetes中可能呈现的将来网关API。 应用Contour和Envoy实现多角色设置 Envoy是一个CNCF的毕业级代理我的项目,而Contour是一个建设在Envoy之上的Ingress控制器。Contour通过HTTPProxy对象扩大了Ingress资源的概念,容许将一个HTTPProxy对象委托给另一个HTTPProxy对象。换句话说,它容许咱们应用多个Kubernetes命名空间中的多个HTTPProxy资源来定义流量路由,并且能够拜访受不同角色限度的命名空间。如下所示。 如果没有些YAML,对于Kubernetes的形容是不残缺的,因而让咱们查看实现下面的YAML。首先是定义站点标识的顶级HTTPProxy: apiVersion: projectcontour.io/v1kind: HTTPProxymetadata: name: example-com-root namespace: security-admin-onlyspec: virtualhost: fqdn: example.com tls: secretName: example-com-cert includes: - name: site-fanout namespace: site-admin-only在security-admin-only命名空间中的example-com-root HTTPProxy资源通过域名和TLS证书定义了站点标识,并委托进一步路由到site-admin-only命名空间中的site-fanout HTTPProxy资源: apiVersion: projectcontour.io/v1kind: HTTPProxymetadata: name: site-fanout namespace: site-admin-onlyspec: includes: - name: login namespace: login conditions: - prefix: /login - name: mainsite namespace: mainsite conditions: - prefix: /mainsitesite-fanout HTTPProxy资源定义了/login门路下的任何内容的路由到login命名空间中的login HTTPProxy资源。治理登录应用程序的团队有login命名空间的齐全拜访权,因而能够创立以下HTTPProxy资源来路由到他们也管制的Kubernetes服务: ...

October 30, 2020 · 1 min · jiezi

关于cncf:准备好了DevSecCostOps

作者:Janisa Anandamohan Spotify是如何在短短几个月内节俭数百万云服务老本的?咱们将老本优化作为日常开发过程的一部分。咱们最新开源的Cost Insights插件使得团队的云老本能够在Backstage看到,并且能够操作。所以工程师们能够看到他们应用云的影响(在产品和资源层面),并在任何有意义的时候进行优化。通过从头开始治理云计算成本,你能够做出更理智的决策,从而在不浪费资源的状况下持续疾速构建和扩大。 咱们是在把工程师变成会计吗?不,咱们只是让工程师在他们感觉天然的中央做他们最善于的事:在Backstage。 为什么要把老本管理工具交给工程师? 工程师在理解特定个性、产品或服务为什么应用云资源方面最理解。因而,他们最能了解老本如何影响正在进行的开发(反之亦然)。 如果从云基础设施的万尺高度进行自顶向下的老本治理,那么你所做的决策很可能与产品无关,尤其是在较大的组织中。设定一个宽泛的老本削减指标,可能会产生意想不到的结果--以就义经济增长或试验为代价削减开销。 接地情报,数据驱动的解决方案 咱们在Spotify的假如是,如果你把收入数据带入工程师的日常开发工作流程,他们天然会寻找老本优化,就像他们寻找任何其余优化一样。老本优化将会更加高效和无效,因为决策是接地进行。 问题是,大多数云平台没有提供足够细粒度的老本数据来做出这些决策。而且你的组织越大(比方像Spotify这样有2000个微服务和4000个数据管道的大公司),你就越不能把这些大而含糊的数字归到正确的团队身上,更不用说一个产品或外部服务了。 这就是老本洞察(Cost Insights)的作用。在组织结构图上,老本治理和产品开发不是离开的部门,Backstage是把它们联合在一起的--工程师们通过具体和具体的档次来分割和回应。 如何理智破费 仅仅让老本浮现是不够的。要想有用,这些数字必须是相干的、可关联的和可操作的。换句话说,不仅仅是老本信息,还有洞察力。该插件有几种办法能够将来自云提供商的数据放在更有用的上下文中。 应用业务指标来评估老本 老本洞察会让你一眼就看出趋势,还能够让你比拟每个季度的老本。更重要的是,你还能够依据你最关怀的业务指标来评估老本。在上面的例子中,第一个屏幕中显示的向上的斜率是否值得放心?兴许不是--如果你切换视图,你会看到每天均匀用户的破费(daily average user,DAU)实际上在降落。这正是你想看到的。 (留神:屏幕是例子;它们没有显示实在的数据。) 用可关联的、真实世界的比拟来阐明老本 除了金额,老本洞察容许团队可视化并将超支老本转换为更相干的术语。在上面的例子中,咱们将虚拟机实例老本的增长(100%的增长)等同于开发人员所破费的工夫(大概1个工程师)。咱们在插件中应用了这个比拟,因为咱们发现它与咱们本人的工程师产生了共鸣--为减少收入提供了一个有用的视角。你能够配置“工程师的老本”对你的组织意味着什么。或者,工程师们能够在他们本人的比拟中构建--咖啡、碳弥补额度、电动奢华汽车--任何让老本对他们来说更加无形的货色。 (留神:屏幕是例子;它们没有显示实在的数据。) 把收入与特定的产品和资源分割起来 老本数据越具体,就越相干,越可操作,越有帮忙。老本洞察容许你以一种对你的工程师有意义的形式将老本归因于产品和资源。例如,这里咱们看到了按单个流水线细分的数据处理老本。这容许你的团队更准确地优化指标。 (留神:屏幕是例子;它们没有显示实在的数据。) 在不升高开发速度的状况下降低成本 当波及到削减老本时,咱们想要避免适度优化。增长和老本能够并行不悖。窍门在于晓得本人什么时候失去了均衡,须要解决。咱们的产品会在收入大幅减少的时候强调老本,所以工程师们只有在必要的时候才会思考老本,而不会分心于他们设定的指标和优先事项。 而后,工程师能够本人确定,与节俭的老本相比,在优化上投入的工夫是否有价值。老本洞察将决定权交给咱们的工程师,让他们抉择何时关注增长,何时关注老本。与以往一样,控制权依然属于咱们的开发人员,咱们认为这是它的归属。 开始应用 你能够从明天开始在GitHub上应用Cost Insights插件。咱们提供了一个示例客户机,其中蕴含预期格局的静态数据。CostInsightsApi应该与云账单后端进行通信,后者将从云提供商收集的账单数据聚合在一起。 以后公布的老本洞察包含: 每日老本图表,按团队或帐单帐户与可配置业务指标(包含针对日常流动用户的选项)的老本比拟洞察面板--可为你的公司应用的云产品配置老本揭示和倡议可抉择的工夫周期为月与月或季度与季度的比拟将老本增长转化为“均匀工程师老本”,以帮忙优化衡量决策咱们心愿帮忙其余公司将云计算成本转化为一种可关联的形式,以便他们的工程师更好地了解云计算的影响,并精确地确定优化的机会。 如果你对咱们辨认的问题感兴趣,你能够在“cost-insights”标签下的问题列表中找到它们。 筹备好DevSecCostOpsPlus了(以及之后的其它) 有DevOps,有DevSecOps,还有Backstage:所有基础设施的前端。从构建、测试、部署到监控和平安--Backstage帮忙你治理整个技术组织,并为工程师提供无缝的开发体验,从端到端。当初还扩大到了云基础设施和工具的老本治理。高兴地构建和高兴地优化。 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

October 23, 2020 · 1 min · jiezi

关于cncf:追踪指标日志于一身的OpenTelemetry发布追踪规范RC版本-GA计划

作者:Morgan McLean 正如咱们之前布告中所探讨,咱们正在致力构建OpenTelemetry的第一个GA版本。自从3月份beta版以来,OpenTelemetry曾经解决了2640个github问题,合并了5721个PR,使其成为第二大沉闷的CNCF我的项目。明天是这个过程中的另一个里程碑,追踪标准的解冻和公布第一个候选(release candidate,RC)版本。 追踪标准RC版本 追踪标准当初解冻,并且是一个RC版本。OpenTelemetry的API和SDK有一个稳固的追踪标准来构建本人的RC版本。这意味着: 实现追踪标准的API、SDK和Collector(收集器)的RC版本将在将来几周内呈现。从当初到最终的GA标准之间,不容许任何毁坏追踪标准的更改,除了RC期间发现的任何重大(P1)问题。咱们不冀望这些呈现,但RC期间的目标是为了让咱们验证一个值得GA的标准。RC期间容许一些不破坏性的扭转。其中大多数是对现有行为的廓清或简略的编辑更新。标准的RC局部包含所有与追踪相干的依赖项,特地是以下局部:追踪(Trace)、行李(Baggage)、资源(Resource)、上下文流传(Context Propagation)、环境变量(Environment Variables)和导出器(用于追踪的Exporters)。你能够在我的项目状态矩阵中查看每个OpenTelemetry组件的实现进度。 接下来是什么呢? 实现追踪标准的RC版本,是OpenTelemetry在3月份公布beta以来的首要任务。实现这些工作后,咱们当初将重点,转移到RC跟踪API、SDK、收集器和主动仪表(auto instrumentation)组件的实现,以及生成指标标准的RC版本。 RC追踪的实现 大多数OpenTelemetry的API和SDK曾经靠近实现RC追踪实现,咱们预计第一波将在将来两周内公布。心愿提供工具(针对各种web框架、存储客户端等)的贡献者,能够在RC API公布后开始构建。尽管在RC应用和测试过程中发现的问题可能会导致API的扭转(这些组件将有多个pre-GA的RC版本),但这些将受到极大的限度。 SDK可能会有两波RC里程碑。第一个将蕴含来自标准的追踪和上下文流传局部的性能,第二个将蕴含针对行李、导出器、资源和环境变量的RC实现。 指标 在追踪RC组件公布的同时,咱们将对追踪的关注转到指标标准。从这周开始,咱们将优先思考与指标标准相干的变更。之后,API、SDK、收集器和其余组件将公布带有RC品质的追踪和指标性能的版本。 生产和GA的筹备工作 当指标标准、SDK、收集器和其余组件达到RC版本状态,咱们将专一于生产工作,如编写文档、GA后的版本策略、构建额定的自动化测试等等。当咱们对每个组件的利用停顿和利用反馈感到称心,咱们将发表它们的GA版本。 整体时间表 标准中的追踪局部达到了RC的品质并且解冻了(这是明天的布告)组件(API、SDK、收集器、主动仪表等)公布具备RC品质追踪性能的RC版本规格的指标局部达到RC品质,并且解冻组件公布带有RC品质追踪和指标性能的RC版本当咱们对指标 + 追踪的RC版本感到称心时,OpenTelemetry会GA日志进入beta版,而后公布RC标准,每个组件中紧接着是RC品质的日志性能,而后是日志的GA在接下来的几周中,评估了指标标准的工作之后,咱们将对GA公布时间表有更好的了解。 关注某一种语言的停顿 除了我的项目状态矩阵,每个组件的实现都有本人的github我的项目来关注进度,例如JavaScript、Java、Go、Python、.NET和Java auto instrumentation。 FAQ 我想在生产服务上应用OpenTelemetry;明天的布告有什么影响? 带有RC品质追踪反对的SDK将在几周前面世。不倡议将RC版本用于要害的生产服务,然而它们是有实用功能的,旨在提供与行将到来的GA对应版本兼容的API。 我想为OpenTelemetry编写仪器;明天的布告有什么影响? 带有RC品质追踪反对的API将很快面世(在SDK之前)。你能够绑定这些来生成跟踪,这些跟踪将与OpenTelemetry SDK或OpenTelemetry API的任何其余实现对接。 OpenTelemetry什么时候会提供OpenCensus和OpenTracing的代替? 目前,桥接API的工作正在进行中,它容许OpenTelemetry SDK无缝替换OpenCensus库或OpenTracing实现。尽管该性能的交付日期与OpenTelemetry的GA指标无关,但咱们心愿它能在每个API + SDK的RC版本和GA里程碑之间提供。 总结 对于OpenTelemetry社区来说,生成标准的RC版本是一个重要的里程碑,咱们的贡献者为此付出了微小的致力。咱们要感激参加此版本的每个人和每个组织,并意识到他们的奉献为我的项目的长期胜利奠定了根底。 组织提供了次要开发反对OpenTelemetry包含(依据提交排名):Splunk、微软、谷歌、Lightstep、Dynatrace、New Relic、Infostellar、Toptal、Red Hat、Shopify、Zillow、Kinvolk、Postmates、Uber、Honeycomb、Out There Labs、NCR、MailChimp、Datadog、Reelevant、大众汽车、Transit、亚马逊(明天发表他们的反对)和蒙特利尔市。在咱们的Dev Stats站点上能够关注奉献组织的残缺列表。咱们感激这些公司对这个我的项目的投资,因为咱们晓得工程工夫是十分低廉的;如此多的公司看到了为OpenTelemetry做奉献的价值,这一事实证明了该我的项目在整个行业的影响力。 如果你还没有退出OpenTelemetry社区,但想退出的话,当初就是最佳时机!按周提交量和累积提交量计算,OpenTelemetry目前位居CNCF前三名,不论你对我的项目的提交程度(哈!),都欢送你的奉献。如果你对某个特定畛域感兴趣(例如,Python API + SDK),最好的参加形式是加入相干的每周SIG会议或与Gitter上的其余贡献者进行交互。 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

October 22, 2020 · 1 min · jiezi

关于cncf:GitHub给Helm的5岁礼物

五年前,在Deis(现已被微软收买)的黑客马拉松中,Helm诞生了。 commit ecad6e2ef9523a0218864ec552bbfc724f0b9d3dAuthor: Matt Butcher <mbutcher@engineyard.com> Date:   Mon Oct 19 17:43:26 2015 -0600 initial add 这个提交能够在helm-classic Git仓库中找到,那是Helm v1的代码所在。这是最后的Helm,与Deployment Manager合并到Kubernetes之前。这就是所有开始的中央。 从第一天开始,Helm我的项目就依赖GitHub进行源代码管制、拉申请治理和问题跟踪。作为一个毕业的CNCF我的项目,Helm组织当初治理着几十个GitHub仓库。 但在托管chart方面,咱们将它们存储在托管在谷歌云上的对象存储桶中。这一历史性的决定反映了过后谷歌是Helm的次要贡献者之一。 最近,谷歌反对官网Helm chart仓库的时代曾经完结。咱们非常感谢谷歌在过来的几年里托管了Helm chart仓库。然而这给了咱们一个机会,来进一步整合咱们的chart开发流水线和GitHub。 所以在明天的生日庆典上,咱们要发表Helm stable和incubator的chart仓库,将会间接托管在GitHub。此外,GitHub Actions将为chart公布提供流水线性能。多亏了GitHub的超快网络,chart下载比以往任何时候都快! 咱们在GitHub市场上公布了官网的Helm GitHub Actions。查看Helm Chart Releaser理解怎么在GitHub托管Helm charts。 尽管Helm 2曾经完结了反对,咱们也将官网的Tiller Docker镜像移到了GitHub的容器注册核心。 咱们非常感谢GitHub的工具,以及他们对各种规模的开源我的项目的反对。 Helm,生日快乐! Matt Butcher和Matt Farina@technosophos & @mattfarina 点击浏览网站原文。

October 20, 2020 · 1 min · jiezi

关于cncf:克服清理容器镜像的挑战

客座文章作者:Alexey Igrychevm,Flant的软件工程师。最后在Flant博客发表。 解决交付到Kubernetes的古代云原生应用程序CI/CD流水线时,在容器注册表(container registry)驻留大量镜像会成为一个显著的问题。如果你不想让注册表超载(并为无用的占用空间买单),那么你须要理解哪些镜像将不再应用。 找到它们的规范是什么?为什么注册表基本不能意识到它们?这里是咱们了解和以一个广泛的形式解决这个问题的旅程。尽管咱们的解决方案的实际局部是在一个特定的开放源码工具(werf)中展现,然而同样的办法也能够利用到你本人的案例和工具中。 介绍 随着工夫的推移,容器注册表中的镜像数量会大幅增长,这会占用越来越多的空间,并让你付出微小的代价。为了标准、限度或维持注册表空间可承受的增长速度,你最有可能能够: 对镜像应用固定数量的标记(tag);以某种形式清理镜像。第一种办法只实用于小团队。如果永恒标记(如latest、main、test、boris等)满足开发人员的需要,注册核心的规模就不会增长,你能够在很长一段时间内遗记清理它。这是因为所有过期的镜像最终都将被重写,并且你不用手动清理任何内容(惯例的垃圾收集器会解决任何残留物)。 然而,这种办法重大限度了开发过程,很少在古代应用程序的CI/CD中应用。自动化曾经成为开发过程中不可分割的一部分。它容许你更快地测试、部署和交付令人兴奋的新个性给用户。例如,在每次提交之后,CI流水线会在所有我的项目中主动创立。作为CI流水线的一部分,咱们构建和测试镜像,将其部署到各种Kubernetes环境(层)中进行调试和其余测试。如果一切正常,那么这些更改将达到最终用户。这不再是一个火箭迷信--毕竟,如果你正在浏览这篇文章,你可能也会这样做。 因为调试和实现新性能是同时进行的,而且每天可能有多个版本,因而开发过程波及大量提交,这会导致注册表中呈现大量镜像。因而,咱们须要找到一种办法来革除注册表中未应用的(不再相干的)镜像。 然而咱们如何晓得镜像是否相干呢? 镜像相关性的规范 在大多数状况下,相关性的规范如下: 咱们须要的第一种(最显著也是最重要的)镜像类型是目前在Kubernetes中应用的那些。删除这些镜像可能会导致生产停机(例如,可能须要应用这些镜像来创立新的正本),或者在某些环境中打消团队的所有调试工作。(这就是为什么咱们创立了这个Prometheus exporter来监控Kubernetes集群中失落的镜像)。第二种类型(不太显著,但依然很要害且与操作相干)是在以后版本呈现重大问题时执行回滚所需的镜像。例如,在Helm的状况下,这些是在已保留的版本中应用的镜像。(作为一个边注,Helm默认放弃256个版本;这是一个很大的数字,而且你很可能不须要所有这些版本)。毕竟,咱们在开发过程中保留了所有这些不同的版本,因为咱们心愿应用它们进行回滚。另一种类型是对于开发人员的需要:咱们须要所有以某种形式与他们正在进行的流动相干的镜像。例如,如果咱们思考PR,那么放弃链接到上一个提交的镜像是有意义的。通过这种形式,开发人员能够疾速回滚更改并对其进行剖析。最初一种类型包含匹配应用程序特定版本的镜像,即示意最终产品:v1.0.0、20.04.01、sierra等等。注:以上规范是依据咱们与来自不同公司的数十个开发团队单干的教训设计进去的。然而,这些规范可能会因开发过程和应用的基础设施的个性而有所不同(例如,没有应用Kubernetes)。 现有的注册核心以及它们如何满足这些规范 风行的容器注册解决方案都有用于清理镜像的内置策略。它们容许你设置从注册表中删除标记的条件。然而,这些规定通常仅限于指定名称、创立工夫和标记的数量*。 *取决于容器注册表的具体实现。咱们剖析了以下解决方案:Azure CR、Docker Hub、ECR、GCR、GitHub package、GitLab Container Registry、Harbor Registry、JFrog Artifactory、Quay.io(2020年9月)。 这组参数足以抉择合乎第四个条件的镜像,即链接到应用程序特定版本的镜像。然而,你必须做出斗争,以某种形式满足剩下的三个规范--以更严格或更宽松的形式,这取决于你的冀望和经济能力。 例如,你能够批改开发团队中的工作流,以匹配第三种与开发人员相干的镜像类型:引入定制的镜像命名,保护特定的容许列表,或者安顿团队成员之间的外部协定。但最终你必须让它自动化。如果可用的解决方案不够灵便,你将不得不本人设计! 其余两个条件(#1和#2)也会呈现相似的状况:如果不从部署应用程序的内部零碎(在咱们的例子中是Kubernetes)获取数据,就无奈满足这些条件。 Git工作流程阐明 设想一下,这是你残缺的Git工作流程: 在一个通用的开发工作流中提交、分支和公布 在下面的图片中,咱们应用了一个男人的头部图标来标记目前Kubernetes中为任何类型的用户(最终用户、测试人员、管理人员等)部署的所有镜像,或者开发人员正在应用的所有镜像(用于调试和其余起因)。 如果你的清理策略容许你仅通过特定标记的名称来保留镜像,将会产生什么? 应用特定的标记保留镜像 这相对不是咱们想要的。 然而,如果你的策略容许你在特定的工夫框架/最初N次提交前保留镜像,会产生什么呢? 应用特定的工夫框架保留镜像 这个看起来好多了。然而,它远非完满!例如,依然有一些开发人员须要其余可用的镜像(甚至部署到K8s)来进行调试。 总结一下以后的市场状况:在清理镜像时,现有的容器注册解决方案没有提供足够的灵活性。造成这种状况的次要起因是他们无奈与内部世界进行交换。因而,须要这种灵活性的团队被迫“从内部”实现镜像删除,应用Docker Registry API(或特定注册表实现的API)的变通方法。 这就是为什么咱们试图找到一个通用的解决方案,能够为所有团队和所有类型的容器注册自动化镜像清理过程…… 咱们的通用镜像清理办法 但咱们到底为什么须要它呢?问题是,咱们并不是一个特定的开发团队,而是一个业务团队,反对各种类型的团队,帮忙他们全面而理论地解决CI/CD问题。而werf开源工具是这一过程的次要驱动因素。werf的显著个性是它监督CD过程贯通所有阶段:从构建到部署。 将镜像推送到注册表*(在它们被构建之后)是这样一个工具的显著性能之一。因为所有的镜像都必须被存储,因而天然须要以某种形式清理它们。这就是为什么咱们提出的解决这个问题的办法合乎下面列出的所有四个规范。 *注册表用户面临同样的问题,即便注册表自身能够是不同的品种(Docker Registry、GitLab Container Registry,Harbor等)。在咱们的例子中,通用解决方案没有绑定到特定的注册表实现,因为它运行在注册表之外,并且它的行为在所有实现中是雷同的。 尽管咱们在示例中应用了werf,但咱们心愿其余有相似艰难的团队会发现咱们的办法是有用的,并能提供信息。 因而,咱们转向清理机制的内部实现,而不是构建在容器注册表中的实现。咱们的第一步是应用Docker Registry API依据标记的数量和它们的创立日期(下面探讨过)从新实现雷同的根本策略。它们扩大为基于部署在Kubernetes中的镜像的非凡容许列表。为了实现它,咱们应用Kubernetes API循环了所有已部署的资源,并取得了一个关联镜像列表。当咱们有这个列表时,咱们永远不会从注册表中革除这些镜像。 这个相当琐碎的解决方案解决了最要害的问题(规范1),但这仅仅是咱们改良清理机制之旅的开始。下一步--也是更乏味的一步--是咱们决定将公布的镜像链接到Git历史记录中。 标记计划 首先,咱们抉择了一种办法,在最终的镜像中蕴含荡涤所需的所有信息,并引入标记计划。公布镜像时,用户抉择首选的标记选项(git-branch、git-commit或git-tag)并应用相应的值。在CI零碎中,这些值是依据环境变量主动调配的。基本上,最终的镜像链接到一个特定的Git对象(branch/commit/tag),并将清理所需的数据存储在标记中。 这种办法产生了一组策略,容许咱们应用Git作为假相的繁多起源: 当删除Git branch/tag时,注册表中相干的镜像会主动删除。咱们能够通过更改标记计划中的标记数量,和设置自创立关联提交以来的最大天数,来管制链接到Git标记/提交的镜像数量。总的来说,这个实现合乎咱们的须要,但很快咱们就面临了一个新的挑战。应用基于Git的标记计划给咱们带来了几个毛病--足以重新考虑这种办法。(对这些缺点的详细描述超出了本文的范畴;你能够在这里理解更多信息)。因而,转向一种更无效的标记策略,基于内容的标记,导致咱们扭转了清理容器镜像的形式。 新算法 技术上的起因是什么?当应用基于内容的标记策略时,每个标记都能够在Git中链接到屡次提交。因而,当你在清理过程中抉择镜像时,你不能再独自依赖提交。 在咱们新的清理算法中,咱们决定齐全放弃标记计划,而将整个过程建设在元镜像根底上。每个meta-image蕴含: 公布镜像里的提交(也就是说,镜像是否在容器注册表中增加、更改或放弃不变并不重要);对应于所构建的镜像的外部标识符。换句话说,咱们将公布的标记链接到Git中的提交。 最终的配置和个别算法 ...

October 16, 2020 · 1 min · jiezi

关于cncf:使用Argo-CD自动化Kubernetes多集群配置

客座文章最后由DoiT International高级云架构师Mike Sparr在DoiT博客上公布 在我看来,谷歌Anthos企业解决方案中,最酷的方面是Anthos配置管理(Anthos Config Management,ACM)。你能够设置一个Git repo,并将各种集群连贯到它,它们将以GitOps的形式标准化配置,并避免漂移。这对于在不同托管地位治理成千盈百个集群的大型企业尤其重要。 应用Argo CD自动化Kubernetes多集群配置 受到ACM的启发,我想晓得是否能够应用另一种GitOps解决方案,Argo CD,从新创立这种类型的性能。我很快乐与大家分享它的工作原理,当我在Git repo中批改配置文件时,它们无缝地利用到两个集群中。 架构概述 设置 为了简略起见,我在谷歌云的托管Kubernetes服务GKE上,别离在两个区域创立了两个集群,以模仿东和西的场景。当然,你能够在集群的任何中央装置Argo CD,并确保它们可能拜访你的Git repo。 我创立了上面的shell脚本来疏导所有;然而,对于生产用处,我倡议在可能的状况下应用Terraform来治理基础设施。 create-k8s-clusters.sh: #!/usr/bin/env bashexport PROJECT_ID=<YOUR-PROJECT-ID>export AUTH_NETWORK="<YOUR-IP-ADDRESS>/32" # change to your IP or use dotenv of course# enable apisgcloud services enable container.googleapis.com # Kubernetes Engine API# helper functionsset_location () { case $1 in "west") export ZONE="us-west2-b" export REGION="us-west2" ;; "central") export ZONE="us-central1-a" export REGION="us-central1" ;; "east") export ZONE="us-east1-c" export REGION="us-east1" ;; *) echo $"Usage: $0 {west|central|east}" exit 1 esac}install_argo_cd () { echo "Installing Argo CD ..." kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user="$(gcloud config get-value account)" kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml # configure app-of-apps git repo echo "Configuring app-of-apps repo ..." kubectl apply -f app-of-apps.yaml}create_cluster () { CLUSTER_NAME=$1 set_location $CLUSTER_NAME echo "Creating cluster $CLUSTER_NAME in zone $ZONE ..." gcloud beta container --project $PROJECT_ID clusters create "$CLUSTER_NAME" --zone "$ZONE" --no-enable-basic-auth --cluster-version "1.16.9-gke.6" --machine-type "e2-standard-2" --image-type "COS" --disk-type "pd-standard" --disk-size "100" --node-labels location=west --metadata disable-legacy-endpoints=true --scopes "https://www.googleapis.com/auth/compute","https://www.googleapis.com/auth/devstorage.read_write","https://www.googleapis.com/auth/sqlservice.admin","https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/monitoring","https://www.googleapis.com/auth/pubsub","https://www.googleapis.com/auth/servicecontrol","https://www.googleapis.com/auth/service.management.readonly","https://www.googleapis.com/auth/trace.append" --preemptible --num-nodes "1" --enable-stackdriver-kubernetes --enable-ip-alias --network "projects/${PROJECT_ID}/global/networks/default" --subnetwork "projects/${PROJECT_ID}/regions/${REGION}/subnetworks/default" --default-max-pods-per-node "110" --enable-autoscaling --min-nodes "0" --max-nodes "3" --enable-network-policy --enable-master-authorized-networks --master-authorized-networks $AUTH_NETWORK --addons HorizontalPodAutoscaling,HttpLoadBalancing --enable-autoupgrade --enable-autorepair --max-surge-upgrade 1 --max-unavailable-upgrade 1 --labels env=sandbox --enable-vertical-pod-autoscaling --identity-namespace "${PROJECT_ID}.svc.id.goog" --enable-shielded-nodes --shielded-secure-boot --tags "k8s","$1" # authenticate echo "Authenticating kubectl ..." gcloud container clusters get-credentials $CLUSTER_NAME --zone $ZONE # install argo cd echo "Installing Argo CD ..." install_argo_cd echo "Cluster $CLUSTER_NAME created in zone $ZONE"}# create clustersecho "Creating and configuring clusters ..."locations=("west" "east")for loc in ${locations[@]}; do create_cluster $locdone启动集群 ...

October 14, 2020 · 2 min · jiezi

关于cncf:使用kind和GitHub-Actions重建Linkerd的持续集成

客座文章最后由Andrew Seigner在Bouyant博客上发表 这篇文章是Andrew在2020KubeCon欧洲上的演讲。 介绍 在2019年中,Linkerd我的项目的继续集成(CI)花了45分钟,所有的测试都在一个Kubernetes集群上串行化,多小时的备份也很常见。迁徙到Kubernetes in Docker(kind)集群和GitHub Actions使CI不到10分钟,并且能够并行。 这篇文章将具体介绍Linkerd从一个繁多的、长久的Kubernetes集群,到实践上有限的一次性类型集群的CI旅程。这段旅程蕴含了一些对于哪些模式和工具在Linkerd的用例中工作得好(或者不太好)的弯路。 Linkerd是什么? 尽管本文的指标是具体阐明最终用户,如何在CI中高效地测试Kubernetes应用程序,但一些无关Linkerd的背景常识会有所帮忙。Linkerd是一个开源的服务网络,也是一个CNCF成员我的项目。想要更多地理解什么是服务网格,请查看“The Service Mesh: What Every Software Engineer Needs to Know about the World’s Most Over-Hyped Technology”。出于这篇文章的目标,有必要理解一些对于Linkerd的简略事实: 它是用Rust、Go和Javascript编写的。它在Kubernetes中以多部署(deployment)的模式运行。它通过插入到你的pod中的代理来治理你的服务之间的所有流量。Linkerd架构 测试Linkerd 既然Linkerd负责管理Kubernetes集群中的所有流量,那么Linkerd的正确性和性能就十分要害了。为了帮忙确保这一点,咱们的CI包含一系列动态、单元和集成测试,包含Rust、Go和JavaScript测试。这篇文章次要关注集成测试。咱们将介绍这些测试的三个迭代。 测试Linkerd。集成测试能够在左下角的绿色框中看到。 迭代一:在GKE + Travis上运行CI 2019年中,Linkerd的集成测试以作业(job)的形式在Travis上运行。每个作业将构建Linkerd Docker镜像,将其推到gcr.io,并在单个GKE集群上执行集成测试。因为它是一个繁多的Kubernetes集群,所以咱们必须确保每个集成测试在卸载了Linkerd之后本人清理洁净。随着工夫的推移,咱们须要测试在不同配置下装置Linkerd。例如,应用Helm,或者通过降级门路。这意味着咱们当初要装置Linkerd,运行集成测试,每次CI运行要卸载Linkerd五次。整个过程大概花了45分钟。将此与同时呈现的多个拉申请(PR)联合起来,多个小时的备份就变得很常见了。在这一点上,咱们采取了禁用对PR的集成测试的选项,咱们将只在合并时运行它们。当然,从咱们这么做的那一刻起,咱们的次要分支就开始一直地失败集成测试,因为直到合并时才会发现失败。 迭代一:GKE + Travis 对CI需要排优先级 在这一点上,咱们意识到咱们须要后退一步,从新评估咱们对于测试Linkerd的抉择。咱们列出了这张需要优先级列表: 需要1:可重现的构建和测试 Linkerd的集成测试套件包含在Kubernetes集群上装置大量资源,并验证流量是否正确流动。如果咱们在CI中察看到测试失败,最重要的是确保咱们能够在CI和本地开发中轻松地重现该失败。 需要2:浏览构建和测试历史的UI 对于CI零碎来说,浏览测试历史的UI仿佛是不言而喻的,然而当咱们收集需要时,咱们并没有认为任何事件都是天经地义的。咱们思考了查看构建和测试历史的其余办法,包含后台作业和脚本,能够通过电子邮件状态或向PR公布GitHub评论。最终,咱们晓得咱们须要一种简略的办法来共享测试失败的链接,咱们互相ping的时候能够应用指向特定集成测试失败中的特定线路的URL。 需要3:GitHub/PR集成 预先看来,咱们还须要整合咱们目前的PR零碎,GitHub。咱们之前曾经尝试过本人构建这些集成,但咱们心愿可能找到一些开箱即用的货色,而不是给本人更多的保护工作。 需要4:密封建造和测试 许多Linkerd的PR来自社区,通常来自咱们以前从未共事过的人。咱们心愿确保咱们的测试在一个尽可能隔离的环境中运行,因为咱们在咱们花钱保护的硬件上运行不受信赖的代码。咱们还心愿在运行测试之前不须要保护人员对每个PR进行抽查。 需要5:快 测试的周转工夫对于开发人员的生产力总是至关重要的。有时须要五次或更多的尝试来修复一个测试。如果每个测试运行须要一个小时,那么你就损失了将近一天。这一要求被转化为一个打算,以防止在internet上推Docker镜像,反对增量重建,并尽可能在近程机器上构建Linkerd。 需要6:便宜或收费 作为一个开源我的项目,咱们心愿在估算很少或没有估算的状况下满足上述所有需要。 需要7:OSS 作为开源维护者,咱们总是更喜爱应用开源工具。然而请留神,这是咱们最初的要求。咱们会在可能的状况下应用开源工具,然而如果闭源工具满足了所有其余需要,咱们不会主动放弃它。 CI技术评估 思考到需要的优先级,咱们开始评估咱们在这个畛域能够找到的任何工具: k8s发行版:kind、k3d、k3s、GKE、AKS、EKS、DigitalOcean K8s计算:Packet构建:skaffold、Bazel作业管理:GitHub Actions、Prow、Travis、CircleCI、Azure Pipelines、Jenkins X、Gitlab CI、garden.io公布/CD:Kubernetes Release、werf.io 咱们用所有这些工具在不同水平上构建了概念证实。过后,咱们不晓得本人会抉择其中的一种还是五种,并放弃凋谢。(对咱们未抉择到的工具的任何作者:请留神,这并非打击你的任何作品,咱们对技术的抉择在很大水平上取决于咱们的用例,其中包含下面列出的优先需要,无限的工夫和估算,以及咱们对现有工具的相熟水平。) 差点错过:Prow 思考到这一点,我想谈谈一个咱们十分喜爱但最终没有抉择的工具:Prow。 ...

October 9, 2020 · 1 min · jiezi

关于cncf:Kubernetes-Operators-101

客座文章最后由红帽服务可靠性工程师Alexandre Menezes在CloudOps博客上发表 大多数应用程序都须要来自其运行环境的资源:内存、CPU、存储器、网络等等。这些资源中的大多数能够很容易地通明地应用,有些可能不依赖于应用程序。大多数应用程序在部署之前都须要一些后面的配置步骤,并且须要一些(或者很多)非凡的保护工作,这些工作可能与备份、复原、文件压缩、高可用性查看、日志保护、数据库增长和健全例程等相干。例如,在降级时可能须要将它们置于某种非凡状态,以确保它们不会删除用户。 咱们方才形容的所有这些货色,都是应用程序之上的实用技术常识。在软件和服务软件的生命周期中,所有这些操作工作都要反复屡次。当然,很多时候他们有一些脚本来自动化这些工作。然而,如果应用程序在容器中运行,在一个由Kubernetes或OpenShift编排的Pod中呢?有没有更好的办法,来实现自动化呢?能够“容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩,云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。”(来自云原生定义) 这个问题的答案就是操作器模式(operator pattern)。又称为Kubernetes Operators。那么,它们是什么呢?如何开发一个?它们能够向咱们的应用程序增加什么?通过将它们公布到操作器核心,它们是如何增加到咱们的软件作为一种服务体验的? 我集体喜爱给出的最好定义是,操作器是Kubernetes API的扩大,以自定义资源的模式,由部署后运行在Pod中的规范控制器协调/治理。仿佛很简单,对吧?让咱们看一下这些局部。 扩大Kubernetes API 首先,让咱们略微后退一步,试着一点一点地了解它。我想问的第一个问题是,咱们如何与Kubernetes互动?咱们应用kubectl来从独立治理的角度部署和保护咱们的应用程序,咱们应用client-go和其余库来自动化与Kubernetes API的通信。好酷。API给了咱们什么? 让咱们看看Kubernetes API给咱们什么: 所有这些个性在原生Kubernetes对象之间共享。许多设计良好的操作,如创立、读取、更新和删除、监督端点的性能、身份验证和受权等等。 咱们晓得Kubernetes资源构建在定义之上,这些定义来自于这个存储库中的Kubernetes API: https://github.com/kubernetes... 在那里咱们能够找到这些资源的组、版本和品种,对吧?这是间接进入名为TypeMeta字段的信息。让咱们看一看! 如果咱们失去一个资源,例如DaemonSet和运行: $ kubectl get DaemonSet myDS -o yaml在一开始,咱们会看到如下内容: apiVersion: apps/v1kind: DaemonSet这通知咱们DaemonSet在apps组下,版本是v1,是一种DaemonSet。咱们在哪里能够找到对应的golang类型呢?咱们只须要到存储库并找到types.go文档。像下图: $ tree -L 2...├── apps│ ├── OWNERS│ ├── v1│ ├── v1beta1│ └── v1beta2...在v1文件夹中,咱们有types.go,咱们能够寻找DaemonSet类型如下: type DaemonSet struct { metav1.TypeMeta `json:",inline"` // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata // +optional metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"` // The desired behavior of this daemon set. // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status // +optional Spec DaemonSetSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"` // The current status of this daemon set. This data may be // out of date by some window of time. // Populated by the system. // Read-only. // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status // +optional Status DaemonSetStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`}如果咱们能够以这种形式开发咱们的应用程序,使其成为Kubernetes的原生局部,或者至多利用所有这些个性,只需输出kubectl get myapplication,并依据我的特定需要接管回信息,会怎么样呢?更进一步,如果咱们能创立本人的更新例程和函数呢?如果咱们能够利用嵌入的指标规范,并从Kubernetes构建粗浅的见解,就像咱们应用原始资源一样,会怎么样呢? ...

October 8, 2020 · 2 min · jiezi

关于cncf:Helm-Hub搬家到Artifact-Hub

明天,咱们很快乐地发表,Helm Hub正在转移到Artifact Hub。这意味着,当你到Helm Hub时,你将被重定向到Artifact Hub。 这对你意味着什么 如果你搜寻Helm Hub或在Helm Hub列出你的chart,你可能会想晓得,这对我意味着什么? Artifact Hub列出了Helm Hub列出的所有雷同的chart。它提供了更快的搜寻,并蕴含了面搜寻(faceted search)。你应该可能以与之前相似的形式发现chart。Helm CLI搜寻如常持续工作。 除了搜寻chart之外,Artifact Hub还有更多内容。当chart更新时,你能够通过电子邮件或web hook取得告诉。你能够找到其余工件并查看相干的工件。Artifact Hub提供了比Helm Hub更多的性能。 如果你在Helm Hub中列出了你的chart存储库,而在Artifact Hub中还没有列出它们,那么它们将主动被导入。Artifact Hub提供了索取存储库,以及列出新存储库的办法。在列出存储库时,能够将其连贯到用户帐户或多用户组织。 咱们为什么要这样做 Helm Hub建在Monocular我的项目上。这个我的项目是为了解决无限数量的Helm存储库而设计的,它的用例与尽可能多的chart存储库的公开列表略有不同。它在Helm我的项目中施展了很好的作用,但随着Helm chart和存储库数量的减少,它开始显示出一些局限性。咱们晓得咱们须要解决一些对于Helm Hub的问题。 当咱们开始遇到增长问题时,Artifact Hub就呈现了。咱们没有构建操作本人的Hub实例,也没有编写咱们本人的软件来解决伸缩问题,而是让Artifact Hub来解决chart发现和治理。Artifact Hub反对和促成了CNCF生态系统的更多内容,而不仅仅是chart。 疑虑或问题 如果你在转换过程中遇到问题,请让咱们晓得。有几种办法: 如果问题是从迁徙中索取Artifact Hub上的chart存储库,请在Helm Hub上提交一个问题。遇到Artifact Hub站点的问题时,你能够将问题提交到Artifact Hub我的项目中。它是一个CNCF我的项目,是开源的。应用Helm CLI搜寻Artifact Hub有问题吗?你能够向Helm提交一个问题。留神:在搜寻中找到时,chart的url默认以hub.helm.sh结尾。Matt Farina@mattfarina 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

October 8, 2020 · 1 min · jiezi

关于cncf:CNCF宣布云原生存储项目Rook毕业

自退出CNCF以来,云原生存储工具的贡献者增长了260% 旧金山,加利福尼亚州-2020年10月7日-CNCF®(Cloud Native Computing Foundation®,云原生计算基金会),为云原生软件构建可继续的生态系统的一个组织,明天发表Rook毕业。从孵化阶段到毕业阶段,Rook曾经证实了其被采纳的水平在一直增长、一个凋谢的治理过程、个性成熟度以及对社区、可持续性和包容性的动摇承诺。 Rook是一款面向Kubernetes的开源云原生存储编排器,为各种存储解决方案提供平台、框架和反对,从而与云原生环境进行原生集成。Rook通过Kubernetes操作器(Operator)为每个存储提供商提供服务。它最后是在2018年被承受为CNCF我的项目的。这是CNCF毕业的第13个我的项目,也是第一个基于块、文件或对象存储的我的项目。 “存储是任何云原生部署的一个重要方面,Rook补救了过来在云原生环境之外运行长久存储的团队的空白。”CNCF CTO/COO Chris Aniszczyk说:“Rook易于应用,通过操作器模式与Kubernetes无缝集成,咱们很快乐看到该我的项目毕业,并期待造就他们一直增长的社区。” 自退出CNCF以来,用户采用率,社区生态系统和我的项目成熟度始终在稳步增长和进步。多家公司在生产中应用Rook,包含Calit2 UCSD、Finleap Connect、Geodata等。 维护者团队目前由7名成员组成,组织散布良好,包含Cloudical、Nexenta、Red Hat、Suse和Upbound。自2018年9月成为孵化我的项目以来,Rook外围存储库的贡献者增长了260%,从90人增长到279人。在过来的12个月里,184个不同的贡献者编写了超过1140个拉申请。 “Rook源于对云原生环境中主动存储管理的需要。与其将内部存储解决方案插入Kubernetes,咱们意识到Kubernetes集群中须要一个存储平台,”Rook维护者兼红帽高级首席软件工程师Travis Nielsen说。“咱们为这次毕业感到十分骄傲,这体现了咱们我的项目的成熟,以及咱们对产品质量、平安和可靠性的投入!” “2018年,当咱们将Rook捐献给CNCF时,人们对Kubernetes产生了浓重的趣味和社区,并对云原生社区的主动存储管理产生了需要。重要的是要确保Rook放弃自在和社区驱动,持续为更宽泛的生态系统推动翻新,”Rook联结创始人兼Upbound开创工程师Jared Watts说。“咱们为Rook的蓬勃发展感到自豪,感激CNCF的领导和反对,并期待推动这个生态系统向前倒退,成为一个成熟的、可生产的云原生存储解决方案。” 平安审计是在2019年12月由CNCF Security SIG执行,有13个从高到低的严重性发现,其中许多在开源我的项目中常见。Rook保护人员曾经采取措施来解决这些问题。平安个人审查了这个我的项目,并倡议TOC该我的项目应毕业,其架构或健康状况没有实质性担心。 “即便是在GA前公布的版本中降级,咱们也从未失落过一个字节的数据。咱们在Rook社区的帮忙下取得了不凡的体验。”Finleap Connect技术总监Christian Hüning示意:“它运行得完美无瑕,为咱们提供了最要害的业务应用程序所须要的性能和弹性。” “这些是在Kubernetes上运行要害软件的air-gapped装置,”Replicated创始人兼CTO Marc Campbell说。“咱们依附Rook来治理Ceph,这样咱们就能够无需本人构建而取得高度可用的可再发行块和对象存储。” “咱们很快乐看到该项目标成熟,它经验了CNCF生态系统的不同阶段,并且引入了咱们未来能够应用的其余各种后端,”Next Generation Networks卓越核心云基础架构工程师Moh Ahmed说。 为了从孵化阶段正式毕业,该我的项目曾经达到了CII最佳实际的合格规范,并采纳了本人的治理构造。 理解更多对于Rook,请拜访:https://rook.io/ 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

October 8, 2020 · 1 min · jiezi

关于cncf:应用程序打包器Porter作为沙箱项目加入CNCF|实现CNAB

不到两年前,当Jeremy Rickard和我创立Porter时,咱们心愿创立一个社区主导的我的项目,激励厂商之间的合作,从而使云原生利用程序包(Cloud Native Application Bundles,CNAB)具备可拜访性和可维护性。咱们心愿持续反对独立于供应商的使命,同时倒退可能应用Porter的开发并为其做出奉献的实践者社区。 明天,Porter的保护人员很快乐地发表,Porter曾经被接收为CNCF沙箱我的项目。通过向CNCF奉献Porter,咱们心愿激励采纳Porter来简化程序包的创立和应用,并看到更多的公司奉献mixin。 短期内,咱们将专一于咱们的路线图。咱们的介绍文档将被扩大和重构,以使Porter和程序包更容易入门。咱们还收集了来自社区的对于Porter各种可用性的反馈,例如如何在CI流水线中构建和推广程序包,或者在Porter清单中应用模板变量,咱们将着手解决这些问题,使Porter更容易应用和自动化。 除了为这些打算奉献想法和精力之外,开发人员还能够通过遵循咱们的Mixin开发指南来奉献Mixin。Mixin的例子包含Docker Mixin和Terraform Mixin。 如果你有趣味理解更多对于程序包,请查看这个视频介绍。理解更多对于Porter社区的信息,并为我的项目做出奉献。 Carolyn Van Slyck@carolynvs 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

September 30, 2020 · 1 min · jiezi

关于cncf:使用CNCF的Kuma和Envoy运行多集群和多云服务网格

当咱们创立Kuma(日语中“熊”的意思)时,咱们幻想创立一个能够跨每个集群、每个云和每个利用程序运行的服务网格。这些都是大型组织必须实现的需要,以反对他们的应用程序团队跨各种架构和平台:VM、Kubernetes、AWS、GCP等等。 Kuma当初是CNCF的一个我的项目,在撰写本文时,它是惟一一个向基金会捐献并获承受的以Envoy为根底的服务服务,咱们始终不懈地在社区中执行这个愿景。(编者按:在公布本文时,Open Service Mesh是另一个向基金会捐献并获承受的以Envoy为根底的服务服务。) 从今年夏天公布的具备先进多区域(multi-zone)性能的Kuma 0.6开始,Kuma当初在一个多网格管制立体上反对每一个云供应商、每一个架构和每一个平台。在多区域部署中部署时,Kuma形象了跨多个区域的服务网格策略的同步,以及跨这些区域的服务连通性(和服务发现)。区域能够是一个Kubernetes集群、一个数据中心、一个云区域、一个VPC、一个子网等等--咱们能够依照本人的爱好宰割区域,咱们还能够将Kubernetes和VM工作负载混合到一个分布式网格部署中。 Kuma创立了一个服务连贯笼罩混合基础设施主动发现和连贯服务,包含混合Kubernetes + VM服务。 自第一天起,Kuma就推出了多网格反对,减少了的多区域性能能够在同一个集群上创立多个隔离的网格(具备专用的mTLS CA),缩小了团队协调,减少了隔离并进步了安全性。而不是每个人都共享的一个大型服务网格。此外,因为多区域利用了自Kuma第一个版本以来提供的一流的K8s + VM反对,因而组织中的所有团队和工作负载都能够受害于服务网格,而不仅仅是咱们的新我的项目。 因而,团队应用散布在每个云、集群和工作负载上的Kuma服务网格,能够从一个独自的Kuma集群自身进行治理。同时,多个服务网格能够在一个Kuma管制立体上提供(程度可伸缩),以简化跨组织的网格治理--十分相似于Kubernetes及其名称空间的工作形式。 Kuma在同一个部署上反对多个虚构网格,打消了为每个应用程序提供多个服务网格集群的需要,从而显著升高了ops老本。 应用KDS扩大xDS 咱们在Kuma能够通过利用“多区域”部署模式,在多个集群、云或区域之间部署分布式服务网格。“多区域”部署是在v0.6+中引入的一种运行Kuma的新形式,另外还有“独立”部署模式(每个区域一个服务网格)。 在多区域部署中,有几个重要的性能,Kuma提供: 有两种管制立体模式:全局(global)和近程(remote)。这在服务网格畛域是十分独特的。有一个新的DNS”.mesh“区域给服务发现。有一种新的“Ingress”数据立体代理类型,能够在Kuma网格内实现区域之间的连贯。在分布式部署中,“全局”管制立体将负责承受Kuma资源,通过原生Kubernetes CRD或基于VM的部署中的YAML来确定服务网格的行为。它将负责将这些资源传播到“近程”管制立体--每个咱们想要反对的区域都有一个。 “近程”管制立体将通过Envoy xDS API的扩大与“全局”管制立体替换Kuma资源,咱们将该API称为KDS(Kuma Discovery Service),通过gRPC协定,也就是通过HTTP/2。“近程”管制立体还将承受来自基于Envoy的数据立体代理的申请,这些代理属于传统xDS上的同一区域。 近程管制立体还嵌入一个DNS服务发现,可用于发现跨不同区域的服务。下面的架构很容易地装置,只需通过几个步骤应用Kuma CLI “kumactl”或HELM chart。 在Kuma里,咱们将Envoy代理过程形象为“kuma-dp”过程,使用户不用间接配置或启动“envoy”,从而使启动数据立体代理的整个过程更加容易。高级用户如果他们违心的话,依然能够拜访底层的“envoy”过程。 利用Envoy原生的xDS API在每个区连贯“kuma-dp”与“近程”管制立体,以及利用KDS连贯“近程”管制立体到全局管制立体,实际上咱们应用了gRPC使整个服务网格基础设施堆栈以统一的形式进行。 “全局”和“近程”架构有几个益处: 咱们能够通过扩大“近程”管制立体来独立扩大每个区域,并在某个区域呈现问题时实现HA。没有单点故障:即便“全局”管制立体产生故障,咱们依然能够在“近程”管制立体上注册和登记数据立体代理,并且每个服务的最新地址依然能够流传到其余基于Envoy的边车。“全局”管制立体容许咱们主动流传每个区域的状态,同时确保“近程”管制立体理解每个区域的Kuma Ingress,以实现跨区域连贯。管制立体的拆散管制着如何在区域之间同步Kuma资源(如网格和策略),然而它须要另外两个组件,以便可能以自动化形式在整个区域的数据立体层进行发现和连贯:服务发现和“Ingress”数据立体代理模式。 跨区域发现和连贯 如咱们所述,多区域部署可用于跨多个云和集群部署分布式服务网格,并反对在不同区域运行的服务之间的无缝通信,无效地提供跨区域服务发现和连贯。 在其余用例中,跨区域连贯可用于: 在单个和多云环境中跨多个Kubernetes集群、区域和可用性区域启用高可用性 容许流量从一个区域转移到另一个区域,以进行劫难复原通过利用流量控制策略来确定将服务流量从一个区域转移到另一个区域的条件,从而实现咱们的应用程序从VM到Kubernetes(或从物理数据中心到云)的逐渐转换。Kuma的多区域部署通过提供两个重要性能实现跨区域连贯:一种新的“Ingress”数据立体代理模式将传入的流量解决到一个区域。每个区域将部署一个Kuma Ingress,能够随着交通流量的减少而程度伸缩。“Ingress”数据立体模式是在默认代理模式和“网关”模式(以反对第三方API网关)的根底上增加的。因为采纳了新的“Ingress”模式,Kuma不须要区域之间的立体网络拓扑,并且能够反对更简单的基础设施。内置的服务发现DNS服务器将服务的地址解析为同一区域中正本的IP地址或另一个区域中的入口代理的地址。同样,“全局”和“近程”管制立体也能够依照Kuma上的多区域指令,点击一下即可装置Ingress和DNS服务发现。在服务发现方面,Kuma在内置DNS解析器上创立一个“.mesh”DNS条目,该条目可用于解析同一区域或其余区域中的服务,从而无效地“扁平化”跨简单基础设施的服务发现。依据已配置的流量路由策略,Kuma将确定咱们是否应该应用本地区域中的服务正本,还是应该将申请解析为另一个区域中的Kuma Ingress的IP地址,而后利用SNI确定已申请了哪些服务,并相应地路由申请。 在这个示例中,咱们有三个服务(users、invoices和billing)。“invoices.mesh”的申请将被代理到同一区域内的一个IP地址,而“billing.mesh”的申请则被主动代理到另一个区域的Ingress。 因为SNI对于跨区域通信是强制性的,因而必须在网格上启用mTLS策略。此外,因为Kuma曾经晓得所有的服务在哪里运行,跨区域发现和连贯将主动产生。 当一个新的服务被注册到Kuma,一个新的“kuma.io/zone”标签被增加到数据立体定义中,这样咱们就能够应用基于属性的策略选择器来配置Kuma策略,比方流量路线,以确定跨区域流量的行为(不同区域的蓝/绿或灰度,加权流量,以及流量挪动)。 应用默认端口80上的任何“{service-name}.mesh”(即便服务未在端口80上侦听)时,DNS解析器(除了解析服务的地址外)还将主动解析以下端口:指标服务并将其注入到连贯中,以放弃整个连贯的失常运行工夫,即便一个团队决定重新分配其余团队可能正在应用的服务端口。此性能缩小了在Kuma网格中保护大量服务和连贯所需的团队合作。 总结 多得了自v0.6+以来Kuma提供的新的多区域性能,咱们当初能够轻松地跨多个Kubernetes集群、云和区域运行服务网格。因为Kuma原生既反对容器化工作负载,又反对VM工作负载,因而该性能还能够用于创立跨混合架构的服务连通性。 通过提供一键式装置步骤来主动装置新区域以及诸如全局/近程管制立体,内置服务发现和本机Kuma Ingress之类的性能,Kuma抽象化服务连接性,通过创立无效笼罩的网络让服务跨简单的网络拓扑发现和应用彼此。这使其非常适合任何企业或分布式环境。 要启动和运行Kuma,你能够查看装置页面以及官网的Slack频道。 网格高兴!???? 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

September 23, 2020 · 1 min · jiezi

关于cncf:容器附加存储CAS是云原生存储

客座文章作者:Evan Powell,CEO @MayaData 或者,云服务怎么会不是云原生的呢? 欧洲KubeCon在很多方面都很平凡。一个惊喜是,因为KubeCon是一个虚构流动,这导致我与各种存储供应商和我的项目的对话比之前的KubeCon更多。KubeCon存储的交换频道招集了许多聪慧的供应商,他们通常单干,试图为最终用户解决问题;我受到了鼓励,试着尽我的一份力来跟上。 这就是本文终点,作为容器附加存储(Container Attached Storage,CAS)定义的原始作者,接下来为更宽泛的社区创立一个博客是有意义的。 引发这次更新的问题来自一个传统存储供应商的工程师,他问--我略微援用一下:“如果涣散耦合对于云原生架构如此重要,这是否意味着,依赖于一个给定的云自身就不是云原生的?换句话说,云服务自身不是云原生的吗?”我不得不答复--是的--但故事还有更多内容。 回顾--什么是CAS? 容器附加存储是一种模式,它十分合乎数据合成的趋势,以及运行小型、涣散耦合的工作负载的小型、自治团队。换句话说,我的团队可能须要为咱们的微服务应用Postgres,而你的团队可能依赖于Redis和MongoDB。咱们的一些用例可能须要性能,一些可能在20分钟内就用完,其余的是写密集型的,其余的是读密集型的等等。在大型组织中,团队依赖的技术,会随着组织规模的增长,和组织越来越信赖团队抉择他们本人的工具,而变得越来越多。Kubernetes反对这种模式--有时被探讨为数据网格(data mesh)和多语言数据(polyglot data)的衰亡--来自ThoughtWorks的Zhamak Dehghani和其他人有相干的探讨。 理解更多对于CAS: 早在2018年4月,我在CNCF的网站上创立了CAS一词的博客:https://www.cncf.io/blog/2018... 7月的CNCF网络研讨会,由OpenEBS我的项目负责人Kiran Mova主持:https://www.cncf.io/webinars/... 这是来自Kiran社区网络研讨会的一张标准图片,并附有一些解释: CAS意味着开发者,能够在不思考其组织存储架构的底层需要的状况下工作。对于CAS,云磁盘与SAN雷同,SAN与裸机或虚拟主机雷同。咱们没有召开会议来抉择下一个存储供应商,或探讨设置来反对咱们的用例,咱们应用咱们须要的存储或localPV治理来启动咱们本人的CAS容器,而后继续前进。 好的,^^这就是CAS,然而云有什么不是原生云的呢? Kubernetes的一个被忽视的方面是,它最后创立的目标,是确保咱们能够以云原生形式运行云。让我来解释一下。 在Kubernetes之前,很难发表用意(intent),并晓得将要执行此用意,而不管其部署环境是本地部署,还是A、B或C云。相同,企业被倡议抉择一家次要的云,并且加倍他们与该云的专业知识和关系。 因而,整个组织和他们编写的所有软件都隐式地依赖于该云,因而与云耦合。这种严密耦合通常并不重要,直到它变得重要为止。只有像Netflix这样的组织,他们的零碎架构既能解决AWS的破绽,又能通过混沌工程踊跃地、不懈地验证本人的容错性,能力挺过各种各样的AWS宕机。据揣测,他们转移至多一部分工作负载的能力,比方基于Spinnaker的CI/CD,也有助于他们与AWS协商更好的价格。 简而言之,如果你将云原生定义为可能在底层云中断时存活,那么与云严密耦合自身就是一种反模式。 Kubernetes之所以成为咱们这个时代最重要的开源我的项目之一,局部起因在于它意识到了这种严密耦合的危险和阻抗挑战。而且,对于一个传统的共享所有的存储硬件供应商来说,这里有些敏感,这种逻辑在他们销售的零碎上双倍实用。 如果你想构建涣散耦合的零碎,就像你不能简略地在一个云上,并且只在那个云上运行一样,你也不能假如一个宣称可扩大到数千个节点的存储系统在所有状况下都能工作。 如果咱们承受云原生外围的“构建失败”信条,咱们必须抵赖共享的所有存储将会解体。它的行为形式并不适宜每个团队的工作负载。它将以非Kubernetes原生形式运行,所有这些依赖关系将超出咱们管制的危险引入到咱们的环境中,这对咱们的团队来说是不通明的。 好的,那么CAS有什么新货色呢? 当CAS首次呈现时,它被用于较少工作要害型工作负载,这并不奇怪。很好的例子包含各种“半永久性”工作负载,其中你心愿数据在CI/CD运行期间保留,或者用于一些数据迷信工作,而后你心愿它隐没。对于这些示例,CAS容许工作负载疾速且统一地启动十分重要。第二个也是重要的需要是,无论底层环境如何,CAS的行为形式都是雷同的。 当Kubernetes调度工作负载时,即便是相当典型的32秒的EBS附加工夫,如果运行工夫为5分钟,而你每天运行它几十次,则须要不少工夫。你能够在晚期OpenEBS采纳者列表中看到这种模式,晚期的公共援用往往偏向于持续时间绝对较短的工作负载。 几年前,Kubernetes上的较长持续时间的工作负载以两种形式之一解决。 要么通过云中的托管服务,或减少额定弹性级别的NoSql数据库。一开始咱们认为CAS在这两种状况下都不实用,因为传统的共享存储必定不实用;然而,咱们很快意识到NoSQL数据库和Kafka这样的解决方案,能够在咱们称为动静LocalPV的中央失去帮忙。 通过放弃对底层环境(包含可用的云卷和物理磁盘)的理解,像OpenEBS的LocalPV这样的CAS解决方案,升高了在Kubernetes上运行这些工作负载的操作工作量。CAS解决方案这样做的形式,缩小了对给定底层云或存储系统的锁定或依赖。 第一个新的CAS要求 因而,咱们能够相应地更新CAS定义。咱们当初晓得CAS解决方案须要包含LocalPV反对。同样,帮忙应用LocalPV运行数据应用程序的相干Kubernetes操作器也是如此。 最近,咱们看到许多工作负载都在减少,对于这些工作负载,本地节点性能十分重要。 性能问题同样能够通过应用LocalPV来解决。一个挑战是,许多工作负载当初既须要性能又须要多节点HA。仅仅通过Restic或其余我的项目或产品备份节点是不够的。 思考运行在PostgreSQL或MySql上的高性能工作负载--例如运行在MySql上的Magento。仅仅备份数据是不够的,MySql通常心愿可能立刻拜访另一个节点上的数据。兴许难能可贵的是,许多这些工作负载在云呈现之前就存在了。传统的SQL,如MySql、PostgreSQL和其余SQL,简直总是部署故障转移和正本。有时,这些传统的工作负载甚至能够通过Kafka或相似的形式整合在一起,以交付一个对立的数据网格,就像后面ThoughtWorks的文章中提到的那样。咱们的幻想是为企业提供关注点,比方从所有数据中学习,同时也容许小型独立团队的自治和敏捷性。 第二个新的CAS要求 因而,咱们能够用第二种形式更新CAS定义。咱们当初晓得CAS解决方案须要以LocalPV速度蕴含多节点HA。 这个需要的惟一问题是,到目前为止,可能满足这个需要的解决方案非常少。据我所知,致力于满足这一需要的惟一CAS解决方案是OpenEBS Mayastor;它将在2020年9月达到测试版0.4。 第三和第四项附加的CAS要求 第三个更新在这两个更新之后的逻辑上进行。CAS解决方案在其架构中应该是云原生的。如果咱们想胜利地反对所有类型的工作负载,比方NoSql工作负载的LocalPV,以及对许多性能敏感的PostgreSQL等部署具备弹性的高性能,那么CAS必须提供多种存储数据的办法。 在OpenEBS的状况,该我的项目利用云原生架构提供了不少于4个“数据引擎”(如果计算可用的所有不同格调的LocalPV,会更多)。晚期的CAS解决方案在实质上更加繁多。我认为所有的CAS都须要以Kubernetes作为基底的思维来构建,从而实现可插拔的非单体架构。 最初,开源仿佛是显著的。感性的人可能不批准这一点,因为有一些显著的CAS模式的晚期贡献者依赖于专有软件。然而,专有软件引入了供应商依赖,这与云原生固有的“可移植性”精力相冲突。 综上所述,从成千上万的容器附加存储用户那里,咱们能够自信地说,CAS的定义应该扩大到包含: CAS必须反对pass-through模式(咱们在Kubernetes生态系统中称之为LocalPV)CAS必须反对LocalPV速度的多节点HACAS软件在架构上应该是云原生的--依据工作负载反对多个数据引擎CAS应该是开源的,以防止引入供应商依赖关系。总结 在过来的几年里,咱们看到了来自更宽泛的云原生社区的大量反馈和反对,这些社区致力于如何在解决数据时最大限度地利用Kubernetes和云原生办法。咱们必须付出能力失去。而且,我比以往任何时候都快乐,因为MayaData将OpenEBS捐献给了CNCF。咱们很天然地将Litmus也捐献给了关注有状态工作负载的混沌工程。咱们十分骄傲的是,依据这篇来自CNCF的DevStats报告,截止到2020年8月底,MayaData是CNCF我的项目的第5大次要贡献者:https://all.devstats.cncf.io/... 最近,咱们帮忙启动了Data on Kubernetes社区我的项目,在这供应商中立空间中探讨操作人员、数据库、用例等等。来自应用Kubernetes组织的工程师像Optoro和Arista等,以及Kafka/Confluent和Cassandra/DataStax等我的项目进行了发言。欢送并激励所有人与独立组织者取得联系,以任何你想要的形式参加。 CAS当初被看作是把Kubernetes转换成数据立体的要害局部。CAS补充了底层云存储服务、本地CSI可拜访存储,甚至是本地节点中可用的原始磁盘和内存。 咱们应用CAS(特地是OpenEBS)的教训表明,用户曾经相熟了这种模式。CAS的新需要反映了这模型的增长和成熟度。 我对将来几年咱们将走向何方感到兴奋。当咱们在Kubernetes上摸索更多数据密集型的工作负载时,咱们的需要将如何倒退?不论是什么,咱们都渴望和你一起找出答案。咱们在MayaData这里聆听,并持续倒退CAS模式以满足新的需要。 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

September 23, 2020 · 1 min · jiezi

关于cncf:5个Kubernetes成本估算问题和策略

客座文章最后由Robert Brennan在Fairwinds博客发表 预计你在特定的Kubernetes工作负载上破费(或节约)多少是艰难的。好消息是,有一些正当的策略能够估算给定工作负载的老本。 在这篇文章中,咱们将探讨影响老本估算的五个次要问题,并在Fairwinds Insights的老本仪表盘中谈及咱们用来克服这些问题的策略。咱们将在行将公布的博客中对正确的大小进行更深刻的探讨。 问题1:装箱(Bin Packing) 假如咱们有一个节点,破费咱们20美元/月。假如它有5GB的内存和5个CPU可供使用。(留神:这不是一个十分事实的节点,然而它使图和数学进去难看点????) 这里有一个工作负载,须要2GB的内存和2个CPU能力运行: 咱们能够在一个节点中包容多达两个Pod的工作负载: 然而,如果咱们想为工作负载增加第三个Pod,就没有足够的空间了。所以咱们须要增加(并付费)一个新节点: 留神,在第一个节点上有一点空间节约--咱们有1GB内存和1CPU。而咱们的第二个节点没有被充分利用--不到一半的资源被投入使用。 这是老本估算的首要问题:Kubernetes不能在多个节点上拆分一个Pod。因而,如果一个节点不能包容整个Pod,就会有肯定数量的容量被节约。 解决方案:这里的一种解决方案是“适当大小”节点。如果咱们应用一个领有4GB内存和4CPU的节点,咱们的工作负载将十分适合,并且没有容量会节约: 问题#2:资源不对称(Resource Asymmetry) 让咱们思考一种不同的工作负载:一种CPU十分密集的工作负载。它须要3个CPU能力运行,但内存只有1GB。 当初咱们只能将1个Pod值的工作负载放入一个节点(应用咱们的4CPU/4GB示例): 这里会节约大量未应用的容量--不仅是1个CPU,还有3 GB内存。咱们只应用了一半的节点,但如果咱们想增加第二个Pod,咱们将须要第二个节点,但节约的量是一样的! 解决方案:同样,咱们须要调整节点的大小--云提供商提供CPU密集型和内存密集型的节点来解决这个问题。 问题3:老本归属(Cost Attribution) 咱们假如较小的节点(4个CPU和4 GB)破费16美元/月。应用这些数字,咱们能够粗略预计出每个CPU和每个GB内存的老本。16美元中,8美元进了CPU,8美元进了内存。这样咱们就能够推断出,咱们为每CPU和每GB内存领取了2美元。 那么咱们最后的工作量是多少呢? 依据下面的计算,咱们能够说$2/CPU * 2CPU + $2/GB * 2GBs = $8。这是有意义的--咱们能够在一个16美元的节点上恰好满足两个这样的工作负载。咱们将在上面探讨的起因,咱们称之为老本估算的乐观办法。 然而咱们的第二个工作负载,CPU密集型的工作负载呢? 让咱们做同样的计算:$2/CPU * 3CPU + $2/GB * 1GB = $8。乐观的办法是这个工作量破费8美元。但正如咱们在下面看到的,每个节点只能包容一个。所以在事实中,它破费了咱们16美元/月,乐观的办法仿佛不那么精确。 有没有其余的老本估算办法能够给咱们一个更正当的答案?有! 咱们不必把CPU老本和内存老本加在一起,而是取两者的最大值。这有助于咱们思考内存密集型或CPU密集型的工作负载,这可能导致额定的容量被节约。(留神,咱们还须要将后果乘以2,因而咱们也计算失落的资源。) 所以计算结果就是MAX($2/CPU * 3CPU, $2/GB 1GB) 2 = $12。这曾经很靠近16美元的指标了。残余的局部归因于齐全未应用的节点容量(即,只管节点承载了CPU密集型的工作负载,但仍有1个CPU将被节约)。 咱们称之为激进预计法。依据Kubernetes将工作负载装箱到节点上的能力,它为最坏的状况做了筹备。 ...

September 22, 2020 · 1 min · jiezi

关于cncf:使用RBAC-Impersonation简化Kubernetes资源访问控制

客座文章最后由Juanjo Ciarlante在Bitnami上发表 介绍 Kubernetes,像任何其余平安零碎一样,反对以下概念: 身份验证(Authentication):验证和证实用户、组和服务帐户的身份受权(Authorization):容许用户应用Kubernetes资源执行特定的操作会计(Accounting):存储主题操作,通常用于审计(auditing)目标受权--解决用户对资源拜访的过程--总是一个挑战,特地是当拜访由团队成员身份或我的项目成员身份管制时。两个要害挑战是: 因为Kubernetes组(group)成员关系是由身份提供程序(Identity Provider,IdP)从内部解决到API自身的,因而集群管理员须要与身份提供程序管理员交互来设置这些组成员关系,这使得工作流可能很麻烦。身份提供者可能基本不提供组成员关系,从而迫使集群管理员按用户解决拜访,即Kubernetes RoleBindings蕴含容许最终用户(end-user)的“残缺”列表。 在本教程中,咱们提出了一种应用现有Kubernetes受权个性“表演”组成员身份的办法--能够通过团队、我的项目或你可能须要的任何其余聚合。 假如和前提条件 本文假如你: 理解个别的最终用户平安概念有一些对于RBAC角色和绑定的常识和教训了解身份验证和受权之间的区别配置集群时启用Kubernetes RBAC,自1.6发行版以来默认设置Kubernetes身份验证概述 身份验证是任何集群管理员都应该遵循的策略的要害局部,以爱护Kubernetes集群基础设施,并确保只有被容许的用户能力拜访它。 上面简要介绍一下Kubernetes如何进行身份验证。次要有两类用户: ServiceAccounts(SAs): ID由Kubernetes自身在集群内治理。每个ServiceAccount都有一个身份验证令牌(JWT),作为它的凭据用户(内部角色或机器人用户): ID是内部提供的,通常由IdP提供。有许多机制能够提供这个ID,例如: * x509证书 * 动态令牌或用户/密码文件 * 通过内部身份提供者(IdP)的OpenID连贯令牌(OpenID Connect Tokens,OIDC) * Webhook令牌 * 托管的Kubernetes提供商(例如GKE, AKS, EKS)与他们本人的云认证机制集成用户ID蕴含在对Kubernetes API的每次调用中,而该API又是由访问控制机制受权的。 采纳OIDC进行身份验证很常见,因为它提供了单点登录(Single-Sign-On,SSO)体验,不过有些组织可能依然应用最终用户x509证书,因为无需任何内部IdP干涉就能够颁发这些证书。然而,这些独特的办法带来了以下挑战: x509证书:只管它们很容易设置,但用户最终领有一个无奈吊销的x509包(密钥和证书)。这迫使集群所有者指定较短的过期工夫,这显然取决于人员流动性。此外,用户的组被写入x509证书自身。这迫使集群管理员在用户每次更改成员资格时都从新颁发证书,同时无奈吊销以前的证书(即,用户将持续放弃旧组的成员身份,直到以前的证书过期)。OIDC身份验证:应用组织应用的IdP提供SSO很不便。当提供的身份短少组成员关系,或者组成员关系(由组织设置)不能间接映射到用户的Kubernetes工作负载需要的团队或我的项目成员关系时,就会呈现问题。用户当初曾经通过身份验证,咱们须要看看如何受权他们应用Kubernetes集群。 Kubernetes受权和RBAC概述 在网上有许多对于Kubernetes RBAC的资源。如果你不齐全相熟这些概念,我举荐这个对于在Kubernetes中揭开RBAC神秘面纱的很棒的教程。要理解对于如何在集群中配置RBAC的更多信息,请参阅本教程。Kubernetes RBAC容许指定: A)容许的SUBJECTS,对 B)资源品种进行VERBS(能够抉择放大到特定的资源名称) 在下面的模型中,B)被实现为一个Kubernetes Role(或ClusterRole),而A)-> B)的绑定被建模为一个Kubernetes RoleBinding(或ClusterRoleBinding),如下图所示: 应用表演的(impersonated)“虚构用户”来管制拜访 Kubernetes RBAC蕴含一个非凡的impersonate(表演)动词,可用于容许Subjects(即Users、Groups、ServiceAccounts)取得其余Kubernetes用户或组身份。 因为这些取得的身份不肯定须要存在--还记得Kubernetes管制立体自身没有用户或组存储--咱们将在本文中将它们称为“虚构用户(virtual-users)”。此个性容许将“虚构用户”设置为“角色帐户”平安主体。例如: alice@example.com,作为利用前端(app-fe)团队的成员,能够表演虚构用户app-fe-user bob@example.com,作为应用程序后端(app-be)团队的成员,能够表演虚构用户app-be-user 能够创立RBAC规定来容许这些“虚构用户”拜访他们须要的Kubernetes资源,如下图所示: 如上所示,利用现有的Kubernetes RBAC个性,受权解决分为: 团队成员:RBAC ClusterRoles和ClusterroleBindings,它们示意容许用户表演其团队的虚构用户。团队职责:RBAC角色和角色绑定,阐明团队的虚构用户能够拜访哪些理论的Kubernetes资源。理论的表演操作是通过在Kubernetes API调用的头文件指定的,这是不便的由kubectl通过: kubectl --as <user-to-impersonate> ...kubectl --as <user-to-impersonate> --as-group <group-to-impersonate> ...提醒:没有-as参数的kubectl -as -group…是有效的。为了简化CLI的应用,本文倡议应用下面的第一种模式,通过将用户表演为示意用户组或团队成员的“虚构用户”进行建模。 ...

September 18, 2020 · 2 min · jiezi

关于cncf:企业在云原生化过程中面临的七大挑战

客座文章最后在CloudOps博客上发表 云原生应用程序充分利用云的操作模型,通过主动配置、伸缩和冗余来驱动业务价值。通过将独立的应用程序合成为独立但连贯的容器,开发人员创立了能够依据需要,无缝伸缩的应用程序。从其外围来说,云原生计算容许你在任何中央编写和部署代码,在任何公有、混合和私有云环境中都能够。 云原生景观每天都在变得越来越宏大和简单,但Kubernetes和其余根底工具曾经逾越了鸿沟,在规模和范畴上,它们必须超过晚期采纳者,进入企业。 尽管在实践上很棒,但云原生计算的问题是,实现起来并不总是那么容易或间接--特地是如果你的企业有长期存在的遗留应用程序的话。云原生景观是微小的,它很容易被越来越多的相互竞争和重叠的平台和技术所吞没。你不仅必须采纳适宜你独特需要的云原生工具,还必须通过文化转换来造就对它们的应用。变更应该渐进而全面地实现。以下是咱们看到的企业在云原生化过程中面临的七个最常见问题。 1. 迟缓的公布周期和减速的变动速度 翻新须要疾速公布新软件的能力,因为所有行业的变动速度都在一直放慢。要始终筹备好公布和部署,你必须关注过程而不是目的地。违心始终如一地承受变动,并从失败中学习以适应需要。DevOps是为了调整各方的指标,以便可能疾速频繁地公布小批代码。它是工具、过程和文化哲学的组合。 2. 过期的技术 如果你翻新不够快,市场不仅会追上你,而且会超过你。随着工夫的推移,降级你的零碎所须要的致力将呈指数级增长。如果你还没有将应用程序容器化,并且还没有找到遗留组件的云原生等同物,那么这一点尤其正确。尽管你永远不晓得哪些工具会比其余工具更长久,但在这个倒退如此迅速和频繁的世界中放弃相关性是很重要的。开源工具是这一使命的外围,因为它们确保了品质、可靠性、升高了老本,并将锁定的危险降到了最低。 3. 服务提供商锁定和无限的增长灵活性 如果你在过来过于依赖某个平台或工具,你可能会发现自己当初受到厂商锁定的限度。尽管超大规模的云提供商提供的平台功能丰富且易于采纳,但它们通常是以锁定为代价的。云原生计算的最终目标是让你可能利用超大规模的云提供商,同时放弃思考多云和混合云架构的能力。 4. 不足解决数据的业余技术 人才的获取是技术畛域的一大挑战。2019年的一项考察发现,只有7%的IT领导者在招聘和留住人才方面没有遇到困难。技能差距往往会加剧这一问题。随着技术的继续疾速倒退,要害职位往往很难填补。不仅不足合格的技术人才,而且你找到的任何数字独角兽公司都可能受到传统连累的连累。遗留文化、决策过程和技能集会妨碍DevOps可能提供的翻新速度。 5. 平安 在呈现数据泄露之前,人们很容易遗记平安问题,但这个谬误可能代价昂扬。单次入侵的均匀损失从2018年的386万美元减少到2019年的890万美元,增长了112%。因为有如此多的流动部件,安全性既简单又艰难。尽管如此,保护一个在团队中积重难返的平安实际是很重要的。DevSecOps将局部安全性集成到DevOps流水线中,激励团队将安全性引入到开发阶段。你的团队必须在构建和编码时思考到安全性,而不是在遇到黑客攻击时将其作为预先解决。 6. 操作和技术老本高 通过容许组织只领取所需的计算资源,云的确提供了显著的老本效益。通常状况下,应用云计算的总成本会低于购买、反对、保护和设计本地基础设施的老本。然而,云本机基础设施是简单的实体,必须对其进行适当的治理,以实现老本效益的伸缩。你可能会发现真正优化云的应用很有挑战性,然而有一些办法能够做到这一点。 7. 云原生概念很难交换 云原生概念很难沟通和了解,特地是思考到抉择的高度矛盾。在批准对技术进行投资之前,高管们必须理解云原生解决方案的重要性和复杂性。对技术领导来说,向主管解释微服务、容器和其余概念可能是一场艰辛的战斗。 云原生是一个旅程,而不是一个目的地。CloudOps的标识旨在表白这样一种理念:尽管你必须从某个中央开始,但指标是发现自己置身于一个有限的良性循环之中。与遗留应用程序相比,云原生应用程序要简单得多。在成为云原生的过程中,你可能遇到过一个或多个这样的挑战。通过承受继续变动的文化来应答这些挑战,将为你提供只有云原生能力提供的敏捷性和可伸缩性。分割咱们,理解更多对于CloudOps如何帮忙你应答云原生挑战的信息。 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

September 16, 2020 · 1 min · jiezi

关于cncf:CNCF最终用户技术雷达可观测性2020年9月

作者:Cheryl Hung CNCF刚刚公布了第二份季度CNCF最终用户技术雷达。该技术雷达的课题是可观测性。 幻灯片:https://github.com/cncf/endus... 6月,咱们推出了CNCF最终用户技术雷达,这是CNCF最终用户社区的一个新倡导。这是一个由超过140家顶级公司和初创公司组成的个人,他们定期开会讨论在驳回云原生技术时面临的挑战和最佳实际。CNCF最终用户技术雷达的指标是分享最终用户正在踊跃应用的工具、他们举荐的工具以及他们的应用模式。更多对于该办法的信息能够在这里找到。 咱们也很快乐推出radar.cncf.io,在那里你能够找到其余雷达、投票,和代表的行业。 可察看性调查 在2020年8月,最终用户社区的成员被问及他们评估、试验并随后驳回了哪些可察看性解决方案。对283个数据点进行排序和复查,确定最终地位。 这能够解读为: “驳回(Adopt)”环中的五种工具被受访者宽泛驳回和举荐。“试验(Trial)”中的技术失去了一些最终用户的举荐,但他们要么没有失去足够的总体响应,要么只有多数人投了“驳回”票。“评估(Assess)”中的我的项目不足明确的共识。OpenTelemetry、Kiali和Thanos领有宽泛的认知度,但只有多数用户举荐驳回。寻找新的可察看性工具的组织在思考“评估”中的需要时应该思考到它们本人的需要。主题 主题形容了乏味的模式和编辑察看: 最罕用的工具是开源的。取得最多“驳回”投票的三个工具(Prometheus、Grafana、Elastic)和取得最多投票的五个工具(Prometheus、Grafana、Elastic、Jaeger、OpenTelemetry)都是开源的。乏味的是,公司曾经驳回并保护了这些开源零碎,并且可能通过外部投资将其扩大到足够大的部署。因为部署、保护和扩大这些开放源码零碎至多须要一个小团队,所以与应用SaaS提供商相比,公司仿佛认为这种衡量是值得的。 与此同时,在规模或工程能力方面,运行开源工具的公司和驳回可察看性SaaS平台的公司之间仿佛没有清晰的划分。不论公司是应用开源还是SaaS解决方案,OpenMetrics和OpenTelemetry等凋谢规范都被驳回。另外,一些最终驳回SaaS平台的公司在决定是否驳回自治理平台之前,的确经验了评估和构建原型的过程。兴许能够得出这样的论断:新技术的疾速倒退须要新的可察看性技术,而这又须要简直一直地评估和驳回新工具。 在可观测畛域中没有合并。许多公司应用多种工具:一半的公司应用5种或更多的工具,三分之一的公司有应用10种以上工具的教训。可察看性实质上要求从不同的视角查看数据,试图答复问题。不同的工具在不同的技术和集成中具备劣势,这可能是最终用户最终应用多种工具的起因。当被驳回,从一组工具转换到另一组工具或甚至合并可能会很艰难。对于大多数最终用户来说,可察看性并不是他们的外围业务,因而转换工具所需的投资往往不容易取得资金。这可能是为什么在这个雷达上有这么多“驳回”投票的一个重要起因。 乏味的是,公司始终在试验和引入新工具,寻找察看事物的更好办法。随着Kubernetes等云原生技术的呈现,须要应用不同的工具进行监控。例如,Nagios在五年前十分风行,然而对于须要监督Kubernetes工作负载的用户来说,当初曾经不那么重要了。 Prometheus和Grafana常常一起应用。三分之二的受访者同时应用这两种工具。这并不奇怪,但这种高度的相关性依然值得注意。这两个我的项目背地的能源,加上很少的竞争,能够帮忙它们取得如此高的驳回率。此外,还有许多教程和安装程序,使它们很容易一起应用。手拉手应用它们的阻力最小。编辑 Jon Moter是Zendesk的高级首席工程师。Jon在Foundation Engineering组织工作,该组织为Zendesk工程的其余部门提供计算、存储和云基础设施。Twitter:@jonmoterKunal Parmar是Box的软件开发总监。Kunal领导他们的云原生团队,推动了Kubernetes、服务网格和可观测性的驳回。Marcin Suterski是纽约时报的首席工程师。Marcin是交付工程团队的一部分,该团队为整个组织的工程团队提供工具、流程和教育。他目前的重点是可察看性。Jason Tarasovic是PayIt的首席工程师。Jason是平台工程团队的开创工程师,负责构建和运行他们的云原生平台。Twitter:@J_Tarasovic延长浏览 案例钻研:浏览Uber、Adform和Grafana Labs如何应用CNCF技术解决可察看性。 接下来 下一个CNCF最终用户技术雷达将于2020年12月公布,专一于云原生的一个不同主题。投票帮忙决定下一个CNCF最终用户技术雷达的主题。 退出CNCF最终用户社区: 意识谁在应用每个我的项目,并浏览他们的评论奉献和编辑将来的CNCF最终用户技术雷达咱们很快乐向社区提供这份报告,咱们也很乐意听到你的想法。反馈邮件发送到info@cncf.io。 对于办法 2020年8月,CNCF最终用户社区的140家公司形容他们的公司对不同解决方案的倡议:暂缓、评估、试验或驳回。他们也能够给出更具体的评论。因为答案是通过谷歌电子表格提交的,所以在小组中既不窃密也不匿名。 32家公司提交了对于34个解决方案的283个数据点。这些被排序以确定最终的地位。最初,编辑编写主题以反映更宽泛的模式。 点击浏览网站原文。 CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。 CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。

September 15, 2020 · 1 min · jiezi