CoreOS

CoreOS

CoreOS Tectonic 1.8可轻松将外部服务集成到Kubernetes

edge_dawn 发表了文章 • 0 个评论 • 1380 次浏览 • 2018-03-12 21:17 • 来自相关话题

【编者的话】CoreOS Tectonic 1.8版本,轻松将外部服务集成到Kubernetes。 CoreOS公布了其最新版本的流行Kubernetes容器编排工具Tectonic 1.8。它具有新的开放服务目录,使DevOps人员 ...查看全部
【编者的话】CoreOS Tectonic 1.8版本,轻松将外部服务集成到Kubernetes。

CoreOS公布了其最新版本的流行Kubernetes容器编排工具Tectonic 1.8。它具有新的开放服务目录,使DevOps人员能够轻松地将外部服务插入Kubernetes。

正如CoreOS的构造产品经理Rob Szumski在宣布新版本的公司博客中指出,公有云在易用性方面提供了许多好处,但它们最终可能会将您锁定在一些专有工具集中。

这正是新开放云服务目录旨在解决的问题。不需要使用这些专有工具,而使您可以获得更多开放性选择,并且可以更轻松地在云或混合云环境之间切换。

“对于Tectonic 1.8而言,CoreOS开放云服务提供了与客户对托管云产品所期望的几乎相同的几乎相同的操作,这些操作有所不同。与专有云服务不同,Open Cloud Services是非常一流的,可以在CoreOS Tectonic平台上全自动的运行Kubernetes资源,“Szumski在博客文章中写道。

null.png

CoreOS的目标是尽可能保持整个流程的开放性和可移植性,以便客户可以选择他们想要部署应用程序的位置和方式。更重要的是,Open Cloud Catalog内置于构造控制台中,使得启用外部服务变得简单(或根据您的选择禁用它们)。

初期提供的开放云服务包括etcd,Prometheus和Vault。

Open Cloud Service Catalog只是Tectonic 1.8版本的一部分,该版本与17年9月底发布的开源版本保持一致。正如CoreOS指出的那样,这是Kubernetes的一个纯粹的上游版本,这意味着它不是一个分支(云本机计算基金会成员一致致力于的Kubernetes开源项目)。

它还会自动更新Docker容器引擎(开发人员使用docker引擎创建应用程序的容器)。使用Kubernetes来管理和部署容器。这意味着,它在容器DevOps两个方面兼顾。

最新版本在17年底发布,该公司表示,将对现有CoreOS客户进行Tectonic 1.7的平稳的自动更新。

原文链接: CoreOS Tectonic 1.8 makes it easy to plug external services into Kubernetes(翻译:edge_dawn)

Red Hat收购CoreOS的真正原因

kurtzhong 发表了文章 • 0 个评论 • 2588 次浏览 • 2018-02-10 15:46 • 来自相关话题

上周,企业开源领头羊Red Hat发表声明将收购CoreOS,一个在火热的容器市场中大有前途的玩家。 表面上看,这次交易的动机很明显:Red Hat需要让自己的容器故事更加丰满,而CoreOS满足这个需求。 ...查看全部
上周,企业开源领头羊Red Hat发表声明将收购CoreOS,一个在火热的容器市场中大有前途的玩家。

表面上看,这次交易的动机很明显:Red Hat需要让自己的容器故事更加丰满,而CoreOS满足这个需求。

然而,就像基础设施市场的绝大多数厂商一样,他们的(意图)是复杂的——正如容器世界中所有其他事物都是复杂的一样。

可能会有人说,复杂度是关键。
# 让容器企业就绪
自从Docker公司2014年将容器技术带到企业基础设施软件革命前线之后,厂商和企业的开发者一直在真正的企业场景中实现容器技术的应用。

容器编排和容器管理是众多缺失的环节中的两个。容器编排能使企业大规模部署容器,处理弹性伸缩中的细枝末节,对容器的价值主张至关重要。

容器管理是容器编排价值主张的补充。它使容器编排的环境具有可见性和可控制性,并增强其安全性,使其具备企业层面上运行容器其他必需的能力。

领导着容器编排战场的是Kubernetes——一个主要出自Google的开源项目。Docker有自带的编排工具Swarm,但是Kubernetes具有产品成熟度的优势,已经在生机勃勃的开源生态系统中夺取了统治者地位。

但是Kubernetes并没有直接解决容器管理中的复杂度问题,这正是CoreOS试图用自己的Tectonic产品来填补的空档。“Tectonic将领先的容器管理解决方案和大规模运行容器所有所需结合起来”,CoreOS的网站这样说道,“这意味着其拥有最好的开源组件,久经沙场的安全系统,和完全自动化的运营。Tectonic是企业级Kubernetes。”
# 复杂度的挑战
如果用来满足企业需求在技术层面听起来很复杂,那你的感觉没错——容器自身的复杂度是一个有争议的区域。“与平台自身不一样,构建Kubernetes自身这个日常的预先任务是复杂艰难的”,RackN的CEO和创始人之一Rob Hirschfeld说,“多节点运营是复杂的:这是我们想要Kubernetes这样平台的原因”。

但是,Kubernetes却没有让容器变得更简单。“实际的情况是Kubernetes很复杂。安装好并让它运行起来颇具挑战——没有必要否认这一点。但是这种复杂度也可以反过来说是一个好处”,Matt Rogish,ReactiveOps的创始人说。“ECS和Docker Swarm表面看来似乎简单点,但是它们有更高的偶然复杂度——而且这个复杂度被强加给你。相反,Kubernetes偶然复杂度很低,本质复杂度(用来实现实际上需要的功能的复杂度)很高”。

在Kubernetes上增加额外的像CoreOS Tectonic的容器管理层也并没有降低其复杂度。反而是为了帮助机构管理它。“基于容器的应用正驱动着下一代的技术,它们跨多个或者混合云平台应用驱动,包括物理的、虚拟的,私有云和公有云平台”,Paul Cormier,Red Hat的产品和技术部门总裁说。“我们相信这次收购将会奠定Red Hat在混合云和现代应用部署的奠基石地位”。
# 似曾相识的复杂度:OpenStack
有巨大复杂度的开源企业基础设施软件并不是什么新鲜事。拿OpenStack为例,这个私有云基础设施先驱有大量的活动部件,它的生态系统十分多元化、拥挤不堪,这为它赢得了格外复杂和难以处理的名声。好几年我们都听到OpenStack这同样的事情”,RackN的Hirschfeld说道。

一点也不让人意外的是,过去几年吸引到OpenStack的注意力都转移到了Kubernetes和容器社区的其他地方——今天,OpenStack已经成了像CoreOS Tectonic这样的科技要解决的复杂度。CoreOS的官网上称,“Tectonic是全面Kubernetes解决方案,用来在任何地方部署、管理、和安全加固容器,它能结合OpenStack的优点,和Kubernetes的基于容器的工具链。有CoreOS在你左右,借助最好的容器基础设施,OpenStack将变的更容易管理和部署”。

CoreOS的网站继续说道,“OpenStack在复杂度方面的名声有时候盖过了它的能力。Kubernetes集群编排能让OpenStack的管理和管理更加容易”。

对于Red Hat来说,OpenStack的复杂度是一个它能帮助客户解决的问题。“容器使得应用在混合云环境具有了可移植性,所以客户今天能在不同的地方部署应用:在Amazon、Azure和Google这样的公有云上,在VMWare和OpenStack这样的本地部署平台上,或者在物理裸机上”,Joe Fernanes,Red Hat的负责OpenShift产品部资深管理经理解释说,“一直以来,我们在OpenShift和Kubernetes以及容器上的投入都是要建立起这种抽象,使得应用可以高效地在所有这些地方部署”。

Alex Polvi,CoreOS的CEO,在这个话题上发表了更加细致的观点。“通过把OpenStack作为一个应用在Kubernetes运行,我们能将这个数据中心整合成一个已经被超大规模的巨头验证的平台”。
# Red Hat的开源策略
Red Hat的商业模型集中在为本质上免费开源的软件提供支持和服务。然而,尽管CoreOS是基于开源构建的,Tectonic也包含商业代码。“我们想特别澄清的是CoreOS专注于开源项目和协作,即使这意味着我们对手可以与我们竞争,我们在保持这两个平台分离”,Kelsey Hightower在2015年当他还是CoreOS的开发者和提倡者的时候这样说。他现在是Google的Staff Developer Advocate。“有一个coreos.com,其是关于Linux容器开源项目的;然后tectonic.com是将这些项目结合起来组成一个商业解决方案的,但是它们并不与相关开源项目冲突”。

就其本身而言,Red Hat一直以来都是Kubernetes的一个主要贡献方。“Red Hat在拥抱容器和容器编排方面起步早,已经向相关的开源社区做了深度贡献,其中就包括Kubernetes,在其中是仅次于Google的第二大领导者。”Red Hat在一个新闻发布上解释道:“现在有了Red Hat和CoreOS的结合,Red Hat同时扩大了其在上游社区和基于容器的企业解决方案方面的领导力。”

在Red Hat是否会将Tectonic中的商业代码开源这一件事情上,他们的态度很谨慎。“CoreOS的绝大多数技术都已经开源”,Red Hat的FAQ列表解释道,“Red Hat长久以来都展示了将不开源的在必要时候开源的决心,我们没有理由看到我们在这条策略上会有什么改变”。
# 整理总结
作为一个开源厂商,Red Hat不是从软件的知识产权中获利——因此,CoreOS的IP价值对于这次收购关系很小。

这个故事实际上是关于人的,CoreOS公司有130名员工,从很多方面看这次交易是一次收购式招聘,同时借助Red Hat的专业团队来将为其企业客户提供了更加全方位服务。

相比较而言,这次交易与Red Hat的传统竞争者IBM和Oracle关系较小,与Docker公司竞争的关系更大。“它们的联合对于我而言是一次人才的合并……能壮大OpenShift Enterprise相较于Docker公司的Docker企业版的影响力”,BoxBoat的CTO,Will Kinard说。

OpenShift是Red Hat的PaaS方案,而且有一些CoreOS的技术和人力将会分别在OpenShift产品和OpenShift团队中找到更好的位置。

Janakiram & Associates分析师Janakiram MSV同意这种观点。“在企业领域,Red Hat是Docker公司的一个关键竞争者。这次收购将会给Docker公司带来压力,它们目前为止已经从不同的投资方募集到2.4亿美元。它必须加快在获取企业客户的速度,并且推动其商业产品的采用率。”


然而,对于Red Hat的客户来说,这场战斗是关于人才的——这是一个OpenStack和Kubernetes相继追随的模式。“客户不具有OpenStack的技术积累,它们只知道它们需要它”,Jon Keller,Technologent的field CTO说。“对于Kubernetes是同样的情况。它十分合适,因为它们无法找到足够多的人来自己做”。

容器生态如此复杂因而对于Red Hat来说是一个加分,特别是在混合IT情景增加了额外的复杂度的情况下。“我们相信这次收购会为Red Hat在混合云和现代应用部署打好奠基石”,Red Hat的Cormier总结说。

总之,Red Hat的客户成为最后的赢家。“我们相信我们最大的客户将会从中获益”,Red Hat的VP和总经理Ashesh Badani说。

CoreOS的技术和团队在Kubernetes方面已经具有全面的能力,它们的加入在混合IT的情景下能呈现出在今天可能最可靠和全面的现代基础设施。随着整个容器生态系统走向成熟,Red Hat的统治只会变得愈来愈强。

原文链接:The Real Reason Red Hat Is Acquiring CoreOS(翻译:钟最龙)

红帽收购完CoreOS,接下来将如何整合两家公司的Kubernetes产品?

sean 发表了文章 • 0 个评论 • 2693 次浏览 • 2018-02-07 18:21 • 来自相关话题

鉴于周二宣布的一项收购协议,Kubernetes容器编排领域内两个最突出的商业品牌将合二为一。率先打开容器市场,并带来精简Linux内核概念的CoreOS,现在成了红帽的全资子公司。根据即将成为红帽高管的CoreOS CEO Alex Polvi所述,该交易已 ...查看全部
鉴于周二宣布的一项收购协议,Kubernetes容器编排领域内两个最突出的商业品牌将合二为一。率先打开容器市场,并带来精简Linux内核概念的CoreOS,现在成了红帽的全资子公司。根据即将成为红帽高管的CoreOS CEO Alex Polvi所述,该交易已经完成,没有等待期。

Polvi说:“得益于此次收购,我们可以将两条产品线结合形成客户无法在市场上找到的一套无与伦比的机能。虽然我们的产品是竞争关系,但它们在很多方面是高度分化的。OpenShift和Tectonic看起来都是Kubernetes产品,但它们的工作方式及对客户的价值诉求完全不同。将这些东西组合在一起,将产生市场上所可能拥有的终极产品。”

这是一份来自即将变成前CEO的人的雄心勃勃的声明。从技术上说,这笔交易只是私下交易的一次收购,据报道,红帽历史上有过21笔类似的交易。虽然红帽通常不会公布其收购价值,但这笔CoreOS交易它给出的交易价值是2.5亿美元。该公司在2015年收购配置自动化公司Ansible首次公布协议时估值为1亿美元,不过此前有个独立调查将其估值定为1.5亿美元。
# 不确定的融合
红帽明确表示、同时也是急于宣布的是本次交易中浮现出来的基于Kubernetes的产品。

“我们面前有一个机会来做有意义的决定,”红帽负责OpenShift的副总Ashesh Badani以非常巧妙的措词说明Tectonic在OpenShift产品线中的位置尚未最终确定。

“我们将用几周时间而非几个月好好考虑最合理的方式。如何将这两种技术整合在一起,从而保留二者的精华部分?”Badani接着说。他说,Tectonic具有一定的商业客户份额,因此红帽在品牌整合时将尽可能保持这些客户所带来的价值。但是,他强调,OpenShift产品计划不会中断。

“给我们点时间,我们的工程师团队、产品团队、市场团队将坐在一起研究最佳的行进路线,”他说道。

难道CoreOS与红帽在签署协议前没有这样的坐谈机会?并非如此,Badani说,尽管谈判的财务部分进行得很充分,但与交易后业务相关的事项需要保密。因此,在写作本文时,Tectonic将采用的具体形式,以及它如何与红帽的OpenShift产品线并行或合并均尚无定论。

这是否意味着CoreOS大量人员,包括Polvi、CTO及联合创始人Brandon Philips以及工程师主管李响的命运都悬而未决?Badani明确表示CoreOS的开发和技术人才都将被邀请在红帽中留任,他强调说公司的员工是他心目中的重要资产。

Badani说,“这笔交易和伙伴关系的完成,依靠的是CoreOS为市场带来的大量工程人才和创新。如果我们未尽一切可能保证将Alex、Brandon以及所有其他人在内的整个工程和市场团队带入,那就是我们的责任。”他补充说,尽管头衔有待调整,他们从今天起就是该公司的正式成员。他说,产品的路线图可能需要做调整,这有助于最终决定他们的新头衔。
# CoreOS的核心所在
CoreOS的Polvi列出了他认为有别市场其他产品的独特的公司产品,并希望将他们整合到红帽产品线中。Quay(几乎没人读成“key”)私有容器注册中心是他希望能生存并发展下去的一个产品,就像etcd一样,后者是Kubernetes出现之后的事实键值仓库,也是红帽工程师的长期首选组件。

Container Linux也是Polvi提到的有可能在交易浮现出来的一个差异化产品——CoreOS的名字即来源于该产品。考虑到红帽自身是Linux操作系统的制造商,这可能是一厢情愿的想法。Atomic Linux已经是红帽企业Linux(RHEL)一个轻量级的发行版,旨在运行于由一个完善的中央REEL核心管理的分布式主机上。

红帽周二发布的FAQ显示,部分Container Linux交付机制可能被移植到Atomic上,特别是早在2015年与红帽竞争时,Brandon Philips引以为傲的CoreOS优于Atomic的在线更新系统。红帽将此移植形容为两个操作系统之间的“和解”。 这条消息似乎在宣布Container Linux被正式收购后不久消失了。

该消息促使CoreOS Tectonic产品经理Rob Szumski通过谷歌讨论组及Twitter中提供了一些补充说明。

Szumski写道:“Container Linux一直是免费提供的,我们预计这不会改变,红帽计划继续Container Linux的开发。事实上,与将Fedora的创新技术融入红帽企业Linux类似,我们可能会看到类似更新交付机制的Container Linux创新被融入其中。”

上述陈述中的关键词是“可能”。

与此同时,根据红帽和CoreOS的说法,rkt——这个在2015年首次挑起容器界短暂大分裂的容器格式和运行时——不在谈判桌的议题中。在去年被捐赠给云原生计算基金会(CNCF)后,rkt仍然可能会出现在一些客户驱动的实现中,不过Polvi告诉我们,他期望rkt能够根据自己的长处找到价值所在。

根据Polvi和Badani的说法,收购讨论中也未提及Docker或Docker Inc。

Badani说:“我们将持续接受开源社区中的每个合作机会。在竞争方面,我们并没有真正看到太多Docker的表现。过去几个月,随着亚马逊和微软Azure的加入,Kubernetes的市场势头非常明显。Docker最近才开始在这方面进行投入,因此还未展现出足够的竞争力。他们的Swarm编排技术不像他们所希望那么有竞争力,这就是他们也要投资Kubernetes的原因。我真的不担心他们。”

Polvi说:“CoreOS主要销售产品给那些想要使用Kubernetes的公司。目前企业用户能在市场上找到的Kubernetes产品实际上只有两种:Tectonic和OpenShift。Docker宣布了一款Kubernetes产品,现在已有一个Alpha或Beta产品,但是并没有准备就绪的企业销售团队。也许将来会发生变化,但客户现在需要Kubernetes。”

Docker在1月18日发布了Docker Enterprise的Beta版Kubernetes集成。
# 寻找Kubernetes市场
根据Polvi的算法,市面上将只有单一一个企业Kubernetes供应商。Kublr可能会对此感到震惊,但至少在这位前CEO的头脑中,他的产品与Red Hat的结合必将胜出。

不过这块蛋糕到底有多大?在去年秋天的一项调查中,CNCF请企业选择他们在生产中所使用的编排器,约69%的受访者表示他们使用了通用的Kubernetes,而OpenShift仅占总数的12%,Tectonic仅占4%。
01.jpg

当问题限定在占比23%、部署超过1000个容器的受访者子集时,OpenShift在该子集中的份额增长至17%。但Tectonic的份额减少了一半,而通用Kubernetes获得了3分。

所以也许这次收购可能会在Kubernetes市场有所作为,只是其市场本身在总体生态系统中占比不足三分之一。又或者,正如IT分析师Kurt Marko所认为的那样,这里面有市场的想法可能是一种幻觉。

Marko在写给The New Stack的报告中写道,“Kubernetes是集群管理/工作负载编排的事实标准。包括红帽在内的任何人都无法主宰这个市场,因为这不是一个真正的市场,它只是一个功能。”

Marko继续写道:“我真的不认为多数企业客户(比如经理、高管,而非开发人员)会考虑他们所运行的Linux发行版等细节。他们更感兴趣的是能够可靠安全地运行应用程序、能够提供良好的性能,并得到定期更新和问题响应支持的东西。如果CoreOS在容器方面工作更好,那很好,如果它捆绑在一个包含了Kubernetes、注册中心和虚拟网络结构(Contiv等)的容器平台中,那更好。”

Marko在红帽的产品线中确实看到了适合Container Linux的位置,特别是Tectonic作为OpenShift PaaS的基础架构平台。但是,这种天作之合现在几乎每周都会出现,有时甚至不需要并购或收购,思科上周就公布了自己的思科容器平台,这又是一个品牌化的Kubernetes服务。”

Marko写道:“我认为真正的‘战斗’将是赢取希望使用混合容器架构的用户,这种架构将内部部署和公共云容器服务无缝地结合在一起。在这一点上,红帽还有更多的工作要做,特别是考虑到谷歌/VMware和谷歌/思科的合作关系。”

因此,虽然这笔交易明显改变了开发者心目中Kubernetes的战场,并可能进一步边缘化Docker,但实际上可能不是那种用于表征软件平台成熟度的“市场整合”。更像是服务器市场一个主要选手找了个途径来利用一个产品的成功之处,如果这个产品从一开始就是商业化、专有化的,即使是一个金矿……没有人会听说它。

原文链接:Docker Who? By Acquiring CoreOS, Red Hat Aims to Be the Kubernetes Company(翻译:梁晓勇

红帽公司收购CoreOS,旨在拓展自身在Kubernetes与容器领域的领导地位

大卫 发表了文章 • 0 个评论 • 3813 次浏览 • 2018-01-31 08:11 • 来自相关话题

凭借CoreOS的加持,红帽公司将进一步加大技术开发力度,从而帮助客户立足混合与多云环境构建、运行并管理容器化应用程序。 作为全球规模最大的开源解决方案供应商,红帽公司今天宣布其已经签署一项最终协议,将收购Kubernetes与容器原 ...查看全部
凭借CoreOS的加持,红帽公司将进一步加大技术开发力度,从而帮助客户立足混合与多云环境构建、运行并管理容器化应用程序。

作为全球规模最大的开源解决方案供应商,红帽公司今天宣布其已经签署一项最终协议,将收购Kubernetes与容器原生解决方案领导者兼创新者CoreOS公司。此笔交易的总价为2.5亿美元,虽然可能在实际执行时作出些许调整,但幅度应不会太大。红帽公司对CoreOS的收购将进一步助力客户构建一切自身需要的应用程序,并将其部署在红帽灵活的开源环境当中。通过将CoreOS的补充性功能与红帽此前已经广泛推动的Kubernetes以及红帽OpenShift容器化产品相结合,开源巨头希望进一步加快其面向现代应用工作负载的领先混合云平台的普及与发展速度。

我们相信,此次收购将成为红帽旗下混合云与现代应用部署的发展基石。

——PAUL CORMIER,红帽公司产品与技术总裁

随着应用程序逐步向混合及多云环境迁移,越来越多的企业开始利用容器方案以简化与云环境对接的各类应用程序的构建、部署与移动工作。IDC公司指出,“目前,云采用、简化与可移植性方面正取得实质性进展,市场对于云服务的需求也在持续增长。预计在未来几年当中,云计算架构将成为企业客户的主要支出方向。而随着容器体系的日益复杂化,企业应在寻求应用平台供应商的帮助,从而更轻松地利用容器技术对现有生产性应用程序进行转换与扩展,最终将其顺畅运行在公有云或私有云环境之内。”

创立于2013年的CoreOS公司旨在为各种规模的企业构建并交付基础设施,帮助其获得与大型软件企业对等的运营环境、实现自动更新与服务器修复,并协助解决停机时间控制、安全性保障以及恢复能力实现等实际难题。自早期发布针对容器作出优化的轻量级Linux操作系统以来,相关技术使得可扩展与弹性容器化应用程序的广泛使用成为可能,这也令CoreOS成为这一技术领域内备受赞誉的领导者。

CoreOS公司亦是CoreOS Tectonic的缔造者,这是一套企业级Kubernetes平台,负责跨越私有云以及不同公有云供应商为企业客户提供自动化运营与可移植能力,且完全基于开源软件实现。该公司旗下还拥有CoreOS Quay,一套企业级容器注册方案。CoreOS公司亦因积极推动容器化应用程序层面的开源创新贡献而广受好评,具体包括身为Kubernetes的主要贡献者、创建并维护轻量级Linux发行版Container Linux(用于自动执行软件更新并简化容器运行)、推出Kubernetes分布式数据存储方案etcd、向云原生计算基金会(简称CNCF)捐赠应用程序容器引擎rkt,以及积极推动当前开放容器倡议(简称OCI)标准的普及等等。

红帽公司很早就开始接纳容器与容器编排技术,并对包括Kubernetes在内的相关开源社区作出深入贡献——事实上,红帽已经成为Kubernetes社区中仅次于谷歌的第二大贡献者。红帽公司在基于容器类应用的开发方面同样是全球范围内当之无愧的领导者,其重要成果正是红帽OpenShift(业界最全面的企业级Kubernetes平台)。如今与CoreOS合并之后,红帽公司将能够在上游社区与企业级容器解决方案领域进一步奠定自身的领导优势。

预计这笔交易不会对截至2018年2月28日的红帽公司第四财季或整个财年指标造成重大影响。

此笔交易预计将于2018年1月之内结束,但须遵循成交条件惯例。

感兴趣的朋友亦可访问红帽公司博客,通过其官网了解更多与收购相关的细节信息。

大力支持

Paul Cormier红帽公司产品与技术总裁指出:

“新的技术时代将受到跨多云与混合云环境(包括物理、虚拟、私有云以及公有云平台)的基于窗口类应用的有力驱动,而Kubernetes、容器以及Linux已经成为这一转型的核心所在。与红帽一样,CoreOS一直是推动这些创新的上游开源社区领导者,同时亦在为企业客户提供企业级Kubernetes服务方面保持领先地位。我们相信此次收购将帮助红帽公司进一步巩固混合云与现代应用部署的基础。”

Alex Polvi,CoreOS公司CEO指出:

“红帽与CoreOS的合作关系已经持续了很长时间。作为开源协作方,我们共同为容器及分布式系统开发出一系列关键性创新成果,并帮助将自动化运营转化为现实。此次合并标志着我们在推进共同目标方面迈入新的阶段,也意味着我们的这些重要技术成果将进一步在各类企业乃至世界范围内得到普及。在这里要感谢CoreOS大家庭、感谢我们的客户、合作伙伴。当然,最重要的是要感谢自由软件社区对我们使命的不懈支持,这一切都将以自动化运营方式令互联网体系变得更加安全。”

原文链接:Red Hat to Acquire CoreOS, Expanding its Kubernetes and Containers Leadership(翻译:David)

容器监控的基石Prometheus 2.0到来

codesun 发表了文章 • 0 个评论 • 4618 次浏览 • 2017-11-12 15:36 • 来自相关话题

【编者的话】本文为大家带来了Prometheus 2.0中新存储层需求的由来,主要的挑战,实现的简要介绍,以及相关的基准测试结果,相关领域人员可以参考一下。 Kubernetes使得复杂环境的管理变得容易,但是为了确保可用性,对Kub ...查看全部
【编者的话】本文为大家带来了Prometheus 2.0中新存储层需求的由来,主要的挑战,实现的简要介绍,以及相关的基准测试结果,相关领域人员可以参考一下。

Kubernetes使得复杂环境的管理变得容易,但是为了确保可用性,对Kubernetes组件以及群集上运行的所有应用程序进行操作深入分析至关重要。在CoreOS,我们相信监控是良好生产环境的基石,这也是我们投入开发Prometheus监控系统的原因。作为一个由Cloud Native Computing Foundation(CNCF)支持的项目,Prometheus迅速获得了基础设施及应用监控方面的热度,今天是它更进一步的时候。
01.png

CoreOS将Prometheus作为我们企业级Kubernetes平台Tectonic的集成组件,并且我们也一直在努力提升其对Kubernetes用户的价值。今年早些时候,我们分享了关于下一代Prometheus(version 2.0)的新存储层方面的工作。为了稳固这项工作,我们和Prometheus团队以及我们的用户进行了更加密切的合作。在3个alpha版本,6个beta版本以及3个RC版本之后,今天Prometheus 2.0正式宣布稳定版本。感谢Brian Brazil和Goutham Veeramachaneni,他们在这项工作中付出巨大。在我们探索该发行版的优点之前,让我们回过头来,先探讨一下我们为何需要一个新的存储层。
# 时间序列和动态环境
Prometheus关于监控的理念鼓励在堆栈的每一层都采用高度详细的度量工具。容器的状态,通过的请求流,甚至是运行于其中的应用的深层信息都通过度量工具对外可见。Prometheus带来了一款强力的查询语言帮助将度量数据汇总转换成行动方案。

Prometheus通过时间序列的方式收集和存储数据,它是通过固定间隔收集到的带有时间戳数据的序列。这种设计可以使运行中的容器轻松产生成千的时间序列。随着容器的规模从成百扩展到成千,在集群中很可能产生数百万被跟踪的时间序列。

为上百万的时间序列持续写入数据显然是一项技术难题。更糟糕的是,Kubernetes使得持续销毁和创建容器变得十分容易。该项模型对于持续部署,自动扩容以及批处理作业调度而言是极为强大的,因此只会随着时间的推移而变得越来越普遍。

每个容器都有一个独一无二的标识符,所有其时间序列均包含该标识符,以达到最佳的视角。因此当被跟踪的活跃时间序列总数大致固定时,Prometheus中可以对外访问的所有历史时间序列数据是持续增长的。允许查询十亿级的时间序列是一项全新的挑战,但我们决定让Prometheus很好地支持该特性。

新的存储引擎就是用来解决这项挑战的。受到全文搜索的启发,它使用倒排索引以提供对于Prometheus时间序列可能拥有的任意纬度进行快速检索。新的磁盘格式确保相关的时间序列数据良好分布,另外write-ahead日志也使得Prometheus 2.0n能够从崩溃中恢复。

Prometheus同样变得更易操作了。Prometheus 1.x的用户应该对调整期望负载的存储配置十分熟悉。然而,有了新的存储层之后,这些控制就不再需要了。
# 基准测
这项工作的真实结果是令人印象深刻的。Prometheus 2.0的资源消耗得到了显著降低,使用率更加稳定,并且新的索引方式带来了更低且一致的查询延迟。

下方的图是一个基准测试集的结果,它来自一个运行着成百个应用Pod并被监控的Kubernetes集群。Pod按照高频率替换以产生时间序列的扰动。各有2个Prometheus 1.5和Prometheus 2.0实例运行采集新数据。不同版本中,各有1个实例对外服务,以产生适中性的高查询负载。

从前2个图中,我们可以看到Prometheus 2.0的内存和CPU消耗均明显更低,并且自启动后,它们很快到达稳定状态。Prometheus 1.5则需要更多的资源,并且其资源使用率难以预测。
02.png

03.png

Prometheus 2.0中最大的改进是其每秒写入磁盘的数据量,可以查看下图。新版本的写入量较之前低了近2个数量级。很明显,这能增加SSD的寿命(译者:SSD寿命由PE次数决定,与写入数据量密切相关),进而降低成本。在高序列扰动的情况下,即使使用相同的序列压缩算法,依旧可以观察到显著的磁盘空间节省。
04.png

在Prometheus 1.5中,随着更多的时间序列被创建,查询的延迟是线性增长的。Prometheus 2.0则从一开始就维持了稳定的性能,它使得查询的反馈更加敏捷,正如下图所示。
05.png

# 其余新特性
Prometheus 2.0的大多数工作都聚焦于提升性能并使其更加易于操作。但是新的存储层同样被设计以更好地和Prometheus的外部交互,这使得围绕收集到的时间序列数据进行广泛的定制处理成为可能。

快照备份是一项被频繁要求的特性。当使用flag `--web.enable-admin-api`时,只需要通过简单的API调用,Prometheus 2.0便可原生支持它们。
bash
$ curl -XPOST http:///api/v2/admin/tsdb/snapshot
{"name":"2017-10-18T13:44:35Z-3f6a679bb001e65d"}

快照存放于名为返回值的目录中,且可以被上传到归档存储中,它们几乎不会占用额外的磁盘空间。最棒的是,新的Prometheus服务器可以从备份的数据启动,你只需将数据移动到新的服务器数据目录中即可。

关于完整的变更列表以及如何从Prometheus 1.x迁移,请查看官方声明以及迁移指南
# 敬请尝试
有关Prometheus 2.0增强的最佳部分是,Prometheus当前不但可以比以往更好地支持Kubernetes的工作负载,更在于当Kubernetes在基础设施中活力倍增时,它预留了足够的空间来支撑届时的工作负载。

想要了解Prometheus,请关注11月16日上午8时webinar上关于新特性的PT(来自Prometheus开发者Frederic Branczyk)。

如果你想要亲自了解集成Prometheus支持是如何使得CoreOS Tectonic成为真正的企业级Kubernetes平台的,你可以免费部署一个不多于10个节点的Tectonic集群。你将能够使用最新的Prometheus操作器不费吹灰之力地在集群中部署Prometheus 2.0,而无需额外的配置。

声明:本文中的基准测试通过prombench生成。为了复现它们,你需要一个配置好的AWS账户,并且你必须指定想要执行的基准测试spec。`spec.example.yaml`正是生成本文所用图的spec。
# 相关文章

+ Prometheus 2.0: New storage layer dramatically increases monitoring scalability for Kubernetes and other distributed systems
+ The Prometheus Operator: Managed Prometheus setups for Kubernetes
+ Monitoring Kubernetes with Prometheus | Prometheus Docker Monitoring
+ CoreOS and Prometheus: Building monitoring for the next generation of cluster infrastructure

原文链接:Prometheus, the backbone of container monitoring, hits 2.0(翻译:孙科)

为什么我们创立CoreOS

cyeaaa 发表了文章 • 0 个评论 • 1688 次浏览 • 2017-09-20 22:46 • 来自相关话题

【编者的话】经常有人问,我们为什么要创立CoreOS。以前写过,我们的使命是保护互联网安全,更进一步讲:为什么我们会关注互联网安全?这个是CoreOS的核心问题,保护互联网安全是保护我们的隐私以及最终自由的关键。 # 自由,隐私与安全 ...查看全部
【编者的话】经常有人问,我们为什么要创立CoreOS。以前写过,我们的使命是保护互联网安全,更进一步讲:为什么我们会关注互联网安全?这个是CoreOS的核心问题,保护互联网安全是保护我们的隐私以及最终自由的关键。

# 自由,隐私与安全
“我相信自由。”,那种马丁•路德•金所指的自由。正是这种自由激发了我对自由软件的热情。然而我也相信我们生活的时代,生活和技术以某种限制自由的方式交织在一起。

科技给生活带来了巨大的进步,但也有和隐私冲突的倾向。

美国宪法,特别是《权利法案》确立了保护隐私权,因为隐私是自由的基础。试想选举投票过程:如果因为怕被监视而不能做出自己认可的选择,就不是自由选举了。

随着我们的生活越来越数字化——从物流服务到食品配送,甚至恒温器和冰箱都要接入互联网——它们越来越多地被掌握在以云服务方式提供新产品的公司手中。如果这些云服务没有正确地构建和及时地维护,将不可避免地被黑客攻击。一旦它们被黑客入侵了,我们会失去有些隐私并损害我们的自由。

这就是我们为什么要创立CoreOS,保护互联网安全。因为一次次地看到,数以百万计的数据,在重大数据泄露中遭受破坏,我们就铺了一个大家都可以对此来做点什么的路。

# 防止数据泄露
最近,Equifax被黑事件就是个很好的例子。 Equifax是一家信贷报告公司,被迫成为云服务公司。因为一个开源软件的安全更新安装失败,导致Equifax的系统被黑客入侵。它是人类历史上最大的隐私泄露事件之一,也是对自由世界最大的打击之一。这使我深受困扰。我相信,CoreOS是解决方案的一个重要组成部分。

在CoreOS,我们的目标是通过工具创建他们的云服务来武装这些公司以及正确地运行我们的数字生活。我们也致力于,让他们自己能够轻松地运行这些高度复杂的系统。不会再错过任何更新,默认启用全部安全功能,新版本应用也会安全快速地交付。

作为CoreOS的联合创始人兼首席执行官,我对迄今为止所取得的成就感到非常自豪。 我们还没有结束。没有什么比与CoreOS团队合作,更值得让我献身的事了。

想了解CoreOS的企业级Kubernetes平台如何让系统更容易管理,更可靠,更安全,请试用Tectonic today


原文链接:为什么我们创立CoreOS(翻译:陈晏娥, 校对:田浩浩)

===========================================
译者介绍
陈晏娥,鞍钢集团矿业公司信息开发中心高级工程师,专注虚拟化技术。

CentOS 7上搭建安全、容灾、高可用的etcd集群

张夏 发表了文章 • 1 个评论 • 14209 次浏览 • 2017-08-06 22:38 • 来自相关话题

【编者的话】etcd 是 CoreOS 团队发起的开源项目,基于 Go 语言实现,做为一个分布式键值对存储,通过分布式锁,leader选举和写屏障(write barriers)来实现可靠的分布式协作。 本文目标是部署一个基于TLS( ...查看全部
【编者的话】etcd 是 CoreOS 团队发起的开源项目,基于 Go 语言实现,做为一个分布式键值对存储,通过分布式锁,leader选举和写屏障(write barriers)来实现可靠的分布式协作。

本文目标是部署一个基于TLS(Self-signed certificates)的安全、快速灾难恢复(Disaster Recovery, SNAPSHOT)的高可用(High Availability)的etcd集群。
##准备工作
版本信息:
OS: CentOS Linux release 7.3.1611 (Core) 
etcd Version: 3.2.4
Git SHA: c31bec0
Go Version: go1.8.3
Go OS/Arch: linux/amd64

##机器配置信息
CoreOS官方推荐集群规模5个为宜,为了简化本文仅以3个节点为例:
NAME       ADDRESS	          HOSTNAME	                  CONFIGURATION
infra0 192.168.16.227 bjo-ep-kub-01.dev.fwmrm.net 8cpus, 16GB内存, 500GB磁盘
infra1 192.168.16.228 bjo-ep-kub-02.dev.fwmrm.net 8cpus, 16GB内存, 500GB磁盘
infra2 192.168.16.229 bjo-ep-kub-03.dev.fwmrm.net 8cpus, 16GB内存, 500GB磁盘

官方建议配置
硬件            通常场景                    重负载
CPU 2-4 cores 8-18 cores
Memory 8GB 16GB-64GB
Disk 50 sequential IOPS 500 sequential IOPS
Network 1GbE 10GbE

注:重负载情况以CPU为例,每秒处理数以千计的client端请求。AWS、GCE推荐配置请参考:Example hardware configurations on AWS and GCE
##搭建etcd集群
搭建etcd集群有3种方式,分别为Static, etcd Discovery, DNS Discovery。Discovery请参见官网https://coreos.com/etcd/docs/latest/op-guide/clustering.html,在此不再敖述。本文仅以Static方式展示一次集群搭建过程。
每个node的etcd配置分别如下:
$ /export/etcd/etcd --name infra0 --initial-advertise-peer-urls http://192.168.16.227:2380 \
--listen-peer-urls http://192.168.16.227:2380 \
--listen-client-urls http://192.168.16.227:2379,http://127.0.0.1:2379 \
--advertise-client-urls http://192.168.16.227:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=http://192.168.16.227:2380,infra1=http://192.168.16.228:2380,infra2=http://192.168.16.229:2380 \
--initial-cluster-state new

$ /export/etcd/etcd --name infra1 --initial-advertise-peer-urls http://192.168.16.228:2380 \
--listen-peer-urls http://192.168.16.228:2380 \
--listen-client-urls http://192.168.16.228:2379,http://127.0.0.1:2379 \
--advertise-client-urls http://192.168.16.228:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=http://192.168.16.227:2380,infra1=http://192.168.16.228:2380,infra2=http://192.168.16.229:2380 \
--initial-cluster-state new

$ /export/etcd/etcd --name infra2 --initial-advertise-peer-urls http://192.168.16.229:2380 \
--listen-peer-urls http://192.168.16.229:2380 \
--listen-client-urls http://192.168.16.229:2379,http://127.0.0.1:2379 \
--advertise-client-urls http://192.168.16.229:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=http://192.168.16.227:2380,infra1=http://192.168.16.228:2380,infra2=http://192.168.16.229:2380 \
--initial-cluster-state new

##TLS
etcd支持通过TLS加密通信,TLS channels可被用于集群peer间通信加密,以及client端traffic加密。Self-signed certificates与Automatic certificates两种安全认证形式,其中Self-signed certificates:自签名证书既可以加密traffic也可以授权其连接。本文以Self-signed certificates为例,使用Cloudflare的cfssl很容易生成集群所需证书。
首先,安装go以及设置环境变量GOPATH
$ cd /export
$ wget https://storage.googleapis.com/golang/go1.8.3.linux-amd64.tar.gz
$ tar -xzf go1.8.3.linux-amd64.tar.gz

$ sudo vim ~/.profile
$ export GOPATH=/export/go_path
$ export GOROOT=/export/go/
$ export CFSSL=/export/go_path/
$ export PATH=$PATH:$GOROOT/bin:$CFSSL/bin

$ source ~/.profile

下载并build CFSSL工具, 安装路径为$GOPATH/bin/cfssl, eg. cfssl, cfssljson会被安装到/export/go_path目录。
$ go get -u github.com/cloudflare/cfssl/cmd/cfssl
$ go get -u github.com/cloudflare/cfssl/cmd/cfssljson

初始化certificate authority
$ mkdir ~/cfssl
$ cd ~/cfssl
$ cfssl print-defaults config > ca-config.json
$ cfssl print-defaults csr > ca-csr.json

配置CA选项, ca-config.json文件内容如下
{
"signing": {
"default": {
"expiry": "43800h"
},
"profiles": {
"server": {
"expiry": "43800h",
"usages": [
"signing",
"key encipherment",
"server auth"
]
},
"client": {
"expiry": "43800h",
"usages": [
"signing",
"key encipherment",
"client auth"
]
},
"peer": {
"expiry": "43800h",
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
]
}
}
}

ca-csr.json Certificate Signing Request (CSR)文件内容如下
{
"CN": "My own CA",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "US",
"L": "CA",
"O": "My Company Name",
"ST": "San Francisco",
"OU": "Org Unit 1",
"OU": "Org Unit 2"
}
]

用已定义的选项生成CA:cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
2017/08/02 00:56:03 [INFO] generating a new CA key and certificate from CSR
2017/08/02 00:56:03 [INFO] generate received request
2017/08/02 00:56:03 [INFO] received CSR
2017/08/02 00:56:03 [INFO] generating key: rsa-2048
2017/08/02 00:56:04 [INFO] encoded CSR
2017/08/02 00:56:04 [INFO] signed certificate with serial number 81101109133309828380726760425799837279517519090

会在当前目录下生成如下文件

ca-key.pem
ca.csr
ca.pem

注:保存好ca-key.pem文件。

生成server端证书:
$ cfssl print-defaults csr > server.json

server.json内容如下:
{
"CN": "server",
"hosts": [
"127.0.0.1",
"192.168.16.227",
"192.168.16.228",
"192.168.16.229",
"bjo-ep-kub-01.dev.fwmrm.net",
"bjo-ep-kub-02.dev.fwmrm.net",
"bjo-ep-kub-03.dev.fwmrm.net"
],
"key": {
"algo": "ecdsa",
"size": 256
},
"names": [
{
"C": "US",
"L": "CA",
"ST": "San Francisco"
}
]
}
接下来生成server端证书以及private key
$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server server.json | cfssljson -bare server

$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server server.json | cfssljson -bare server
2017/08/02 00:57:12 [INFO] generate received request
2017/08/02 00:57:12 [INFO] received CSR
2017/08/02 00:57:12 [INFO] generating key: ecdsa-256
2017/08/02 00:57:12 [INFO] encoded CSR
2017/08/02 00:57:12 [INFO] signed certificate with serial number 138149747694684969550285630966539823697635905885

将会生成如下文件:
server-key.pem
server.csr
server.pem

生成peer certificate
$ cfssl print-defaults csr > member1.json

替换 CN和hosts值,如下:
{
"CN": "member1",
"hosts": [
"127.0.0.1",
"192.168.16.227",
"192.168.16.228",
"192.168.16.229",
"bjo-ep-kub-01.dev.fwmrm.net",
"bjo-ep-kub-02.dev.fwmrm.net",
"bjo-ep-kub-03.dev.fwmrm.net"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "US",
"ST": "CA",
"L": "San Francisco"
}
]

生成 member1 certificate与private key
$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=peer member1.json | cfssljson -bare member1

$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=peer member1.json | cfssljson -bare member1
2017/08/02 00:59:12 [INFO] generate received request
2017/08/02 00:59:12 [INFO] received CSR
2017/08/02 00:59:12 [INFO] generating key: rsa-2048
2017/08/02 00:59:13 [INFO] encoded CSR
2017/08/02 00:59:13 [INFO] signed certificate with serial number 222573666682951886940627822839805508037201209158

得到如下文件:
member1-key.pem
member1.csr
member1.pem

在集群其他节点上重复如上步骤。
生成 client certificate
$ cfssl print-defaults csr > client.json

client.json内容如下:
{
"CN": "client",
"hosts": [
"127.0.0.1",
"192.168.16.227",
"192.168.16.228",
"192.168.16.229"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "US",
"ST": "CA",
"L": "San Francisco"
}
]

生成client certificate
$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client client.json | cfssljson -bare client 

将会得到如下文件
client-key.pem
client.csr
client.pem

拷贝节点1生成的证书到全部节点,并将证书全部置于/etc/ssl/etcd/目录, 至此TLS证书全部生成完成。

测试TLS
示例1: 客户端到服务器采用HTTPS客户端证书授权
启动etcd服务:
$ /export/etcd/etcd -name infra0 --data-dir infra0 \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem --cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--advertise-client-urls=https://127.0.0.1:2379 --listen-client-urls=https://127.0.0.1:2379

插入数据:
$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/foo -XPUT -d value=bar -v

读取数据成功
$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/foo
{"action":"get","node":{"key":"/foo","value":"bar","modifiedIndex":12,"createdIndex":12

示例2:Using self-signed certificates both encrypts traffic and authenticates its connections.
各节点的etcd配置分别如下
$ /export/etcd/etcd \
--name infra0 \
--initial-advertise-peer-urls https://192.168.16.227:2380 \
--listen-peer-urls https://192.168.16.227:2380 \
--listen-client-urls https://192.168.16.227:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.227:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member1.pem --peer-key-file=/etc/ssl/etcd/member1-key.pem

$ /export/etcd/etcd \
--name infra1 \
--initial-advertise-peer-urls https://192.168.16.228:2380 \
--listen-peer-urls https://192.168.16.228:2380 \
--listen-client-urls https://192.168.16.228:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.228:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member2.pem --peer-key-file=/etc/ssl/etcd/member2-key.pem

$ /export/etcd/etcd \
--name infra2 \
--initial-advertise-peer-urls https://192.168.16.229:2380 \
--listen-peer-urls https://192.168.16.229:2380 \
--listen-client-urls https://192.168.16.229:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.229:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member3.pem --peer-key-file=/etc/ssl/etcd/member3-key.pem

准备测试数据:
$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/fristname -XPUT -d value=Xia -v

$ ETCDCTL_API=3 /export/etcd/etcdctl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.229:2379 put lasttname 'Zhang'

验证测试结果:
$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/
{"action":"get","node":{"dir":true,"nodes":[{"key":"/foo","value":"bar","modifiedIndex":19,"createdIndex":19},{"key":"/fristname","value":"Xia","modifiedIndex":20,"createdIndex":20},{"key":"/lasttname","value":"Zhang","modifiedIndex":21,"createdIndex":21}]

##etcd Troubleshooting
etcd failure主要分为如下5种情况:
  1. 少数followers failure
  2. Leader failure
  3. 多数failure
  4. Network partition
  5. 启动时失败
接下来主要对上面情况3进行处理,也就是平时常说的Disaster Recovery
##灾备恢复(Disaster Recovery)
以etcd v3 provides snapshot 方式为例说明etcd一次灾难恢复过程。
首先,etcd正常工作时利用etcdctl snapshot save命令或拷贝etcd目录中的member/snap/db文件,以前者为例:
$ ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshot.db}}
如果enable TLS,需要如下命令:
{{{$ ETCDCTL_API=3 /export/etcd/etcdctl --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.228:2379 snapshot save snapshot.db --cacert=/etc/ssl/etcd/ca.pem --cert=/etc/ssl/etcd/client.pem --key=/etc/ssl/etcd/client-key.pem

Snapshot saved at snapshot.db

将生成snapshot拷贝到集群其他2个节点上,所有节点灾备的恢复都用同一个snapshot。

插入部分数据用于测试灾备:
$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/fristname -XPUT -d value=Xia -v

$ ETCDCTL_API=3 /export/etcd/etcdctl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.229:2379 put lasttname 'Zhang'

测试数据已插入成功:
$ ETCDCTL_API=3 /export/etcd/etcdctl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.229:2379  get  firstname

$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/
{"action":"get","node":{"dir":true,"nodes":[{"key":"/foo","value":"bar","modifiedIndex":19,"createdIndex":19},{"key":"/fristname","value":"Xia","modifiedIndex":20,"createdIndex":20},{"key":"/lasttname","value":"Zhang","modifiedIndex":21,"createdIndex":21}]

停止3个机器的etcd服务,并删除全部节点上etcd数据目录 。
恢复数据,以TLS enable为例,分别在3个节点执行如下命令进行恢复:
$ ETCDCTL_API=3 /export/etcd/etcdctl snapshot restore snapshot.db \
--name infra0 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-token etcd-cluster-1 \
--initial-advertise-peer-urls https://192.168.16.227:2380 \
--cacert /etc/ssl/etcd/ca.pem \
--cert /etc/ssl/etcd/client.pem \
--key /etc/ssl/etcd/client-key.pem

$ ETCDCTL_API=3 /export/etcd/etcdctl snapshot restore snapshot.db \
--name infra1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-token etcd-cluster-1 \
--initial-advertise-peer-urls https://192.168.16.228:2380 \
--cacert /etc/ssl/etcd/ca.pem \
--cert /etc/ssl/etcd/client.pem \
--key /etc/ssl/etcd/client-key.pem

$ ETCDCTL_API=3 /export/etcd/etcdctl snapshot restore snapshot.db \
--name infra2 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-token etcd-cluster-1 \
--initial-advertise-peer-urls https://192.168.16.229:2380 \
--cacert /etc/ssl/etcd/ca.pem \
--cert /etc/ssl/etcd/client.pem \
--key /etc/ssl/etcd/client-key.pem

恢复数据log示例:
$ ETCDCTL_API=3 /export/etcd/etcdctl snapshot restore snapshot.db   --name infra0   --initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380   --initial-cluster-token etcd-cluster-1   --initial-advertise-peer-urls https://192.168.16.227:2380   --cacert /etc/ssl/etcd/ca.pem   --cert /etc/ssl/etcd/client.pem   --key /etc/ssl/etcd/client-key.pem
2017-08-06 04:09:12.853510 I | etcdserver/membership: added member 3e5097be4ea17ebe [https://192.168.16.229:2380] to cluster cabc8098aa3afc98
2017-08-06 04:09:12.853567 I | etcdserver/membership: added member 67d47e92a1704b1a [https://192.168.16.227:2380] to cluster cabc8098aa3afc98
2017-08-06 04:09:12.853583 I | etcdserver/membership: added member b4725a5341abf1a0 [https://192.168.16.228:2380] to cluster cabc8098aa3afc98

接下来,在3个节点上分别执行:
$ /export/etcd/etcd \
--name infra0 \
--initial-advertise-peer-urls https://192.168.16.227:2380 \
--listen-peer-urls https://192.168.16.227:2380 \
--listen-client-urls https://192.168.16.227:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.227:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member1.pem --peer-key-file=/etc/ssl/etcd/member1-key.pem

$ /export/etcd/etcd \
--name infra1 \
--initial-advertise-peer-urls https://192.168.16.228:2380 \
--listen-peer-urls https://192.168.16.228:2380 \
--listen-client-urls https://192.168.16.228:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.228:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member2.pem --peer-key-file=/etc/ssl/etcd/member2-key.pem

$ /export/etcd/etcd \
--name infra2 \
--initial-advertise-peer-urls https://192.168.16.229:2380 \
--listen-peer-urls https://192.168.16.229:2380 \
--listen-client-urls https://192.168.16.229:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.229:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member3.pem --peer-key-file=/etc/ssl/etcd/member3-key.pem

验证灾备恢复效果,原集群数据是否保存:
$ ETCDCTL_API=3 /export/etcd/etcdctl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.229:2379 get lasttname
lasttname
Zhang

$ ETCDCTL_API=3 /export/etcd/etcdctl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.229:2379 get firstname
firstname
Xia

从上面结果可以看出,灾备恢复成功。
##etcd系统限制
  1. 请求大小限制:当前支持 RPC requests 1MB 数据,未来会有所增加或可配置
  2. 存储大小限制:默认 2GB存储,可配置 --quota-backend-bytes扩展到8GB

##监控
etcd提供基于Prometheus + builtin Grafana的etcd Metrics监控方案和监控项,具体请参见
etcd Metrics: https://coreos.com/etcd/docs/latest/metrics.html

获取监控项举例
$  curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/metrics

etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="1"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="2"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="4"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="8"} 0

... ...

process_start_time_seconds 1.50390583624e+09
process_virtual_memory_bytes 1.0787151872e+10

Prometheus + builtin Grafana: https://coreos.com/etcd/docs/latest/op-guide/monitoring.html

欢迎转载,请注明作者出处:张夏,FreeWheel Lead Engineer,DockOne社区


Coreos 如何修改由cloud-config ,安装时生成的配置文件,重启系统后不被还原。

回复

Bruce Xiong 发起了问题 • 1 人关注 • 0 个回复 • 2203 次浏览 • 2017-07-28 15:16 • 来自相关话题

为什么CoreOS携手开源?

xiao_ye2000 发表了文章 • 0 个评论 • 2728 次浏览 • 2017-07-03 13:36 • 来自相关话题

【编者的话】本文通过日常研发中遇到的问题,提出引入开源项目的重要性,介绍了CoreOS协助创立的CNCF以及它赞助的一些项目,同时也介绍了Kubernetes社区的一些现状和未来发展的展望。 【3 天烧脑式容器存储网络训练营 | 深圳 ...查看全部
【编者的话】本文通过日常研发中遇到的问题,提出引入开源项目的重要性,介绍了CoreOS协助创立的CNCF以及它赞助的一些项目,同时也介绍了Kubernetes社区的一些现状和未来发展的展望。

【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。

CoreOS构建开源软件。为什么携手开源软件呢?因为要解决的问题规模巨大,在宏观的层面需要革新。预计:

* 今时今日有3,646,000,000的因特网用户;
* 29,000,000的软件开发者和IT从业者;
* 去年新增了238,975,082的因特网用户;
* 全球大概有100,000,000左右的服务器。

显然我们作为软件工程师和管理员是忙不过来的。开源软件是使这一扩展成为财富的关键,大家在各种环境中合作处理最难的操作问题,例如管理安全性、可靠性以及可移植性。

大概三年半前,我们开始一起用工具套件解决分布式系统中解锁计算可移植层。随着Container Linux、Docker、Kubernetes等的引入,基于软件容器的生态系统开始形成。
coreos.png

#构建Container Linux
CoreOS Container Linux,为容器世界创造的开源操作系统,大概四年前开始研发,设计理念是容器把Linux推向了一个全新的道路,需要对安全、性能以及宽平台多方面支持的全新版本。因此我们构建了一个有快速发布Linux内核特性的OS,尤其是在容器化优化方面。

Container Linux现在被广泛的采用运行于各种云平台以及裸金属平台上。
#CoreOS创建CNCF中的开源项目:rkt和CNI
至此,我们已经协助建立了CNCF(the Cloud Native Computing Foundation)并且捐助了包含rktCNI等一些关键容器技术。这些开源项目由CoreOS工程师发起并且在容器生态系统中的成功提供了一定的帮助。

最新的rkt发布版本自从被加入到CNCF以来,第一次对于帮助促进这次发布的社区成员表示了极大的感谢。本次发布新加入了很多贡献者,同时也提出了基于Xen stage1的建议。

CNI是容器中的网络系统插件,它使得类似Kubernetes之类的管理平台更容易的支持IPAM、SDN或者其它网络方案。CoreOS几年前创造了CNI,以实现跨容器的解决方案和计算环境之间简单网络的可互相操作性。CNI有着一个蓬勃发展的第三方网络解决方案社区,用户可以从那里选择网络插件加入到Kubernetes容器架构中去。我们很高兴看到这些广泛采用的系统加入到CNCF中。
#对于Prometheus监控引擎的贡献
监控架构软件和系统对于创建一个可靠的生产环境至关重要,Promethus事实上是Kubernetes生态系统的监控系统。鉴于其重要性,CoreOS在这个项目上投入了一定的人力并且把项目往可扩展性方向做出了很有意义的推进。社区对于可扩展性的关注是即将推出的Prometheus 2.0版本的前沿和中心,这个版本提供了时序存储层上的很大提升,旨在解决当前工作负载的瞬态性。
#Celebrating Clair 2.0
Clair是CoreOS建立的一个安全项目,完成容器镜像的静态分析并将它的内容和公共漏洞数据库相关联。Quay安全扫描的核心就是Clair,但是它也支持其它许多需要容器镜像扫描的项目。

今天我们庆祝Clair 2.0的发布,包含Alpine Linux扫描等附加功能。这是个重要的里程碑的发布,感谢参与的43的贡献者。
#联盟的Kubernetes状态
我们致力于创建一个强有力的Kubernetes开发社区,有着与之匹配的客户和合作伙伴的更广泛的社区。去年Kubernetes社区已经达成了几个重要的里程碑,包括几个稳定版本,一群增长中的贡献者,另外Kubernetes指导委员会的启动也帮助组织项目在未来几年进一步发展。
##项目治理和发布
Kubernetes处理问题的空间是巨大的!Kubernetes社区发展快速的原因是由于社区组织的能力组织成了一个个的小团队,称为特别兴趣组)。这些组织可以从横向跨项目的问题,如集群安装或认证/授权到更多的纵向问题,如Azure集成。然而当需要对创建新的资源库、划分新的发布版本包括新的API或者删除未进过测试的代码等操作跨SIG决定的时候,谁做出最后的确定就很不清晰。

几个月前,Kubernetes社区创立了一个管理引导委员会在如何处理这类问题上做出建议。最近引导委员会发布了一系列重要的建议和文档包括成立Kubernetes指导委员会全职解决项目组织问题。计划八月初建立Kubernetes指导委员会。
##未来的展望
最后,让我们期待接下来几个Kubernetes发布版本里的一些特性和能力。我从LWN的Jon Corbet对常规Linux内核的预测获得启发。然后我的工作比Jon的更容易,Kubernetes社区开发了一个相对中心化的特性以及设计计划系统,因此对于这些预测,我有很高的信心相信它们都会成真。

核心部署API正在转向稳定:这很容易预测,因为Kubernetes社区的很多人都致力于将它实现。Kubernetes社区正在快速地把重要的API添加到项目中,例如通过DaemonSets支持长时间运行的节点服务、通过StatefulSets支持静态状态应用以及通过Deployments支持滚动升级等工作负载。这些API已经被用户的很多发布版本证明且已经做好了转成稳定版本的准备。

一致性和自动集群配置:Kubernetes有很多动态的部分,从API server和Scheduler到kubelet和kube-proxy。这些每个组件都需要获取密文和可调参数。现在这些都是通过命令行参数实现;但是管理这些组件非常困难,需要重启才能更新,而且对于版本更新来说是不大可能的。目前正在研发通过配置文件映射到称为组件配置的API对象,使配置更加一致,更容易自动化。

通过TPRs扩展和API的聚合:对于创建集群应用的人们来说,Kubernetes的API已经成为了一个很便捷的系统。这是因为这些API有着友好的命令行工具,基于角色的接入控制并且可以插入很多用户认证系统。因此,人们创建了许多应用并将资源保存到Kubernetes中,这些资源称为第三方资源,另外还有个新的API聚合子系统用来启动API,可以在server端验证,和Kubernetes API版本集成,并且后台可以是不同的数据存储。

应用在Kubernetes API之上编译:基于Kubernetes API的扩展能力,已经出现了虚火基于该API的应用。这包含从数据库、认证鉴权以及用户应用特定工作流的许多应用。这些应用的管理员将可以利用Kubernetes提供的所有功能包括日志、调试和监控工具等。

更多的用Metrics API监控驱动API:并不是只有外部应用才被Kubernetes中新的API聚合启动。SIG Instrumentation现在正在创立一个metrics API服务器,可以随着现如今用户创建的越来越大规模的集群而扩展。这也使得Kubernetes内部更多的监控驱动决定系统变得可能:基于用户的指标自用扩缩,更好的首选管理工具就更容易插入到例如Prometheus等时序数据库中。
#朝着光明的未来迈进
非常感谢所有人和我们在许多开源容器生态环境中关键项目中一起工作并取得成功。我们鼓励你们加入到开源和分布式系统的旅程中。或者,跟我们合作吧!CoreOS正在招聘

原文链接:Why CoreOS Builds with Open Source(翻译:李桦)

CoreOS容器编排之路:从Fleet到Kubernetes的转变

chilly_2016 发表了文章 • 0 个评论 • 3460 次浏览 • 2017-04-23 18:22 • 来自相关话题

【编者的话】近两年分布式应用的组织和管理水平大幅提升。CoreOS集群管理始于fleet,fleet是2014年发布的一个简易的分布式服务管理框架。而社区上Kubernetes被广泛应用,并逐渐成为了开源容器框架的事实标准。基于技术应用和市场占有等原因,Kub ...查看全部
【编者的话】近两年分布式应用的组织和管理水平大幅提升。CoreOS集群管理始于fleet,fleet是2014年发布的一个简易的分布式服务管理框架。而社区上Kubernetes被广泛应用,并逐渐成为了开源容器框架的事实标准。基于技术应用和市场占有等原因,Kubernetes成为大规模容器架构集群最优秀的自动化编排工具,CoreOS也因此而改变技术选型。本文讲述了CoreOS公司集群编排框架的前世今生,描述了从fleet到Kubernetes的转变。

【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述、架构、日志和监控,部署、自动驾驶、服务发现、网络方案等核心机制分析,进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。

目前,CoreOS计划于2018年2月1日从Linux的容器平台上替换fleet技术,对fleet的支持也即将截止。fleet进入了维护期,仅负责安全及补丁修复的升级。此项变动代表着集群编排和管理技术将转移到Kubernetes技术上。此转变也简化了用户自动更新容器Linux最小集操作系统的发布和部署操作。

新集群部署将提供以下支持:


2018年2月1日以后,fleet的容器镜像在CoreOS的软件注册仓库中仍存在,但不作为Linux的容器操作系统集装打包。

若已购买Linux容器服务的fleet的用户,可在服务终止前从原有渠道获得迁移服务。并获取相关文档。

在此期间,可继续通过CoreOS的邮件列表服务解答fleet用户的问题。为了让大家更加顺利的开始,计划2月14日早上10点邀请CoreOS CTO Brandon Philips,举办一场fleet迁移到Kubernetes的在线技术研讨会。方便大家在线交流。
#fleet:集群化之路的第一步
公司创始之初,CoreOS就致力于研究操作系统的集群编排技术,目前以CoreOS Linux容器操作系统最为流行,也是首家提供云环境自动部署和调度集群资源的容器软件。最初该软件是通过fleet实现开源集群调度框架,实现集群设备的系统初始化。

采用fleet不到一年,Google公布了开源Kubernetes项目。令人振奋是他推动了CoreOS Linux容器操作系统fleet的etcd分布式键值后台存储技术的发展,更重要的是Kubernetes提供了fleet未提供的今后发展方向和解决方案。

Kubernetes设计了一套稳定可扩展的API接口、预置服务发现、容器网络、及扩展的关键特性。此外,该技术还在Google Borg,Omega,and SRE团队有多年的运营经验。
#Kubernetes and Tectonic:如何编排容器
基于以上原因,在Kubernetes 1.0之前,CoreOS转而将Kubernetes作为容器编排设计的主要特性,将开发资源投入到Kubernetes的相关基础功能和社区支持中去。CoreOS是Cloud Native Computing Foundation(CNCF)的主要成员之一,谷歌将Kubernetes版权捐赠给CNCF产业联盟,这也促使Kubernetes真正成为全行业努力发展的软件成果。

CoreOS的开发团队主导了Kubernetes版本周期管理,Special Interest Groups(SIGs)曾用了2年时间简化Kubernetes部署、管理和升级,便于生产环境可用。 CoreOS flannel SDN 成为热门的Kubernetes网络管理机制。因为CoreOS开发的Kubernetes网络接口模型作为容器网络接口(CNI)已被大量容器化系统应用。团队致力于设计和应用Kubernetes基于角色的访问控制(RBAC)的技术,使得开源身份认证解决方案dex的团队补充了认证提供商和类似LDAP的企业级解决方案。当然,etcd原本作为fleet的后台数据存储,代表了早期的努力,也将继续沿用到Kubernetes的时代中。

fleet探索了集群自动化管理的愿景,CEO Alex Polvi 认为Kubernetes帮助CoreOS达到最终目标。感谢过去社区对fleet的反馈和支持,公司已将多年积累的经验和思路应用到Kubernetes和Tectonic的集群容器编排上。
##在CoreOS Tectonic上开始使用Kubernetes
Tectonic提供一种最简易的构建新集群方式。在应用开源Kubernetes的基础上,它提供了集群编排软件的简单安装和自动升级服务。对于10个节点以内规模的集群的设备提供免费测试应用lisence,并支持AWS和裸机部署两种环境。
##minikube是Kubernetes的简易先导
若是个使用容器编排的新手,minikube工具可帮助用户在本地快捷的运行Kubernetes,也是一个可安装在笔记本或本地电脑上的Kubernetes先导帮助工具。
##让Kubernetes开启CoreOS的容器Linux之旅
为了深入研究Kubernetes的技术细节,可参考部署帮助手册。帮助文档提供了Kubernetes相关概念的解释说明,以及一些超出Tectonic两类初始环境外的平台部署技术。
#为fleet容器提供集群继续提供维护支持
在2018年2月fleet将从容器的Alpha版本上删除,随后将从Beta和稳定版本上删除,而此后版本可通过运行容器环境继续使用fleet。有一个简单封装的脚本可帮助客户获取fleet应用容器软件及安装说明。

管理员们可通过调试“fleet迁移配置示例”实现容器化fleet应用部署的迁移。设备提供商可在fleet节点上部署封装配置以激活服务。
#下一步:从fleet迁移到Kubernetes
可加入CoreOS的 Container Linux 邮件列表或IRC以获得反馈或技术支持。也可在2月14日的现场技术研讨会获得更多信息。最终,建议参加Coreos 的Kubernetes的专家面授培训,帮助开始Kubernetes的正式使用。

原文链接:Container orchestration: Moving from fleet to Kubernetes(翻译:Chilly)
条新动态, 点击查看
FanLin

FanLin 回答了问题 • 2015-03-29 02:40 • 12 个回复 不感兴趣

CoreOS系统如何手动升级或者自动升级?

赞同来自:

被点名回答这个问题,哈哈。 CoreOS升级的问题一直是困扰<strong>国内玩家</strong>的一个痛,为什么说是国内玩家,且听慢慢道来。 首先,在说这个关于升级... 显示全部 »
被点名回答这个问题,哈哈。 CoreOS升级的问题一直是困扰<strong>国内玩家</strong>的一个痛,为什么说是国内玩家,且听慢慢道来。 首先,在说这个关于升级的问题之前,有必要先解释两个东东:CoreOS的 <strong>升级通道</strong> 和 <strong>升级策略</strong>。 <span style="font-size:16px"> 升级通道 </span> 定义了 CoreOS 每次升级的目标版本号。官方提供了三个升级通道,分别为 Alpha、Beta 和 Stable,简单来说就是每个大版本升级的 <strong>内测</strong>、 <strong>公测</strong> 和 <strong>正式发行版</strong>。只不过 CoreOS 目前是采用一个不断增加的数字来表示各个版本号,数字越大则相对版本越高。 各通道发布更新的频率依次为(官方目标数据,实际可能不准时): <ul><li>Alpha:每周星期四发布</li><li>Beta:每两周发布一次</li><li>Stable:每个月发布一次</li></ul>每个通道当前的具体版本号可以在(https://coreos.com/releases/)上查看到。关于升级通道,(https://coreos.com/docs/cluster-management/setup/switching-channels/)有更详细的介绍。除了三个官方通道,企业版CoreOS用户可以自己定制升级的通道,不过这个功能没有开放给普通用户。企业版是按月付费的价格是 $100/月,见(https://coreos.com/products/)。还有另一个土豪企业版的是 $2100/月,提供7*24小时人工技术支持,估计大家没这个需求。<span style="font-size:16px">升级策略</span>关系到系统自动升级后用户是否需要手工重启。它的值可以是 <strong>best-effort</strong>(默认值)、 <strong>etcd-lock</strong>、 <strong>reboot</strong> 和 <strong>off</strong>。其作用依次解释如下:<ul><li>best-effort:如果Etcd运行正常则相当于 etcd-lock,否则相当于 reboot</li><li>etcd-lock:自动升级后自动重启,使用 LockSmith 服务调度重启过程</li><li>reboot:自动升级后立即自动重启系统</li><li>off:自动升级后等待用户手工重启</li></ul> 其中 LockSmith 是控制集群重启过程的服务,用来保证每次只有固定数量的主机同时重启,从而确保集群服务的健壮性。它的更详细用法可以直接查看其 (https://github.com/coreos/locksmith) 的介绍。 升级通道和升级策略都可以在系统启动时的 cloud-config 中的 coreos.update 中配置,例如(开头的点点是空格占位,无奈因为空格缩进在排版以后会显示不出来): > coreos: .. update: .... reboot-strategy: best-effort .... group: alpha 对于已经启动的集群,可以在 /etc/coreos/update.conf 配置文件中修改,其内容格式如下: > GROUP=alpha REBOOT_STRATEGY=best-effort 修改完成后需要重启一下 update-engine 服务: > sudo systemctl restart update-engine 接下来回到正题,先来说说自动升级。 <span style="font-size:16px">自动升级</span> CoreOS会在 <strong>启动后10分钟</strong> 以及之后的 <strong>每隔1个小时</strong> 自动检测系统版本,如果检查到新版本就会自动下载下来放到备用分区上,然后依据之前的那个升级策略决定是否自动重启节点。OK,就这么简单。 <span style="font-size:16px">手动升级</span> 其实看过上面的介绍之后,不难理解,用户手动执行升级一般是没有必要滴。当然如果你非要这么做,也非常简单,命令是 <strong>update_engine_client -update</strong>。如果只是想查看一下有没有新版本,可以换个参数 <strong>update_engine_client -check_for_update</strong>。 但这里就牵扯出一个残酷的事实... CoreOS 的升级服务器不晓得出于什么原因,在国内是被万能的 GFW 墙掉了滴。因此你会发现下面这个情况: 这个是我在国外的一个 CoreOS 服务器集群手工升级的结果。 检测升级: > core@ip-172-31-21-8 ~ $ update_engine_client -check_for_update Initiating update check and install. 执行升级: > core@ip-172-31-21-8 ~ $ update_engine_client -update Initiating update check and install. Waiting for update to complete. LAST_CHECKED_TIME=0 PROGRESS=0.000000 CURRENT_OP=UPDATE_STATUS_IDLE NEW_VERSION=0.0.0.0 NEW_SIZE=0 Update failed. <-- 因为暂时没有新版本 然后我到国内的一个 CoreOS 集群做了同样的操作: > core@deis-01 ~ $ update_engine_client -check_for_update Initiating update check and install. Error getting dbus proxy for com.coreos.update1: GError(3): Could not get owner of name 'com.coreos.update1': no such name Retrying to get dbus proxy. Try 2/4 ... ... Retrying to get dbus proxy. Try 4/4 Error getting dbus proxy for com.coreos.update1: GError(3): Could not get owner of name 'com.coreos.update1': no such name Giving up -- unable to get dbus proxy for com.coreos.update1 执行完这个命令,已经整个人都不好了。因此,我们真正最关心的问题可能既不是“手动升级”也不是“自动升级”,而是,当当~下面这个东东:<strong>配置CoreOS升级代理服务器</strong>。 <span style="font-size:16px">使用HTTP代理服务器升级CoreOS</span> 方法其实很简单,只是需要用户自己有一个放在国外的HTTP服务器。创建一个配置文件 /etc/systemd/system/update-engine.service.d/proxy.conf,内容为: > Environment=HTTP_PROXY=http://your.proxy.address:port 将HTTP_PROXY的值换成实际的代理服务器地址,重启一下 update-engine 服务即可: > sudo systemctl restart update-engine 这个工作也可以在 cloud-config 里面用 write_files 命令在节点启动时候就完成,不再详述。 <span style="font-size:16px">内网升级</span> 能否使用自定义的内网升级服务器?答案是肯定+否定的,因为这也是企业版服务的一部分。 配置方法倒是很简单,还是 cloud-config 或者 /etc/coreos/update.conf 配置文件。例如,cloud-config 的: > coreos: .. update: .... reboot-strategy: best-effort .... group: alpha .... server: 这里写服务器地址咯,不过一般的用户是不会有私有升级服务器的啦 官方有一个简易的升级服务器实现在(https://github.com/coreos/dev-util/blob/master/devserver.py),不过鉴于(https://coreos.com/docs/sdk-distributors/sdk/building-development-images/)实在是一件麻烦的工作,还是考虑一下代理服务器的方案吧。: D
郭蕾

郭蕾 回答了问题 • 2015-04-10 15:09 • 9 个回复 不感兴趣

容器OS的选择与使用

赞同来自:

我来汇总下目前的几个容器操作系统吧,这些操作系统应该是新的云和容器的产物,他们是一个新时代的新产物。所以各家老牌操作系统厂商也都在积极跟进。对于选择和使用,我没有实战经验,但根据情况来看,哪个都不是很成熟。如果非要选,推荐使用CoreOS。 &amp... 显示全部 »
我来汇总下目前的几个容器操作系统吧,这些操作系统应该是新的云和容器的产物,他们是一个新时代的新产物。所以各家老牌操作系统厂商也都在积极跟进。对于选择和使用,我没有实战经验,但根据情况来看,哪个都不是很成熟。如果非要选,推荐使用CoreOS。 <ol><li>(https://coreos.com/)</li></ol>CoreOS是一个基于Linux内核的轻量级操作系统,它的目标既不是桌面系统,也不是传统的服务器领域。CoreOS的设计目的是为了高效地管理基础设施资源,当然需要借助容器的概念。CoreOS大概是在2013年8月发布了第一个apha版本,然后在2014年7月正式发布了稳定版本。相关的资料比较多,初创公司,算是目前市场上比较成熟的容器操作系统。 <ol><li>(http://www.projectatomic.io/)</li></ol>2014年4月,Red Hat发布了Atomic项目。Atomic是一个用于运行容器的操作系统。Atomic项目并不是为了构建另一个操作系统:Red Hat已经有了RHEL、 Fedora 以及现在的CentOS,再鼓捣第四个操作系统出来并没有什么意义。所以,Red Hat并没有这么做,目前的Atomic是一个基于Fedora的原型系统,而另一个采用CentOS的版本也计划即将发布,目前它还不是一个可用于生产环境的产品。2015年3月底,红帽宣布推出红帽企业Linux 7原子主机(Atomic Host),这也可以看出红帽的决心。 <ol><li>(http://www.ubuntu.com/cloud/tools/snappy) </li></ol>Snappy Ubuntu Core 是Canonical推出的一个小型服务器操作系统,它使用与现有Ubuntu相同的库,同时使用更简便的机制(即容器)供用户安装应用。此外,Ubuntu Core 使用的这种容器机制也兼容 Docker。Snappy是在2014年12月发布的,相关的资料非常少。 <ol><li>(http://rancher.com/)</li></ol>RancherOS是Rancher Labs的一个开源项目,旨在提供一种在生产环境中大规模运行Docker的最小最简单的方式。它只包含运行Docker必须的软件,其二进制下载包只有大约20MB。RancherOS是2015年2月发布的,为了抵制CoreOS,所以目前Docker目前比较亲睐RancherOS。 <ol><li>(http://dockerone.com/article/298)</li></ol>微软推出的针对云环境高度优化的容器操作系统,刚刚发布,不过官方表示将会在几周内发布测试版本。Nano Server是一个Windows Server的最小化footprint安装包,针对云和容器做了高度优化。Nano Server只提供你需要的组件 - 没有任何多余的组件,这使得服务器镜像更小,部署更快,网络带宽耗费更小,同时启动更迅速也更为安全。 另外,对于你说的谷歌和CoreOS的联姻,我非常同意你的观点:强化了容器OS的重要性,也点燃了容器操作系统的战争。CoreOS生态圈里又多了一名大将Kubernetes,这部电视剧真好看。

红帽收购完CoreOS,接下来将如何整合两家公司的Kubernetes产品?

sean 发表了文章 • 0 个评论 • 2693 次浏览 • 2018-02-07 18:21 • 来自相关话题

鉴于周二宣布的一项收购协议,Kubernetes容器编排领域内两个最突出的商业品牌将合二为一。率先打开容器市场,并带来精简Linux内核概念的CoreOS,现在成了红帽的全资子公司。根据即将成为红帽高管的CoreOS CEO Alex Polvi所述,该交易已 ...查看全部
鉴于周二宣布的一项收购协议,Kubernetes容器编排领域内两个最突出的商业品牌将合二为一。率先打开容器市场,并带来精简Linux内核概念的CoreOS,现在成了红帽的全资子公司。根据即将成为红帽高管的CoreOS CEO Alex Polvi所述,该交易已经完成,没有等待期。

Polvi说:“得益于此次收购,我们可以将两条产品线结合形成客户无法在市场上找到的一套无与伦比的机能。虽然我们的产品是竞争关系,但它们在很多方面是高度分化的。OpenShift和Tectonic看起来都是Kubernetes产品,但它们的工作方式及对客户的价值诉求完全不同。将这些东西组合在一起,将产生市场上所可能拥有的终极产品。”

这是一份来自即将变成前CEO的人的雄心勃勃的声明。从技术上说,这笔交易只是私下交易的一次收购,据报道,红帽历史上有过21笔类似的交易。虽然红帽通常不会公布其收购价值,但这笔CoreOS交易它给出的交易价值是2.5亿美元。该公司在2015年收购配置自动化公司Ansible首次公布协议时估值为1亿美元,不过此前有个独立调查将其估值定为1.5亿美元。
# 不确定的融合
红帽明确表示、同时也是急于宣布的是本次交易中浮现出来的基于Kubernetes的产品。

“我们面前有一个机会来做有意义的决定,”红帽负责OpenShift的副总Ashesh Badani以非常巧妙的措词说明Tectonic在OpenShift产品线中的位置尚未最终确定。

“我们将用几周时间而非几个月好好考虑最合理的方式。如何将这两种技术整合在一起,从而保留二者的精华部分?”Badani接着说。他说,Tectonic具有一定的商业客户份额,因此红帽在品牌整合时将尽可能保持这些客户所带来的价值。但是,他强调,OpenShift产品计划不会中断。

“给我们点时间,我们的工程师团队、产品团队、市场团队将坐在一起研究最佳的行进路线,”他说道。

难道CoreOS与红帽在签署协议前没有这样的坐谈机会?并非如此,Badani说,尽管谈判的财务部分进行得很充分,但与交易后业务相关的事项需要保密。因此,在写作本文时,Tectonic将采用的具体形式,以及它如何与红帽的OpenShift产品线并行或合并均尚无定论。

这是否意味着CoreOS大量人员,包括Polvi、CTO及联合创始人Brandon Philips以及工程师主管李响的命运都悬而未决?Badani明确表示CoreOS的开发和技术人才都将被邀请在红帽中留任,他强调说公司的员工是他心目中的重要资产。

Badani说,“这笔交易和伙伴关系的完成,依靠的是CoreOS为市场带来的大量工程人才和创新。如果我们未尽一切可能保证将Alex、Brandon以及所有其他人在内的整个工程和市场团队带入,那就是我们的责任。”他补充说,尽管头衔有待调整,他们从今天起就是该公司的正式成员。他说,产品的路线图可能需要做调整,这有助于最终决定他们的新头衔。
# CoreOS的核心所在
CoreOS的Polvi列出了他认为有别市场其他产品的独特的公司产品,并希望将他们整合到红帽产品线中。Quay(几乎没人读成“key”)私有容器注册中心是他希望能生存并发展下去的一个产品,就像etcd一样,后者是Kubernetes出现之后的事实键值仓库,也是红帽工程师的长期首选组件。

Container Linux也是Polvi提到的有可能在交易浮现出来的一个差异化产品——CoreOS的名字即来源于该产品。考虑到红帽自身是Linux操作系统的制造商,这可能是一厢情愿的想法。Atomic Linux已经是红帽企业Linux(RHEL)一个轻量级的发行版,旨在运行于由一个完善的中央REEL核心管理的分布式主机上。

红帽周二发布的FAQ显示,部分Container Linux交付机制可能被移植到Atomic上,特别是早在2015年与红帽竞争时,Brandon Philips引以为傲的CoreOS优于Atomic的在线更新系统。红帽将此移植形容为两个操作系统之间的“和解”。 这条消息似乎在宣布Container Linux被正式收购后不久消失了。

该消息促使CoreOS Tectonic产品经理Rob Szumski通过谷歌讨论组及Twitter中提供了一些补充说明。

Szumski写道:“Container Linux一直是免费提供的,我们预计这不会改变,红帽计划继续Container Linux的开发。事实上,与将Fedora的创新技术融入红帽企业Linux类似,我们可能会看到类似更新交付机制的Container Linux创新被融入其中。”

上述陈述中的关键词是“可能”。

与此同时,根据红帽和CoreOS的说法,rkt——这个在2015年首次挑起容器界短暂大分裂的容器格式和运行时——不在谈判桌的议题中。在去年被捐赠给云原生计算基金会(CNCF)后,rkt仍然可能会出现在一些客户驱动的实现中,不过Polvi告诉我们,他期望rkt能够根据自己的长处找到价值所在。

根据Polvi和Badani的说法,收购讨论中也未提及Docker或Docker Inc。

Badani说:“我们将持续接受开源社区中的每个合作机会。在竞争方面,我们并没有真正看到太多Docker的表现。过去几个月,随着亚马逊和微软Azure的加入,Kubernetes的市场势头非常明显。Docker最近才开始在这方面进行投入,因此还未展现出足够的竞争力。他们的Swarm编排技术不像他们所希望那么有竞争力,这就是他们也要投资Kubernetes的原因。我真的不担心他们。”

Polvi说:“CoreOS主要销售产品给那些想要使用Kubernetes的公司。目前企业用户能在市场上找到的Kubernetes产品实际上只有两种:Tectonic和OpenShift。Docker宣布了一款Kubernetes产品,现在已有一个Alpha或Beta产品,但是并没有准备就绪的企业销售团队。也许将来会发生变化,但客户现在需要Kubernetes。”

Docker在1月18日发布了Docker Enterprise的Beta版Kubernetes集成。
# 寻找Kubernetes市场
根据Polvi的算法,市面上将只有单一一个企业Kubernetes供应商。Kublr可能会对此感到震惊,但至少在这位前CEO的头脑中,他的产品与Red Hat的结合必将胜出。

不过这块蛋糕到底有多大?在去年秋天的一项调查中,CNCF请企业选择他们在生产中所使用的编排器,约69%的受访者表示他们使用了通用的Kubernetes,而OpenShift仅占总数的12%,Tectonic仅占4%。
01.jpg

当问题限定在占比23%、部署超过1000个容器的受访者子集时,OpenShift在该子集中的份额增长至17%。但Tectonic的份额减少了一半,而通用Kubernetes获得了3分。

所以也许这次收购可能会在Kubernetes市场有所作为,只是其市场本身在总体生态系统中占比不足三分之一。又或者,正如IT分析师Kurt Marko所认为的那样,这里面有市场的想法可能是一种幻觉。

Marko在写给The New Stack的报告中写道,“Kubernetes是集群管理/工作负载编排的事实标准。包括红帽在内的任何人都无法主宰这个市场,因为这不是一个真正的市场,它只是一个功能。”

Marko继续写道:“我真的不认为多数企业客户(比如经理、高管,而非开发人员)会考虑他们所运行的Linux发行版等细节。他们更感兴趣的是能够可靠安全地运行应用程序、能够提供良好的性能,并得到定期更新和问题响应支持的东西。如果CoreOS在容器方面工作更好,那很好,如果它捆绑在一个包含了Kubernetes、注册中心和虚拟网络结构(Contiv等)的容器平台中,那更好。”

Marko在红帽的产品线中确实看到了适合Container Linux的位置,特别是Tectonic作为OpenShift PaaS的基础架构平台。但是,这种天作之合现在几乎每周都会出现,有时甚至不需要并购或收购,思科上周就公布了自己的思科容器平台,这又是一个品牌化的Kubernetes服务。”

Marko写道:“我认为真正的‘战斗’将是赢取希望使用混合容器架构的用户,这种架构将内部部署和公共云容器服务无缝地结合在一起。在这一点上,红帽还有更多的工作要做,特别是考虑到谷歌/VMware和谷歌/思科的合作关系。”

因此,虽然这笔交易明显改变了开发者心目中Kubernetes的战场,并可能进一步边缘化Docker,但实际上可能不是那种用于表征软件平台成熟度的“市场整合”。更像是服务器市场一个主要选手找了个途径来利用一个产品的成功之处,如果这个产品从一开始就是商业化、专有化的,即使是一个金矿……没有人会听说它。

原文链接:Docker Who? By Acquiring CoreOS, Red Hat Aims to Be the Kubernetes Company(翻译:梁晓勇

红帽公司收购CoreOS,旨在拓展自身在Kubernetes与容器领域的领导地位

大卫 发表了文章 • 0 个评论 • 3813 次浏览 • 2018-01-31 08:11 • 来自相关话题

凭借CoreOS的加持,红帽公司将进一步加大技术开发力度,从而帮助客户立足混合与多云环境构建、运行并管理容器化应用程序。 作为全球规模最大的开源解决方案供应商,红帽公司今天宣布其已经签署一项最终协议,将收购Kubernetes与容器原 ...查看全部
凭借CoreOS的加持,红帽公司将进一步加大技术开发力度,从而帮助客户立足混合与多云环境构建、运行并管理容器化应用程序。

作为全球规模最大的开源解决方案供应商,红帽公司今天宣布其已经签署一项最终协议,将收购Kubernetes与容器原生解决方案领导者兼创新者CoreOS公司。此笔交易的总价为2.5亿美元,虽然可能在实际执行时作出些许调整,但幅度应不会太大。红帽公司对CoreOS的收购将进一步助力客户构建一切自身需要的应用程序,并将其部署在红帽灵活的开源环境当中。通过将CoreOS的补充性功能与红帽此前已经广泛推动的Kubernetes以及红帽OpenShift容器化产品相结合,开源巨头希望进一步加快其面向现代应用工作负载的领先混合云平台的普及与发展速度。

我们相信,此次收购将成为红帽旗下混合云与现代应用部署的发展基石。

——PAUL CORMIER,红帽公司产品与技术总裁

随着应用程序逐步向混合及多云环境迁移,越来越多的企业开始利用容器方案以简化与云环境对接的各类应用程序的构建、部署与移动工作。IDC公司指出,“目前,云采用、简化与可移植性方面正取得实质性进展,市场对于云服务的需求也在持续增长。预计在未来几年当中,云计算架构将成为企业客户的主要支出方向。而随着容器体系的日益复杂化,企业应在寻求应用平台供应商的帮助,从而更轻松地利用容器技术对现有生产性应用程序进行转换与扩展,最终将其顺畅运行在公有云或私有云环境之内。”

创立于2013年的CoreOS公司旨在为各种规模的企业构建并交付基础设施,帮助其获得与大型软件企业对等的运营环境、实现自动更新与服务器修复,并协助解决停机时间控制、安全性保障以及恢复能力实现等实际难题。自早期发布针对容器作出优化的轻量级Linux操作系统以来,相关技术使得可扩展与弹性容器化应用程序的广泛使用成为可能,这也令CoreOS成为这一技术领域内备受赞誉的领导者。

CoreOS公司亦是CoreOS Tectonic的缔造者,这是一套企业级Kubernetes平台,负责跨越私有云以及不同公有云供应商为企业客户提供自动化运营与可移植能力,且完全基于开源软件实现。该公司旗下还拥有CoreOS Quay,一套企业级容器注册方案。CoreOS公司亦因积极推动容器化应用程序层面的开源创新贡献而广受好评,具体包括身为Kubernetes的主要贡献者、创建并维护轻量级Linux发行版Container Linux(用于自动执行软件更新并简化容器运行)、推出Kubernetes分布式数据存储方案etcd、向云原生计算基金会(简称CNCF)捐赠应用程序容器引擎rkt,以及积极推动当前开放容器倡议(简称OCI)标准的普及等等。

红帽公司很早就开始接纳容器与容器编排技术,并对包括Kubernetes在内的相关开源社区作出深入贡献——事实上,红帽已经成为Kubernetes社区中仅次于谷歌的第二大贡献者。红帽公司在基于容器类应用的开发方面同样是全球范围内当之无愧的领导者,其重要成果正是红帽OpenShift(业界最全面的企业级Kubernetes平台)。如今与CoreOS合并之后,红帽公司将能够在上游社区与企业级容器解决方案领域进一步奠定自身的领导优势。

预计这笔交易不会对截至2018年2月28日的红帽公司第四财季或整个财年指标造成重大影响。

此笔交易预计将于2018年1月之内结束,但须遵循成交条件惯例。

感兴趣的朋友亦可访问红帽公司博客,通过其官网了解更多与收购相关的细节信息。

大力支持

Paul Cormier红帽公司产品与技术总裁指出:

“新的技术时代将受到跨多云与混合云环境(包括物理、虚拟、私有云以及公有云平台)的基于窗口类应用的有力驱动,而Kubernetes、容器以及Linux已经成为这一转型的核心所在。与红帽一样,CoreOS一直是推动这些创新的上游开源社区领导者,同时亦在为企业客户提供企业级Kubernetes服务方面保持领先地位。我们相信此次收购将帮助红帽公司进一步巩固混合云与现代应用部署的基础。”

Alex Polvi,CoreOS公司CEO指出:

“红帽与CoreOS的合作关系已经持续了很长时间。作为开源协作方,我们共同为容器及分布式系统开发出一系列关键性创新成果,并帮助将自动化运营转化为现实。此次合并标志着我们在推进共同目标方面迈入新的阶段,也意味着我们的这些重要技术成果将进一步在各类企业乃至世界范围内得到普及。在这里要感谢CoreOS大家庭、感谢我们的客户、合作伙伴。当然,最重要的是要感谢自由软件社区对我们使命的不懈支持,这一切都将以自动化运营方式令互联网体系变得更加安全。”

原文链接:Red Hat to Acquire CoreOS, Expanding its Kubernetes and Containers Leadership(翻译:David)

容器监控的基石Prometheus 2.0到来

codesun 发表了文章 • 0 个评论 • 4618 次浏览 • 2017-11-12 15:36 • 来自相关话题

【编者的话】本文为大家带来了Prometheus 2.0中新存储层需求的由来,主要的挑战,实现的简要介绍,以及相关的基准测试结果,相关领域人员可以参考一下。 Kubernetes使得复杂环境的管理变得容易,但是为了确保可用性,对Kub ...查看全部
【编者的话】本文为大家带来了Prometheus 2.0中新存储层需求的由来,主要的挑战,实现的简要介绍,以及相关的基准测试结果,相关领域人员可以参考一下。

Kubernetes使得复杂环境的管理变得容易,但是为了确保可用性,对Kubernetes组件以及群集上运行的所有应用程序进行操作深入分析至关重要。在CoreOS,我们相信监控是良好生产环境的基石,这也是我们投入开发Prometheus监控系统的原因。作为一个由Cloud Native Computing Foundation(CNCF)支持的项目,Prometheus迅速获得了基础设施及应用监控方面的热度,今天是它更进一步的时候。
01.png

CoreOS将Prometheus作为我们企业级Kubernetes平台Tectonic的集成组件,并且我们也一直在努力提升其对Kubernetes用户的价值。今年早些时候,我们分享了关于下一代Prometheus(version 2.0)的新存储层方面的工作。为了稳固这项工作,我们和Prometheus团队以及我们的用户进行了更加密切的合作。在3个alpha版本,6个beta版本以及3个RC版本之后,今天Prometheus 2.0正式宣布稳定版本。感谢Brian Brazil和Goutham Veeramachaneni,他们在这项工作中付出巨大。在我们探索该发行版的优点之前,让我们回过头来,先探讨一下我们为何需要一个新的存储层。
# 时间序列和动态环境
Prometheus关于监控的理念鼓励在堆栈的每一层都采用高度详细的度量工具。容器的状态,通过的请求流,甚至是运行于其中的应用的深层信息都通过度量工具对外可见。Prometheus带来了一款强力的查询语言帮助将度量数据汇总转换成行动方案。

Prometheus通过时间序列的方式收集和存储数据,它是通过固定间隔收集到的带有时间戳数据的序列。这种设计可以使运行中的容器轻松产生成千的时间序列。随着容器的规模从成百扩展到成千,在集群中很可能产生数百万被跟踪的时间序列。

为上百万的时间序列持续写入数据显然是一项技术难题。更糟糕的是,Kubernetes使得持续销毁和创建容器变得十分容易。该项模型对于持续部署,自动扩容以及批处理作业调度而言是极为强大的,因此只会随着时间的推移而变得越来越普遍。

每个容器都有一个独一无二的标识符,所有其时间序列均包含该标识符,以达到最佳的视角。因此当被跟踪的活跃时间序列总数大致固定时,Prometheus中可以对外访问的所有历史时间序列数据是持续增长的。允许查询十亿级的时间序列是一项全新的挑战,但我们决定让Prometheus很好地支持该特性。

新的存储引擎就是用来解决这项挑战的。受到全文搜索的启发,它使用倒排索引以提供对于Prometheus时间序列可能拥有的任意纬度进行快速检索。新的磁盘格式确保相关的时间序列数据良好分布,另外write-ahead日志也使得Prometheus 2.0n能够从崩溃中恢复。

Prometheus同样变得更易操作了。Prometheus 1.x的用户应该对调整期望负载的存储配置十分熟悉。然而,有了新的存储层之后,这些控制就不再需要了。
# 基准测
这项工作的真实结果是令人印象深刻的。Prometheus 2.0的资源消耗得到了显著降低,使用率更加稳定,并且新的索引方式带来了更低且一致的查询延迟。

下方的图是一个基准测试集的结果,它来自一个运行着成百个应用Pod并被监控的Kubernetes集群。Pod按照高频率替换以产生时间序列的扰动。各有2个Prometheus 1.5和Prometheus 2.0实例运行采集新数据。不同版本中,各有1个实例对外服务,以产生适中性的高查询负载。

从前2个图中,我们可以看到Prometheus 2.0的内存和CPU消耗均明显更低,并且自启动后,它们很快到达稳定状态。Prometheus 1.5则需要更多的资源,并且其资源使用率难以预测。
02.png

03.png

Prometheus 2.0中最大的改进是其每秒写入磁盘的数据量,可以查看下图。新版本的写入量较之前低了近2个数量级。很明显,这能增加SSD的寿命(译者:SSD寿命由PE次数决定,与写入数据量密切相关),进而降低成本。在高序列扰动的情况下,即使使用相同的序列压缩算法,依旧可以观察到显著的磁盘空间节省。
04.png

在Prometheus 1.5中,随着更多的时间序列被创建,查询的延迟是线性增长的。Prometheus 2.0则从一开始就维持了稳定的性能,它使得查询的反馈更加敏捷,正如下图所示。
05.png

# 其余新特性
Prometheus 2.0的大多数工作都聚焦于提升性能并使其更加易于操作。但是新的存储层同样被设计以更好地和Prometheus的外部交互,这使得围绕收集到的时间序列数据进行广泛的定制处理成为可能。

快照备份是一项被频繁要求的特性。当使用flag `--web.enable-admin-api`时,只需要通过简单的API调用,Prometheus 2.0便可原生支持它们。
bash
$ curl -XPOST http:///api/v2/admin/tsdb/snapshot
{"name":"2017-10-18T13:44:35Z-3f6a679bb001e65d"}

快照存放于名为返回值的目录中,且可以被上传到归档存储中,它们几乎不会占用额外的磁盘空间。最棒的是,新的Prometheus服务器可以从备份的数据启动,你只需将数据移动到新的服务器数据目录中即可。

关于完整的变更列表以及如何从Prometheus 1.x迁移,请查看官方声明以及迁移指南
# 敬请尝试
有关Prometheus 2.0增强的最佳部分是,Prometheus当前不但可以比以往更好地支持Kubernetes的工作负载,更在于当Kubernetes在基础设施中活力倍增时,它预留了足够的空间来支撑届时的工作负载。

想要了解Prometheus,请关注11月16日上午8时webinar上关于新特性的PT(来自Prometheus开发者Frederic Branczyk)。

如果你想要亲自了解集成Prometheus支持是如何使得CoreOS Tectonic成为真正的企业级Kubernetes平台的,你可以免费部署一个不多于10个节点的Tectonic集群。你将能够使用最新的Prometheus操作器不费吹灰之力地在集群中部署Prometheus 2.0,而无需额外的配置。

声明:本文中的基准测试通过prombench生成。为了复现它们,你需要一个配置好的AWS账户,并且你必须指定想要执行的基准测试spec。`spec.example.yaml`正是生成本文所用图的spec。
# 相关文章

+ Prometheus 2.0: New storage layer dramatically increases monitoring scalability for Kubernetes and other distributed systems
+ The Prometheus Operator: Managed Prometheus setups for Kubernetes
+ Monitoring Kubernetes with Prometheus | Prometheus Docker Monitoring
+ CoreOS and Prometheus: Building monitoring for the next generation of cluster infrastructure

原文链接:Prometheus, the backbone of container monitoring, hits 2.0(翻译:孙科)

为什么CoreOS携手开源?

xiao_ye2000 发表了文章 • 0 个评论 • 2728 次浏览 • 2017-07-03 13:36 • 来自相关话题

【编者的话】本文通过日常研发中遇到的问题,提出引入开源项目的重要性,介绍了CoreOS协助创立的CNCF以及它赞助的一些项目,同时也介绍了Kubernetes社区的一些现状和未来发展的展望。 【3 天烧脑式容器存储网络训练营 | 深圳 ...查看全部
【编者的话】本文通过日常研发中遇到的问题,提出引入开源项目的重要性,介绍了CoreOS协助创立的CNCF以及它赞助的一些项目,同时也介绍了Kubernetes社区的一些现状和未来发展的展望。

【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。

CoreOS构建开源软件。为什么携手开源软件呢?因为要解决的问题规模巨大,在宏观的层面需要革新。预计:

* 今时今日有3,646,000,000的因特网用户;
* 29,000,000的软件开发者和IT从业者;
* 去年新增了238,975,082的因特网用户;
* 全球大概有100,000,000左右的服务器。

显然我们作为软件工程师和管理员是忙不过来的。开源软件是使这一扩展成为财富的关键,大家在各种环境中合作处理最难的操作问题,例如管理安全性、可靠性以及可移植性。

大概三年半前,我们开始一起用工具套件解决分布式系统中解锁计算可移植层。随着Container Linux、Docker、Kubernetes等的引入,基于软件容器的生态系统开始形成。
coreos.png

#构建Container Linux
CoreOS Container Linux,为容器世界创造的开源操作系统,大概四年前开始研发,设计理念是容器把Linux推向了一个全新的道路,需要对安全、性能以及宽平台多方面支持的全新版本。因此我们构建了一个有快速发布Linux内核特性的OS,尤其是在容器化优化方面。

Container Linux现在被广泛的采用运行于各种云平台以及裸金属平台上。
#CoreOS创建CNCF中的开源项目:rkt和CNI
至此,我们已经协助建立了CNCF(the Cloud Native Computing Foundation)并且捐助了包含rktCNI等一些关键容器技术。这些开源项目由CoreOS工程师发起并且在容器生态系统中的成功提供了一定的帮助。

最新的rkt发布版本自从被加入到CNCF以来,第一次对于帮助促进这次发布的社区成员表示了极大的感谢。本次发布新加入了很多贡献者,同时也提出了基于Xen stage1的建议。

CNI是容器中的网络系统插件,它使得类似Kubernetes之类的管理平台更容易的支持IPAM、SDN或者其它网络方案。CoreOS几年前创造了CNI,以实现跨容器的解决方案和计算环境之间简单网络的可互相操作性。CNI有着一个蓬勃发展的第三方网络解决方案社区,用户可以从那里选择网络插件加入到Kubernetes容器架构中去。我们很高兴看到这些广泛采用的系统加入到CNCF中。
#对于Prometheus监控引擎的贡献
监控架构软件和系统对于创建一个可靠的生产环境至关重要,Promethus事实上是Kubernetes生态系统的监控系统。鉴于其重要性,CoreOS在这个项目上投入了一定的人力并且把项目往可扩展性方向做出了很有意义的推进。社区对于可扩展性的关注是即将推出的Prometheus 2.0版本的前沿和中心,这个版本提供了时序存储层上的很大提升,旨在解决当前工作负载的瞬态性。
#Celebrating Clair 2.0
Clair是CoreOS建立的一个安全项目,完成容器镜像的静态分析并将它的内容和公共漏洞数据库相关联。Quay安全扫描的核心就是Clair,但是它也支持其它许多需要容器镜像扫描的项目。

今天我们庆祝Clair 2.0的发布,包含Alpine Linux扫描等附加功能。这是个重要的里程碑的发布,感谢参与的43的贡献者。
#联盟的Kubernetes状态
我们致力于创建一个强有力的Kubernetes开发社区,有着与之匹配的客户和合作伙伴的更广泛的社区。去年Kubernetes社区已经达成了几个重要的里程碑,包括几个稳定版本,一群增长中的贡献者,另外Kubernetes指导委员会的启动也帮助组织项目在未来几年进一步发展。
##项目治理和发布
Kubernetes处理问题的空间是巨大的!Kubernetes社区发展快速的原因是由于社区组织的能力组织成了一个个的小团队,称为特别兴趣组)。这些组织可以从横向跨项目的问题,如集群安装或认证/授权到更多的纵向问题,如Azure集成。然而当需要对创建新的资源库、划分新的发布版本包括新的API或者删除未进过测试的代码等操作跨SIG决定的时候,谁做出最后的确定就很不清晰。

几个月前,Kubernetes社区创立了一个管理引导委员会在如何处理这类问题上做出建议。最近引导委员会发布了一系列重要的建议和文档包括成立Kubernetes指导委员会全职解决项目组织问题。计划八月初建立Kubernetes指导委员会。
##未来的展望
最后,让我们期待接下来几个Kubernetes发布版本里的一些特性和能力。我从LWN的Jon Corbet对常规Linux内核的预测获得启发。然后我的工作比Jon的更容易,Kubernetes社区开发了一个相对中心化的特性以及设计计划系统,因此对于这些预测,我有很高的信心相信它们都会成真。

核心部署API正在转向稳定:这很容易预测,因为Kubernetes社区的很多人都致力于将它实现。Kubernetes社区正在快速地把重要的API添加到项目中,例如通过DaemonSets支持长时间运行的节点服务、通过StatefulSets支持静态状态应用以及通过Deployments支持滚动升级等工作负载。这些API已经被用户的很多发布版本证明且已经做好了转成稳定版本的准备。

一致性和自动集群配置:Kubernetes有很多动态的部分,从API server和Scheduler到kubelet和kube-proxy。这些每个组件都需要获取密文和可调参数。现在这些都是通过命令行参数实现;但是管理这些组件非常困难,需要重启才能更新,而且对于版本更新来说是不大可能的。目前正在研发通过配置文件映射到称为组件配置的API对象,使配置更加一致,更容易自动化。

通过TPRs扩展和API的聚合:对于创建集群应用的人们来说,Kubernetes的API已经成为了一个很便捷的系统。这是因为这些API有着友好的命令行工具,基于角色的接入控制并且可以插入很多用户认证系统。因此,人们创建了许多应用并将资源保存到Kubernetes中,这些资源称为第三方资源,另外还有个新的API聚合子系统用来启动API,可以在server端验证,和Kubernetes API版本集成,并且后台可以是不同的数据存储。

应用在Kubernetes API之上编译:基于Kubernetes API的扩展能力,已经出现了虚火基于该API的应用。这包含从数据库、认证鉴权以及用户应用特定工作流的许多应用。这些应用的管理员将可以利用Kubernetes提供的所有功能包括日志、调试和监控工具等。

更多的用Metrics API监控驱动API:并不是只有外部应用才被Kubernetes中新的API聚合启动。SIG Instrumentation现在正在创立一个metrics API服务器,可以随着现如今用户创建的越来越大规模的集群而扩展。这也使得Kubernetes内部更多的监控驱动决定系统变得可能:基于用户的指标自用扩缩,更好的首选管理工具就更容易插入到例如Prometheus等时序数据库中。
#朝着光明的未来迈进
非常感谢所有人和我们在许多开源容器生态环境中关键项目中一起工作并取得成功。我们鼓励你们加入到开源和分布式系统的旅程中。或者,跟我们合作吧!CoreOS正在招聘

原文链接:Why CoreOS Builds with Open Source(翻译:李桦)

CoreOS容器编排之路:从Fleet到Kubernetes的转变

chilly_2016 发表了文章 • 0 个评论 • 3460 次浏览 • 2017-04-23 18:22 • 来自相关话题

【编者的话】近两年分布式应用的组织和管理水平大幅提升。CoreOS集群管理始于fleet,fleet是2014年发布的一个简易的分布式服务管理框架。而社区上Kubernetes被广泛应用,并逐渐成为了开源容器框架的事实标准。基于技术应用和市场占有等原因,Kub ...查看全部
【编者的话】近两年分布式应用的组织和管理水平大幅提升。CoreOS集群管理始于fleet,fleet是2014年发布的一个简易的分布式服务管理框架。而社区上Kubernetes被广泛应用,并逐渐成为了开源容器框架的事实标准。基于技术应用和市场占有等原因,Kubernetes成为大规模容器架构集群最优秀的自动化编排工具,CoreOS也因此而改变技术选型。本文讲述了CoreOS公司集群编排框架的前世今生,描述了从fleet到Kubernetes的转变。

【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述、架构、日志和监控,部署、自动驾驶、服务发现、网络方案等核心机制分析,进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。

目前,CoreOS计划于2018年2月1日从Linux的容器平台上替换fleet技术,对fleet的支持也即将截止。fleet进入了维护期,仅负责安全及补丁修复的升级。此项变动代表着集群编排和管理技术将转移到Kubernetes技术上。此转变也简化了用户自动更新容器Linux最小集操作系统的发布和部署操作。

新集群部署将提供以下支持:


2018年2月1日以后,fleet的容器镜像在CoreOS的软件注册仓库中仍存在,但不作为Linux的容器操作系统集装打包。

若已购买Linux容器服务的fleet的用户,可在服务终止前从原有渠道获得迁移服务。并获取相关文档。

在此期间,可继续通过CoreOS的邮件列表服务解答fleet用户的问题。为了让大家更加顺利的开始,计划2月14日早上10点邀请CoreOS CTO Brandon Philips,举办一场fleet迁移到Kubernetes的在线技术研讨会。方便大家在线交流。
#fleet:集群化之路的第一步
公司创始之初,CoreOS就致力于研究操作系统的集群编排技术,目前以CoreOS Linux容器操作系统最为流行,也是首家提供云环境自动部署和调度集群资源的容器软件。最初该软件是通过fleet实现开源集群调度框架,实现集群设备的系统初始化。

采用fleet不到一年,Google公布了开源Kubernetes项目。令人振奋是他推动了CoreOS Linux容器操作系统fleet的etcd分布式键值后台存储技术的发展,更重要的是Kubernetes提供了fleet未提供的今后发展方向和解决方案。

Kubernetes设计了一套稳定可扩展的API接口、预置服务发现、容器网络、及扩展的关键特性。此外,该技术还在Google Borg,Omega,and SRE团队有多年的运营经验。
#Kubernetes and Tectonic:如何编排容器
基于以上原因,在Kubernetes 1.0之前,CoreOS转而将Kubernetes作为容器编排设计的主要特性,将开发资源投入到Kubernetes的相关基础功能和社区支持中去。CoreOS是Cloud Native Computing Foundation(CNCF)的主要成员之一,谷歌将Kubernetes版权捐赠给CNCF产业联盟,这也促使Kubernetes真正成为全行业努力发展的软件成果。

CoreOS的开发团队主导了Kubernetes版本周期管理,Special Interest Groups(SIGs)曾用了2年时间简化Kubernetes部署、管理和升级,便于生产环境可用。 CoreOS flannel SDN 成为热门的Kubernetes网络管理机制。因为CoreOS开发的Kubernetes网络接口模型作为容器网络接口(CNI)已被大量容器化系统应用。团队致力于设计和应用Kubernetes基于角色的访问控制(RBAC)的技术,使得开源身份认证解决方案dex的团队补充了认证提供商和类似LDAP的企业级解决方案。当然,etcd原本作为fleet的后台数据存储,代表了早期的努力,也将继续沿用到Kubernetes的时代中。

fleet探索了集群自动化管理的愿景,CEO Alex Polvi 认为Kubernetes帮助CoreOS达到最终目标。感谢过去社区对fleet的反馈和支持,公司已将多年积累的经验和思路应用到Kubernetes和Tectonic的集群容器编排上。
##在CoreOS Tectonic上开始使用Kubernetes
Tectonic提供一种最简易的构建新集群方式。在应用开源Kubernetes的基础上,它提供了集群编排软件的简单安装和自动升级服务。对于10个节点以内规模的集群的设备提供免费测试应用lisence,并支持AWS和裸机部署两种环境。
##minikube是Kubernetes的简易先导
若是个使用容器编排的新手,minikube工具可帮助用户在本地快捷的运行Kubernetes,也是一个可安装在笔记本或本地电脑上的Kubernetes先导帮助工具。
##让Kubernetes开启CoreOS的容器Linux之旅
为了深入研究Kubernetes的技术细节,可参考部署帮助手册。帮助文档提供了Kubernetes相关概念的解释说明,以及一些超出Tectonic两类初始环境外的平台部署技术。
#为fleet容器提供集群继续提供维护支持
在2018年2月fleet将从容器的Alpha版本上删除,随后将从Beta和稳定版本上删除,而此后版本可通过运行容器环境继续使用fleet。有一个简单封装的脚本可帮助客户获取fleet应用容器软件及安装说明。

管理员们可通过调试“fleet迁移配置示例”实现容器化fleet应用部署的迁移。设备提供商可在fleet节点上部署封装配置以激活服务。
#下一步:从fleet迁移到Kubernetes
可加入CoreOS的 Container Linux 邮件列表或IRC以获得反馈或技术支持。也可在2月14日的现场技术研讨会获得更多信息。最终,建议参加Coreos 的Kubernetes的专家面授培训,帮助开始Kubernetes的正式使用。

原文链接:Container orchestration: Moving from fleet to Kubernetes(翻译:Chilly)

CoreOS和Docker分别要将rkt和containerd捐赠给CNCF

kurtzhong 发表了文章 • 0 个评论 • 3481 次浏览 • 2017-03-17 22:10 • 来自相关话题

今天(3月15日)CoreOS和Docker联合提议将rkt和containerd作为新项目纳入CNCF(云原生计算基金会)。在今天CNCF的技术监管协会(Technical Oversight Commitee,或TOC)会议上,Jonathan Boull ...查看全部
今天(3月15日)CoreOS和Docker联合提议将rkt和containerd作为新项目纳入CNCF(云原生计算基金会)。在今天CNCF的技术监管协会(Technical Oversight Commitee,或TOC)会议上,Jonathan Boulle,一名rkt的项目领导人兼共同发起人,提议了rkt;Michael Crosby,一名containerd项目领导人兼共同发起人,提议了contanerd。这些提议是让这些项目和其他关键项目共同发展的第一步,这些项目包括gRPC、Kubernetes、Prometheus和很多其他项目。通过将这些项目捐献给CNCF,我们保证容器社区继续在一个中立的归属下齐心协力。

【上海站|3天烧脑式微服务架构训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。

容器执行是云原生的一个至关重要的支柱,并且我们相信rkt将会持续在CNCF社区的帮助下进步并壮大。rkt有180多名来自多元化的背景的贡献者,已经帮助建立并且推进很多关于容器安全,组合性和协作性的对话。现在,行业中已经有一部分致力于容器安全,而像CNCF这样的机构能促进对话,并最终让更多的公司吸收、推动并受益于云原生基础设施。

我们期待在接下来的数天和数周里,和rkt和CNCF社区一起完成接下来的步骤。如果你有兴趣了解最新进展,可以订阅这个邮件列表
# rkt为什么加入CNCF
云原生计算的一个支柱是将应用打包成容器镜像,然后把这些镜像分发到服务器。在服务器上,容器引擎会下载镜像,验证镜像的完整性,然后执行容器进程。理想的状态是,容器引擎使用最简单的方式来实现这个过程,同事满足生产环境中云原生用户的需求。rkt工具就像一束激光,集中于解决这些问题,其成果已经受到了市场的欢迎,并促进了它和一些云原生编排系统如Kubernetes、Mesos、Nomad和很多机构的内部定制系统集成。

自从它被CoreOS在2014年12月发布以来,rkt项目已经高度成熟并被广泛使用。在绝大多数的主流Linux发行版中都能找到,并且每一个rkt的发布版都会构建用户可以直接安装的自包含rpm/deb安装包。这些软件包也能在Kubernetes仓库中找到,作为该仓库的一部分,便于测试rkt和Kubernetes的集成。同时,在Google Container ImageCoreOS Container Linux运行Kubernetes中,rkt也扮演了中心的作用。

同时,rkt项目也间接推进了容器生态系统中很多新的重要API,规范和讨论。CNI,被Mesos、Kubernetes、rkt和其他项目使用的容器网络插件系统,就直接来源于最初的rkt插件系统并且已经汇聚了来自多家机构和整个行业的努力。rkt的团队也创建了appc,即App Container Spec,发起了一场行业内的关于容器标准的讨论,并且最终产生了OCI,即Open Container Initiative。正在进行的将Kubernetes打造成一个支持多容器运行时的系统起源于早期在"rktnetes"方面的工作,其已经促使了Container Runtime Interface API在Kubernetes内诞生。在所有的这些场景中,rkt项目都扮演共享生态环境中协作的催化剂。

总得说来,容器执行是云原生的一个核心部分。通过将rkt放到CNCF下的提议,我们能得到如下的益处:

  • 为项目找到一个中立的、受尊敬的归属
  • 伴随来自社区的努力和投入,能得到更多的帮助
  • 加速和Kubernetes、OCI和containerd的合作

# rkt现状和未来
感谢社区让rkt走到今天这一步。很多公司,如BlaBlaCar,一家欧洲有名的汽车共享服务商,他们正在生产环境中使用rkt并且正向Kubernetes迁移,并分享了他们在生产坏境中使用rkt的经验。社区中的其他成员也说:
01.png

来自@coreoslinux的rkt是真正值得关注的东西,https://t.co/UYeOVX0CUz

02.png

不得不说,CoreOS的rkt有着很好的设计

请继续使用rkt并且提出反馈,分享你们使用rkt的故事。你可以在我们的rkt的usersintegration文档页面添加你的pull request。
## FAQ
Q:今天这意味着什么?

现在rkt和containerd的提议已经提交后,下一步是等待CNCF TOC成员来支持并提议项目的加入。到了这一步后,项目会向上推进,进入一个正式的提议阶段,然后继续往上在接下来几周里接受投票。



而对于专门负责rkt的项目组来说,并没有什么大的不同。所有rkt的其他maintainer会一如往常的继续项目上的工作。同时,我们希望在CNCF的帮助下,能催生新的用户和维护者,一起推动并且依赖rkt。



Q:containerd和rkt的不同之处是什么?

rkt能下载、验证并且配置好容器镜像;而containerd也能完成同样的事情。同时,两个项目都支持OCI镜像和Docker镜像。



一个主要的不同之处是,rkt作为一个无守护进程的工具(daemonless tool),可以用来在生产环境中,集成和执行那些特别的有关键用途的容器。举个例子,CoreOS Container Linux使用rkt来以一个容器镜像的方式执行Kubernetes的agent,即kublet。更多的例子包括在Kubernetes生态环境中,使用rkt来用一种容器化的方式挂载volume。这也意味着rkt能被集成进并和Linux的init系统一起使用,因为rkt自己并不是一个init系统。



Q:对于构建容器的开发者来说意味着什么?


对于需要构建容器的开发者来说,一切照常,因为containerd和rkt的目标都是要让用户能够执行他们已有的OCI镜像和Docker镜像。



对于在生产环境中部署容器的基础设施专家群体来说,这意味着rkt团队和项目会以CNCF的一部分,在一个中立的机构下,继续它的使命,即创建一个简单、可组合、生产环境可用的容器化系统。



我们同时也迫切想看到在rkt项目中和其他CNCF生态环境项目,如Kubernetes,gRPC和Prometheus的协作。



Q:所有的这些容器引擎都可以通过Kubernetes CRI使用吗?

CoreOS帮助建立了一个标准的接口,叫做Kubernetes Runtime Interface(Kubernetes运行时接口,CRI),能让Kubernetes使用一些可插拔的容器运行时引擎。rkt已经可以通过CRI使用(一个调用实例请参考minikube项目的使用说明)。




原文链接:CoreOS's rkt and Docker's containerd jointly donated to CNCF(翻译:钟最龙)

CoreOS 基于容器部署虚拟机

justinfu 发表了文章 • 0 个评论 • 3120 次浏览 • 2017-03-02 10:26 • 来自相关话题

【编者的话】本文是介绍CoreOS基于容器部署虚拟机的实践和思考,这种非传统思维非常具有启发性,为容器技术的发展提出了一种全新的方向。 IT组织经常面临的一个问题是,在选择将容器部署在物理机还是虚拟机上时,必须做出慎重的权衡。目前,大 ...查看全部
【编者的话】本文是介绍CoreOS基于容器部署虚拟机的实践和思考,这种非传统思维非常具有启发性,为容器技术的发展提出了一种全新的方向。

IT组织经常面临的一个问题是,在选择将容器部署在物理机还是虚拟机上时,必须做出慎重的权衡。目前,大多数IT组织选择在虚拟机上部署容器,因为他们已经有了一系列工具来管理虚拟机。虚拟机也被认为是更安全的,因为它能够更好地隔离容器的工作负载。

然而,CoreOS并不认同这种普遍认识,他们通过发布了其Quay Container Registry的一个版本来说明这一点,这使得现在的启动时间比原来快80%。CoreOS CTO Brandon Philips说基于Kubernetes这样一个开源的容器编排框架,最新版的Quay快很多,因为他们实际上使用的是基于容器部署的虚拟机。

为了实现这个目标,CoreOS将用于托管虚拟机的容器部署在Packet公有云服务平台上,这是一个将裸机作为云基础设施提供给用户使用的平台。然后,Quay的实例能够被用来使用容器文件和源代码去构建可在某些云上部署的容器镜像,比如AWS云。

在通过Kubernetes更快速地创建镜像这个特性基础上,Quay的实现方式将作为一个典型范例,即IT组织如何才能获得容器带来的那些众所周知的好处。从IT安全角度来看,虚拟机提供了良好的隔离机制,然而在裸机服务器上运行容器则提供了提升基础设施利用率的方法。

当然,有多少种类似方法在容器上能运行虚拟机,还有待从其他案例中进一步研究。但它确实能够说明这两种形式的虚拟化技术的融合方式可以推动容器的发展。大多数IT组织可能在不远的将来还是继续采取将容器运行在虚拟机上的做法。但许多独立软件供应商可能会选择将虚拟机运行在容器内部,以满足安全和弹性伸缩双重要求。

许多IT组织都已经达成共识,几乎每一个传统技术都可以被封装成容器的形式,以使应用程序更容易访问和易于移植。而这种容器可能会添加一些处理开销,这种传统应用将更容易从外部被访问,因为可以使用标准容器应用程序编程接口(APIs)来调用。

## 作者介绍
Mike Vizard 是一个有着25年工作经验的IT行业记者,他为IT Business Edge,Channel Insider,Baseline以及其他一些IT杂志供稿。此前,他是Ziff-Davis Enterprise的总编辑和CRN and InfoWorld的编辑部主任。

原文链接:CoreOS Deploys Virtual Machines on Top of Containers (翻译:付辉)

CoreOS的Tectonic新发行版支持Kubernetes自我管理

adolphlwq 发表了文章 • 0 个评论 • 4184 次浏览 • 2017-01-07 13:37 • 来自相关话题

【编者的话】本文详细介绍了CoreOS Tectonic(商业版Kuberbetes)新发型版中的self-hosting机制。并在文末引用Joonas Bergius的话,认为self-drivering技术在未来软件功能中很有前景。 ...查看全部
【编者的话】本文详细介绍了CoreOS Tectonic(商业版Kuberbetes)新发型版中的self-hosting机制。并在文末引用Joonas Bergius的话,认为self-drivering技术在未来软件功能中很有前景。

为了充分利用Kubernetes原生管理容器化应用的能力,CoreOS更新了自家的Kubernetes商业发行版Tectonic,增加了无停机更新的功能。

CoreOS的CTO Brandon Philips在本周纽约举办的Tectonic Summit的keynote中提到:“我们现在已经做到使用完全相同的APIs和函数监控Kubernetes和applications。我们把所有的功能集成到Tectonic控制台钩子函数中,你只需要点击一下按钮就可以完成部署。”
2544ad27-philips.jpg

Philis还提到,“目前为止,Tectonic和Kubernetes的安装过程繁琐到令人抓狂。本质上是因为,人们不得不手动去更新整个分布式系统。”

“人们ssh登录到每个节点上人工修改文件,或者至少写个脚本来执行这些任务。和管理Kubernetes应用相比这些操作需要一系列技能。”

一篇CoreOS博文在谈到自我管理能力时指出,“事实上,掌握kubectl和相关工具来管理Kubernetes应该转换为,将如何安装Kubernetes并保证它运行放在第一位。”

“这就是为什么我们非常努力地投入到上游代码,实现了Kubernetes自我管理的功能。”Philips讲到。

Philips把自我管理的能力类比为Linus Torvalds使用Linux来编译新版本的Linux。Linus Torvalds使用minix平台编译第一个Linux版本。但是Linux稳定之后,Linus就把编译器移植到稳定的Linux上,来编译新的Linux。

Kubernetes自己可以保证,某个pod故障后,它会运行一个新的pod来替代挂掉的。在这次新的Tectonic版本中,被启动的不再是新的pod,而是新版本的Kubernetes,它被打包到一组pods中。这里Tectonic利用了Kubernetes新的安装工具:kubeadm。

Kubernetes的典型升级中,与工作节点相比,所有的控制节点是优先升级的理想节点。Tectonic升级时,会在控制节点为新版本保留空间。一旦新版本运行起来,Jobs会从每个旧组件过渡到对应的新组件,直到更新完成。下面的视频介绍了Kubernetes自我更新的过程。

视频

这个方法和CoreOS更新自身的Linux发行版类似(最近更名为Container Linux)。由于Tectonic是分布式应用,所以组件的更新顺序是指定的,通常以API server,scheduler,proxy,kubeket的顺序更新。

CoreOS自身通过组件CoreUpdate、以容器的方式更新,这些操作在管理控制台里执行。

在Tectonic更新发布之前,CoreOS为企业测试提供了获取alpha和beta版本的渠道。

如果更新后出现问题,可以通过机制回退到以前的版本。Kubernetes的数据存储、etcd都会备份上一个版本的信息。我们也提供了手册指导用户从不同的故障中恢复,比如scheduler故障。

Philips还讲到,大部分企业部署案例中,自动更新相比于人工更新表现更加出色。

CoreOS不止于仅仅自我管理Kubernetes,这项技术会应用在未来的软件中。毋庸置疑,其它发行版也会使用这项技术。

CoreOS还发布了Dex 2.0,基于openID connect的认证服务。openID connect是一个广泛应用的认证协议,它可以通过加密令牌管理Kubernetes上的用户、与企业用户的轻量目录访问协议(LDAP)连接。版本2允许Kubernetes不依赖外部数据库运行Dex。Dex使用Kubernetes的APIs来持久化认证数据。但是旧版本需要数据库。

“我个人认为自我驱动技术的想法有很好的前景,那会是我们的最终方案。”DigitalOcean技术经理Joonas Bergius谈到新版本Tectonic时如是说。

Tectonic现在免费支持10的节点。

原文连接:CoreOS Offers Self-Hosting Kubernetes with New Tectonic Release(翻译:adolphlwq)

=========================================
译者介绍
adolphlwq,博客地址:QuanTalk

CoreOS 收购 Kubernetes版Git -- Redspread

YiGagyeong 发表了文章 • 0 个评论 • 3134 次浏览 • 2016-11-30 15:50 • 来自相关话题

【编者的话】本文简要介绍了 Redspread,可以实现对 Kubernetes 集群的修改和备份等功能,相当于 Kubernetes 界的 Git,但与 Git 又有所区别。而被CoreOS收购后,Spread 也会被集成到 Tectonic 中。 ...查看全部
【编者的话】本文简要介绍了 Redspread,可以实现对 Kubernetes 集群的修改和备份等功能,相当于 Kubernetes 界的 Git,但与 Git 又有所区别。而被CoreOS收购后,Spread 也会被集成到 Tectonic 中。

开源工具 Kubernetes 集群版本控制的开发人员发现,在周一宣布的收购交易中他们已经成为 CoreOS 的员工。 Redspread 去年8月发布了1.0版本的 Spread 客户端本地存储库系统,并且宣称 Docker 可以“推动容器化的演进”,现在发现自己已属于构成rkt 容器格式的公司。

“Spread 是一项伟大的技术”,CoreOS 首席执行官 Alex Polvi 在接受 The New Stack 采访时说。 “那么如何修改和备份集群呢? 这是一个基本的操作,任何公司在生成环境都会这样做,也需要这样做。 Spread 和 Git 差不多,但是是针对 Kubernetes 来说。 Spread 允许修改并存储在特定时间集群的抽象。 在后 Kubernetes 时代,能够批量备份集群,我们需要这样一个系统级的场景。

Polvi 进一步确认 Spread 功能将被纳入Tectonic — CoreOS 的 Kubernetes 商业版本。
# 简化部署
在去年8月份的一篇Redspread博客中,CEO Mackenzie Burnett 解释了 “Spread repository” 的设计用意。

“Spread 和 Git 之间的关键区别在于我们的版本化:部署的结构化数据,”Burnett写道。 “与正常的文本文件不同,结构化数据包括信息的上下文。 这意味着我们知道配置字段代表什么,或这些字段期望是什么“类型”(字符串,布尔,整数等)。 这使我们能够以编程方式“备份” Kubernetes 集群,并在这些上下文信息之上构建新功能,如字段或对象之间的连接。

CoreOS作为一个年轻的公司 ,第一次重大收购是在两年前收购Quay,一个私人托管的Docker registry,现在是 Tectonic 的主要部分,并保持了其原有名称。 Polvi 在与我们的讨论中承认了这一点,他表明尽管 Spread 的功能将被集成到 Tectonic 中,但它的存储库概念和 Quay 的企业注册表将共存。
1111.jpg

Burnett(左图)去年在马里兰大学公园大学获得国际关系学士学位。 去年2月份,业务合作伙伴和 CTO Dan Gillespie [右],在Kubernetes开发社区的一个公开会议上,将 Redspread 引入到 Kubernetes 场景中。 在会议上,他们展示了其计划 — 用一条命令使得 Spread 部署一个版本化的 Kubernetes 集群 — 这个计划在去年8月份都所有账户成功完成。

Spread 对 Kubernetes 用户的日常实践产生的一方面影响是,通过介绍目录约定 — 一种标准的方式,用以存储容器部署所需的对象,例如 Dockerfile 和各种 Kubernetes 配置(“Kube对象”) 。 在本约定中,单个 Docker 容器将被存储为`* .ctr`文件,从而鼓励构建一个可以更容易区分容器版本的系统。

对于多种部署共用的参数,可以使用给定的模板,这极大地简化了各种平台(例如AWS)的集群部署。 模板的名称作为spread部署函数的参数。 这样,开发人员可以更轻松地将测试集群部署到 Minikube — 基于笔记本电脑的开源 Kubernetes staging 环境。顺便提一下,Burnett 和 Gillespie 也是 Minikube 的贡献者。

在去年2月份的社区会议上,Burnett说,“这就是我们期望的Spread的未来 — Kubernetes 版本的 Git,一个类似于UNIX的,最小版本的命令行容器工作流。
# 快速发展
我问 CoreOS 的 Polvi,他的公司能够与Redspread 合作,是因为该公司可以继续成长为一家超过两个人的创业公司, 还是因为竞争原因收购他们的服务是绝对必要的?

“Redspread 团队非常有才华,”他回答说,“我想如果他们要继续独立,他们会非常成功。 能够与他们合作,我觉得很幸运,所以我们可以一起加速生态系统。 他们是一个非常有才华的团队,我相信如果你是这个领域的投资者,你应该投资在这些平台上运行的产品,而不是与他们竞争。 去找寻下一个 Uber ,而不是找寻iOS或Android平台的替代品。

将 Spread 的服务集成到 Tectonic 中的确切细节尚未确定,但 Polvi 表示这样的整合实际上可能加快了他未来的平台计划。 “与Redspread合作,以一种有意义的方式加速了 Tectonic 的前行,”他说。

原文链接:CoreOS Acquires Redspread, a ‘Git for Kubernetes’(翻译:李加庆

DockOne微信分享( 九十):猎豹移动基于CoreOS在AWS上的项目实践

DarkForces. 发表了文章 • 0 个评论 • 3390 次浏览 • 2016-10-31 22:57 • 来自相关话题

【编者的话】本次分享介绍基于AWS的EC2服务如何设计和搭建适合自己业务的架构方案实现全球多region部署,介绍模型案例:CoreOS的使用技巧与运维经验,把一个集群当成一台机器管理心得,包括: 为什么选择AWS和Docker为 ...查看全部
【编者的话】本次分享介绍基于AWS的EC2服务如何设计和搭建适合自己业务的架构方案实现全球多region部署,介绍模型案例:CoreOS的使用技巧与运维经验,把一个集群当成一台机器管理心得,包括:

  1. 为什么选择AWS和Docker
  2. 为什么选择CoreOS部署我们的应用
  3. CoreOS在AWS平台上如何快速构建集群并且进行管理
  4. 应用过程中遇到的问题与解决方案

#1、为什么选择AWS和Docker

QQ图片20161103134905.png

首先我先介绍一下猎豹移动的一些业务,如图, 我们在海外有着庞大的用户群体,接近16E下载量,月活用户4.94E,71%来自海外,战略合作伙伴主要以阿里、百度、腾讯、小米……
QQ图片20161103134913.png

这么大的海外用户量我们是这么做业务部署和服务的呢?

首先在选择服务商的方面我们选择了实力最强的亚马逊AWS作为我们的云服务商,我们海外几乎所有的服务都是架构在AWS的平台上面。

这给我们带来了什么好处呢,总结起来有3点:

  1. 便捷的全球化部署
因为我们的用户遍布全球,所以便捷的全球化部署是我们非常看重的,我们使用了AWS全球9个地区的region,其中包括美国3个,欧洲1个,亚太地区3个,南美洲1个,遍布全球 。

  1. 弹性的扩展
对于云服务,弹性的扩展是最为便捷的,可以在几分钟(而不是几小时或几天)内增加或减少服务器。可以同时管理一个、数百个,甚至数千个服务器实例。当然,因为这全是通过Web服务或API控制。

  1. 成本的优化
而且无需前期的投资,持续的成本优惠与调整;提高了资源利用率,按需付费;无需出国,管理世界各地的服务器,节约人力成本。

介绍完我们基础平台的选择后,为了更好的自动化,集群化,我们开始接触容器技术,而且是如何在AWS平台上实现容器化。

我们把容器的概念进行理解:给你的应用程序“打包”,能够执行一个“进程”,同时能把你执行的内容和其他“进程隔离”开来的东西,容器化有什么好处呢?
QQ图片20161103134918.jpg

这些好处在所有网站上看到的东西,听完这个介绍,感觉有点空洞,还是不知道是什么,我们用到的一些package,我再所有的系统里面都可以运行这些进程,而且进程隔离开,为什么还要Docker,这也是我们团队刚刚接触时遇到的困惑,除了Linux系统,最早提出容器化的VMware、Microsoft都有这方面的尝试,只不过他们的容器是虚拟机,而互联网的发展需要一个轻量级的容器。
QQ图片20161103134924.jpg

这个图是借鉴了Yahoo的架构,非常的可爱形象,比普通的架构图更加生动,我们猎豹有很多广告业务,商业的开发同学做的ADserver,也会有很多流式数据实时处理的系统,通过data highway汇聚到大数据处理系统,Hadoop、Spark计算,后端储存我们用的是aws-s3。如果要完成这套系统,基础架构,需要多少人力物力呢?可想而知,单单运维方面上百人的团队就这样建立起来了。

以往,我们一批机器只做一件事,比如100个adserver只做广告接口,另外100台机器只做广告检索,再有100台机器做数据传输处理,某个模块出问题去扩容或者处理某个模块,这是大家最常见的方法。这对架构的高可用设计是个很大学问,需要多机房冗余,多地部署等等。如果引入微服务的概念呢?
QQ图片20161103134930.jpg

如左边图,一台机器上面只运行各自的模块和依赖,不同机器各司其职,出问题处理问题模块。而右边微服务的设计,我无所谓我的程序如何分布,每台host都可以部署多个模块混合复用,自定义哪些模块可以和哪些分配到同一台host,哪些模块不能和哪些模块分配到同一台host,一旦某个模块挂掉,调度编排工具可以帮助马上启动一个新的docker替代工作。扩容的时候不需要针对不通模块去部署和发布,只需要调整一下各个docker的数量即可。
#2、为什么选择CoreOS部署我们的应用

下面我介绍一下我们线上稳定运行很久的一个RCV日志处理集群的容器化改造过程,下图是我们开始的架构图:
QQ图片20161103134934.jpg

开始我们的架构很简单,前端接收,经过各个模块处理后存储,然后统一进行处理分析,报表延迟很长,而且经常出问题需要手动补数据。
QQ图片20161103134937.png

后来我们对架构进行了容器话的改造,而且引入了数据流式处理,每个region部署一个收集集群,frontend的数据可以buffer一周的时间,并且可以故障后续传,通过Kafka汇总到我们的中央region的nrt系统进行准实时的数据汇总和分析,报表延迟可以控制到5分钟以内,而且每个region的集群都可以像管理一台机器一样管理。
QQ图片20161103134940.png

这套系统我们团队为他命名为Meissa,是猎户座最亮的一颗星,他底层搭建在CoreOS上,用CoreOS只带的etcd和Fleet进行集群的服务发现和编排管理,程序使用Docker进行打包,利用Jenkins进行发布,images保存在自建的docker-registry里面供集群使用。
QQ图片20161103134944.png

QQ图片20161103134948.png

#3、CoreOS在AWS平台上如何快速构建集群,并且进行管理

在AWS上面开通一套CoreOS 的集群非常方便,只需要在AWS的镜像仓库里面 选择合适的CoreOS版本,编写好user-data(Linux的cloud-init)传入正确的cloud-config即可,这个可以参考CoreOS的官网。这里说一下etcd token的使用,etcd的功能和ZooKeeper很相似,可以在私网自己通过IP定义leader的节点和数量,也可以通过官网进行token注册,比较方便。

这里举个例子:
QQ图片20161103134952.png

一个集群都用这个配置文件(可以根据不同用途修改metadata的名字),开机后会自动发现集群并且注册到一起,如下图:
QQ图片20161103134955.png

这个是集群列表,标注每个host的名字方便调度
QQ图片20161103134957.png

这个是units列表,看这个@符号,后面有1234,4台机器上运行,之前服务端的同学写个while true 脚本或者使用supervisor去判断程序是否启动,挂了拉起来,而且不可以跨服务器去守护进程,fleet可以帮你在符合条件的units任意一台上面启动这个服务,可以跨服务器。
QQ图片20161103135000.jpg

etcd的discovery key已经把各个leader节点信息记录到token的url里面,同步到各个节点,去个各个节点做服务注册和发现。
QQ图片20161103135003.png

使用fleetctl可以随需求安排程序的启动,fleet相当于集群版systemd。
QQ图片20161103135006.png

#4、应用过程中遇到的问题与解决方案

fleet 配置文件编写的一些技巧,如何合理编排自己的服务 。
QQ图片20161103135009.png

CMD ENTRYPOINT不建议使用,add和cp都一样,ENTRYPOINT可以传参数,还是写到run里面ENTRYPOINT后面写命令,“一个参数 空格 一个参数”,这样写的话转义就出问题了,这是Docker的问题,用数组的方式[bash,-c];关闭进程用stop,不要直接kill进程,因为如果你写了个shell脚本启动你的程序,那么这个进程的pid=1为bash,kill掉的是bash,而不是你的容器程序, 或者使用exec,这样会把子进程替换父进程;docker的stop会有一个tw时间,默认应该是60s,如果你的程序关闭比较慢,比如kafka需要落磁盘,60秒不够怎么办,可以手动传入比较长的timeout时间;Docker默认的ulimit是1024,有时候发现你的Docker总是莫名重启,可以看看是不是ulimit用尽了。

#Q&A

Q:没有用到Flannel,网络实现是什么,未来对CoreOS的容器管理工具rkt的计划?

A:网络上我们直接使用的host的方式,容器主要是看中了CI和CD的便利好没有往高密度的场景设计的计划,rkt是个好东西,更有开源的感觉,看后期Docker社区发展情况是否越来越封闭。

Q:registry怎么ha的,是在容器还是VM?
>A:这个问题之前也是一直困扰着我们,我们用AWS的ELB做负载均衡,后端放2台EC2,镜像存到S3,缓存写在Redis里,我们是使用官方的image,随时用随时上传和使用,挂了就再启动一个,不依赖长期有效的hub。

Q:最近暴漏的安全问题需要内核升级才能解决,这正是CoreOS的优势、不必重启系统,猎豹是否在线上有这种经验?实际中CoreOS在升级内核时是否真那么方便?
>A:这个是我们非常喜欢的一个特性,自动升级内核,做过运维的同学都知道,做一次内核升级是多么痛苦,我们最开始用的是stable766.4,现在都不用我们去升级就自动帮我们升级到8xx的stable版本了。

Q:集群中etcd节点数目是多少,奇数个etcd节点的优势具体怎么体现的,以及etcd的代理节点在业务中的价值?
>A:etcd很类似于ZooKeeper,leader节点必须是奇数个,我们一般是3个,最多5个,所有节点都会主动和leader节点通讯,leader节点可以运行在集群任何节点上,也可以通过API接口手动调整leader节点所在的底层服务器,很灵活,任何一台都可以选举成leader,不用部署任何额外配置,省心。

Q:编排调度都是自己开发的系统吗,如何管理那么多的容器?
>A:用的CoreOS自带的模块,etcd+fleet+systemd,很底层,登陆任何一台机器做操作就可以管理整个集群,就像管理一台机器一样,我们把日常发布等操作基本都用Jenkins代劳了。

以上内容根据2016年10月25日晚微信群分享内容整理。分享人齐海澎(Kuma Qi),猎豹移动高级运维工程师。负责猎豹移动商业广告产品与大数据相关产品的运维团队管理,作为猎豹移动运维部的管理团队成员,负责商业广告业务和大数据计算在AWS服务上的稳定运行,并帮助公司开展容器技术的初步尝试。3年AWS服务使用与运维经验,运维全球8个region数以千计的计算服务资源,搭建并运维起跨5个地区的基于CoreOS的Docker集群。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

Coreos 如何修改由cloud-config ,安装时生成的配置文件,重启系统后不被还原。

回复

Bruce Xiong 发起了问题 • 1 人关注 • 0 个回复 • 2203 次浏览 • 2017-07-28 15:16 • 来自相关话题

CoreOS中如何安装Docker Machine

回复

xiphis 回复了问题 • 2 人关注 • 1 个回复 • 2462 次浏览 • 2017-04-05 08:50 • 来自相关话题

请教下 coreos自动化安装(大规模)大家是怎么做的?

回复

henryrao 回复了问题 • 2 人关注 • 2 个回复 • 4335 次浏览 • 2016-07-31 22:44 • 来自相关话题

容器OS的选择与使用

回复

sealinger 回复了问题 • 19 人关注 • 9 个回复 • 16059 次浏览 • 2016-04-13 14:39 • 来自相关话题

CoreOS系统如何手动升级或者自动升级?

回复

kkkk 回复了问题 • 7 人关注 • 12 个回复 • 15565 次浏览 • 2015-06-19 09:53 • 来自相关话题

关于用vagrant安装coreos集群的问题

回复

secretomb 回复了问题 • 2 人关注 • 3 个回复 • 4235 次浏览 • 2015-04-24 19:52 • 来自相关话题

CoreOS如何配置Docker Hub Mirror地址?

回复

azhai 回复了问题 • 6 人关注 • 2 个回复 • 6946 次浏览 • 2015-04-22 19:21 • 来自相关话题

Docker 存储后端使用GlusterFS 这样做可行吗?底层系统是CoreOS

回复

徐新坤 回复了问题 • 3 人关注 • 2 个回复 • 7643 次浏览 • 2015-03-24 17:00 • 来自相关话题

coreos fleet ssh 如何配置

回复

icebolt 回复了问题 • 2 人关注 • 1 个回复 • 4108 次浏览 • 2015-03-19 13:11 • 来自相关话题

beta.release.core-os.net被樯了?

回复

xds2000 回复了问题 • 4 人关注 • 2 个回复 • 3146 次浏览 • 2015-01-24 16:55 • 来自相关话题

CoreOS Tectonic 1.8可轻松将外部服务集成到Kubernetes

edge_dawn 发表了文章 • 0 个评论 • 1380 次浏览 • 2018-03-12 21:17 • 来自相关话题

【编者的话】CoreOS Tectonic 1.8版本,轻松将外部服务集成到Kubernetes。 CoreOS公布了其最新版本的流行Kubernetes容器编排工具Tectonic 1.8。它具有新的开放服务目录,使DevOps人员 ...查看全部
【编者的话】CoreOS Tectonic 1.8版本,轻松将外部服务集成到Kubernetes。

CoreOS公布了其最新版本的流行Kubernetes容器编排工具Tectonic 1.8。它具有新的开放服务目录,使DevOps人员能够轻松地将外部服务插入Kubernetes。

正如CoreOS的构造产品经理Rob Szumski在宣布新版本的公司博客中指出,公有云在易用性方面提供了许多好处,但它们最终可能会将您锁定在一些专有工具集中。

这正是新开放云服务目录旨在解决的问题。不需要使用这些专有工具,而使您可以获得更多开放性选择,并且可以更轻松地在云或混合云环境之间切换。

“对于Tectonic 1.8而言,CoreOS开放云服务提供了与客户对托管云产品所期望的几乎相同的几乎相同的操作,这些操作有所不同。与专有云服务不同,Open Cloud Services是非常一流的,可以在CoreOS Tectonic平台上全自动的运行Kubernetes资源,“Szumski在博客文章中写道。

null.png

CoreOS的目标是尽可能保持整个流程的开放性和可移植性,以便客户可以选择他们想要部署应用程序的位置和方式。更重要的是,Open Cloud Catalog内置于构造控制台中,使得启用外部服务变得简单(或根据您的选择禁用它们)。

初期提供的开放云服务包括etcd,Prometheus和Vault。

Open Cloud Service Catalog只是Tectonic 1.8版本的一部分,该版本与17年9月底发布的开源版本保持一致。正如CoreOS指出的那样,这是Kubernetes的一个纯粹的上游版本,这意味着它不是一个分支(云本机计算基金会成员一致致力于的Kubernetes开源项目)。

它还会自动更新Docker容器引擎(开发人员使用docker引擎创建应用程序的容器)。使用Kubernetes来管理和部署容器。这意味着,它在容器DevOps两个方面兼顾。

最新版本在17年底发布,该公司表示,将对现有CoreOS客户进行Tectonic 1.7的平稳的自动更新。

原文链接: CoreOS Tectonic 1.8 makes it easy to plug external services into Kubernetes(翻译:edge_dawn)

Red Hat收购CoreOS的真正原因

kurtzhong 发表了文章 • 0 个评论 • 2588 次浏览 • 2018-02-10 15:46 • 来自相关话题

上周,企业开源领头羊Red Hat发表声明将收购CoreOS,一个在火热的容器市场中大有前途的玩家。 表面上看,这次交易的动机很明显:Red Hat需要让自己的容器故事更加丰满,而CoreOS满足这个需求。 ...查看全部
上周,企业开源领头羊Red Hat发表声明将收购CoreOS,一个在火热的容器市场中大有前途的玩家。

表面上看,这次交易的动机很明显:Red Hat需要让自己的容器故事更加丰满,而CoreOS满足这个需求。

然而,就像基础设施市场的绝大多数厂商一样,他们的(意图)是复杂的——正如容器世界中所有其他事物都是复杂的一样。

可能会有人说,复杂度是关键。
# 让容器企业就绪
自从Docker公司2014年将容器技术带到企业基础设施软件革命前线之后,厂商和企业的开发者一直在真正的企业场景中实现容器技术的应用。

容器编排和容器管理是众多缺失的环节中的两个。容器编排能使企业大规模部署容器,处理弹性伸缩中的细枝末节,对容器的价值主张至关重要。

容器管理是容器编排价值主张的补充。它使容器编排的环境具有可见性和可控制性,并增强其安全性,使其具备企业层面上运行容器其他必需的能力。

领导着容器编排战场的是Kubernetes——一个主要出自Google的开源项目。Docker有自带的编排工具Swarm,但是Kubernetes具有产品成熟度的优势,已经在生机勃勃的开源生态系统中夺取了统治者地位。

但是Kubernetes并没有直接解决容器管理中的复杂度问题,这正是CoreOS试图用自己的Tectonic产品来填补的空档。“Tectonic将领先的容器管理解决方案和大规模运行容器所有所需结合起来”,CoreOS的网站这样说道,“这意味着其拥有最好的开源组件,久经沙场的安全系统,和完全自动化的运营。Tectonic是企业级Kubernetes。”
# 复杂度的挑战
如果用来满足企业需求在技术层面听起来很复杂,那你的感觉没错——容器自身的复杂度是一个有争议的区域。“与平台自身不一样,构建Kubernetes自身这个日常的预先任务是复杂艰难的”,RackN的CEO和创始人之一Rob Hirschfeld说,“多节点运营是复杂的:这是我们想要Kubernetes这样平台的原因”。

但是,Kubernetes却没有让容器变得更简单。“实际的情况是Kubernetes很复杂。安装好并让它运行起来颇具挑战——没有必要否认这一点。但是这种复杂度也可以反过来说是一个好处”,Matt Rogish,ReactiveOps的创始人说。“ECS和Docker Swarm表面看来似乎简单点,但是它们有更高的偶然复杂度——而且这个复杂度被强加给你。相反,Kubernetes偶然复杂度很低,本质复杂度(用来实现实际上需要的功能的复杂度)很高”。

在Kubernetes上增加额外的像CoreOS Tectonic的容器管理层也并没有降低其复杂度。反而是为了帮助机构管理它。“基于容器的应用正驱动着下一代的技术,它们跨多个或者混合云平台应用驱动,包括物理的、虚拟的,私有云和公有云平台”,Paul Cormier,Red Hat的产品和技术部门总裁说。“我们相信这次收购将会奠定Red Hat在混合云和现代应用部署的奠基石地位”。
# 似曾相识的复杂度:OpenStack
有巨大复杂度的开源企业基础设施软件并不是什么新鲜事。拿OpenStack为例,这个私有云基础设施先驱有大量的活动部件,它的生态系统十分多元化、拥挤不堪,这为它赢得了格外复杂和难以处理的名声。好几年我们都听到OpenStack这同样的事情”,RackN的Hirschfeld说道。

一点也不让人意外的是,过去几年吸引到OpenStack的注意力都转移到了Kubernetes和容器社区的其他地方——今天,OpenStack已经成了像CoreOS Tectonic这样的科技要解决的复杂度。CoreOS的官网上称,“Tectonic是全面Kubernetes解决方案,用来在任何地方部署、管理、和安全加固容器,它能结合OpenStack的优点,和Kubernetes的基于容器的工具链。有CoreOS在你左右,借助最好的容器基础设施,OpenStack将变的更容易管理和部署”。

CoreOS的网站继续说道,“OpenStack在复杂度方面的名声有时候盖过了它的能力。Kubernetes集群编排能让OpenStack的管理和管理更加容易”。

对于Red Hat来说,OpenStack的复杂度是一个它能帮助客户解决的问题。“容器使得应用在混合云环境具有了可移植性,所以客户今天能在不同的地方部署应用:在Amazon、Azure和Google这样的公有云上,在VMWare和OpenStack这样的本地部署平台上,或者在物理裸机上”,Joe Fernanes,Red Hat的负责OpenShift产品部资深管理经理解释说,“一直以来,我们在OpenShift和Kubernetes以及容器上的投入都是要建立起这种抽象,使得应用可以高效地在所有这些地方部署”。

Alex Polvi,CoreOS的CEO,在这个话题上发表了更加细致的观点。“通过把OpenStack作为一个应用在Kubernetes运行,我们能将这个数据中心整合成一个已经被超大规模的巨头验证的平台”。
# Red Hat的开源策略
Red Hat的商业模型集中在为本质上免费开源的软件提供支持和服务。然而,尽管CoreOS是基于开源构建的,Tectonic也包含商业代码。“我们想特别澄清的是CoreOS专注于开源项目和协作,即使这意味着我们对手可以与我们竞争,我们在保持这两个平台分离”,Kelsey Hightower在2015年当他还是CoreOS的开发者和提倡者的时候这样说。他现在是Google的Staff Developer Advocate。“有一个coreos.com,其是关于Linux容器开源项目的;然后tectonic.com是将这些项目结合起来组成一个商业解决方案的,但是它们并不与相关开源项目冲突”。

就其本身而言,Red Hat一直以来都是Kubernetes的一个主要贡献方。“Red Hat在拥抱容器和容器编排方面起步早,已经向相关的开源社区做了深度贡献,其中就包括Kubernetes,在其中是仅次于Google的第二大领导者。”Red Hat在一个新闻发布上解释道:“现在有了Red Hat和CoreOS的结合,Red Hat同时扩大了其在上游社区和基于容器的企业解决方案方面的领导力。”

在Red Hat是否会将Tectonic中的商业代码开源这一件事情上,他们的态度很谨慎。“CoreOS的绝大多数技术都已经开源”,Red Hat的FAQ列表解释道,“Red Hat长久以来都展示了将不开源的在必要时候开源的决心,我们没有理由看到我们在这条策略上会有什么改变”。
# 整理总结
作为一个开源厂商,Red Hat不是从软件的知识产权中获利——因此,CoreOS的IP价值对于这次收购关系很小。

这个故事实际上是关于人的,CoreOS公司有130名员工,从很多方面看这次交易是一次收购式招聘,同时借助Red Hat的专业团队来将为其企业客户提供了更加全方位服务。

相比较而言,这次交易与Red Hat的传统竞争者IBM和Oracle关系较小,与Docker公司竞争的关系更大。“它们的联合对于我而言是一次人才的合并……能壮大OpenShift Enterprise相较于Docker公司的Docker企业版的影响力”,BoxBoat的CTO,Will Kinard说。

OpenShift是Red Hat的PaaS方案,而且有一些CoreOS的技术和人力将会分别在OpenShift产品和OpenShift团队中找到更好的位置。

Janakiram & Associates分析师Janakiram MSV同意这种观点。“在企业领域,Red Hat是Docker公司的一个关键竞争者。这次收购将会给Docker公司带来压力,它们目前为止已经从不同的投资方募集到2.4亿美元。它必须加快在获取企业客户的速度,并且推动其商业产品的采用率。”


然而,对于Red Hat的客户来说,这场战斗是关于人才的——这是一个OpenStack和Kubernetes相继追随的模式。“客户不具有OpenStack的技术积累,它们只知道它们需要它”,Jon Keller,Technologent的field CTO说。“对于Kubernetes是同样的情况。它十分合适,因为它们无法找到足够多的人来自己做”。

容器生态如此复杂因而对于Red Hat来说是一个加分,特别是在混合IT情景增加了额外的复杂度的情况下。“我们相信这次收购会为Red Hat在混合云和现代应用部署打好奠基石”,Red Hat的Cormier总结说。

总之,Red Hat的客户成为最后的赢家。“我们相信我们最大的客户将会从中获益”,Red Hat的VP和总经理Ashesh Badani说。

CoreOS的技术和团队在Kubernetes方面已经具有全面的能力,它们的加入在混合IT的情景下能呈现出在今天可能最可靠和全面的现代基础设施。随着整个容器生态系统走向成熟,Red Hat的统治只会变得愈来愈强。

原文链接:The Real Reason Red Hat Is Acquiring CoreOS(翻译:钟最龙)

红帽收购完CoreOS,接下来将如何整合两家公司的Kubernetes产品?

sean 发表了文章 • 0 个评论 • 2693 次浏览 • 2018-02-07 18:21 • 来自相关话题

鉴于周二宣布的一项收购协议,Kubernetes容器编排领域内两个最突出的商业品牌将合二为一。率先打开容器市场,并带来精简Linux内核概念的CoreOS,现在成了红帽的全资子公司。根据即将成为红帽高管的CoreOS CEO Alex Polvi所述,该交易已 ...查看全部
鉴于周二宣布的一项收购协议,Kubernetes容器编排领域内两个最突出的商业品牌将合二为一。率先打开容器市场,并带来精简Linux内核概念的CoreOS,现在成了红帽的全资子公司。根据即将成为红帽高管的CoreOS CEO Alex Polvi所述,该交易已经完成,没有等待期。

Polvi说:“得益于此次收购,我们可以将两条产品线结合形成客户无法在市场上找到的一套无与伦比的机能。虽然我们的产品是竞争关系,但它们在很多方面是高度分化的。OpenShift和Tectonic看起来都是Kubernetes产品,但它们的工作方式及对客户的价值诉求完全不同。将这些东西组合在一起,将产生市场上所可能拥有的终极产品。”

这是一份来自即将变成前CEO的人的雄心勃勃的声明。从技术上说,这笔交易只是私下交易的一次收购,据报道,红帽历史上有过21笔类似的交易。虽然红帽通常不会公布其收购价值,但这笔CoreOS交易它给出的交易价值是2.5亿美元。该公司在2015年收购配置自动化公司Ansible首次公布协议时估值为1亿美元,不过此前有个独立调查将其估值定为1.5亿美元。
# 不确定的融合
红帽明确表示、同时也是急于宣布的是本次交易中浮现出来的基于Kubernetes的产品。

“我们面前有一个机会来做有意义的决定,”红帽负责OpenShift的副总Ashesh Badani以非常巧妙的措词说明Tectonic在OpenShift产品线中的位置尚未最终确定。

“我们将用几周时间而非几个月好好考虑最合理的方式。如何将这两种技术整合在一起,从而保留二者的精华部分?”Badani接着说。他说,Tectonic具有一定的商业客户份额,因此红帽在品牌整合时将尽可能保持这些客户所带来的价值。但是,他强调,OpenShift产品计划不会中断。

“给我们点时间,我们的工程师团队、产品团队、市场团队将坐在一起研究最佳的行进路线,”他说道。

难道CoreOS与红帽在签署协议前没有这样的坐谈机会?并非如此,Badani说,尽管谈判的财务部分进行得很充分,但与交易后业务相关的事项需要保密。因此,在写作本文时,Tectonic将采用的具体形式,以及它如何与红帽的OpenShift产品线并行或合并均尚无定论。

这是否意味着CoreOS大量人员,包括Polvi、CTO及联合创始人Brandon Philips以及工程师主管李响的命运都悬而未决?Badani明确表示CoreOS的开发和技术人才都将被邀请在红帽中留任,他强调说公司的员工是他心目中的重要资产。

Badani说,“这笔交易和伙伴关系的完成,依靠的是CoreOS为市场带来的大量工程人才和创新。如果我们未尽一切可能保证将Alex、Brandon以及所有其他人在内的整个工程和市场团队带入,那就是我们的责任。”他补充说,尽管头衔有待调整,他们从今天起就是该公司的正式成员。他说,产品的路线图可能需要做调整,这有助于最终决定他们的新头衔。
# CoreOS的核心所在
CoreOS的Polvi列出了他认为有别市场其他产品的独特的公司产品,并希望将他们整合到红帽产品线中。Quay(几乎没人读成“key”)私有容器注册中心是他希望能生存并发展下去的一个产品,就像etcd一样,后者是Kubernetes出现之后的事实键值仓库,也是红帽工程师的长期首选组件。

Container Linux也是Polvi提到的有可能在交易浮现出来的一个差异化产品——CoreOS的名字即来源于该产品。考虑到红帽自身是Linux操作系统的制造商,这可能是一厢情愿的想法。Atomic Linux已经是红帽企业Linux(RHEL)一个轻量级的发行版,旨在运行于由一个完善的中央REEL核心管理的分布式主机上。

红帽周二发布的FAQ显示,部分Container Linux交付机制可能被移植到Atomic上,特别是早在2015年与红帽竞争时,Brandon Philips引以为傲的CoreOS优于Atomic的在线更新系统。红帽将此移植形容为两个操作系统之间的“和解”。 这条消息似乎在宣布Container Linux被正式收购后不久消失了。

该消息促使CoreOS Tectonic产品经理Rob Szumski通过谷歌讨论组及Twitter中提供了一些补充说明。

Szumski写道:“Container Linux一直是免费提供的,我们预计这不会改变,红帽计划继续Container Linux的开发。事实上,与将Fedora的创新技术融入红帽企业Linux类似,我们可能会看到类似更新交付机制的Container Linux创新被融入其中。”

上述陈述中的关键词是“可能”。

与此同时,根据红帽和CoreOS的说法,rkt——这个在2015年首次挑起容器界短暂大分裂的容器格式和运行时——不在谈判桌的议题中。在去年被捐赠给云原生计算基金会(CNCF)后,rkt仍然可能会出现在一些客户驱动的实现中,不过Polvi告诉我们,他期望rkt能够根据自己的长处找到价值所在。

根据Polvi和Badani的说法,收购讨论中也未提及Docker或Docker Inc。

Badani说:“我们将持续接受开源社区中的每个合作机会。在竞争方面,我们并没有真正看到太多Docker的表现。过去几个月,随着亚马逊和微软Azure的加入,Kubernetes的市场势头非常明显。Docker最近才开始在这方面进行投入,因此还未展现出足够的竞争力。他们的Swarm编排技术不像他们所希望那么有竞争力,这就是他们也要投资Kubernetes的原因。我真的不担心他们。”

Polvi说:“CoreOS主要销售产品给那些想要使用Kubernetes的公司。目前企业用户能在市场上找到的Kubernetes产品实际上只有两种:Tectonic和OpenShift。Docker宣布了一款Kubernetes产品,现在已有一个Alpha或Beta产品,但是并没有准备就绪的企业销售团队。也许将来会发生变化,但客户现在需要Kubernetes。”

Docker在1月18日发布了Docker Enterprise的Beta版Kubernetes集成。
# 寻找Kubernetes市场
根据Polvi的算法,市面上将只有单一一个企业Kubernetes供应商。Kublr可能会对此感到震惊,但至少在这位前CEO的头脑中,他的产品与Red Hat的结合必将胜出。

不过这块蛋糕到底有多大?在去年秋天的一项调查中,CNCF请企业选择他们在生产中所使用的编排器,约69%的受访者表示他们使用了通用的Kubernetes,而OpenShift仅占总数的12%,Tectonic仅占4%。
01.jpg

当问题限定在占比23%、部署超过1000个容器的受访者子集时,OpenShift在该子集中的份额增长至17%。但Tectonic的份额减少了一半,而通用Kubernetes获得了3分。

所以也许这次收购可能会在Kubernetes市场有所作为,只是其市场本身在总体生态系统中占比不足三分之一。又或者,正如IT分析师Kurt Marko所认为的那样,这里面有市场的想法可能是一种幻觉。

Marko在写给The New Stack的报告中写道,“Kubernetes是集群管理/工作负载编排的事实标准。包括红帽在内的任何人都无法主宰这个市场,因为这不是一个真正的市场,它只是一个功能。”

Marko继续写道:“我真的不认为多数企业客户(比如经理、高管,而非开发人员)会考虑他们所运行的Linux发行版等细节。他们更感兴趣的是能够可靠安全地运行应用程序、能够提供良好的性能,并得到定期更新和问题响应支持的东西。如果CoreOS在容器方面工作更好,那很好,如果它捆绑在一个包含了Kubernetes、注册中心和虚拟网络结构(Contiv等)的容器平台中,那更好。”

Marko在红帽的产品线中确实看到了适合Container Linux的位置,特别是Tectonic作为OpenShift PaaS的基础架构平台。但是,这种天作之合现在几乎每周都会出现,有时甚至不需要并购或收购,思科上周就公布了自己的思科容器平台,这又是一个品牌化的Kubernetes服务。”

Marko写道:“我认为真正的‘战斗’将是赢取希望使用混合容器架构的用户,这种架构将内部部署和公共云容器服务无缝地结合在一起。在这一点上,红帽还有更多的工作要做,特别是考虑到谷歌/VMware和谷歌/思科的合作关系。”

因此,虽然这笔交易明显改变了开发者心目中Kubernetes的战场,并可能进一步边缘化Docker,但实际上可能不是那种用于表征软件平台成熟度的“市场整合”。更像是服务器市场一个主要选手找了个途径来利用一个产品的成功之处,如果这个产品从一开始就是商业化、专有化的,即使是一个金矿……没有人会听说它。

原文链接:Docker Who? By Acquiring CoreOS, Red Hat Aims to Be the Kubernetes Company(翻译:梁晓勇

红帽公司收购CoreOS,旨在拓展自身在Kubernetes与容器领域的领导地位

大卫 发表了文章 • 0 个评论 • 3813 次浏览 • 2018-01-31 08:11 • 来自相关话题

凭借CoreOS的加持,红帽公司将进一步加大技术开发力度,从而帮助客户立足混合与多云环境构建、运行并管理容器化应用程序。 作为全球规模最大的开源解决方案供应商,红帽公司今天宣布其已经签署一项最终协议,将收购Kubernetes与容器原 ...查看全部
凭借CoreOS的加持,红帽公司将进一步加大技术开发力度,从而帮助客户立足混合与多云环境构建、运行并管理容器化应用程序。

作为全球规模最大的开源解决方案供应商,红帽公司今天宣布其已经签署一项最终协议,将收购Kubernetes与容器原生解决方案领导者兼创新者CoreOS公司。此笔交易的总价为2.5亿美元,虽然可能在实际执行时作出些许调整,但幅度应不会太大。红帽公司对CoreOS的收购将进一步助力客户构建一切自身需要的应用程序,并将其部署在红帽灵活的开源环境当中。通过将CoreOS的补充性功能与红帽此前已经广泛推动的Kubernetes以及红帽OpenShift容器化产品相结合,开源巨头希望进一步加快其面向现代应用工作负载的领先混合云平台的普及与发展速度。

我们相信,此次收购将成为红帽旗下混合云与现代应用部署的发展基石。

——PAUL CORMIER,红帽公司产品与技术总裁

随着应用程序逐步向混合及多云环境迁移,越来越多的企业开始利用容器方案以简化与云环境对接的各类应用程序的构建、部署与移动工作。IDC公司指出,“目前,云采用、简化与可移植性方面正取得实质性进展,市场对于云服务的需求也在持续增长。预计在未来几年当中,云计算架构将成为企业客户的主要支出方向。而随着容器体系的日益复杂化,企业应在寻求应用平台供应商的帮助,从而更轻松地利用容器技术对现有生产性应用程序进行转换与扩展,最终将其顺畅运行在公有云或私有云环境之内。”

创立于2013年的CoreOS公司旨在为各种规模的企业构建并交付基础设施,帮助其获得与大型软件企业对等的运营环境、实现自动更新与服务器修复,并协助解决停机时间控制、安全性保障以及恢复能力实现等实际难题。自早期发布针对容器作出优化的轻量级Linux操作系统以来,相关技术使得可扩展与弹性容器化应用程序的广泛使用成为可能,这也令CoreOS成为这一技术领域内备受赞誉的领导者。

CoreOS公司亦是CoreOS Tectonic的缔造者,这是一套企业级Kubernetes平台,负责跨越私有云以及不同公有云供应商为企业客户提供自动化运营与可移植能力,且完全基于开源软件实现。该公司旗下还拥有CoreOS Quay,一套企业级容器注册方案。CoreOS公司亦因积极推动容器化应用程序层面的开源创新贡献而广受好评,具体包括身为Kubernetes的主要贡献者、创建并维护轻量级Linux发行版Container Linux(用于自动执行软件更新并简化容器运行)、推出Kubernetes分布式数据存储方案etcd、向云原生计算基金会(简称CNCF)捐赠应用程序容器引擎rkt,以及积极推动当前开放容器倡议(简称OCI)标准的普及等等。

红帽公司很早就开始接纳容器与容器编排技术,并对包括Kubernetes在内的相关开源社区作出深入贡献——事实上,红帽已经成为Kubernetes社区中仅次于谷歌的第二大贡献者。红帽公司在基于容器类应用的开发方面同样是全球范围内当之无愧的领导者,其重要成果正是红帽OpenShift(业界最全面的企业级Kubernetes平台)。如今与CoreOS合并之后,红帽公司将能够在上游社区与企业级容器解决方案领域进一步奠定自身的领导优势。

预计这笔交易不会对截至2018年2月28日的红帽公司第四财季或整个财年指标造成重大影响。

此笔交易预计将于2018年1月之内结束,但须遵循成交条件惯例。

感兴趣的朋友亦可访问红帽公司博客,通过其官网了解更多与收购相关的细节信息。

大力支持

Paul Cormier红帽公司产品与技术总裁指出:

“新的技术时代将受到跨多云与混合云环境(包括物理、虚拟、私有云以及公有云平台)的基于窗口类应用的有力驱动,而Kubernetes、容器以及Linux已经成为这一转型的核心所在。与红帽一样,CoreOS一直是推动这些创新的上游开源社区领导者,同时亦在为企业客户提供企业级Kubernetes服务方面保持领先地位。我们相信此次收购将帮助红帽公司进一步巩固混合云与现代应用部署的基础。”

Alex Polvi,CoreOS公司CEO指出:

“红帽与CoreOS的合作关系已经持续了很长时间。作为开源协作方,我们共同为容器及分布式系统开发出一系列关键性创新成果,并帮助将自动化运营转化为现实。此次合并标志着我们在推进共同目标方面迈入新的阶段,也意味着我们的这些重要技术成果将进一步在各类企业乃至世界范围内得到普及。在这里要感谢CoreOS大家庭、感谢我们的客户、合作伙伴。当然,最重要的是要感谢自由软件社区对我们使命的不懈支持,这一切都将以自动化运营方式令互联网体系变得更加安全。”

原文链接:Red Hat to Acquire CoreOS, Expanding its Kubernetes and Containers Leadership(翻译:David)

容器监控的基石Prometheus 2.0到来

codesun 发表了文章 • 0 个评论 • 4618 次浏览 • 2017-11-12 15:36 • 来自相关话题

【编者的话】本文为大家带来了Prometheus 2.0中新存储层需求的由来,主要的挑战,实现的简要介绍,以及相关的基准测试结果,相关领域人员可以参考一下。 Kubernetes使得复杂环境的管理变得容易,但是为了确保可用性,对Kub ...查看全部
【编者的话】本文为大家带来了Prometheus 2.0中新存储层需求的由来,主要的挑战,实现的简要介绍,以及相关的基准测试结果,相关领域人员可以参考一下。

Kubernetes使得复杂环境的管理变得容易,但是为了确保可用性,对Kubernetes组件以及群集上运行的所有应用程序进行操作深入分析至关重要。在CoreOS,我们相信监控是良好生产环境的基石,这也是我们投入开发Prometheus监控系统的原因。作为一个由Cloud Native Computing Foundation(CNCF)支持的项目,Prometheus迅速获得了基础设施及应用监控方面的热度,今天是它更进一步的时候。
01.png

CoreOS将Prometheus作为我们企业级Kubernetes平台Tectonic的集成组件,并且我们也一直在努力提升其对Kubernetes用户的价值。今年早些时候,我们分享了关于下一代Prometheus(version 2.0)的新存储层方面的工作。为了稳固这项工作,我们和Prometheus团队以及我们的用户进行了更加密切的合作。在3个alpha版本,6个beta版本以及3个RC版本之后,今天Prometheus 2.0正式宣布稳定版本。感谢Brian Brazil和Goutham Veeramachaneni,他们在这项工作中付出巨大。在我们探索该发行版的优点之前,让我们回过头来,先探讨一下我们为何需要一个新的存储层。
# 时间序列和动态环境
Prometheus关于监控的理念鼓励在堆栈的每一层都采用高度详细的度量工具。容器的状态,通过的请求流,甚至是运行于其中的应用的深层信息都通过度量工具对外可见。Prometheus带来了一款强力的查询语言帮助将度量数据汇总转换成行动方案。

Prometheus通过时间序列的方式收集和存储数据,它是通过固定间隔收集到的带有时间戳数据的序列。这种设计可以使运行中的容器轻松产生成千的时间序列。随着容器的规模从成百扩展到成千,在集群中很可能产生数百万被跟踪的时间序列。

为上百万的时间序列持续写入数据显然是一项技术难题。更糟糕的是,Kubernetes使得持续销毁和创建容器变得十分容易。该项模型对于持续部署,自动扩容以及批处理作业调度而言是极为强大的,因此只会随着时间的推移而变得越来越普遍。

每个容器都有一个独一无二的标识符,所有其时间序列均包含该标识符,以达到最佳的视角。因此当被跟踪的活跃时间序列总数大致固定时,Prometheus中可以对外访问的所有历史时间序列数据是持续增长的。允许查询十亿级的时间序列是一项全新的挑战,但我们决定让Prometheus很好地支持该特性。

新的存储引擎就是用来解决这项挑战的。受到全文搜索的启发,它使用倒排索引以提供对于Prometheus时间序列可能拥有的任意纬度进行快速检索。新的磁盘格式确保相关的时间序列数据良好分布,另外write-ahead日志也使得Prometheus 2.0n能够从崩溃中恢复。

Prometheus同样变得更易操作了。Prometheus 1.x的用户应该对调整期望负载的存储配置十分熟悉。然而,有了新的存储层之后,这些控制就不再需要了。
# 基准测
这项工作的真实结果是令人印象深刻的。Prometheus 2.0的资源消耗得到了显著降低,使用率更加稳定,并且新的索引方式带来了更低且一致的查询延迟。

下方的图是一个基准测试集的结果,它来自一个运行着成百个应用Pod并被监控的Kubernetes集群。Pod按照高频率替换以产生时间序列的扰动。各有2个Prometheus 1.5和Prometheus 2.0实例运行采集新数据。不同版本中,各有1个实例对外服务,以产生适中性的高查询负载。

从前2个图中,我们可以看到Prometheus 2.0的内存和CPU消耗均明显更低,并且自启动后,它们很快到达稳定状态。Prometheus 1.5则需要更多的资源,并且其资源使用率难以预测。
02.png

03.png

Prometheus 2.0中最大的改进是其每秒写入磁盘的数据量,可以查看下图。新版本的写入量较之前低了近2个数量级。很明显,这能增加SSD的寿命(译者:SSD寿命由PE次数决定,与写入数据量密切相关),进而降低成本。在高序列扰动的情况下,即使使用相同的序列压缩算法,依旧可以观察到显著的磁盘空间节省。
04.png

在Prometheus 1.5中,随着更多的时间序列被创建,查询的延迟是线性增长的。Prometheus 2.0则从一开始就维持了稳定的性能,它使得查询的反馈更加敏捷,正如下图所示。
05.png

# 其余新特性
Prometheus 2.0的大多数工作都聚焦于提升性能并使其更加易于操作。但是新的存储层同样被设计以更好地和Prometheus的外部交互,这使得围绕收集到的时间序列数据进行广泛的定制处理成为可能。

快照备份是一项被频繁要求的特性。当使用flag `--web.enable-admin-api`时,只需要通过简单的API调用,Prometheus 2.0便可原生支持它们。
bash
$ curl -XPOST http:///api/v2/admin/tsdb/snapshot
{"name":"2017-10-18T13:44:35Z-3f6a679bb001e65d"}

快照存放于名为返回值的目录中,且可以被上传到归档存储中,它们几乎不会占用额外的磁盘空间。最棒的是,新的Prometheus服务器可以从备份的数据启动,你只需将数据移动到新的服务器数据目录中即可。

关于完整的变更列表以及如何从Prometheus 1.x迁移,请查看官方声明以及迁移指南
# 敬请尝试
有关Prometheus 2.0增强的最佳部分是,Prometheus当前不但可以比以往更好地支持Kubernetes的工作负载,更在于当Kubernetes在基础设施中活力倍增时,它预留了足够的空间来支撑届时的工作负载。

想要了解Prometheus,请关注11月16日上午8时webinar上关于新特性的PT(来自Prometheus开发者Frederic Branczyk)。

如果你想要亲自了解集成Prometheus支持是如何使得CoreOS Tectonic成为真正的企业级Kubernetes平台的,你可以免费部署一个不多于10个节点的Tectonic集群。你将能够使用最新的Prometheus操作器不费吹灰之力地在集群中部署Prometheus 2.0,而无需额外的配置。

声明:本文中的基准测试通过prombench生成。为了复现它们,你需要一个配置好的AWS账户,并且你必须指定想要执行的基准测试spec。`spec.example.yaml`正是生成本文所用图的spec。
# 相关文章

+ Prometheus 2.0: New storage layer dramatically increases monitoring scalability for Kubernetes and other distributed systems
+ The Prometheus Operator: Managed Prometheus setups for Kubernetes
+ Monitoring Kubernetes with Prometheus | Prometheus Docker Monitoring
+ CoreOS and Prometheus: Building monitoring for the next generation of cluster infrastructure

原文链接:Prometheus, the backbone of container monitoring, hits 2.0(翻译:孙科)

为什么我们创立CoreOS

cyeaaa 发表了文章 • 0 个评论 • 1688 次浏览 • 2017-09-20 22:46 • 来自相关话题

【编者的话】经常有人问,我们为什么要创立CoreOS。以前写过,我们的使命是保护互联网安全,更进一步讲:为什么我们会关注互联网安全?这个是CoreOS的核心问题,保护互联网安全是保护我们的隐私以及最终自由的关键。 # 自由,隐私与安全 ...查看全部
【编者的话】经常有人问,我们为什么要创立CoreOS。以前写过,我们的使命是保护互联网安全,更进一步讲:为什么我们会关注互联网安全?这个是CoreOS的核心问题,保护互联网安全是保护我们的隐私以及最终自由的关键。

# 自由,隐私与安全
“我相信自由。”,那种马丁•路德•金所指的自由。正是这种自由激发了我对自由软件的热情。然而我也相信我们生活的时代,生活和技术以某种限制自由的方式交织在一起。

科技给生活带来了巨大的进步,但也有和隐私冲突的倾向。

美国宪法,特别是《权利法案》确立了保护隐私权,因为隐私是自由的基础。试想选举投票过程:如果因为怕被监视而不能做出自己认可的选择,就不是自由选举了。

随着我们的生活越来越数字化——从物流服务到食品配送,甚至恒温器和冰箱都要接入互联网——它们越来越多地被掌握在以云服务方式提供新产品的公司手中。如果这些云服务没有正确地构建和及时地维护,将不可避免地被黑客攻击。一旦它们被黑客入侵了,我们会失去有些隐私并损害我们的自由。

这就是我们为什么要创立CoreOS,保护互联网安全。因为一次次地看到,数以百万计的数据,在重大数据泄露中遭受破坏,我们就铺了一个大家都可以对此来做点什么的路。

# 防止数据泄露
最近,Equifax被黑事件就是个很好的例子。 Equifax是一家信贷报告公司,被迫成为云服务公司。因为一个开源软件的安全更新安装失败,导致Equifax的系统被黑客入侵。它是人类历史上最大的隐私泄露事件之一,也是对自由世界最大的打击之一。这使我深受困扰。我相信,CoreOS是解决方案的一个重要组成部分。

在CoreOS,我们的目标是通过工具创建他们的云服务来武装这些公司以及正确地运行我们的数字生活。我们也致力于,让他们自己能够轻松地运行这些高度复杂的系统。不会再错过任何更新,默认启用全部安全功能,新版本应用也会安全快速地交付。

作为CoreOS的联合创始人兼首席执行官,我对迄今为止所取得的成就感到非常自豪。 我们还没有结束。没有什么比与CoreOS团队合作,更值得让我献身的事了。

想了解CoreOS的企业级Kubernetes平台如何让系统更容易管理,更可靠,更安全,请试用Tectonic today


原文链接:为什么我们创立CoreOS(翻译:陈晏娥, 校对:田浩浩)

===========================================
译者介绍
陈晏娥,鞍钢集团矿业公司信息开发中心高级工程师,专注虚拟化技术。

CentOS 7上搭建安全、容灾、高可用的etcd集群

张夏 发表了文章 • 1 个评论 • 14209 次浏览 • 2017-08-06 22:38 • 来自相关话题

【编者的话】etcd 是 CoreOS 团队发起的开源项目,基于 Go 语言实现,做为一个分布式键值对存储,通过分布式锁,leader选举和写屏障(write barriers)来实现可靠的分布式协作。 本文目标是部署一个基于TLS( ...查看全部
【编者的话】etcd 是 CoreOS 团队发起的开源项目,基于 Go 语言实现,做为一个分布式键值对存储,通过分布式锁,leader选举和写屏障(write barriers)来实现可靠的分布式协作。

本文目标是部署一个基于TLS(Self-signed certificates)的安全、快速灾难恢复(Disaster Recovery, SNAPSHOT)的高可用(High Availability)的etcd集群。
##准备工作
版本信息:
OS: CentOS Linux release 7.3.1611 (Core) 
etcd Version: 3.2.4
Git SHA: c31bec0
Go Version: go1.8.3
Go OS/Arch: linux/amd64

##机器配置信息
CoreOS官方推荐集群规模5个为宜,为了简化本文仅以3个节点为例:
NAME       ADDRESS	          HOSTNAME	                  CONFIGURATION
infra0 192.168.16.227 bjo-ep-kub-01.dev.fwmrm.net 8cpus, 16GB内存, 500GB磁盘
infra1 192.168.16.228 bjo-ep-kub-02.dev.fwmrm.net 8cpus, 16GB内存, 500GB磁盘
infra2 192.168.16.229 bjo-ep-kub-03.dev.fwmrm.net 8cpus, 16GB内存, 500GB磁盘

官方建议配置
硬件            通常场景                    重负载
CPU 2-4 cores 8-18 cores
Memory 8GB 16GB-64GB
Disk 50 sequential IOPS 500 sequential IOPS
Network 1GbE 10GbE

注:重负载情况以CPU为例,每秒处理数以千计的client端请求。AWS、GCE推荐配置请参考:Example hardware configurations on AWS and GCE
##搭建etcd集群
搭建etcd集群有3种方式,分别为Static, etcd Discovery, DNS Discovery。Discovery请参见官网https://coreos.com/etcd/docs/latest/op-guide/clustering.html,在此不再敖述。本文仅以Static方式展示一次集群搭建过程。
每个node的etcd配置分别如下:
$ /export/etcd/etcd --name infra0 --initial-advertise-peer-urls http://192.168.16.227:2380 \
--listen-peer-urls http://192.168.16.227:2380 \
--listen-client-urls http://192.168.16.227:2379,http://127.0.0.1:2379 \
--advertise-client-urls http://192.168.16.227:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=http://192.168.16.227:2380,infra1=http://192.168.16.228:2380,infra2=http://192.168.16.229:2380 \
--initial-cluster-state new

$ /export/etcd/etcd --name infra1 --initial-advertise-peer-urls http://192.168.16.228:2380 \
--listen-peer-urls http://192.168.16.228:2380 \
--listen-client-urls http://192.168.16.228:2379,http://127.0.0.1:2379 \
--advertise-client-urls http://192.168.16.228:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=http://192.168.16.227:2380,infra1=http://192.168.16.228:2380,infra2=http://192.168.16.229:2380 \
--initial-cluster-state new

$ /export/etcd/etcd --name infra2 --initial-advertise-peer-urls http://192.168.16.229:2380 \
--listen-peer-urls http://192.168.16.229:2380 \
--listen-client-urls http://192.168.16.229:2379,http://127.0.0.1:2379 \
--advertise-client-urls http://192.168.16.229:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=http://192.168.16.227:2380,infra1=http://192.168.16.228:2380,infra2=http://192.168.16.229:2380 \
--initial-cluster-state new

##TLS
etcd支持通过TLS加密通信,TLS channels可被用于集群peer间通信加密,以及client端traffic加密。Self-signed certificates与Automatic certificates两种安全认证形式,其中Self-signed certificates:自签名证书既可以加密traffic也可以授权其连接。本文以Self-signed certificates为例,使用Cloudflare的cfssl很容易生成集群所需证书。
首先,安装go以及设置环境变量GOPATH
$ cd /export
$ wget https://storage.googleapis.com/golang/go1.8.3.linux-amd64.tar.gz
$ tar -xzf go1.8.3.linux-amd64.tar.gz

$ sudo vim ~/.profile
$ export GOPATH=/export/go_path
$ export GOROOT=/export/go/
$ export CFSSL=/export/go_path/
$ export PATH=$PATH:$GOROOT/bin:$CFSSL/bin

$ source ~/.profile

下载并build CFSSL工具, 安装路径为$GOPATH/bin/cfssl, eg. cfssl, cfssljson会被安装到/export/go_path目录。
$ go get -u github.com/cloudflare/cfssl/cmd/cfssl
$ go get -u github.com/cloudflare/cfssl/cmd/cfssljson

初始化certificate authority
$ mkdir ~/cfssl
$ cd ~/cfssl
$ cfssl print-defaults config > ca-config.json
$ cfssl print-defaults csr > ca-csr.json

配置CA选项, ca-config.json文件内容如下
{
"signing": {
"default": {
"expiry": "43800h"
},
"profiles": {
"server": {
"expiry": "43800h",
"usages": [
"signing",
"key encipherment",
"server auth"
]
},
"client": {
"expiry": "43800h",
"usages": [
"signing",
"key encipherment",
"client auth"
]
},
"peer": {
"expiry": "43800h",
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
]
}
}
}

ca-csr.json Certificate Signing Request (CSR)文件内容如下
{
"CN": "My own CA",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "US",
"L": "CA",
"O": "My Company Name",
"ST": "San Francisco",
"OU": "Org Unit 1",
"OU": "Org Unit 2"
}
]

用已定义的选项生成CA:cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
2017/08/02 00:56:03 [INFO] generating a new CA key and certificate from CSR
2017/08/02 00:56:03 [INFO] generate received request
2017/08/02 00:56:03 [INFO] received CSR
2017/08/02 00:56:03 [INFO] generating key: rsa-2048
2017/08/02 00:56:04 [INFO] encoded CSR
2017/08/02 00:56:04 [INFO] signed certificate with serial number 81101109133309828380726760425799837279517519090

会在当前目录下生成如下文件

ca-key.pem
ca.csr
ca.pem

注:保存好ca-key.pem文件。

生成server端证书:
$ cfssl print-defaults csr > server.json

server.json内容如下:
{
"CN": "server",
"hosts": [
"127.0.0.1",
"192.168.16.227",
"192.168.16.228",
"192.168.16.229",
"bjo-ep-kub-01.dev.fwmrm.net",
"bjo-ep-kub-02.dev.fwmrm.net",
"bjo-ep-kub-03.dev.fwmrm.net"
],
"key": {
"algo": "ecdsa",
"size": 256
},
"names": [
{
"C": "US",
"L": "CA",
"ST": "San Francisco"
}
]
}
接下来生成server端证书以及private key
$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server server.json | cfssljson -bare server

$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server server.json | cfssljson -bare server
2017/08/02 00:57:12 [INFO] generate received request
2017/08/02 00:57:12 [INFO] received CSR
2017/08/02 00:57:12 [INFO] generating key: ecdsa-256
2017/08/02 00:57:12 [INFO] encoded CSR
2017/08/02 00:57:12 [INFO] signed certificate with serial number 138149747694684969550285630966539823697635905885

将会生成如下文件:
server-key.pem
server.csr
server.pem

生成peer certificate
$ cfssl print-defaults csr > member1.json

替换 CN和hosts值,如下:
{
"CN": "member1",
"hosts": [
"127.0.0.1",
"192.168.16.227",
"192.168.16.228",
"192.168.16.229",
"bjo-ep-kub-01.dev.fwmrm.net",
"bjo-ep-kub-02.dev.fwmrm.net",
"bjo-ep-kub-03.dev.fwmrm.net"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "US",
"ST": "CA",
"L": "San Francisco"
}
]

生成 member1 certificate与private key
$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=peer member1.json | cfssljson -bare member1

$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=peer member1.json | cfssljson -bare member1
2017/08/02 00:59:12 [INFO] generate received request
2017/08/02 00:59:12 [INFO] received CSR
2017/08/02 00:59:12 [INFO] generating key: rsa-2048
2017/08/02 00:59:13 [INFO] encoded CSR
2017/08/02 00:59:13 [INFO] signed certificate with serial number 222573666682951886940627822839805508037201209158

得到如下文件:
member1-key.pem
member1.csr
member1.pem

在集群其他节点上重复如上步骤。
生成 client certificate
$ cfssl print-defaults csr > client.json

client.json内容如下:
{
"CN": "client",
"hosts": [
"127.0.0.1",
"192.168.16.227",
"192.168.16.228",
"192.168.16.229"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "US",
"ST": "CA",
"L": "San Francisco"
}
]

生成client certificate
$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client client.json | cfssljson -bare client 

将会得到如下文件
client-key.pem
client.csr
client.pem

拷贝节点1生成的证书到全部节点,并将证书全部置于/etc/ssl/etcd/目录, 至此TLS证书全部生成完成。

测试TLS
示例1: 客户端到服务器采用HTTPS客户端证书授权
启动etcd服务:
$ /export/etcd/etcd -name infra0 --data-dir infra0 \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem --cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--advertise-client-urls=https://127.0.0.1:2379 --listen-client-urls=https://127.0.0.1:2379

插入数据:
$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/foo -XPUT -d value=bar -v

读取数据成功
$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/foo
{"action":"get","node":{"key":"/foo","value":"bar","modifiedIndex":12,"createdIndex":12

示例2:Using self-signed certificates both encrypts traffic and authenticates its connections.
各节点的etcd配置分别如下
$ /export/etcd/etcd \
--name infra0 \
--initial-advertise-peer-urls https://192.168.16.227:2380 \
--listen-peer-urls https://192.168.16.227:2380 \
--listen-client-urls https://192.168.16.227:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.227:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member1.pem --peer-key-file=/etc/ssl/etcd/member1-key.pem

$ /export/etcd/etcd \
--name infra1 \
--initial-advertise-peer-urls https://192.168.16.228:2380 \
--listen-peer-urls https://192.168.16.228:2380 \
--listen-client-urls https://192.168.16.228:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.228:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member2.pem --peer-key-file=/etc/ssl/etcd/member2-key.pem

$ /export/etcd/etcd \
--name infra2 \
--initial-advertise-peer-urls https://192.168.16.229:2380 \
--listen-peer-urls https://192.168.16.229:2380 \
--listen-client-urls https://192.168.16.229:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.229:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member3.pem --peer-key-file=/etc/ssl/etcd/member3-key.pem

准备测试数据:
$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/fristname -XPUT -d value=Xia -v

$ ETCDCTL_API=3 /export/etcd/etcdctl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.229:2379 put lasttname 'Zhang'

验证测试结果:
$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/
{"action":"get","node":{"dir":true,"nodes":[{"key":"/foo","value":"bar","modifiedIndex":19,"createdIndex":19},{"key":"/fristname","value":"Xia","modifiedIndex":20,"createdIndex":20},{"key":"/lasttname","value":"Zhang","modifiedIndex":21,"createdIndex":21}]

##etcd Troubleshooting
etcd failure主要分为如下5种情况:
  1. 少数followers failure
  2. Leader failure
  3. 多数failure
  4. Network partition
  5. 启动时失败
接下来主要对上面情况3进行处理,也就是平时常说的Disaster Recovery
##灾备恢复(Disaster Recovery)
以etcd v3 provides snapshot 方式为例说明etcd一次灾难恢复过程。
首先,etcd正常工作时利用etcdctl snapshot save命令或拷贝etcd目录中的member/snap/db文件,以前者为例:
$ ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshot.db}}
如果enable TLS,需要如下命令:
{{{$ ETCDCTL_API=3 /export/etcd/etcdctl --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.228:2379 snapshot save snapshot.db --cacert=/etc/ssl/etcd/ca.pem --cert=/etc/ssl/etcd/client.pem --key=/etc/ssl/etcd/client-key.pem

Snapshot saved at snapshot.db

将生成snapshot拷贝到集群其他2个节点上,所有节点灾备的恢复都用同一个snapshot。

插入部分数据用于测试灾备:
$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/fristname -XPUT -d value=Xia -v

$ ETCDCTL_API=3 /export/etcd/etcdctl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.229:2379 put lasttname 'Zhang'

测试数据已插入成功:
$ ETCDCTL_API=3 /export/etcd/etcdctl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.229:2379  get  firstname

$ curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/v2/keys/
{"action":"get","node":{"dir":true,"nodes":[{"key":"/foo","value":"bar","modifiedIndex":19,"createdIndex":19},{"key":"/fristname","value":"Xia","modifiedIndex":20,"createdIndex":20},{"key":"/lasttname","value":"Zhang","modifiedIndex":21,"createdIndex":21}]

停止3个机器的etcd服务,并删除全部节点上etcd数据目录 。
恢复数据,以TLS enable为例,分别在3个节点执行如下命令进行恢复:
$ ETCDCTL_API=3 /export/etcd/etcdctl snapshot restore snapshot.db \
--name infra0 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-token etcd-cluster-1 \
--initial-advertise-peer-urls https://192.168.16.227:2380 \
--cacert /etc/ssl/etcd/ca.pem \
--cert /etc/ssl/etcd/client.pem \
--key /etc/ssl/etcd/client-key.pem

$ ETCDCTL_API=3 /export/etcd/etcdctl snapshot restore snapshot.db \
--name infra1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-token etcd-cluster-1 \
--initial-advertise-peer-urls https://192.168.16.228:2380 \
--cacert /etc/ssl/etcd/ca.pem \
--cert /etc/ssl/etcd/client.pem \
--key /etc/ssl/etcd/client-key.pem

$ ETCDCTL_API=3 /export/etcd/etcdctl snapshot restore snapshot.db \
--name infra2 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-token etcd-cluster-1 \
--initial-advertise-peer-urls https://192.168.16.229:2380 \
--cacert /etc/ssl/etcd/ca.pem \
--cert /etc/ssl/etcd/client.pem \
--key /etc/ssl/etcd/client-key.pem

恢复数据log示例:
$ ETCDCTL_API=3 /export/etcd/etcdctl snapshot restore snapshot.db   --name infra0   --initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380   --initial-cluster-token etcd-cluster-1   --initial-advertise-peer-urls https://192.168.16.227:2380   --cacert /etc/ssl/etcd/ca.pem   --cert /etc/ssl/etcd/client.pem   --key /etc/ssl/etcd/client-key.pem
2017-08-06 04:09:12.853510 I | etcdserver/membership: added member 3e5097be4ea17ebe [https://192.168.16.229:2380] to cluster cabc8098aa3afc98
2017-08-06 04:09:12.853567 I | etcdserver/membership: added member 67d47e92a1704b1a [https://192.168.16.227:2380] to cluster cabc8098aa3afc98
2017-08-06 04:09:12.853583 I | etcdserver/membership: added member b4725a5341abf1a0 [https://192.168.16.228:2380] to cluster cabc8098aa3afc98

接下来,在3个节点上分别执行:
$ /export/etcd/etcd \
--name infra0 \
--initial-advertise-peer-urls https://192.168.16.227:2380 \
--listen-peer-urls https://192.168.16.227:2380 \
--listen-client-urls https://192.168.16.227:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.227:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member1.pem --peer-key-file=/etc/ssl/etcd/member1-key.pem

$ /export/etcd/etcd \
--name infra1 \
--initial-advertise-peer-urls https://192.168.16.228:2380 \
--listen-peer-urls https://192.168.16.228:2380 \
--listen-client-urls https://192.168.16.228:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.228:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member2.pem --peer-key-file=/etc/ssl/etcd/member2-key.pem

$ /export/etcd/etcd \
--name infra2 \
--initial-advertise-peer-urls https://192.168.16.229:2380 \
--listen-peer-urls https://192.168.16.229:2380 \
--listen-client-urls https://192.168.16.229:2379,https://127.0.0.1:2379 \
--advertise-client-urls https://192.168.16.229:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster infra0=https://192.168.16.227:2380,infra1=https://192.168.16.228:2380,infra2=https://192.168.16.229:2380 \
--initial-cluster-state new \
--client-cert-auth --trusted-ca-file=/etc/ssl/etcd/ca.pem \
--cert-file=/etc/ssl/etcd/server.pem --key-file=/etc/ssl/etcd/server-key.pem \
--peer-client-cert-auth --peer-trusted-ca-file=/etc/ssl/etcd/ca.pem \
--peer-cert-file=/etc/ssl/etcd/member3.pem --peer-key-file=/etc/ssl/etcd/member3-key.pem

验证灾备恢复效果,原集群数据是否保存:
$ ETCDCTL_API=3 /export/etcd/etcdctl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.229:2379 get lasttname
lasttname
Zhang

$ ETCDCTL_API=3 /export/etcd/etcdctl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem --endpoints=https://192.168.16.227:2379,https://192.168.16.228:2379,https://192.168.16.229:2379 get firstname
firstname
Xia

从上面结果可以看出,灾备恢复成功。
##etcd系统限制
  1. 请求大小限制:当前支持 RPC requests 1MB 数据,未来会有所增加或可配置
  2. 存储大小限制:默认 2GB存储,可配置 --quota-backend-bytes扩展到8GB

##监控
etcd提供基于Prometheus + builtin Grafana的etcd Metrics监控方案和监控项,具体请参见
etcd Metrics: https://coreos.com/etcd/docs/latest/metrics.html

获取监控项举例
$  curl --cacert /etc/ssl/etcd/ca.pem --cert /etc/ssl/etcd/client.pem --key /etc/ssl/etcd/client-key.pem -L https://127.0.0.1:2379/metrics

etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="1"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="2"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="4"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="8"} 0

... ...

process_start_time_seconds 1.50390583624e+09
process_virtual_memory_bytes 1.0787151872e+10

Prometheus + builtin Grafana: https://coreos.com/etcd/docs/latest/op-guide/monitoring.html

欢迎转载,请注明作者出处:张夏,FreeWheel Lead Engineer,DockOne社区


为什么CoreOS携手开源?

xiao_ye2000 发表了文章 • 0 个评论 • 2728 次浏览 • 2017-07-03 13:36 • 来自相关话题

【编者的话】本文通过日常研发中遇到的问题,提出引入开源项目的重要性,介绍了CoreOS协助创立的CNCF以及它赞助的一些项目,同时也介绍了Kubernetes社区的一些现状和未来发展的展望。 【3 天烧脑式容器存储网络训练营 | 深圳 ...查看全部
【编者的话】本文通过日常研发中遇到的问题,提出引入开源项目的重要性,介绍了CoreOS协助创立的CNCF以及它赞助的一些项目,同时也介绍了Kubernetes社区的一些现状和未来发展的展望。

【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。

CoreOS构建开源软件。为什么携手开源软件呢?因为要解决的问题规模巨大,在宏观的层面需要革新。预计:

* 今时今日有3,646,000,000的因特网用户;
* 29,000,000的软件开发者和IT从业者;
* 去年新增了238,975,082的因特网用户;
* 全球大概有100,000,000左右的服务器。

显然我们作为软件工程师和管理员是忙不过来的。开源软件是使这一扩展成为财富的关键,大家在各种环境中合作处理最难的操作问题,例如管理安全性、可靠性以及可移植性。

大概三年半前,我们开始一起用工具套件解决分布式系统中解锁计算可移植层。随着Container Linux、Docker、Kubernetes等的引入,基于软件容器的生态系统开始形成。
coreos.png

#构建Container Linux
CoreOS Container Linux,为容器世界创造的开源操作系统,大概四年前开始研发,设计理念是容器把Linux推向了一个全新的道路,需要对安全、性能以及宽平台多方面支持的全新版本。因此我们构建了一个有快速发布Linux内核特性的OS,尤其是在容器化优化方面。

Container Linux现在被广泛的采用运行于各种云平台以及裸金属平台上。
#CoreOS创建CNCF中的开源项目:rkt和CNI
至此,我们已经协助建立了CNCF(the Cloud Native Computing Foundation)并且捐助了包含rktCNI等一些关键容器技术。这些开源项目由CoreOS工程师发起并且在容器生态系统中的成功提供了一定的帮助。

最新的rkt发布版本自从被加入到CNCF以来,第一次对于帮助促进这次发布的社区成员表示了极大的感谢。本次发布新加入了很多贡献者,同时也提出了基于Xen stage1的建议。

CNI是容器中的网络系统插件,它使得类似Kubernetes之类的管理平台更容易的支持IPAM、SDN或者其它网络方案。CoreOS几年前创造了CNI,以实现跨容器的解决方案和计算环境之间简单网络的可互相操作性。CNI有着一个蓬勃发展的第三方网络解决方案社区,用户可以从那里选择网络插件加入到Kubernetes容器架构中去。我们很高兴看到这些广泛采用的系统加入到CNCF中。
#对于Prometheus监控引擎的贡献
监控架构软件和系统对于创建一个可靠的生产环境至关重要,Promethus事实上是Kubernetes生态系统的监控系统。鉴于其重要性,CoreOS在这个项目上投入了一定的人力并且把项目往可扩展性方向做出了很有意义的推进。社区对于可扩展性的关注是即将推出的Prometheus 2.0版本的前沿和中心,这个版本提供了时序存储层上的很大提升,旨在解决当前工作负载的瞬态性。
#Celebrating Clair 2.0
Clair是CoreOS建立的一个安全项目,完成容器镜像的静态分析并将它的内容和公共漏洞数据库相关联。Quay安全扫描的核心就是Clair,但是它也支持其它许多需要容器镜像扫描的项目。

今天我们庆祝Clair 2.0的发布,包含Alpine Linux扫描等附加功能。这是个重要的里程碑的发布,感谢参与的43的贡献者。
#联盟的Kubernetes状态
我们致力于创建一个强有力的Kubernetes开发社区,有着与之匹配的客户和合作伙伴的更广泛的社区。去年Kubernetes社区已经达成了几个重要的里程碑,包括几个稳定版本,一群增长中的贡献者,另外Kubernetes指导委员会的启动也帮助组织项目在未来几年进一步发展。
##项目治理和发布
Kubernetes处理问题的空间是巨大的!Kubernetes社区发展快速的原因是由于社区组织的能力组织成了一个个的小团队,称为特别兴趣组)。这些组织可以从横向跨项目的问题,如集群安装或认证/授权到更多的纵向问题,如Azure集成。然而当需要对创建新的资源库、划分新的发布版本包括新的API或者删除未进过测试的代码等操作跨SIG决定的时候,谁做出最后的确定就很不清晰。

几个月前,Kubernetes社区创立了一个管理引导委员会在如何处理这类问题上做出建议。最近引导委员会发布了一系列重要的建议和文档包括成立Kubernetes指导委员会全职解决项目组织问题。计划八月初建立Kubernetes指导委员会。
##未来的展望
最后,让我们期待接下来几个Kubernetes发布版本里的一些特性和能力。我从LWN的Jon Corbet对常规Linux内核的预测获得启发。然后我的工作比Jon的更容易,Kubernetes社区开发了一个相对中心化的特性以及设计计划系统,因此对于这些预测,我有很高的信心相信它们都会成真。

核心部署API正在转向稳定:这很容易预测,因为Kubernetes社区的很多人都致力于将它实现。Kubernetes社区正在快速地把重要的API添加到项目中,例如通过DaemonSets支持长时间运行的节点服务、通过StatefulSets支持静态状态应用以及通过Deployments支持滚动升级等工作负载。这些API已经被用户的很多发布版本证明且已经做好了转成稳定版本的准备。

一致性和自动集群配置:Kubernetes有很多动态的部分,从API server和Scheduler到kubelet和kube-proxy。这些每个组件都需要获取密文和可调参数。现在这些都是通过命令行参数实现;但是管理这些组件非常困难,需要重启才能更新,而且对于版本更新来说是不大可能的。目前正在研发通过配置文件映射到称为组件配置的API对象,使配置更加一致,更容易自动化。

通过TPRs扩展和API的聚合:对于创建集群应用的人们来说,Kubernetes的API已经成为了一个很便捷的系统。这是因为这些API有着友好的命令行工具,基于角色的接入控制并且可以插入很多用户认证系统。因此,人们创建了许多应用并将资源保存到Kubernetes中,这些资源称为第三方资源,另外还有个新的API聚合子系统用来启动API,可以在server端验证,和Kubernetes API版本集成,并且后台可以是不同的数据存储。

应用在Kubernetes API之上编译:基于Kubernetes API的扩展能力,已经出现了虚火基于该API的应用。这包含从数据库、认证鉴权以及用户应用特定工作流的许多应用。这些应用的管理员将可以利用Kubernetes提供的所有功能包括日志、调试和监控工具等。

更多的用Metrics API监控驱动API:并不是只有外部应用才被Kubernetes中新的API聚合启动。SIG Instrumentation现在正在创立一个metrics API服务器,可以随着现如今用户创建的越来越大规模的集群而扩展。这也使得Kubernetes内部更多的监控驱动决定系统变得可能:基于用户的指标自用扩缩,更好的首选管理工具就更容易插入到例如Prometheus等时序数据库中。
#朝着光明的未来迈进
非常感谢所有人和我们在许多开源容器生态环境中关键项目中一起工作并取得成功。我们鼓励你们加入到开源和分布式系统的旅程中。或者,跟我们合作吧!CoreOS正在招聘

原文链接:Why CoreOS Builds with Open Source(翻译:李桦)

CoreOS容器编排之路:从Fleet到Kubernetes的转变

chilly_2016 发表了文章 • 0 个评论 • 3460 次浏览 • 2017-04-23 18:22 • 来自相关话题

【编者的话】近两年分布式应用的组织和管理水平大幅提升。CoreOS集群管理始于fleet,fleet是2014年发布的一个简易的分布式服务管理框架。而社区上Kubernetes被广泛应用,并逐渐成为了开源容器框架的事实标准。基于技术应用和市场占有等原因,Kub ...查看全部
【编者的话】近两年分布式应用的组织和管理水平大幅提升。CoreOS集群管理始于fleet,fleet是2014年发布的一个简易的分布式服务管理框架。而社区上Kubernetes被广泛应用,并逐渐成为了开源容器框架的事实标准。基于技术应用和市场占有等原因,Kubernetes成为大规模容器架构集群最优秀的自动化编排工具,CoreOS也因此而改变技术选型。本文讲述了CoreOS公司集群编排框架的前世今生,描述了从fleet到Kubernetes的转变。

【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述、架构、日志和监控,部署、自动驾驶、服务发现、网络方案等核心机制分析,进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。

目前,CoreOS计划于2018年2月1日从Linux的容器平台上替换fleet技术,对fleet的支持也即将截止。fleet进入了维护期,仅负责安全及补丁修复的升级。此项变动代表着集群编排和管理技术将转移到Kubernetes技术上。此转变也简化了用户自动更新容器Linux最小集操作系统的发布和部署操作。

新集群部署将提供以下支持:


2018年2月1日以后,fleet的容器镜像在CoreOS的软件注册仓库中仍存在,但不作为Linux的容器操作系统集装打包。

若已购买Linux容器服务的fleet的用户,可在服务终止前从原有渠道获得迁移服务。并获取相关文档。

在此期间,可继续通过CoreOS的邮件列表服务解答fleet用户的问题。为了让大家更加顺利的开始,计划2月14日早上10点邀请CoreOS CTO Brandon Philips,举办一场fleet迁移到Kubernetes的在线技术研讨会。方便大家在线交流。
#fleet:集群化之路的第一步
公司创始之初,CoreOS就致力于研究操作系统的集群编排技术,目前以CoreOS Linux容器操作系统最为流行,也是首家提供云环境自动部署和调度集群资源的容器软件。最初该软件是通过fleet实现开源集群调度框架,实现集群设备的系统初始化。

采用fleet不到一年,Google公布了开源Kubernetes项目。令人振奋是他推动了CoreOS Linux容器操作系统fleet的etcd分布式键值后台存储技术的发展,更重要的是Kubernetes提供了fleet未提供的今后发展方向和解决方案。

Kubernetes设计了一套稳定可扩展的API接口、预置服务发现、容器网络、及扩展的关键特性。此外,该技术还在Google Borg,Omega,and SRE团队有多年的运营经验。
#Kubernetes and Tectonic:如何编排容器
基于以上原因,在Kubernetes 1.0之前,CoreOS转而将Kubernetes作为容器编排设计的主要特性,将开发资源投入到Kubernetes的相关基础功能和社区支持中去。CoreOS是Cloud Native Computing Foundation(CNCF)的主要成员之一,谷歌将Kubernetes版权捐赠给CNCF产业联盟,这也促使Kubernetes真正成为全行业努力发展的软件成果。

CoreOS的开发团队主导了Kubernetes版本周期管理,Special Interest Groups(SIGs)曾用了2年时间简化Kubernetes部署、管理和升级,便于生产环境可用。 CoreOS flannel SDN 成为热门的Kubernetes网络管理机制。因为CoreOS开发的Kubernetes网络接口模型作为容器网络接口(CNI)已被大量容器化系统应用。团队致力于设计和应用Kubernetes基于角色的访问控制(RBAC)的技术,使得开源身份认证解决方案dex的团队补充了认证提供商和类似LDAP的企业级解决方案。当然,etcd原本作为fleet的后台数据存储,代表了早期的努力,也将继续沿用到Kubernetes的时代中。

fleet探索了集群自动化管理的愿景,CEO Alex Polvi 认为Kubernetes帮助CoreOS达到最终目标。感谢过去社区对fleet的反馈和支持,公司已将多年积累的经验和思路应用到Kubernetes和Tectonic的集群容器编排上。
##在CoreOS Tectonic上开始使用Kubernetes
Tectonic提供一种最简易的构建新集群方式。在应用开源Kubernetes的基础上,它提供了集群编排软件的简单安装和自动升级服务。对于10个节点以内规模的集群的设备提供免费测试应用lisence,并支持AWS和裸机部署两种环境。
##minikube是Kubernetes的简易先导
若是个使用容器编排的新手,minikube工具可帮助用户在本地快捷的运行Kubernetes,也是一个可安装在笔记本或本地电脑上的Kubernetes先导帮助工具。
##让Kubernetes开启CoreOS的容器Linux之旅
为了深入研究Kubernetes的技术细节,可参考部署帮助手册。帮助文档提供了Kubernetes相关概念的解释说明,以及一些超出Tectonic两类初始环境外的平台部署技术。
#为fleet容器提供集群继续提供维护支持
在2018年2月fleet将从容器的Alpha版本上删除,随后将从Beta和稳定版本上删除,而此后版本可通过运行容器环境继续使用fleet。有一个简单封装的脚本可帮助客户获取fleet应用容器软件及安装说明。

管理员们可通过调试“fleet迁移配置示例”实现容器化fleet应用部署的迁移。设备提供商可在fleet节点上部署封装配置以激活服务。
#下一步:从fleet迁移到Kubernetes
可加入CoreOS的 Container Linux 邮件列表或IRC以获得反馈或技术支持。也可在2月14日的现场技术研讨会获得更多信息。最终,建议参加Coreos 的Kubernetes的专家面授培训,帮助开始Kubernetes的正式使用。

原文链接:Container orchestration: Moving from fleet to Kubernetes(翻译:Chilly)

CoreOS和Docker分别要将rkt和containerd捐赠给CNCF

kurtzhong 发表了文章 • 0 个评论 • 3481 次浏览 • 2017-03-17 22:10 • 来自相关话题

今天(3月15日)CoreOS和Docker联合提议将rkt和containerd作为新项目纳入CNCF(云原生计算基金会)。在今天CNCF的技术监管协会(Technical Oversight Commitee,或TOC)会议上,Jonathan Boull ...查看全部
今天(3月15日)CoreOS和Docker联合提议将rkt和containerd作为新项目纳入CNCF(云原生计算基金会)。在今天CNCF的技术监管协会(Technical Oversight Commitee,或TOC)会议上,Jonathan Boulle,一名rkt的项目领导人兼共同发起人,提议了rkt;Michael Crosby,一名containerd项目领导人兼共同发起人,提议了contanerd。这些提议是让这些项目和其他关键项目共同发展的第一步,这些项目包括gRPC、Kubernetes、Prometheus和很多其他项目。通过将这些项目捐献给CNCF,我们保证容器社区继续在一个中立的归属下齐心协力。

【上海站|3天烧脑式微服务架构训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。

容器执行是云原生的一个至关重要的支柱,并且我们相信rkt将会持续在CNCF社区的帮助下进步并壮大。rkt有180多名来自多元化的背景的贡献者,已经帮助建立并且推进很多关于容器安全,组合性和协作性的对话。现在,行业中已经有一部分致力于容器安全,而像CNCF这样的机构能促进对话,并最终让更多的公司吸收、推动并受益于云原生基础设施。

我们期待在接下来的数天和数周里,和rkt和CNCF社区一起完成接下来的步骤。如果你有兴趣了解最新进展,可以订阅这个邮件列表
# rkt为什么加入CNCF
云原生计算的一个支柱是将应用打包成容器镜像,然后把这些镜像分发到服务器。在服务器上,容器引擎会下载镜像,验证镜像的完整性,然后执行容器进程。理想的状态是,容器引擎使用最简单的方式来实现这个过程,同事满足生产环境中云原生用户的需求。rkt工具就像一束激光,集中于解决这些问题,其成果已经受到了市场的欢迎,并促进了它和一些云原生编排系统如Kubernetes、Mesos、Nomad和很多机构的内部定制系统集成。

自从它被CoreOS在2014年12月发布以来,rkt项目已经高度成熟并被广泛使用。在绝大多数的主流Linux发行版中都能找到,并且每一个rkt的发布版都会构建用户可以直接安装的自包含rpm/deb安装包。这些软件包也能在Kubernetes仓库中找到,作为该仓库的一部分,便于测试rkt和Kubernetes的集成。同时,在Google Container ImageCoreOS Container Linux运行Kubernetes中,rkt也扮演了中心的作用。

同时,rkt项目也间接推进了容器生态系统中很多新的重要API,规范和讨论。CNI,被Mesos、Kubernetes、rkt和其他项目使用的容器网络插件系统,就直接来源于最初的rkt插件系统并且已经汇聚了来自多家机构和整个行业的努力。rkt的团队也创建了appc,即App Container Spec,发起了一场行业内的关于容器标准的讨论,并且最终产生了OCI,即Open Container Initiative。正在进行的将Kubernetes打造成一个支持多容器运行时的系统起源于早期在"rktnetes"方面的工作,其已经促使了Container Runtime Interface API在Kubernetes内诞生。在所有的这些场景中,rkt项目都扮演共享生态环境中协作的催化剂。

总得说来,容器执行是云原生的一个核心部分。通过将rkt放到CNCF下的提议,我们能得到如下的益处:

  • 为项目找到一个中立的、受尊敬的归属
  • 伴随来自社区的努力和投入,能得到更多的帮助
  • 加速和Kubernetes、OCI和containerd的合作

# rkt现状和未来
感谢社区让rkt走到今天这一步。很多公司,如BlaBlaCar,一家欧洲有名的汽车共享服务商,他们正在生产环境中使用rkt并且正向Kubernetes迁移,并分享了他们在生产坏境中使用rkt的经验。社区中的其他成员也说:
01.png

来自@coreoslinux的rkt是真正值得关注的东西,https://t.co/UYeOVX0CUz

02.png

不得不说,CoreOS的rkt有着很好的设计

请继续使用rkt并且提出反馈,分享你们使用rkt的故事。你可以在我们的rkt的usersintegration文档页面添加你的pull request。
## FAQ
Q:今天这意味着什么?

现在rkt和containerd的提议已经提交后,下一步是等待CNCF TOC成员来支持并提议项目的加入。到了这一步后,项目会向上推进,进入一个正式的提议阶段,然后继续往上在接下来几周里接受投票。



而对于专门负责rkt的项目组来说,并没有什么大的不同。所有rkt的其他maintainer会一如往常的继续项目上的工作。同时,我们希望在CNCF的帮助下,能催生新的用户和维护者,一起推动并且依赖rkt。



Q:containerd和rkt的不同之处是什么?

rkt能下载、验证并且配置好容器镜像;而containerd也能完成同样的事情。同时,两个项目都支持OCI镜像和Docker镜像。



一个主要的不同之处是,rkt作为一个无守护进程的工具(daemonless tool),可以用来在生产环境中,集成和执行那些特别的有关键用途的容器。举个例子,CoreOS Container Linux使用rkt来以一个容器镜像的方式执行Kubernetes的agent,即kublet。更多的例子包括在Kubernetes生态环境中,使用rkt来用一种容器化的方式挂载volume。这也意味着rkt能被集成进并和Linux的init系统一起使用,因为rkt自己并不是一个init系统。



Q:对于构建容器的开发者来说意味着什么?


对于需要构建容器的开发者来说,一切照常,因为containerd和rkt的目标都是要让用户能够执行他们已有的OCI镜像和Docker镜像。



对于在生产环境中部署容器的基础设施专家群体来说,这意味着rkt团队和项目会以CNCF的一部分,在一个中立的机构下,继续它的使命,即创建一个简单、可组合、生产环境可用的容器化系统。



我们同时也迫切想看到在rkt项目中和其他CNCF生态环境项目,如Kubernetes,gRPC和Prometheus的协作。



Q:所有的这些容器引擎都可以通过Kubernetes CRI使用吗?

CoreOS帮助建立了一个标准的接口,叫做Kubernetes Runtime Interface(Kubernetes运行时接口,CRI),能让Kubernetes使用一些可插拔的容器运行时引擎。rkt已经可以通过CRI使用(一个调用实例请参考minikube项目的使用说明)。




原文链接:CoreOS's rkt and Docker's containerd jointly donated to CNCF(翻译:钟最龙)