拥抱容器,你选好管理方式了吗?

kubernetes阅读(162)评论(0)

根据 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!

【干货-K8S系列】Kubernetes调度核心解密:从Google Borg说起

kubernetes阅读(472)评论(0)

在之前“容器生态圈脑图大放送”文章中我们根据容器生态圈脑图,从下至上从左至右,依次介绍了容器生态圈中8个组件,其中也提到Kubernetes ,是一个以 Google Borg 为原型的开源项目。可实现大规模、分布式、高可用的容器集群。本篇我们重点介绍Kubernetes前世今生。

一个容器平台的主要功能就是为容器分配运行时所需要的计算,存储和网络资源。容器调度系统负责选择在最合适的主机上启动容器,并且将它们关联起来。它必须能够自动的处理容器故障并且能够在更多的主机上自动启动更多的容器来应对更多的应用访问。

目前三大主流的容器平台Swarm, Mesos和Kubernetes具有不同的容器调度系统。Swarm的特点是直接调度Docker容器,并且提供和标准Docker API一致的API。 Mesos针对不同的运行框架采用相对独立的调度系统,其中Marathon框架提供了Docker容器的原生支持。Kubernetes则采用了Pod和Label这样的概念把容器组合成一个个的互相存在依赖关系的逻辑单元。相关容器被组合成Pod后被共同部署和调度,形成服务(Service)。这个是Kubernetes和Swarm,Mesos的主要区别。相对来说,Kubernetes采用这样的方式简化了集群范围内相关容器被共同调度管理的复杂性。换一种角度来看,Kubernetes采用这种方式能够相对容易的支持更强大,更复杂的容器调度算法。

谈到Kubernetes, 我们就不能不提到Google的Borg系统。Google的Borg系统群集管理器负责管理几十万个以上的jobs,来自几千个不同的应用,跨多个集群,每个集群有上万个机器。它通过管理控制、高效的任务包装、超售、和进程级别性能隔离实现了高利用率。它支持高可用性应用程序与运行时功能,最大限度地减少故障恢复时间,减少相关故障概率的调度策略。Kubernetes的架构设计基本上是参照了Google Borg。本文结合Google发布的相关论文和视频,初步介绍了Google Borg的资源调度,以及它对Kubernetes容器调度系统产生的影响和未来走向。关于本文内容的具体技术细节描述请参见Google论文以及Kubernetes文档。

Borg调度介绍

本文的第一部分我们先介绍一下看看Borg. Google的Borg系统运行几十万个以上的任务,来自几千个不同的应用,跨多个集群,每个集群(cell)有上万个机器。它通过管理控制、高效的任务包装、超售、和进程级别性能隔离实现了高利用率。它支持高可用性应用程序与运行时功能,最大限度地减少故障恢复时间,减少相关故障概率的调度策略。以下就是Borg的系统架构图。其中Scheduler负责任务的调度。

 

2017022801

 

Borg调度测试

Borg对开发者隐藏了系统资源管理和故障处理细节,我们来从开发者的角度来看如何在Borg中运行一万个Hello World的任务。开发者只需要完成以下config file并且提交给Borg.

 

2017022802

 

大家可以看到这样的一个config file包含了集群名称,任务二进制, 资源要求以及replica数量。Kubernetes的YAML文件很大程度上继承了这些配置项。

当我们提交这样一个Hello World 任务给Borg后,调度器Scheduler会根据系统资源自动部署一万个Hello World任务到主机上。下图是一个部署时间表。

 

2017022803

 

可以看到经过了3分钟后大约一万个任务就开始运行了。原因在于其中会有一些任务因为各种各样的原因停止运行。下图可以看到3分钟后大概只有9993个任务在运行。Borg会自动进行错误处理并且部署新的任务。

 

2017022804

 

Borg调度核心

那么如何提升整个Borg系统的资源利用率呢?核心的解决方案就是根据主机资源合理的调度任务,提高系统效率。Borg主要从以下几个方面着手。

在同一台主机上跑多个任务。

  1. 采用最优的打包算法,合理的把成比例的CPU、Memory资源分配给任务,避免资源阻塞造成浪费。下图橙色标识的主机就是因为CPU或者内存资源占用超过合理比例而造成另外一种资源的浪费。

2017022805

  1. 在系统中同时跑生成和非生产任务。Borg系统的任务分为生产型(Prod)任务,即高优先级任务和非生产的(non-prod)任务。大多数长期服务是Prod的,大部分批处理任务是non-prod的。通常情况下,生产型任务会保留一部分资源以应付极端情况,这些资源可以被用来跑非生产型应用,当生产型任务需要更多资源的时候,非生产型任务会被调度出系统。
  1. 资源回收。从下图可以看到,Borg会根据现有资源消耗情况评估任务对未来资源的需求作为Reservation, 把绿色部分的资源回收再利用给那些可以忍受低质量资源的工作。Borg调度器使用限制资源(limit)来计算Prod任务的可用性,这些Prod任务从来不依赖于回收的资源,也不提供超售的资源;对于non-Prod的任务则使用了目前运行任务的Reservation,新的任务也可以被调度到回收资源上去。当一台主机因为对资源预估不足时,Borg会限制或者杀掉non-prod任务。资源预估可以采用激进或者保守的策略,Borg目前采用的介于两者之间的中庸策略。

 

2017022806

 

Kubernetes借鉴了Borg的整体架构思想。如下图,其中Pod调度也是由Scheduler组件完成的。

 

2017022807

 

有一种情况下,Scheduler不参与Pod调度,那就是用NodeName指定部署主机。

 

2017022808

 

Kubernetes资源调度

和Borg类似,Kubernetes的资源分为两种属性。可压缩资源(例如CPU循环,Disk I/O带宽)都是可以被限制和被回收的,对于一个Pod来说可以降低这些资源的使用量而不去杀掉Pod。不可压缩资源(例如内存、硬盘空间)一般来说不杀掉Pod就没法回收。未来Kubernetes会加入更多资源,如网络带宽,存储IOPS的支持。

Kubernetes调度器使用Predicates和Priorites来决定一个Pod应该运行在哪一个节点上。Predicates是强制性规则,用来形容主机匹配Pod所需要的资源,如果没有任何主机满足该Predicates, 则该Pod会被挂起,直到有主机能够满足。可用的Predicates如下:

  • PodFitPorts:没有任何端口冲突
  • PodFitsResurce:有足够的资源运行Pod
  • NoDiskConflict:有足够的空间来满足Pod和链接的数据卷
  • MatchNodeSelector:能够匹配Pod中的选择器查找参数。
  • HostName:能够匹配Pod中的Host参数

如果调度器发现有多个主机满足条件,那么Priorities就用来判断哪一个主机最适合运行Pod。Priorities是一个键值对,key表示名称,value表示权重。可用的Priorities如下:

  • LeastRequestdPriority:计算Pods需要的CPU和内存在当前节点可用资源的百分比,具有最小百分比的节点就是最优的。
  • BalanceResourceAllocation:拥有类似内存和CPU使用的节点。
  • ServicesSpreadingPriority:优先选择拥有不同Pods的节点。
  • EqualPriority:给所有集群的节点同样的优先级,仅仅是为了做测试。

Kubernetes调度总结

为了对Pod所运行时要求的资源做出限制,Kubernetes通过配额YAML文件来设置Resource quotas和limit,从而管理独立Pod以及项目中所有Pod(即Namespace)的资源要求。未来Kubernetes会针对Pod资源QoS做出更多功能增强,以应对日益复杂的容器应用需求。

我们可以看到基于资源分配的任务调度是Borg和Kubernetes的核心组件。两者的调度模块都处于整个系统的核心位置。Kubernetes的调度策略源自Borg, 但是为了更好的适应新一代的容器应用,以及各种规模的部署,Kubernetes的调度策略相应做的更加灵活,也更加容易理解和使用。

2016年Kubernetes(k8s)大事记

kubernetes阅读(578)评论(0)

34次发布 , 18,557次commits,175家企业参与,705个贡献者,2,552,778行Go代码

2016年是Kubernetes快速发展的一年,在社区中,从对它疑虑到逐渐认可再到追捧,转变过程用了不到一年的时间。

Kubernetes被越来越多的公司作为生产系统容器集群的编排引擎,以Kubernetes为核心构建企业内部的容器生态越来越成为业界的共识。

2017已经开始,为了让我们在新的一年更加出色,我们一起来回顾一下2016年Kubernetes发生的大事件。

2017020404

2016 Kubernetes 大事记

2016年,Kubernetes经历了34次稳定版发布,发布次数相比2015年增加了112.5%,平均发布间隔为11天。

V1.5.0

2016年12月23日

Kubernetes 1.5版本意义重大,它完善对Federation的支持、新增的CRI、特别是增加对Windows容器的支持,能够让K8在未来走向更加广阔的天地。

主要更新

  • — StatefulSets:修复了一些BUG,让它更加稳定
  • — 增强对Federation支持:新增kubefed命令,支持联邦的DaemonSets、Deployments、ConfigMaps
  • — 简化集群部署:增强kubeadm、为Master节点设置HA
  • — 增强节点健壮性和可扩展性
  • — 增强Windows容器支持
  • — 发布了插件化、可插拔的容器运行时接口(CRI)
  • — 增强对API支持:授权和认证

新特性

  • — API机制:对OpenAPI的支持、基于此的第一个非Go客户端 [beta]
  • — ReplicaSet创建Pod失败后,可以通过API获取底层错误的原因 [stable]
  • — kubectl apply通过—prune参数删除不再需要的资源 [stable]
  • — StatefulSets支持对需要持久化应用的创建和管理 [beta]
  • — 出于安全方面考虑,不再支持删除未响应的节点上的Pod,如果通过CLI强制删除会收到警告 [beta]
  • — 继续打磨RBAC,提供了一组默认的集群角色 [alpha]
  • — 提升了kubeadm的易用性和交互体验 [alpha]
  • — 在GCE上,可以通过kubeup/kubedown脚本提供对于高可用master节点的创建和删除 [alpha]
  • — 支持联邦的DaemonSets [alpha]
  • — 支持联邦的ConfigMaps [alpha]
  • — 支持联邦的Deployments [alpha]
  • — 添加对联邦资源的删除选项:DeleteOptions.OrphanDependents [alpha]
  • — 引入一个简化创建联邦集群的CLI工具:kubefed [alpha]
  • — 服务之间可以通过DNS进行调用,而不是之前Pod里host文件的方式 [stable]
  • — 服务类型为NodePort和LoadBalancer里提供了基于源IP的策略选项 [beta]
  • — 通过beta版的ConfigMaps的参数支持DNS的水平扩展 [stable]
  • — 如果容器运行时开启userns重映射时,保留对宿主userns的访问能力 [alpha]
  • — 支持可插拔的CRI,并提供一个Docker-CRI用于测试和反馈 [alpha]
  • — 基于QoS层级,提供对每个Pod的Cgroup配置 [stable]
  • — 基于Pod级别的(而不是Container级别的)资源控制模型,提供针对Pod级别的Cgroup配置 [alpha]
  • — Kubelet通过集成的memcg通知、检测Pod是否超出了内存的硬限制 [beta]
  • — 引入了对于容器化的节点一致性检查工具:使用镜像gcr.io/google_containers/node-test:0.2 [beta]
  • — 添加对于不透明整数资源(Opaque Integer Resource)的统计 [alpha]
  • — 在遵守应用SLO的情况下,PodDisruptionBudget可以用来删除(drain)节点 [beta]
  • — Dashboard UI现在可以显示所有用户可见对象及其资源的使用情况 [stable]
  • — 支持对Windows Server 2016的节点支持和调度 [alpha]

V1.4.0

2016年9月27日

Kubernetes 1.4版本大大降低了K8S集群的部署难度,对有状态应用有了更好的支持,集群的Web管理工具——Dashboard能够替代90%的命令行操作,同时,K8S在安全方面也正在不断完善。

主要更新

  • — 简化用户体验:更易搭建集群、更易理解集群
  • — 支持有状态应用:增强持久能力,新的调度和资源特性
  • — 集群联邦:多集群的Ingress,联邦混合云上的资源支持
  • — 安全:增加Pod级和集群级粒度的安全方案

新特性

  • — 增加了每次对安全服务端点访问的审计日志 [alpha]
  • — kube-apiserver支持Swagger 2.0 [beta]
  • — 默认启用服务端的垃圾回收 [beta]
  • — 引入基于时间的、可命名的ScheduledJobs [alpha]
  • — 根据容器镜像策略来决定它是否可以被调度 [alpha]
  • — Access Review为外部需求提供授权机制 [alpha]
  • — 保证关键的基础Pod在必要的情况以停止常规Pod下为代价进行调度 [alpha]
  • — 简化了Apiserver和Kubelet间安全通信的启动过程 [alpha]
  • — kubeadm简化了Kubernetes集群的启动 [alpha]
  • — 通过向Federation API提交Ingress的创建请求就可以创建联邦Ingress。联邦控制系统通过虚拟IP来完成对所有集群的负载均衡。GCE L7 Load Balancer首次实现此特性。 [alpha]
  • — 联邦ReplicaSet可以根据不同的权重在多个集群上保证Pod的数量 [beta]
  • — 联邦Secrets保证跨集群一致性 [beta]
  • — 联邦APIserver增加了对Events的支持 [beta]
  • — 创建联邦Namespace会让所有注册在联邦里的每个集群都维持同样的Namespace [alpha]
  • — Ingress支持单Master多Zones的集群 [alpha]
  • — service LB支持保留客户端源IP地址的策略 [alpha]
  • — Dashboard开放了节点性能展示 [alpha]
  • — Pods现支持对sysctl的白名单。不安全的sysctl将被Kubelete的白名单记录 [alpha]
  • — AppArmor的功能特性将被应用到Pod容器上 [beta]
  • — 集群增加了对安全相关特性的访问控制 [beta]
  • — 面临磁盘压力时Kubelet可以驱除节点上的Pod [stable]
  • — 自动化的Docker校验结果 [beta]
  • — 持久卷提供对StorageClass配置多个卷的支持 [beta]
  • — 支持新的卷插件:Quobyte Distributed File System [stable]
  • — 支持新的卷插件:Azure Data Disk [stable]
  • — 新的Dashboard,支持90%的命令行功能 [stable]

V1.3.0

2016年7月2日

Kubernetes 1.3版本第一次引入了对有状态应用的支持(PetSet)和对NVDIA GPU的支持

主要更新

  • — alpha版的基于角色的认证(RBAC Auth)添加到API组中
  • — beta版联邦的API组发布
  • — Service可以注册到联邦中所有集群的CloudDNS中(AWS和GCP)
  • — alpha版的PetSet用于有状态应用的场景
  • — alpha版本的init pod为有状态的容器提供一次性安装的特性
  • — 在kubectl rolling-update过程中重试Pod/RC的更新
  • — 为kubectl rollouts添加status子命令
  • — 七层的负载均衡控制器和磁盘控制器在master端实现,计算节点不再需要拥有与之操作相关的权限
  • — 设置TSL1.2最小化
  • — 添加Kubectl create secret tls命令
  • — webhook令牌认证器
  • — 为安全敏感的pod引入beta版的PodSecurityPolicy对象
  • — kubectl在json错误时会显示出错的行号
  • — kubectl中使用-t来简化—tty选项
  • — 提高Node的稳定性:根据内存的压力,适当剔除一些pods
  • — 增加了对NVDIA的GPU支持,当前为alpha版
  • — 将Loadbalancer和Nodeport的服务添加到配额体系中

V1.2.0

2016年3月17日

Kubernetes 1.2版本具有划时代的意义,在这个版本中,K8S的集群规模得到质的提升,”声明式”的Deployment、支持动态配置管理的ConfigMap、适用于多个计算节点同时部署一个的场景DaemonSet,这些全新的理念和丰富的使用场景让K8S在社区中异常火爆,开始了”Kubernetes rules the world”的征程。

主要更新

  • — 集群规模提升4倍:每个集群支持1000个节点,支撑30000个Pod,减少4倍系统负载
  • — 动态的配置管理ConfigMap被加入到核心API组中,配置信息可以存储在Kubernetes集群中,在容器启动时动态的拉取相应的配置
  • — Deployments实现了声明式的应用的自动发布和升级,它支持版本化,支持同时多个rollout操作,聚合该deployment下的所有pod的状态,保证应用的高可用性和快速回滚
  • — 云上集群可以进行区域划分,服务对应的Pod分布在各个可用区域中,应用在可用区域间容错
  • — DaemonSets简化了在每个节点上容器的运行,对应的服务在每个节点上有且只有一个Pod
  • — Ingress支持TLS和L7基于http的流量转发
  • — kubectl drain可以在比如在节点维护或升级内核的时候先驱逐Pod,然后优雅地删除节点
  • — 支持自定义度量的应用水平扩展
  • — 容易上手的新颖Dashboard,可以和命令行一样跟系统交互

新特性

  • — Job提升:apiVersion: batch/v1现已可用,并且不再需要指定spec.selector.field。兼容老版本的extensions/v1beta1,仍可以通过它进行访问 [GA]
  • — HPA提升:apiVersion autoscaling/v1现已可用,用整型TargetCPUUtilizationPercentage 换了原来嵌套的结构CPUTargetUtilization,默认值为80%,使用ScaleTargetRef直接指向待扩展的资源 [GA]
  • — Kube-proxy默认启用iptables代理,可用参数—proxy-mode指定是userspace还是iptables。如果没指定参数将会参照node的annotaion里proxy-mode进行设置,都没有采用将默认值。如果iptables模式启动失败将退回到userspace模式启动。iptables比userspace性能更好,占用资源更少 [GA]
  • — 通过为系统保留资源提升了节点稳定性 [GA]
  • — 为健康检查和可读性检查添加了三个参数:periodSecond,successThreshold, failureThreshold [GA]
  • — 引入跟ReplicaController很相似但更通用的ReplicaSet [beta]
  • — 可以对ReplicaSet、ReplicaController、以及Deployment进行扩展 [beta]
  • — kubectl run命令默认产生Deployment和Job
  • — 用户可指定Pods的安全上下文
  • — 支持SELinux的卷可以自动使用SELinux上下文作标签
  • — 稳定的go client库发布了1.2版 [stable]
  • — 通过Kubelet新的度量API可以访问日志、文件系统、磁盘和卷的使用情况
  • — 动态提供持久卷(Persistent Volume)
  • — 支持并行运行多个调度器(scheduler)
  • — 更具表现力的节点亲和性标识,支持节点的“软”亲和。
  • — Pod可以通过annotation指定主机名和子域名。如果匹配到同一命名空间的一个服务,那么会为这个Pod创建FQDN的A记录
  • — SchedulerExtender允许用户实现自定义的调度策略
  • — 新的 Flex Volume Plugin 允许用户可以执行安装在每个节点/usr/libexec/kubernetes/kubelet-plugins/volume/exec/目录的卷插件
  • — Kubelet提供了新的度量API,提供用户友好的方式显示系统信息: 日志、容器的文件系统使用情况、每个Pod挂载的卷的使用情况,和宿主机的磁盘使用情况

V1.1.1

2015年11月19日

为了更好的理解2016年Kubernetes的变化,这里列举一下V1.1.1版本的主要更新和新特性。V1.1.1首次引入了HPA和Job概念,支持HTTP的负载均衡策略也是一大亮点。

主要更新

  • — 支持Pod水平自动扩容(HPA)
  • — 为批处理和仅运行一次的任务提供Job资源
  • — 支持HTTP负载均衡
  • — 提升kubectl对容器的交互和对滚动升级的支持

新特性

  • — 为SC添加非root指令和kubelet检查
  • — 为kube-proxy添加启动事件
  • — 实现了基于iptables的Proxy
  • — 添加了HPA的实验性API
  • — 支持Openstack Keystone认证插件
  • — Kubelet启用优雅删除
  • — Kubectl默认不显示Terminated的Pod
  • — 支持外部IP
  • — 支持OpenID认证
  • — 将-t参数的含义由—template变为–tty
  • — 默认开启—validate,并提示如何关闭它
  • — 为Controller-Manager添加HPA参数
  • — 支持对Pod的优雅删除
  • — 添加Ceph FS卷插件
  • — 废弃参数create-external-load-balancer
  • — MESOS:添加初始化执行的CPU和内存参数
  • — 阻止apiServer启用证书
  • — 允许用户提供的IP来为K8s创建LoadBalancer
  • — kubectl describe Pod/Node时显示更多信息
  • — 随着K8s二进制包一同分发kubectl 补全
  • — 引入新资源Job
  • — 升级 utils/iptables以支持firewalld
  • — 升级flunted-gcp,使得与K8s关联的日志可导出
  • — 从OpenShift上获取kubectl edit
  • — 修复对于私有仓库的docker 配置格式问题
  • — 支持pod日志的扩展选项
  • — 为kubelet增加参数控制的RLIMIT_NOFILE
  • — 支持特权pod
  • — 从默认的admission controller里去除DenyEscalatingExec
  • — 支持docker 1.8.3
20161219151628

鸣谢:容器时代 大伟

Kubernetes的2016年:野蛮生长

kubernetes阅读(1043)评论(0)

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

发布全记录

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

 

20170116090312

 

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

 

20170116090324

 

火爆的社区

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

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

 

20170116090347

 

贡献榜前三

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

 

20170116090356

 

按代码提交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:

 

20170116090403

 

他们的Github链接是:

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

年度概述

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

 

20170116090411

 

后记

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

20161209082613

欢迎关注译者立尧微信

Google揭露Kubernets未来发展

kubernetes阅读(313)评论(0)

目前Kubernetes虽为目前市面上唯一能同时调度Windows Container以及Linux Container的工具,不过Kubernetes社群的野心不止于此,「企业希望可以将容器排程、管理纳入技术布局,因此得在正式环境中支持Linux Server及Windows Server。」

因此,Google也揭露Kubernetes在未来的新版本中,所要加强的三大方向。首先是社群会与微软紧密合作,加强Windows Server Container的网络骨干结构,「在容器端点上支持原生覆盖网络(network overlay)。」

第二是增进Windows Server节点的安装、设定及诊断功能,包含让它可以部署至AWS、Azure以及GCP等公有云环境。

最后是加强Container Runtime接口,让企业可以更深入地探索、监控以Windows Server为基础的容器。

原文资讯:http://blog.kubernetes.io/2016/12/windows-server-support-kubernetes.html

eBay构建自有工具集成Kubernetes和OpenStack

kubernetes阅读(229)评论(0)

为了让开发人员保持快乐,电子商务公司eBay开发了一个框架,用于在其大规模OpenStack云上部署容器。

eBay云计算基础设施和平台高级总监Suneet Nandwani表示,从eBay云计划的第一天起,该电子商务公司就一直致力于保持开发人员的快乐。这带来了公司的数个挑战和创新,最新的是TessMaster的开发—— 一个在OpenStack上部署Kubernetes的管理框架。

“伴随着Docker的出现,很明显容器成为了开发者喜欢的一种技术。“Nandwani表示。

eBay将集群管理器看作是实现大规模自动化运营的一种潜在途径。Nandwani补充说:“我们觉得可管理性和可操作性伴随着集群管理的改善可以提高。此外,高级规划和集群管理可以提高基础设施的使用效率,从而节省成本。”

该公司探索多种可能,选择Kubernetes作为开发界面。但eBay作为世界上最大的OpenStack实现之一,运行Kubernetes似乎并不适合。

Nandwani解释说:“大多数在内部采用Kubernetes的公司规模都小得多。当你有一个几十个节点的集群,这是一回事,而如果你有七、八个成千上万的节点的集群,事情就完全不同了。”

当它开始在2016年初揭示这个问题时,eBay并不满意现有的解决方案,比如Magnum。

“我们没有看到社区中有什么可以帮助我们,所以我们决定为运行在OpenStack之上的Kubernetes编写自己的管理平台。”Nandwani说。

据介绍,TessMaster可以在OpenStack上部署Kubernetes,可以扩展它,并将它弹出并向下移动。这项工作正在进行,eBay会继续构建管理功能。虽然eBay还没有把TessMaste开源,但有此打算。

 

20170105134620

 

目前,eBay在TessMaster的帮助下部署了七个大型集群,并计划大规模扩展Kubernetes的使用。 “有很多新的应用程序正在开发,甚至也有平台正在开发。eBay的目标是运行在Kubernetes上。”Nandwani说。

eBay 2013年迁移到OpenStack也是因为它对开发者的吸引力。

“当我们第一次构建eBay特有的云时,它工作得相当不错,但缺点之一是不够开放。”Nandwani说。 “因此我们必须训练我们自己的开发人员在我们的云上工作,第二是如何吸引人才,社区正在快速发展,我们却静止不动。在2013年,eBay做出了一个战略决策,迁移到OpenStack。”

像容器一样,OpenStack对像eBay这样的大平台提出了挑战。

Nandwani解释说:“因为OpenStack上的大部分部署比我们的部署小得多,所以没有太多的关注放在如何大规模运行云平台上。一旦云规模大起来,如何监控这个云,如何做容量管理,一旦出现问题如何补救,警告等一大堆问题就会出现。”

eBay在解决这些问题上做了重大的工程方面的努力,其中一些已经共享出来,一些仍然是内部解决方案。 “我们已经开发了很多从工程角度看成熟的解决方案以管理大规模的OpenStack。”Nandwani说。

编译: OpenStack中国社区 Jonathan Zhang
作者:Stephanie Condon
来源:http://www.zdnet.com/article/ebay-builds-its-own-tool-to-integrate-kubernetes-and-openstack/

如何计算Kubernetes节约的成本

kubernetes阅读(613)评论(0)

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

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

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

二、介绍我们的主人公

 

20161127114653

 

让我们设置一个虚构的场景。 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的原因(下)

kubernetes阅读(448)评论(0)

在上一篇文章里,我讲述了让我热爱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真的改变了游戏。

五个热爱Kubernetes的原因(上)

kubernetes阅读(577)评论(0)

简 介

在柏林的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

坦率的讲,企业容器云选Kubernetes(K8S)就对了!

kubernetes阅读(509)评论(0)

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

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

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

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

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

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

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

那么问题来了,基于企业这样的容器化需求和趋势,究竟什么样的企业适合选用容器云,并且是基于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赢得容器之战

kubernetes阅读(369)评论(0)

【编者的话】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。

 

Docker和rkt快别争了,kubernetes(k8s)才是容器生态的中心

kubernetes阅读(446)评论(0)

开源项目 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”将以不同的方式被支持。

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