K8s架构和重要概念

k8s 架构图 master与node关系图：

Master 架构

• API Server：提供了HTTP Rest 接口的服务进程，对所有资源对象的增删改查等操作的唯一入口
• Contorller Manager: k8s 集群所有资源对象的自动化控制中心
• Schedular： ks集群中所有资源对象自动化调度控制中心
• ETCD： k8s集群注册服务发现中心，可以保存k8s集群中所有资源对象的数据

Node 架构

在 OS 上去创建容器所需要运行的环境，最终把容器或者 Pod 运行起来，也需要对存储跟网络进行管理。

• Kubelet: 负责Pod对应容器的创建，启动和停止等操作，与master节点合作

• kube-proxy: 使用iptabels进行组建Kunernetes的网络实现互通

• Storage plugin:配置容器存储

• Network plugin： 配置容器网络

• Container Runtime： 启动配置这个容器和这个容器的运行环境Pod

Pod架构

一个Pod里面有一个或多个容器，定义容器运行的方式，提供给容器其共享的运行环境（网络等）。

在 Pod 里面，我们也可以去定义容器所需要运行的方式。比如说运行容器的 Command，以及运行容器的环境变量等等。Pod 这个抽象也给这些容器提供了一个共享的运行环境，它们会共享同一个网络环境，这些容器可以用 localhost 来进行直接的连接。而 Pod 与 Pod 之间，是互相有 isolation 隔离的。

• Pod 可包含多个容器在里面，每个 Pod 至少会有一个 Pause 容器，其它用户定义的容器都共享该 Pause 容器，Pause 容器的主要作用是用于定义 Pod 的 ip 和 volume，
• Pod 是 Kubernetes 的最小工作单元
• 每个 Pod 包含一个或多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行

Pause 容器： 每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。

设计原因？

原因之一：在一组容器作为一个单元的情况下，我们难以简单地对“整体”进行判断及有效地行动。
原因之二：Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接的Volume，这样既简化了密切关联的业务容器之间的通信问题，也很好地解决了它们之间的文件共享问题。
通俗的讲，就是一个pod可能会包括多个容器，需要有一个管理者就是pause。

Kubernetes 引入 Pod 的两个目的

（1）可管理性

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

（2）通信和资源共享

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

3，Pod 的两种使用方式

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

对于那些联系非常紧密，而且需要直接共享资源的容器，应该放在一个 Pod 中。
比如下面这个 Pod 包含两个容器：一个 File Puller，一个是 Web Server。File Puller 会定期从外部的 Content Manager 中拉取最新的文件，将其存放在共享的 volume 中。Web Server 从 volume 读取文件，响应 Consumer 的请求。这两个容器是紧密协作的，它们一起为 Consumer 提供最新的数据；同时它们也通过 volume 共享数据。所以放到一个 Pod 是合适的。

API Server 创建pod基本流程图

• 用户通过API Server创建一个Pod
• API Server将信息写入到etcd中存储
• scheduler检测到有未绑定Node节点的Pod，开始调度并更新Pod绑定到哪个节点，并发送给API Server
• API Server 会把Pod绑定的节点信息写入到etcd和scheduler 本地留存一份
• Node结点上的kubelet通过API Server查看绑定的Pod，检测到新的pod被调度过来，于是将Pod相关数据传递给container runtime ，比如 Docker，去运行Pod
• Docker将运行的信息传递给Container runtime，Kubelete可以从它获取到Pod状态，将状态更新到API Server中。API Server最后将状态写入etcd