江湖路远,Kubernetes 版图扩张全记录

中文社区阅读(87)评论(0)

今天的这个故事出自“江湖”,一半关于各路豪杰的江湖纷争、聚合反目;另一半关于 Kubernetes 从初出茅庐到异军突起走过的蜕变之路。

“ 如果有一个 workload 到了亚马逊那儿,你们就完了!” 2013 年,VMware 公司首席执行官 Pat Gelsinger 在公司的合作伙伴交流大会(Partner Exchange Conference)如是说。“现在到永远,我们都要拥有公司的 workload”。作为前英特尔资深经理, Gelsinger 的这些话对云计算五年前的情景作了很好的还原:彼时,VMware 还认为自己是宇宙的中心,并试图捍卫和巩固自己的地位。亚马逊正努力将数据中心迁移到自己的公有云领域。

那时的 Gelsinger 肯定没想到,四年后,他确实再也不用担心失去公司的 workload 了。一场让他意想不到的“江湖纷争”即将袭来,他要对付的可不仅仅是老对手 Amazon 了。

重新洗牌

VMware 一统江湖

“VMware” 中的 “VM” 代表虚拟机,它成为了组织在云平台上部署应用程序的第一个工具。虚拟机的出现引发了大众对“可移植性” (即在任何地方都能部署应用程序)的渴望。但是 VMware 聪明地通过部署和管理虚拟机的方式来保护自己的利益,使得 vSphere 成为所有入站道路的必须监督者。

理想的践行者 Docker

然后,Docker 出现了。它是第一个将“可移植性”赋予数据中心的工具。2013 年,Docker 开发了一个容器机制,将 workload 从笨重的操作系统中解救出来,来维护虚拟机。这样,他们就可以使用 Linux kernel 而不是虚拟机监视器来进行管理。这是当时众多组织触不可及的 “革命理想”,但只有 Docker 践行并实现了。

从出现伊始, Docker 就遭遇了来自企业的质疑目光。同时出现的还有一个广为流传的论断:一个新的市场即将围绕着 Docker 容器形成。套用 PC 世界的旧模板,软件市场当时也是围绕格式和兼容性形成的。推断下去,接下来将出现各大容器公司相互竞争的局面,然后是优胜劣汰,紧接着 Docker 或者其他更强大的竞争对手,会从对手的灰烬中取得最终胜利。

只有当“可移植性”无处不在时,才实现了真正的可移植。2015 年,Docker 放大胆子赌了一把,将整个容器 format 捐赠给了 Linux 基金会赞助的一个开源项目。这个项目现在被称为 Open Container Initiative(OCI)。彼时的 Docker 计划先行一步,放弃人人想要的“可移植性”,让容器 format 增值。Docker 捐赠了容器 format,让竞争对手再也找不到与之竞争的明确方向,Docker 笃定它的未来就在部署和维护容器 workload 的机制上。

Kubernetes 初出茅庐

就在同年,谷歌推动建立了一个独立基金会:Cloud Native Computing Foundation (CNCF)。 CNCF 与 OCI 有很多相同的成员,但 CNCF 专注于容器 workload 的成员们,试图在“部署和管理”方面寻找竞争优势。紧接着,CNCF 就推出了 Kubernetes,这个编排工具将谷歌工作workload staging 概念与 Docker 容器相结合(最初名为“Borg”)。

Red Hat 公司围绕 Kubernetes 重建了 OpenShift PaaS 平台,而 CoreOS 将其业务重点转向 Tectonic,即 Kubernetes 的商业实施。

Kubernetes 的野蛮生长

就像推倒了一块多米诺骨牌,容器领域的众多利益相关者在 2017 年一个接一个地将部署和管理战略倒向了 Kubernetes,包括 Docker 公司本身 :

  • 4 月,托管的 OpenStack 云管理服务提供商 Mirantis,宣布将 Kubernetes 集成到其云平台 1.0 中,并承诺将其 Staging 和配置机制的重点从以安装人员为中心模式,转向以 workload 为中心模式。
    同月,微软收购了基于 Kubernetes 的容器部署平台制造商 Deis,以前所未有的姿态向 Azure 开放平台迁移。紧接着 Deis 技术在 Azure 上出现。 ( 2016 年 6 月微软就已经从 Google 挖走了 Kubernetes 的创始人 Brendan Burns。)
  • 5 月,在波士顿举行的 OpenStack 峰会上,OpenStack 许多社区领导齐聚一堂,承认 Kubernetes 是其私有云模型中,容器 workload 的事实 staging 环境。当时还有一个亟待解决的问题:Kubernetes 或 OpenStack 究竟应该留在虚拟基础架构的最底层,还是应该针对每个客户的情况合理地解决这个问题?
    几乎在同时,IBM 推出了 Kubernetes 支持的云容器服务,向客户提供了一种无缝、即刻启动 Docker 容器的方法。
  • 6 月初,Oracle 在开源会议上承认 Kubernetes 是其新容器 Staging 策略的核心。作为 Docker 的竞争对手,CoreOS 自从平台成立以来就被称为 “Tectonic 的商用 Kubernetes 环境的生产者”。 CoreOS 把最小的 Linux kernel 贡献给 Oracle,Oracle 把自己的 Linux 踢到了一边。
  • 6 月末,在 Cloud Foundry 峰会上,Cloud Foundry 基金会发布了 Kubo,这是一种在传统机器内部 staging Kubernetes 的多个负载均衡实例的工具。这为 8 月份的VMware 和姊妹公司 Pivotal 与 Google 建立合作关系打下基础,并推出 Pivotal Container Service(PKS)。这个消息发布于 Amazon 与 VMware 建立合作伙伴关系一天后,当时 Kubo 已经为 Google 云平台定制进行了商业实施。值得注意的是,在整个 PKS 首次发布会期间,“Docker” 这个词一次也没被提过。(10 月份,Kubo 项目更名为 Cloud Foundry Container Runtime。)
  • 8 月初,亚马逊终于下了“赌注”,加入了 CNCF,并承诺做出实质性贡献。
  • 9 月中旬, Oracle 也正式加入了 CNCF。
  • 9 月中旬,Mesosphere 做出了一个相当惊人的举动,在 beta 版本中,加入了一种整合这两个平台的方法。其用户可以安装、扩展和升级多个生产级 Kubernetes 集群。
  • 10 月中旬,这场容器竞争战似乎发出了即将结束的信号。Docker 宣布拥抱 Kubernetes,Docker 的创始人 Solomon Hykes 在大会上宣布:下一个版本的 Docker 将支持两种编排平台—— Swarm 和 Kubernetes!
  • 10 月下旬,微软推出了一个专门 Azure 容器服务(AKS)预览版,这一次 Kubernetes 不仅站在了“舞台” 中央上,而且 “K” 还是最中间的字母。不久之后,该公司的市场营销和网站给出了它的 Kubernetes 平台的第一个版本,推出了基于 DC / OS 的容器 Staging 平台作为备选方案。
    在同一个月,思科在基于 ACI 的数据中心架构和谷歌云之间,通过 Kubernetes 宣布了一个名为 Goodzilla 的 Bridge。
  • 11 月底,亚马逊正式推出了自己的 AKS 容器服务,并把 AWS 云与 Google 和 Azure 相提并论。

此消彼长

从市场角度来看,所有这些发展都表明:谷歌已经成功地控制了所有通向数据中心容器化道路。众所周知,没有可移植性的容器是毫无意义的,对于数据中心的客户们来说,一个 Staging 和编排环境是远远不够的。

微软第一个证明,通过开源核心优势来迅速占领市场是个可行的办法。当年,它让 Internet Explorer 变得免费,逼得 Netscape 只能通过增加大量不必要的新功能慌张回击,最终还是落得失败下场。Docker 显然也知道这个道理,开源了容器 format,让同类产品不能与之争锋。

然而,Docker 还是没有如当日所愿,建立自己的增值路线——就是那个可以通过开源手段来占领市场的“大杀器”。有人可能觉得,Docker 的基于集群的编排平台 Swarm 还不“成熟”。可是 Kubernetes 在向 Docker 发起进攻的时候可能更“幼稚”,但它有自己的“杀手锏”:相关的容器可以分组到 pod 中。

Red Hat 第一个出来,利用 OpenShift 来展示这一“杀手锏”, 这使得众多开源贡献者都对 Kubernetes 魂牵梦绕。在 Docker 移动创建 OCI 之后, Google 几乎马上就允许 Linux 基金会建立 CNCF,他们的成员几乎是同一拨人,这确保 OCI 部分的设计不会让 CNCF 感到意外,同时也保证了 Kubernetes 在社区讨论桌上的好位置。

Kubernetes 正在进行时

以下是 Kubernetes 正在进行时,在 2018 年肯定会让 Kubernetes 受益:

  • CSI 项目:这个项目最近得到了戴尔技术公司(戴尔 EMC 的母公司)的支持,这个项目承诺,将通过与数据库和 Storage Volume 保持持久链接,提供微服务 。使用 CSI 接口,任何打开这种持久链接的 API 都可以通过三个主要容器编排平台:Kubernetes,Mesos(DC / OS)和 Swarm 进行同样寻址。它目前由 Moby 管理,而 Moby 却是由 Docker 原始的开放源代码产生的,但现在 Moby 有一个独立的方向。这对于 Kubernetes 而言非常有利,开源数据 Plugins 的主题再也不是 Docker 领地中的本地特性了。
  • CRI-O 项目:它利用 Kubernetes 的原生 Container Runtime Interface (CRI),使容器编排平台能够通过本地 API(一个称为“runtime”的可寻址组件)实例化一个容器。目前在许多数据中心,生产环境把 Docker Engine 作为 Orchestrator 和 Runtime 之间的中介; CRI-O 专门为 Kubernetes 提供让 Docker 完全隔离在生产环境的方法,让它只能出现在开发人员的工作台上。
  • Kata 项目:Kata 与 Docker 的竞争对手 Hyper 一同加入英特尔的 Clear Containers 项目中。Kata 可以为数据中心提供构建和部署 workload 的方法,Docker 将会完全被淘汰,同时还能够在基于容器的 workload 和第一代虚拟机之间共存。OpenStack 基金支持这个项目,它将利用 Kubernetes 作为其主要容器编排平台。

然而即便迎来了如此全胜局面,Kubernetes 仍然面临着巨大的挑战。具体来说,Kubernetes 可能变得如此无处不在,如此标准化,以至于任何供应商或开源贡献者都难以围绕它再创造竞争优势了。

路漫漫其修远兮

对于数据中心来说,Kubernetes 的突然出现意味着:过去基于公有云的 PaaS 平台,如 Heroku 和原来的 Windows Azure,只有使用它支持的资源和语言才可用。而现在,只要使用 Kubernetes,每个人的平台都支持容器内部,而不是外部。这有助于在一定程度上平衡服务提供商,因为他们现在都可以提供相同的界面来获取和托管客户的 workload。这也缩小了这些提供者在服务上彼此竞争的空间。规律如此,每当市场商品化,幸存者都是那些赢得价格战的人。

Kubernetes 可能已经在 2017 年完全超过了 Docker。但是市场瞬息万变,谁又能保证在 2018 年 Google 或其他任何人不会超过它呢,江湖路远,让我们拭目以待!

看后Kubernetes时代 – 容器生态2017

中文社区阅读(1369)评论(1)

如果说2017年的容器技术圈子只能用一个关键词来概括的话,那一定非“Kubernetes”莫属。

从2017年2月,“Kubernetes”开始频繁登上各大技术媒体头条,来自不同维度不同渠道的商业分析和技术文章也纷至沓来。有趣的是,无论是官方报道还是个人评述,无论是直接还是委婉,无一不在透露着一个同样的信息:“Kubernetes要赢!”

可是,描述这样一个连商业实体都没有的开源项目“要赢”,总是听起来有些奇怪。

“要赢谁?”

“为什么要赢?”

“赢了之后呢?”

我们不妨就从这个论断说起吧。

Kubernetes赢在何处

如果说错失了Big Data时代的Google实在令人扼腕,那么Container时代的Google终于靠开源社区打了个翻身仗。虽然在最初的lmctfy项目(Google自研容器)上依然栽了跟头,虽然同Docker公司共举容器编排大业的计划依然吃了闭门羹。但Google还是笑到了最后。

不过,Kubernetes项目的发展绝非一帆风顺。它的前期只有一篇不温不火的B类会议文章Borg来站台,远没有“三大paper”一举奠定大数据基石那么耀眼。而在它发布的之后,炙手可热Docker公司却始终拒绝同Google开展任何形式的合作。而与此同时,Mesos等一票老牌调度系统的阴影则从一开始就让Kubernetes团队心有芥蒂。种种不利因素,再加上当时Google在Kubernetes上投入资源时的捉肘见襟,无论再怎么乐观,这个“要赢”的论断恐怕都不容易成为现实,

当然,如果不是Google找到了一个靠谱的盟友的话。

这位盟友有多靠谱?它是这个世界上唯一一家年盈利超10亿美元的开源技术公司。

Kubernetes刚发起的时候,其核心的理念来自几位“Elder(元老)”的构想,他们大多是Borg和Omega项目的开发者或者架构师,一直专注于如何在没有cloud的场景下构建足够规模的通用Infrastructure Layer的实践,并且在这个领域摸索的过程中,这批技术人员也逐渐形成了一套创新性的设计理念,这些观点在Borg论文中曾经透露出了一些端倪,但真正全面揭晓还是依托于Kubernetes开源项目。所以如果大家回头去翻Kubernetes最早的一些Issue和Design,其实都是一篇篇“小论文”,思路严谨,论证充分(废话连篇),这跟大多数开源项目早期的头脑风暴,或者围绕一个核心设计逐渐展开的做法,是有很大不同的。

另一方面,彼时的RedHat正苦于自家OpenShift被竞争对手碾压的境况。经典PaaS不能破局的困难,反倒让RedHat对Docker这个有望颠覆PaaS的项目格外上心。这样一个在操作系统领域积累深厚、资源充足、并且蠢蠢欲动以求变革的开源巨头,碰上了满脑子Idea却对全面推进Kubernetes心有余而力不足的Google团队,可谓一拍即合。2014年12月,在Google正式发布Kubernetes项目不久,RedHat即官方宣布与Google开展战略合作,全面投入Kubernetes。在当时的一份官宣中,RedHat以非常自信的姿态表达了对容器的“颠覆性”创新的认可,并大胆预言Kubernetes会在2015年后取得应用编排与管理领域的统治地位:

……(RedHat的竞争对手们) 必须要认识到自研任何容器的局限性,尽早接纳Docker项目 ……

…… (RedHat的竞争对手们)必须要认识到没有人能够同Google在成规模的容器编排和管理领域里相抗衡 ……

谁曾想到,当年这套透露着几分“终于傍上大腿”的侥幸、甚至“托大”的说辞,现在看起来却几乎句句“实锤”。

这也是为何,Kubernetes虽一直大幅受益于Google的声誉和名望,还长期拥有Borg/Omega团队的技术加持,但如果从技术实现上来审视,这个项目却称得上是半个RedHat项目。也正是凭借最初阶段“Google赋予灵魂,RedHat赋予实体”的策略,Kubernetes才能够秉持着天马行空的设计思想的同时,稳扎稳打,然后一步步崛起于社区。

如今的Kubernetes,既赢得了GitHub等众多明星用户的青睐,也受到了全世界所有公有云巨头的热捧,还硬生生把Docker公司逼到改旗换帅、彻底摒弃了以往“暴力不合作”的路线,如果用一个“赢”字来描述它现在的情形,倒也并不为过。不过,这个“赢”字背后的原因,又在哪里呢?

Rancher的创始人梁胜博士最近有过一句评论,可谓道破天机:

时至今日,在容器技术领域依然有许多创新,只不过这些创新大多发生在Kubernetes以及CNCF生态系统中了

没错,容器技术圈的创新能力,在2015年后就已经逐渐转移到了Kubernetes生态,这是一个不争的事实,却也是一个曾经被忽视的变化。实际上,伴随着DockerCon越来越“boring”,Kubernetes的专属生态CNCF基金会却开始风生水起的原因也正在于此。

而从技术的角度上看,Kubernetes生态能取得这样的成功,依托的乃是一项其他竞争对手所不具备的核心能力:“使能用户二次创新“。

何谓“使能用户二次创新”?这其实是Kubernetes项目从开始设计之初就高度重视的一项关键诉求:

第一:从上层API到底层容器运行时,Kubernetes工作流中的每个环节,都希望具备完善的可扩展性。

第二:Kubernetes任何功能特性的设计和实现,都尽可能针对更通用的用户场景而非特定需求。

原生“使能二次创新”的技术基础,加上Google与生俱来的技术号召力,在加上CNCF基金会的整合和商业运作,以Kubernetes为核心所建立起来的这套容器编排生态,绝不比Docker公司最初建立起来的以容器为核心社区有任何逊色。再加上容器编排与管理的概念天生就更接近用户,Kubernetes的理念很快被社区接纳乃至追捧,也是情理之中。

一个直观的例子就是CoreOS的Operator项目。我们知道,在Kubernetes里部署任务,经常使用的是Deployment(Replication)来管理多个副本组成集群。但如果我们这次要部署的任务比较特殊,它的集群需要在增/删副本之后/之前做手动的运维操作呢?各种数据库集群就是最典型的例子。而Operator实际上是个用户自己编写的管理器,通过编程的方式把“运维”逻辑写进了管理器的代码当中。但关键在于,这个管理器的编写过程是完全“无脑”的,无非就是复制粘贴官方模板、然后填充自己的运维逻辑而已。这是因为Operator是构建于Kubernetes的CRD(自定义API资源)特性之上的,这个特性的目的就是允许并帮助用户自己编写一个可以与系统etcd交互的、Kubernetes风格的API资源管理器,并无缝地衔接到Kubernetes的核心API当中。

这个设计看起来很很直白,但是却解决了一个长期以来困扰系统级开源项目的难题:用户对项目的API不满意怎么办?

在过去的实践中,原封不动使用开源项目的场景是非常少见的,更常见的情况是用户把开源项目的API修改的面目全非。但在Kubernetes的场景下,用户的自定义API和原生API可以友好共处,统一对外服务,而且不会随着upstream变更而分家。这是保证Kubernetes社区完整性和被接纳程度的一个核心手段。

更为重要的是,有了这些标准化的扩展性API,用户就可以发挥自己的能动性,在Kubernetes之上构建出更多的扩展,甚至把这些扩展再交还给社区中的其他用户推广和使用。正如CoreOS的Operator,现在已经成为了社区运维有状态应用的一大法宝。

当然,“二次创新”的例子远不止于此。

2017年5月24日,Lyft,IBM联合Google共同宣布了Istio项目,一举撼动了微服务这个以往“光说不练”的“花架子”领域。Istio的核心思想,乃是借助一个proxy来接管容器里业务的进出流量,从而通过在proxy上的控制操作来完成应用流量的切分、访问授权、策略配置等一些列微服务治理功能。可以看到,这里有一个核心问题是:如何保证每一个需要治理的容器都绑定这样一个proxy呢?

解决这个问题的手段就是Pod。作为Kubernetes里的核心概念和原子调度单位,Pod是一组亲密耦合的容器集合,容器之间共享同一Network Namespace,显然,Istio框架中的proxy和业务容器正属于这样的耦合关系。但这还不是关键所在,这里最棘手的问题在于,Istio要做的是一个非侵入型的微服务框架,不可能要求用户在自己的部署文件中每次都额外定义一个proxy容器。怎么办?

答案还是借助Kubernetes。Kubernetes中有一个叫Initializer的扩展机制,允许用户在不修改业务Pod部署描述前提下,请求Kubernetes为业务Pod“自动注入”并启动一个预先定义号的容器。在Istio里,这个自动注入的容器正是前面不断提到的proxy:Envoy(Lyft自研的高性能服务代理)。

可以看到,通过组合Initializer等一系列Kubernetes标准API,用户可以优雅地实现很多以往繁琐或者困难的分布式系统的构建工作:就比如Istio里这套Spring AOP(面向切面编程)风格的组合方式。也正是因为有了这种标准化的实现手段,用户基于Kubernetes的“二次创新”才有可能再次交还给Kubernetes社区,从而碰撞出更多的创新火花和更新颖的用户案例。最终,不断激发出的创新开始吸引了更多人力和资本的进入,而资本与生俱来的促进作用就会推动这个社区的更强势的扩张。这种“开源-社区-商业”互相促进而构建出来的正向激励循环,正是Kubernetes生态在过去一年里“势不可挡”的重要原因。

回想在Kubernetes刚发布的时候,甚至在2017年初,Kubernetes的Pod以及Pod所体现出来的“解耦容器关系”的设计模式,依然时常被质疑为“用处不大”或者“过度设计”,然后现在回头来看Istio项目的炙手可热,我们确实要感慨“技术视野”的培育绝非一朝一夕。

从利用CNI、CRI等一系列良好设计的通用接口来实现不同类型、不同功能的网络和容器运行时,到使用API Aggregation扩展Kubernetes API Server从而支持自定义资源监控格式并以此来做Auto-Scaling,Kubernetes生态之中类似的“二次创新”的例子已然不胜枚举。依托于这种原生地鼓励用户发挥自己聪明才智的先进理念,在2018年,我们有足够的理由相信“二次创新”将继续成为Kubernetes生态中的一大关键词,各种基于Kubernetes可扩展能力的创新工作将成为社区的常态,甚至成为更多团队“一战成名”的不二法宝。

在未来,已经争取到领先地位的Kubernetes项目的进化重点,将逐步转移到安全性、稳定性、多租户能力、规模和性能优化、可扩展性设计等更多横向功能的升级上面。另外,将更多的非核心功能从主干代码中移除也将是未来一段时间Kubernetes社区的主要工作之一。2017年里,随client-go、apimachinery等API库的独立,已经为CRD等可扩展性功能的实现带来了极大的便利,而将来诸如部署工具kubeadm,内置的各种Cloud Provider,内置的rkt集成,各种各样的volume plugin等代码,也都将逐步迁移到它们单独的库中维护,这将有希望大大降低Kubernetes主库的复杂度和维护难度。

另一方面,Kubernetes可扩展性上的另一个重要设计CSI(Container Storage Interface)也已经发布。这意味着不久的将来,就如同容器运行时一样,容器持久化存储方案也将不必再跟Kubernetes的核心代码耦合,Kubernetes将使用统一的gRPC接口在完全独立的控制逻辑中维护容器存储卷(volume)生命周期。这个设计也很有可能会刺激容器存储领域更多的创新工作和更多的存储选择出现在Kubernetes社区当中。而包括KataContainers在内的虚拟化容器运行时,也将受益于存储解耦带来的、完全不同于现有容器存储设计的高性能的持久化存储方案。

在接下来的集群管理能力上,目前最大5000个节点的支持能力已经能够满足大多数用户的生产需求,而IPVS Service的引入也有很大希望能解决以往纯iptables Service引发的大规模集群中性能额外损耗问题。而在调度层面,默认调度器的可配置规则已经大幅增加,调度优先级和抢占技术也已经进入了默认调度器的alpha功能当中。而通过灵活配置亲密/反亲密关系、Taint/Toleration规则,Kubernetes的使用者已经能够解决绝大多数生产环境中的运维和调度需求。

在多租户与安全能力上,Kubernetes项目终于弥补上了这部分的短板。RBAC(基于角色的访问控制)功能目前已经成熟应用于很多基于CRD的Kubernetes外部扩展上面,Secret存储的加密也已经实现,集群部署中的节点通信加密配置也成为了默认功能。而在社区中,更完善的“强多租户”设计也第一次被提出,以便真正满足多租户环境下的集群管理需求。不过需要指出的是,Kubernetes的角色定位依然是Layer 0(Infrastructure Layer),更倾向于对上提供必要的多租户支持API和规范而不是实现完整的多租户模型。后者还是需要依靠Layer 1(Service Layer)来自己完成。

2017年也是人工智能技术席卷全球的一年,Kubernetes在其中也扮演了推波助澜的作用。在与之相对应的硬件加速器(Hardware Accelerator)功能的设计上,Kubernetes社区在Google,NVIDIA和Intel的牵头下发布了Device Plugin来允许用户自己编写自定义的、自发现的高性能硬件资源描述,并且以此为基础,将支持NUMA,InfinitiBand,FPGA等硬件框架的设计纳入了路线图。随着Kubeflow等项目的发布,不难预料到,Kubernetes在新的一年里会继续加大同人工智能社区合作,向成为机器学习领域支撑大规模分布式训练和AI服务的默认框架这一目标上不断挺进,而在此过程中,各家vendor在Kubernetes社区中进行技术上的角逐,亦将成为这个领域的主旋律之一。

随着Kubernetes项目的逐渐稳定,其开发迭代周期也将有所放缓,将目前每3个月一次release周期延长已经被提上讨论日程。与此同时,随着社区自动化管理能力(bot)的提高和SIG(Special Interest Group)组织的进一步完善,现有社区成员的写权限回收也是将来可能发生的大概率事件。这些都是Kubernetes社区逐步走向成熟的标志性里程碑。

容器运行时的二次繁荣

2017年,Kubernetes引领了容器编排与管理领域的蓬勃发展,而与此同时,另一个很有意思的现象则是容器运行时(Container Runtime)迎来了一次难得的二次繁荣。

一般来说,伴随着容器编排领域的迅速发展和成熟,容器运行时技术一定会因为被上层编排框架所屏蔽而逐渐淡出用户视野。事实上,这也正是Docker公司自成立以来的心病:光有一个容器运行时Docker,并不足以吸引用户真正投入到有价值的商业产品(比如PaaS)上来,更何况容器技术本身又是一个门槛相对不高的组合性创新成果,不能形成长期有效的技术壁垒。这个事实,也正是Docker公司一定要强推Swarm和SwarmKit等项目,以及Mesosphere曾短暂取得瞩目的一个主要原因。

当然,在Kubernetes依托社区和强大的创新能力崛起之后,容器运行时和它背后的主体的淡出便成了不可避免的宿命。这也是为什么我们会看到Docker公司会宣布将它的开源项目改名为Moby,这其实是它自己宣布将要放弃在开源社区中继续同Kubernetes和CNCF社区对抗的重要信号。这也是为什么我们会看到containerd和rkt被接连捐献给CNCF基金会:各类容器运行时的历史使命已经走向尾声了。

但是历史总有意外。Kubernetes的扩展性设计中一项核心功能的确立,却为容器运行时的创新者带来了新的机遇,这就是CRI(Container Runtime Interface)。

CRI的诞生还得追溯到容器运行时第一次繁荣、也就是容器理念第一次席卷技术圈的时候。彼时,Docker公司手持Docker项目大杀四方、是当之无愧的容器技术领导者。而CoreOS公司在选择拥抱Google和Kubernetes的同时,则发布了rkt以制衡Docker,以希望维护自己在容器技术上的话语权。这两位,再加上RedHat,他们在容器运行时领域的合作与竞争,直接推动了OCI这一容器技术标准的诞生。但实际上我们不难看到,Docker公司在容器运行时领域所占据的绝对主导地位,以及OCI本身对Docker公司商业利益的不友好意味,使得OCI长期以来并没能发挥出“标准”所应起到的推动和整合作用。

也正是在这个阶段,以Intel ClearContainer和Hyper为代表虚拟化容器技术,则开始从安全和多租户角度进入到开发者的视野。一时间,容器运行时领域可谓熙熙攘攘,不胜热闹。

而在Kubernetes发布之后,很多机敏的技术人员其实已经嗅到了其中的机遇。在Kubernetes未来有大概率会成功的前提下,谁能在Kubernetes内置的容器运行时中抢占到一个位置,谁才有可能在将来的容器技术圈子中争取到一席之地。所以很快,CoreOS公司通过政治和技术双管齐下的努力下,rkt成功跻身为Docker之后第二个被Kubernetes支持的容器运行时。但也正在这时,一些连锁反应式的问题也被激发出来。

一方面,彼时的Kubernetes羽翼未丰,并没有强势到能直接帮扶起rkt这个相对弱势的容器运行时的地步,更何况当时的Docker项目正突飞猛进,没有给同质的rkt留下任何喘息和反击的机会。所以虽然很早就进入了Kubernetes体系,rkt却一直处于少有用户问津的尴尬地位。

而另一方面,在当时快速迭代、完全没有稳定的Kubernetes尤其是kubelet组件中,额外引入的rkt运行时其实带来了大量的维护工作,并且这些工作很多时候还要依赖于CoreOS的介入才能解决,这无疑给Kubernetes团队带来了很大的压力。

与此同时,Kubernetes团队本身并不希望锁定在Docker容器之上。Docker公司不断推进Swarm项目的决心,很难让人对继续使用这样一个唯一的、不稳定的、将来甚至可能会变成一个PaaS的“容器”感到放心。

在这样的背景下,适逢Kubernetes团队也开始尝试逐步在项目中引入虚拟化容器技术,能不能提供一个通用的、与下层容器运行时无关的接入层来无缝对接上述所有容器运行时,就成为了当时Kubernetes能否更进一步关键所在。更重要的是,这也是Docker的软肋之一。由于显而易见的原因,Swarm体系并没有动力去支持任何非Docker之外的容器运行时,而另一方面,彼时的OCI话语权不济,并不能发挥对接其他容器运行时的作用,这就意味着Kubernetes项目会成为对接非Docker容器运行时的唯一出路。

就这样,一套由Google,Hyper和CoreOS共同主导的、以Kubernetes项目为核心的容器运行时接口的设计,应运而生。

CRI的及时发布,使得Kubernetes团队在后续SwarmKit等事件中可以处变不惊。而它的诞生,也直接推动了容器运行时这原本应该逐步淡化的领域焕发了第二次繁荣。

cri-o与cri-containerd

这次繁荣的第一个标志性的事件,是runC容器运行时cri-o的发布。

cri-o的初衷非常直白,既然现在Kubernetes可以借助CRI对接任何容器运行时甚至虚拟机,那么我们自然会想到,为什么不直接把runC封装成一个CRI的实现呢?这样不就可以绕过现有Docker容器的大部分机制而直接操作Linux容器了么?

所以,不同于Docker,除了用来响应CRI的gRPC server,cri-o并不需要额外的daemon组件来维护Linux容器。CRI的API调用在这里被直接翻译成对runC的操作命令,然后在宿主机上创建并启动runC容器。不难看出,这个工作流其实跟containerd的功能是基本一致的,但有意思的是,cri-o的发起者RedHat并没有使用containerd而是重新造了轮子。这其中,containerd的实际维护者是Docker公司恐怕是主要的考量因素之一。

实际上,在Docker公司决定打造自己的封闭生态之后,RedHat就跟Docker公司走向了对立的一面。毕竟相比Google专注于公有云业务而不太在意企业及市场,Docker公司随后发布的每一项产品(项目),却都在不同领域实实在在争抢着RedHat的蛋糕。作为曾经一起同推进容器技术的“兄弟”,如今“分手”后的RedHat对Docker公司的负面态度是可想而知的。所以,cri-o在某些实现细节上透露出来的一些偏执,也是这种思想指导下的必然产物。从最初放出言论要“fork Docker”,到现在cri-o的实际落地,RedHat在容器运行时领域的志向目前都压在这个项目之上。这也是为何RedHat的宣传机器在2017年 可谓开足了马力,连Kubernetes首席布道师Kelsey Hightower也曾短期被“攻陷”过。

然而,开源社区里最有意思的事情也莫过于此。就在cri-o几乎要以下一代Kubernetes默认容器运行时的身份粉墨登场之时,Google和IBM以及containerd的维护者们却默默的上线了cri-containerd项目。这个项目的思路更加显而易见:鉴于containerd已经捐给了CNCF,现在只要在其基础上略微封装,就可以为Kubernetes打造一个Docker native的、身份中立的CRI实现。相比cri-o每个release都要推广一番的风风火火,cri-containerd的进展可谓低调,仅在最近的DockerCon上小幅亮相了一次,并且期间一直与cri-o保持的良好的合作关系(比如共同维护lib)。但低调并不意味着不作为,2017年底,cri-containerd项目悄无声息地开始了与containerd项目的合并计划,这意味着很快containerd本身将会原生支持Kubernetes CRI。

CRI的成功我们有目共睹,但Kubernetes下一代默认容器运行时目前却尚无定论。Kelsey Hightower一向不太“待见”Docker,他的成名作“Kubernetes the Hard Way”在短暂试用cri-o后目前还是切换到了cri-containerd上。不过这也并不足以说明所有问题,至少在未来一段时间内,“No Default”还是可以继续作为这一领域的官方说辞。

不过,cri-o本身的崛起,侧面说明了“得编排者得天下”是目前容器运行时领域进一步发展的正确思路。CRI的及时发布,使得Kubernetes团队在后续SwarmKit等事件中可以处变不惊。而它的诞生,也直接推动了容器运行时这原本应该逐步淡化的领域焕发了第二次繁荣

Kata!Kata!

这个事件,正是Hyper runV同Intel ClearContainer的合并。合并之后的项目以KataContainers命名并托管于中立基金会,为虚拟化容器技术路线之争画上了句号。

实际上,在Hyper推出了runV技术之后,部分敏锐的技术人员就迅速开始了往Kubernetes推进基于runV的虚拟化容器技术的的集成工作。相比于Swarm体系的封闭和Mesos社区的后知后觉,Kubernetes项目从一开始就展现出来的技术远见,使得这个选择倒并不意外。而这次技术行为的直接结果,则是推动了CRI这一关键特性的诞生和落地:又是一个典型的社区“二次创新”然后再反哺社区的故事。在这个过程中,kubernetes/frakti项目作为虚拟化容器运行时的官方CRI实现,正是推动这项技术进入Kubernetes生态核心的关键一步。

不过,相比于Linux容器领域的Docker项目的一枝独秀,虚拟化容器技术则有一个困扰社区许久的问题,那就是几乎同期发布的Intel ClearContainer项目一直以来跟runV处于重合位置。尽管在项目的后期,Intel和Hyper团队已经开始共同维护很多公有的子项目,但开源社区的掣肘关系依然牵制了虚拟化容器技术进入容器生态核心的步伐。

不过,明智的是,runV并没有固执地在容器API层面同Intel开展类似Docker和rkt之间的竞争,而是把原生接入Kubernetes当成了第一要务,希望借助上层编排框架来为容器运行时发声。这个策略无疑改变了社区对虚拟化容器技术在整个生态中所处位置的看法。事实上,相比于我们所熟知的硬件级别隔离和容器安全这样的常识,虚拟化容器技术的独立内核特性为Kubernetes支持遗留应用和传统业务带来的巨大的想象空间,才是这种技术最大优势所在。尤其是伴随着2017年后期“强多租户”概念被引入到Kubernetes社区,能够从容器运行时层就开始进行租户隔离的设计已经成了一种刚性需求。没有虚拟化级别的隔离能力和独立内核来保证业务的多样性,“强多租户”基本无从谈起。试想一下,在一个真正的多租户云数据中心里,有的租户的应用是Windows的,有的是Linux的,除非做低效的静态划分,常规Linux容器又该如何应对这样的需求呢?

KataContainers项目的出现,把刚刚崭露头角的虚拟化容器技术推向了一个新的阶段。作为OpenStack基金会力图革新后发起的第一个项目,托管于该基金会下面的KataContainers却不必遵守OpenStack社区任何现有的规范,其自由度和改革力度,可见一斑。而这次合并的最终促成虽然被OpenStack基金会抢了先机,但CNCF基金会则开始从OCI入手,试图将KataContainers的运行时再纳入到OCI的范畴之中。我们有理由相信,在两大基金会的通力合作之下,KataContainers的前景非常光明。

不过,更为重要的是,以KataContainers为代表的虚拟化容器技术在云计算领域的探索,正有意无意地打开了公有云的一个新篇章。

ACI,Fargate与“Serverless容器云”

在runV容器发布之后,为了验证虚拟化容器对公有云带来的变化,一个名为hyper.sh服务同步上线并随后迅速霸榜了HackerNews头条。这个服务的创新之初在于,虽然它的整个技术栈都基于Kubernetes,但是它却不对外暴露任何Kubernetes API,也没有提供任何操作console,而是让用户用本地的“hyper run <IMAGE>”指令来在云端创建和启动容器。由于使用了虚拟化容器技术,这个工作流里完全不需要虚拟机的介入,所有租户的容器直接运行在裸物理机集群当中。

虽然看起来简单,但这个设计的本质,却提供了一种容器云的Serverless的设计思路。在这个“无服务器”云的设计中,云的用户完全不必学习任何Kubernetes或者云平台API或者文档,仅靠开发者所熟悉的本地容器操作就可以完成作业的云端部署,然后按秒计费。

而在2017年,这种颇有远见的容器云Serverless开始得到了公有云巨头的青睐。这一次的始作俑者正是近年来在云服务领域出手“稳”、“准”、“狠”的Microsoft。2017年7月26日,Microsoft Azure团队宣布了ACI(Azure Container Instance)服务的发布,其通过“az container create”创建容器的思路,与hyper.sh如出一辙,并且同样屏蔽了所有下层的PaaS和IaaS概念然后按秒计费。一石激起千层浪,国外容器技术圈子对这种服务的讨论迅速成为了当时的技术头条。有人说它是AWS Lamda的有力竞争者,也有人说这才是Serverless服务的终极形态。

紧接着,在2017年11月,堪称全球云计算技术风向标的AWS re:Invent 大会上,AWS高调宣布了同类型服务Fargate的诞生,把Serverless Container Cloud的理念推向了新的高潮。作为回应,Microsoft则联合Hyper发起了virtual-kubelet项目,旨在定制一套标准,允许云提供商把自己的Serverless Container Cloud,以kubelet API的方式接入到任意的Kubernetes集群中作为一个特殊的节点而存在,从而轻松实现一个基于Kubernetes的混合云。目前,AWS、甚至OpenStack都已经加入这个项目开始贡献自己的实现,对应的基金会和开源生态正迅速形成。不出意外,很快Google、国内的阿里云等巨头,也会推出类似的Serverless Container Cloud服务,并且加入到virtual-kubelet项目当中。

Serverless Container Cloud服务备受欢迎的本质,乃在于公有云计算所服务的用户,尤其是广大的开发者群体,对于追求“简单高效”的热情其实是非常高涨的。对于他们来说,在各种设计拙劣的云管理界面上进行凌乱的鼠标操作,绝对不如在键盘上敲打本地命令来的舒服。这种微妙的体验变化,正如同git对比SVN,Docker对比OpenStack。更为重要的是,这种服务形态也正符合了Kubernetes技术继续发展的正确路线:Kubernetes所要扮演的角色,乃是取代传统的Infrastructure Layer并鼓励技术人员进行上层的“二次创新”,而并不是直接面对最终用户(实际上Kubernetes本身的声明式API也是对运维而非开发友好的)。真正为最终用户提供云服务的,很大概率应该是构建于Kubernetes之上的、更加简洁高效的服务型API,而Serverless,尤其是Serverless Container Cloud的设计,正是这种需求下最为贴切的实现方式之一。

不难预料,在新的一年,基于Kubernetes之上构建出来的创新型Serverless服务(当然也包括OpenFaaS等优秀的Function),将会是大小云计算提供商进一步角逐的一个关键领域。相比之下,曾经在国内外普遍开花的、以直接售卖Kubernetes集群为核心的各种“CaaS”,将会沉寂许多。

Docker Inc的未来

毫无疑问,2017年的Docker公司依然是容器圈子里的主角。只不过这一次,波澜之中的Docker公司的确并不好过。

从2017年4月Docker项目毫无征兆地改名为Moby开始,Docker公司顶着巨大的争议,逐步完成了开源技术创新公司到商业公司的转变,也开始正视长期以来同Kubernetes社区竞争所带来的极其不利的商业局面:伴随着Kubernetes项目的成功,Swarm已成为明日黄花,曾一度承载着新希望的SwarmKit也渐渐淡出社区视野。2017年10月,在DockerCon EU上,Docker公司官方宣布下一版本的Docker EE中将全力拥抱Kubernetes,标志着持续了近三年之久的容器编排之争彻底落下帷幕。紧接着,所有纷争的始作俑者、曾经携Docker对抗整个容器社区的Solomon Hykes也宣布自己“角色转变”,不再负责Docker产品的具体技术事宜。

曾经纷纷扰扰的容器圈子,竟然一夜之间尘埃落定,个中滋味,不免让人心生惆怅。Docker公司和Solomon的经历可能不算是传奇,但也绝对能够在云计算历史中留下了浓墨重彩的一笔。我们甚至会不时想象,如果当初Solomon没有去做Swarm,而是选择同Google合作共举Kubernetes,如今的CoreOS还会不会活着?如今的Docker公司又是什么样子?

历史难做假设。

但是Docker公司的未来却依然是光明的。

在积极拥抱Kubernetes社区之后,Docker公司正走向正确的轨道。大家不要忘记,在迎合开发者社群和技术微创新这两个关键手段上,Docker公司的实力绝不容忽视。2018年初,Docker Mac集成Kubernetes的版本正式发布,并立刻在开发者群体中掀起了轩然大波。在Mac OS上如此流畅启动和运行Kubernetes的体验,在这么短的时间内就被Docker公司带到了开发者手里,这其中体现出来的技术能力与产品理念,正是将来Docker公司继续立足的核心所在。当然,Docker公司最终的成功,依然取决于其商业产品能否赢得重量级客户的青睐,在这一点上,Kubernetes的坚定盟友CoreOS已然占尽先机并且完成了转型。但是Docker公司在容器领域不俗的创新能力和产品积累其实是有增无减,其产品线也更完整,在开发者群体中的基础也更雄厚,这样一个人气与技术兼备的创业公司的未来,绝不见得会像某些文章中描述的那样一片哀鸿。这一点,我们不妨拭目以待。

国内

相比于过去默默无闻,2017年的国内容器技术玩家终于得意发声,而且“不鸣则已,一鸣惊人”。阿里集团在双11过后,高调发布了源自其内部容器T4的开源项目Pouch,并迅速成为了当时的技术热点。事实上,早在Docker和Kubernetes技术如火如荼的2015年,业界就发出过疑问:在此领域积累深厚(百度有Matrix,阿里有T4)的国内的互联网巨头为何迟迟不见动作?

好在厂商会迟到,但技术不会。Pouch的发布,也正是前面提到的“2017年容器运行时技术二次繁荣”的又一例证。在Docker公司逐渐式微、rkt几乎退役的档口,Kubernetes的崛起和CRI的成熟正在为所有的容器运行时玩家带来全新的机会。从代码上看,Pouch并非“Docker fork”,而是利用类似技术进行的全新实现。从功能上看,Pouch原生接入了runV来提供多样化的隔离机制,内置“富容器”能力以满足不同的业务场景,打包了Dragonfly来实现高效的镜像分发,这意味着这套技术栈从底自上有着同Docker整体不一样的业务考量。

但另一方面,如今的时间点不同与2015年,用户的关注点已经从容器运行时转移到了上层容器编排管理的服务能力。而作为近来Linux容器的第三个实现(cri-o只支持Kubernetes,不能算作完整的容器实现),尽管功能上有所差异,但Pouch仍然难免会陷入同质竞争的不利局面。不过需要指出的是,阿里集团接下来亦在酝酿其内部集群管理系统Sigma项目的开源工作,并且会积极地将Sigma纳入到Kubernetes的现有生态当中,这就为Pouch未来的前景增添了一层有趣的砝码。毕竟,Pouch本身在Docker的优势地位中突围可以说困难重重,但正如前面所提到过的,如果能够借助上层容器编排能力重新表达这一容器运行时的关键作用,那这套技术方案的应用前景和接纳难度很可能会发生变化。这也正回到了我们最开始谈到“Kubernetes赢在何处”时所作出的阐述:Kubernetes社区通过从技术和生态双重层面上使能用户二次创新的做法,必将推动这个生态走向一个更加繁荣而有意义的新阶段。

总结

“任何一个被浓厚的商业兴趣所充斥的开源社区,最后都难免走向有毒的方向”

— Solomon Hykes

2017年,曾经的弄潮儿Docker公司在巨大的争议中终于完成了向商业公司的重要转变,也宣告了由Kubernetes社区所主导的、全新的容器生态正式拉开序幕。在回顾Kubernetes如何赢得这次竞争的同时,我们应该意识到容器运行时“二次繁荣”的短暂窗口正在为我们带来新的机遇。与此同时,容器公有云的形态正在悄然发生变化,伴随着这次变革而存在的,固然有风险,但也有很可能会催生出新的云计算赢家甚至独角兽。最为重要的是,伴随着Kubernetes社区的日益壮大,如何避免这个生态陷入Solomon所警告的“有毒”陷阱,恐怕很快就会成为摆在这个社区所有参与者面前的一道难题。是的,是所有参与者都对此负有责任,而绝不仅仅是CNCF或者Google就有能力独自解决的一次危机。

作者

张磊,浙江大学博士研究员,Hyper项目成员,Kubernetes项目资深成员与社区维护者。长期专注并活跃于容器集群管理与云计算数据中心领域,连续多次被微软授予该领域“最有价值专家(MVP)”称号。

来源:infoq

http://www.infoq.com/cn/articles/2017-container-Kubernetes

2017Docker公司过的不容易

中文社区阅读(1252)评论(0)

编者话:本文来源云头条微信公众号,原标题,“Docker公司已死”,个人觉得此title太过标题党,索性改成“2017Docker公司过的不容易”似乎更贴切。

作者简介:Chris Short在IT行业有20多年的从业经历,他毕生坚定地提倡使用开源解决方案。他是身体部分残障的美国空军退伍老兵,现与妻子和儿子一起住在密歇根州大底特律都市区。

要说Docker在2017年的日子非常难过,那已经算是轻描淡写了。除了优步(Uber)外,我实在想不出还有哪一家更加被利用、被炒作、资金充裕的硅谷初创公司(仍在运营之中)像Docker在2017年那样步履维艰、糟糕透顶。回顾2017年,人们会记得在这一年,Docker这款优秀的软件完全毁于糟糕的经营方法,导致Docker公司在2018年寿终正寝。本文从局外人的视角回顾了Docker怎么出岔子,哪里出了岔子,以及为何说Docker现在试图解决问题为时太晚。

Docker是优秀软件

有一点很清楚,Docker帮助彻底改变了软件开发领域。拿来cgroups、命名空间和进程隔离等Linux基本元素,把它们做入到一个工具中,这本身就很了不起。2012年,我试图弄清楚开发环境如何可以更易于移植。 Docker的崛起使开发环境得以成为一个简单的、可版本控制的Dockerfile。工具形形色色,从Packer、Vagrant、VirtualBox和众多基础设施,到Docker,不一而足。Docker UI实际上也相当不错!这是一款用途广泛的优秀工具。Docker团队的成员应该为他们开发的工具感到自豪。

Docker是硅谷的宠儿

Docker早期的成功促使该公司围绕其产品建立起了一个庞大社区。而早期的这种成功让它融到了一轮又一轮的资金。像高盛、Greylock Partners、红杉资本和Insight Venture Partners这些大名鼎鼎的投资者竞相为Docker提供大把大把的资金。到目前为止,Docker筹集到的投资总额在2.42亿美元至逾2.5亿美元之间。

但是与2010年代大多数资金充裕、不计代价以求成功的初创公司一样,Docker也犯了人力资源方面的几个失误。Docker在崛起过程中竭力保护一些很蹩脚的货色。这导致我个人不喜欢这家公司的领导层。产品仍然是一流的,但这根本无法因此原谅该公司的行为。遗憾的是,硅谷的许多宠儿都是这样,这种情况需要有所改变。

Kubernetes对Docker造成了损害

Kubernetes的崛起更是加快了Docker的消亡。 Docker在处理Kubernetes方面并没有为它自己带来任何好处,而Kubernetes是开源社区青睐的容器编排工具。Docker的竞争产品Docker Swarm是Docker的头脑中唯一记挂的容器编排工具。尽管Kubernetes起初偏爱Docker容器,Docker还是做出了这个决定。这里捎带提一下,Docker Captains在2017年初证实,当初Docker对文章、聚会和会议上屡屡提到的Kubernetes根本就不感冒。

直到奥斯汀召开的dockercon17大会,Docker依然奉行无视Kubernetes的这种做法。然后在dockercon EU 17大会上,Docker几乎突然决定全身心地支持Kubernetes。这个突然的变化说明Docker显然承认了Kubernetes的强势崛起、即将成为市场的霸主。Docker成为KubeCon + CloudNativeCo北美2017年大会的赞助商,并且设有展台,更是彰显了这个事实。

Moby?

没有人了解Docker去年4月份在dockercon17上宣布Moby时做了什么。Moby被称为是Docker项目的新上游,但是没有提前宣布Moby的发布。所罗门•海克斯(Solomon Hykes)在dockercon17大会上发言时,GitHub上出现了一下子由Docker向Moby大转变这一幕,无数的人害怕地惊叫起来。这种突如其来、考虑欠周的变化需要 GitHub的工作人员直接干预。

不仅没有处理好这个变化,Docker所要传达的讯息也没有深思熟虑。这导致该公司对这一变化表示道歉,高层亲自出面解释。这让原本乱象丛生的容器领域和Docker(或者Moby?)生态系统更让人摸不着头脑了。处理Moby的发布继续困扰着那些从业人员。 Docker品牌可能因此受到了损害。

对Kubernetes态度冷淡

Docker在最后的时刻尴尬地拥抱Kubernetes是表明它即将崩溃的迹象。被问及Docker Swarm是否已经死亡时,所罗门•海克斯曾经发推文道:“Docker将继续支持Kubernetes和Swarm作为一等公民,并且鼓励交流和分享。开放性和灵活选择为每个人创造了一个更健康的生态系统。”这里的问题是,Docker Swarm并没有完全成熟,实际上离完全成熟相差甚远。Docker Swarm产品团队及其少数开源贡献者将跟不上Kubernetes社区的步伐。尽管Docker UI很优秀,但Kubernetes UI却出色得多。就好像Docker现在承认自己是容器领域的一家边缘化的咨询公司。

结束语

Docker的真正问题是缺乏连贯一致的领导团队。战略重心似乎就围绕这家公司的某一个人。这个人已经被越来越远离公司的核心,但他依然当权。公司已经过了重组,把重心转移到企业客户。这种转变对于Docker的投资者来说颇为明智(毕竟公司确实背负信托责任)。但是,这种转变会削弱该品牌的酷炫因素,而酷炫因素当初促使其大获成功。常言道:“伟大的文明不是被谋杀的,而是自杀的。”Docker就是这样一个活生生的例子。

阴谋论

针对Docker在2017年的尴尬时期,我在Twitter上倒是提出了一个观点。Docker可能知道公司本身已是穷途末路。由于组织变化表明即将退出(可能通过收购),该公司的技术核心优先考虑一些变化。将containerd捐赠给云原生计算基金会(CNCF),让Moby成为Docker的上游,并且拥抱Kubernetes,这些举措将使Docker的人员所做的好事被永载史册。这让像Oracle或微软这样的大企业得以过来收购这家公司,不必担心Docker的员工取得的技术进步被许可证牢牢束缚。这为软件团队和公司本身提供了两全其美的方法。不用说,2018年对于Docker来说将是值得关注的一年。

Kubernetes 1.9GA 版本最新发布 | 更新日志

中文社区阅读(2827)评论(0)

2017年12月15日,kubernetes1.9版本发布。Kubernetes依然按照每三个月一个大版本发布的速度稳定迭代,这是今年发布的第四个版本,也是今年的最后一个版本,该版本最大的改进是Apps Workloads API成为稳定版本,这消除了很多潜在用户对于该功能稳定性的担忧。还有一个重大更新,就是测试支持了Windows了,这打开了在kubernetes中运行Windows工作负载的大门。

Workloads API GA

apps/v1 Workloads API成为GA(General Availability),且默认启用。 Apps Workloads API将DaemonSetDeploymentReplicaSetStatefulSet API组合在一起,作为Kubernetes中长时间运行的无状态和有状态工作负载的基础。

Deployment和ReplicaSet是Kubernetes中最常用的两个对象,经过一年多的实际使用和反馈后,现在已经趋于稳定。SIG apps同时将这些经验应用到另外的两个对象上,使得DaemonSet和StatefulSet也能顺利毕业走向成熟。v1(GA)意味着已经生产可用,并保证长期的向后兼容。

Windows支持(beta)

Kubernetes最初是为Linux系统开发的,但是用户逐渐意识到容器编排的好处,我们看到有人需要在Kubernetes上运行Windows工作负载。在12个月前,我们开始认真考虑在Kubernetes上支持Windows Server的工作。 SIG-Windows现在已经将这个功能推广到beta版本,这意味着我们可以评估它的使用情况

增强存储

kubernetes从第一个版本开始就支持多种持久化数据存储,包括常用的NFS或iSCSI,以及对主要公共云和私有云提供商的存储解决方案的原生支持。随着项目和生态系统的发展,Kubernetes的存储选择越来越多。然而,为新的存储系统添加volume插件一直是一个挑战。

容器存储接口(CSI)是一个跨行业标准计划,旨在降低云原生存储开发的障碍并确保兼容性。 SIG-StorageCSI社区正在合作提供一个单一接口,用于配置、附着和挂载与Kubernetes兼容的存储。

Kubernetes 1.9引入了容器存储接口(CSI)的alpha实现,这将使挂载新的volume插件就像部署一个pod一样简单,并且第三方存储提供商在开发他们的解决方案时也无需修改kubernetes的核心代码。

由于该功能在1.9版本中为alpha,因此必须明确启用该功能,不建议用于生产使用,但它为更具扩展性和基于标准的Kubernetes存储生态系统提供了清晰的路线图。

其它功能

自定义资源定义(CRD)校验,现在已经成为beta,默认情况下已启用,可以用来帮助CRD作者对于无效对象定义给出清晰和即时的反馈。

SIG Node硬件加速器转向alpha,启用GPU,从而实现机器学习和其他高性能工作负载。

CoreDNS alpha可以使用标准工具来安装CoreDNS。

kube-proxy的IPVS模式进入beta版,为大型集群提供更好的可扩展性和性能。

社区中的每个特别兴趣小组(SIG)继续提供其所在领域的用户最迫切需要的功能。有关完整列表,请访问发行说明

获取

Kubernetes1.9已经可以通过GitHub下载

参考

Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem

剖析IBM Cloud Private服务,以Kubernetes为调度核心

中文社区阅读(473)评论(0)

IBM Cloud Private重点策略

  1. 主打PaaS应用管理需求,强调快速自建的私有容器云
  2. 兼顾传统IT需求,能同步管理容器及VM

上有AWS、GCP以及Azure,下有甲骨文竞争对手的IBM,在今年3月时宣布,正式在Bluemix容器服务上支持Kubernetes。目前这家公司支持Kubernetes的方式共有两种。第一种是以公有云平台IBM Cloud Public的容器服务为基础,支持容器调度功能。第二种则是在私有容器平台IBM Cloud Private中,以Kubernetes为核心引擎,目前两个平台都已经支持至Kubernetes 1.7.3版。

而IBM调度工具架构的演进,总共可分为3阶段。最初,IBM推出自家版本的Docker,并以Docker Swarm为基础,自主开发了一套调度工具。第二阶段中,则在单一平台上同步整合Mesos及Kubernetes,使用Mesos管理系统资源,Kubernetes则专注在容器调度。而到了现今,则是全力押宝Kubernetes,透过它掌控容器调度、资源分配的任务。

公有云平台以Cloud Foundry为主要底层架构

现在IBM Cloud Public及IBM Cloud Private这两个平台上皆支持Kubernetes,但是平台特色的定位,也影响该门技术的支持程度及实作功能。

目前IBM Cloud Public是以开源PaaS Cloud Foundry为基础,许多服务仍要靠既有Buildpack,打包应用程序执行所需要的组态设定、环境。而容器调度任务则主要靠Cloud Foundry的Diego框架完成。以PaaS为基础的优点在于,开发者只须关注程序代码开发,不须介入底层Docker容器的运作,但是其平台僵固性也更高。

私有容器平台用Kubernetes为核心,还能搭配其他开源工具

虽然目前IBM Cloud Public、IBM Cloud Private皆能作为容器执行平台,但私有环境的目标是让Kubernetes跟Cloud Foundry并存。

IBM Cloud Private虽支持Cloud Foundry,不过底层则是选择Kubernetes为核心,整合了开源网络虚拟化工具Calico、Kubernetes打包工具Helm,以及IBM自家的行动应用程序管理工具Application Center。

而IBM Cloud Private除了有Kubernetes作为调度核心外,还得提供其他相关容器功能。例如,在此平台也有提供容器漏洞扫描功能,想要部署在该平台运作的容器,均得通过此程序,藉此确保既有Kubernetes环境中执行的容器不会受到影响。

以私有容器平台而言,IBM不单把Kubernetes视为容器调度工具,如果将平台上的Docker容器视为各自独立执行的服务,此时Kubernetes便可以被视作PaaS,而IBM Cloud Private则成为企业内部的私有容器云管理平台。

以容器为基础发展,也为企业使用者带来更多自由度,例如,可以自由加入开源工具如Elasticsearch、Kibana或是Grafana等。

此外,现阶段IBM Cloud Private也已经整合微服务管理工具Istio,主要用途为补强Kubernetes的网络功能。Istio现阶段在此平台主要满足两大需求。第一需求是支持路由功能,透过此工具管理、追踪出入集群的网络流量。而第二个功能则是安全监控功能,根据系统管理所定义的网络管理策略,限制系统服务的访问权限。

Istio团队表示,想要开发稳定、松散耦合,又能进入正式环境的微服务相当具有挑战性。随着单体式(Monolithic)应用程序分解成微服务,软件团队必须考虑分布式系统如何整合各种服务,像是服务搜寻、负载平衡、容错、监控。

而Istio提供的是「服务网」(Service Mesh)的概念,让服务及网络之间拥有透明的架构层,提供运营商所需的控制能力,开发人员也可以专注开发程序代码,让运营商脱离应用程序的功能开发与发布过程。而Istio的角色即是系统化地嵌入代理人,将各种不同的微服务变成单一的整合服务网络。

而近日所推出的0.2版,除了加强稳定性、表现效能之外,也加入一些企业所需的支持,像是TLS认证机制、TCP服务。同时,Istio开始支持多种开源工具,像是HashiCorp的集群管理调度工具Nomad、服务探查工具Consul,还有Netflix开源推出的云端负载均衡工具Eureka。

Kubernetes操作接口仍有可继续加强,增进易用性

不过,现在许多企业系统仍以VM环境为主力,还不能一次到位地迈入容器环境。因此,IBM以基础架构管理工具Terraform,开发了IBM Cloud Automation Manager,即使只有Kubernetes,也能同步管理容器及VM。

目前Kubernetes最新的版本为1.8,而IBM已经开始支持1.7.3版,支持步调算是快。不过部分既有服务、产品还未能与容器平台进行深度整合。例如,现在企业用户使用Kubernetes必须透过传统的命令程序接口操作,对部分非工程背景用户可能较不便。而IBM现在也已经计划,要推出更友善的Kubernetes操作接口。

同时,IBM也希望把Kubernetes变成新一代的PaaS平台,并且将产品、服务容器化,透过Docker镜像形式提供并收取授权费用,也能减低企业部署、安装的难度。

如何配置Kubernetes以实现最大程度的可扩展性

RancherLabs阅读(941)评论(0)

Kubernetes的设计初衷是要解决管理大规模容器化环境时的困难。不过,这并不意味着Kubernetes在任何的环境下都可以进行扩展。有一些方法可以让用户最大限度地发挥Kubernetes的扩展能力,而在扩展Kubernetes时,有一些重要事项和限制需要注意,本文中我将对这些内容进行说明。

规模和性能

扩展Kubernetes集群,首先要注意的就是规模和性能之间的平衡。比如,Kubernetes 1.6可被用于多达5000个节点的集群。不过5000个节点并不是硬性限制的最大值,它只是一个推荐的节点最大值。在实际使用中,节点数可以远超过5000个,只是这样会导致性能下降罢了。

这个问题具体来说是这样的:Kubernetes有两个服务层级的目标,一个是在一秒内返回99%的API调用。另一个是在5秒内启动99%的pods。尽管这些目标并不是完整的一套性能指标,但它们确实为评估通用集群性能提供了良好的基准。而据Kubernetes所说,超过5000个节点的集群可能无法实现这些服务层级的目标。

所以有一点请大家注意,在有些时候,为了发挥Kubernetes的扩展性,你有可能不得不牺牲一部分的性能,这些牺牲对你来说既可能是值得的,也可能是不值得的,而这取决于你具体的部署场景。

配额(quotas)

在建立非常大规模的Kubernetes集群时,你可能会遇到的一个主要问题就是配额问题。对于基于云的节点尤为如此,因为云服务提供商通常情况下会设置配额限制。

这个问题之所以如此重要,是因为部署大规模的Kubernetes集群实际上是一个看似简单的过程。config-default.sh文件有NUM_NODES的设置。表面上,你可以通过加大与此设置相关联的值来构建大规模集群。虽然这在某些情况下可行,但最终也可能会遭遇到配额问题。因此,在你打算扩展集群之前,很有必要就现有的任何配额先和云供应商进行沟通。云供应商不仅可以让你了解现有配额的情况,而且至少一部分云供应商会同意用户增加配额限制的请求。

当你在评估这些限制的时候,需要注意,尽管配额限制会直接限制你创建Kubernetes集群的数量,然而集群大小的限制更多是出自与Kubernetes间接相关的配额。例如,提供商可能会限制允许你使用的IP地址数量,或者限制你创建的虚拟机实例数量。而好消息是,主要的几个云服务商已经有多次和Kubernetes打交道的经验,应该能够帮助你解决这些问题。

主节点

除了上述的限制外,还需要考虑的一个问题是集群大小对所需的主节点大小和数量的影响。这些取决于Kubernetes的实现方式,不过要记住的一点是,集群越大,所需的主节点数量也越多,而那些主节点的功能需求也就越高。

如果你正在从头构建新的Kubernetes集群,这可能是一个无关的问题,毕竟确定需要的主节点数量是集群规划过程中的正常阶段。可是如果你打算扩展现有Kubernetes集群,那么你更需要去多加考虑主节点的需求,因为在集群启动时主节点的大小就已经设置好了,而且不能够动态调整。

扩展附加组件(scaling add-ons)

另一件需要我们注意的是,Kubernetes定义了附加组件容器的资源限制。这些资源限制可确保附加组件不会消耗过多的CPU和内存资源。

这些有关限制的问题是,它们是基于相对较小的集群进行定义的。如果你在大规模集群中运行某些附加组件,它们可能会需要超额使用更多的资源。这是因为附加组件必须服务更多的节点,也因此需要额外的资源。如果开始出现与组件相关限制的问题,那么你就会看到附加组件一个一个地被kill掉。

总结

Kubernetes集群可以大规模扩展,但可能会遇到与配额和性能相关的问题。因此,在向Kubernetes集群添加大量新节点之前,请一定要仔细考虑横向扩展所出现的各种需求。

为什么Docker最终接受了Kubernetes?

中文社区阅读(3531)评论(0)

容器编排器的大战似乎快要结束了——Docker宣布在下一个企业版本开始支持Kubernetes。下面是你需要了解的:

Docker的吉祥物可能是鲸鱼,然而在Dockercon Europe 2017之前,Kuberenetes是人们避而不谈的大象。三个主要云提供商都加入了由Kubernetes主持的开源基金会,即云原生基金会(CNCF),这让其势不可挡。

行业的转向似乎让Docker Swarm成了孤家寡人。Docker的竞争者如Redhat的Openshift早已接受Kubernetes,Docker也终于在Dockercon Europe 2017的主题演讲中宣布将Kubernetes整合加入日程,总算登上Kubernetes的列车。

编排器概览

就像Apple推出iPhone让智能手机变成主流,Docker让容器变成了主流。自从项目发布以来,Docker着重于提升开发者的体验。基本理念是可以在整个行业中,在一个标准的框架上,构建、交付并且运行应用。理论上,一个机构能够从一个笔记本上构建出一个持续集成和持续开发的流程,然后将其应用到生产环境。

起初的一个挑战是数据中心编排。与VMware vSphere不同,当时少有能在生产环境中大规模管理负载的工具,而Docker用来在数据中心级别进行容器编排的主要方式是Docker Swarm。

容器编排的解决方案一直不缺。Mesosphere是早期的领头羊,而现在的势头已经今非昔比。Docker Swarm虽然是单个厂商的编排视角,但是它与Docker EE深度整合。Docker正在用Docker EE构建一个能合与成熟的项目如Cloud Foundry匹敌的平台。然而,正如前面提到的,整个行业已经聚集到了Kubernetes的家门前。

按照Docker的说法,Google将它们的超大范围的经验带到了容器编排中。Kubernetes采取的开源策略赢得了生态中的大量用户。

结伴运行

Kubernetes的学习曲线是陡峭的。Docker的实现看起来将Kubernetes的复杂度隐藏到了幕后。编排层就像应用开发者和运维团队的一个契约一样。API是一种用来在这两种团队之间进行沟通的语言。Swarm和Kubernetes不仅使用不同的架构,而且使用的API也不一样。

Docker采用的设计允许在同一个集群中同时运行Kubernetes和Swarm。在部署Swarm的时候,安装器提供了一个安装Kubernetes的选项。如果勾选了该选项,Kubernetes会继承Swarm安装的冗余设计,同时将两种不同的方式整合到子系统如网络中。

为两种编排器设计的生态系统仍然能够独立地运行。例如,利用原生Kubernetes API的应用和进程能直接和用Swarm部署的实例运行。类似的,使用Docker Compose文件部署的应用能原生地在Swarm提供的Kubernetes基础设施上原生地运行。

这就给我们带来了资源管理的挑战。Swarm和Kubernetes能在单个主机上运行,每一个编排器都不知道对方的存在。每一个编排器都假设能使用主机100%的资源,所以,Docker不推荐在同一个主机上同时运行Kubernetes和Swarm的工作负载。

这个特性会在2018的第一个季度GA,据此我有理由认为这是一个容器生态系统的里程碑时刻。通过将Docker EE和Kubernetes整合,Docker不再只是人们口中的开发平台,它也是一个生产级别的能和PaaS提供的解决方案一战的生态系统。

原文链接:Why Docker is finally embracing Kubernetes(翻译:钟最龙)

应用开发者必须了解的Kubernetes网络二三事

RancherLabs阅读(1069)评论(0)

在容器领域内,Kubernetes已毋庸置疑成为了容器编排和管理的社区标准。如果你希望你所搭建的应用程序能充分利用多云(multi-cloud)的优势,有一些与Kubernetes网络相关的基本内容是你必须了解与考虑的。

Kubernetes网络基本的部署调度单元:Pod

Kubernetes中的基本管理单元并非是一个容器,而是一个叫做pod的东西。我们认为部署了一个或多个容器的环境是一个pod单元。通常情况下,它们代表了提供部分服务的单个功能端点。

举两个有效的pods单元为例:

  • 数据库pod — 一个单一MySQL容器
  • Web pod — 包含一个python实例的容器及包含Redis数据库的容器

pods具有以下常用的特性:

  • 它们共享资源 — 包括了网络栈和命名空间
  • pod包含了一个IP地址,用于客户端连接
  • pod的配置定义了任意公共端口以及哪个容器占用该端口
  • pod中的全部容器可以通过网络中的任意端口进行交互(这些容器都会被本地引用,因此需要确保pod中的服务都有唯一的端口)

Kubernetes服务(Kubernetes Services)

Kubernetes服务位于负载均衡器之后,负责管理多个相同的pods。客户端无需连接到每个pod的IP,而是直接连接负载均衡器的IP地址。Kubernetes服务会将你的应用程序定义为一个服务,使得Kubernetes可以根据定义的规则和实际可用资源动态扩展pod数量。

若想要应用程序被Kubernetes基础设施外部的客户端访问到,唯一的方法是将应用程序定义为服务的一部分。无论你是否扩展节点,都需要Kubernetes服务分配外部IP地址。

标签(Labels)

标签是Kubernetes中一组作用于对象(如pods)的键值对,需要具有实际意义且有相关性。

在Kubernetes的标准配置中,标签并不直接影响与Kubernetes相关的核心操作,而是主要用于对对象的分组和识别。

网络安全(Network Security)

下面我们将介绍一些Kubernetes推荐使用的网络插件,这些插件用到了我们上一节提到的标签。利用标签,它们可以在容器运行时改变某些功能。在Kubernetes中,大多数使用的网络插件都是基于容器网络接口(Container
Networking Interface ,CNI)规范,这项规范由Cloud Native Computing Foundation(CNCF)制定。CNI允许在多个容器平台中使用相同的网络插件。现在我们使用一种调整网络安全策略的方法,该方法并不像传统的网络或者安全团队模型那样预先设置好一切,而是在容器运行时,利用标签来调整正确的网络策略(容器的动态变化太过频繁,很难进行手动干预),目前该方法已经成为了 Kubernetes Network Special Internet Group(Network SIG)的一部分。如今,我们已经有多个可供使用的网络插件能够将网络策略应用于命名空间和pods中,这其中包括OpenContrail 和 Project Calico。

通过这种新方法,Kubernetes管理员可以导入所有预先准备的策略,开发者负责调整并根据需求自主选择策略,而所有这一切都会定义到pod中执行。

网络策略示例:

POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys/
{
 "kind": "NetworkPolicy",
 "metadata": {
 "name": "pol1"
 },
 "spec": {
 "allowIncoming": {
 "from": [
 { "pods": { "segment": "frontend" } }
 ],
 "toPorts": [
 { "port": 80, "protocol": "TCP" }
 ]
 },
 "podSelector": { "segment": "backend" }
 }
}

有网络策略定义的pod配置示例:

apiVersion: v1
kind: Pod
metadata:
 name: nginx
 labels:
 app: nginx
 segment: frontend
spec:
 containers:
 - name: nginx
 image: nginx
 ports:
 - containerPort: 80

结论

有了Kubernetes提供的功能,开发者现在拥有了完全定义应用程序及其依赖性所需的灵活性,并且可以在单个pod中使用多个容器。如果任何一个容器发生错误,Kubernetes能够确保将其对应的pod停用,自动用新的pod替换。此外,开发者还可以定义应用程序或者服务侦听的端口号,无论它是较大服务的一部分,或仅仅是一个独立实例。通过这样的操作,使用持续交付和部署方法论的快速开发和部署周期将会成为常态。

Kubernetes容器编排的三大支柱

RancherLabs阅读(1909)评论(0)

资源管理、调度和负载均衡作为K8s的三大支柱,它们是如何在K8s中实现的?它们又是如何相互作用,以提供高效的容器工作负载管理的?

每当谈及Kubernetes,我们经常听到诸如资源管理、调度和负载均衡等术语。虽然Kubernetes提供了许多功能,但更关键的还是要了解这些概念,只有这样才能更好地理解如何放置、管理并恢复工作负载。在这篇文章中,我提供了每个功能的概述,并解释了它们是如何在Kubernetes中实现的,以及它们如何相互作用,以提供高效的容器工作负载管理。

资源管理

资源管理是对基础设施资源的有效配置。在Kubernetes中,资源可以通过容器或pod来请求、分配或消耗。拥有一个通用的资源管理模型是非常必要的,因为在Kubernetes中,包括调度器、负载均衡器、工作池管理器甚至应用程序本身的许多组件,都需要有资源意识。如果资源利用不足,这就意味着浪费,意味着成本效益低下。如果资源被过度订购,可能会导致应用程序故障、停机或错误的SLA等。

资源以它所描述的资源类型的单位来表示。例如,内存的字节数或计算容量的毫秒级。Kubernetes为定义资源及其各种属性提供了明确的规范。

虽然,当今使用的主要资源类型是CPU和内存,但资源模型是可扩展的,允许多种系统以及由用户自定义的资源类型。其他类型包括网络带宽、网络操作和存储空间。

资源规格在不同的环境下具有不同的含义。在Kubernetes中指定资源的三种主要方式如下:

  • ResourceRequest指的是为容器或Pod请求的一组资源。例如,对于每个Pod实例,一个Pod可以请求1.5个CPU和600MB内存。ResourceRequest可以视为描述应用服务对资源的“需求”。
  • ResourceLimit是指容器或pod可以消耗的组合资源的上限。例如,如果一个pod在运行时使用了超过2.5个CPU或1.2GB的内存,我们可能会认为它由于内存泄漏或其他问题而变得“流氓”了。在这种情况下,以防干扰其他集群租户,调度器可能会考虑将pod作为驱逐的候选对象。
  • ResourceCapacity规范描述了集群节点上可用的资源量。例如,一个物理集群主机可能具有48个内核和64GB或RAM。集群可以由具有不同资源容量的节点组成。容量规范可以被视为描述资源“供应”。

调度

在Kubernetes中,调度是将pod (由调度器管理的基本实体)与可用资源相匹配的过程。调度器考虑资源需求、资源可用性以及其他用户提供的约束和策略指令,如服务质量、亲和性/反亲和性需求、数据局部性等等。本质上,调度器的作用是将资源“供应”匹配到工作负载“需求”,如下所示:

一些调度约束(简称FitPredicates)是强制性的。例如,如果pod需要具有四个CPU内核和2GB内存的集群节点,则该pod将保持在一个暂挂状态,直到找到满足此要求的集群主机为止。

在其他情况下,可能有多个主机满足强制性标准。在这种情况下,PriorityFunctions被视为反映调度首选项。基本上,调度器采用满足强制性FitPredicates的主机列表,根据用户可配置的优先级功能的结果对每个主机打分,并找到满足最大调度优先级数量的最佳优化配置方案。

在Kubernetes中,工作负载可以由数量不定的pod组成,每个pod都具有特定的资源需求。此外,工作负载和集群都是动态的,并具有伸缩性和自动扩展功能,因此,由于需要调度程序不断地重新评估位置决策,pod的数量可能会发生变化。另外,由于Kubernetes的功能类似于cron作业,调度器需要考虑的不仅是当前的供应、需求和集群状态,还需要考虑未来工作负载的预留容量。

把调度挑战想象成俄罗斯方块游戏,理解起来就不会那么难了。我们的目标是尽可能紧密地打包所有部分(有效利用资源)。但是,它们是多维的(需要特定的内存、CPU、标签选择器等等),而不是二维的游戏片段(pod)。无法匹配游戏的部分类似于无法运行的应用程序。游戏板不是静态的,它随着主机进出服务和服务规模的变化而变化。这就是Kubernetes调度的挑战。

负载均衡

负载均衡最终涉及将应用负载均匀地扩展到可变数量的集群节点上,以便有效利用资源。应用程序服务需是可伸缩的,即使关闭单个节点或组件出现故障仍可访问。负载均衡与调度相比是另一个不同的挑战,但这两个概念具有关联性。

Kubernetes依靠pod的概念来实现水平伸缩。提示:pod是与在同一主机上运行的应用程序功能相关的容器集合。要实现可伸缩,共享一个公共标签的多个pod将跨多个集群主机运行。复制控制器负责确保应用程序中目标数量的pod正在运行,并根据需要创建或销毁pod,以满足此目标。每个pod都将在集群上拥有自己的虚拟IP地址,并可以随时间而变,这就是服务的切入点。

Kubernetes的服务抽象出一组pod,提供了一个网络端点。因为服务IP地址(如pod)具有仅在群集内可路由的IP,所以服务通常与入口资源耦合,提供了将外部IP地址和端口代理到服务端点的方法。这就使应用程序可用于外部世界。尽管在Kubernetes(包括使用云提供商提供的负载均衡器)中实现负载均衡有多种方式,但最通常使用的方式是上文介绍的涉及入站和服务的方式。

总结

这一切与调度有什么关系?如上所述,通过pod的自动可伸缩功能,通过观察到的CPU使用率动态,Kubernetes可以据此调整由复制控制器管理的pod数量。控制器定期查询资源指标API以获取每个pod的利用率,将其与创建自动伸缩控制器时指定的目标CPU利用率进行比较,并根据结果指示复制控制器来调整pod副本的目标数量。

其结果是负载均衡和调度之间交互作用。当外部客户端创建负载时,通过入口访问应用程序服务,pod所使用的CPU将会增加或下降。超出某些阈值,自动伸缩控制器将与复制控制器和调度程序进行交互,根据负载调整pod数量。该服务将会提供修改后的pod数及其位置,因此,pod数可能已经改变的事实对内网客户和外部客户来说是透明的。

平衡资源需求与应用需求的微妙之处就在于自动伸缩控制器、复制控制器和Kubernetes调度程序在资源需求、供应、约束和优先级方面的持续性的互相协调。所有这些都是在客户端应用程序意识不到的情况下进行的。Kubernetes之所以成为容器化的工作负载领域广受欢迎的编排解决方案。就在于它能够高效、透明和可靠地执行这些操作,以便应用程序正常运行。

了解更多关于Kubernetes的信息,以及如何在Rancher上实现Kubernetes,可下载电子书《Deploying and Scaling Kubernetes with Rancher》

3个开源项目让Kubernetes使用更容易

中文社区阅读(2193)评论(0)

译者注:本文介绍Heptio、Kubed和Kubicorn开发的配套工具,它们旨在填补Kubernetes在集群状态管理,快照,灾难恢复方面的空白。以下为译文:

Kubernetes无疑是容器化领域里一个优雅的解决方案。 Kubernetes能够让我们大规模地运行容器化应用程序,而不用淹没在负载平衡,网络容器,确保应用程序的高可用性或管理更新或回滚的细节上。许多复杂性被安全地隐藏起来。

但是使用Kubernetes并不是没有挑战。Kubernetes的启动和运行需要一些工作,许多围绕Kubernetes的管理和维护任务是很棘手的。

即便Kubernetes社区发展很活跃,我们也不能指望Kubernetes主体项目能立即解决每个问题。幸运地是,Kubernetes社区正在对那些Kubernetes团队由于种种原因没有关注到的问题找寻解决方案。

下面是3个新涌现出来的Kubernetes项目,目的是使操作人员不再那么难以部署,维护,操作和监督容器。

Kubed

AppsCode,一个针对容器应用开发的协同编码平台供应商,最近发布了一个项目来填补Kubernetes集群管理方面的许多空白。

Kubed–发音为“Cube-dee”,是“Kubernetes守护进程”的简称,它将一大堆有用的功能整合到一个守护进程中。 Kubed可以执行定期集群快照,为已删除的对象提供临时存储(万一你需要再次使用它的话),执行自动事件转发,通过各种渠道发送通知等等。

Kubernetes也可以在Elasticsearch或InfluxDB的实例中存储日志数据,但清理旧数据是用户自己的责任。一个Kubed的功能,janitors,可以在指定的时间段之后自动清除日志数据。 Kubed还不支持执行这种清理的‘干运行’功能,但是添加该功能的请求已经被提交。

Kubed项目目前处于alpha、不稳定的状态,未来计划有许多突破性的变化。这些计划包括支持 Kubernetes最近推出的自定义资源定义(CRDs)和通过Kubernetes提供的用户API 服务器来将Kubed API作为Kubernetes扩展API集使用。

Heptio

两位从原谷歌Kubernetes开发团队离职的员工创建了Heptio,旨在使Kubernetes更易于使用。和其他旨在提供自己Kubernetes发行版本公司不同的是,他们注重在源头上提供开源工具来提升Kubernetes的使用效果。

本月早些时候,Heptio发布了第一批项目,Heptio ArkHeptio Sonobuoy。Ark是Kubernetes 集群的灾难恢复系统–一种基于容器的集快照、备份和恢复于一体的应用程序。Ark记录了Kubernetes API对象和持久存储卷(PV)的状态。Ark的默认示例使用和S3兼容的存储服务(“Minio”),但Ark也可以使用其他主要云提供商的存储服务–比如亚马逊的AWS,谷歌的云平台和微软的Azure。

Ark现在还没有提供一个在不同环境之间随意切换现有Kubernetes集群的解决方案。对此,Heptio解释说,Ark需要在不同的云提供商之间支持持久存储卷快照的迁移,目前尚不支持这一功能。

另外一个项目,Sonobuoy,用来检查给定的Kubernetes安装,看它是否能通过用于验证 Kubernetes发布版本的测试。

Kubernetes的部署通常会被供应商或用户做大量修改,这可能会使他们与更新不兼容。Sonobuoy的工作是去发现这些更改是否引起了不兼容。集群的状态也可以导出并用于诊断报告,Sonobuoy的测试也可以通过一个插件架构来扩展。

Sonobuoy仍在早期的开发阶段,不过,它不能检查Kubernetes一致性测试中标识出的所有问题。它的长期计划是和由Kubernetes核心团队创建的测试集保持同步。

Kubicorn

Kubicorn项目旨在帮助用户在各种云服务中构建和管理Kubernetes的基础设施。 像Puppet和其他用于管理基础设施的现代化工具一样,Kubicorn采用了声明式理念:用户描述他们想要在其集群中看到的状态,Kubicorn确保集群的状态与该目标一致。

Kubicorn旨在可以作为一个独立工具来使用,同时也可以作为其他工具调用的库来使用。 同理,Kubicorn利用了Kubernetes的现有工具,例如kubeadm工具。 因此,Kubicorn旨在补充现有的工作流程,而不是替代它们。

Kubicorn采用的方法主要是使用快照。Kubicorn通过允许用户定义其集群的状态,检查该状态是否符合原子性(如果不符合,它将被回滚),并将该状态捕获为快照。这些快照也可以用于新的部署。

请注意,Kubicorn不是官方的Kubernetes项目,它仍然被认为是实验性的,不应该在生产环境中使用它。

但是当然,试验Kubernetes的时机已经成熟了。你可能也想试试Kubicorn,Kubed和Heptio。

Kubernetes 稳定版发布两年,代码提交次数破5万

中文社区阅读(2040)评论(0)

占据容器调度工具龙头的Kubernetes,距离1.0版发布已达2年之久。现在该项目在GitHub上的提交次数总共已经破5万。参与Kubernetes上游项目开发的CoreOS,也揭露了几个数据,显示该项目生态圈的大小。CoreOS社区经理Elsie Phillips表示,在过去一整年内,代码提交次数总共有3万3千次,代码贡献者也新增了2,500名。而开发者上传的Issue则多了122%。

让我们一张图来了解过去一年Kubernetes取得的成就:

了解更多

容器技术标准化大统一,首个开放容器标准 OCI 1.0 正式发布

中文社区阅读(1222)评论(0)

在2015年,由Docker、IBM、微软、红帽及Google等厂商所组成的OCI联盟成立,并于2016年4月推出了第一个开放容器标准。除推出OCI Runtime标准,让开发者打包、部署应用程序,并可以自由选用不同的容器Runtime外,还推出开放容器OCI镜像标准,由容器技术社区制定规范,确立容器镜像建立、认证、部署以及命名的方式。而在近日,第一个标准OCI 1.0版终于正式出炉,而OCI联盟执行总监Chris Aniszczyk表示,此标准也意味容器离标准化更近一步。

Chris Aniszczyk表示,在过去几年间,容器技术的使用率,以及企业对此技术的兴趣都有着快速成长,而大型科技公司、云端服务商也纷纷推出相关的容器解决方案,为了让容器技术能继续作为应用程序可携性的基础,必须推出特定标准,确保这项技术的中立性。

在发布这个开放容器标准后,Chris Aniszczyk表示,为容器技术在生存环境落地时,带来基本的开放标准,包含了容器镜像格式以及Runtime规格的标准,他也认为,推动此标准,可替企业解决容器在各环境互通性的难题,也为创新带来更多动力。

各核心厂商的重要人士,也发表各自对于OCI 1.0版的想法。Kubernetes项目共同创办人Brendan Burns表示,OCI达到一个重要里程碑,透过开放标准,容器技术可替分散式云端运算带来革命性改变,此标准也替Kuberntes这类系统带来了基础建构元件。而CoreOS技术负责人Brandon Philips表示,OCI为Runtime及镜像建立了标准,有助于替成长中市场带来稳定性,让企业能放心采用容器技术,我们也跟K8s社区一同合作,要让OCI标准整合至未来发布的版本中。红帽容器技术架构首席工程师Vincent Batts则表示,在OCI成立两年后推出了第一个标准,不过这仅是该组织的第一步,未来在容器的生命周期、调度等项目还会更多合作。

而OCI联盟之中的发起者Docker,也揭露在OCI的未来发展动向。在此次发布为Runtime及镜像建立标准,OCI联盟下一个目标,就是要推出一个认证计划,确保这些厂商发布产品、项目,的确符合OCI制定的标准。