10个业界最流行的Kubernetes发行版
如果你需要大规模的容器编排,想必Kubernetes毋庸置疑是你的首要选择,这一由谷歌推出的开源容器编排系统近年来发展飞速,大受业界及广大用户好评。
尽管如此,对于大多数用户而言,Kubernetes存在着学习曲线陡峭、难以设置和配置的问题,导致终端用户需要承担繁重的管理工作。基于此,最佳的解决办法并非单枪匹马学习并直接上手Kubernetes,而是寻找一个完善的容器技术解决方案,这种方案通常将Kubernetes纳为其支持和维护的组件之一,使用起来通常更直观和简洁,如此一来便极大程度降低了Kubernetes的上手门槛。
在本文中,我列出了10个业界最流行的Kubernetes相关产品,包括了Kubernetes发行版、容器工具、不同的供应商提供的Linux内核等等。
本文的列表不包括Amazon EKS或者Google Kubernetes Engine(GKE)这样的云服务,仅仅列出了可以在本地运行或作为云托管的软件发行版。
目 录
- Rancher 2.0
- CoreOS Tectonic/Red Hat CoreOS
- Canonical Distribution of Kubernetes(CDK)
- Docker 社区版 / Docker 企业版
- Heptio Kubernetes 订阅
- Kontena Pharos
- Pivotal 容器服务 (PKS)
- Red Hat OpenShift
- SUSE 容器服务平台
- Telekube
十大Kubernetes发行版
Rancher 2.0
https://rancher.com/kubernetes/
严格来说,Rancher 2.0并不是一个单纯的Kubernetes发行版,而是一个开源的Kubernetes管理平台。Rancher 2.0 为企业用户提供Kubernetes-as-a-Service (Kubernetes即服务),且能够实现多Kubernetes集群的统一纳管,不论这些Kubernetes集群在何处、以何种方式部署。这解决了生产环境中企业用户可能面临的基础设施不同的困境。Rancher 2.0能统一纳管来自Google(GKE)、Amazon(EKS)和Azure(AKS)等公有云上托管的Kubernetes服务的平台。
Rancher Labs公司在2019年发布了提供轻量级的Kubernetes发行版,K3s。这款产品专为在资源有限的环境中运行Kubernetes的研发和运维人员设计。其每个服务器实例仅需512MB RAM以及200MB的磁盘空间。它删除了旧的、非必须的代码,整合正在运行的打包进程,使用containerd代替Docker作为运行时的容器引擎,并在除etcd之外引入了SQLite 作为可选的数据存储,通过这些变化极大地减少了运行所需的空间和资源。
CoreOS Tectonic/Red Hat CoreOS
CoreOS提供以容器为中心的Linux发行版,它兼容Docker,但又有固定的镜像格式、它自己的runtime、以及一个“企业级Kubernetes发行版”。上述这些共同构成了CoreOS Tectonic堆栈的基础。
CoreOS操作系统Container Linux是业界的一大流行产品,它的亮点之一在于它就像一组容器化组件,用户无需关闭正在运行的应用程序,即可将操作系统的自动更新整合到生产环境中。CoreOS还可以对Kubernetes进行“一键式”更新。此外,CoreOS Tectonic可以在Amazon Web Services、Microsoft Azure以及裸机上运行。
Red Hat收购了CoreOS之后,计划将其集成到Red Hat OpenShift中。Container Linux将被重新命名为Red Hat CoreOS。此举预计将在2020年之前完成,在此之前Container Linux将继续得到支持。根据Red Hat的说法,过渡后将提供“几乎所有”CoreOS Tectonic的功能。
Canonical Distribution of Kubernetes(CDK)
Canonical,Ubuntu Linux的制造商,也拥有自己的Kubernetes发行版,即Canonical Distribution of Kubernetes(CDK)。该发行版的一大卖点是它是一款广泛受到支持、易于理解且普遍部署的Ubuntu Linux发行版。Canonical声称其堆栈既可以在任何云上运行,也可以在本地部署,并支持CPU和GPU驱动的工作负载。付费客户还能享受Canonical的工程师远程管理他们的Kubernetes集群的服务。
Canonical的Kubernetes发行版也有轻量级版本的,叫Microk8s。开发人员以及Kubernetes新手可以在笔记本或者台式机上安装Microk8s,将其用于测试、实验,甚至在那些硬件配置低的生产环境中使用。
此外,Canonical和Rancher Labs共同开发了一个产品叫做“云原生平台(Cloud Native Platform,简称CNP)”,它将Canonical的Kubernetes发行版和Rancher的容器管理平台相匹配。如此,就可以使用Kubernetes管理运行在每个集群上的容器并且用Rancher管理多Kubernetes集群。目前,CNP已经在Rancher 2.x的版本中可以使用。
Docker 社区版 / Docker 企业版
https://www.docker.com/products/kubernetes
对于很多人来说,Docker仅仅是容器。但实际上,2014年之后Docker也有它自己的集群和编排系统,Docker Swarm,而这一系统曾是Kubernetes的竞争对手。直到2017年10月,Docker宣布将在其未经修改的、永久标准的状态中添加Kubernetes作为标准打包方式,这一调整涵盖了Docker Community Edition和Docker Enterprise 2.0及以后的版本。
Docker Enterprise 3.0添加了Docker Kubernetes服务,这一Kubernetes集成可以保持开发人员桌面和生产部署环境中Kubernetes版本一致。
简而言之,Docker公司已经意识到Kubernetes比Swarm更适合管理庞大、复杂的容器环境。然而,Docker依然包括其原始的集群系统“swarm 模式”,它更适用于那些不太复杂的工作,例如部署一个无需扩展太多的本地的、受保护的应用程序或者维护不需要修改的现有swarm模式集群。
Heptio Kubernetes 订阅版
https://heptio.cloud.vmware.com/
Kubernetes的两位创始人Craig McLuckie和Joe Beda,创办了Heptio,主要围绕Kubernetes提供服务和产品。他们第一个主打产品是一个付费的Kubernetes部署服务, Heptio Kubernetes Subscription(HKS)。Heptio提供全天候的技术支持,收费是每月2000美元及以上。
Heptio的主要优势在于它是企业级的Kubernetes,又不害怕厂商锁定。它可以在公有云或者私有硬件上运行部署。所有Heptio提供的用于管理Kubernetes配置的工具都是开源的,并且修复程序可以直接交付到支持的集群。
2018年VMware收购了Heptio,不过此次收购目前暂未影响Heptio的产品计划。
Kontena Pharos
https://www.kontena.io/pharos/
Kontena Pharos的定位是“Kubernetes that just works”,它与Red Hat的Linux产品拥有大致相同的“剧本”。底层架构是经过CNCF认证的Kubernetes发行版,可以在Apache 2许可下使用(和Fedora或CentOS一样)。付费客户可以获得专业级功能、技术咨询、支持服务和特定固定价格的产品,比如迁移到云原生基础设施。
核心Pharos发行版默认配置了自动安全更新和多个容器运行时等基本功能。付费的版本则添加了企业工具,比如Kontena Lens面板、Kontena Storage分布式存储系统、备份、负载均衡以及在内网隔离环境中部署集群。
专业版有30天的试用期,订阅的费用为每月近3000美元起。而开源的版本则没有时间的限制也不需要许可费用。
Pivotal 容器服务 (PKS)
https://pivotal.io/cn/platform/pivotal-container-service
Pivotal,以其在Cloud Foundry上的表现而为人熟知,它拥有企业级Kubernetes服务,即Pivotal Container Service(PKS)。PKS吸取了许多其他Pivotal项目的灵感,例如,它使用曾经用于Pivotal的Cloud Foundry的Kubo项目来启动和管理Kubernetes集群。
PKS一个最突出的特性是与VMware虚拟机堆栈紧密集成,事实上,PKS是VMware-Pivotal的联合项目。运行在PKS上的容器可以访问在vSphere上运行的虚拟机可用的服务,譬如VMware VSAN中的持久存储。此外,PKS可以通过用于在公有云和私有云环境中管理VMware基础设施的VMware Cloud Foundation进行管理。
简而言之,任何使用VMware并且对Kubernetes越来越感兴趣的企业可能希望研究PKS以充分利用他们现有的VMware设置。
Red Hat OpenShift
https://www.redhat.com/en/technologies/cloud-computing/openshift
OpenShift是红帽的PaaS产品,最初使用与Heroku buildpack类似的“盒式磁带”打包应用程序,然后将其部署在称为“齿轮”的容器中。然后Docker出现了,OpenShift经过了重新设计,使用新的容器镜像和运行时标准。不可避免地,Red Hat采用了Kubernetes作为OpenShift中的编排技术。
OpenShift还为PaaS中的所有组件提供抽象化和自动化。这种抽象和自动化扩展到Kubernetes,会带来相当大的管理负担,因此OpenShift可以用来缓解这一过程,作为部署PaaS的更为重要的一部分。
如上文所提到的,CoreOS Tectonic正在合并到Red Hat OpenShift中,虽然技术合并预计要到2020年才能完成。
SUSE 容器服务平台
https://www.suse.com/products/caas-platform/
因Linux 发行版而在欧洲广为人知的SUSE也拥有 SUSE CaaS平台。概念上,SUSE CaaS平台让人想起CoreOS Tectonic,它结合了运行容器的裸机“微型”操作系统、Kubernetes、内置的镜像仓库和集群配置工具。
SUSE CaaS Platform3于2018年发布,在这一版本中添加了多主机功能以使集群更能适应主节点崩溃和内核调整功能,以便对包含的Linux内核进行自定义调整。
SUSE CaaS平台可以在公有云和本地裸机上运行,但需注意SUSE目前无法支持任何与底层云基础架构的集成。这意味着SUSE CaaS平台不是为了补充Amazon EKS或Google Kubernetes Engine而设计的,而是为了规避他们,让您可以跨多个云和数据中心运行容器。
Telekube
https://gravitational.com/gravity/
Teleport SSH服务器的所属公司Gravitational开发了Gravity,这是一种在本地或远程集群上运行的“强化生产”Kubernetes发行版。Gravity的定位是私有SaaS平台的解决方案或在多个区域及托管提供商中运行Kubernetes-as-a-service。
Gravity上的应用程序要想在Kubernetes上的容器中运行,必须做一些前提准备。它们必须首先被打包成“Bundles”,这些“Bundles”之后会被发布到Kubernetes集群进行分发。这些“绑定”属于额外工作,除此之外我们常见的部署容器应用程序所需的准备工作也仍然需要做,不过Bundle清单也是Gravity唯一需要的额外工作了。
Gravity包含拍摄整个Kubernetes集群的快照的功能,其中包括所有的应用程序和配置,并且用户可以部署快照到任意其他Kubernetes环境中。
结 语
Kubernetes和容器正在改变应用程序的创建、部署以及管理的方式。而本文列出的这些Kubernetes发行版,正在引领着这场变革。
原文链接:
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
凌晨1点突发致命生产事故,人工多线程来破局!
有一个读者问我:你认为一个程序员具备什么样的能力,才算得上是厉害的程序员? 我答:拥有解决问题的能力的程序员。 这个回答貌似有点抽象,不要紧看下面的文章你会慢慢有所了解。 一、解决问题的能力 很多年前,当我还是一个小菜鸟的时候,我的领导经常告诉我,解决问题的时候,不要局限于技术本身,并且形象的给我举了一个例子。 有一次两个程序员一直讨论,如何判断两台服务器之间是否网络正常,争争吵吵了很久。旁边的一个测试说,Ping 一下不就知道了吗?就这样他们用 Java 代码实现了 Ping 操作解决了这个问题。 多年以后,虽然我知道有更优雅的方式来解决这个问题,但是我仍然觉得之前的那个测试人员很聪明。后面我们持续打过一年交道,她能力真的很强,在小公司相当于产品经理+测试的职能。 需要给大家说明的是:解决问题的能力和技术能力是两个能力区间,我见过很多程序员源码玩得一溜,生产出现问题的时候仍然不知道如何去解决问题。 生产出现问题的时候,是考验一个程序员的最高水准,在面对高强度高压力下,动作不变形,能够冷静思考、分析、解决问题,能达到这个水平的程序员,这在古代可以拜为上将军。 我一直非常喜欢能够快速解决...
- 下一篇
ESLint 在中大型团队的应用实践
引言 代码规范是软件开发领域经久不衰的话题,几乎所有工程师在开发过程中都会遇到,并或多或少会思考过这一问题。随着前端应用的大型化和复杂化,越来越多的前端工程师和团队开始重视 JavaScript代码规范。得益于前端开源社区的繁盛,当下已经有几种较为成熟的 JavaScript 代码规范检查工具,包括 JSLint、JSHint、ESLint、FECS 等等。本文主要介绍目前较为通用的方案——ESLint,它是一款插件化的 JavaScript 代码静态检查工具,其核心是通过对代码解析得到的 AST(Abstract Syntax Tree,抽象语法树)进行模式匹配,定位不符合约定规范的代码。 ESLint 的使用并不复杂。依照 ESLint 的文档安装相关依赖,可以根据个人/团队的代码风格进行配置,即可通过命令行工具或借助编辑器集成的 ESLint 功能对工程代码进行静态检查,发现和修复不符合规范的代码。如果想降低配置成本,也可以直接使用开源配置方案,例如eslint-config-airbnb或eslint-config-standard。 对于独立开发者,或者执行力较强、技术场景较...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS6,CentOS7官方镜像安装Oracle11G
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19
- CentOS6,7,8上安装Nginx,支持https2.0的开启