毋庸置疑，Kubernetes已经渗透到了我们生活的方方面面。最近，VMware的Bryan Liles多次这样形容Kubernetes:
“Kubernetes 不是一款产品...它是一个用于搭建平台的云原生平台”
— Keith Lee
这个表述很有意思，但是什么意思呢？什么叫平台的平台？为什么非Kubernetes不可呢？
我觉得Bryan在文中揭示了五点。您将会发现Kubernetes是个特别棒的平台，它支持的平台即能帮助企业获得经济收益，又能实现加速开发。
Kubernetes具有云原生的组件可以为他人搭建软件系统
我们如今可以自由地定义“平台”，您的平台可能是个数据库平台、分析平台、监控平台、应用平台，或者是一个集成平台——您想要什么样的都有。这里的“平台”代表的是分布式系统本身，由很多可迁移的部分组成，共同实现一定的功能。
如果Kubernetes是一个基础架构平台（我知道它也有应用水平的抽象），您可以在此基础上继续搭建，比如IaaS。那么Kubernetes到底能带来什么好处呢？
各种各样的基础架构API
Kubernetes不仅仅是一个容器调度器，它的接口可接入所有的核心基础架构。也就是说，您可以建立、升级集群，调整集群规模、设置资源配额、配置并管理DNS，供给并管理持久性存储等等。程序上您可以虚拟接入所有部分，并部署、配置、接入分布式系统。对于搭建平台的人来说，这些能力最好都集成在一个API面。
持续的云中立体验
这一点经常被忽略了，但是很重要。得益于容器化，现在我们已经以统一的操作流程在各处虚拟运行工作负载。Kubernetes则更进一步，通过 Amazon EKS、Google’s GKE或Azure的AKS，可以在整个堆栈中持续部署。在您的数据中心或边缘都可以采用VMware PKS。
除了少数例外（比如，捆绑一些具体的云服务），一个Kubernetes集群就是一个Kubernetes集群。当然，各家厂商支持不同的Kubernetes版本，也有不同的管理控制平面，但是它们的API是一致的，Kubernetes的厉害之处就在于这里。所有的平台搭建者都想拥有“打包一次，走遍天下”的体验。
智能的资源利用和工作负载安置
在搭建平台时，您手上可能有一堆组件，都是创建系统所需要的。Kubernetes最擅长的就是将Pods调度至节点上，然后进行一些复杂的配置，为这个Pod找到最好的节点。
如果Kubernetes只在容器中运行，那您在部署时就可以使用几种“类型”的工作负载：初始化容器、短生命周期容器、有状态或无状态工作负载、定时任务、并行任务等等。在搭建平台时，需要运行多种工作负载才能取得规模效率。Kubernetes的优势在于可为架构中不同的构件选择匹配不同类型的资源。
自我修复以及滚动更新支持
理想的情况是平台自动运行。不仅日常运营行没问题，突发问题也能轻松应对。如果能明确目标状态（常常是声明式的），而且系统能保证一直处于该状态，并修复问题，这个理想就会实现。比如说，如果Kubernetes中的Pod崩溃了，另一个就会被自动调用。
存活探针（Liveness probes）和就绪探针（readiness probes）发挥着非常重要的作用。很多集群的运营（例如节点故障）都是人工处理的，如果您使用的是托管的Kubernetes产品，就由这一产品来处理。很多时候，增强的自动化能力来自于OSS (操作支持系统) 项目（和平台）的工具。平台搭建人员应该知道Kubernetes能为他们做什么，以及运营人员要解决什么问题。
在集群内更新容器时，Kubernetes可以滚动升级，方便部署新的组件，而且干扰也被降至最低。
清晰的扩展点
Kubernetes与管理程序的重要区别在于扩展性。客户资源是一种扩展。这些扩大了开箱即用的Kubernetes API，将之作为一级对象。不过，在Kubernetes中其实还有很多扩展点，影响着从kubectl CLI到网络和存储插件的方方面面。
落实运营者规范
这代表着一类Kubernetes扩展，使重复性的部署和工作负载的管理任务可以自动进行。例如，很多产品（比如Kafka的Confluent版本）现在支持Kubernetes运营人员为客户供给实例。对于平台的搭建者来说，如果能够直接简化应用运营那就太好了。当您的平台可以运行定制化的软件和ISV产品时，平台的经济性也不会差。
内置安全功能加强保密信息和策略管理
Kubernetes的安全能力一直在不断改善，目前的水平也很不错。平台的搭建者想要知道如何设置API的验证和授权、获得TLS认证、以命名空间或集群分隔用户、设置Pod的安全上下文和安全策略、配置配额、设置网络策略以及使用内置的保密信息管理。在Kubernetes之上部署平台时，您应该采用这些声明式的或配置好的设置。
在购买“Kubernetes原生”软件时您应该检查的事情
如果有人说某物是“适用于Kubernetes”的，一定要确认它使用的是Kubernetes原生的对象或者已知的扩展点。如果有人仅在Kubernetes上运行他们的软件，却没有利用Kubernetes的优势，那就要特别警惕。
只要看看开发文档很快就会发现这些，MongoDB和它的操作器在这方面就很出色。Greenplum也有一个原生操作器。Confluent也已经做到了上述一点。Knative以及riff也采用并扩展了核心Kubernetes类型，从此将无服务器概念引入了Kubernetes。再看kpack，它利用Kubernetes资源类型将代码打包进容器，然后在Kubernetes上运行。多带劲儿!
深入了解一下，看看你的软件供应商在客户资源、滚动部署、基础架构中立API以及pod故障处理等方面是否符合标准。
这意味着无论您愿不愿意都要采用Kubernetes了
还是不想运行Kubernetes？那您也不必有压力。不过，您可能还是绕不开它。
越来越多的软件厂商把它的产品打包成容器，或者是一套容器。他们相当喜欢以某种形式捆绑多个平台再销售给客户。您要决定是人工运行这些容器还是利用类似Kubernetes的平台使容器管理运营化。
我觉得VMware的“太平洋计划”(Project Pacific)很了不起。从这个vSphere的再生架构中您将收获原生Kubernetes管理和虚拟机，采用与您的团队同样的工具来供给和管理基础架构。
即使您并没有以原生的状态创建或部署容器化的工作负载，您恐怕也要运行它们。请开始自学课程，逐步熟悉，然后进入下一个VMworld。
这意味着您需要对Kubernetes平台负责
Kubernetes很强大，也相当复杂。这没什么办法。如果您想利用托管的云产品“运行”Kubernetes，劝您还是算了。
“Kubernetes是条艰难的道路”这句话好假，说的好像还有容易的道路似的。
— Czarkuberneteski
使用了Google或Microsoft的托管产品也仍然需要您照顾Kubernetes。当然，您不必部署Node，但常规的生命周期运营和配置还是不可少。您要负责的包括升级（和顺利的测试）、高可用性规划和各种平台生命周期任务。本来这些都不过分，毕竟“云”应该意味着什么都不需要我们来操心。
这意味着很多类型的工作负载的目标API不是Kubernetes
Kubernetes并不适用于所有的工作负载。API水平过低。我的同事Craig McLuckie就指出，Kubernetes会变得越来越隐形。
如果我们把工作做好了，五年之后，人们就不会再关注Kubernetes了。不是因为它自己溜了，而是它常态化了，被新的创新成果所掩盖。
— Craig McLuckie
Microsoft交付Azure Spring Cloud，Pivotal 交付适用于Kubernetes的Pivotal Application Service，Google交付由Knative 驱动的Cloud Run，为什么这些公司好像都突然进军这一领域？因为我们都意识到了Kubernetes是非常出色的基础架构，它仍需要开发的流程。它需要一个容器搭建系统、一个应用部署API、一个交易场所、聚焦应用的管理命令，也就是一个凌驾于基础架构之上的应用平台。
所以，应该采用Kubernetes，运行起来，也要明白这是一个运行其它平台的平台，它将提升您的软件交付能力和业务成果。
关于作者：
Richard Seroter
Pivotal产品营销副总监
Richard Seroter是Pivotal产品营销副总裁，微软12个月的云MVP，以开发人员为中心的培训公司Pluralsight的讲师，InfoQ.com云计算的首席编辑，以及多本有关应用程序集成策略的书的作者。作为Pivotal产品营销副总裁，Richard领导产品，合作伙伴，客户和技术营销，并帮助客户了解如何改变其构建软件的方式。
