罗永浩|图文并茂！带你深度解析Kubernetes( 七 ) 罗永浩

Kubernetes抽象出一个Pod对象，是一组（一个或多个）容器，这些容器共享存储、网络等，这些容器是相对紧密的耦合在一起的。 Pod是Kubernetes内创建和管理的最小可调度单元，调度过程是按Pod整体所需资源一起进行调度的。 Pod本身只是逻辑上的概念，在容器管理这层并不认识Pod对象。
Pod的实现需要使用一个中间容器（Infra容器），在这个Pod中， Infra容器永远是第一个被创建的容器，用户定义的其他容器通过Join Network Namespace的方式与Infra容器关联在一起。抽象一个中间容器的原因在于各个业务容器是对等的，其启动没有严格的先后顺序，需借助中间容器实现共享网络和存储的目的。

其中， Node、Pod与容器三者关系，如下图所示。 Node表示一台机器，可调度多个Pod ，而一个Pod内又能包含多个容器。

至此，再来通过Kubernetes中各个对象的关联关系来更为深刻的理解Pod的意义。下图可以看出， Pod其实是整个编排过程中操作的核心，很多对象直接或间接的同Pod相关联。

Service对象

Kubernetes编排抽象的另一个核心对象是Service对象，它统一的解决了集群内服务发现与负载均衡。 Service是对一组提供相同功能的Pod的抽象，为其提供了一个统一的入口。 Service通过标签选择服务后端，匹配标签的Pod IP和端口列表组成endpoints ，由kube-proxy负责将请求负载到相关的endpoints 。
下图是kube-proxy通过iptables模式来实现Service的过程， Service对象有一个虚拟clusterIP ，集群内请求访问clusterIP时，会由iptables规则负载均衡到后端endpoints 。

声明式API

Declarative（声明式设计）指的是一种软件设计理念和编程方式，描述了目标状态，由工具自行判断当前状态并执行相关操作至目标状态。声明式强调What ，目标是什么。而Imperative(命令式)需要用户描述一系列详细指令来达到期望的目标状态。命令式强调How ，具体如何做。
下图描绘了一个场景：目标副本数为3 。对于声明式而言，用户设定目标为3 ，系统获取当前副本数为2 ，系统判定当前值与目标值的差为1 ，便自行加1 ，最终实现副本数为3的目标状态。而对于命令式，需用户判断当前副本数为2 ，用户给出指令副本+1 ，系统接收用户指令，执行副本数+1操作，最终系统副本数为3 。
kubernetes的一大核心设计就是采用了声明式API ，利用该设计思想有效的实现了系统的自动化运行。 Kubernetes声明式API指定了集群期望的运行状态，集群控制器会通过List&Watch机制来获取当前状态，并根据当前状态自动执行相应的操作至目标状态。
Kubernetes中，用户通过提交定义好的API对象来声明期望状态，系统允许有多个API写端，以PATCH方式对API对象进行修改。 Kubectl工具支持三种对象管理方式：命令式命令行、命令式对象配置(yaml)、声明式对象配置(yaml) 。举例如下：命令式命令行：

kubectl run nginx –image nginx

命令式对象配置：

kubectl create –f nginx.yaml
kubectl replace –f nginx.yaml

以上先kubectl create再kubectl replace的操作，与命令式命令行不存在本质区别。只是把具体命令写入yaml配置文件中而已。声明式对象配置：