VMware虚拟化与Kubernetes（K8s）的对比

　　概述
　　容器技术是最近几年非常热门的技术，它似乎就是为云端的应用量身定制的，所以它也被贴上了云原生应用（CloudNativeApplication）技术的标签。目前最为流行的容器管理调度平台是Kubernetes（缩写为K8s），是Google为支持大批量容器而开发的企业级运行平台，可以支持负载均衡、高可靠等生产级功能。VMware在VMworld2017上也宣布了跟Pivotal、Google合作开发的VMwarePivotalContainerService，这是一个商用的K8s平台，简称PKS（中间的K代表Kubernetes）。
　　现在专门为VMware用户写了这篇文章，利用你所熟悉的vSphere平台来跟K8s作一个类比，从而帮助你快速了解K8s。
　　vSphere平台和Kubernetes的总体对比
　　那么到底什么是Kubernetes呢？简单来说，K8s和容器的关系就相当于vSphere和虚机的关系。在VMware发展早期的时候，那时候只有VMwareWorkstation，后来出现了基于vCenter和ESXi的VIvSphere体系架构，从而使虚拟化步入了数据中心。同样的，容器一开始的时候只有一个简单的容器引擎Docker，K8s的出现为容器提供了一个生产级的运行环境。把vSphere和K8s平台肩并肩放在一起比较的话，你会发现它们的概念有很多类似之处，这可以帮助我们很快地理解K8s技术的各种细节。
　　系统架构
　　就像vSphere平台上的vCenter和ESXi主机，K8s平台上也有对应的概念：Master和节点（node），Master起到的作用就跟vCenter一样，对整个K8s集群进行管理，它也是工作负载管理API的访问入口。跟ESXi主机对应的就是K8s节点，节点是K8s集群中的计算资源，容器就是运行在节点上，节点可以是虚机或者物理服务器。K8s也有一个类似于vCenterDB的数据库etcd，它以的键值方式存储了整个集群的配置和状态。
　　跟vSphere不同的是，K8sMaster上也能运行容器负载，当然vCenterServer上是不运行虚机的。虽然K8sMaster也是一种计算资源，但是一般只在上面运行系统管理相关的容器应用，普通的应用负载不应该放在Master上。
　　vSphere有GUI管理界面WebClient和命令行管理接口vCLI和PowerCLI，K8s也提供了GUI界面或命令行来管理K8s集群。下面截屏是使用命令kubectl。exe来管理K8s集群的例子，我们可以看到这个集群有一个Master（vkubemaster007）和4个节点（vkubemode01718），K8s的版本是v1。6。5，节点上的操作系统是Ubuntu16。04。
　　工作负载
　　vSphere中的工作负载调度单位是虚机，K8s中的调度单位是Pod；一台ESXi主机上可以运行多个虚机，一个K8s节点上也可以运行多个Pod，每个Pod都有一个独立的IP地址来跟其他的Pod相通讯。在vSphere环境中，应用运行在虚机的操作系统中，K8s平台上应用运行在容器里；一个虚机中只能运行一个操作系统实例，而一个Pod中可以运行多个容器实例。K8s会考虑到Pod的关联性而把Pod中的容器实例运行在同一个节点上，从而让他们共享同一个运行环境；一般是把一个应用和它相关的辅助模块设计在同一个Pod中，然后作为一个整体来进行调度运行。
　　系统管理
　　我们使用WebClient来管理vSphere集群，K8s也有一个图形化的管理界面Dashboard，同WebClient一样，这也是一个基于Web的应用。Dashboard的功能也变得越来越强大，它可以实现大部分的K8s集群管理功能，而不用输入很长的kubectl命令。
　　系统配置
　　K8s可以通过一个YAML（YetAnotherMarkupLanguage）文件来定义和描述K8s集群的配置和状态，然后就可以基于该文件创建整个K8s集群，K8s会尽力地保持集群运行在指定的状态。例如，如果你指定了某一个Pod要有4个副本，K8s就会监控所有这些Pod的运行，如果有任何一个Pod工作异常的话，它就会设法修复这个状态，实在不行的话就另启一个Pod副本。
　　要理解YAML配置文件的话，你可以把它对应为虚机的。VMX文件，或是VirtualAppliance的。OVF文件。当然，YAML配置文件在K8s中不仅用于定义集群，也用于定义其他的组件，如：副本集合、服务、部署等。
　　虚拟集群
　　vSphere中为了管理资源的分配专门有一个资源池（ResourcePool）的概念，就像是在物理集群中划分出了一些小的虚拟集群，vSphere利用资源池来控制资源的分配。K8s也有类似的概念叫namespaces，namespace的主要用途是创建多租户环境，也可以在上面指定资源配额（ResourceQuota）。
　　资源管理
　　vSphere需要指定每一个ResourcePool的资源分配限额，K8s可以在namespace上设置资源配额（ResourceQuotas）来控制资源分配，这是在YAML配置文件中定义的。
　　工作负载标记
　　这在vSphere和K8s中几乎是完全一致的，vSphere使用tag标签来标识虚机，而K8s使用标签（label）来标识容器。所不同的是，K8s中标签是必须的，而不是可选的。
　　计算冗余
　　vSphere中有FaultTolerance技术来提供计算资源的冗余，受保护的虚机运行在一台服务器上，另一台服务器上有一个从被保护虚机复制而来的影子（Shadow），FT技术通过Lockstep来同步主虚机和影子虚机之间的数据和状态。正常情况下影子虚机是不工作的，当主服务器宕机时，影子虚机立刻被激活成主虚机，并继续主虚机工作；这时vSphere会设法在集群中找到另一台合适的服务器，在上面从新的主虚机复制出新的影子虚机，以继续对主虚机进行保护。
　　K8s中也有相应的资源冗余机制，ReplicaSets用于指定一个Pod需要运行的实例数量，K8s会自动维持实例的数量，任何一个实例由于故障原因宕掉了，K8s马上会自动启动一个新的实例补上。当然两者基本的工作原理是不一样的，K8s中的所有实例正常情况都是在工作的，在多个实例间均衡工作负载，而不存在主备的概念，这是由云原生应用的本质所决定的。
　　负载均衡
　　vSphere并不内置有负载均衡功能，一般是通过虚拟的（如NSX）或物理的（如F5）负载均衡器来把服务请求平均分配给多台虚机。负载均衡也有多种配置模式，以单肩模式（onearmed）为例，我们把网络流量东西向地均衡分配给虚机。
　　K8s中也有类似的概念Service，是一组一起协作的Pod，每个Pod都被定义了一个标签选择器（labelselector）。K8sService也有多种配置模式，例如ClusterIP模式，每个Service都被分配了一个外部可见的静态IP地址和DNS域名以便于被访问到，负载流量以轮循（roundrobin）的方式分配给每一个Pod。其他的模式如NodePort，以不同端口访问节点的流量会被映射到不同的Pod；当然也可以配成LoadBalancer模式来使用外部的负载均衡器。
　　K8s还有另外一种非常重要的负载均衡机制IngressController，一个ingresscontroller以Pod的形式存在，并且分配有一个外部可见的IP地址，该IP地址对应着一个含有通配符的DNS记录，ingresscontroller根据预先设定的规则来把流量分配给不同的Pod。例如下图中的IP地址192。168。100。244对应DNS域名sphinxv。esxcloud。net，访问sphinxv1。esxcloud。net的流量会被重定向给sphinxsvc1，而访问sphinxv2。esxcloud。net的流量被重定向给sphinxsvc2。