kubernetes(2) kubernetes基础概念

kubernetes的资源类型概述

k8s是一个容器编排系统，它的编排对象为Pod。Pod本质上是k8s API支持众多抽象资源类型中的一种。而资源类型可实例化为一个对象。此处和对象式的编程语言可以作对比：对象式的编程语言，以数据为中心，代码服务于数据，其核心任务是通过定义class，以描述一类事物的属性和此类事物支持的方法。方法限制了一类事物之上的操作接口，而属性描述了事物的特征。

而在kubernetes中，数据是对象，代码是方法。k8s的API是RESTful(表征状态转移) 风格的API。它的主要目标在于，通过API把可被操作的事物抽象为类别，在k8s上称之为资源。资源是只支持某些属性和操作方法的一类事物，给它们赋值后，就是实例化的过程，就可以创建出对象object。

k8s中资源支持的方法，并不可以随意定义。它依托于http/https协议进行传输，因此它支持的方法为http/https协议支持的通用方法，比如GET,PUT,POST,DELETE,PATCH…

因此所有对象支持的方法都相似，只有增删改查。在某种程度而言，对于对象的操作，类似对于数据库的操作。

除了Pod这种资源类型，k8s还支持Service，Namesapce和Volume等资源类型。它们是最基础的k8s资源对象。在它们之上还有更为高级，用于管理基础对象的资源类型。比如控制器对象如ReplicaSet，Deployment，DaemonSet，StatefulSet，Job和CronJob。

可以看到它们的首字母大写，这也符合对象式编程语言中，对类定义的书写习惯。

kubernetes的pod访问逻辑概述

k8s的核心任务是容器编排，而容器实际上就是应用程序。k8s建构在多节点之上，它隐藏了底层节点并以更加抽象的方式对外输出用户可统一使用的操作接口，可以对Pod(容器)进行增删改查。而运行Pod的目的，在于运行容器。

比如运行一个nginx容器，必然占据CPU和内存等资源，并监听套接字以对外通信。如果Pod故障而崩溃，容器编排系统必须具备健康状态检测的功能，一旦检测到Pod发生故障则自动恢复出一个健康的Pod。这种功能的支持由Pod控制器来实现。

最基础的Pod控制器为deployment，它属于资源类型之一。通过Deployment资源类型创建出deployment控制器，由deployment控制器指挥k8s创建出一个或多个pod，pod数量取决于用户定义。控制器会精确控制pod的数量，集群上运行的pod数量必须精确符合用户指定的数量。如果pod提供服务，其内部的服务如何被客户端所访问？因为pod重建后，IP地址会发生变化，IP地址是动态分配的以避免冲突，因此pod崩溃并重建后，客户端如何得知访问的新IP地址？

动态逻辑为了实现客户端和服务交互，而pod的建立和销毁是动态的，故而必须借助服务注册和服务发现以实现客户端和服务端的衔接。

因此，k8s添加了service这个中间层，用于提供客户端访问服务的固定端点。客户端访问pod时，实际访问的是service，它也是资源类型之一。而后service把用户请求反向代理到Pod之上。如果有多个Pod，还能实现负载均衡的效果，因此service可理解为Pod的代理。

kubernetes的三种网络概述

Service创建后，称为serviceIP或clusterIP。后端pod IP地址为pod IP，Pod IP配置在虚拟网卡上。如此客户端直接访问调度器的IP地址，每个service就好像反代并拥有调度功能，类似nginx的方式。

而service和后端Pod之间，通过label selector，实现label关联。k8s为每个资源对象附加标签，因此可基于标签来引用各资源。标签选择器可以过滤符合条件的标签，即使重建pod，其标签也是不变的。一旦过滤后，就可关联到service上。

service只要不手动去改变，地址就不会变化。它实际上是iptables/ipvs规则，它们都可实现调度功能，而后者实现的功能更为强大。因此clusterIP并不存在任何接口之上。

假如service发生变化，也会导致客户端无法访问。因此，需要服务发现，在k8s上通过动态DNS实现。当用户创建service时，service一定会有名称和IP地址，此时DNS会动态注册一条A记录。只要访问名称，即可定向到serviceIP。即使service重建导致IP改变，只要通过DNS解析即可正常访问到新的serviceIP。

此处的DNS称为服务组件，用于保存service和IP地址的对应关系。要发现服务时，只需发现服务名称即可。

k8s的第三个IP，为nodeIP。它配置在节点的网卡上

传统架构中，如果部署一个nmt，nginx的客户端为外部互联网客户端，tomcat的客户端为nginx，mysql的客户端为tomcat上的程序。而在k8s架构时，访问逻辑将发生变化：external client -> service-nginx -> nginx -> service-tomcat -> tomcat -> service-mysql -> mysql

运维人员的三大职能：发布，变更和故障处理。

而在k8s中，运维发布时，通过控制器创建Pod；运维变更，比如扩容和缩容也通过控制器；故障处理，比如Pod宕机也由控制器处理。此时，本来由运维人员处理的，现在由控制器处理。因此可理解为，控制器就是封装运维人员对应用程序运维的操作规程。

对于无状态的应用而言，上述的处理逻辑非常容易实现。但对于有状态的应用程序，情况就变得十分困难，因此需要operator来处理。如果k8s把IT信息系统的运维管理，封装成用户可定制的程序化框架。而控制器，就是以往运维工程师的职能所在。

总结：k8s网络存在三种形式的网络：service网络，pod网络，node网络

k8s要求，pod网络可直接跨主机通信，而无需像docker般通过两次nat转换。但实际应用时，pod1 -> pod2 service -> pod2，这种访问逻辑会经过中间层。但service实际上是迭代的效果，而非递归。它增加了中间查询的过程，而不是nat。因此，实际上pod1访问serivce，service会把pod2的IP回馈给pod1，然后pod1直接访问pod2.