一、概念

Kubernetes是一个高度自动化的资源控制系统，以“一切以服务为中心”作为指导思想，也就是Service，那么由谁来提供Service

呢？由Pod对象，又通过Label标签来为Service和Pod建立关联；Pod运行在Node上，那么Pod又是怎么产生的呢？可以直接定

义创建，也可由RC（Replication Controller）文件创建。

1.1.官方架构图

非官方架构图

二、Master

是集群控制节点，每个K8S集群中都需要一个Master节点来负责整个集群的管理和控制，它是整个集群的“首脑”，运行着三个关键进程：

1.kube-apiserver

• 提供API，是所有资源增、删、改、查等操作的唯一入口,也是集群控制的入口进程，并把所有操作处理信息存储到etcd中
• 从 etcd 读取（ListWatch）全量数据，并缓存在内存中，绝大部分情况下，apiserver 直接从本地缓存对外提供服务，避免客户端直接请求到etcd；无状态服务，可水平扩展；
• 从最简形式上来说，apiserver 就是挡在 etcd 前面的一个代理（proxy）
  

2.kube-controller-manager

所有资源对象的自动化控制中心，好比资源对象的“大总管”；
处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager就是负责管理这些控制器的。

3.kube-scheduler

负责资源调度（Pod）的进程，相当于公交公司的“调度室”；

在整个系统中起到“承上启下”的作用，“承上”是指负责接受Controller Manager创建的新Pod，为其调度到Node节点；
“启下”是指调度完成后，目标Node上的kubelet接管后续工作，负责Pod接下来的生命周期。

在整个调度过程中，涉及三个对象：待调度Pod列表、可用Node节点、以及调度算法和策略

scheduler通过调度算法为待调度Pod列表中的每个Pod从Node列表中选择一个最合适的Node来实现Pod调度。

调度决策需要考虑的因素包括

Pod 对硬件/软件资源的请求？节点是否报告内存或磁盘压力情况？
该节点是否具有与 pod 规范中的节点选择器匹配的标签？
如果 pod 请求绑定到特定的主机端口，该端口是否已在该节点上占用？
pod 是否容忍节点的污点？
pod 是否指定节点亲和性或反亲和性规则等。

etcd

持久化 KV 存储，集群资源（pods/services/networkpolicies/…）的唯一的权威数据（状态）源；

三、Node

除了Master，K8S集群中的其他机器被称为Node节点，它是集群中的工作负载节点，是真正干活的。它有以下一组关键进程:

1.kubelet

kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，如创建/删除容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。

每个kubelet都会在API Server上注册节点自身的信息，定期向Master汇报节点资源的情况，并通过CAdvisor监控容器和节点资源。

2.kube-proxy

监听apiserver中的service和endpoint的变化，创建路由规则来提供服务IP和负载均衡功能。

是Service的透明代理兼负载均衡器，其核心功能是将某个Service的访问请求转发到后端的多个Pod实例中

3.Docker Engine

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

四、Pod

Pod是管理，创建，计划的最小单元。
每个Pod都有一个特殊的“根容器”Pause容器，Pod里的多个业务容器共享Pause容器的IP和Volume，简化了业务容器之间的通信问题和文件共享问题。

Kubernetes为每个Pod分配了唯一的IP地址，称之为Pod IP；采用虚拟二层网络技术Flannel、Openvswitch实现任意两个Pod之间的TCP/IP直接通信。

Pod里的服务进程通过Endpoint（PodIP+containerPort）对外提供服务。

Pod可以对其能使用的服务器上的计算资源设置限额。以千分之一的CPU配额为最小单元，用m表示。通常一个容器的CPU配额100~300m，即占用0.1～0.3个CPU。CPU配额是一个绝对值，跟服务器CPU的个数无关。
内存的配额也是绝对值，用Mi表示。

Pod有两种类型：

1.普通Pod

一旦创建，被放入到etcd中存储，随后被调度到某个具体的Node上进行绑定，并被kubelet进程实例化成一组相关的Docker容器并启动起来。当Pod中的某个容器停止时，K8s会自动检测到这个问题并且重新启动这个Pod（重启Pod里的所有容器），如果Pod所在的Node宕机，则会将这个Node上的所有Pod重新调度到其他节点上。

2.静态Pod

不存放在K8s的etcd存储里，而是存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动运行。

五、Label

一对 key/value ，被关联到对象上，比如Pod。标签可以用来划分特定组的对象（比如，所有女的），标签可以在创建一个对象的时候直接给与，也可以在后期随时修改，每一个对象可以拥有多个标签，但是，key值必须是唯一的。

5.1. Label selector的使用场景

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

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

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

5.2. 示例

selector:
  matchLabels:
    app: myweb
  matchExpressions:
    - {key: tier, operator: In, values: [frontend]}

六、RC(Replication Controller)

Replication Controller 保证了在所有时间内，都有特定数量的Pod副本正在运行，如果太多了，Replication Controller就杀死几个，如果太少了，Replication Controller会新建几个，和直接创建的pod不同的是，Replication Controller会替换掉那些删除的或者被终止的pod。

只创建一个pod，也要使用Replication Controller。Replication Controller 就像一个进程管理器，监管着不同node上的多个pod,而不是单单监控一个node上的pod。

七、Deployment

为Pod和ReplicaSet提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController来方便的管理应用。相对于RC的一个最大升级是可以随时知道当前Pod“部署”的进度

八、Service

K8S中的Service就是我们经常提起的微服务架构中的一个“微服务”。
K8S为每个Service都分配一个全局唯一的虚拟IP—Cluster IP，并通过DNS做了一个Name与Service的域名映射。

1.三个IP

a. Node IP

Node节点的IP地址。是物理网卡的IP地址，是一个真实存在的物理网络。

b. Pod IP

它是Docker Engine根据docker0网桥的IP地址段进行分配的，不同Node里面的Pod通过虚拟二层网络进行互相通信。

c. Cluster IP

通过NodePort的方式来访问Service

九、Volume

是Pod中能够被多个容器访问的共享目录。
Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume中的数据也不丢失。

十、Namespace

1.命名空间在很多情况下用于实现多租户的资源隔离。
K8S集群在启动后会创建一个名为“default”的NameSpace。

2.权限控制

十一、Annotation

与Label类似，但没有Label那样严格的命名规则，是用户任意定义的“附加”信息，以便于外部工具进行查找。