kubernetes|图文并茂！带你深度解析Kubernetes( 六 ) docker|操作系统|Google

其中， 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配置文件中而已。声明式对象配置：

kubectl apply –f nginx.yaml

Kubernetes推荐使用：声明式对象配置(YAML) 。 kubectl replace执行过程是通过新的YAML文件中的API对象来替换原有的API对象，而Kubectl apply执行了一个对原有API对象的PATCH操作。除此之外， YAML配置文件用于Kubernetes对象的定义，还会有以下收益：

便捷性：不必添加大量的参数到命令行中执行命令。

灵活性：YAML可以创建比命令行更加复杂的结构。

可维护性：YAML文件可以通过源头控制，跟踪每次操作；并且对象配置可以存储在源控制系统中（比如Git）；对象配置同时也提供了用于创建对象的模板。

开放插件

Kubernetes的设计初衷就是支持可插拔的架构，解决PaaS平台使用不方便、不易扩展等问题。为了便于系统的扩展， Kubernetes中开放了以下接口可对系统资源（计算、网络、存储）插件进行扩展，可分别对接不同的后端来实现自己的业务逻辑。
CRI（Container Runtime Interface）：容器运行时接口，提供计算资源。 CRI接口设计的一个重要原则是只关注接口本身，而不关心具体实现， kubelet就只需要跟这个接口打交道。而作为具体的容器项目，比如Docker、rkt、containerd、kata container它们就只需要自己提供一个该接口的实现，然后对kubelet暴露出gRPC服务即可。简单来说， CRI主要作用就是实现了kubelet和容器运行时之间的解耦。

CNI（Container Network Interface）：容器网络接口，提供网络资源。跨主机容器间的网络互通已经成为基本要求， K8S网络模型要求所有容器都可以直接使用IP地址与其他容器通信，而无需使用NAT；所有宿主机都可以直接使用IP地址与所有容器通信，而无需使用NAT 。反之亦然。容器自己的IP地址，和别人（宿主机或者容器）看到的地址是完全一样的。 K8S提供了一个插件规范，称为容器网络接口(CNI) ，只要满足K8S的基本需求，第三方厂商可以随意使用自己的网络栈，通过使用overlay网络来支持多子网或者一些个性化使用场景，所以出现很多优秀的CNI插件被添加到Kubernetes集群中。