五个热爱Kubernetes的原因(下)

社区小编 007阅读(805)评论(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的原因(上)

社区小编 007阅读(1212)评论(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)就对了!

社区小编 007阅读(1136)评论(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赢得容器之战

社区小编 007阅读(658)评论(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)才是容器生态的中心

社区小编 007阅读(1015)评论(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”将以不同的方式被支持。

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