目录

1.K8S相关概念

Cluster

Master

Node

Pod

Controller Manager

Service

NameSpace

2.K8S架构和集群规划

K8S架构

K8S架构拆解图

K8S Master节点

K8S Node节点

K8S中Pod的创建流程

---

1.K8S相关概念

• Cluster

Cluster由多台虚拟机或者物理设备组成，是计算、存储和网络等资源的集合，K8S利用这些资源运行各种基于容器的应用。

• Master

Master是Cluster集群的大脑，它的主要职责是调度、即决定将应用放在哪个节点运行。Master 运行 Linux 操作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个 Master。

• Node

Node是用于运行容器应用的节点。Node由Master管理，Node主要负责监控并汇报容器的状态，并根据Master的要求管理容器的生命周期。Node运行在Linux操作系统上，可以是物理机或者虚拟机。

• Pod

Pod是K8S的最小工作单元。每个Pod可以包含一个或者多个有紧密联系的容器应用。Pod中的容器回作为一个整体被Master调度到一个Node上运行。（Pod如何创建？通过Master上的Controller Manager）

---

K8S引入Pod主要基于下面两个目的：

1. 可管理性。
   有些容器天生就是需要紧密联系，一起工作。Pod 提供了比容器更高层次的抽象，将它们封装到一个部署单元中。Kubernetes 以 Pod 为最小单位进行调度、扩展、共享资源、管理生命周期。

2. 通信和资源共享。
   Pod 中的所有容器使用同一个网络 namespace，即相同的 IP 地址和 Port 空间。它们可以直接用 localhost 通信。同样的，这些容器可以共享存储，当 Kubernetes 挂载 volume 到 Pod，本质上是将 volume 挂载到 Pod 中的每一个容器。

Pods的使用方式：

1. 运行单一容器。
   one-container-per-Pod 是 Kubernetes 最常见的模型，这种情况下，只是将单个容器简单封装成 Pod。即便是只有一个容器，Kubernetes 管理的也是 Pod 而不是直接管理容器。

2. 运行多个容器。
   但问题在于：哪些容器应该放到一个 Pod 中？ 
   答案是：这些容器联系必须 非常紧密，而且需要 直接共享资源。

---

Example：

下图的Pod包含两个容器：一个File Puller，一个是Web Server。

    

File Puller 会定期从外部的 Content Manager 中拉取最新的文件，将其存放在共享的 volume 中。Web Server 从 volume 读取文件，响应 Consumer 的请求。这两个容器是紧密协作的，它们一起为 Consumer 提供最新的数据；同时它们也通过 volume 共享数据。所以放到一个 Pod 是合适的。

再来看一个反例：是否需要将 Tomcat 和 MySQL 放到一个 Pod 中？

Tomcat 从 MySQL 读取数据，它们之间需要协作，但还不至于需要放到一个 Pod 中一起部署，一起启动，一起停止。同时它们是之间通过 JDBC 交换数据，并不是直接共享存储，所以放到各自的 Pod 中更合适。

• Controller Manager

Controller Manager作为集群内部的管理控制中心，负责集群内的Node，Pod副本，服务端点（endpoint），命名空间（namespace）等的管理，当某个Node意外宕机，CM会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态。

K8S通常不会直接创建Pod。而是通过CM来管理Pods的，Controller Manager中定义了Pod的部署特性，比如有几个副本，在哪个Node上运行等，CM有许多不同的Controller，用来提供各种功能。如下图：

每个Controller通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试将系统状态修复到“期望状态”。

• Service

Deployment Controller为Pod和Replication Set通过声明示更新，通过它够可以创建出多个Pod，每个Pod都有自己的IP，那么外界如何去访问这些Pod呢？通过Pod的IP吗？这肯定是不行对的，Pod可能会被频繁地创建，销毁，或者重启，它们的IP会频繁地变化，用Pod的IP去访问不太现实。

答案是使用Service。

Service在K8S中主要提供的功能是负载均衡和服务自动发现，它提供了我们访问单个或者多个容器应用的能力。每个Service在其生命周期内，都拥有一个固定的IP地址和端口（所以Pod的IP变化，不会影响到这个Pod的上层Service的IP地址变化）。这样也方便后端进行Pod的弹性伸缩等操作。

所有说K8S运行Pod和访问Pod这两项任务分别由Controller和Service执行。

• NameSpace

我们可以认为NameSpace是K8S Cluster中的虚拟化集群。在一个K8S集群中可以有多个命名空间，这些命名空间在逻辑上彼此隔离。常见的pods, services, replication controllers和deployments等都是属于某一个NameSpace的（默认是default）。

类似于default这样的默认NameSpace，K8S集群共有三个：

•     default：创建资源时如果不指定NameSpace的话，默认将被放到default中
•     kube-system：kubernetes系统组件使用。
•     kube-public：公共资源使用。但实际上现在并不常用。

2.K8S架构和集群规划

• K8S架构

• K8S架构拆解图

K8S Master节点

    从上图可以看到K8S Cluster的大脑，运行着的Daemon服务包括kube-apiserver、kube-scheduler、kube-controller-manager、etcd和Pod网络（例如flannel）。

1. API Server （kube-apiserver)

    API Server提供HTTP/HTTPS RESTful API，即Kubernetes API。API Server是Kubernetes Cluster的前端接口，各种客户端工具（CLI或UI）以及Kubernetes其他组件可以通过它管理Cluster的各种资源。

2. Scheduler（kube-scheduler） 

    Scheduler负责决定将Pod放在哪个Node上运行。Scheduler在调度时会充分考虑Cluster的拓扑结构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。

3. Controller Manager（kube-controller-manager） 

    Controller Manager负责管理Cluster各种资源，保证资源处于预期的状态。Controller Manager 由多种Controller组成，包括replication controller、endpoint controller、namespace controller、serviceaccounts controller等。 
               不同的controller管理不同的资源。例如，replication controller管理Deployment、StatefulSet、DaemonSet的生命周期，namespace controller管理Namespace资源。

4. etcd
               etcd负责保存Kubernetes Cluster的配置信息和各种资源的状态信息。当数据发生变化时，etcd会快速通知Kubernetes相关组件。

5. Pod网络 

    Pod要能够相同通信，Kubernetes Cluster必须部署Pod网络，flannel是其中一个可选方案。

K8S Node节点

Node是Kubernetes集群架构中运行Pod的服务节点（亦叫agent或minion）。Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。关联Master管理节点，拥有名称和IP、系统资源信息。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy.

• 每个Node节点都运行着以下一组关键进程
• kubelet：负责对Pod对于的容器的创建、启停等任务
• kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件
• Docker Engine（Docker）：Docker引擎，负责本机容器的创建和管理工作

　　Node节点可以在运行期间动态增加到Kubernetes集群中，默认情况下，kubelet会向master注册自己，这也是Kubernetes推荐的Node管理方式，kubelet进程会定时向Master汇报自身情报，如操作系统、Docker版本、CPU和内存，以及有哪些Pod在运行等等，这样Master可以获知每个Node节点的资源使用情况，冰实现高效均衡的资源调度策略。

1. Kubelet：kubelet是node的agent，当Scheduler确定在某个Node上运行Pod后，会将Pod的具体配置信息（image、volume等）发送给该节点的kubelet，kubelet会根据这些信息创建和运行容器，并向master报告运行状态。

2. Kube-proxy: service在逻辑上代表了后端的多个Pod，外借通过service访问Pod。service接收到请求就需要kube-proxy完成转发到Pod的。每个Node都会运行kube-proxy服务，负责将访问的service的TCP/UDP数据流转发到后端的容器，如果有多个副本，kube-proxy会实现负载均衡，有2种方式：LVS或者Iptables。

3. 容器运行时环境，如Docker, rkt, runc等：负责节点的容器的管理工作。

K8S中Pod的创建流程

创建Pod 的流程

           1. 用户通过REST API创建一个Pod
           2. apiserver将其写入etcd
           3. scheduluer检测到未绑定Node的Pod，开始调度并更新Pod的Node绑定
           4. kubelet检测到有新的Pod调度过来，通过container runtime运行该Pod
           5. kubelet通过container run

 

参考：《每天5分钟玩转Kubernetes》、https://www.cnblogs.com/linuxk/