行业头条

在之前的文章中，我们从容器OS、容器引擎，基础架构的容器网络、存储、安全，容器运行必不可少的镜像仓库、编排，及运维关注的监控、日志，多维度关注并解读了容器生态圈中的各个玩家。总体而言，较为活跃的有Google主导的kubernetes生态，和Docker公司主导的docker生态。选择哪个技术流派从某种意义上，也决定了选择哪种生态，这也是当前使用容器的公司面临的一大难题。

本文将从容器引擎为切入点，说明这两大流派的历史、初衷和技术对比。

容器引擎玩家知多少

看到这个标题，你的表情可能是这样滴[惊愕]：纳尼？容器引擎不就是docker么？这时，CoreOS可能在后面默默地流泪，因为CoreOS的rkt也是玩家中的一员。虽然目前Docker的容器使用者相对更多，但rkt的发展也不可忽视。

Rocket与Docker 引发的站队

前世

这里让我们先来八一个卦，故事要从2013年开始说起。是的，Docker公司在2013年发布了后来红遍大江南北的docker产品，一场新的技术带来一次新的革命，也带来新的市场机遇，CoreOS也是其中的一员，在容器生态圈中贴有标签：专为容器设计的操作系统CoreOS。作为互补，CoreOS+Docker曾经也是容器部署的明星套餐。值得一提的是，CoreOS为Docker的推广和源码社区都做出了巨大的贡献。

然而好景不长，CoreOS认为Docker野心变大，与之前对Docker的期望是“一个简单的基础单元”不同，Docker也在通过开发或收购逐步完善容器云平台的各种组件，准备打造自己的生态圈，而这与CoreOS的布局有直接竞争关系。

2014年底，CoreOS的CEO Alex Polvi正式发布了CoreOS的开源容器引擎Rocket（简称rkt），作为一份正式的“分手”声明。当然，Docker的CEO Ben Golub也在官网作出了及时回应，总体意思表明没有违背初心，但这些都是应用户和贡献者的要求而扩展的，希望大家能一起继续并肩作战。

今生

当然，我们都知道了后来的事实，作为容器生态圈的一员，Google坚定的站在了CoreOS一边，并将kubernetes支持rkt作为一个重要里程碑，Docker发布的docker 1.12版本开始集成了集群swarm的功能。作为相亲相爱的一家人，Google于2015年4月领投CoreOS 1200万美元，而CoreOS也发布了Tectonic，成为首个支持企业版本kubernetes的公司。从此，容器江湖分为两大阵营，Google派系和Docker派系。

而CoreOS除了Rocket和CoreOS外，也提供类似dockerhub的Quay的公共镜像服务，也逐步推出容器网络方案flannel、镜像安全扫描Clair、容器分布式存储系统Torus（2017年2月在对应github项目上表示停止开发）等优质的开源产品，包括早期的etcd，各个产品都和kubernetes有了很好的融合。

CNI&CNCF

在两大派系的强烈要求（对撕）下，2015年6月，Docker不得已带头成立了OCI组织，旨在“制定并维护容器镜像格式和容器运行时的正式规范（“OCI Specifications”），以达到让一个兼容性的容器可以在所有主要的具有兼容性的操作系统和平台之间进行移植，没有人为的技术屏障的目标 （artificial technical barriers）”。在2016年8月所罗门和Kubernetes 的Kelsey Hightower的Twitter大战中，所罗门透露出对容器标准化消极的态度。

有意思的是，同年（2015年）7月，Google联合Linux基金会成立了最近国内容器厂商陆续加入的CNCF组织，并将kubernetes作为首个编入CNCF管理体系的开源项目。旨在“构建 云原生 计算并促进其广泛使用，一种围绕着微服务、容器和应用动态调度的以基础设施架构为中心的方式”。陆续加入CNCF的项目有CoreDNS，Fluentd（日志），gRPC, Linkerd（服务管理），openTracing，Prometheus（监控）。

Docker与Rocket的半毛钱关系

为了表示本文真的是篇技术型文章，也来说说Docker和Rocket的一些对比。

Docker和Rocket目前都遵循OCI标准，但两者对容器引擎的设计初衷有较大差异：

功能边界

总的来说，CoreOS认为引擎作为一个独立的组件，而Docker目前已发展成为一个平台，这也是CoreOS推出Rocket的官方原因之一。从功能角度来对比，Docker提供了日志、镜像和管理，甚至在1.12版本集成了swarm集群功能。而Rocket（rkt）的边界为在Linux系统上运行应用容器的功能组件。

表1 常用功能对比

		Docker	rkt
常用功能	镜像下载	docker pull	rkt fetch
	镜像提交	docker push	N/A
	镜像提交	docker commit	Acbuild (appc 工具)
	日志查看	docker log	N/A
	容器运行	docker run	rkt run
	容器启停	docker start/stop	rkt stop
	集群管理	已集成swarm	CoreOS的Tectonic提供此功能
当前版本（2017.3.20）		v17.03.0	V1.25.0

容器安全

容器安全也是CoreOS一直诟病docker的地方，docker自1.10后的版本在安全性上也在不断增强。以下从容器的安全方面，包含镜像、系统、容器运行时三部分横向对比。需要说明的是，镜像安全中镜像扫描也尤为重要，Docker Cloud和DockerHub提供在线漏洞扫描，CoreOS也提供了Clair开源项目对接CVE库进行镜像的漏洞扫描。

表2 安全对比

		docker	rkt
镜像安全	镜像签名	默认无签名验证，可设置签名验证	默认强制验证签名
系统安全	Linux系统安全策略	Namespace隔离性， Cgroups配额资源限制， Capability权限划分，SELinux/AppArmor访问控制权限。	Namespace隔离性， Cgroups配额资源限制，Capability权限划分，SELinux/AppArmor，TPM（Trusted Platform Module）
运行时 安全	容器隔离	由其他方案和厂家提供	支持KVM虚拟机中运行pod时，基于OS内核级和hypervisor级的隔离，非容器宿主机的cgroups和namespace隔离。

兼容性

除了两者在功能和安全上的对比，为了用户方便评估，在兼容性上也稍作比较。可以看到，发布较晚的rkt在对Docker兼容性方面采用包容的态度，且rkt和kubernetes保持一致，基本运行单元为pod。

表3 兼容运行单元对比

	Docker	rkt
镜像兼容型	支持使用Docker镜像运行容器	支持使用Docker镜像，OCI镜像运行容器
基本运行单元	基本支持单元为容器	基本执行单位为pod，支持kubernetes， Nomad
标准和规范	支持CNI规范	支持AppC规范，CNI规范

总结

本文从历史的角度说明rkt的由来，及引伸的技术流派问题。同时，也对Docker和rkt从设计（功能、安全和兼容性）的初衷进行简单对比。如果单从Docker和rkt社区相比，Docker目前热度更高，但后续如何发展，与其说是简单的Docker和rkt对比，倒不如说是两大技术流派的选择。

对于容器引擎的选择，虽然rkt在安全和兼容性设计上更胜一筹，但当前用户使用Docker较多，笔者分析主要也是以下原因：

1. 安装便利性。对于企业常用的OS，在CentOS中进行yum和Ubuntu中进行apt-get，即可方便安装；同比，目前CoreOS官网信息表明，rkt针对CentOS版本还不能使用在生产环境中，对ubuntu也没有发布对应的安装包。另外，对于国内的网络环境，笔者科学上网后几经波折才下载到rkt的release版本。
2. 社区活跃度。从两者在github中的数据，可以看到Docker社区无论在贡献者数量和提交次数上都比rkt社区要多，一定程度上也说明了两者用户的使用数量。这点和两者首个版本发布的时间有很大关系。

鉴于以上，建议容器平台使用者和学习者目前可以优先考虑Docker作为容器引擎，或是直接使用容器相关厂家提供的从容器引擎到容器云平台的整体解决方案。对于需要基于容器进行二次开发形成产品的容器厂家，尤其是基于kubernetes提供服务的厂家，建议同时对rkt保持关注。

编者按：2017年OpenStack峰会（5.8-5.11）正在如火如荼进行， OpenStack和Kubernetes的“相爱相杀”正在陆续上演，K8s可谓抢尽本届峰会的风头，成了不折不扣的主角。虽然大多数美国分析师都认为可以通过大会讨论出未来方向和结果，但笔者认为真正的结果在企业用户心中。只有实际成功的案例才能真正说明二者微妙的关系，正所谓“黑猫白猫，能抓到老鼠的猫，才是好猫”。

2017 OpenStack Summit大会正在如火如荼的进行，在会议开始之前，这三行问题就已引人关注：

1. “OpenStack on Kubernetes？
2. Kubernetes on OpenStack？
3. How about Kubernetes on OpenStack on Kubernetes？”

以下是分组会议的话题清单，我们似乎可以从中看出些什么：

• Kubernetes和大规模OpenStack；
• 企业采用Kubernetes和容器；
• OpenDaylight Kubernetes和OpenStack Magnum集成；
• ESCaaS 4.0，OpenStack和Kubernetes的统一管理平台；
• 混合云Kubernetes。

没错，一个非常明确的重点：Kubernetes。

2017年，OpenStack在全球范围内的企业数据中心正获得越来越多的部署。OpenStack最初的存在是为了让私有云基础设施能够像公共云一样方便快捷地支持应用程序。回顾OpenStack这些年所遇到的需求和面临的挑战，似乎都通过使用Kubernetes得以解决。

相关组织做了一次问卷调查，调查数字表明，使用OpenStack的受访者中，84%的人很高兴讨论他们在什么行业，他们负责什么方面的工作，但很多人不热衷于回答问卷中最重要的一个问题：“你用什么容器或PaaS平台工具来管理你的应用程序？”

在少数回答了这个问题的人中，大约43％的人表示他们使用Kubernetes来管理他们的应用程序，而其他选项（包括Swarm和Mesos）都低于该数字。

为什么？

峰会这几天，所有人都在围绕这三大问题展开讨论:

1、Kubernetes真的能成为OpenStack的实际应用程序服务管理组件？

如果这个问题换成“OpenStack和Kubernetes在私有云部署中分别扮演什么角色？”那就可以简单地回答说，“OpenStack管理基础设施，Kubernetes管理容器，”

OpenStack的文档指出：Magnum是一个OpenStack项目，它提供容器编排引擎来进行部署和管理。将Magnum与Kubernetes、Swarm或Mesos集成在一起，是一个非常好的思路。

认真的工程师必须提出这个问题：怎样的整合才是最可取的？

2、OpenStack名声大噪，却难以部署和管理吗？

据悉，OpenStack基金会在其4月调查报告中承认，用户的反馈集中在安装方面缺乏一致性，缺乏共同的生命周期管理工具，缺乏自动化部署系统，缺乏标准化升级过程，缺乏对BUG修复的关注，以及几乎所有工作流程中都有难以估量的步骤数量，这些都是OpenStack用户们强烈反馈的问题。

3、谁是OpenStack的领导者和推动者？

几年前，分析师们认为OpenStack重要性是显而易见的，否则惠普就不会投入如此多的资金来推动它。后来，当惠普退出时，一些分析师又宣布OpenStack将走向死亡。

但是很少有人注意到：获得惠普OpenStack业务的SUSE Linux可能更适合惠普向他的客户们提供这些服务。

大多数市场感知中存在着现实，在分析师眼中，该平台的方向即将明确，但对于大多数客户来说，由供应商和小团队供应商提供的案例才最具吸引力。

峰会热切进行中，OpenStack仍然是软件历史上最前所未有的集体努力者之一，相比之下，部分Linux的成功可能才是偶然的。

原文链接：

https://thenewstack.io/openstack-summit-2017-will-kubernetes-stealing-show/

Docker于 2013年推出以来，给软件开发带来了极具传染性的振奋和创新，并获得了来自各个行业、各个领域的巨大的支持——从大企业到初创公司，从研发到各类IT人员，还有开源社区、ISV、最大的公共云供应商、软件堆栈上的每个工具等。自Docker推出以来，许多重大的里程碑事件都推动了容器革命。让我们就其中一些作个简要回顾。

容器编排工具的选择

容器入门非常简单。所需要的仅是笔记本电脑和Docker客户端。然而，运行微服务应用程序则要另当别论。其中最困难的是创建、管理和自动化临时容器集群。

解决这一挑战的第一个主要工具是Mesos及它的编排工具Marathon。即使在Docker之前就已经提供了分布式基础设施，Marathon也可以在Twitter和其他大型Web应用程序中的生产工作负载中使用。

下一个得到广泛认同的编排工具是Kubernetes。事实上，如今Kubernetes因为它的可扩展性已经领先于Docker编排工具。它支持广泛的编程语言、基础设施选项，并获得容器生态系统的巨大支持。它将应用层与基础设施层隔离开来，从而能够跨多个云供应商和基础设施设置，实现真正的可移植性。

Docker Swarm随后也加入了容器编排领域，并且其覆盖率已经迎头赶上。Swarm很容易上手，并且能与Docker平台的其他部分很好地集成。初步迹象表明，这一竞争已经改变了Kubernetes。

对企业而言，编排工具是容器应用成功的关键。尽管这三个选择都不差，但您应该根据您的需求做出最合适的选择。

容器安全快速发展

在初期，容器默认的隔离性较弱。随着时间的推移，这一情况正在发生变化。与容器安全相关的一个关键进展，是出现了多个能力强大的容器 registry。registry通过存储和扫描容器镜像和存储库来发现漏洞。这是Docker安全性的重要组成部分，因为未经验证的发布商提供的公开存储库，极容易带来安全威胁。这也是开放的生态系统的缺点之一，因为在开放的生态系统中，镜像很容易共享。但使用 registry进行安全检查可以减少这种风险。

Docker Hub是大多数Docker用户开始使用的默认registry，也是目前最流行的。主要的IaaS提供商都有自己的registry。这很有必要，尤其是如果您大量投资AWS、Azure或Google Cloud。它们具有默认的存储库扫描功能、更成熟的访问控制，以及一系列用于联网、存储和监视的其他工具。除此之外，像Quay和GitLab容器 registry这样的第三方 registry也越来越受欢迎。registry的选择比编排工具多得多，市场也很开放。

除了 registry之外，TwistLock和Aqua security等第三方容器安全服务商也提供了超出默认值的安全性。

适用于Windows和Mac的原生Docker客户端

Docker最初是一种基于Linux的技术，它依赖于Linux内核中内置的特殊功能（这些功能只能在Linux上可用，而非其他类似Unix的内核）。如果要在Windows或Mac上运行Docker，则必须使用虚拟机引擎（如VirtualBox）和基于Linux的虚拟机来托管Docker环境。对于那些想在Windows或Mac机器上测试Docker应用程序的开发人员来说，这个设置非常方便，但作为Docker服务器部署解决方案却不实用。

2016年初，随着原生Docker对Windows的支持，情况发生了变化。这是一项重大进展，因为许多企业工作负载在Windows Server上运行。在这些环境中使用Docker的需求很强劲。

目前， Docker在Windows上本机运行时，仍存在一定局限性。网络尚未完全实现，仅支持Windows Server 2016和Windows 10。但是，Docker已经支持原生Windows，这一进展已经为Windows生态系统中的Docker提供了大量的新机遇。

内置VS开源Docker组件

Docker公司已经建立了企业版（包括Docker Datacenter，它现在已经集成到Docker的新企业版平台中），它们由Docker本身的组件组成，其中包括Swarm管理器，而Docker Engine并未内置这些组件。Docker对使用自己的工具来建造容器堆栈更感兴趣，而不是与容器生态系统中的其他组织合作，最初引起了一些人的担忧，即Docker将忽略社区标准。去年八月份，出于这方面的担忧，他们甚至还谈到了forking Docker。（不过至今并没有谁真的fork了Docker。）

最近，随着Docker采取措施向客户保证它不会垄断行业，这种紧张局势已经平息。它对CNCF的积极贡献，包括最近将底层的容器技术开源，都是朝这个方向发展的。在上个月的DockerCon大会上，该公司通过将代码转移到Moby项目，并引入LinuxKit，从而使它的主要项目更模块化，更便于社区访问。(此文分析了这些变更对Rancher Labs、Rancher产品以及各种各样用户的影响)

当然，Docker仍然有批评者。但相比一年前，Docker技术栈明显更加开放，并能与其他生态系统更好地集成。

结论

容器生态系统仍然在不断发展与改变。也许当我们刚弄清楚Docker对于跨所有类型组织的应用程序意味着什么时，新的标准又出现了。本文所强调的趋势是一个快速成熟的生态系统的指标。最值得关注的，是在这一领域中，Docker和各个供应商是如何进步，以推动容器生态系统的发展的。

根据 451 Research，2016年，容器技术市场产生了7.62亿美元的收入。到2020年，分析公司预测，容器的年度收入将达到27亿美元，复合年增长率为40％。

容器市场大好，但是我们面临两个问题：如何确保这些容器的安全性？以及如何部署管理它们？

想要解决问题。首先，我们需要建立——

容器策略：您希望在哪里运用容器？每个 CPU 应分配多少个？ 所有这些问题，都可以通过设置正确的容器策略进行回答。

互操作性：当然，他们应该与您现有的 IT 管理工具协同运作。

OK，在有了明确的需求之后，我们就可以对目前主流的容器编排工具——Kubernetes、Mesosphere Marathon 和 Docker Swarm 进行进一步筛选，他们都可以在不改变原有架构的情况下对容器进行编排管理。

Docker Swarm

如果你刚开始接触容器，最初了解到的应该是 Docker，作为很多人的入门级容器，它吸引了大量的用户。 而 Swarm 是 Docker 本地的编排工具，算得上是 Docker 本地的集群管理器。

Docker Swarm 在2016年6月（1.12）版本中将其功能整合到完整的 Docker 应用程序中，并花了大量的精力来解决启动和运行。虽然几个新产品有启动问题，比如服务发现程序（例如 Consul 或 CoreOSetcd）是在 Docker Swarm 启动之前运行。Sysadmins 发现这个问题很难解决，即使解决这些启动问题，也还是需要花费大量的精力部署 Swarm。

所以，即便新的 Docker Swarm 努力获取用户，但目前它仍然落后于 Mesosphere 的中央操作系统（DC / OS）和 Kubernetes，但是谁能保证以后不发生变化呢？ 毕竟新改进的 Docker Swarm 确实在部署的便利性上有了提升。 我之前跟几个 DevOps 谈过，他们认为，与 Kubernetes 或 Mesos 集群相比，Docker Swarm 是一个快进版本。

所以，如果你已经是一个有经验的 Docker 用户，Swarm 的学习曲线对你来说就很容易。 Docker Native Orchestration 使用单节点 Docker 概念，并将它们扩展到 Swarm。 但一旦你有在运行的 Docker 节点，Swarm 的设置就十分繁琐。 例如，您可以使用单个 shell 命令将 Docker 实例添加到 Swarm 集群。 更新的 Swarm 还支持滚动更新，包括节点之间的传输层安全加密，以及简单的负载平衡和相对容易的服务抽象。

目前，Swarm 还有改进的余地。 例如，它当前不支持运行状况检查和自动回滚。 Swarm 用户也抱怨很多实现问题。例如， Swarm 不能正确支持多主机容器网络等。

Docker Swarm 是内置在 Docker 中的，这应该是它最大的吸引力。 不过，潜在用户应该注意的是，它就是一个运行的工作，而不是一个立马能解决您容器部署和管理问题的解决方案。

Mesosphere Marathon

Marathon 是一个用于 Mesosphere DC / OS 和 Apache Mesos 的容器编排平台。 DC / OS 是基于 Mesos 分布式系统内核的分布式操作系统。 Mesos 也是一个开源集群管理系统。 Marathon（通过其合作伙伴计划，Chronos，容错作业调度程序）提供有状态应用程序和基于容器的无状态应用程序之间的管理集成。

Marathon 的出现实际上早于容器。 Mesosphere 联合创始人和首席技术官 Tobias Knaup 在最近的一次采访中解释说，“Marathon 从一开始就被设计为一个通用的工作负载管理器，甚至在 Docker 出名之前。 他们的目标是建立一个桥梁，连通旧世界到新世界，使现有的应用程序可以部署和扩展，不需要进行太大的变化。“在 Knaup 看来，无论它是不是一个现代应用程序架构（如微服务或更传统的三层企业应用程序），至少它非常适合长时间运行。

Marathon 有一个用户界面，您可以将其视为一个应用程序，它可以看作一个框架来管理容器。这涉及DevOps 的开发人员方面，因为容器通过 REST API 与 Marathon 一起工作。

Marathon 具有许多功能，包括高可用性，服务发现和负载平衡。 如果在 DC / OS 上运行它，您的应用程序也会获得虚拟 IP 路由。

作为一个更成熟的项目，Marathon 没有 Docker Swarm 的初期问题。 另一方面，Marathon 有一个更陡峭的学习曲线。 由于 Marathon 只能在带有 Mesos 的软件堆栈上运行，这增加了另一层的复杂性。最后，一些功能（例如身份验证）仅适用于 DC / OS 上的Marathon。 这为你的堆栈又增加了一个抽象层。

Kubernetes

Kubernetes（也就是 K8S），起源于 Borg。（开源之前，Kubernetes 的名字叫做“项目7”，是 Borg 的友好版本）。

Google 在创建 Kubernetes 中的作用并不令人感到惊异。很久以前 Docker 使得容器流行起来，Google 的很多项目——搜索、Gmail、Google 文档都使用了容器技术。 Borg，以及和它的开源的继承者 Kubernetes，管理着数十亿个容器。

Kubernetes 自推出以来，就被移植到 Azure，DC / OS 以及几乎所有叫得出名字的云平台。 唯一的例外是 Amazon WebServices（AWS）。 即使在那里，CoreOS 也让用户在 AWS 上部署 Kubernetes 集群。

Kubernetes 有巨大的供应商支持。 今天，Kubernetes 由 Linux 基金会托管。 此外，还有来自众多公司的 Kubernetes 发行版，包括Red Hat OpenShift，Canonical 公司的 Kubernetes 发行版，CoreOS Tectonic 以及英特尔和 Mirantis。

为什么？ 除了证明自身在 Google 的大型数据中心，Kubernetes 拥有自我修复，自动化推出和回滚和存储编排。功能列表还在继续更新。 简而言之，无论你想用你的容器做什么，Kubernetes 都可以对它进行管理。

互操作性也是 Kubernetes 一个巨大的亮点。 Sam Ghods 是基础架构即服务（IaaS）云提供商 Box 的联合创始人，他称赞 Kubernetes，他说：“我可以编写一个 JSON 规范，并将其提交给任何地方运行的任何 Kubernetes 集群，还能够重新创建正确的拓扑和完全正确的我需要的基础设施。”

Kubernetes 的另一个优点是“对每朵云的友好性，”软件工程师 Erez Rabih 说，“你可以在 AWS，GoogleCloud，Microsoft 的 Azure、Rackspace 上运行你的集群。”事实上，Kubernetes 开发人员的短期目标是使你能够运行 Docker 容器，由 Kubernetes 管理，同时在多个云架构上使用群集联盟。

当然，Kubernetes 并不是完美的。 首先，它有两个问题。 第一，负载平衡很困难。 到最后，Kubernetes 的进入将使得 Kubernetes 从内部运行到外部的负载均衡器变得容易，但这还是一个在逐步改进的工作。 第二，Kubernetes 擅长自动修复问题。 但它运行非常好，并且可以快速地对容器进行重启，以至于你不会注意到你的容器崩溃。 当然，为了解决这个问题，您需要添加一个集中式日志系统。

最后，这三种容器管理工具都与多个云平台配合使用，包括 OpenStack、Magnum 和 Azure 容器服务。

好了！在这么多分析之后，问题来了，哪一个平台最适合你呢？

Kubernetes 的首席工程师 Brendan Burns 显然坚持自己的偏爱，但他总结了这些容器管理系统之间的差异：“Mesos 和 Kubernetes 主要旨在解决运行集群应用程序的类似问题; 他们有不同的发展历史和不同的方法来解决这个问题。Mesos 的集中力量在通用调度，插入多个不同的调度器。“

相比之下，Burns 说，”Kubernetes 的设计理念是，构建分布式应用程序的环境。它包括用于复制和服务发现作为核心原理，而这是通过 Mesos 中的框架添加的。Swarm 是 Docker 努力扩展现有的 Docker API，使一群机器看起来像一个单一的 Docker API。

从支持视图和功能列表比较来看，赢家显然是 Kubernetes。 在 AWS 和 Docker 之外，所有人都支持它。

幸运的是，您可以混合和匹配这些程序，满足您公司需求。三者之间可以很好地进行协同工作。这不容易，但它是可行的 ——也许这也是探索三者之间哪个更适合你的最佳方式。

但是，和往常一样，最佳选择取决于您的具体需求。例如，如果你的公司有工作人员精通 Docker，可以选择运行在 Docker Swarm 上。因为假如它运行得很好，那为什么还要切换到另一个系统？ 况且 Docker 一直都会被使用。 Marathon 有它的优势，为你提供一种方式（虽然是多层次的方式）来处理你的容器和你的旧应用程序。

我无法给你一容易的“这才是真正的方式”的答案。你要逐一检查它们，来找出哪个容器管理工具或工具满足自己的需要。

我可以告诉你，如果你搬到容器，你肯定会需要这些程序。你也不想浪费你的时间来构建自己的容器管理工具的吧。

所以，选择哪个呢？ Good luck！

Kubernetes的2016年是野蛮生长的一年，遍布全球的数百位开发者纷纷投身到K8s的快速迭代中。越来越多的企业开始采用K8s支撑生产业务，实现了高可用的容器化微服务。与此同时，CNCF开始提供面向K8s项目的全球化服务，并分别在英国伦敦和美国西雅图召开了KubeCon。

发布全记录

今年Kubernetes经历了34次稳定版发布，发布次数相比2015年增加了112.5%，平均发布间隔为11天。2016年度K8s连同alpha版和beta版共计发布111次：

 

 

主要版本发布全记录：2016年3月16日发布1.2版，7月1日发布1.3版，9月27日发布1.4版，到12月14日发布1.5版：

 

 

火爆的社区

2016年Kubernetes社区非常火爆，Slack上的用户由2015年的2200发展到了10,768之多。而在Google Trends上排行也是一路飙升。

2016全年共有超过175家公司参与社区，705位贡献者提交了总计18,557次commits，K8s项目Go语言代码超2,552,778行：

 

 

贡献榜前三

在代码托管平台Github上，对Kubernetes项目的贡献进行统计后得出贡献榜前三：

 

 

按代码提交commits，分别是Wojciech Tyczynski，David Eads和Clayton Coleman：

他们的Github链接是：

• Wojciech Tyczynski: https://github.com/wojtek-t
• David Eads: https://github.com/deads2k
• Clayton Coleman: https://github.com/smarterclayton

按代码提交行数，分别是Chao Xu，Tim Hockin 和 Clayton Coleman：

 

 

他们的Github链接是：

• Chao Xu: https://github.com/caesarxuchao
• Tim Hockin: https://github.com/thockin
• Clayton Coleman: https://github.com/smarterclayton

年度概述

前Googles技术基础架构部门高级副总裁 Urs Holzle曾这样表示：“我就直说了，你想搞一个Borg的外部版本？可Borg是我们最重要的竞争力之一啊，我们甚至都不愿意对外谈起它，然后你居然告诉我你想要开源它？”

 

 

后记

2016年Kubernetes的版本更迭非常频繁，这也证明了社区的快速增长。Kubernetes的发展速度已经提高了两倍之多，并且丝毫没有减慢的趋势。

2016年行将结束，我们都很期待继续见证Kubernetes的2017年。节日快乐！希望能够在3月的德国柏林KubeCon上见到你。

译者说

Everyone is excited about Kubernetes. This is why we choose it : )

原文链接
原文链接：http://static.lwy.io/pdf/kubernetes_-_a_year_in_review_2016.pdf
原文作者：LiveWyer

简 介
在本系列中，我们涵盖了一些可以通过容器和Kubernetes管理解决的重要业务话题。 我们谈论了一个企业如何能够省钱，回答了为什么您的架构对您的底线很重要，而且，我们还讨论了如何使用Kubernetes和Supergiant让应用向容器化的基础设施迁移过程变得更加容易。

一、今天，我将展示如何计算使用Kubernetes后企业真正节约的成本

我们将累计通过一个配置良好的集群产生的真实的数据。 在我们的示例中，我们将使用Amazon Web Services服务，但是这些数字在许多云提供商中看起来类似。 您还能了解以何种方式可以达到您节省硬件成本的预期。
我将讨论在裸金属，虚拟机和Kubernetes上运行应用程序的成本。 当Kubernetes实施得很好时，其基础设施和支持节省将帮助您的业务降低价格，改善支持，并为您的客户提供更好的性能。

二、介绍我们的主人公

 

 

让我们设置一个虚构的场景。 Luh Elephant，Inc.是一家小型公司，使用AWS为客户提供按需的PostgreSQL数据库实例，客户对Luh提供的数据库服务非常满意。 然而，完整的实例变得昂贵，价格越来越高，因此客户已经开始关注他们的成本。

三、开始竞争！

很多竞争者也开始按需提供Postgre，但是价格更低。Luh Elephant, Inc.怀疑是使用容器、虚拟机器或者魔法的原因，但是他们也注意到竞争者们的糟糕的性能。为了更好的竞争，Luh Elephant想做出改变。
很多客户开始选择更便宜的，所以如何提供有竞争力的价格并且可以符合甚至超越当前的性能标准是一个难题。他们真的可以降低价格并提供顾客喜欢的体验和性能吗？

四、用数字回答!

首先，让我们看一下当前Luh Elephant, Inc.使用的基础设施。他们目前有300名顾客，并且前100名顾客使用高价的3服务器集群。在这个例子中所有的服务器都是4核的，而在现实中，客户群将更加多样化，但为了简单起见，先这样假设。

假设AWS m4.xlarge类按需实例，这是Luh Elephant，Inc.当前的硬件每月支出。

客户	服务器数	成本合计
200(一台服务器一组)	200	$34,894
100(三台服务器一组)	300	$52,341
		$87,235

五、预留实例的定价怎么样？

预留实例是降低成本的第一步，所以让我们计算一下。

理论上，预留实例在所有的实例上得到“一年，部分预付”定价，Luh Elephant可以降低它们41%的成本，达到$51,110每个月。然而，现实又向他们扔了一个弧线球：因为他们商业的不可预测性，他们不能预测并且为第二年预留所有的实例。

简单的转换到预留实例策略不能足够的降低成本。得到所有的节约成本但还不能解决问题，并且在一些例子中，竞争者的价格仍旧低了50%。即使完美的实施预留实例计划，数学依旧很受限制。

六、所以，还有什么其他的选择来降低成本？

一直折磨Luh Elephant的是一个常见的问题，也困扰着很多的机构：每个服务器一个主要的应用。从成本上来讲，当服务器没有很好的被利用或者大部分时间是空闲的时候很令人不安。将更多的应用程序压缩到服务器上以获得更多的价值，如果没有很智能的管理，将会导致各种性能和相邻干扰的问题。

所以，我们需要更好地利用我们支付的硬件，为了达到这个目的，我们有几个选项供选择。

选项1：预置虚拟机

这对于企业是一个高可行性的选择，所以我会详细解释。随着时间的流逝，预置的硬件可能是提供便宜计算能力最好的方式，然而，它也伴随有一些强大的障碍。运行预置硬件会带来硬件的花销，如硬件成本，管理硬件的优秀、高薪的工程师的花销。如果这些障碍不成问题，预置就是目前为止最好的解决办法了。

预置解决办法的准确节约的数字很难计算，因为节约的成本完全取决于执行。从经验来讲，我们希望Luh Elephant可以将基础设施成本降到$20,000每个月。但是记住这不包括额外的工程师工资，而且也不算前期资本支出。初始支出将很高，因为新硬件将需要预先购买。

对于没经验的公司，选择1不适合，至少还要很多年。他们没有资金去支付预置款，并且他们只有10名员工（在最初可能还没有这么多）。找到更加有才华的可能要花费几个月，这在他们竞争的市场中不是一个选择。

选项2：使用一个集群管理工具

硬件集群管理工具（如Mesos等）是很好的工具，但是它们不能解决“我想让我的应将更高效”的问题。虽然它们有助于减少高效运行大规模生产应用程序所需的知识，但是扩容管理是需要手工操作的，容易造成人为事故。此外，这些系统不会降低硬件支出，有可能会增加硬件支出。

然而，亲爱的读者，不要焦躁，我们还有一个选择。

选项3：用Kubernetes容器化

这对于我们的主人公是最完美的选择！在我们第一篇关于用Kubernetes节约资金的文章中，您可以很清楚的看到Kubernetes管理的资源种类。Kubernetes满足了想要统治他们的市场的、缺乏资金的公司的所有的要求。而且它不需要牺牲性能或用户体验。

另一个可能的选择是使用非Kubernetes的容器管理器。 这可能节省一点成本，但Kubernetes是目前唯一的有能力并做好动态分配资源的容器管理器。

七、所以，Kubernetes解决办法转化成现金是多少呢？

让我们分开来算。我们从之前的文章中知道您可以在Kubernetes中保守的设计一个资源规划，可以使您在硬盘中增加50%的资源消耗，并且这也是可以调节的。每个模块可以找到合适的比率使它最好的适用于它的应用，并且有令人满意的节约成本。50%-80%对于大多数状态性的应用是一个合适的开始。

客户	服务器数	旧方案成本合计	Kubernetes成本合计
200(一台服务器一组)	200	$34,894	$17,447
100(三台服务器一组)	300	$52,341	$26,171
		$87,235	$43,618

这就是我们所说的！这是一笔不错的节约。并且现在服务器计数更加可以预测了。我们真的可以比预留实例得到更好地使用：$25,605 (三年从41% 到大约 60%)。

用这种节约成本的方式，Luh Elephant, Inc.公司可以大幅度的降低价格，甚至比竞争者的价格更低，而且还是一样的性能！

这种基础设施模型还有一个额外的好处就是Luh Elephant, Inc.如果选择，现在可以使用甚至更大的实例了。在相同的AWS实例等级使用更大的实例，对于服务器成本几乎无影响，但是将会使他们的客户访问高价值的云功能，例如非常高的网络流通量，更高的存储速度和突发性。如果一个或多个用户临时超出了他们的使用限额，更大的实例可以提供更多的空间。所有的这些都使这家创业公司获得更多的其他竞争者可以提供的优势。

八、Supergiant在哪里开始发挥作用？

Kubernetes有时会令人畏惧，因此我们开发了Supergiant，让它在Kubernetes之上运行，它不会让Kubernetes 更难掌握—— 它只是将深层的Kubernetes功能带到表面，并使它们易于管理。

致谢与参考文献
原文链接：https://supergiant.io/blog/how-to-calculate-kubernetes-cost-savings
作者： Mike Johnston

在上一篇文章里，我讲述了让我热爱Kubernetes前5个理由（上）。2015年7月Kubernetes被捐赠给Cloud Native Computing Foundation，并开始接受数十个包括Canonical，CoreOS，Red Hat等公司的开发。

我的前五个理由主要来自Kubernetes项目的历史、易于使用的特点和强大的功能。后面的五个理由将更”干货“。在上篇文章里提到：选择一个要在数据中心中执行任务的分布式系统不像是在一个电子表格里寻找性能或特征那样简单。你应该按照团队的需求灵活决定。然而要注意，我所说的这个十个理由是我的观点，并且我正以此使用、测试和开发系统。

6. 滚动升级和回滚

滚动升级和回滚对于应用管理来说毫无疑问是必需品，尤其是当我们拥抱快速迭代的开发周期和持续改进的时候。一个拥有这些特性的系统，它的设计和运行往往很复杂。

部署资源在Kubernetes里被重新定义–起初Kubernetes拥有Replication Controller(RC)，它定义了Pods的声明式状态–例如哪个容器、我在我的系统里想要多少个容器等。但是通过RC实现的滚动升级发生在客户端，客户端关闭经常会导致错误。

所以，Kubernetes引入了Deployment这个资源，使用Replica Sets（多种资源重命名中的一部分）替换掉了Replication Controllers。每次一个deployment被用户定义之后，系统就会创建一个新replica set。对replica set的扩容和缩容造就了滚动升级和回滚的能力。确实，旧的replica set并没有被除，而是保留在系统中，作为Deployment历史的一部分。

Deployment的扩容和部署策略可以在显式的定义中进行修改。

这些所有的功能，都是被一个基于REST API的HTTP请求触发。

让我们看看一个简单的deployment历史：

$ kubectl rollout history deploymetn ghost
 deployments "ghost":
 REVISION CHANGE-CAUSE
 1 kubectl run ghost --image=ghost --record
 2 kubectl edit deployment/ghost

这里演示一下升级。我们可以通过`rollout undo`来进行回滚。它将增加历史中的修订（Revise）

$ kubectl rollout undo deployment ghost
 deployment "ghost" rolled back
 $ kubectl rollout history deployment ghost
 deployments "ghost":
 REVISION CHANGE-CAUSE
 2 kubectl edit deployment/ghost
 3 kubectl run ghost --image=ghost --record

底下的一行经过编辑一个Deployment，你执行了滚动升级。回滚是一个rollout undo，嗯，是这样，你可以回滚到一个特定的版本。

7. 配额

开源世界里过去的15年涌现了大量的业务模型（及变体），它们其中有些一直是某个商业组件（插件）的形式出现。

在Kubernetes里内置了配额。它们可以被用来限制API资源的数量，或限制例如CPU和内存的物理资源的使用。与Pods和Deployments相似，配额也是K8s里的API资源。你可以通过yaml或json文件进行定义，并且在你的集群里利用kubectl进行创建。

例如，为了限制在一个特定命名空间里Pods的数量为1，你可以定义如下的资源配额：

apiVersion: v1kind: ResourceQuotametadata:
 name: object-counts
 namespace: defaultspec:
 hard:
 pods: "1"

就像对其他资源一样，你可以通过kubectl get和 kubectl edit通过下面的两条命令查看和修改配额:

$ kubectl get resourcequota
 NAME AGE
 object-counts 15s

现在是单Pod运行，如果这时你继续创建新的Pod，K8s就会返回一个错误，告诉你超过了配额：

$ kubectl create -f redis.yaml
 Error from server: error when creating "redis.yaml": pods "redis"

配额是内置的一级K8s API。这真令人惊奇!

8. 第三方资源

这在大多数系统中是一个难以理解的新概念。

Kubernetes的设计哲学是它包含了一组用来管理容器化应用的API。可以预料到，在一段时间内这个核心将相对稳定。用户可能使用到的任何另外的API资源可能不会被加入到核心中，而是会被动态地创建。Kubernetes将管理它们，并客户端将动态地使用它们。这个技术曾被Pearson用来管理数据库。

这个例子我在LinuxCon上讲过，用来创建一个叫做pinguin的新的API对象。你可以通过第三方资源对象（ThirdParty Resource Object）进行创建。就像其他的K8s资源一样，它同样拥有metadata、apiversion、kind和一组versions的属性。metadata包含了一个用来定义新的资源组的名字：

metadata:
name: pin-guin.k8s.linuxcon.comapiVersion: extensions/v1beta1kind: ThirdPartyResourcedescription: “A crazy pinguin at Linuxcon”versions:- name: v1

让我们创建这个新资源：

$ kubectl create -f pinguins.yml
 $ kubectl get thirdpartyresources
 NAME DESCRIPTION VERSION(S)
 pin-guin.k8s.linuxcon.com A crazy pinguin at Linuxcon v1

通过这种方式，你可以自由地创建一个pinguin（保持LinuxCon主题）：

$ cat pinguins.yml
 apiVersion: k8s.linuxcon.com/v1
 kind: PinGuin
 metadata:
 name: crazy
 labels:
 linuxcon: rocks
 $ kubectl create -f pinguin.yml

并且动态地，kubectl现在意识到了你创建的pinguin。注意这个特性仅在k8s:v1.4.0中可用。

$ kubeclt get pinguin
 NAME LABELS DATA
 crazy linuxcon=rocks {"apiVersion":"k8s.linuxcon.com/v1", "kind":"PinGui...

现在你可以想象能用它做点什么了，结果是你需要编写一个控制器，用一段代码来监控pinguins，当它被创建、删除或修改时做出某些动作。

这个特性意味着Kubernetes的API Server现在可以被每个用户任意地进行扩展，棒呆了！

9. 基于角色的访问控制（RBAC)

除了配额之外，基于角色的访问控制也是一个企业级系统的必须。类似于配额，在数据中心解决方案里，它通常是一个经过考虑之后的想法，而不是一个商业组件。

对于Kubernetes，我们拥有细粒度的访问控制，它基于角色，并且最好的部分当然是，100%的API驱动。通过这个，我意思是角色和绑定都是API资源了，管理员可以在集群上编写和创建这些资源，就像用户创建Pods和Deployments一样。

它最初在v1.3.0版本里引入，它是一个alpha版本的API，仍被认为是实验的。但是多个发布版之后，我完全认为它是稳定的API了。

大致来说，你创建角色——API资源类型role，定义一些规则：

kind: RoleapiVersion: rbac.authorization.k8s.io/v1alpha1metadata:
 namespace: default
 name: pod-readerrules:
 - apiGroups: ["api/v1"]
 resource: ["pods"]
 verbs: ["get", "watch", "list"]
 nonResourceURLs: []

然后你将用户和角色进行关联，通过创建绑定资源RoleBinding完成。一个绑定，就是一组用户，将他们和角色结合。一旦你创建了绑定，系统任何用户都会继承来自这个角色的访问规则。

kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1alpha1metadata:
 name: admin
 namespace: defaultsubjects:
 - kind: ServiceAccount
 name: defaultroleRef:
 kind: Role
 namespace: default
 name: admin
 apiVersion: rbac.authoziation.k8s.io/v1alpha1

对于这点，来自CoreOS的Eric Chiang有段非常精彩的视频。 内置RBAC，完全API驱动，简直了！

10. 集群联邦

最后但不是唯一的是集群联邦。 回到Borg论文里，我们热爱Kubernetes的第一个原因，你可能已经注意到了一个单独的K8s集群实际上等价于单个Borg的“Cell”，或者可用域。现在在Kubernetes 1.4.0里，已经拥有了将多个集群联邦起来并通过一个控制台进行管理的功能。这意味着我们拥有了Borg lite。
这是热爱Kubernetes的一个关键原因，因为它带来了混合容器云的解决方案。想象一下，拥有K8s集群前置和一个公有云（例如：AWS，GKE，Azure)。通过这个联邦控制台，你可以运行跨多个集群的微服务。扩容会自动平衡集群间的副本，并且提供一个单独的DNS端点，同时负载均衡也是联邦的。

这个让我非常激动，因为我们应该可以更快地在已有的集群和公有云上进行应用的迁移。是，你听对了，这全部都是内置的，而不是商业组件。

开始联邦吧，Kelsey Hightower写了一篇非常详细的教程，值得一试。

其它

以上就是我热爱Kubernetes的前十个原因。我非常确定别人也有其他的原因，这个系统的可以热爱的地方太多了。我一直使用、测试和开发数据中心解决方案，我感觉到Kubernetes是一个经过深度考虑的系统，它极其稳定，可扩展，和拥有一些我们本以为会是商业组件的关键特性。Kubernetes真的改变了游戏。

简 介

在柏林的LinuxCon上我发表过题为“我为什么喜爱Kubernetes的十个原因”的演讲，效果反响热烈，好多人都让我把这篇演讲写成博客。那么这篇博客就围绕这十个原因中关于前五个的展开，后五个将在下篇博客进行。

简明扼要地说，Kubernetes是一个“为了自动化部署、扩容和管理容器化应用的开源系统”，通常被看作是容器编排工具

背景

Kubernetes项目在2014年6月由Google创立，现在它在Github上拥有超过1000位贡献者，超过3,7000次提交和超过1,7000颗星，并且目前由Linux Foundation下设的Cloud Native Computing Foundation管理。据Garnter近期的一次调查报告显示，Kubernetes在所有管理大量容器的系统中处于领先地位（译者注：该报告显示Kubernetes占到大约37%的份额，Docker Swarm大约16%，Mesos大约13%）。了解Kubernetes来源

为了在数据中心中执行任务而选择合适的分布式系统并非易事，这是因为比较不同的解决方案要比阅读关于特性和性能的文档更为复杂。观测例如Kubernetes的性能存在很多变数，因此这是一项艰巨的挑战。我相信要做出这样的选择不仅需要考虑前面的这些因素，还需要考虑到过往的经历，团队中每个人的理解和技能。是的，这似乎不够理性，但我就是这么想的。

所以在这里，下面列出热爱Kubernetes的原因，排名不分前后：

1、Borg血统

Kubernetes(K8s)继承自谷歌的秘密应用管理工具：Borg。我常说K8s是Borg的开源重写版。k8s概述

Borg长久以来是一个秘密，直到被Borg论文所公布。这个系统由谷歌著名的SRE团队用来管理例如Gmail甚至GCE这样的应用。

2、轻松部署

这一点看起来有些争议。但当我在2015年早些时候就发现安装部署非常直接。

首先, 你可以在单节点上运行K8s，我们会回到这点。但对于一个非高可用安装，你只需要安装一个中心管理节点和一组工作节点。管理节点运行三个进行（API Server，Scheduler 和Controller Manager）加上一个键值对存储etcd，工作节点运行两个进程（监控容器变化的Kubelet和暴露服务的Kube-proxy）。

这个架构，从上层来看很像Mesos，CloudStack或者OpenStack等系统。如果用ZooKeeper替换掉etcd，用Mesos master替换掉API Server运行，并且用Mesos Worker替换掉kubelet/proxy，你就得到了Mesos。

我在开始的时候写了一本Ansible Playbook，它使用CoreOS虚拟机并安装所有的K8s组件。CoreOS兼具覆盖网络（例如Flannel）和Docker的优点。结果是在5分钟内，我可以启动一个K8s集群。我一直在更新我的playbook，对于我来说，启动k8s只需要一条命令：

$ ansible-playbook k8s.yml

注意如果你使用Google云，你需要一个Kubernetes服务，GCE也可以让你一条命令启动集群：

$ gcloud container clusters create foobar

从我来看这非常简单，但我也知道这不是适用于每个人的。事情都是相对的，重用某人的playbook可能会很痛苦。

与此同时，Docker在做一件非常糟糕的事情，它重写了Swarm，并且将它嵌入到Docker engine里。它使得运行Swarm集群只需要两行bash命令。

如果你想要这种类型的启动，Kubernetes目前也支持一个叫做kubeadm的命令，它使得你可以从命令行创建集群。启动一个主节点，并加入工作节点。就是这样

$ kubeadm ini

$ kubeadm join

我也同样为它建立了playbook，戳这里查看。

3、使用minikube的开发方案

当你想尽快体验一个系统，你又不全量部署在你的数据中心或云上。你可能只是想在你本地的机器进行测试。

没事，你可以使用minikube。

下载，安装，你只需一条bash命令就可以搭建一个单节点、独立的Kubernetes实例。

$ minikube start

Staring local Kubernetes cluster...

Kubectl is now configured to use the cluster.

在很短的时间内，minikube将为你启动Kubernetes需要的每个程序，然后你就可以访问你的单节点k8s实例了：

$ kubectl get ndoes

NAME    STATUS  AGE

minikube Ready  25s

默认情况下，它支持Virtualbox，并启动一个只会运行单个程序（例如localkube）的VM，为你快速搭建Kubernetes。这个VM同时还会启动Docker，你也可以使用它作为Docker宿主机。

Minikube同时允许你测试不同的Kubernetes版本，和配置不同的测试特征。它也附带了Kubernetes dashboard，你可以快速打开：

$ minikube dashboard

4、易于学习的API

在REST之前的世界是痛苦的，学习痛苦、编程痛苦、使用痛苦、调试痛苦。还包含了很多不断完善的、相互竞争的标准。但这一去不复返。这就是为什么我如此喜爱简洁的REST

API，我可以查看和使用curl进行测试。对我来说，Kubernetes

API很不错。仅仅包含了一组资源（对象）和HTTP动作，通过基于JSON或YAML的请求和响应我可以操作这些对象。

Kubernetes发展迅猛，我喜欢这些被划分到不同API组里的多种不同的资源，它们还被很好地控制了版本。我可以知道我使用的是alpha、beta还是stable版本，同时我也知道去哪里查看这些定义。

如果你阅读了第3个原因，那么你已经拥有了minikube，是么？那么最快地查看这些API的方法就是深入它们：

$ minikube ssh

$ curl localhost:8080

{

    "path": [

        "/api",

        "/api/v1",

        "

如果你看到了这些API分组，并且可以体验它们包含的这些资源，请尝试：

$ curl localhost:8080/api/v1

$ curl localhost:8080/api/v1/nodes

所有的资源都包含kind, apiVersion, metadata。

为了学习每个资源的定义，Swagger API browser非常实用。我也通常会去文档里查询一个特定的域等。学习API的下一步实际上是使用命令行接口kubectl，即原因5。

5、极好的命令行接口

不管是学习API还是编写自己的客户端，Kubernetes都不会把你扔下。K8s的命令行客户端叫做kubectl，它基于语句，功能强悍。

你可以使用kubectl管理整个Kubernetes集群和所有的资源。

可能对于kubectl最难的部分是安装它或者找到它。这里有提升的空间。

让我们再次使用minikube，并且体验kubectl的动作，例如get，describe和run。

$ kubectl get nodes

$ kubectl get nodes minikube -o json

$ kubectl describe nodes minkube

$ kubectl run ghost --image=ghost

最后一条命令将会启动一个Ghost博客平台。你很快就会见到一个pod出现，一个pod是Kubernetes最小的计算单元和最基本的资源。当使用run命令的时候，Kubernetes创建了另外一个叫做deployment的资源。Deployment提供了一个容器化服务（看作单个微服务）的声明式的定义。对它的扩容通过下面的命令完成：

$ kubectl scale deployments/ghost --replicas=4

对于每个kubectl命令，你都可以使用两个小技巧：–watch和–v=99。watch标记会等待事件发生，这就跟标准Linux命令watch类似。值为99的verbose标记会给你跟kubectl功能一样的curl命令。这非常有助于学习API，找到它使用的资源和请求。

最后，你可以通过编辑deployment来更新它，这会出发一个滚动升级。

$ kubectl edit deployment/ghost

其它

其余的5个热爱Kubernetes的原因，敬请期待。

那么你听说了Kubernetes但却对它是什么和它怎么工作的毫不知情？Linux Foundation的Kubernetes Fundamentals Course将带你从零开始学习如何部署一个容器化应用和通过API进行操作。

原文链接：https://www.linux.com/blog/top-5-reasons-love-kubernetes

原文作者：https://twitter.com/sebgoa

本文简单粗暴，直戳泪点，ho，不，是直戳痛点。帮你揭开挡在你与容器云之间的那层神秘面纱，看看你的企业究竟适不适合选用基于K8S的容器云管理平台。

企业对容器云平台的需求现状是什么？

众所周知，Docker很火，一大批互联网公司早已领先一步，逐渐搭建起了自己的容器云平台，而传统企业们也不甘落后，正在试水或狂奔而来的路上……

但是，Docker虽火，并不代表就要一哄而上，更不代表对容器技术简单的“拿来主义”。而且，在容器圈内还存在着Kubernetes、Mesos、Swarm等分属不同阵营的容器集群管理工具，以及基于这些工具的多个容器云提供商。

「  企业面临的选择太多，往往就会不知道如何选择！ 」

事实上，选择什么样的容器云，除了货比三家，更要结合自身需求，我们发现：

越来越多的企业正在寻求一种能够满足现有企业组织结构、技术架构、开发运维模式、安全策略等诸多需求的容器云平台，而且也不会简单、快速的按照这个平台的约束去大规模改造现有开发交付模式，而是更多的在专业技术团队的引导下逐步转换到容器化，或者以应用为中心的云平台上。

那么问题来了，基于企业这样的容器化需求和趋势，究竟什么样的企业适合选用容器云，并且是基于K8S的容器云呢？

首先，让我们先来扒一扒Kubernetes，看看它有什么优势能够独得企业恩宠：

K8S档案：

姓名：Kubernetes

小名：K8S

父母：科技界豪门谷歌

年龄：15岁

工龄：3年

专业：容器集群管理

职业：为容器云平台提供应用部署、维护、扩展机制等功能

兴趣爱好：爱交好友、乐于助人，好友都是圈内名人，如intel、ebay、Yahoo

个人优势：身材小巧、灵活性强、擅长帮助朋友快速成长

个性化标签：豪门“富二代”、人脉广、人气旺、专业素质过硬

对比概括K8S优势：

• 与Docker官方的Swarm相比，它成熟稳重，有超强的功能扩展性，支持超大规模集群的精细管理，支持有状态的大数据分析，支持复杂的网络场景，兼容性更好；

• 与Apache的Mesos相比，它年轻朝气蓬勃，具有强大的生命力，功能完善，简便易用上手快，17K+的点赞（社区star）就是证明！另外在负载均衡、灰度升级、失败冗余、容灾恢复、DevOps等方面都有绝活。

坦率的讲，选择什么样的容器集群管理系统、什么样的容器云管理平台很重要，这是因为：先进智能的容器管理系统、灵活易用而又高效安全的容器云管理平台，可以让你的企业在开发运维中更加高效迅速，资源利用率更高。

互联网时代，行业竞争激烈，风云突变，应用的开发效率、稳定性、扩展性和安全性，将直接决定你的企业能够甩开竞争对手几条大街，更决定企业市值（估值）的高低！

那么下面让我们再来看看哪些行业、哪些场景，适合使用基于K8S的容器管理平台？

『 1 』

如果你在金融行业，面临基础架构复杂老旧，弹性扩展能力差；高峰时段和低谷时段业务量差异巨大，业务负载剧烈波动，且负载波峰不可预估；高峰期业务需求高，很多应用面临快速上线的压力，那么你需要！

『 2 』

如果你在汽车行业，面临IT业务由众多供应商提供，运维管理难度增大，安全上要求三层网络隔离；或者你要建立车联网应用平台，打造无门槛应用开发生态，苦于无法把云上、云下环境打平，那么你需要！

『 3 』

如果你在电商行业，面临电商系统和营销系统服务组件众多，每次部署需要耗费很长时间，且容错能力比较薄弱，无法应对大规模并发访问，那么你需要！

『 4 』

如果你在传统大型企业，面临机构繁琐庞杂，跨部门业务流程漫长，申请、审批、开发、测试周期一拖再拖，那么你需要！

『 5 』

如果你在传统中小企业，研发能力较差，外包公司各种不靠谱，要么缺少应用配置文件、验收文档空泛，要么数据库建立与调用规则混乱，业务与业务之间协同工作成本高昂，那么你需要！

可以说，不管你是在大企业，还是小企业，不管是互联网企业，还是传统企业，只要：

• 你的企业业务发展迅速，追求快速上线应用；
• 你的业务追求稳定、可靠，寻求IT成本和效率的最优配置；
• 你的企业处于转型变革期，追求时髦技术的学习研究和业务应用迁移的平滑过渡；

那么，选择基于K8S的容器云管理平台就对了！它会为你提供容器服务、代码构建、镜像仓库、服务编排、集群管理、系统管理等多元化、全方位的服务。

写在最后：随着容器技术的普及、标准化，以及众多国内外企业的力推，中国的云计算企业、或者有云计算需求的企业对容器技术的重视程度将会进一步提高，任何企业都不想继续在低版本的云计算平台上花费更多精力，转型容器化已是大势所趋。那么，选择什么样的容器云平台就已经是箭在弦上的大事了。

【编者的话】Kubernetes是Google开源的容器集群管理系统，其提供应用部署、维护、 扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用。今年的调查显示，Kubernetes成为被最广泛使用的编排工具。为什么在编排方面Kubernetes如此受欢迎呢？让我们看Matt Asay如何看待这个问题。

容器的使用在技术中日益广泛使用，尽管不同的编排产品竞争激烈，但是行业中一般都以Kubernetes作为容器的默认编排引擎。

对比诸多编排工具，包含Docker官方的Swarm，我们有必要研究下Kubernetes为何如此受欢迎，尤其是彼此之间复杂度的区别。

像MongoDB和Linux这样流行的开源软件，流行的原因可以归结为社区建设的功劳—例如谷歌研发15年的背后支持。最终，这一独特的卓越工程愿意让别人接手，也是Kubernetes能够成为令人印象深刻的开源项目的原因。

做有内容的社区

从社区的年龄来讲，Kubernetes不占优势。毕竟Kubernetes才两岁而已（从作为开源项目算起），而Apache的Mesos已经推出7年之久。Docker Swarm虽然是比Kubernetes更年轻的项目，但是它的背后是来自于Docker官方容器中心的全方位支持。

然而作为编排工具，对手在社区这一点比起来就显得略微苍白。现在Kubernetes社区在基础云平台的管理下正在不断变得丰富多彩。

• Kubernetes是活跃在Github中前几名的项目之一：占有在所有项目中排名0.01%的star，而且在所有团队项目活跃度排名第一。
• 虽然Kubernetes的文档欠佳，但是Kubernetes有自己的Slack和Stack Overflow社区作为补充，帮助解决问题优于其竞争对手。
• 在LinkedIn上有更专业的Kubernetes专家，相比其他工具，Kubernetes通过LinkedIn为使用者提供了更广阔的解决问题空间。
• 最明显的是，OpenHub的数据却显示了Apache Mesos正在走向衰落，Docker Swarm增长也开始放缓。从原始社区的贡献来讲，Kubernetes正在迅速增长，从1000+贡献者34000+的提交贡献，远远超过了其他像Mesos竞争对手的四倍之多。

是什么造成了这样疯狂的结果呢？总之一句话，是谷歌，或者是说谷歌的选择开源。虽然其他的每一个编排项目背后都有一个供应商公司在影响着，但是Kubernetes受益于谷歌的不干涉开发，以及比较优秀的原始引擎。

与此同时，Docker拥有实际上的容器标准，Docker也一直在努力构建与Kubernetes一样广泛深入的容器社区。基于以上原因，谷歌的Kelsey Hightower指出，Docker本身在阻止竞争对手进入构建容器标准。

当然，容器不需要任何标准化的输入，但是市场似乎更倾向于更少的权利集中在编排层的容器。由于市场需要一个可行的商业模式，我们期待Docker在ops,hence，编排容器方面的竞争。但是除非公司把Swarm转变为真实的行业标准，这样可能赢得了容器的战争，而会在编排工具的竞争中失败，即使他声称可以提供更好的性能。

谷歌崇拜者

Kubernetes活跃社区的背后是特殊的技术力量驱动。作为谷歌的Borg技术，Kubernetes已经累积了15年的深耕细作的发展和生产实践。这项技术特别好以至于时任谷歌技术基础架构部门领导的Urs Holzle难以置信的反应，当时一些工程师建议建议一个Borg版本并且提议开源。
“所以，让我直说了吧，你可以构建一个外部的Borg任务调度器，这也是我们一个最重要的竞争优势，甚至不谈其他的，重要的问题是要它开源吗？”

工程师使用Borg作为集群管理的工具，其中Gmail，YouTobe，Google Search和其他流行的谷歌服务都是用此工具作为基础框架管理。后来它被内置在谷歌的计算引擎中。但是工程师发现，用户关注点在CPU的那点利用率上。容器管理工具是必须的，他们可以作为一个守护进程运行在系统中，其中的诀窍把它公开、开源了。

据谷歌产品经理Martin Buhr说，谷歌更换Kubernetes的动机来自于一些官面的原因和一些自身的利益。谷歌希望开源的Kubernetes可以极大地扩展开发人员的生产力，从而使这个世界更加美好。更自私的讲，“随着时间的推移，我们将对谷歌云平台容器做全面的支持，将在市场上创造一个基于容器的应用程序，他们其中很大一部分会与我们同在的。”

换句话说，让开发和运维团队可以很舒服地使 用Kubernetes，所以他们可以选择谷歌的云平台更方便的使用。这是基本没有其他工作的，如果谷歌开始对Kubernetes有直接的货币利益，那对开源社区来说是个毒丸。

简而言之，Kubernetes的成功源于谷歌在代码层次15年的深耕细作，也因为谷歌渴望社区继续发展，并期待花费下一个15年去发展Kubernetes。

 

开源项目 CRI-O，其前身为OCID，官方简介是“OCI-based implementation of Kubernetes Container Runtime Interface”。作为接口，它使得Kubernetes 不依赖于传统的容器引擎（比如Docker），也能够管理容器化工作负载。

该项目通过与Kubernetes（或其商业版CoreOS Tectonic）协作，可以帮助DevOps人员来管理容器的整个“生命周期”。

开发人员需要使用容器引擎构建镜像，通常情况下更喜欢用自己的staging 环境做本地测试。但是管理和运营人员会发现，相对于标准容器引擎， Kubernetes技术栈（比如编排系统、CRI和CRI-O）更适合用来管理复杂的生产环境。

该项目将编排工具放在容器技术栈的重要位置，同时降低了容器引擎的重要性。CRI 的一个Contributor说，让Kubernetes支持任意容器引擎，在理念上与Open Container Initiative一脉相承。容器引擎可以是docker或CoreOS的rkt，或OCI 的 runc（它可以做很多如Docker 或 CoreOS  rkt 这类容器可以做的事情，比如从registry拉镜像，但它不会从makefile构建镜像）。

CRI-O 是什么？

「  尽管 Open Container Initiative 类似的部分已经与 CRI-O的职责区别越来越大，两个项目的成员、贡献者和厂商也有很大重合，但CRI-O 仍然是OCI的自然延伸，它为容器引擎和镜像提供了一套标准接口。」，Kubernetes 工程师Kelsey Hightower 在The New Stack 的采访中说道。

CRI-O 项目的设想是用户不应该依赖任何特定的容器引擎去完成工作负载。按照最初的设想，该项目将为 Kubernetes提供一个工具集，使其能够管理容器的整个生命周期，而不需要Docker、rkt、OpenShift、Photon 或任何其他容器引擎。

「 我们对容器引擎的功能要求很少，不管是Docker还是rkt，它们要做的工作都很少 」，Hightower说，「 我们需要的是访问内核的API，不仅仅针对Linux，也可以是Windows。如果这是社区想要去的方向，Kubernetes就要支持这些想法-因为在这一点上它比Docker公司更大 」。

在这一假设之下，是一个新奇的观点：编排才是容器生态的中心，而“引擎”就我们所知，只是一个开发工具。

另一方面，CRI（通用容器接口API和Kubernetes）将给容器引擎厂商一个机会，以便接入Kubernetes系统。运行容器的环境中，只要暴露出适当的连接，不需要容器引擎进行代码重构就可以兼容Kubernetes。

其中一个方式是，在容器引擎和编排工具中间实现一个抽象层，容器厂商如何实现这一层完全取决于他们自己。

容器引擎中间层实现以后，CRI  API（与Kubernetes连接的部分）将把更多的容器生命周期控制权交给kubelet —— pod的管理者。Pod是Kubernetes 特有的概念，但容器生态系统必须采用这个概念。

对于Kubernetes，下一个版本的目标是1.5版本，包括CRI的最终版，允许kubelet 与Docker，rkt、Hyper.sh（中国团队开发）以及CRI-O（RedHat领导开发）进行通信。

“关于如何与Kubernetes 通信，很多不同的容器引擎都非常感兴趣”，Philips说，“与其在kubelet中为每一个容器引擎构建一个接口，我们创造了一个更抽象的接口，允许容器引擎去接入而不用直接参与Kubernetes 的工作。”

谁需要重构，重构什么？

Hightower 将CRI（“CRI”在“CRI-O”之前）描述为一个抽象的概念，代表容器引擎应该支持的基本特性，而Kubernetes可以用来验证这些特性。一旦CRI完成，将重构Kubernetes代码以实现CRI。

如果CRI-O成功，容器引擎厂商不需要对引擎代码库进行修改，就可以简单地与Kubernetes交互。

“现在，如果你想很happy地玩耍Kubernetes，必须构建一堆东西，而且可能修改你目前的做事方式”，Hightower 说，“你查看现有的代码库，看看为Docker做了哪些东西。在某种程度上，你需要付出类似的努力，去修改适合你的运行时引擎，从而与Kubernetes很好的配合。”

就像 CoreOS的Philips 解释的一样，每个容器引擎将利用一个中间层—— 它能够将容器引擎的 API请求，转化成Kubernetes可以处理的形式。

“考虑到CRI的运行机制，你需要一个GRPC daemon 去监听请求”，Philips说，“它能与kubelet 通信；反过来，kubelet 可以通过socket对实现CRI的引擎发送一个远程调用”。

Philips说，“目前对Docker和rkt的支持将被合并到CRI接口”。 CoreOS rkt 对CRI的实现目前已经在Github上开源，项目名称为rktlet。不管是rktlet，还是Docker对CRI的实现（不管将来叫什么名字），他预计都被重构为CRI。

Google 的Hightower 说：“尽管Docker已经要求与Kubernetes 一起实现中间层，最终仍然是Google 的工程师去实现，而不是Docker的。Philips也表示，不管谁去实现中间层，Docker和其它容器引擎厂商遵循同样的规则，都不能搞特权。

“为了与CRI集成，Docker Engine和 rkt Engine都处在不断变化中”，Brandon Philips如是说。

OCI镜像格式的最终标准还没有确定，OCI发言人也表明OCI镜像格式1.0 发布之前还有两个迭代版本。

同时，Docker 在不断增强其容器引擎的特性，并且捆绑了Swarm 编排工具和服务发现。

“我认为这一切进展都不错，”Philips说，“人们可能不喜欢这样——这很正常，每个人都可以有自己的观点。对于Kubernetes ，我们仍然会提供一包东西。但我们在创造和改进它时，不认为它仅仅是一件商品（还有情怀）。

超越Kubernetes

“前面我们谈到Pod，为了正确地实现它，你还需要了解很多东西”，Hightower 说，“把负担推给容器引擎，让它们去写一拖代码才能与kubernetes愉快地玩耍，这一点对于每个容器引擎都很不公平。想想看：他们还要为Mesos和Swarm去实现类似功能的代码，想想都可怕。为了简化这部分功能，我们将把Kubernetes专属的逻辑放到kubelet中；对于外部而言，通过一种友好的方式使用容器引擎本来就具备的特性。

假设这已经是事实，现有容器引擎特性被隐藏在一个接口后面，该接口能够将pod为中心基于kubelet 的逻辑从kubernetes 隔离出来，与Kubernetes之外但有同样API的编排工具交互，这个编排工具对API可能有一套完全不同的实现方式（饼越来越大）。

我们和Mesosphere 创始人Ben Hindman 也探讨了这种可能性。

“我认为这个行业需要的是可拼凑的组件”，Hindman 对The New Stack 解释说。“在Kubernetes 案例中，我认为这很关键。Kubernetes依靠Docker做容器管理，并且他们尝试构建编排。当Docker整合Swarm时，他们不仅有一个容器管理器，也在做编排。仅仅从架构的角度来看，这是非常合理的。我想说的是：如果我们只做一个容器管理的组件，让很多人可以利用，岂不是很更好？”

对于 Docker公司有意向将runc作为开放标准，Hindman非常认同，但他也不忘吐槽：完整的编排不仅仅是与与容器引擎交互。

“还有很多，比如下载镜像、镜像打包、镜像解包 —— 还有更多的事情必须去做。

对我来说，我认为行业中还在就一个问题争论：这些东西应不应该被分解和模块化？它不仅仅是 fork the repo 那么简单，还需要在架构上解释得通。”[ Ben Hindman ]，

Mesosphere 的 DC/OS环境中也有这些组件做铺垫，Hindman 解释说，已经无需依赖 runc 或任何Docker 组件。容器社区的真正目标，正如他所说的，是在组件之间指定架构层面上的边界，并建立它们之间建立适当的接口。

这是否意味着Mesosphere支持 CRI-O，CRI-O的目标也如Kelsey Hightower向我们解释的一样，与Hindman 预计的完全兼容吗？

然而Hindman并不是为 OCI呐喊，需要注意的是，Mesosphere 是OCI的创始成员之一。 OCI的最初的目的是开发一种通用的运行时格式，让runc 能够以容器的方式启动它。容器社区也关心镜像格式，包括容器在非运行状态下的文件系统和元数据。所以OCI也接受这套理念。

“对于我们而言，镜像格式比运行时格式更有趣，也有意义” ，Hindman 说，“Mesosphere 之所以拥抱 universal containerizer，原因是希望支持所有开放格式的容器，包括OCI。”

但在这样一个最佳架构中，可能没有方法去规范工作负载的调度器。不同调度器的特性可能千差万别。因此，如果以这种方式，努力通过一个文件描述工作负载（可能是配置文件、元数据文件或manifest文件），并且试图对所有调度器通用，最终制定出来的标准可能满足不了任何调度器的需求，进而妨碍调度器本身特性的扩展。

但是，确定一个通用镜像格式则简单很多，最终取决于 Linux 是否支持该格式。“如果支持它，我们可以公开它。在镜像格式上，我认为没有太大的争论，因此，把它作为一个标准就OK。”

Hindman 总结说，Mesosphere 将继续支持OCI，将来会以同样的粒度支持CRI-O。但跟CRI-O相比，Mesosphere 的“universal container runtime”将以不同的方式被支持。

未来在编排领域，我们会看到一个激烈竞争的市场，而不是容器引擎领域。