行业头条

容器编排器的大战似乎快要结束了——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已毋庸置疑成为了容器编排和管理的社区标准。如果你希望你所搭建的应用程序能充分利用多云（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替换。此外，开发者还可以定义应用程序或者服务侦听的端口号，无论它是较大服务的一部分，或仅仅是一个独立实例。通过这样的操作，使用持续交付和部署方法论的快速开发和部署周期将会成为常态。

资源管理、调度和负载均衡作为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》

译者注：本文介绍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 Ark和Heptio 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，距离1.0版发布已达2年之久。现在该项目在GitHub上的提交次数总共已经破5万。参与Kubernetes上游项目开发的CoreOS，也揭露了几个数据，显示该项目生态圈的大小。CoreOS社区经理Elsie Phillips表示，在过去一整年内，代码提交次数总共有3万3千次，代码贡献者也新增了2,500名。而开发者上传的Issue则多了122％。

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

了解更多

• Kubernetes文档 / 中文文档
• CNCF
• Kubernetes github更新日志
• Kubernetes github社区页面

在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制定的标准。

在之前的文章中，我们从容器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