论文部分内容阅读
Kubernetes和容器正在改变应用的构建、部署和管理方式。以下这些发行版正在引领这一变革。
如果你需要大规模的容器编排，就可以借助Kubernetes这个项目。这个出自谷歌的开源容器编排系统备受好评，不仅得到了良好的支持，而且发展势头迅猛。
尽管如此，Kubernetes仍存在庞大、复杂，并且难以搭建和配置的问题。不仅如此，它还将许多繁重的工作留给了终端用户。因此，最好的方法是不要自己单独去尝试它们，而是寻找一个含有Kubernetes的完整的容器解决方案。在这个解决方案中，Kubernetes会被作为组件得到支持和维护。
我在这里列出了12个最具知名度的Kubernetes解决方案，它们实际上是整合了Kubernetes和容器工具的发行版，也就是由众多厂商推出的带有Linux内核和用户层的发行版。
需要注意的是，本文重点关注的是可在本地运行或可被云托管的软件发行版，不包括如亚马逊EKS或谷歌Kubernetes引擎等专用的云服务。
CoreOS Tectonic
CoreOS提供了专注于容器的Linux发行版，并且可以与Docker兼容，不过它有着自己的镜像格式和运行环境。与此同时，还提供了一款“企业级Kubernetes”发行版。两者一起共同构成了CoreOS Tectonic堆栈的基础。
CoreOS操作系统Container Linux与众不同，主要是因为它们被作为一套容器化组件交付。这样一来，操作系统的自动更新可以在不影响应用正常运行的情况下顺畅地进入到生产环境中。CoreOS还表示他们可以对Kubernetes进行“一键”更新。CoreOS Tectonic可以在亚马逊网络服务（AWS）、微软Azure和裸机上运行。
Canonical 版的Kubernetes发行版
Ubuntu Linux的开发商Canonical也推出了自己的Kubernetes发行版。Canonical版的Kubernetes发行版的一大卖点是它们立足于已得到广泛推崇并部署的Ubuntu Linux发行版。Canonical称，其堆栈可以在任何云端或本地运行，并且支持由CPU和GPU驱動的工作负载。付费用户可以让Canonical工程师远程管理他们的Kubernetes集群。
Canonical 和 Rancher 实验室共同推出了 一款名为“云原生平台”（Cloud Native Platform）的产品，该产品将 Canonical的Kubernetes发行版与Rancher的容器管理平台整合到了一起。其理念是使用Kubernetes来管理每个集群中运行的容器，同时使用Rancher来管理多个Kubernetes集群。Cloud Native Platform 将随 Rancher 2.0 一起推出，目前仅提供了测试预览版。
Docker 社区版/Docker 企业版
对于我们当中的大多数人来说，Docker就是容器。自2014 年以来，Docker 拥有了自己的集群和编排系统Docker Swarm，直到近期它们还是 Kubernetes 的竞争对手。然而在2017 年 10 月，Docker宣布将不做任何修改处于原本状态的Kubernetes作为Docker社区版和 Docker Enterprise 2.0 的标准插入式组件。
简而言之，Docker公司已经认识到自己将会遇到大麻烦，并承认Kubernetes比Swarm更适合管理大型复杂的容器环境。尽管如此，Docker仍然为低强度工作保留了其初始的集群系统（即“Swarm 模式”），比如位于防火墙后面的本地应用，这些应用在数量上不会有大的增长。
Heptio Kubernetes付费版
为了提供基于 Kubernetes 的服务和产品，Kubernetes 的两位发明者Craig McLuckie 和Joe Beda 共同创立了Heptio。他们的第一个主要产品是Heptio Kubernetes 付费版（HKS），这是一项需要付费的 Kubernetes 部署服务，由Heptio提供24/7 全天候支持。起步价为每月 2000 美元。
Heptio的主要卖点是提供没有厂商锁定的企业级Kubernetes。该产品可以运行在公有云或私有硬件上。由Heptio提供的所有Kubernetes配置管理工具都是开源的，补丁可以直接推送到受支持的集群。
Mesosphere DC/OS
Mesosphere DC/OS通过Apache Mesos将一组机器转变成可动态分配给多个应用的单个资源。Kubernetes被支持作为DC/OS 上众多应用程序包中的一个，允许用户跨 DC/OS 群集安装、运行和更新Kubernetes。
DC/OS 本质上是否是一个Kubernetes发行版值得商榷。这主要是考虑到Kubernetes 并不完全是 DC/OS 的一部分，但可以像其他被支持的应用一样通过DC/OS来部署，就像Linux应用可通过Linux发行版的软件包管理系统进行管理一样。尽管如此，Mesosphere使用Kubernetes的方式严格遵循Kubernetes 的工作方式。例如，他们使用Kubernetes 的主流社区发行版以确保与现有工具集有着高度的兼容性。
Mirantis云平台
正如 Mirantis 所言，Mirantis云平台将OpenStack、Kubernetes 或两者的组合作为“敏捷基础设施平台”的基础。简而言之，Mirantis Cloud Platform 是一个用于编排虚拟机、容器和裸机服务器的单一集成解决方案。该平台以“DevOps 方式”管理部署在该平台上的应用程序，使用 Salt 作为配置管理工具，并集成 CI/CD 支持以确保应用程序被正确部署。 Mirantis云平台能够直接在裸机、OpenStack集群或公有云上运行Kubernetes。据Mirantis称，Mirantis云平台可以更容易地与Kubernetes协同工作，原因在于配置Kubernetes底层基础设施的工作不会落在终端用户身上。
Platform9 托管的Kubernetes
大多数Kubernetes发行版将重点放在了让 Kubernetes 从内到外和从上到下都易管理上。Platform9托管的Kubernetes可以在本地的裸机或远程的公有云等任意环境中运行，并可由 Platform9的工程师作为服务进行远程管理。
在客户的监督下，Platform9大约每六周就会对托管的Kubernetes进行一次更新。 Platform9还提供了一些正常情况下必须手动添加至Kubernetes集群中的功能，比如针对多租户场景的用户配额。此外，Platform9还提供了与无服务器计算服务（“函数即服务”系统）的Platform9 Fission 项目的集成功能，其可在容器化环境下与大多数编程语言协同工作。
Rancher 2.0
Rancher 实验室已经将Kubernetes集成到了他们2.0 版本的Rancher容器管理平台中，不过目前Rancher 2.0还处于测试阶段。相比其他的Kubernetes发行版，Rancher 2.0 在更高的层级上工作，其位于Linux主机、Docker容器和 Kubernetes 节点之上，可以在不考虑位置和基础设施的情况下独立管理所有这些节点。它们甚至可以管理位于亚马逊EKS、谷歌Kubernetes引擎、微软Azure容器服务和其他Kubernetes即服务云上的Kubernetes集群。
Rancher 也有自己的Kubernetes发行版。Rancher的目的是消除搭建Kubernetes 集群和为特定环境定制的Kubernetes时所遇到的繁琐工作，同时防止一些自定义功能妨碍Kubernetes进行顺畅的升级，这对于那些快速发展和经常性更新的项目来说是一个非常重要的考虑。
红帽OpenShift
作为红帽的平台即服务（PaaS） 产品，红帽OpenShift最初使用的是类似于Heroku buildpack的“cartridges”来打包应用，然后把它们部署到名为“gears”的容器中。在Docker出现后，OpenShift被进行了重写，以便利用新的容器镜像和运行时标准。红帽也不可避免地将Kubernetes作为OpenShift内的编排技术。
OpenShift创建的目的是为了向 PaaS中的所有组件提供抽象和自动化。这种抽象和自动化也扩展到了Kubernetes，这也带来了相当大的管理负担，而OpenShift 可以用来在PaaS大型部署任务中缓解这些负担。有兴趣的读者可以查阅InfoWorld网站关于红帽OpenShift 3的测评，以了解更多信息。
Stackube
作为专门用于运行容器的Hyper.sh云服务的开发商，HyperHQ开发出了一个“以 Kubernetes为中心的OpenStack发行版”，即Stackube。通常情况下，OpenStack 使用一个名为Nova的组件来配置和管理计算节点，Stackube则使用的是 Kubernetes替代了Nova。除此之外，它们使用的是“不做任何修改的原”OpenStack 和 Kubernetes，所有其他额外细节都由OpenStack插件进行处理。
HyperHQ称，Stackube的主要优势是它们可以根据使用哪个容器运行环境提供多种不同类型的多租户。对于“软”多租户来说，他们可以使用Docker，如果想实现企业级的资源分离，那么他们可以使用HyperContainer，因为后者使用了管理程序级的隔离
SUSE云即服务（CaaS）平台
以在欧洲广泛使用的Linux发行版而闻名的SUSE也推出了SUSE CaaS平台。在概念上，它们会让人联想到CoreOS Tectonic，后者为一套裸机“微”操作系统，能够运行容器和作为容器编排系统的Kubernetes、内置的镜像注册表和集群配置工具。
SUSE CaaS平台能够在公有云和本地裸机上运行，不过需要注意的是SUSE目前并不支持與底层云基础设施的任何集成。这意味着SUSE CaaS平台的设计不是作为亚马逊EKS或谷歌Kubernetes引擎的补充而设计的，而是为了战胜这些产品，让用户可以跨多个云和数据中心运行容器。
Telekube
Teleport SSH服务器的开发商Gravitational推出了可在在本地或远程集群上运行的“生产强化型”Kubernetes 发行版，即Telekube。Telekube 定位为私有软件即服务（SaaS）平台解决方案，可跨多个地区或托管服务提供商将Kubernetes 作为一项服务予以运行。
Telekube 上的应用必须具备能够在Kubernetes上的容器中运行的能力。此外，它们必须被打包至“Bundls”中，随后“Bundls”将被发布到Kubernetes集群中。在部署基于容器的应用之前，虽然还需要为捆绑做一些额外的工作，不过Bundle 清单是用户唯一需要维护的Telekube额外工作。
本文作者Serdar Yegulalp为InfoWorld网站资深撰稿人，长期关注机器学习、容器、开发运营和Python生态系统，并定期对上述内容进行总结。
原文网址
https：//www.infoworld.com/article/3265059/containers/12-kubernetes-distributions-leading-the-container-revolution.html
如果你需要大规模的容器编排，就可以借助Kubernetes这个项目。这个出自谷歌的开源容器编排系统备受好评，不仅得到了良好的支持，而且发展势头迅猛。
尽管如此，Kubernetes仍存在庞大、复杂，并且难以搭建和配置的问题。不仅如此，它还将许多繁重的工作留给了终端用户。因此，最好的方法是不要自己单独去尝试它们，而是寻找一个含有Kubernetes的完整的容器解决方案。在这个解决方案中，Kubernetes会被作为组件得到支持和维护。
我在这里列出了12个最具知名度的Kubernetes解决方案，它们实际上是整合了Kubernetes和容器工具的发行版，也就是由众多厂商推出的带有Linux内核和用户层的发行版。
需要注意的是，本文重点关注的是可在本地运行或可被云托管的软件发行版，不包括如亚马逊EKS或谷歌Kubernetes引擎等专用的云服务。
CoreOS Tectonic
CoreOS提供了专注于容器的Linux发行版，并且可以与Docker兼容，不过它有着自己的镜像格式和运行环境。与此同时，还提供了一款“企业级Kubernetes”发行版。两者一起共同构成了CoreOS Tectonic堆栈的基础。
CoreOS操作系统Container Linux与众不同，主要是因为它们被作为一套容器化组件交付。这样一来，操作系统的自动更新可以在不影响应用正常运行的情况下顺畅地进入到生产环境中。CoreOS还表示他们可以对Kubernetes进行“一键”更新。CoreOS Tectonic可以在亚马逊网络服务（AWS）、微软Azure和裸机上运行。
Canonical 版的Kubernetes发行版
Ubuntu Linux的开发商Canonical也推出了自己的Kubernetes发行版。Canonical版的Kubernetes发行版的一大卖点是它们立足于已得到广泛推崇并部署的Ubuntu Linux发行版。Canonical称，其堆栈可以在任何云端或本地运行，并且支持由CPU和GPU驱動的工作负载。付费用户可以让Canonical工程师远程管理他们的Kubernetes集群。
Canonical 和 Rancher 实验室共同推出了 一款名为“云原生平台”（Cloud Native Platform）的产品，该产品将 Canonical的Kubernetes发行版与Rancher的容器管理平台整合到了一起。其理念是使用Kubernetes来管理每个集群中运行的容器，同时使用Rancher来管理多个Kubernetes集群。Cloud Native Platform 将随 Rancher 2.0 一起推出，目前仅提供了测试预览版。
Docker 社区版/Docker 企业版
对于我们当中的大多数人来说，Docker就是容器。自2014 年以来，Docker 拥有了自己的集群和编排系统Docker Swarm，直到近期它们还是 Kubernetes 的竞争对手。然而在2017 年 10 月，Docker宣布将不做任何修改处于原本状态的Kubernetes作为Docker社区版和 Docker Enterprise 2.0 的标准插入式组件。
简而言之，Docker公司已经认识到自己将会遇到大麻烦，并承认Kubernetes比Swarm更适合管理大型复杂的容器环境。尽管如此，Docker仍然为低强度工作保留了其初始的集群系统（即“Swarm 模式”），比如位于防火墙后面的本地应用，这些应用在数量上不会有大的增长。
Heptio Kubernetes付费版
为了提供基于 Kubernetes 的服务和产品，Kubernetes 的两位发明者Craig McLuckie 和Joe Beda 共同创立了Heptio。他们的第一个主要产品是Heptio Kubernetes 付费版（HKS），这是一项需要付费的 Kubernetes 部署服务，由Heptio提供24/7 全天候支持。起步价为每月 2000 美元。
Heptio的主要卖点是提供没有厂商锁定的企业级Kubernetes。该产品可以运行在公有云或私有硬件上。由Heptio提供的所有Kubernetes配置管理工具都是开源的，补丁可以直接推送到受支持的集群。
Mesosphere DC/OS
Mesosphere DC/OS通过Apache Mesos将一组机器转变成可动态分配给多个应用的单个资源。Kubernetes被支持作为DC/OS 上众多应用程序包中的一个，允许用户跨 DC/OS 群集安装、运行和更新Kubernetes。
DC/OS 本质上是否是一个Kubernetes发行版值得商榷。这主要是考虑到Kubernetes 并不完全是 DC/OS 的一部分，但可以像其他被支持的应用一样通过DC/OS来部署，就像Linux应用可通过Linux发行版的软件包管理系统进行管理一样。尽管如此，Mesosphere使用Kubernetes的方式严格遵循Kubernetes 的工作方式。例如，他们使用Kubernetes 的主流社区发行版以确保与现有工具集有着高度的兼容性。
Mirantis云平台
正如 Mirantis 所言，Mirantis云平台将OpenStack、Kubernetes 或两者的组合作为“敏捷基础设施平台”的基础。简而言之，Mirantis Cloud Platform 是一个用于编排虚拟机、容器和裸机服务器的单一集成解决方案。该平台以“DevOps 方式”管理部署在该平台上的应用程序，使用 Salt 作为配置管理工具，并集成 CI/CD 支持以确保应用程序被正确部署。 Mirantis云平台能够直接在裸机、OpenStack集群或公有云上运行Kubernetes。据Mirantis称，Mirantis云平台可以更容易地与Kubernetes协同工作，原因在于配置Kubernetes底层基础设施的工作不会落在终端用户身上。
Platform9 托管的Kubernetes
大多数Kubernetes发行版将重点放在了让 Kubernetes 从内到外和从上到下都易管理上。Platform9托管的Kubernetes可以在本地的裸机或远程的公有云等任意环境中运行，并可由 Platform9的工程师作为服务进行远程管理。
在客户的监督下，Platform9大约每六周就会对托管的Kubernetes进行一次更新。 Platform9还提供了一些正常情况下必须手动添加至Kubernetes集群中的功能，比如针对多租户场景的用户配额。此外，Platform9还提供了与无服务器计算服务（“函数即服务”系统）的Platform9 Fission 项目的集成功能，其可在容器化环境下与大多数编程语言协同工作。
Rancher 2.0
Rancher 实验室已经将Kubernetes集成到了他们2.0 版本的Rancher容器管理平台中，不过目前Rancher 2.0还处于测试阶段。相比其他的Kubernetes发行版，Rancher 2.0 在更高的层级上工作，其位于Linux主机、Docker容器和 Kubernetes 节点之上，可以在不考虑位置和基础设施的情况下独立管理所有这些节点。它们甚至可以管理位于亚马逊EKS、谷歌Kubernetes引擎、微软Azure容器服务和其他Kubernetes即服务云上的Kubernetes集群。
Rancher 也有自己的Kubernetes发行版。Rancher的目的是消除搭建Kubernetes 集群和为特定环境定制的Kubernetes时所遇到的繁琐工作，同时防止一些自定义功能妨碍Kubernetes进行顺畅的升级，这对于那些快速发展和经常性更新的项目来说是一个非常重要的考虑。
红帽OpenShift
作为红帽的平台即服务（PaaS） 产品，红帽OpenShift最初使用的是类似于Heroku buildpack的“cartridges”来打包应用，然后把它们部署到名为“gears”的容器中。在Docker出现后，OpenShift被进行了重写，以便利用新的容器镜像和运行时标准。红帽也不可避免地将Kubernetes作为OpenShift内的编排技术。
OpenShift创建的目的是为了向 PaaS中的所有组件提供抽象和自动化。这种抽象和自动化也扩展到了Kubernetes，这也带来了相当大的管理负担，而OpenShift 可以用来在PaaS大型部署任务中缓解这些负担。有兴趣的读者可以查阅InfoWorld网站关于红帽OpenShift 3的测评，以了解更多信息。
Stackube
作为专门用于运行容器的Hyper.sh云服务的开发商，HyperHQ开发出了一个“以 Kubernetes为中心的OpenStack发行版”，即Stackube。通常情况下，OpenStack 使用一个名为Nova的组件来配置和管理计算节点，Stackube则使用的是 Kubernetes替代了Nova。除此之外，它们使用的是“不做任何修改的原”OpenStack 和 Kubernetes，所有其他额外细节都由OpenStack插件进行处理。
HyperHQ称，Stackube的主要优势是它们可以根据使用哪个容器运行环境提供多种不同类型的多租户。对于“软”多租户来说，他们可以使用Docker，如果想实现企业级的资源分离，那么他们可以使用HyperContainer，因为后者使用了管理程序级的隔离
SUSE云即服务（CaaS）平台
以在欧洲广泛使用的Linux发行版而闻名的SUSE也推出了SUSE CaaS平台。在概念上，它们会让人联想到CoreOS Tectonic，后者为一套裸机“微”操作系统，能够运行容器和作为容器编排系统的Kubernetes、内置的镜像注册表和集群配置工具。
SUSE CaaS平台能够在公有云和本地裸机上运行，不过需要注意的是SUSE目前并不支持與底层云基础设施的任何集成。这意味着SUSE CaaS平台的设计不是作为亚马逊EKS或谷歌Kubernetes引擎的补充而设计的，而是为了战胜这些产品，让用户可以跨多个云和数据中心运行容器。
Telekube
Teleport SSH服务器的开发商Gravitational推出了可在在本地或远程集群上运行的“生产强化型”Kubernetes 发行版，即Telekube。Telekube 定位为私有软件即服务（SaaS）平台解决方案，可跨多个地区或托管服务提供商将Kubernetes 作为一项服务予以运行。
Telekube 上的应用必须具备能够在Kubernetes上的容器中运行的能力。此外，它们必须被打包至“Bundls”中，随后“Bundls”将被发布到Kubernetes集群中。在部署基于容器的应用之前，虽然还需要为捆绑做一些额外的工作，不过Bundle 清单是用户唯一需要维护的Telekube额外工作。
本文作者Serdar Yegulalp为InfoWorld网站资深撰稿人，长期关注机器学习、容器、开发运营和Python生态系统，并定期对上述内容进行总结。
原文网址
https：//www.infoworld.com/article/3265059/containers/12-kubernetes-distributions-leading-the-container-revolution.html