从开发者的角度比较Kubernetes和Cloud Foundry从开发者的角度比较Kubernetes和Cloud Foundry

本文从一个开发者的角度，对Kubernetes和Cloud Foundry进行了多维度的比较，包括：平台是否类PaaS，支持的容器，管理控制台，命令行接口，零宕机部署，外部负载均衡，内部负载均衡，市场，配置，存储卷，启动学习过程，前景，等等。作者个人更喜欢Cloud Foundry，但他也认为，两个平台均有兼容对方特性的趋势，前景一片光明。

多年来我一直在Pivotal Cloud Foundry上开发。使用Spring Boot工具栈，我能轻松地创建CI/CD流水线并完成部署。我发现它是一个真正的敏捷平台（2018年这还是一个流行语吗?）。

另一方面，Kubernetes发展迅猛，因此我花了几周时间去理解它。我对Kubernetes不像对Cloud Foundry那么有经验，因此严格来说，以下只是一个Kubernetes初学者的观察结果。

本文将尽量从一个开发者的角度来理解两个平台的差异。这里不会有很多内部细节的架构图，纯粹是从一个用户的使用角度来看，而且该用户是一个对其它平台所知甚少的Java开发者。

这样的比较天生就是主观的，因此虽然我会尽量对任意一方都提供客观的比较，我仍会对哪一方更适合我而发表意见。因此，某些意见不一定适合你。

概览

Cloud Foundry

Cloud Foundry是一个独立于云的平台即服务解决方案。开源的Cloud Foundry由Cloud Foundry基金会开发并支持，基金会包括Pivotal、Dell EMC、IBM、VMWare以及其它许多公司。商业版本的Cloud Foundry，如 IBM Bluemix和Pivotal Cloud Foundry（简称PCF），是基于开源的Cloud Foundry 项目开发的。

Kubernetes

Kubernetes是一个来源于谷歌Borg项目的开源云平台。它由Cloud Native Computing Foundation发起，该基金会的成员包括了许多行业巨头，如AWS、Azure、Intel、IBM、RedHat、Pivotal等许多公司。

Kubernetes首要的功能是一个容器运行时。尽管不限于此，但它通常是被用来运行Docker容器。有一些解决方案基于Kubernetes提供了PaaS体验，比如RedHat OpenShift。

相似点

• 两者都使用容器的思想来隔离应用和系统其它组件。
• 两者都可以既运行在公有云（AWS、Azure、GCP）上，也可以运行在预置型云平台，如使用Vmware vsphere的云平台上。
• 两者都提供了混合环境上的运行能力，允许你在不同的云平台运行应用以提高可用性，甚至支持应用在公有云和私有云上同时运行。
• Pivotal Cloud Foundry的最新版本也开始支持Kubernetes作为通用的容器运行时。下文有更多比较。

 

PaaS和IaaS+

Cloud Foundry

Cloud Foundry最重要的特点是，它是一个PaaS。Kubernetes则不太像PaaS，有些人把它看做IaaS+ ，甚至Kubernetes 的文档也把自己描述为“不是传统的、包罗万象的PaaS”。

作为一个开发者，我觉得最大的区别是，Cloud Foundry如何采取非常Spring化的，固定的方式来开发、部署和管理。

如果你用过Spring Boot，你会知道它的其中一个强项是，通过查找maven/gradle依赖进行自动配置。例如，如果你依赖MySQL JDBC驱动，你的Spring数据框架将自动配置从而能使用MySQL。如果驱动未提供，它会回退成h2这个内存数据库。

正如我们将在本文中看到的，PCF就是采用了相似的方式进行应用部署和服务绑定。

Kubernetes

Kubernetes采用了不同的方式。它从根本上说是一个通用的容器运行时，对应用的内部工作机制知之甚少。它的主要目的是提供一个运行容器的简单基础设施解决方案，其它所有事都由开发者完成。

支持的容器

Kubernetes

Kubernetes运行Docker容器。因此，它支持各种应用，消息代理，Redis数据库，自定义Java应用，以及其它任何你可以在Docker Hub上找到的应用。

每个写过Dockerfile的人都知道，它既可以是几行描述符代码，也可以是一个相当复杂的文件。下面是我从GitHub上找的一个相当简单的例子：

FROM ubuntu
MAINTAINER Kimbro Staken 

RUN apt-get install -y python-software-properties python python-setuptools ruby rubygems
RUN add-apt-repository ppa:chris-lea/node.js
RUN echo "deb http://us.archive.ubuntu.com/ubuntu/ precise universe" >> /etc/apt/sources.list
RUN apt-get update
RUN apt-get install -y nodejs 

RUN apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10
RUN echo "deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen" | tee -a /etc/apt/sources.list.d/10gen.list
RUN apt-get -y update
RUN apt-get -y install mongodb-10gen

RUN easy_install supervisor
RUN echo_supervisord_conf > /etc/supervisord.conf
RUN printf "[include]\nfiles = /var/www/Supervisorfile\n" >> /etc/supervisord.conf

ADD . /var/www

RUN cd /var/www ; npm install 

CMD ["/usr/local/bin/supervisord", "-n", "-c", "/etc/supervisord.conf"] 

这个例子对普通开发者来说虽不可怕，但我们立马知道这里有一个学习曲线。因为Docker是个通用容器解决方案，它可以运行几乎任何东西。决定容器内的操作系统如何执行你的代码是你作为开发者的任务。它很强大，但是能力越大，责任越大。

Cloud Foundry

Cloud Foundry对容器采用了一个非常固执的方式。它使用了一个叫garden的容器解决方案。PCF的较早版本的原始容器称为warden，它事实上要早于Docker本身。

Cloud Foundry自身事实上也早于Kubernetes，它的第一个版本始于2011年，而Kubernetes直到2014年才出现。

比如何使用容器运行时更重要的是，如何创建容器。

我们以一个开发者需要部署一个Spring Boot Java应用为例。

使用Docker，你需要定义一个Dockerfile以支持运行基于Java的应用。你可以用各种不同方式来定义这个容器。你可以选择不同的基础操作系统，不同服务商提供的不同JDK版本，你可以暴露不同的端口，以支持不同安全级别上的访问。没有一个标准说基于Java的Spring Boot应用该长什么样。

在Cloud Foundry，所有基于Java的应用都有一个基线buildpack，这个buildpack是由供应商提供的。一个buildpack是针对给定语言创建应用运行时的模板。buildpack是由Cloud Foundry自身管理的。

Cloud Foundry把定义容器的部分工作从开发者手上接了过来。它定了一个标准，基于Java的容器应该长什么样，这样所有开发者，不管是DevOps团队还是IT专家，都可以同步这个模板。你可以确信你的容器将和其他开发者提供的容器一样运行，不管在现有的集群内，还是将来有可能转到的公有云平台上。

当然，有时候这个基线是不够的。例如，你可能想要添加自己的自签名SSL证书到buildpack。在这些场景下你可以扩展你的基础buildpack，但那仍然允许你使用一个标准的默认包作为基线。

继续这个固定的方式，Cloud Foundry可以基于用户提供的构造件（build artifact）内容，自动区分使用哪个buildpack。这个构建件可以是一个jar包，一个PHP目录，一个nodejs目录，一个.NET可执行文件等。一旦区分出来，Cloud Foundry将为你创建garden容器。

所有这些都表明，使用PCF，你的构造件是你的本地部署文件，而在Kubernetes，你的部署件是一个Docker镜像。使用Kubernetes，你需要自己在Dockerfile中为这个Docker镜像定义一个模板，而在PCF，你可以从一个buildpack中自动获取这个模板。

管理控制台

Cloud Foundry

PCF将Web仪表盘拆分成了两个不同的目标受众。

• Ops管理员仪表目标受众是IT专家，他们负责创建虚拟机或者硬件设施，以用来创建PCF集群。
  
  
• 应用管理员仪表盘目标受众是开发者，他们负责推送应用代码到测试或者生产环境。开发者完全不清楚运行它的PCF 集群的底层基础设施。他所能看到的是分配给他的组织的配额，比如内存限制。
  
  

 

Kubernetes

Kubernetes采用了不同的方式，一个仪表盘管理了所有事物。下图是一个典型的Kubernetes仪表盘。

正如图中左手边所示，我们有许多数据可以处理。你可以访问持久化卷，后台进程，定义的角色，副本控制器等。很难区分哪些是开发者要做的，哪些是IT 管理员要做的。有人可能会告诉你在DevOps文化中，开发者和IT管理员是同一个人，这说的也对。但是在现实中，相比一个简单的应用管理员，这仍然是令人更困惑的范例。

命令行接口

Cloud Foundry

Cloud Foundry使用的命令行接口是cf。它允许开发者控制所有它能控制的东西。你可能已注意到，它仍然是顺着简化的方向走的，它的想法是对几乎所有事物都采用一种固定的方式。

例如，假如你当前在包含一个名为myapp.jar的spring boot jar文件的目录下，你可以用以下命令部署这个应用到PCF：

cf push myapp -p myapp.jar

这就是你全部要做的事。PCF将查询当前工作目录，找到可执行的jar文件。然后它将下载java buildpack，创建一个容器，计算所需内存，部署应用到当前登陆的PCF的org和space下，并根据应用名设置路由。

wabelhlp0655019:test odedia$ cf push myapp -p myapp.jar
Updating app myapp in org OdedShopen / space production as user…
OK
Uploading myapp…
Uploading app files from: /var/folders/_9/wrmt9t3915lczl7rf5spppl597l2l9/T/unzipped-app271943002
Uploading 977.4K, 148 files
Done uploading
OK
Starting app myapp in org OdedShopen / space production as user…
Downloading pcc_php_buildpack…
Downloading binary_buildpack…
Downloading python_buildpack…
Downloading staticfile_buildpack…
Downloading java_buildpack…
Downloaded binary_buildpack (61.6K)
Downloading ruby_buildpack…
Downloaded ruby_buildpack
Downloading nodejs_buildpack…
Downloaded pcc_php_buildpack (951.7K)
Downloading go_buildpack…
Downloaded staticfile_buildpack (7.7M)
Downloading ibm-websphere-liberty-buildpack…
Downloaded nodejs_buildpack (111.6M)
Downloaded ibm-websphere-liberty-buildpack (178.4M)
Downloaded java_buildpack (224.8M)
Downloading php_buildpack…
Downloading dotnet_core_buildpack…
Downloaded python_buildpack (341.6M)
Downloaded go_buildpack (415.1M)
Downloaded php_buildpack (341.7M)
Downloaded dotnet_core_buildpack (919.8M)
Creating container
Successfully created container
Downloading app package…
Downloaded app package (40.7M)
Staging…
— — -> Java Buildpack Version: v3.18 |
https://github.com/cloudfoundry/java-buildpack.git#841ecb2
— — -> Downloading Open Jdk JRE 1.8.0_131 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_131.tar.gz (found in cache)
Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.1s)
— — -> Downloading Open JDK Like Memory Calculator 2.0.2_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-2.0.2_RELEASE.tar.gz (found in cache)Memory Settings: -Xmx681574K -XX:MaxMetaspaceSize=104857K -Xss349K -Xms681574K -XX:MetaspaceSize=104857K
— — -> Downloading Container Security Provider 1.5.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-security-provider/container-security-provider-1.5.0_RELEASE.jar (found in cache)
— — -> Downloading Spring Auto Reconfiguration 1.11.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-1.11.0_RELEASE.jar (found in cache)
Exit status 0
Uploading droplet, build artifacts cache…
Uploading build artifacts cache…
Uploading droplet…
Staging complete
Uploaded build artifacts cache (109B)
Uploaded droplet (86.2M)
Uploading complete
Destroying container
Successfully destroyed container
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
1 of 1 instances running

尽管你可以几乎不用任何介入就可以启动应用，但这不是说你放弃了所有控制。PCF允许你进行很多定制。你可以定义自己的路由，设置实例数、最大内存和磁盘空间，以及环境变量等。所有这些都可以通过Cloud Foundry命令行或者通过一个manifest.yml文件作为cf push命令的参数完成。一个典型的manifest 文件可以如下图一样简单：

applications:
- name: my-app
memory: 512M
instances: 2
env:
PARAM1: PARAM1VALUE
PARAM2: PARAM2VALUE

最主要的结论是：在PCF，你提供你知道的信息，剩下的事情由平台完成。Cloud Foundry的haiku 是：

这是我的代码
请在云上为我运行
我不关心怎么运行

Kubernetes

在Kubernetes这里，你用kubectl这个命令行工具与其交互。所有命令都不复杂，但是从我目前所体验到的，命令仍然有一个很高的学习曲线。

对初学者来说，一个基本的假定是，你有一个已配置好的私有docker镜像仓库（除非你打算部署镜像到公共的镜像仓库比如docker hub）。一旦你启动了这个仓库，你需要推送你的Docker 镜像到那个仓库。

现在那个仓库已包含了你的镜像，你可以用kubectl发起部署那个镜像的命令。Kubernetes文档给出了启动一个Nginx服务器的例子：

# start the pod running nginx
$ kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster"
deployment "nginx-app" created

以上命令只启动了一个kubernetes pod并运行容器。

Pod是对一个或者一组容器的抽象，它们共享相同的网络IP和存储。它事实上是Kubernetes里最小的部署单元。你不能直接访问一个Docker容器，你只能访问它的Pod。通常一个Pod包含一个Docker容器，但是你也可以运行多个。例如，一个应用容器可能想在同一个Pod里部署一些监控的后台容器。

为了使容器在Kubernetes集群里可以被其它Pod访问，你需要用service来包装这个Pod。

# expose a port through with a service
$ kubectl expose deployment nginx-app --port=80 --name=nginx-http
service "nginx-http" exposed

你的容器现在可在容器内访问，但它仍没有暴露到外部世界。鉴于此，你需要用一个ingress来包装你的服务。

注意：Ingress仍然是一个beta特性。

当前我还没找到一条简单的命令来暴露一个Ingress（如果直接有命令，请纠正我）。我们必须先创建一个Ingress描述文件，例如：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test-ingress
annotations:
ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
  paths:
  - path: /testpath
    backend:
      serviceName: test
      servicePort: 80

一旦有了这个文件，我们可以使用下面的命令来创建Ingress：

kubectl create -f my-ingress.yaml

和PCF仅使用一个manifest.yml文件不同，Kubernetes的部署文件都是分开的，Pod创建使用pod yml文件，Service创建使用service yml文件，还有比如你上面看到的，Ingress创建使用Ingress文件。一个典型的描述文件不是完全压倒性的，但是我也不认为它是用户体验最好的。比如，下面是一个典型的nginx deployment描述文件：

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
  app: nginx
template:
metadata:
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

所有这些是想说，使用Kubernetes，你需要有明确指定。不要期望deployment有隐式操作。如果我要为Kubernetes创建一个三行诗，它很可能是这样的：

这是我的代码
我将精确地告诉你如何在云上运行
没有我的同意，你不允许做任何假定。

零宕机部署

两个平台都支持零宕机部署应用，然而这是我觉得Kubernetes获胜的其中一点，因为它提供了内建的机制，能使用回滚来支持零宕机部署。

Cloud Foundry

使用Pivotal Cloud Foundry，没有内建的机制来支持滚动升级，你只能使用Cloud Foundry命令行的某些模拟功能来执行零宕机更新。这个概念称为蓝绿部署。如果是一步步指导，它可能是这样的：

• 启动点：你在生产环境有一个myApp应用，你想要部署一个新版本-v2
• 对v2版本取一个新的应用名，比如myApp-v2
• 新的app 有它自己的初始化路由myApp-v2.mysite.com
• 针对新的应用进行测试和验证
• 给应用myApp-v2匹配一个额外的路由，使用老的应用的相同路由。例如：
  

  cf map-route myApp-v2 mysite.com —hostname myApp
  

• 现在到你的应用的请求将在v1和v2间进行负载均衡。基于你的每个版本的可用实例数，你可以执行A/B 测试。例如，如果你v1版本有4个实例，v2版本有一个实例，那么你的20%的客户端流量将被导到新的代码。
• 如果你在任何时候发现了问题，简单的移除v2就行。不会有任何问题。
• 一旦测试结果满意，扩大v2版本的可用实例数，减少甚至完全删除v1实例。
• 移除你的v2应用的myApp-v2.mysite.com 路由。现在你已经完全迁移到了新的代码，经过了健壮性测试阶段和A/B测试阶段，实现了零宕机。

 

注意：Cloud Foundry命令行接口支持扩展插件。某些插件提供了自动的蓝绿部署功能，如blue-green-deploy、autopilot和zdd。我个人觉得blue-green-deploy 易用且直观，尤其是他支持部署的自动化冒烟测试。

kubernetes

kubectl内建支持滚动升级。你只需针对一个给定的部署传递一个新的Docker镜像，例如：

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jon/kubernetes-bootcamp:v2

以上命令告诉Kubernetes对kubernetes-bootcamp这个deployment的所有Pod进行滚动升级，从当前镜像切换到新的v2镜像。在这个过程中，你的应用会一直可用。

还有更让人印象深刻的-你随时可以使用undo命令回退到之前的版本：

kubectl rollout undo deployments/kubernetes-bootcamp

 

外部负载均衡

正如我们前面所见，PCF和Kubernetes都针对你的应用实例/Pod提供了负载均衡。只要添加一条路由或者一个Ingress，你的应用就可以暴露到外部世界。

如果我们从到达应用所需经过的抽象层次来看，我们可以描述如下：

Kubernetes

ingress → service → pod → container

 

Cloud Foundry

route → container

 

内部负载均衡（服务发现）

Cloud Foundry

PCF 在集群内提供两种负载均衡的方式：

• 在传统的服务端配置中，基于路由的负载均衡。这和上面提到的外部负载均衡类似，然而你可以通过标识某些域名为内部域名，从而指定它们只能在PCF集群内访问。
• 使用Spring Cloud服务进行客户端负载均衡。这些服务集合提供了Spring Cloud框架的许多特性，Spring Cloud基于Netflix OSS。针对服务发现，Spring Cloud服务使用Netflix的Eureka。

Eureka在PCF环境中被当做系统级服务。其它的应用向Eureka注册自己，从而向集群其它应用发布自己。Eureka服务器对所有注册的客户端进行心跳健康检查，以维护一个最新的健康实例列表。

已注册的客户端可以连接Eureka并基于服务ID询问该服务可用实例（服务id指的是Spring Boot应用的 spring.application.name 变量值）。Eureka 将返回所有可用实例的列表。客户端自行决定真正访问哪个实例。通常这由Ribbon 或者Feign这些客户端负载均衡框架完成，但这属于应用的实现细节，和PCF自身没关系。

客户端负载均衡理论上更容易扩展因为每个客户端都缓存了所有可用实例，即使Eureka暂时挂掉，客户端也能继续工作。

如果你的应用已经使用了Spring Cloud和Netflix OSS技术栈，那么PCF就非常适合你。

kubernetes

Kubernetes使用DNS域名解析找到集群内其它服务。在同一命名空间下，你可以通过另一个服务的名字找到它。在不同命名空间下，你可以通过服务名加"."再加命名空间找到它。

Kubernetes的负载均衡提供的最大优势是它不需要任何特定的客户端库。Eureka最主要是针对基于Java的应用（尽管针对其它语言的版本也有）。使用Kubernetes，你可以对任何暴露了Pod的Kubernetes服务进行负载均衡的http调用，而不用考虑客户端或者服务端的实现。负载均衡的域名即是暴露了Pod的服务名。例如：

• 你在命名空间zone1下有个应用my-app
• 它暴露了一个GET请求的/myApi REST路由
• 这个应用在集群内有10个Pod实例
• 你创建了一个my-service的服务，在集群内暴露该应用
• 集群内同一命名空间下的任意Pod，可以这样调用：
  

  GET https://my-service/myApi
  

• 集群内其它命名空间下的所有Pod，可以这样调用：
  

  GET https://my-service.zone1/myApi
  

API路由将在所有可用实例间进行负载均衡。它不关心你的客户端是用Java、PHP、Ruby、.NET还是其它技术写的。

市场

PCF提供了一个服务市场。它提供了一种简单得可笑的方式将应用绑定到服务。PCF中的术语“service”和Kubernetes中的service 不一样。PCF的Service绑定你的应用到其它事物，如数据库、监控工具、消息代理等。一些开箱即用的服务包括：

• Spring Cloud服务，它提供访问Eureka，配置服务，以及一个Hystrix仪表盘。
• RabbiMQ消息总线
• MySQL

第三方供应商也可以实现他们自己的服务。由第三方提供的服务包括Datastax for Cassandra and Redislabs for Redis这俩内存数据库。下面是Pivotal Web Services上的可用服务：

IBM Bluemix是另一个Cloud Foundry供应商，它提供它自己的服务，包括针对AI的IBM Watson以及一些机器学习应用。

每个服务根据你的SLA需求都有不同的可用套餐，比如针对开发环境的一个小型数据库以及针对生产环境的高可用数据库。

最后一项要点是，你可以选择定义用户提供的服务。这允许你绑定你的应用到已存在的服务，如一个Oracle数据库，或者一个Apache Kafka消息总线。一个用户提供的服务简单说就是一组键值对，你可以以环境变量的方式注射它们到你的应用。它提供任意特定的配置，比如URL，环境的用户名和密码，服务从属于PCF 的一个空间（space）。

kubernetes

Kubernetes不提供开箱即用的市场。它有一个服务目录扩展，支持提供类似的服务目录，但它还在beta阶段。

由于它可以运行任何Docker容器，从某种程度上看，Dockerhub就可以被认为是Kubernetes的市场。你可以运行任何可在容器内运行的东西。

Kubernetes也有一个类似于用户提供的服务这样一个概念。任何配置或者环境变量都可存在于ConfigMap，它允许你将容器配置外部化，从而使其更便携。

配置

提到配置，Spring Cloud Services的其中一个特性就是Spring Cloud Config。它是特定针对Spring Boot应用的另一个服务。这个配置服务提供一个来源于你所选git仓库的配置件，从而支持零宕机的配置变更。如果你的Spring bean被打上@RefreshScope标签，他们可重新加载更新的配置，通过对你的应用调用一个POST的/refresh API。作为配置源的属性文件基于预定义的加载顺序被加载，这些加载顺序提供了某些基于原型的机制来确定配置如何加载。这是一个很棒的方式，但是它仍假定你的应用基于Spring Boot技术栈。如果你现已使用Spring Boot的配置服务，PCF非常适合你。

在Kubernetes，你仍然可以以容器的方式运行配置服务，但是那极有可能是一个不必要的操作负担，因为你已经有了内建的ConfigMap的支持。使用平台原生支持的方案更好。

存储卷

Kubernetes的一个最大区别是它支持关联一个存储卷到你的容器。Kubernetes使用etcd作为媒介管理存储卷，你可以关联这种卷到你的任意容器。这意味着你拥有了一个可靠的存储方案，它允许你运行基于存储的容器，比如数据库或者文件服务器。

在PCF，你的应用是完全无状态的。PCF遵循12因素应用模型，这个模型的其中一条就是假定你的应用无状态。理论上你应当将当前运行在你的预置数据中心的应用，移植到AWS的时候，假如有适当的连接，它也应该能工作。任何基于存储的解决方案，要么转到一个PCF服务，要么转到PCF集群外的存储解决方案。这是缺点还是优点，取决于你的应用和架构。对无状态的应用运行时，比如Web服务器，将它从内部存储设备解耦出来总是一个好主意。

启动学习过程

kubernetes

开始学习Kubernetes不容易。正如前面所提到的一样，你无法用个5分钟的快速启动指南来开始学习，有许多事物你需要提前知道，以及许多假定你都要提前满足（Docker仓库以及Git仓库总是需要授权的）。

看一下精彩的Kubernetes基础交互指南，它展示了使用该平台所需掌握的知识。对一个基本的启动学习过程，有6 个步骤，每个步骤都包含了相当多的你需要理解的命令和术语。想要尝试跟随这个例子使用本地的minikube虚拟机，而不是预先配置好的在线集群，是相当困难的。

Cloud Foundry

开始学习PCF是很容易的。你的开发者已经知道如何开发他们的Spirng Boot / Node.js / Ruby / .NET 应用。他们已经知道这些构件是什么。他们也很可能已有一些Jenkins流水线。他们只是想要在云上运行相同的东西。

如果我们看一下PCF 的“开始学习 Pivotal Cloud Foundry”，我们可以发现它几乎没有任何东西需要启动和和运行。当你需要更复杂的交互，它都给你准备好了，不论是Cloud Foundry命令行工具，manifest.yml，还是Web控制台，但是它不阻止你快速启动学习。如果你主要是开发服务端的应用，使用Java或者Node.js，那么PCF使你更简单，更快速且更智能得上云。

前景

Kubernetes

Kubernetes真正是一个伟大的开源平台。我们要赞扬Google，它放弃对Kubernetes的控制，由社区来主导。可能那就是Kubernetes如此迅速地脱颖而出，而其它解决方案，比如Docker swarm被甩在后面的最大原因。其它供应商也提供了基于Kubernetes的更像PaaS的解决方案，比如RedHat OpenShift。

但是伴随着多样性和繁荣的生态系统的同时，Kubernetes的前景也有许多不同的方向。某种程度上它确实像一个Google的产品，或许它将会接受Google持久的支持，或许它会改为不再支持后向兼容，又或者它将被停止并转向下一个热门（还有人记得Google Buzz，Google Wave，或者 Google Reader？）。任何正在转向Angular 5的AngularJS 开发者都会告诉你后向兼容不是最高优先级的。

Cloud Foundry

Cloud Foundry也是一个繁荣的开源平台，但是这个平台谁定调子相当清晰。那就是Pivotal，以及IBM的部分贡献。是的，它是开源的，但是它的企业版是Pivotal Cloud Foundry，它提供了额外的功能，比如服务市场，运维管理等。从这个角度来说，它是有限的民主。这个产品主要服务企业客户，它的特性集将最先响应那些客户的需求。

如果Kubernetes是Google，那么PCF就是Apple。

它相对来说有更多的门槛，更多的控制，更好的设计，以及发布一个更好产品的承诺。我感觉这个平台更聚焦，而聚焦在我的工作中非常重要。

PKS

最近发布的PCF 2.0版本，真正的惊喜是，所有我在本文中讨论的，当前已成了这个版本的一部分。应用运行时（本文中所有和PCF相关的）现在称为Pivotal Application Service（PAS）。它还有了一个新的无服务器解决方案，称为Pivotal Function Service（PFS），以及一个新的Kubernetes运行时，称为Pivotal Container Service（PKS）。这意味着Pivotal Cloud Foundry当前可以给你两个世界的最佳体验：一个极佳的应用运行时，供云原生应用快速上线，以及一个极佳的容器运行时，当你需要开发通用的底层容器时。

结论

本文尽可能得分享了我在两个平台的个人体验。尽管我有一点点偏向PCF，那是因为它已很好得给我提供了服务。我尽可能公正得体验Kubernetes，发现它是一个非常万能的平台，但也是一个需要更陡峭的学习曲线的平台。可能我在Spirng生态系统中呆得太久了吧！随着最新的PKS发布，Cloud Foundry将提供最佳的整合PaaS，它允许你又快又简单地运行云原生应用，同时也支持最佳的通用容器运行时。我能想到这在很多场景下都很有用。例如，Apache Kafka是现今其中一个最佳的消息代理，但是这个消息代理目前仍没有可用的PCF服务，因此它必须运行在外部虚拟机上。现在有了PCF 2.0，我可以在PCF集群内运行Apache Kafka Docker容器了。

最主要的结论是，这不是一个非此即彼的讨论。因为应用运行时和容器运行时这两者现在在同一个产品内共生，两者的前景是非常光明的。

感谢您的阅读，祝您编码愉快！

原文链接：Comparing Kubernetes to Pivotal Cloud Foundry -- A Developer's Perspective （翻译：池剑锋）