云原生：详解｜K8s核心对象技术解析

云世 公众号

续前篇：详解｜K8s核心技术栈解析

K8s与虚拟机部署的区别、高可用部署的命令、对象如何定义、对象分组原则、Pod、service、deployment等核心对象工作流程、架构、原理解析

K8s应用的好处

假设你是一个开发人员，写了一个web服务器，想把它发布出去。在虚拟机世界里面，这是很困难的：

首先要去建这些虚拟机，要有一个provision的过程：需要去设定什么样的操作系统，要多少CPU，多少memory，然后要想办法把你的应用程序，包括它所依赖的中间件，（比如你的应用是Java程序，就需要想办法把Tom cat装上去，要把你的war包放在固定的目录，需要去重启Tom cat，让你的应用起起来）。

对于一两个节点，这个手工操作ok，但是当面对成千上万甚至几十万的实例的时候，这个操作几乎就不可能，就失去人为去管理整个平台的能力了，成本和出错的几率会非常大。

那么在容器世界里怎么做呢？

在前面一篇：容器核心技术解析 中讲过：

1. 首先可以通过go build把源代码编译成一个可执行的文件，

2. 然后通过 docker build，把编译好的文件放到容器镜像里面，

3. 接下来在定义容器镜像启动的时候，定义它执行哪条命令，把所有编译的任务都放到了这个文件里面。

这个文件有几个目标：

1. 把源代码编译成可执行文件，

2. 通过docker build把可执行文件塞到一个容器镜像里面去，

3. 通过docker push把这个容器镜像推到镜像仓库。默认的镜像仓库是docker hub。

作为应用开发人员，通过以上操作就把应用打包好，并且上传到镜像仓库了。要去做部署的时候，就去另外一个环境，用镜像把它部署出来。

K8s的部署跟虚拟机不一样

回顾前面讲的K8s的核心对象：Namespace、Pod、Node等。

这些核心对象及相互之间在K8s是如何运作的，有哪些通用属性呢？

以及这些核心对象间世怎么联动的？

其中Pod就是用来起镜像的容器实例的。

先定义一个K8s对象，deployment，它是用来干嘛的？它跟Pod之间有什么关系？

举个例子：deployment其中有个属性叫replica，如果它=3，就是有3个实例。（设定多个实例的原因是要做应用的高可用，做冗余部署）。每个实例分别提供了IP。思考对于冗余部署的服务来说，要提供一个服务出去，能把这三个IP都给出去吗？

当多实例部署的时候，把每个实例的IP都给出去，是有问题的。因为把IP list给出去，要依赖客户端来决定连哪个。客户端盯着一个，只把request发给其中一个IP，而背后有三个实例，它的负载是不均衡的。当请求很大的时候，会出现所有request都连到一个实例上去，这个实例就可能没法响应了，但是其他的实例又都是空闲的。

所以为了保证应用高可用率，要有负载负载均衡。

K8s提供了一个对象叫做service，预先定义好了service，叫做Nginx service，是为服务配负载均衡规则的。service有plus IP作为这个服务的虚IP，VIP（virtual IP）。访问虚IP就会把请求转到后面的三个Pod。每次访问的时候，它连的backend就已经做了负载均衡。这种情况下，服务就有了高可用的能力。

如果把其中一个Pod删掉，再通过访问VIP，用户的访问是不受影响的，它把请求指向了其他两个Pod中的一个，保证了出现故障时的应用高可用。

在K8s中，应用高可用部署可以简化到敲三个命令完成：

1. 第一条命令：create -f +文件，创建了一个对象deployment

   通过建deployment，达到的目标是把应用部署到K8s平台上。

2. 第二条命令：scale，把建好的对象里面其中一个副本数的属性进行扩展到n，获得的结果是同时起了n个Pod。

3. 第三条命令，集群里面有service，提供虚IP，访问虚ip，就把所有的请求转到backend的Pod里面去，就完成了应用的高可用部署。

K8s的对象是如何设计的

K8s之所以厉害，成为业界云计算的统一标准、事实标准，是因为它是一个声明式系统。

通过声明式系统，也就是它的架构原则，把所有要管控的对象都用统一的方法抽象成了一个个对象。

K8s的统一属性

第一部分是Typemeta

里面又有TypeMeta，用来声明这个对象的类型。

Type meta里面有三个重要的属性，第一个属性是叫做group，第二个属性叫kind，第三个属性叫version。我们常说的GKV。

1，K8s有很多很多的对象，会按照不同的业务目的，把这些对象放到不同的group里面去，所以可以把group就认为它是 Java里面的package。

2，Kind代表这个对象是什么。映射到Java里面的class。

3，第三个是version， K8s里面任何对象都有一个version，而且很多对象在中间态的时候会有不同的多种版本同时存在。

比如装了某一个K8s版本，你用不同的版本都能get出来， version干嘛用的呢？社区在不断的迭代过程中，不断的设计和演化出来。K8s在每年有4个版本，基本上每个季度一次，它是按照既定的周期去发新版本的。（后面一年会调整为三个版本，因为release太多，整个业界都要跟着他走，都跟得很累）

我们讲究敏捷，讲究迭代，任何社区的API定义，对象的定义，并不是一定义出来就是一个final版本了，社区会follow一定的原则做版本的演进。从alpha，到beta，然后再上生产。

跟做系统类似，开始先做poc，一个最初的版本，然后随着需求不断增加，把功能部署出去，不停的使用，会觉得有一个设计是不合理的，要做一些调整。所以K8s在做演进的时候，非生产版本的变化是不保证的。

处在版本升级，迁移中，如果用的是alpha功能或beta功能，可能它的属性会发生变化，那么怎么减少迁