Node、Pod、Replica Controller、Service等可以看作一种资源对象，资源对象可以通过kubectl工具执行增、删、改、查等操作将其保存在etcd中持久化存储。k8s通过跟踪对比etcd库里保存的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错。

1.master

master节点负责整个集群的管理和控制，基本上k8s的所有控制命令都发给它，负责具体的执行过程，执行的所有命令基本都是在master节点上运行的。master节点上需要启动一个etcd服务，因为k8s里所有资源对象的数据保存在etcd中。

master几点运行的关键进程：

Kubernetes API Server(kube-apiserver):所有资源增删改查等操作的入口

Kubernetes Controller Manager(kube-controller-manager):资源对象的自动控制中心

Kubernetes Scheduler(kube-scheduler):负责Pod调度的进程

2.node

Node节点可以是一台物理主机或者虚拟机，当某个Node宕机时，会被Master自动转移到其他节点上去。Node节点在运行期间可以动态的增加到k8s集群中，前提是节点已经安装和配置了关键进程。在默认情况下kbuelet会向Master注册自己，并定时汇报自身情况。

node节点的关键进程：

kubelet:负责Pod对应的容器的创建、启停等任务，与master协作，实现集群管理基本功能。

kube-proxy:实现Kubernetes Service的通信与负载机制的重要组件。

docker:负责本机的容器创建和管理工作。

3.Pod

每一个Pod都有一个Pause根容器，Pause容器对应的镜像属于Kubernetes平台的一部分

Pod有普通的Pod和静态Pod，静态Pod存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动运行。普通的Pod一旦被创建，就会放到etcd中存储，随后会被Kubernetes Master调度到某个具体的Node上并进行绑定，随后该Pod被对应的Node上的kubeket进程实例化成一组相关的Docker容器并启动起来。默认情况下，当Pod里的某个容器停止时，Kubernetes会自动检测，并重新启动这个Pod，重启Pod里面的所有容器。

在Pod的yaml文件中，metadata.name为Pod的名字，matadata.labels.name为标签；spec定义了容器和对应的镜像，spec.containers.ports是在containerPort上启动容器。Pod的IP和containerPort组成了Endpoint，代表着此Pod里的一个服务进程对外的通信地址。Pod还可以设置资源限制。

4.Label

Label可以附加到各种资源对象上去，如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，可以通过给指定的资源对象捆绑一个或者多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便地进行资源分配、调度等管理工作。

给某个资源对象定义一个Label，就相当于给它打了一个标签，随后可以通过Label Selector来查询和筛选拥有某些Label的资源对象，新出现的资源管理对象如Deployment、ReplicaSet、DaemonSet和Job则可以在Selector中使用基于集合的筛选条件定义。

Label Selector在Kubernetes中的重要使用场景：

--kube-controller进程通过资源对象RC上定义的Label Selector来筛选要监控的Pod副本的数量，从而实现Pod副本的数量始终符合预期设定的全自动控制流程。

--kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立起每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制。

--通过对某些Node定义特定的Label，并且在Pod定义文件中使用NodeSelector这种标签调度策略,kube-scheduler进程可以实现Pod“定向调度”的特性。

使用Label可以给对象创建多组标签，通过Label和Label Selector使得被管理对象能够被精细地分组管理，实现整个集群的高可用性。

5.Replication Controller

定义了某种Pod的副本数量和预期值，RC定义的几个部分：

--Pod期待的副本数（replicas）

--用于筛选目标Pod的Label Selector

--创建新的Pod的模板（template）

6.Deployment

是为了解决Pod编排问题，可以看作RC的一次升级，Replica Set与Deployment可以实现Pod的自动扩容和伸缩。

7.Service

service其实就是微服务，每个Pod都会被分配一个单独的IP地址，每个Pod都提供了一个独立的Endpoint被客户端访问，多个Pod副本组成了一个集群来提供服务，负载均衡器为这组Pod开启一个对外的服务端口，并且将这些Pod的Endpoint列表加入端口的转发列表中，客户端通过负载均衡器的对外IP地址+服务端口来访问此服务。客户端的请求转发到那个Pod上，由负载均衡器（如kube-proxy）来决定，把对Service的请求转发到后端的Pod上

Pod容易发生改变，Service一旦被创建，就会分配一个可用的ClusterIP，在Service整个生命周期内不会发生改变，使用dns服务发现机制。

外部系统访问Service的问题：

--Node IP：真是存在的IP，Kubernetes集群之外的节点访问Kubernetes集群之内的节点时，必须通过NodeIP进行通信。

--Pod IP：位于不同Node上的Pod能够彼此直接通信，所以Kubernetes里一个Pod里的容器访问另外一个Pod里面的容器是通过PodIP，真是流量通过NodeIP。

--Cluster IP：Service的ClusterIP是Kubernetes内部的地址，无法外部使用。实际会有一部分服务提供给集群外部的应用或者用户使用，使用Web端的服务模块，在ports.nodePort定义端口号，使用nginx可以解决Kubernetes集群中node的负载均衡。

8.Namespace

用于实现多租户的资源隔离，Namespace通过将集群内部的资源对象“分配”到不同的Namespace中，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。如果不特别指明Namespace，用户创建的RC，Pod，Service都将被系统创建到默认的名为default的Namespace中。先用yaml文件定义Namespace，metadata.name；在创建资源对象时指定，metadata.namespace。

9.关系图