2016年Kubernetes(k8s)大事记

kubernetes阅读(373)评论(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阅读(848)评论(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阅读(258)评论(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阅读(198)评论(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阅读(565)评论(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阅读(366)评论(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阅读(478)评论(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阅读(422)评论(0)

本文简单粗暴,直戳泪点,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赢得容器之战

kubernetes阅读(324)评论(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阅读(359)评论(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”将以不同的方式被支持。

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