然而相比起Kubernetes的热度和知名度，这个被人们寄予厚望的工具在企业中成功落地的着名案例却少的多了。尤其是在传统的企业之中，不管是开发和运维都在反映Kubernetes有点难，不容易使用。为什么会这样？
原因很简单，Kubernetes不是设计来直接使用的。我们先来看看Google自己是怎么说的吧：
Kelsey Hightower 是谷歌云非常资深的布道师，可以说他的声音也就代表了谷歌官方的思路，而这个思路对于Kubernetes的定位很明确：Kubernetes本身并不是一个直接可用的平台，而是一个用来构建平台的基础。
也可以打个比方，如果我们把现代的云平台看成是一个操作系统的话，那么Kubernetes只是这个操作系统的内核。从一个操作系统的内核到一个企业级操作系统还差多少东西？相信读者们都应该很清楚。
所以，不管是开发还是运维，若想把“传说中”Kubernetes的各种威力发挥出来，只是靠Kubectl而没有其他合适的工具，那是非常困难的。例如，我们来看看以下几个场景：
- 某公司A有几个应用软件开发商与其长期合作，目前都是通过容器镜像的方式为该公司提供最新的软件版本。但是由于历史原因，各开发商提供的镜像中的操作系统，中间件或者软件工具各不相同，经常出现因为安全或者合规问题无法部署到生产环境而引起项目交付延迟的情况；
- 某公司B基于某个版本的操作系统已经在生产环境中部署了几百个容器，并且运行良好。最近该公司的IT部门得知该公司当前版本的操作系统发现了严重的安全漏洞，需要立即打上安全补丁，但是这些应用绝大多数是要求不间断运行的，怎么办？
- 某公司C为了提高生产效率，已经在内部建立起了CI/CD管道来自动化软件的开发测试部署过程，并且一直在根据使用效果做持续改进。最近该公司发现一年前部署的一个软件版本出现了bug需要修复，但是现在的CI/CD管道已经做了几次修改，其中依赖的软件版本都已经有了变化，已经无法重新构建出原来的软件环境，只有重新手工操作或者重新配置CI/CD管道…
这些例子在日常工作中可能都非常常见，他们集中体现了在企业环境中使用Kubernetes的一个典型的难点：如何同时满足开发团队对于“高效率”和运维团队对于“安全可控”的需求？
而这正是kpack所要解决的问题。
Kpack，其全名是Kubernetes Native Container Build Service，如其英文名所示，是一个Kubernetes原生的容器构建工具。Kpack具体能做什么事情？它又能为我们日常的开发和运维工作带来哪些助益？下面容我为大家细细道来。
什么是Kpack？
Kpack是由原来的Pivotal，也就是现在的VMWare开源的软件工具。简单来讲，kpack其实就是Kubernetes的一组扩展的资源定义（CRD），它通过声明式的方式来配置一个符合OCI标准的容器镜像，然后可以直接通过源代码来自动化地构建这个镜像并上传到指定的镜像仓库。
废话不多说，我们先通过一个动画来看看Kpack是怎么使用的：
在动画中，演示人员首先创建了一个容器镜像的描述文件image.yaml，然后直接执行kubectl apply -f image.yaml，我们可以看到容器镜像就已经构建成功并且上传到了镜像仓库中！
为了了解清楚整个过程都发生了什么事情，我们不妨把整个动画一帧一帧地再重放一遍。
首先我们看一下演示人员使用的image.yaml都包含哪些内容：
在这个描述文件中，最关键的就是两个配置项：tag和source。其中，“tag”指的就是生成的容器镜像，而“source”则是软件版本管理系统中源代码的位置（url）和版本（revision）。这里假设版本管理用的是git。
当然，在执行命令kubectl apply -f image.yaml之前，这个Kubernetes集群已经已经配置好了镜像仓库例如Harbor等，并且这里配置的serviceAccount可以访问该镜像仓库。
然后我们再看看接下来的几个命令在做什么。
- Kubectl get images: kpack会对每个构建出来的镜像进行记录，调用这个命令会列出当前所有kpack构建的镜像。当然，如果想查看某个镜像的详细信息，可以调用命令kubectl describe image
。
- Kubectl get builds: 除了构建的容器镜像以外，kpack也同样会对每一次镜像构建的build过程做记录，用kubectl get builds就可以获得过去所有构建镜像的build操作。为了很明显地看出每一次build具体对应于哪一个镜像，build的名称都是用镜像的名字做开头，后面加上随机数字，就如上图所显示的那样。同样，用kubectl describe build也可以看到具体build的详细信息。
- Logs -image=demo-image: 查看镜像构建的日志。“logs”是kpack提供的一个日志工具，可以专门用来查看kpack打印出来的日志，可以用于镜像构建的调试。
那么日志究竟打印出来了什么内容？如下可以看到日志开头的一小部分：
没错，对PaaS产品有一定了解的读者可能已经猜到了，kpack的核心，真正执行容器构建操作的其实就是着名的Buildpacks，现在也是CNCF中最受关注的开源项目之一：Cloud Native Buildpacks。
为了让大家对Buildpack和其工作机制有一些了解，这里有必要先来简单介绍一下Buildpack和Cloud Native Buildpacks的关系。
BuildPacks和Cloud Native Buildpacks
Cloud Native Buildpacks是从早年Pivotal和Heroku提出的buildpack的概念演化而来。Buildpack的主要思路就是：在多数情况下，把软件从源码打包到容器镜像的过程是一个重复性操作，因此应该完全是自动化的。
为了完全实现这个自动化过程，Buildpack里面包含了构建一个容器镜像所需要的主要组件，如操作系统，容器化的中间件，开源组件，主流编程语言的运行环境和通用服务等。例如，早期的Buildpacks支持的语言包括Java，Windows（托管Web Core）上的。NET，。NET Core，Node.js，Go，PHP，Python和Ruby等。
使用Buildpack方法，在部署应用程序时，Buildback程序将自动生成，容器化和运行应用程序所需的所有框架和运行时支持汇总在一起。它通过“读取”代码并下载运行它所需的依赖项来实现。比如说，如果发现push上来的文件当中包含了。jar文件，那么就选择用Java Buildpacks来构建容器镜像；如果包含了。php文件，那么则会用PHP Buildpack来构建容器镜像，等等。除此之外， Buildpack还会配置该应用程序所需的网络服务。
作为Buildpack的联合发起者，自然Heroku和Pivotal都把Buildpack集成到了自己的PaaS平台当中，例如Pivotal主导开发的开源PaaS平台Cloud Foundry以及自己的商业产品Pivotal Application Service（Pivotal Cloud Foundry的2.0版本），就是依赖于Buildpacks打造了广受企业开发者喜爱的应用一键部署的体验“cf push”，如下所示：
cf push是Cloud Foundry的一个命令，开发人员通过这个命令，可以把自己编译好的应用“扔到”PAS平台上，然后PAS平台就会为应用自动选择合适的Buildpack，将应用封装到容器里面，并自动完成以上列出的所有上线步骤（部署容器，加载环境变量，配置负载均衡，配置防火墙和安全策略，配置APM，配置日志等等）。
更重要的是，很多已经大规模用于生产环境的Buildpack是由一些公司定期维护和更新的。因此，开发和运维人员都不用担心他们所使用的软件和库是否是最新和最安全的，因为它们已经内嵌到Buildpacks中了。这正像大型Buildpack支持者Pivotal也就是现在的VMware所说的那样，“您不必考虑依赖库，中间件或运行时组件，平台可以为您完成。”
而在近年来随着Kubernetes逐渐发展成为标准基础设施的一部分，业界对于将Buildpacks用于Kubernetes平台的呼声越来越高。因此，Pivotal（VMWare）和Heroku又将Buildpacks在Kubernetes平台之上做了适配和优化，并且启动了一个新的CNCF项目Cloud Native Buildpack（以下简称CNB）。相比之前的Buildpacks，CNB的能力又得到了进一步的提升：开发人员甚至都不用自己去编译代码了，CNB已经支持了源代码在线编译的能力，所以开发人员可以直接把应用的源代码“扔”给CNB，CNB就可以自动对源码进行编译并打包成容器镜像！
那么下面我们就对Kpack的引擎CNB做一下深入的分解，看看它究竟是如何工作的。
Cloud Native Buildpacks的工作原理
我们可以用多种方式来集成CNB，不过对于CNB来说，不管如何被集成，它的工作总是从接收到应用的源码开始的。
我们还是看一下Kpack的场景。Kpack会从指定的url下载应用的源码，然后将这些源码交给CNB。在CNB接收到了源代码之后，会通过如下四个步骤完成它自己的全部任务：
- Detection（检测）: 查找系统中可以用于应用构建的Buildpack，例如Java Buildpack， .Net Buildpack, Go Buildpacks等等，然后按照默认的顺序逐个判断哪个Buildpack可以用于当前代码的构建；
- Analysis（分析）: 确定具体的Buildpack之后，将Buildpack解包，找到那些可以用于优化构建和导出阶段的文件，以备稍后使用；
- Build（构建）: 将应用程序源代码转换为可打包到容器中的可运行工件；
- Export（打包）: 创建最终的符合OCI标准的容器镜像。
注意，虽然Docker镜像在日常工作中使用最多，但是CNB旨在支持所有符合OCI标准的镜像格式。
那么我们还是看看刚才kpack打印出来的日志，就大概了解这四部分是怎么工作的了。
首先，从日志的第一行，我们看到Kpack将示例应用源代码clone下来，然后交给了CNB。访问一下这个应用所在的url，我们会发现这个应用是一个Node.js应用。
然后，CNB开始启动第一步，检测自己现有的Buildpack哪一个能够支持这个代码的构建。
1、检测
为了便于Buildpack的管理，我们看CNB将Buildpack按照编程语言分成了不同的组，如果开发人员不指定具体的Buildpack，那么CNB就会把每个组都拿出来逐个与源码进行匹配，下面的日志显示了第一组所包含的Buildpack。
很明显第一组里面包含的都是支持Java的buildpack，因为Java在企业应用中最为常见，所以在这里检测时把这一组放在最前面。但是由于这个应用是node.js的，所以第一组不合适。（如果开发人员用Spring Boot去开发应用，从最新的2.3版本开始，其实还有更简单的方法使用Java Buildpacks，后面我们会提到。）
第二组和第三组都有Node Engine Buildpack，不同的第二组的包管理用的是Yarn，而第三组用的是NPM。由于CNB在源码当中发现了package.json而没有yarn的关键文件yarn.lock,所以CNB判断这个需要用NPM Buildpack来支持。所以，第三组的两个buildpack全部检测通过 ，第一个步骤完成，开始进行第二步的操作。
2、分析
在确定了Buildpack之后，可以看到日志里面有这样一句：“Cache ‘/cache’： metadata not found, nothing to restore”。这是在分析Buildpack之前，kpack首先要先看看对于这个应用源代码，系统内部有没有缓存的直接可用的镜像层的缓存。这个缓存机制非常重要，因为随着应用的不断迭代，每天都需要不断地修改源码并且进行测试，如果有这样一个cache将之前已经构建好的镜像层在内部进行缓存，那么在应用的首次构建之后，以后的构建就无需再一遍遍重新“拼接”出这个镜像层，在完成第一步检测之后直接使用cache中的镜像层就可以了。
在本例中，因为是第一次构建，所以Kpack没有发现cache中有已经构建过的镜像层，所以就需要对镜像的配置（主要基于image.yaml）进行分析，并依次调用两个Buildpack进行镜像的构建工作。
看到这里我们一定要说清楚一个很重要的问题：对每一个编程语言就用一个Buildpack不就行了吗？这样多方便，干嘛要分解成多个Buildpack来完成？
灵活性肯定是这个问题的答案之一，但是其实这里面还有另外一个更重要的因素，那就是这个平台的可维护性。
我们可以回想一下文章开头提到的B公司的例子。如果一家公司基于某个版本的操作系统已经部署了很多容器，而后来这个版本的操作系统出现严重的安全漏洞需要打安全补丁，那该怎么办？把所有的这些应用的镜像全部重新构建，测试，升级部署吗？如果这样的容器有几百个甚至几千个，这得需要多少工作量？！多长时间才能完成？只怕是还没等完成，黑客就已经入侵系统了…
而在CNB里面，每一个Buildpack都被设计成可以构建为镜像的一个layer，这样当每一个buildpack中包含的软件出现了新版本，需要打安全补丁，或者需要进行定制，我们只需要修改这个buildpack就好，正如下图所示：
即便是对于已经用原来的Buildpack已经构建并已经运行的容器镜像，也无需重新对原来的镜像全部重新构建，因为CNB提供了rebase的功能，通过这个功能，CNB会检查应用当前的基础镜像是不是有最新版本可用，如果有的话，可以将已经构建好的容器中的基础镜像直接替换掉。对于那些未来要开发运维几百，几千甚至几万容器的企业来说，这个功能不管是对于开发人员还是运维人员来说，无疑都是一个福音。
说清楚了这一点，我们也就很容易看懂例子中这两个Buildpack在做什么了：
- Node Engine Buildpack会下载Node.js的运行时环境，并进行配置；
- NPM Buildpack会根据package.json中的内容，下载编译运行本应用所需要的所有的依赖库；
这两部分分别构成了容器镜像中的两层。这样构建容器镜像的材料都已经齐备，可以开始build image了。
3、构建
对于Node.js来说，因为代码不需要编译就可以运行，所以这一步很简单，只是需要把源代码copy过来就可以了。
如果是其他需要编译的语言比如说Java，这里可能就需要Maven或者Gradle的Buildpack（根据应用源代码的配置）来对源码进行编译了。
4、打包
从日志当中我们可以看出，这个image构建成功，共由5个layer组成，分别是app，config，launcher，以及分别由两个Buildpack所构建的node engine和node modules。
这里特别需要注意的是日志打印出的最后一行：“Caching layer …”。正如之前提到的，在这次构建完成之后，node engine这一层的layer将会被缓存在系统中，这样以后再重新构建该应用的镜像的时候，就无须再重新下载node.js的运行时并构建这层layer了。
至此，镜像已经构建完成。我们也已经了解了CNB是如何通过一系列自动化的操作将应用的源代码直接构建成容器镜像的。事实上，Buildpack的技术体系经过近10年的不断发展和优化到今天，已经兼备了成熟性和灵活性，除了今天我们所介绍的KPack以外，通过把它和其他的技术相结合，可以开发出各种高效的新平台，或者是推动现有工具的创新发展。
例如，就如前文所提到的，在企业最常用的微服务开发框架Spring Boot的2.3版本中，已经预集成了Cloud Native Buildpacks，而且使用起来非常简单。具体来说，通过在Maven中使用新的spring-boot:build-image goal，或者是在Gradle中使用bootBuildImage task，都可以通过我们刚刚介绍的CNB的能力直接将源码构建成为容器镜像。有兴趣的读者不妨一试，体验一下无需安装任何工具便可以实现的全自动化的镜像构建过程。
Kpack的使用
所有的开源项目，包括像Kpack这样的项目，如果真的想要在实际工作中使用，都会有一些特别的问题需要注意，下面我们就了解一下几个比较重要的问题。
从哪里可以找到Buildpacks？
其实对于我们一般的用户来说，不用关心哪里去找Buildpacks，因为我们可能常用的Buildpacks已经内置在Kpack当中以套件的方式存在，可以直接使用了，正像上面的例子当中所描述的那样。但是，我们最好还是应该了解Buildpacks具体是怎样被组织和管理的，这样我们才能用它完成日常工作中更加复杂的需求比如说它的定制和升级。
在Kpack中，还有一个很重要的组件我们没有提及，那就是Builder，而这个Builder就是Buildpacks的组合套装。根据在K8s当中的使用习惯，我们可以将Builder设定为供某一个namespace使用，或者供整个K8s全局使用的ClusterBuilder，这些都是通过yaml文件的配置实现，非常简单，不再赘述。
关键是Builder里面的结构是怎么样的？
Kpack的Builder其实是Cloud Native Buildpacks中Builder组件的CRD封装，下面就是CNB中Builder组成的示意图：
我们可以看到，Builder主要由三部分组成：Buildpacks，lifecycle以及build image。其中的lifecycle其实上面我们已经详细分析过，就是检测，分析，构建和打包这四个步骤，而build image则是build源代码所需要的基础镜像环境。
我们在图中的左边也可以看到一个run image，从名字当中可以得知，其实这个run image就是应用打包好之后可以去部署的运行环境。我们上面所提到的rebase的操作其实替换的就是这个run image：
由于CNB是公开的标准，所以Kpack可以使用任何满足这样规范的Builder。目前市场上面最为成熟和广泛使用的builder是Packto Builders。而下面就是Packto Builder当中包含的Java的Buildpacks：
Packto目前主要是由VMWare（Pivotal）来维护和发展。
当然除了Packto的Builder，还有另外两个Builder也是CNB官方推荐的，一个是来自于Google的用于GCP的Builder（gcr.io/buildpacks/builder）,另外一个则是来自于Salesforce的Heroku（heroku/buildpacks:18）。
Buildpack需要升级怎么办？
Buildpack需要升级这是一个非常明显的需求，并且因为现在技术迭代的速度越来越快，软件版本更新的频率也越来越快，这样在一年里面升级几次Buildpack是很正常的事情。
目前CNB官方推荐的builder，比如说像Packto Builder，会实时跟踪所包含的Buildpacks里面是否有任何新的升级或者安全补丁，并及时对这些Buildpack进行更新。所以，如果在Kpack里面选择使用像Packto这样比较成熟的Builder，用户自己并不需要对Buildpack的升级做操作，只是需要考虑自己本地的升级策略和配置就可以了。
比如说下面是Kpack里面一个Builder的定义，也是一个CRD：
- apiVersion: build.pivotal.io/v1alpha1
- kind: ClusterBuilder
- metadata:
- name: cluster-sample-builder
- spec:
- image: gcr.io/paketo-buildpacks/builder:base
- updatePolicy：polling
在builder的配置里面，有一个updatePolicy的配置项，这个配置项可以有两个选择，一个是“polling”，如果选择这个选项，Kpack会每隔5分钟去查看一下正在使用的builder有没有变化；也可以选择“external”，在这种情况下是由用户自己负责去升级替换Buildpack。
定制自己的Builder
下面我们把难度再提高一点：如何定制自己的Builder？
Kpack提供了另外一个CRD – CustomBuilder来支持用户自定义CNB builder的需求。但是在定义自己的Builder之前，首先需要在Kpack里面定义两个关键的资源：Store和Stack。
- Store的定义
首先是一个Store定义的例子：
apiVersion: experimental.kpack.pivotal.io/v1alpha1
kind: Store
metadata:
name: sample-store
spec:
sources:
- image: gcr.io/cf-build-service-public/node-engine-buildpackage@sha256:95ff756f0ef0e026440a8523f4bab02fd8b45dc1a8a3a7ba063cefdba5cb9493
- image: gcr.io/cf-build-service-public/npm-buildpackage@sha256:5058ceb9a562ec647ea5a41008b0d11e32a56e13e8c9ec20c4db63d220373e33
- image: gcr.io/paketo-buildpacks/builder:base
Store其实就是一个Buildpack的库，在这个库里面包含了可以用于定义CustomBuilder的所有的Buildpacks。例如，如果我们想从几个Builder里面选出一些满足自己需求的Buildpacks拼接成一个CustomBuilder，那么我们首先就需要把这些Buildpacks都列在这个Store对象里面，正如上面yaml文件所展示的那样。
- Stack的定义
在上文已经提过，其实Stack就是定义基础镜像的地方。Stack会包含两个基础镜像，一个是用于Build的，另外一个是用于应用的运行时环境的。下面就是一个示例的Stack的定义：
- apiVersion: experimental.kpack.pivotal.io/v1alpha1
- kind: Stack
- metadata:
- name: bionic-stack
- spec:
- id: "io.buildpacks.stacks.bionic"
- buildImage:
- image: "gcr.io/paketo-buildpacks/build@sha256:84f3eb6655aa126d827c07a3badbad3192288a50986be1b28ad2526bd38c93c7"
- runImage:
- image: "gcr.io/paketo-buildpacks/run@sha256:e30db2d9b15e0da9f4171e48430ce9249319c126ce6b670b68443e6c13e91aa5"
其中，id是这个stack的定义，当然企业可以根据自己的需求定义多个stack。BuildImage和runImage分别对应于构建和运行所使用的基础镜像模版。
由于很多企业对自己的基础镜像都有自己的要求，因此使用Stack来定义这些基础镜像是一个很好的办法，因为这实际上是在企业内部建立起了一个标准镜像，来自不同团队的开发人员或者应用软件供应商，通过使用Kpack生成容器镜像的过程中，默认就已经遵循了企业安全和合规性等的要求，从而很好的解决了开发/测试/生产环境差异性的问题。
有了Buildpack和基础镜像，下面就可以定义自己的Builder了。比如说，如果一个企业的某个开发团队主要基于Node.js和Java来开发应用，那么可以为他们定制如下的一个CustomBuilder：
- apiVersion: experimental.kpack.pivotal.io/v1alpha1
- kind: CustomBuilder
- metadata:
- name: my-custom-builder
- spec:
- tag: gcr.io/sample/custom-builder
- serviceAccount: default
- stack: bionic-stack
- store: sample-store
- order:
- group:
- id: paketo-buildpacks/node-engine
- id: paketo-buildpacks/yarn
- group:
- id: paketo-buildpacks/adopt-openjdk
- id: paketo-buildpacks/gradle
optional: true
- id: paketo-buildpacks/maven
optional: true
- id: paketo-buildpacks/executable-jar
optional: true
- id: paketo-buildpacks/apache-tomcat
optional: true
- id: paketo-buildpacks/spring-boot
optional: true
- id: paketo-buildpacks/dist-zip
optional: true
我们看，这个CustomBuilder使用了上面的store和stack，然后定义了两个group，分别对应于编译Node.js应用所需要的Buildpack和Spring Boot应用所需要的Buildpack。
我们再回到本文一开始提到的那个例子，在例子中镜像的定义image.yaml文件中是这样指定所用的builder的：builderRef: demo-builder。我们也可以把这个配置改成如下这样：
- builder:
- name: my-custom-builder
- kind: CustomBuilder
这样，Kpack就会用我们刚才定义的builder来构建这个镜像了。
定制自己的Buildpack
Builder可以定制，Buildpack也同样可以。比如说，对于文章开头提到的公司C的例子，即便都是在用Java开发应用，但是不同的应用依赖的JDK版本有可能个不相同，这种情况下我们可能就需要对每一个JDK版本定制一个Buildpack，并且保存在系统中以用于后面软件的更新和升级。这种情形可能相对比较简单，我们可以拷贝一个现有的Java Buildpack，然后对配置做相应的修改，重新打包就可以了。
但是有的时候，Buildpack的定制可能会很复杂。比如说如果需要在Buildpack中加入公司要求的APM或者日志管理的agent，或者应用要满足一些合规性要求，这样就需要对Buildpack的结构作比较多的修改，甚至有可能需要完全重新做一个自己的Buildpack才能完全满足要求。这一部分涉及到的的内容可能也会比较复杂，在本文中就不详述，以后有机会可以用一个单独的主题来分享。
Kpack的展望
一直以来，开发人员对效率的追求和运维人员对环境的控制始终是以尖锐的矛盾形式存在，而Buildpack技术体系在过去十年在世界各大领军企业的大规模生产实践中，成功证明了它可以作为开发和运维需求的桥梁，把这对矛盾巧妙地转化为了双方一致的目标：在安全可控环境之内的应用快速开发和部署。
而伴随着Kubernetes逐渐成为基础设施的新标准，Kubernetes社区也急需要类似Buildpack这样的技术来大大降低Kubernetes在企业落地的难度。这正是VMware（Pivotal）开源Kpack的主要原因：我们希望将世界范围内广受认可的Buildpack的技术体系和Kubernetes的声明式资源管理方式结合在一起，把过去成功的经验移植到K8s平台上面来，为社区提供一个基础和参考去做更多的创新。
当然，我们首先自己就有基于Kpack的企业级版本，那就是VMWare Tanzu产品家族中的Tanzu Build Service和Tanzu Application Service for K8s。下面我们可以分别来简单了解一下这两个企业级版本。
Tanzu Build Service：企业级容器镜像构建流水线
与很多开源软件的企业级版本一样，Tanzu Build Service（以下简称TBS）致力于将kpack与其相关的工具集成在一起，例如默认的Buildpacks和Kubernetes权限模型，这样大大减少手工的配置工作，使平台更加容易使用。
另外，我们深知很多研发和运维工程师都不喜欢写yaml文件，所以TBS还将提供一个称为kp的可选专用CLI，以帮助工程师更快地工作，并更轻松地管理团队的多租户。
当然，最重要是我们提供Buildpacks的支持和维护工作，这将会使TBS的用户放心使用安全和稳定的软件栈来部署自己的应用。
TBS比较适合于已经建立了自己的CI/CD管道的企业，因为TBS解决了最繁琐的从代码到容器镜像的自动化过程，可以直接与企业后面的应用自动部署整合在一起，形成端到端的应用部署管道。
您可以通过https://tanzu.vmware.com/build-service来进一步了解TBS。
然而，很多企业的要求可能更高，他们希望自己有一个全自动化的平台，不但整个应用的构建环境和运行环境完全可控，同时希望平台可以提供从代码到部署完成的全自动化服务，就像是上文提到的Pivotal Application Service的“一键部署”那样的体验。
这就要用到我们另外一个基于Kpack的商业产品：Tanzu Application Service for K8s了。
TAS for K8s：实现Kubernetes平台上面的应用一键部署
TAS for K8s，全名是Tanzu Application Services for K8s，是VMWare Tanzu产品家族里面的PaaS平台，正是来源于原来的Pivotal Application Service在K8s平台上面的实现（原来的Pivotal Aplication Service现在名称为TAS for VM）。
虽然从原来的基于虚拟机运行的构架重构为现在面向K8s的构架，TAS for K8s上面提供的一键部署的产品体验仍然会和原来的Pivotal Application Service类似，甚至连CLI工具都保持不变（仍然是cf push）。
在实际工作场景中TAS for K8s是怎么用的？
如果从一个开发工程师的角度来看，他只需在自己的源代码目录里面直接执行一个cf push命令，一两分钟之后，他的应用已经部署在K8s集群里面可以直接访问了！在整个流程中，Kpack会负责从代码构建为镜像的部分，然后镜像构建好之后会触发镜像的自动化部署过程，这个过程主要是由另外一个开源项目Eirini来实现，它会自动生成yaml文件，并将镜像部署为K8s服务供外部访问。
而从运维团队的角度来看，他们也不用再担心每次应用上线的时候昼夜鏖战的痛苦经历了，因为通过在开发/测试/生产环境中维护同一套满足安全，合规以及开发团队需求的Buildpacks，环境差异已经不再存在，因此在生产环境上线已经没有多少需要手工准备的工作，上线过程已经简化成了几条命令；同时也不用再担心开源软件可能带来的安全漏洞，因为所有的漏洞都会在第一时间在Buildpacks里面被补上！
当然，为了对这个平台有全面的管理，我们也集成了很多K8s的工具来支撑微服务治理，日志，监控，APM，高可用等方面的能力，也是通过自动化配置的方式来减轻运维人员的负担。
您可以通过https://tanzu.vmware.com/application-service来了解更多关于TAS的详细信息。
总结
未来的企业应该需要什么样的工具来使用Kubernetes？从我个人看来，其实答案很简单：这个工具应该使工程师们，不管是开发还是运维，忘记Kubernetes的存在，而不是成为Kubernetes的专家。因为企业的主要目标是自己核心业务的创新，而不是要开发IT基础设施的产品。
过去的Pivotal一直是围绕着这个目标为企业提供产品，今天的VMWare也正在继续为此而努力。不论是开源的Kpack，Cloud Native Buildpacks，还是商业产品TBS和TAS，都已经开始展示出实现这样目标的能力，提供了一条从开源的Kubernetes到现代化的企业云平台的最短实现路径。但是与云原生技术的快速发展同步，这些产品也仍然还是处于快速发展之中，在未来还会有各种各样令人兴奋的新功能加入其中。所以欢迎各位读者对这些产品保持关注，如果愿意试用并提出宝贵意见，我们将不胜感激，并且很愿意与您做深入探讨。
杨海涛
Email: ypaul@vmware.com
WeChat: yanghaitao1979
作者介绍：杨海涛现任VMWare资深云平台架构师，对于应用现代化，云原生平台以及DevOps等领域有深入的理解和丰富的实践经验，目前主要负责VMWare Tanzu产品的解决方案设计，咨询和推广等工作，是Spring认证工程师，Kubernetes认证管理员以及AWS认证架构师。在超过15年的职业经历中，一直专注于软件行业。从事过与软件相关的多种工作，包括：技术研发、项目管理、技术支持、团队管理和系统架构等，据有多个不同行业的大型项目经验。来源：VMware中国
