伸缩Kubernetes到2500个节点中遇到的问题和解决方法

好雨云阅读(6)评论(0)

 

 

Kubernetes自从1.6起便号称可以承载5000个以上的节点,但是从数十到5000的路上,难免会遇到问题。

本片文章即分享Open API在kubernetes 5000之路上的经验,包括遇到的问题、尝试解决问题以及找到真正的问题。

遇到的问题以及如何解决

问题一:1 ~ 500个节点之后

问题:

kubectl 有时会出现 timeout(p.s. kubectl -v=6 可以显示所有API细节指令)

尝试解决:

  • 一开始以为是kube-apiserver服务器负载的问题,尝试增加proxy做replica协助进行负载均衡
  • 但是超过10个备份master的时候,发现问题不是因为kube-apiserver无法承受负载,GKE通过一台32-core VM就可以承载500个节点

原因:

  • 排除以上原因,开始排查master上剩下的几个服务(etcd、kube-proxy)
  • 开始尝试调整etcd
  • 通过使用datadog查看etcd吞吐量,发现有异常延迟(latency spiking ~100 ms)
  • 通过Fio工具做性能评估,发现只用到10%的IOPS(Input/Output Per Second),由于写入延迟(write latency 2ms)降低了性能
  • 尝试把SSD从网络硬盘变为每台机器有个local temp drive(SSD)
  • 结果从~100ms —> 200us

问题二:~1000个节点的时候

问题:

  • 发现kube-apiserver每秒从etcd上读取500mb

尝试解决:

  • 通过Prometheus查看container之间的网络流量

原因:

  • 发现Fluentd和Datadog抓取每个节点上资料过于频繁
  • 调低两个服务的抓取频率,网络性能从500mb/s降低到几乎没有
  • etcd小技巧:通过--etcd-servers-overrides可以将Kubernetes Event的资料写入作为切割,分不同机器处理,如下所示
--etcd-servers-overrides=/events#https://0.example.com:2381;https://1.example.com:2381;https://2.example.com:2381

问题三:1000 ~ 2000个节点

问题:

  • 无法再写入数据,报错cascading failure
  • kubernetes-ec2-autoscaler在全部的etcd都停掉以后才回传问题,并且关闭所有的etcd

尝试解决:

  • 猜测是etcd硬盘满了,但是检查SSD依旧有很多空间
  • 检查是否有预设的空间限制,发现有2GB大小限制

解決方法:

  • 在etcd启动参数中加入--quota-backend-bytes
  • 修改kubernetes-ec2-autoscaler逻辑——如果超过50%出现问题,关闭集群

各种服务的优化

Kube masters 的高可用

一般来说,我们的架构是一个kube-master(主要的 Kubernetes 服务提供组件,上面有kube-apiserver、kube-scheduler 和kube-control-manager)加上多個slave。但是要达到高可用,要参考一下方式实现:

  • kube-apiserver要设置多个服务,并且通过参数--apiserver-count重启并且设定
  • kubernetes-ec2-autoscaler可以帮助我们自动关闭idle的资源,但是这跟Kubernetes scheduler的原则相悖,不过通过这些设定,可以帮助我们尽量集中资源。
{
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [
 {"name" : "GeneralPredicates"},
 {"name" : "MatchInterPodAffinity"},
 {"name" : "NoDiskConflict"},
 {"name" : "NoVolumeZoneConflict"},
 {"name" : "PodToleratesNodeTaints"}
 ],
"priorities" : [
 {"name" : "MostRequestedPriority", "weight" : 1},
 {"name" : "InterPodAffinityPriority", "weight" : 2}
 ]
}

以上为调整kubernetes scheduler范例,通过调高InterPodAffinityPriority的权重,达到我们的目的。更多示范参考范例

需要注意的是,目前Kubernetes Scheduler Policy并不支持动态切换,需要重启kube-apiserver(issue: 41600)

调整scheduler policy造成的影响

OpenAI使用了KubeDNS ,但不久后发现——

问题:

  • 经常出现DNS查询不到的情况(随机发生)
  • 超过 ~200QPS domain lookup

尝试解决:

  • 尝试查看为何有这种状态,发现有些node上跑了超过10个KuberDNS

解决方法:

  • 由于scheduler policy造成了许多POD的集中
  • KubeDNS很轻量,容易被分配到同一节点上,造成domain lookup的集中
  • 需要修改POD affinity(相关介绍),尽量让KubeDNS分配到不同的node之上
affinity:
 podAntiAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 - weight: 100
 labelSelector:
 matchExpressions:
 - key: k8s-app
 operator: In
 values:
 - kube-dns
 topologyKey: kubernetes.io/hostname

新建节点时Docker image pulls缓慢的问题

问题:

  • 每次新节点建立起来,docker image pull都要花30分钟

尝试解决:

  • 有一个很大的container image Dota,差不多17GB,影响了整个节点的image pulling
  • 开始检查kubelet是否有其他image pull选项

解决方法:

  • 在kubelet增加选项--serialize-image-pulls=false来启动image pulling,让其他服务可以更早地pull(参考:kubelet启动选项
  • 这个选项需要docker storgae切换到overlay2(可以参考docker教学文章
  • 并且把docker image存放到SSD,可以让image pull更快一些

补充:source trace

// serializeImagePulls when enabled, tells the Kubelet to pull images one
// at a time. We recommend *not* changing the default value on nodes that
// run docker daemon with version < 1.9 or an Aufs storage backend.
// Issue #10959 has more details.
SerializeImagePulls *bool `json:"serializeImagePulls"`

提高docker image pull的速度

此外,还可以通过以下方式来提高pull的速度

kubelet参数--image-pull-progress-deadline要提高到30mins
docker daemon参数max-concurrent-download调整到10才能多线程下载

网络性能提升

Flannel性能限制

OpenAI节点间的网络流量,可以达到10-15GBit/s,但是由于Flannel所以导致流量会降到 ~2GBit/s

解决方式是拿掉Flannel,使用实际的网络

  • hostNetwork: true
  • dnsPolicy: ClusterFirstWithHostNet

这里还有一些注意事项需要详细阅读


想要简单易用、生产就绪的Kubernetes?试试好雨Rainbond——以应用的方式包装Kubernetes,理解和使用更简单,各种管理流程开箱即用!

好雨Rainbond(云帮)是一款以应用为中心的开源PaaS,深度整合基于Kubernetes的容器管理、Service Mesh微服务架构最佳实践、多类型CI/CD应用构建与交付、多数据中心资源管理等技术,为用户提供云原生应用全生命周期解决方案,构建应用与基础设施、应用与应用、基础设施与基础设施之间互联互通的生态体系,满足支撑业务高速发展所需的敏捷开发、高效运维和精益管理需求。

 

Docker化应用有多少?5年350万个,2018年Docker使用率出炉

中文社区阅读(724)评论(0)

历经5年发展,Docker公司揭露了今年最新的Docker年度数据报告,从2013年3月PyCon大会上,Docker首度亮相之后,至今在Docker上的容器镜像下载次数已经超过了370亿次,容器化的应用有高达350万个,目前在LinkedIn网站上的Docker相关职缺也有15,000个。全球活跃的Docker使用者社群已有200多个,包括台湾也有。全球使用企业版Docker EE的企业顾客目前则约有450家。

而过去一年,Docker功能的进展不多,主要有拥抱Kubernetes,在Docker产品中可以和Swarm并用。其次最重要的新功能是增加了RBAC角色存取控管机制,这也是企业最想要的安全机制。另外Docker也推出了传统应用MTA计划,提供一个企业将老旧应用容器化的建议方法。

Kubernetes 1.10发布:更趋稳定的存储、安全与网络功能

中文社区阅读(3584)评论(0)

我们今天兴奋地宣布,Kubernetes在2018年年内的第一个版本——1.10版已经正式发布!

此次新版本的推出不断提升Kubernetes的成熟度、可扩展性与可插入性。本次最新版本提升了三大关键性功能的稳定度,分别为存储、安全与网络。另外,此次新版本还引入了外部kubectl凭证提供程序(处于alpha测试阶段)、在安装时将DNS服务切换为CoreDNS(beta测试阶段)以及容器存储接口(简称CSI)与持久本地分卷的beta测试版。

下面,让我们深入探讨此次新版本中的几项核心特性:

存储——CSI与本地存储迎来beta测试版

这是存储特别兴趣小组(简称SIG)一次极具影响力的发布内容,标志着其在多种功能层面都已经真正实现成熟。容器存储接口(简称CSI)在Kubernetes中的实现方案终于迎来beta版本:如今,安装新的分卷插件就如同部署pod一样简单。这反过来又使得各第三方存储供应商能够在核心Kubernetes代码库之外独立开发自己的解决方案,从而进一步延续了Kubernetes生态系统的可扩展性。

在本版本中,持久(非共享)本地存储管理也迈向beta阶段,这意味着本地连接(非网络连接)存储可作为持久分卷源使用。如此一来,分布式文件系统与数据库的性能将进一步提升,而使用成本则有所降低。

此版本还包含对持久分卷的多项更新。Kubernetes如今可以自动防止某一pod正在使用的持久分卷声明遭到删除(beta阶段),同时亦可防止删除与持久分卷声明绑定的持久分卷(beta阶段)。这将有助于保证用户以正确的顺序删除存储API对象。

安全——外部凭证供应方(alpha阶段)

已经具备高度可扩展性的Kubenetes在1.10版本当中得以对接kubectl凭证提供程序(alpha阶段),从而进一步提升扩展性水平。各云服务供应商、厂商以及其他平台开发者现在能够发布二进制插件以处理特定云供应商IAM服务的身价验证,或者与Active Directory等并非天然受到支持的内部身份验证系统相集成。这一调整补充了1.9版本当中新增的云控制器管理器功能。

网络——利用CoreDNS作为DNS提供程序(beta阶段)

新版本允许您在安装过程中将DNS服务切换为CoreDNS,这一功能目前处于beta阶段。CoreDNS的移动部件更少——仅拥有单一可执行文件与单一进程,且可支持更多其它用例。

社区中的各个特别兴趣小组(特立独行SIG)继续面向各自专业领域提供增强贡献、修复与功能开发。关于SIG的完整内容列表,请点击此处参阅发行版说明。

推出时间

Kubernetes 1.10目前已经在GitHub上正式开放下载。若要开始使用Kubernetes,请点击此处查阅交互式教程。

两天功能博文系列

如果您有意深入探索这些新的功能特性,请关注我们将于下周发布的两天Kubernetes博文系列,其中将重点介绍以下内容:

  • 第一天——容器存储接口(简称CSI)迎来beta测试阶段。
  • 第二天——本地持久分卷迎来beta测试阶段。

发布团队

此次新版本的推出源自成千上万技术与非技术贡献者们的不懈努力。这里要特别感谢Kubernetes项目微软代表Jaice Singer DuMars领导的发布团队。该团队的十名优秀成员做出大量协调努力,包括说明文档、测试、验证以及功能完整性等等。

随着Kubernetes社区的不断壮大,我们的发布流程也代表着开源软件开发工作中的一轮重要合作。Kubernetes继续在快速发展当中持续吸引到新的用户,而这种增长也创造出积极的反馈周期,使得更多贡献者承诺加入进来以创建一个更具活力的生态系统。

项目推进速度

云原生计算基金会(简称CNCF)继续完善着这一雄心勃勃的项目,并着力为其带来无数贡献成果。K8s DevStats中展示了各主要企业贡献者的具体贡献情况,其中亦包含一系列关于个人贡献者及其pull请求生命周期的预配置报告。随着自动化程度的提升,发布末期的问题数量仅略高于初期阶段。这标志着问题的可管理性迎来了重大转变。凭借着75000多条评论,Kubernetes继续在GitHub上成为最具活力的项目之一。

用户亮点

根据CNCF方面发布的一项调查,超过49%的亚洲受访者利用Kubernetes进行实际生产,另外49%受访者则正在评估将其引入生产流程的可能性。目前众多大型全球性机构正大规模使用Kuberentes从事生产活动。近期公布的社区用户故事包括:

全球最大的电信设备制造商华为公司将其内部IT部门应用迁移至Kubernetes上运行,使得全球部署周期从原本的一周缩短到数分钟,应用交付效率因此提高十倍。

全球五大在线旅行社及酒店集团之一的锦江之星旅游公司利用Kuberntes将其软件发布时间由数小时缩短至数分钟,并利用Kubernetes提高在线工作负载的可扩展性与可用性。

来自德国的媒体与软件企业Haufe Group利用Kubernetes将新版本发布时间控制在半小时以内——而非原本的数天。此外,该公司还能够借此将夜间容量缩减至原本的一半,从而实现30%的硬件成本节约效果。

全球最大资产管理企业BlackRock得以利用Kubernetes实现运营效率提升,并在100天之内完成了一款投资者研究Web应用程序的开发与交付。

Kubernetes是否也给您的团队带来切实帮助?请点击此处与整个社区分享您的经历。

生态系统更新

CNCF正在扩展其认证产品规模,包括认证Kubernetes应用开发者考试(简称CKAD)。CKAD考试旨在证明个人在Kubernetes设计、构建、配置与面向Kubernetes发布云原生应用程序的能力。CNCF正在为这一新项目物色beta测试人员。感兴趣的朋友可以点击此处了解更多信息

Kubernetes说明文档如今提供用户旅程资料:基于读者的个人情况及希望达到的目标制定专门的发展路线。对入门者而言,如今Kubernetes的学习难度已经远低于以往,而更具经验的用户亦可找到专门针对集群管理员及应用程序开发者的高质量教程。

CNCF还提供在线培训,用于教授您创建并配置实际Kubernetes集群所必需的各类技能。

原文链接:http://blog.kubernetes.io/2018/03/kubernetes-1.10-stabilizing-storage-security-networking.html

译者:Andy,来源:DockOne

后Kubernetes时代,带你系统梳理K8S 12大关键特性

数人云阅读(2000)评论(0)

导读:

Kubernetes如今风靡一时,所有主要的云服务提供商都将其作为部署云原生应用的解决方案。Kubernetes有哪些显著的特性和工具优势,让企业开始接受它?本文作者给出了系统的梳理。

“Action without orchestration is burn out; orchestration w/o action is management.”  

没有编排的行动是完蛋的,没有行动的编排是管理,行动加上编排是领导。― Orrin Woodward”

Kubernetes是一种优化资源利用率的抽象概念,它允许跨节点集群高效地进行应用程序分发。

Kubernetes,舵手 !

Kubernetes是一个希腊语单词,意思是“舵手”。

它是一个由谷歌开始的开源项目,从Borg衍生而来,在谷歌内部使用了好几年,现在用于容器管理。目前由CNCF托管。

Kubernetes(缩写为K8S)是一种抽象,它通过容器来优化CPU和内存等资源的利用率,从而可以跨多个节点高效地进行应用程序分发。K8S可以在裸金属或任何云基础设施提供商的任何地方运行。这个新工具是云无关的,聚焦于在基础设施内部部署和调度容器,而不是直接利用节点/主机。

K8S提供的一些平台特性是:

使用pod进行容器分组
自愈
自动伸缩
DNS管理
负载均衡
滚动更新或回滚
资源监控和日志记录
Kubernetes 架构

Kubernetes集群由主节点和一组worker/从属节点组成。

Kubernetes的主节点组成部分是:

  • API服务器(API Server)用户通过Rest操作或kubectl cli与manifestyaml交互。它用于所有与API对象相关的操作,如pod创建,它是在etcd中存储所需状态的唯一组件。
  • 调度器(Scheduler):用户使用kubectl cli向API服务器发出一个命令来创建pod。在执行此操作之后,调度程序根据资源需求将pods分配给可用节点。
  • 控制器管理器(Controller Manager):控制器管理器基于集群状态对资源进行操作,并根据清单yaml进行更改,将当前状态应用程序达到所需状态。换句话说,控制器管理器可以将实际状态与所需的状态进行协调。在控制器管理器中有多个专用的控制器,以便简化集群管理。例如,节点控制器检查是否有当前正在运行的节点停机,并采取纠正措施,而复制控制器确保在节点中实际运行所需的pod数量。
  • etcd:所有关于集群状态的配置信息都以key/value对的形式存储在etcd中,这个组件由CoreOS实现。这些状态显示了集群中包含的节点和需要在其中运行的pods。
  • 插件(Addons):为了将服务器DNS记录添加到Kubernetes,我们需要一个集群DNS 插件。该插件有助于扩展与Kubernetes集群或节点相关的功能。还有许多其他的插件,比如用于日志记录的fluntd、基于角色访问的rbac等等。

安装在Kubernetes节点中的组件是:

  • Docker: Docker守护进程在每个节点中运行。如果容器镜像不存在,那么它将从docker注册中提取并运行。
  • Kubelet: Kubelet节点代理定期检查容器内容器的健康状况。此外,它还确保按manifest安装卷,并下载运行容器所需的敏感信息。它还将节点链接到API服务器。
  • Kube-proxy: Kube-proxy在每个节点上运行,以便在pod中进行负载分配,并为外部主机提供可用的服务。它使用iptable规则或轮询调度来将请求转发到正确的容器。

对于高可用和容错的Kubernetes生产和部署,需要多个主节点和一个单独的etcd集群。如果运行了三个API服务器,则需要一个网络负载平衡器来正确地将负载分配到服务器。唯一剩下的问题是需要三个角色来管理控制器管理器和调度器以维护集群状态和分配节点。为了更高效、更可靠地执行它,只有一个参与者应该执行实际的更改,但是在机器宕机的情况下仍然需要其他实例。为了解决这个问题,我们可以在API中使用lease-lock 来执行主选,而使用它的标志是leader- elect。

Kubernetes通过以下任一种方式实现从Pod到Pod的联网:

1)第2层(切换解决方案)
2)第3层(桥接解决方案)
3) overlay解决方案(weave andflannel)

它们允许在集群中进行Pod和Pod之间的通信,并为每个Pod提供唯一的IP地址。

Kubernetes关键特性

Pod: Collection of Containers容器集

pod是K8S中的一个部署单元,它有一个单独的IP地址。在它内部,Pause容器通过持有一个网络的名称空间、端口和ip地址来处理网络,而这个地址又被pod中的所有容器使用。

ReplicationController

ReplicationController确保在给定的时间内启动和运行所需的容器数量。Pod模板用于定义容器镜像标识符、端口和标签。使用liveness probes,它可以自动治愈pods,并按照期望的状态维持pods数量。也可以通过使用kubectl来手动控制副本计数。

存储管理

Pods本质是短暂的——任何储存在pod或容器中的信息都会丢失。为了存储数据,一个持久的系统是必需的,即使在一个pod被杀死或重新调度之后,如Amazon Elastic Block Storage (EBS),谷歌GCE PD,或一个分布式文件系统,如网络文件系统(NFS)或Gluster文件系统(GFS)。

资源监控

监控是成功运行基础设施的关键之一,它是可靠性等级的基础。Heapster是一个从kubelet收集指标的插件,与cAdvisor集成。cAdvisor用于收集与运行容器的CPU、内存、I/O和网络统计数据相关的指标。由Heapster收集的数据存储在influx DB中,并使用Grafana在UI中显示。还有其他可使用的接收器,如Kafka或Elastic Search,可以用于存储数据并显示在用户界面中。

健康检查

kubernetes的健康检查由kubelet代理完成。它分为liveness 和 readiness probes两种。

处理程序主要有三种类型:

ExecAction:执行Shell命令,如果生成的退出代码为0,则意味着实例是健康的。在任何其他情况下,实例不健康。
TCPAction: Kubelet将尝试连接到指定的端口,如果它建立到给定socket的连接,诊断成功。
HTTPGetAction:基于应用程序公开的HTTP端点,kubelet对指定路径上的容器IP地址执行HTTP GET请求,如果返回200到300个响应代码,诊断就成功了。

每个probe通常有三个结果:

成功:容器通过诊断。
失败:容器未通过诊断。
未知:诊断失败,不要采取任何行动。

水平自动伸缩功能

自动伸缩使用基于负载的计算资源。K8S scale pod自动使用Horizontal Pod Autoscaler对象,从Heapster获取度量数据,并相应地减少或增加pod的数量。例如,如果自动伸缩是基于内存利用率,那么控制器就会开始在pod中观察内存使用情况,并根据容量对该副本计数进行扩展。

服务发现

Kubernetes pods是短暂的,ReplicationController 在任何节点上动态创建它们,因此在集群中发现服务是一个挑战。服务需要发现一个IP地址和动态的端口,以便在集群中进行通信。

有两种主要的方法来找到它——环境变量(Environment variables)和DNS。

更可取的是基于DNS的服务发现,它可以作为集群附加组件使用。跟踪集群中的新服务,并为每个服务创建一组DNS记录。

 

网络

要完全管理集群,必须正确设置网络,并解决三个网络问题:

1.容器到容器的通信:pods通过本地主机通信,并使用Pause容器网络名称空间,解决这个问题。
2.Pod-to-Pod通信:由软件定义的网络解决,如上面架构图所示。
3.外部到pod通信:由服务覆盖。

Kubernetes提供了广泛的网络选择。现在还支持容器网络接口(CNI)插件,这是容器的通用插件架构。目前支持多种编排工具,如Kubernetes、Mesos和CloudFoundry。

有各种覆盖插件:

1.Flannel来自CoreOS,是一个非常简单的etcd后端覆盖网络。它创建了另一个虚拟的、可路由的IP / Pod网络,运行在底层网络之上;ergo,称为覆盖网络。在这个覆盖网络中,每个Pod将被分配一个IP地址,并且会直接使用它们的IP进行通信。
2.Weave通过CNI插件提供与Kubernetes兼容的覆盖网络。

服务

Kubernetes服务是一种抽象,它将通信路由到一组pod,以提供一个微服务。Kube-proxy在每个节点上运行,并通过设置一组iptable规则来管理服务。

设立服务的模式有三种:

1.ClusterIP(只提供内部访问)
2.NodePort(需要在端口上打开防火墙;不建议公开访问)
3.负载均衡器(由AWS或GKE等公有云供应商拥有)

ConfigMap和Secret

ConfigMap使注入基于环境的配置成为可能,同时使容器镜像在多个环境中保持一致。这些可以通过安装卷或环境变量(environment variables)来注入,并将这些值存储在key/value格式中。

Secrets用于存储敏感数据,如密码、OAuth令牌等。

滚动部署和回滚

部署对象持有一个或多个副本集,以支持回滚机制。换句话说,每次更改部署配置时都会创建一个新的副本集,并保留以前的版本,以便有回滚选项。只有一个副本集将在特定时间处于活动状态。

对于滚动部署,需要的策略类型是RollingUpdate和minReadySecs,它指定应用程序为服务流量所花费的时间。如果在应用程序pod还没有准备好时,将其保持默认状态,它将不可用。这个动作可以通过以下命令来完成:

或者,

通过替换部署yaml文件中的内容并运行以下命令:

如果新版本不像预期的那样,那么可以通过运行以下命令回滚到以前的版本:

如果所需版本是前一版本以外的版本,则运行:

Logging记录

要监视应用程序的行为,必须检查日志——每个pod生成多个日志。要开始在仪表板UI中搜索日志,必须有一些机制收集并将它们聚合到一个日志查看器中。为了说明这一点,Fluentd是一个开源工具,也是CNCF的一部分,与 Elastic Search 和 Kibana 完美结合。

 

原文链接:

Kubernetes: Twelve Key Features

https://dzone.com/articles/kubernetes-twelve-key-features

推荐活动:

数人云联合ServiceComb、ServiceMesh社区举办的 Building Microservice Meetup系列活动第2站–3月31日,北京站开始报名啦!本期主题为微服务,从架构到发布》依旧大咖汇集,点击链接快来报名~

相关阅读:

【详解】以银行零售业务为例,一个案例说清楚可视化微服务架构

有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求

添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群

CNCF得意门生结业,Kubernetes全面走向成熟

中文社区阅读(826)评论(0)

两年多之前,CNCF(即云原生容器基金会)正式成立,而其技术领导者们则热烈欢迎Kubernetes成为其首个参与项目。自那时以来,该基金会迅速吸引到更多新的贡献者,外加各类组织、云服务供应商以及用户的广泛参与。即使是在“高手林立”的GitHub上,Kubernetes也在提交量方面排名第九,作者/问题数量更是排名第二——仅次于开源界的至高成果Linux。

优步、彭博、Blackrok、BlaBlaCar、《纽约时报》、Lyft、eBay、Buffer、Ancestry、GolfNow、高盛投资以及其它众多全球性组织都在着手建立大规模生产性Kubernetes。目前,三家规模最大的云服务供应商皆提供自己的托管Kubernetes服务。此外,根据Redmonk公布的数据,全球财富一百强企业当中有71%在使用容器,而超过半数财富百强企业利用Kubernetes作为其容器业务流程平台。

出于上述原因,CNCF技术监督委员会(简称TOC)通过投票表决,最终认定Kubernetes成为该基金会的首个结业项目。获得这一称号将给Kubernetes带来多方面助益。这标志着Kubernetes已经拥有充分的成熟度与弹性水平,足以在任何行业中的各类企业内对容器进行大规模管理。而作为“结业项目”,Kubernetes将处于更为强大的地位,能够更快地发展并始终保持住自己充满活力、健康且多元的技术社区。

多达11258位开发贡献者、GitHub上拥有75000多次提交以及全球Meetup组中的15万8千名成员,反复证明着Kubernetes社区所展现的活力与延伸水平。Kubernetes在30个发展速度最快的开源项目当中排名第三。凭借这样的排名,很多人甚至将Kubernetes定义为开源历史上发展速度最快的项目之一。Redmonk在最近发布的一篇博文当中[1],也表示Kubernetes是其见过的发展最快的技术方案之一!在另一方面,Kubernetes项目非常庞大,包含近100套资源库,因此我们不得不自行开发管理审批权限机制。我们拥有数百名审批者,他们在项目中超过4000个OWNERS文件当中有所体现。感兴趣的朋友可以点击此处[2]通过CNCF的Devstats仪表板查看Kubernetes令人印象深刻的提交与贡献合并流程——根据该仪表板所示,Kubernetes项目每月需要处理成千上万次这样的合并。

为了正式从孵化状态中结业,Kubernetes还必须获得(并保持)核心基础设施项目最佳实践徽章(简称CII徽章)[3]。这项目标于2016年8月即告完成,标志着Kubernetes项目对于代码质量与安全最佳实践作出的明确承诺。另外,为了保持迅猛的发展速度,该项目的治理与社区管理实践也在随着项目自身的发展而不断变化及成熟。Kubernetes还通过了CNCF的行为准则考核,此项考核是为了传递“贡献者人人平等”这一关键性理念。

COO Chris Aniszczyk在奥斯汀召开的KubeCon大会上展示Chop Wood/Carry

从技术角度来看,Kubernetes在2017年先后发布了四个版本。最新的1.9版本包含一个稳定的核心工作负载API、面向Windows服务器容器的beta支持功能(用户可借此在Kubernetes上运行基于Windows与.Net的容器)。另外,通过启用CSI支持,该项目还可充分发挥云原生存储选项的巨大优势。这意味着存储供应商能够更轻松地支持Kubernetes,并为最终用户提供更多存储选项与开放性解决方案。这一最新版本所引发的媒体报道热度也达到新的历史水平;通过社交媒体渠道发布的各类文章共计237篇,转载超过4000次。

Kubernetes的1.10版本预计将于今年3月底发布,感兴趣的朋友不妨关注http://blog.kubernetes.io/ 以了解更多发布细节。Kubernetes,祝贺你!今天是你的好日子。你将踏上更伟大的征程,并迎接更加光明的未来!

相关链接:

  1. http://redmonk.com/sogrady/2018/03/02/the-kubernetes-lesson/
  2. https://k8s.devstats.cncf.io/
  3. https://bestpractices.coreinfrastructure.org/projects/569

原文链接:https://www.cncf.io/blog/2018/03/06/kubernetes-first-cncf-project-graduate

江湖路远,Kubernetes 版图扩张全记录

中文社区阅读(2585)评论(0)

今天的这个故事出自“江湖”,一半关于各路豪杰的江湖纷争、聚合反目;另一半关于 Kubernetes 从初出茅庐到异军突起走过的蜕变之路。

“ 如果有一个 workload 到了亚马逊那儿,你们就完了!” 2013 年,VMware 公司首席执行官 Pat Gelsinger 在公司的合作伙伴交流大会(Partner Exchange Conference)如是说。“现在到永远,我们都要拥有公司的 workload”。作为前英特尔资深经理, Gelsinger 的这些话对云计算五年前的情景作了很好的还原:彼时,VMware 还认为自己是宇宙的中心,并试图捍卫和巩固自己的地位。亚马逊正努力将数据中心迁移到自己的公有云领域。

那时的 Gelsinger 肯定没想到,四年后,他确实再也不用担心失去公司的 workload 了。一场让他意想不到的“江湖纷争”即将袭来,他要对付的可不仅仅是老对手 Amazon 了。

重新洗牌

VMware 一统江湖

“VMware” 中的 “VM” 代表虚拟机,它成为了组织在云平台上部署应用程序的第一个工具。虚拟机的出现引发了大众对“可移植性” (即在任何地方都能部署应用程序)的渴望。但是 VMware 聪明地通过部署和管理虚拟机的方式来保护自己的利益,使得 vSphere 成为所有入站道路的必须监督者。

理想的践行者 Docker

然后,Docker 出现了。它是第一个将“可移植性”赋予数据中心的工具。2013 年,Docker 开发了一个容器机制,将 workload 从笨重的操作系统中解救出来,来维护虚拟机。这样,他们就可以使用 Linux kernel 而不是虚拟机监视器来进行管理。这是当时众多组织触不可及的 “革命理想”,但只有 Docker 践行并实现了。

从出现伊始, Docker 就遭遇了来自企业的质疑目光。同时出现的还有一个广为流传的论断:一个新的市场即将围绕着 Docker 容器形成。套用 PC 世界的旧模板,软件市场当时也是围绕格式和兼容性形成的。推断下去,接下来将出现各大容器公司相互竞争的局面,然后是优胜劣汰,紧接着 Docker 或者其他更强大的竞争对手,会从对手的灰烬中取得最终胜利。

只有当“可移植性”无处不在时,才实现了真正的可移植。2015 年,Docker 放大胆子赌了一把,将整个容器 format 捐赠给了 Linux 基金会赞助的一个开源项目。这个项目现在被称为 Open Container Initiative(OCI)。彼时的 Docker 计划先行一步,放弃人人想要的“可移植性”,让容器 format 增值。Docker 捐赠了容器 format,让竞争对手再也找不到与之竞争的明确方向,Docker 笃定它的未来就在部署和维护容器 workload 的机制上。

Kubernetes 初出茅庐

就在同年,谷歌推动建立了一个独立基金会:Cloud Native Computing Foundation (CNCF)。 CNCF 与 OCI 有很多相同的成员,但 CNCF 专注于容器 workload 的成员们,试图在“部署和管理”方面寻找竞争优势。紧接着,CNCF 就推出了 Kubernetes,这个编排工具将谷歌工作workload staging 概念与 Docker 容器相结合(最初名为“Borg”)。

Red Hat 公司围绕 Kubernetes 重建了 OpenShift PaaS 平台,而 CoreOS 将其业务重点转向 Tectonic,即 Kubernetes 的商业实施。

Kubernetes 的野蛮生长

就像推倒了一块多米诺骨牌,容器领域的众多利益相关者在 2017 年一个接一个地将部署和管理战略倒向了 Kubernetes,包括 Docker 公司本身 :

  • 4 月,托管的 OpenStack 云管理服务提供商 Mirantis,宣布将 Kubernetes 集成到其云平台 1.0 中,并承诺将其 Staging 和配置机制的重点从以安装人员为中心模式,转向以 workload 为中心模式。
    同月,微软收购了基于 Kubernetes 的容器部署平台制造商 Deis,以前所未有的姿态向 Azure 开放平台迁移。紧接着 Deis 技术在 Azure 上出现。 ( 2016 年 6 月微软就已经从 Google 挖走了 Kubernetes 的创始人 Brendan Burns。)
  • 5 月,在波士顿举行的 OpenStack 峰会上,OpenStack 许多社区领导齐聚一堂,承认 Kubernetes 是其私有云模型中,容器 workload 的事实 staging 环境。当时还有一个亟待解决的问题:Kubernetes 或 OpenStack 究竟应该留在虚拟基础架构的最底层,还是应该针对每个客户的情况合理地解决这个问题?
    几乎在同时,IBM 推出了 Kubernetes 支持的云容器服务,向客户提供了一种无缝、即刻启动 Docker 容器的方法。
  • 6 月初,Oracle 在开源会议上承认 Kubernetes 是其新容器 Staging 策略的核心。作为 Docker 的竞争对手,CoreOS 自从平台成立以来就被称为 “Tectonic 的商用 Kubernetes 环境的生产者”。 CoreOS 把最小的 Linux kernel 贡献给 Oracle,Oracle 把自己的 Linux 踢到了一边。
  • 6 月末,在 Cloud Foundry 峰会上,Cloud Foundry 基金会发布了 Kubo,这是一种在传统机器内部 staging Kubernetes 的多个负载均衡实例的工具。这为 8 月份的VMware 和姊妹公司 Pivotal 与 Google 建立合作关系打下基础,并推出 Pivotal Container Service(PKS)。这个消息发布于 Amazon 与 VMware 建立合作伙伴关系一天后,当时 Kubo 已经为 Google 云平台定制进行了商业实施。值得注意的是,在整个 PKS 首次发布会期间,“Docker” 这个词一次也没被提过。(10 月份,Kubo 项目更名为 Cloud Foundry Container Runtime。)
  • 8 月初,亚马逊终于下了“赌注”,加入了 CNCF,并承诺做出实质性贡献。
  • 9 月中旬, Oracle 也正式加入了 CNCF。
  • 9 月中旬,Mesosphere 做出了一个相当惊人的举动,在 beta 版本中,加入了一种整合这两个平台的方法。其用户可以安装、扩展和升级多个生产级 Kubernetes 集群。
  • 10 月中旬,这场容器竞争战似乎发出了即将结束的信号。Docker 宣布拥抱 Kubernetes,Docker 的创始人 Solomon Hykes 在大会上宣布:下一个版本的 Docker 将支持两种编排平台—— Swarm 和 Kubernetes!
  • 10 月下旬,微软推出了一个专门 Azure 容器服务(AKS)预览版,这一次 Kubernetes 不仅站在了“舞台” 中央上,而且 “K” 还是最中间的字母。不久之后,该公司的市场营销和网站给出了它的 Kubernetes 平台的第一个版本,推出了基于 DC / OS 的容器 Staging 平台作为备选方案。
    在同一个月,思科在基于 ACI 的数据中心架构和谷歌云之间,通过 Kubernetes 宣布了一个名为 Goodzilla 的 Bridge。
  • 11 月底,亚马逊正式推出了自己的 AKS 容器服务,并把 AWS 云与 Google 和 Azure 相提并论。

此消彼长

从市场角度来看,所有这些发展都表明:谷歌已经成功地控制了所有通向数据中心容器化道路。众所周知,没有可移植性的容器是毫无意义的,对于数据中心的客户们来说,一个 Staging 和编排环境是远远不够的。

微软第一个证明,通过开源核心优势来迅速占领市场是个可行的办法。当年,它让 Internet Explorer 变得免费,逼得 Netscape 只能通过增加大量不必要的新功能慌张回击,最终还是落得失败下场。Docker 显然也知道这个道理,开源了容器 format,让同类产品不能与之争锋。

然而,Docker 还是没有如当日所愿,建立自己的增值路线——就是那个可以通过开源手段来占领市场的“大杀器”。有人可能觉得,Docker 的基于集群的编排平台 Swarm 还不“成熟”。可是 Kubernetes 在向 Docker 发起进攻的时候可能更“幼稚”,但它有自己的“杀手锏”:相关的容器可以分组到 pod 中。

Red Hat 第一个出来,利用 OpenShift 来展示这一“杀手锏”, 这使得众多开源贡献者都对 Kubernetes 魂牵梦绕。在 Docker 移动创建 OCI 之后, Google 几乎马上就允许 Linux 基金会建立 CNCF,他们的成员几乎是同一拨人,这确保 OCI 部分的设计不会让 CNCF 感到意外,同时也保证了 Kubernetes 在社区讨论桌上的好位置。

Kubernetes 正在进行时

以下是 Kubernetes 正在进行时,在 2018 年肯定会让 Kubernetes 受益:

  • CSI 项目:这个项目最近得到了戴尔技术公司(戴尔 EMC 的母公司)的支持,这个项目承诺,将通过与数据库和 Storage Volume 保持持久链接,提供微服务 。使用 CSI 接口,任何打开这种持久链接的 API 都可以通过三个主要容器编排平台:Kubernetes,Mesos(DC / OS)和 Swarm 进行同样寻址。它目前由 Moby 管理,而 Moby 却是由 Docker 原始的开放源代码产生的,但现在 Moby 有一个独立的方向。这对于 Kubernetes 而言非常有利,开源数据 Plugins 的主题再也不是 Docker 领地中的本地特性了。
  • CRI-O 项目:它利用 Kubernetes 的原生 Container Runtime Interface (CRI),使容器编排平台能够通过本地 API(一个称为“runtime”的可寻址组件)实例化一个容器。目前在许多数据中心,生产环境把 Docker Engine 作为 Orchestrator 和 Runtime 之间的中介; CRI-O 专门为 Kubernetes 提供让 Docker 完全隔离在生产环境的方法,让它只能出现在开发人员的工作台上。
  • Kata 项目:Kata 与 Docker 的竞争对手 Hyper 一同加入英特尔的 Clear Containers 项目中。Kata 可以为数据中心提供构建和部署 workload 的方法,Docker 将会完全被淘汰,同时还能够在基于容器的 workload 和第一代虚拟机之间共存。OpenStack 基金支持这个项目,它将利用 Kubernetes 作为其主要容器编排平台。

然而即便迎来了如此全胜局面,Kubernetes 仍然面临着巨大的挑战。具体来说,Kubernetes 可能变得如此无处不在,如此标准化,以至于任何供应商或开源贡献者都难以围绕它再创造竞争优势了。

路漫漫其修远兮

对于数据中心来说,Kubernetes 的突然出现意味着:过去基于公有云的 PaaS 平台,如 Heroku 和原来的 Windows Azure,只有使用它支持的资源和语言才可用。而现在,只要使用 Kubernetes,每个人的平台都支持容器内部,而不是外部。这有助于在一定程度上平衡服务提供商,因为他们现在都可以提供相同的界面来获取和托管客户的 workload。这也缩小了这些提供者在服务上彼此竞争的空间。规律如此,每当市场商品化,幸存者都是那些赢得价格战的人。

Kubernetes 可能已经在 2017 年完全超过了 Docker。但是市场瞬息万变,谁又能保证在 2018 年 Google 或其他任何人不会超过它呢,江湖路远,让我们拭目以待!

看后Kubernetes时代 – 容器生态2017

中文社区阅读(2325)评论(1)

如果说2017年的容器技术圈子只能用一个关键词来概括的话,那一定非“Kubernetes”莫属。

从2017年2月,“Kubernetes”开始频繁登上各大技术媒体头条,来自不同维度不同渠道的商业分析和技术文章也纷至沓来。有趣的是,无论是官方报道还是个人评述,无论是直接还是委婉,无一不在透露着一个同样的信息:“Kubernetes要赢!”

可是,描述这样一个连商业实体都没有的开源项目“要赢”,总是听起来有些奇怪。

“要赢谁?”

“为什么要赢?”

“赢了之后呢?”

我们不妨就从这个论断说起吧。

Kubernetes赢在何处

如果说错失了Big Data时代的Google实在令人扼腕,那么Container时代的Google终于靠开源社区打了个翻身仗。虽然在最初的lmctfy项目(Google自研容器)上依然栽了跟头,虽然同Docker公司共举容器编排大业的计划依然吃了闭门羹。但Google还是笑到了最后。

不过,Kubernetes项目的发展绝非一帆风顺。它的前期只有一篇不温不火的B类会议文章Borg来站台,远没有“三大paper”一举奠定大数据基石那么耀眼。而在它发布的之后,炙手可热Docker公司却始终拒绝同Google开展任何形式的合作。而与此同时,Mesos等一票老牌调度系统的阴影则从一开始就让Kubernetes团队心有芥蒂。种种不利因素,再加上当时Google在Kubernetes上投入资源时的捉肘见襟,无论再怎么乐观,这个“要赢”的论断恐怕都不容易成为现实,

当然,如果不是Google找到了一个靠谱的盟友的话。

这位盟友有多靠谱?它是这个世界上唯一一家年盈利超10亿美元的开源技术公司。

Kubernetes刚发起的时候,其核心的理念来自几位“Elder(元老)”的构想,他们大多是Borg和Omega项目的开发者或者架构师,一直专注于如何在没有cloud的场景下构建足够规模的通用Infrastructure Layer的实践,并且在这个领域摸索的过程中,这批技术人员也逐渐形成了一套创新性的设计理念,这些观点在Borg论文中曾经透露出了一些端倪,但真正全面揭晓还是依托于Kubernetes开源项目。所以如果大家回头去翻Kubernetes最早的一些Issue和Design,其实都是一篇篇“小论文”,思路严谨,论证充分(废话连篇),这跟大多数开源项目早期的头脑风暴,或者围绕一个核心设计逐渐展开的做法,是有很大不同的。

另一方面,彼时的RedHat正苦于自家OpenShift被竞争对手碾压的境况。经典PaaS不能破局的困难,反倒让RedHat对Docker这个有望颠覆PaaS的项目格外上心。这样一个在操作系统领域积累深厚、资源充足、并且蠢蠢欲动以求变革的开源巨头,碰上了满脑子Idea却对全面推进Kubernetes心有余而力不足的Google团队,可谓一拍即合。2014年12月,在Google正式发布Kubernetes项目不久,RedHat即官方宣布与Google开展战略合作,全面投入Kubernetes。在当时的一份官宣中,RedHat以非常自信的姿态表达了对容器的“颠覆性”创新的认可,并大胆预言Kubernetes会在2015年后取得应用编排与管理领域的统治地位:

……(RedHat的竞争对手们) 必须要认识到自研任何容器的局限性,尽早接纳Docker项目 ……

…… (RedHat的竞争对手们)必须要认识到没有人能够同Google在成规模的容器编排和管理领域里相抗衡 ……

谁曾想到,当年这套透露着几分“终于傍上大腿”的侥幸、甚至“托大”的说辞,现在看起来却几乎句句“实锤”。

这也是为何,Kubernetes虽一直大幅受益于Google的声誉和名望,还长期拥有Borg/Omega团队的技术加持,但如果从技术实现上来审视,这个项目却称得上是半个RedHat项目。也正是凭借最初阶段“Google赋予灵魂,RedHat赋予实体”的策略,Kubernetes才能够秉持着天马行空的设计思想的同时,稳扎稳打,然后一步步崛起于社区。

如今的Kubernetes,既赢得了GitHub等众多明星用户的青睐,也受到了全世界所有公有云巨头的热捧,还硬生生把Docker公司逼到改旗换帅、彻底摒弃了以往“暴力不合作”的路线,如果用一个“赢”字来描述它现在的情形,倒也并不为过。不过,这个“赢”字背后的原因,又在哪里呢?

Rancher的创始人梁胜博士最近有过一句评论,可谓道破天机:

时至今日,在容器技术领域依然有许多创新,只不过这些创新大多发生在Kubernetes以及CNCF生态系统中了

没错,容器技术圈的创新能力,在2015年后就已经逐渐转移到了Kubernetes生态,这是一个不争的事实,却也是一个曾经被忽视的变化。实际上,伴随着DockerCon越来越“boring”,Kubernetes的专属生态CNCF基金会却开始风生水起的原因也正在于此。

而从技术的角度上看,Kubernetes生态能取得这样的成功,依托的乃是一项其他竞争对手所不具备的核心能力:“使能用户二次创新“。

何谓“使能用户二次创新”?这其实是Kubernetes项目从开始设计之初就高度重视的一项关键诉求:

第一:从上层API到底层容器运行时,Kubernetes工作流中的每个环节,都希望具备完善的可扩展性。

第二:Kubernetes任何功能特性的设计和实现,都尽可能针对更通用的用户场景而非特定需求。

原生“使能二次创新”的技术基础,加上Google与生俱来的技术号召力,在加上CNCF基金会的整合和商业运作,以Kubernetes为核心所建立起来的这套容器编排生态,绝不比Docker公司最初建立起来的以容器为核心社区有任何逊色。再加上容器编排与管理的概念天生就更接近用户,Kubernetes的理念很快被社区接纳乃至追捧,也是情理之中。

一个直观的例子就是CoreOS的Operator项目。我们知道,在Kubernetes里部署任务,经常使用的是Deployment(Replication)来管理多个副本组成集群。但如果我们这次要部署的任务比较特殊,它的集群需要在增/删副本之后/之前做手动的运维操作呢?各种数据库集群就是最典型的例子。而Operator实际上是个用户自己编写的管理器,通过编程的方式把“运维”逻辑写进了管理器的代码当中。但关键在于,这个管理器的编写过程是完全“无脑”的,无非就是复制粘贴官方模板、然后填充自己的运维逻辑而已。这是因为Operator是构建于Kubernetes的CRD(自定义API资源)特性之上的,这个特性的目的就是允许并帮助用户自己编写一个可以与系统etcd交互的、Kubernetes风格的API资源管理器,并无缝地衔接到Kubernetes的核心API当中。

这个设计看起来很很直白,但是却解决了一个长期以来困扰系统级开源项目的难题:用户对项目的API不满意怎么办?

在过去的实践中,原封不动使用开源项目的场景是非常少见的,更常见的情况是用户把开源项目的API修改的面目全非。但在Kubernetes的场景下,用户的自定义API和原生API可以友好共处,统一对外服务,而且不会随着upstream变更而分家。这是保证Kubernetes社区完整性和被接纳程度的一个核心手段。

更为重要的是,有了这些标准化的扩展性API,用户就可以发挥自己的能动性,在Kubernetes之上构建出更多的扩展,甚至把这些扩展再交还给社区中的其他用户推广和使用。正如CoreOS的Operator,现在已经成为了社区运维有状态应用的一大法宝。

当然,“二次创新”的例子远不止于此。

2017年5月24日,Lyft,IBM联合Google共同宣布了Istio项目,一举撼动了微服务这个以往“光说不练”的“花架子”领域。Istio的核心思想,乃是借助一个proxy来接管容器里业务的进出流量,从而通过在proxy上的控制操作来完成应用流量的切分、访问授权、策略配置等一些列微服务治理功能。可以看到,这里有一个核心问题是:如何保证每一个需要治理的容器都绑定这样一个proxy呢?

解决这个问题的手段就是Pod。作为Kubernetes里的核心概念和原子调度单位,Pod是一组亲密耦合的容器集合,容器之间共享同一Network Namespace,显然,Istio框架中的proxy和业务容器正属于这样的耦合关系。但这还不是关键所在,这里最棘手的问题在于,Istio要做的是一个非侵入型的微服务框架,不可能要求用户在自己的部署文件中每次都额外定义一个proxy容器。怎么办?

答案还是借助Kubernetes。Kubernetes中有一个叫Initializer的扩展机制,允许用户在不修改业务Pod部署描述前提下,请求Kubernetes为业务Pod“自动注入”并启动一个预先定义号的容器。在Istio里,这个自动注入的容器正是前面不断提到的proxy:Envoy(Lyft自研的高性能服务代理)。

可以看到,通过组合Initializer等一系列Kubernetes标准API,用户可以优雅地实现很多以往繁琐或者困难的分布式系统的构建工作:就比如Istio里这套Spring AOP(面向切面编程)风格的组合方式。也正是因为有了这种标准化的实现手段,用户基于Kubernetes的“二次创新”才有可能再次交还给Kubernetes社区,从而碰撞出更多的创新火花和更新颖的用户案例。最终,不断激发出的创新开始吸引了更多人力和资本的进入,而资本与生俱来的促进作用就会推动这个社区的更强势的扩张。这种“开源-社区-商业”互相促进而构建出来的正向激励循环,正是Kubernetes生态在过去一年里“势不可挡”的重要原因。

回想在Kubernetes刚发布的时候,甚至在2017年初,Kubernetes的Pod以及Pod所体现出来的“解耦容器关系”的设计模式,依然时常被质疑为“用处不大”或者“过度设计”,然后现在回头来看Istio项目的炙手可热,我们确实要感慨“技术视野”的培育绝非一朝一夕。

从利用CNI、CRI等一系列良好设计的通用接口来实现不同类型、不同功能的网络和容器运行时,到使用API Aggregation扩展Kubernetes API Server从而支持自定义资源监控格式并以此来做Auto-Scaling,Kubernetes生态之中类似的“二次创新”的例子已然不胜枚举。依托于这种原生地鼓励用户发挥自己聪明才智的先进理念,在2018年,我们有足够的理由相信“二次创新”将继续成为Kubernetes生态中的一大关键词,各种基于Kubernetes可扩展能力的创新工作将成为社区的常态,甚至成为更多团队“一战成名”的不二法宝。

在未来,已经争取到领先地位的Kubernetes项目的进化重点,将逐步转移到安全性、稳定性、多租户能力、规模和性能优化、可扩展性设计等更多横向功能的升级上面。另外,将更多的非核心功能从主干代码中移除也将是未来一段时间Kubernetes社区的主要工作之一。2017年里,随client-go、apimachinery等API库的独立,已经为CRD等可扩展性功能的实现带来了极大的便利,而将来诸如部署工具kubeadm,内置的各种Cloud Provider,内置的rkt集成,各种各样的volume plugin等代码,也都将逐步迁移到它们单独的库中维护,这将有希望大大降低Kubernetes主库的复杂度和维护难度。

另一方面,Kubernetes可扩展性上的另一个重要设计CSI(Container Storage Interface)也已经发布。这意味着不久的将来,就如同容器运行时一样,容器持久化存储方案也将不必再跟Kubernetes的核心代码耦合,Kubernetes将使用统一的gRPC接口在完全独立的控制逻辑中维护容器存储卷(volume)生命周期。这个设计也很有可能会刺激容器存储领域更多的创新工作和更多的存储选择出现在Kubernetes社区当中。而包括KataContainers在内的虚拟化容器运行时,也将受益于存储解耦带来的、完全不同于现有容器存储设计的高性能的持久化存储方案。

在接下来的集群管理能力上,目前最大5000个节点的支持能力已经能够满足大多数用户的生产需求,而IPVS Service的引入也有很大希望能解决以往纯iptables Service引发的大规模集群中性能额外损耗问题。而在调度层面,默认调度器的可配置规则已经大幅增加,调度优先级和抢占技术也已经进入了默认调度器的alpha功能当中。而通过灵活配置亲密/反亲密关系、Taint/Toleration规则,Kubernetes的使用者已经能够解决绝大多数生产环境中的运维和调度需求。

在多租户与安全能力上,Kubernetes项目终于弥补上了这部分的短板。RBAC(基于角色的访问控制)功能目前已经成熟应用于很多基于CRD的Kubernetes外部扩展上面,Secret存储的加密也已经实现,集群部署中的节点通信加密配置也成为了默认功能。而在社区中,更完善的“强多租户”设计也第一次被提出,以便真正满足多租户环境下的集群管理需求。不过需要指出的是,Kubernetes的角色定位依然是Layer 0(Infrastructure Layer),更倾向于对上提供必要的多租户支持API和规范而不是实现完整的多租户模型。后者还是需要依靠Layer 1(Service Layer)来自己完成。

2017年也是人工智能技术席卷全球的一年,Kubernetes在其中也扮演了推波助澜的作用。在与之相对应的硬件加速器(Hardware Accelerator)功能的设计上,Kubernetes社区在Google,NVIDIA和Intel的牵头下发布了Device Plugin来允许用户自己编写自定义的、自发现的高性能硬件资源描述,并且以此为基础,将支持NUMA,InfinitiBand,FPGA等硬件框架的设计纳入了路线图。随着Kubeflow等项目的发布,不难预料到,Kubernetes在新的一年里会继续加大同人工智能社区合作,向成为机器学习领域支撑大规模分布式训练和AI服务的默认框架这一目标上不断挺进,而在此过程中,各家vendor在Kubernetes社区中进行技术上的角逐,亦将成为这个领域的主旋律之一。

随着Kubernetes项目的逐渐稳定,其开发迭代周期也将有所放缓,将目前每3个月一次release周期延长已经被提上讨论日程。与此同时,随着社区自动化管理能力(bot)的提高和SIG(Special Interest Group)组织的进一步完善,现有社区成员的写权限回收也是将来可能发生的大概率事件。这些都是Kubernetes社区逐步走向成熟的标志性里程碑。

容器运行时的二次繁荣

2017年,Kubernetes引领了容器编排与管理领域的蓬勃发展,而与此同时,另一个很有意思的现象则是容器运行时(Container Runtime)迎来了一次难得的二次繁荣。

一般来说,伴随着容器编排领域的迅速发展和成熟,容器运行时技术一定会因为被上层编排框架所屏蔽而逐渐淡出用户视野。事实上,这也正是Docker公司自成立以来的心病:光有一个容器运行时Docker,并不足以吸引用户真正投入到有价值的商业产品(比如PaaS)上来,更何况容器技术本身又是一个门槛相对不高的组合性创新成果,不能形成长期有效的技术壁垒。这个事实,也正是Docker公司一定要强推Swarm和SwarmKit等项目,以及Mesosphere曾短暂取得瞩目的一个主要原因。

当然,在Kubernetes依托社区和强大的创新能力崛起之后,容器运行时和它背后的主体的淡出便成了不可避免的宿命。这也是为什么我们会看到Docker公司会宣布将它的开源项目改名为Moby,这其实是它自己宣布将要放弃在开源社区中继续同Kubernetes和CNCF社区对抗的重要信号。这也是为什么我们会看到containerd和rkt被接连捐献给CNCF基金会:各类容器运行时的历史使命已经走向尾声了。

但是历史总有意外。Kubernetes的扩展性设计中一项核心功能的确立,却为容器运行时的创新者带来了新的机遇,这就是CRI(Container Runtime Interface)。

CRI的诞生还得追溯到容器运行时第一次繁荣、也就是容器理念第一次席卷技术圈的时候。彼时,Docker公司手持Docker项目大杀四方、是当之无愧的容器技术领导者。而CoreOS公司在选择拥抱Google和Kubernetes的同时,则发布了rkt以制衡Docker,以希望维护自己在容器技术上的话语权。这两位,再加上RedHat,他们在容器运行时领域的合作与竞争,直接推动了OCI这一容器技术标准的诞生。但实际上我们不难看到,Docker公司在容器运行时领域所占据的绝对主导地位,以及OCI本身对Docker公司商业利益的不友好意味,使得OCI长期以来并没能发挥出“标准”所应起到的推动和整合作用。

也正是在这个阶段,以Intel ClearContainer和Hyper为代表虚拟化容器技术,则开始从安全和多租户角度进入到开发者的视野。一时间,容器运行时领域可谓熙熙攘攘,不胜热闹。

而在Kubernetes发布之后,很多机敏的技术人员其实已经嗅到了其中的机遇。在Kubernetes未来有大概率会成功的前提下,谁能在Kubernetes内置的容器运行时中抢占到一个位置,谁才有可能在将来的容器技术圈子中争取到一席之地。所以很快,CoreOS公司通过政治和技术双管齐下的努力下,rkt成功跻身为Docker之后第二个被Kubernetes支持的容器运行时。但也正在这时,一些连锁反应式的问题也被激发出来。

一方面,彼时的Kubernetes羽翼未丰,并没有强势到能直接帮扶起rkt这个相对弱势的容器运行时的地步,更何况当时的Docker项目正突飞猛进,没有给同质的rkt留下任何喘息和反击的机会。所以虽然很早就进入了Kubernetes体系,rkt却一直处于少有用户问津的尴尬地位。

而另一方面,在当时快速迭代、完全没有稳定的Kubernetes尤其是kubelet组件中,额外引入的rkt运行时其实带来了大量的维护工作,并且这些工作很多时候还要依赖于CoreOS的介入才能解决,这无疑给Kubernetes团队带来了很大的压力。

与此同时,Kubernetes团队本身并不希望锁定在Docker容器之上。Docker公司不断推进Swarm项目的决心,很难让人对继续使用这样一个唯一的、不稳定的、将来甚至可能会变成一个PaaS的“容器”感到放心。

在这样的背景下,适逢Kubernetes团队也开始尝试逐步在项目中引入虚拟化容器技术,能不能提供一个通用的、与下层容器运行时无关的接入层来无缝对接上述所有容器运行时,就成为了当时Kubernetes能否更进一步关键所在。更重要的是,这也是Docker的软肋之一。由于显而易见的原因,Swarm体系并没有动力去支持任何非Docker之外的容器运行时,而另一方面,彼时的OCI话语权不济,并不能发挥对接其他容器运行时的作用,这就意味着Kubernetes项目会成为对接非Docker容器运行时的唯一出路。

就这样,一套由Google,Hyper和CoreOS共同主导的、以Kubernetes项目为核心的容器运行时接口的设计,应运而生。

CRI的及时发布,使得Kubernetes团队在后续SwarmKit等事件中可以处变不惊。而它的诞生,也直接推动了容器运行时这原本应该逐步淡化的领域焕发了第二次繁荣。

cri-o与cri-containerd

这次繁荣的第一个标志性的事件,是runC容器运行时cri-o的发布。

cri-o的初衷非常直白,既然现在Kubernetes可以借助CRI对接任何容器运行时甚至虚拟机,那么我们自然会想到,为什么不直接把runC封装成一个CRI的实现呢?这样不就可以绕过现有Docker容器的大部分机制而直接操作Linux容器了么?

所以,不同于Docker,除了用来响应CRI的gRPC server,cri-o并不需要额外的daemon组件来维护Linux容器。CRI的API调用在这里被直接翻译成对runC的操作命令,然后在宿主机上创建并启动runC容器。不难看出,这个工作流其实跟containerd的功能是基本一致的,但有意思的是,cri-o的发起者RedHat并没有使用containerd而是重新造了轮子。这其中,containerd的实际维护者是Docker公司恐怕是主要的考量因素之一。

实际上,在Docker公司决定打造自己的封闭生态之后,RedHat就跟Docker公司走向了对立的一面。毕竟相比Google专注于公有云业务而不太在意企业及市场,Docker公司随后发布的每一项产品(项目),却都在不同领域实实在在争抢着RedHat的蛋糕。作为曾经一起同推进容器技术的“兄弟”,如今“分手”后的RedHat对Docker公司的负面态度是可想而知的。所以,cri-o在某些实现细节上透露出来的一些偏执,也是这种思想指导下的必然产物。从最初放出言论要“fork Docker”,到现在cri-o的实际落地,RedHat在容器运行时领域的志向目前都压在这个项目之上。这也是为何RedHat的宣传机器在2017年 可谓开足了马力,连Kubernetes首席布道师Kelsey Hightower也曾短期被“攻陷”过。

然而,开源社区里最有意思的事情也莫过于此。就在cri-o几乎要以下一代Kubernetes默认容器运行时的身份粉墨登场之时,Google和IBM以及containerd的维护者们却默默的上线了cri-containerd项目。这个项目的思路更加显而易见:鉴于containerd已经捐给了CNCF,现在只要在其基础上略微封装,就可以为Kubernetes打造一个Docker native的、身份中立的CRI实现。相比cri-o每个release都要推广一番的风风火火,cri-containerd的进展可谓低调,仅在最近的DockerCon上小幅亮相了一次,并且期间一直与cri-o保持的良好的合作关系(比如共同维护lib)。但低调并不意味着不作为,2017年底,cri-containerd项目悄无声息地开始了与containerd项目的合并计划,这意味着很快containerd本身将会原生支持Kubernetes CRI。

CRI的成功我们有目共睹,但Kubernetes下一代默认容器运行时目前却尚无定论。Kelsey Hightower一向不太“待见”Docker,他的成名作“Kubernetes the Hard Way”在短暂试用cri-o后目前还是切换到了cri-containerd上。不过这也并不足以说明所有问题,至少在未来一段时间内,“No Default”还是可以继续作为这一领域的官方说辞。

不过,cri-o本身的崛起,侧面说明了“得编排者得天下”是目前容器运行时领域进一步发展的正确思路。CRI的及时发布,使得Kubernetes团队在后续SwarmKit等事件中可以处变不惊。而它的诞生,也直接推动了容器运行时这原本应该逐步淡化的领域焕发了第二次繁荣

Kata!Kata!

这个事件,正是Hyper runV同Intel ClearContainer的合并。合并之后的项目以KataContainers命名并托管于中立基金会,为虚拟化容器技术路线之争画上了句号。

实际上,在Hyper推出了runV技术之后,部分敏锐的技术人员就迅速开始了往Kubernetes推进基于runV的虚拟化容器技术的的集成工作。相比于Swarm体系的封闭和Mesos社区的后知后觉,Kubernetes项目从一开始就展现出来的技术远见,使得这个选择倒并不意外。而这次技术行为的直接结果,则是推动了CRI这一关键特性的诞生和落地:又是一个典型的社区“二次创新”然后再反哺社区的故事。在这个过程中,kubernetes/frakti项目作为虚拟化容器运行时的官方CRI实现,正是推动这项技术进入Kubernetes生态核心的关键一步。

不过,相比于Linux容器领域的Docker项目的一枝独秀,虚拟化容器技术则有一个困扰社区许久的问题,那就是几乎同期发布的Intel ClearContainer项目一直以来跟runV处于重合位置。尽管在项目的后期,Intel和Hyper团队已经开始共同维护很多公有的子项目,但开源社区的掣肘关系依然牵制了虚拟化容器技术进入容器生态核心的步伐。

不过,明智的是,runV并没有固执地在容器API层面同Intel开展类似Docker和rkt之间的竞争,而是把原生接入Kubernetes当成了第一要务,希望借助上层编排框架来为容器运行时发声。这个策略无疑改变了社区对虚拟化容器技术在整个生态中所处位置的看法。事实上,相比于我们所熟知的硬件级别隔离和容器安全这样的常识,虚拟化容器技术的独立内核特性为Kubernetes支持遗留应用和传统业务带来的巨大的想象空间,才是这种技术最大优势所在。尤其是伴随着2017年后期“强多租户”概念被引入到Kubernetes社区,能够从容器运行时层就开始进行租户隔离的设计已经成了一种刚性需求。没有虚拟化级别的隔离能力和独立内核来保证业务的多样性,“强多租户”基本无从谈起。试想一下,在一个真正的多租户云数据中心里,有的租户的应用是Windows的,有的是Linux的,除非做低效的静态划分,常规Linux容器又该如何应对这样的需求呢?

KataContainers项目的出现,把刚刚崭露头角的虚拟化容器技术推向了一个新的阶段。作为OpenStack基金会力图革新后发起的第一个项目,托管于该基金会下面的KataContainers却不必遵守OpenStack社区任何现有的规范,其自由度和改革力度,可见一斑。而这次合并的最终促成虽然被OpenStack基金会抢了先机,但CNCF基金会则开始从OCI入手,试图将KataContainers的运行时再纳入到OCI的范畴之中。我们有理由相信,在两大基金会的通力合作之下,KataContainers的前景非常光明。

不过,更为重要的是,以KataContainers为代表的虚拟化容器技术在云计算领域的探索,正有意无意地打开了公有云的一个新篇章。

ACI,Fargate与“Serverless容器云”

在runV容器发布之后,为了验证虚拟化容器对公有云带来的变化,一个名为hyper.sh服务同步上线并随后迅速霸榜了HackerNews头条。这个服务的创新之初在于,虽然它的整个技术栈都基于Kubernetes,但是它却不对外暴露任何Kubernetes API,也没有提供任何操作console,而是让用户用本地的“hyper run <IMAGE>”指令来在云端创建和启动容器。由于使用了虚拟化容器技术,这个工作流里完全不需要虚拟机的介入,所有租户的容器直接运行在裸物理机集群当中。

虽然看起来简单,但这个设计的本质,却提供了一种容器云的Serverless的设计思路。在这个“无服务器”云的设计中,云的用户完全不必学习任何Kubernetes或者云平台API或者文档,仅靠开发者所熟悉的本地容器操作就可以完成作业的云端部署,然后按秒计费。

而在2017年,这种颇有远见的容器云Serverless开始得到了公有云巨头的青睐。这一次的始作俑者正是近年来在云服务领域出手“稳”、“准”、“狠”的Microsoft。2017年7月26日,Microsoft Azure团队宣布了ACI(Azure Container Instance)服务的发布,其通过“az container create”创建容器的思路,与hyper.sh如出一辙,并且同样屏蔽了所有下层的PaaS和IaaS概念然后按秒计费。一石激起千层浪,国外容器技术圈子对这种服务的讨论迅速成为了当时的技术头条。有人说它是AWS Lamda的有力竞争者,也有人说这才是Serverless服务的终极形态。

紧接着,在2017年11月,堪称全球云计算技术风向标的AWS re:Invent 大会上,AWS高调宣布了同类型服务Fargate的诞生,把Serverless Container Cloud的理念推向了新的高潮。作为回应,Microsoft则联合Hyper发起了virtual-kubelet项目,旨在定制一套标准,允许云提供商把自己的Serverless Container Cloud,以kubelet API的方式接入到任意的Kubernetes集群中作为一个特殊的节点而存在,从而轻松实现一个基于Kubernetes的混合云。目前,AWS、甚至OpenStack都已经加入这个项目开始贡献自己的实现,对应的基金会和开源生态正迅速形成。不出意外,很快Google、国内的阿里云等巨头,也会推出类似的Serverless Container Cloud服务,并且加入到virtual-kubelet项目当中。

Serverless Container Cloud服务备受欢迎的本质,乃在于公有云计算所服务的用户,尤其是广大的开发者群体,对于追求“简单高效”的热情其实是非常高涨的。对于他们来说,在各种设计拙劣的云管理界面上进行凌乱的鼠标操作,绝对不如在键盘上敲打本地命令来的舒服。这种微妙的体验变化,正如同git对比SVN,Docker对比OpenStack。更为重要的是,这种服务形态也正符合了Kubernetes技术继续发展的正确路线:Kubernetes所要扮演的角色,乃是取代传统的Infrastructure Layer并鼓励技术人员进行上层的“二次创新”,而并不是直接面对最终用户(实际上Kubernetes本身的声明式API也是对运维而非开发友好的)。真正为最终用户提供云服务的,很大概率应该是构建于Kubernetes之上的、更加简洁高效的服务型API,而Serverless,尤其是Serverless Container Cloud的设计,正是这种需求下最为贴切的实现方式之一。

不难预料,在新的一年,基于Kubernetes之上构建出来的创新型Serverless服务(当然也包括OpenFaaS等优秀的Function),将会是大小云计算提供商进一步角逐的一个关键领域。相比之下,曾经在国内外普遍开花的、以直接售卖Kubernetes集群为核心的各种“CaaS”,将会沉寂许多。

Docker Inc的未来

毫无疑问,2017年的Docker公司依然是容器圈子里的主角。只不过这一次,波澜之中的Docker公司的确并不好过。

从2017年4月Docker项目毫无征兆地改名为Moby开始,Docker公司顶着巨大的争议,逐步完成了开源技术创新公司到商业公司的转变,也开始正视长期以来同Kubernetes社区竞争所带来的极其不利的商业局面:伴随着Kubernetes项目的成功,Swarm已成为明日黄花,曾一度承载着新希望的SwarmKit也渐渐淡出社区视野。2017年10月,在DockerCon EU上,Docker公司官方宣布下一版本的Docker EE中将全力拥抱Kubernetes,标志着持续了近三年之久的容器编排之争彻底落下帷幕。紧接着,所有纷争的始作俑者、曾经携Docker对抗整个容器社区的Solomon Hykes也宣布自己“角色转变”,不再负责Docker产品的具体技术事宜。

曾经纷纷扰扰的容器圈子,竟然一夜之间尘埃落定,个中滋味,不免让人心生惆怅。Docker公司和Solomon的经历可能不算是传奇,但也绝对能够在云计算历史中留下了浓墨重彩的一笔。我们甚至会不时想象,如果当初Solomon没有去做Swarm,而是选择同Google合作共举Kubernetes,如今的CoreOS还会不会活着?如今的Docker公司又是什么样子?

历史难做假设。

但是Docker公司的未来却依然是光明的。

在积极拥抱Kubernetes社区之后,Docker公司正走向正确的轨道。大家不要忘记,在迎合开发者社群和技术微创新这两个关键手段上,Docker公司的实力绝不容忽视。2018年初,Docker Mac集成Kubernetes的版本正式发布,并立刻在开发者群体中掀起了轩然大波。在Mac OS上如此流畅启动和运行Kubernetes的体验,在这么短的时间内就被Docker公司带到了开发者手里,这其中体现出来的技术能力与产品理念,正是将来Docker公司继续立足的核心所在。当然,Docker公司最终的成功,依然取决于其商业产品能否赢得重量级客户的青睐,在这一点上,Kubernetes的坚定盟友CoreOS已然占尽先机并且完成了转型。但是Docker公司在容器领域不俗的创新能力和产品积累其实是有增无减,其产品线也更完整,在开发者群体中的基础也更雄厚,这样一个人气与技术兼备的创业公司的未来,绝不见得会像某些文章中描述的那样一片哀鸿。这一点,我们不妨拭目以待。

国内

相比于过去默默无闻,2017年的国内容器技术玩家终于得意发声,而且“不鸣则已,一鸣惊人”。阿里集团在双11过后,高调发布了源自其内部容器T4的开源项目Pouch,并迅速成为了当时的技术热点。事实上,早在Docker和Kubernetes技术如火如荼的2015年,业界就发出过疑问:在此领域积累深厚(百度有Matrix,阿里有T4)的国内的互联网巨头为何迟迟不见动作?

好在厂商会迟到,但技术不会。Pouch的发布,也正是前面提到的“2017年容器运行时技术二次繁荣”的又一例证。在Docker公司逐渐式微、rkt几乎退役的档口,Kubernetes的崛起和CRI的成熟正在为所有的容器运行时玩家带来全新的机会。从代码上看,Pouch并非“Docker fork”,而是利用类似技术进行的全新实现。从功能上看,Pouch原生接入了runV来提供多样化的隔离机制,内置“富容器”能力以满足不同的业务场景,打包了Dragonfly来实现高效的镜像分发,这意味着这套技术栈从底自上有着同Docker整体不一样的业务考量。

但另一方面,如今的时间点不同与2015年,用户的关注点已经从容器运行时转移到了上层容器编排管理的服务能力。而作为近来Linux容器的第三个实现(cri-o只支持Kubernetes,不能算作完整的容器实现),尽管功能上有所差异,但Pouch仍然难免会陷入同质竞争的不利局面。不过需要指出的是,阿里集团接下来亦在酝酿其内部集群管理系统Sigma项目的开源工作,并且会积极地将Sigma纳入到Kubernetes的现有生态当中,这就为Pouch未来的前景增添了一层有趣的砝码。毕竟,Pouch本身在Docker的优势地位中突围可以说困难重重,但正如前面所提到过的,如果能够借助上层容器编排能力重新表达这一容器运行时的关键作用,那这套技术方案的应用前景和接纳难度很可能会发生变化。这也正回到了我们最开始谈到“Kubernetes赢在何处”时所作出的阐述:Kubernetes社区通过从技术和生态双重层面上使能用户二次创新的做法,必将推动这个生态走向一个更加繁荣而有意义的新阶段。

总结

“任何一个被浓厚的商业兴趣所充斥的开源社区,最后都难免走向有毒的方向”

— Solomon Hykes

2017年,曾经的弄潮儿Docker公司在巨大的争议中终于完成了向商业公司的重要转变,也宣告了由Kubernetes社区所主导的、全新的容器生态正式拉开序幕。在回顾Kubernetes如何赢得这次竞争的同时,我们应该意识到容器运行时“二次繁荣”的短暂窗口正在为我们带来新的机遇。与此同时,容器公有云的形态正在悄然发生变化,伴随着这次变革而存在的,固然有风险,但也有很可能会催生出新的云计算赢家甚至独角兽。最为重要的是,伴随着Kubernetes社区的日益壮大,如何避免这个生态陷入Solomon所警告的“有毒”陷阱,恐怕很快就会成为摆在这个社区所有参与者面前的一道难题。是的,是所有参与者都对此负有责任,而绝不仅仅是CNCF或者Google就有能力独自解决的一次危机。

作者

张磊,浙江大学博士研究员,Hyper项目成员,Kubernetes项目资深成员与社区维护者。长期专注并活跃于容器集群管理与云计算数据中心领域,连续多次被微软授予该领域“最有价值专家(MVP)”称号。

来源:infoq

http://www.infoq.com/cn/articles/2017-container-Kubernetes

2017Docker公司过的不容易

中文社区阅读(1909)评论(0)

编者话:本文来源云头条微信公众号,原标题,“Docker公司已死”,个人觉得此title太过标题党,索性改成“2017Docker公司过的不容易”似乎更贴切。

作者简介:Chris Short在IT行业有20多年的从业经历,他毕生坚定地提倡使用开源解决方案。他是身体部分残障的美国空军退伍老兵,现与妻子和儿子一起住在密歇根州大底特律都市区。

要说Docker在2017年的日子非常难过,那已经算是轻描淡写了。除了优步(Uber)外,我实在想不出还有哪一家更加被利用、被炒作、资金充裕的硅谷初创公司(仍在运营之中)像Docker在2017年那样步履维艰、糟糕透顶。回顾2017年,人们会记得在这一年,Docker这款优秀的软件完全毁于糟糕的经营方法,导致Docker公司在2018年寿终正寝。本文从局外人的视角回顾了Docker怎么出岔子,哪里出了岔子,以及为何说Docker现在试图解决问题为时太晚。

Docker是优秀软件

有一点很清楚,Docker帮助彻底改变了软件开发领域。拿来cgroups、命名空间和进程隔离等Linux基本元素,把它们做入到一个工具中,这本身就很了不起。2012年,我试图弄清楚开发环境如何可以更易于移植。 Docker的崛起使开发环境得以成为一个简单的、可版本控制的Dockerfile。工具形形色色,从Packer、Vagrant、VirtualBox和众多基础设施,到Docker,不一而足。Docker UI实际上也相当不错!这是一款用途广泛的优秀工具。Docker团队的成员应该为他们开发的工具感到自豪。

Docker是硅谷的宠儿

Docker早期的成功促使该公司围绕其产品建立起了一个庞大社区。而早期的这种成功让它融到了一轮又一轮的资金。像高盛、Greylock Partners、红杉资本和Insight Venture Partners这些大名鼎鼎的投资者竞相为Docker提供大把大把的资金。到目前为止,Docker筹集到的投资总额在2.42亿美元至逾2.5亿美元之间。

但是与2010年代大多数资金充裕、不计代价以求成功的初创公司一样,Docker也犯了人力资源方面的几个失误。Docker在崛起过程中竭力保护一些很蹩脚的货色。这导致我个人不喜欢这家公司的领导层。产品仍然是一流的,但这根本无法因此原谅该公司的行为。遗憾的是,硅谷的许多宠儿都是这样,这种情况需要有所改变。

Kubernetes对Docker造成了损害

Kubernetes的崛起更是加快了Docker的消亡。 Docker在处理Kubernetes方面并没有为它自己带来任何好处,而Kubernetes是开源社区青睐的容器编排工具。Docker的竞争产品Docker Swarm是Docker的头脑中唯一记挂的容器编排工具。尽管Kubernetes起初偏爱Docker容器,Docker还是做出了这个决定。这里捎带提一下,Docker Captains在2017年初证实,当初Docker对文章、聚会和会议上屡屡提到的Kubernetes根本就不感冒。

直到奥斯汀召开的dockercon17大会,Docker依然奉行无视Kubernetes的这种做法。然后在dockercon EU 17大会上,Docker几乎突然决定全身心地支持Kubernetes。这个突然的变化说明Docker显然承认了Kubernetes的强势崛起、即将成为市场的霸主。Docker成为KubeCon + CloudNativeCo北美2017年大会的赞助商,并且设有展台,更是彰显了这个事实。

Moby?

没有人了解Docker去年4月份在dockercon17上宣布Moby时做了什么。Moby被称为是Docker项目的新上游,但是没有提前宣布Moby的发布。所罗门•海克斯(Solomon Hykes)在dockercon17大会上发言时,GitHub上出现了一下子由Docker向Moby大转变这一幕,无数的人害怕地惊叫起来。这种突如其来、考虑欠周的变化需要 GitHub的工作人员直接干预。

不仅没有处理好这个变化,Docker所要传达的讯息也没有深思熟虑。这导致该公司对这一变化表示道歉,高层亲自出面解释。这让原本乱象丛生的容器领域和Docker(或者Moby?)生态系统更让人摸不着头脑了。处理Moby的发布继续困扰着那些从业人员。 Docker品牌可能因此受到了损害。

对Kubernetes态度冷淡

Docker在最后的时刻尴尬地拥抱Kubernetes是表明它即将崩溃的迹象。被问及Docker Swarm是否已经死亡时,所罗门•海克斯曾经发推文道:“Docker将继续支持Kubernetes和Swarm作为一等公民,并且鼓励交流和分享。开放性和灵活选择为每个人创造了一个更健康的生态系统。”这里的问题是,Docker Swarm并没有完全成熟,实际上离完全成熟相差甚远。Docker Swarm产品团队及其少数开源贡献者将跟不上Kubernetes社区的步伐。尽管Docker UI很优秀,但Kubernetes UI却出色得多。就好像Docker现在承认自己是容器领域的一家边缘化的咨询公司。

结束语

Docker的真正问题是缺乏连贯一致的领导团队。战略重心似乎就围绕这家公司的某一个人。这个人已经被越来越远离公司的核心,但他依然当权。公司已经过了重组,把重心转移到企业客户。这种转变对于Docker的投资者来说颇为明智(毕竟公司确实背负信托责任)。但是,这种转变会削弱该品牌的酷炫因素,而酷炫因素当初促使其大获成功。常言道:“伟大的文明不是被谋杀的,而是自杀的。”Docker就是这样一个活生生的例子。

阴谋论

针对Docker在2017年的尴尬时期,我在Twitter上倒是提出了一个观点。Docker可能知道公司本身已是穷途末路。由于组织变化表明即将退出(可能通过收购),该公司的技术核心优先考虑一些变化。将containerd捐赠给云原生计算基金会(CNCF),让Moby成为Docker的上游,并且拥抱Kubernetes,这些举措将使Docker的人员所做的好事被永载史册。这让像Oracle或微软这样的大企业得以过来收购这家公司,不必担心Docker的员工取得的技术进步被许可证牢牢束缚。这为软件团队和公司本身提供了两全其美的方法。不用说,2018年对于Docker来说将是值得关注的一年。

Kubernetes 1.9GA 版本最新发布 | 更新日志

中文社区阅读(4283)评论(0)

2017年12月15日,kubernetes1.9版本发布。Kubernetes依然按照每三个月一个大版本发布的速度稳定迭代,这是今年发布的第四个版本,也是今年的最后一个版本,该版本最大的改进是Apps Workloads API成为稳定版本,这消除了很多潜在用户对于该功能稳定性的担忧。还有一个重大更新,就是测试支持了Windows了,这打开了在kubernetes中运行Windows工作负载的大门。

Workloads API GA

apps/v1 Workloads API成为GA(General Availability),且默认启用。 Apps Workloads API将DaemonSetDeploymentReplicaSetStatefulSet API组合在一起,作为Kubernetes中长时间运行的无状态和有状态工作负载的基础。

Deployment和ReplicaSet是Kubernetes中最常用的两个对象,经过一年多的实际使用和反馈后,现在已经趋于稳定。SIG apps同时将这些经验应用到另外的两个对象上,使得DaemonSet和StatefulSet也能顺利毕业走向成熟。v1(GA)意味着已经生产可用,并保证长期的向后兼容。

Windows支持(beta)

Kubernetes最初是为Linux系统开发的,但是用户逐渐意识到容器编排的好处,我们看到有人需要在Kubernetes上运行Windows工作负载。在12个月前,我们开始认真考虑在Kubernetes上支持Windows Server的工作。 SIG-Windows现在已经将这个功能推广到beta版本,这意味着我们可以评估它的使用情况

增强存储

kubernetes从第一个版本开始就支持多种持久化数据存储,包括常用的NFS或iSCSI,以及对主要公共云和私有云提供商的存储解决方案的原生支持。随着项目和生态系统的发展,Kubernetes的存储选择越来越多。然而,为新的存储系统添加volume插件一直是一个挑战。

容器存储接口(CSI)是一个跨行业标准计划,旨在降低云原生存储开发的障碍并确保兼容性。 SIG-StorageCSI社区正在合作提供一个单一接口,用于配置、附着和挂载与Kubernetes兼容的存储。

Kubernetes 1.9引入了容器存储接口(CSI)的alpha实现,这将使挂载新的volume插件就像部署一个pod一样简单,并且第三方存储提供商在开发他们的解决方案时也无需修改kubernetes的核心代码。

由于该功能在1.9版本中为alpha,因此必须明确启用该功能,不建议用于生产使用,但它为更具扩展性和基于标准的Kubernetes存储生态系统提供了清晰的路线图。

其它功能

自定义资源定义(CRD)校验,现在已经成为beta,默认情况下已启用,可以用来帮助CRD作者对于无效对象定义给出清晰和即时的反馈。

SIG Node硬件加速器转向alpha,启用GPU,从而实现机器学习和其他高性能工作负载。

CoreDNS alpha可以使用标准工具来安装CoreDNS。

kube-proxy的IPVS模式进入beta版,为大型集群提供更好的可扩展性和性能。

社区中的每个特别兴趣小组(SIG)继续提供其所在领域的用户最迫切需要的功能。有关完整列表,请访问发行说明

获取

Kubernetes1.9已经可以通过GitHub下载

参考

Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem

剖析IBM Cloud Private服务,以Kubernetes为调度核心

中文社区阅读(868)评论(0)

IBM Cloud Private重点策略

  1. 主打PaaS应用管理需求,强调快速自建的私有容器云
  2. 兼顾传统IT需求,能同步管理容器及VM

上有AWS、GCP以及Azure,下有甲骨文竞争对手的IBM,在今年3月时宣布,正式在Bluemix容器服务上支持Kubernetes。目前这家公司支持Kubernetes的方式共有两种。第一种是以公有云平台IBM Cloud Public的容器服务为基础,支持容器调度功能。第二种则是在私有容器平台IBM Cloud Private中,以Kubernetes为核心引擎,目前两个平台都已经支持至Kubernetes 1.7.3版。

而IBM调度工具架构的演进,总共可分为3阶段。最初,IBM推出自家版本的Docker,并以Docker Swarm为基础,自主开发了一套调度工具。第二阶段中,则在单一平台上同步整合Mesos及Kubernetes,使用Mesos管理系统资源,Kubernetes则专注在容器调度。而到了现今,则是全力押宝Kubernetes,透过它掌控容器调度、资源分配的任务。

公有云平台以Cloud Foundry为主要底层架构

现在IBM Cloud Public及IBM Cloud Private这两个平台上皆支持Kubernetes,但是平台特色的定位,也影响该门技术的支持程度及实作功能。

目前IBM Cloud Public是以开源PaaS Cloud Foundry为基础,许多服务仍要靠既有Buildpack,打包应用程序执行所需要的组态设定、环境。而容器调度任务则主要靠Cloud Foundry的Diego框架完成。以PaaS为基础的优点在于,开发者只须关注程序代码开发,不须介入底层Docker容器的运作,但是其平台僵固性也更高。

私有容器平台用Kubernetes为核心,还能搭配其他开源工具

虽然目前IBM Cloud Public、IBM Cloud Private皆能作为容器执行平台,但私有环境的目标是让Kubernetes跟Cloud Foundry并存。

IBM Cloud Private虽支持Cloud Foundry,不过底层则是选择Kubernetes为核心,整合了开源网络虚拟化工具Calico、Kubernetes打包工具Helm,以及IBM自家的行动应用程序管理工具Application Center。

而IBM Cloud Private除了有Kubernetes作为调度核心外,还得提供其他相关容器功能。例如,在此平台也有提供容器漏洞扫描功能,想要部署在该平台运作的容器,均得通过此程序,藉此确保既有Kubernetes环境中执行的容器不会受到影响。

以私有容器平台而言,IBM不单把Kubernetes视为容器调度工具,如果将平台上的Docker容器视为各自独立执行的服务,此时Kubernetes便可以被视作PaaS,而IBM Cloud Private则成为企业内部的私有容器云管理平台。

以容器为基础发展,也为企业使用者带来更多自由度,例如,可以自由加入开源工具如Elasticsearch、Kibana或是Grafana等。

此外,现阶段IBM Cloud Private也已经整合微服务管理工具Istio,主要用途为补强Kubernetes的网络功能。Istio现阶段在此平台主要满足两大需求。第一需求是支持路由功能,透过此工具管理、追踪出入集群的网络流量。而第二个功能则是安全监控功能,根据系统管理所定义的网络管理策略,限制系统服务的访问权限。

Istio团队表示,想要开发稳定、松散耦合,又能进入正式环境的微服务相当具有挑战性。随着单体式(Monolithic)应用程序分解成微服务,软件团队必须考虑分布式系统如何整合各种服务,像是服务搜寻、负载平衡、容错、监控。

而Istio提供的是「服务网」(Service Mesh)的概念,让服务及网络之间拥有透明的架构层,提供运营商所需的控制能力,开发人员也可以专注开发程序代码,让运营商脱离应用程序的功能开发与发布过程。而Istio的角色即是系统化地嵌入代理人,将各种不同的微服务变成单一的整合服务网络。

而近日所推出的0.2版,除了加强稳定性、表现效能之外,也加入一些企业所需的支持,像是TLS认证机制、TCP服务。同时,Istio开始支持多种开源工具,像是HashiCorp的集群管理调度工具Nomad、服务探查工具Consul,还有Netflix开源推出的云端负载均衡工具Eureka。

Kubernetes操作接口仍有可继续加强,增进易用性

不过,现在许多企业系统仍以VM环境为主力,还不能一次到位地迈入容器环境。因此,IBM以基础架构管理工具Terraform,开发了IBM Cloud Automation Manager,即使只有Kubernetes,也能同步管理容器及VM。

目前Kubernetes最新的版本为1.8,而IBM已经开始支持1.7.3版,支持步调算是快。不过部分既有服务、产品还未能与容器平台进行深度整合。例如,现在企业用户使用Kubernetes必须透过传统的命令程序接口操作,对部分非工程背景用户可能较不便。而IBM现在也已经计划,要推出更友善的Kubernetes操作接口。

同时,IBM也希望把Kubernetes变成新一代的PaaS平台,并且将产品、服务容器化,透过Docker镜像形式提供并收取授权费用,也能减低企业部署、安装的难度。

如何配置Kubernetes以实现最大程度的可扩展性

RancherLabs阅读(1057)评论(0)

Kubernetes的设计初衷是要解决管理大规模容器化环境时的困难。不过,这并不意味着Kubernetes在任何的环境下都可以进行扩展。有一些方法可以让用户最大限度地发挥Kubernetes的扩展能力,而在扩展Kubernetes时,有一些重要事项和限制需要注意,本文中我将对这些内容进行说明。

规模和性能

扩展Kubernetes集群,首先要注意的就是规模和性能之间的平衡。比如,Kubernetes 1.6可被用于多达5000个节点的集群。不过5000个节点并不是硬性限制的最大值,它只是一个推荐的节点最大值。在实际使用中,节点数可以远超过5000个,只是这样会导致性能下降罢了。

这个问题具体来说是这样的:Kubernetes有两个服务层级的目标,一个是在一秒内返回99%的API调用。另一个是在5秒内启动99%的pods。尽管这些目标并不是完整的一套性能指标,但它们确实为评估通用集群性能提供了良好的基准。而据Kubernetes所说,超过5000个节点的集群可能无法实现这些服务层级的目标。

所以有一点请大家注意,在有些时候,为了发挥Kubernetes的扩展性,你有可能不得不牺牲一部分的性能,这些牺牲对你来说既可能是值得的,也可能是不值得的,而这取决于你具体的部署场景。

配额(quotas)

在建立非常大规模的Kubernetes集群时,你可能会遇到的一个主要问题就是配额问题。对于基于云的节点尤为如此,因为云服务提供商通常情况下会设置配额限制。

这个问题之所以如此重要,是因为部署大规模的Kubernetes集群实际上是一个看似简单的过程。config-default.sh文件有NUM_NODES的设置。表面上,你可以通过加大与此设置相关联的值来构建大规模集群。虽然这在某些情况下可行,但最终也可能会遭遇到配额问题。因此,在你打算扩展集群之前,很有必要就现有的任何配额先和云供应商进行沟通。云供应商不仅可以让你了解现有配额的情况,而且至少一部分云供应商会同意用户增加配额限制的请求。

当你在评估这些限制的时候,需要注意,尽管配额限制会直接限制你创建Kubernetes集群的数量,然而集群大小的限制更多是出自与Kubernetes间接相关的配额。例如,提供商可能会限制允许你使用的IP地址数量,或者限制你创建的虚拟机实例数量。而好消息是,主要的几个云服务商已经有多次和Kubernetes打交道的经验,应该能够帮助你解决这些问题。

主节点

除了上述的限制外,还需要考虑的一个问题是集群大小对所需的主节点大小和数量的影响。这些取决于Kubernetes的实现方式,不过要记住的一点是,集群越大,所需的主节点数量也越多,而那些主节点的功能需求也就越高。

如果你正在从头构建新的Kubernetes集群,这可能是一个无关的问题,毕竟确定需要的主节点数量是集群规划过程中的正常阶段。可是如果你打算扩展现有Kubernetes集群,那么你更需要去多加考虑主节点的需求,因为在集群启动时主节点的大小就已经设置好了,而且不能够动态调整。

扩展附加组件(scaling add-ons)

另一件需要我们注意的是,Kubernetes定义了附加组件容器的资源限制。这些资源限制可确保附加组件不会消耗过多的CPU和内存资源。

这些有关限制的问题是,它们是基于相对较小的集群进行定义的。如果你在大规模集群中运行某些附加组件,它们可能会需要超额使用更多的资源。这是因为附加组件必须服务更多的节点,也因此需要额外的资源。如果开始出现与组件相关限制的问题,那么你就会看到附加组件一个一个地被kill掉。

总结

Kubernetes集群可以大规模扩展,但可能会遇到与配额和性能相关的问题。因此,在向Kubernetes集群添加大量新节点之前,请一定要仔细考虑横向扩展所出现的各种需求。

为什么Docker最终接受了Kubernetes?

中文社区阅读(4375)评论(0)

容器编排器的大战似乎快要结束了——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(翻译:钟最龙)