文章目录
Kubernetes——K8s 核心概念和集群架构组件
1、K8s 核心概念
1.1、Pod
Pod 概述
Pod 是 Kubernetes 创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。
一个 Pod 封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。
Pod 中的每个容器共享网络命名空间，包括IP地址和网络端口。Pod内的容器可以使用localhost相互通信。
Pod 可以指定一组共享存储 volumes 数据卷。Pod 中的所有容器都可以访问共享 volumes，允许这些容器共享数据。volumes 还用于 Pod 中的数据持久化，以防其中一个容器需要重新启动而丢失数据。
Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行。(注意：可以把 pod 想象成豌豆荚，豌豆就是容器，可以有一个或多个。)
首先，Pod运行在一个我们称之为节点（Node）的环境中，这个节点可能是物理机或虚拟机，通常一个节点上面运行几百个Pod；其次每个Pod运行着一个特殊的被称之为根容器（Pause），和一组用户容器组成，这些业务容器共享根容器（Pause）的网络栈和Volume挂载卷，因此它们之间的通信和数据交换效率更为高效。在设计时我们可以充分利用这一特性将一组密切相关的服务进程放到同一个Pod中。最后需要注意的是并不是每一个Pod和它里面运行的容器都能映射到一个Service上，只有那些提供服务的一组Pod才会被映射成一个服务。
静态Pod 和 普通Pod
普通的 Pod：普通 Pod 一旦被创建，就会被放入到etcd中存储，随后会被 Kubernetes Master（主控节点）调度到某个具体的Node上并进行绑定(Binding)，随后该 Pod 被对应的 Node上的 kubelet 进程实例化成一组相关的 docker 容器运行起来。当 Pod 里的某个容器停止时 Kubernetes 会自动检测到这个问题并且重新启动这个 Pod (重启 Pod 里的所有容器)，如果 Pod 所在的 Node 宕机，则会将这个 Node 上所有的 Pod 从新调度到其他节点上。
静态 Pod (Static Pod)：静态 Pod 不存放在 Kubernetes 的 etcd 存储里，而是存放在某个具体的 Node 上的文件中，并且只在此Node上启动运行。静态Pod是由kubelet进行管理的仅存在于特定 Node 上的 Pod。他们不能通过 API Server 进行管理，无法与ReplicationController(RC)、Deployment、或者DaemonSet进行关联，并且kubelet也无法对它们进行健康检查。静态Pod总是由kubelet进行创建的，并且总是在kubelet所在的Node上运行的。
Pod 生命周期
Pod 遵循一个预定义的生命周期，起始于 Pending 阶段，如果至少 其中有一个主要容器正常启动，则进入 Running，之后取决于 Pod 中是否有容器以 失败状态结束而进入 Succeeded 或者 Failed 阶段。
Pod 阶段：Pod 的阶段（Phase）是 Pod 在其生命周期中所处位置的简单宏观概述。
| 取值 | 描述 |
|---|---|
Pending（悬决） |
Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间， |
Running（运行中） |
Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。 |
Succeeded（成功） |
Pod 中的所有容器都已成功终止，并且不会再重启。 |
Failed（失败） |
Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。 |
Unknown（未知） |
因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。 |
1.2、controller，Label 和 service
controller
controller 是 Kubernetes 系统中的核心概念，它其实是定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值。
- 确保预期的 Pod 副本数量
- 无状态应用部署（拿来即用）
- 有状态应用部署（使用有约束条件）
- 可以确保所有的 Node 运行同一个 Pod
- 支持一次行任务和定时任务
Label
Label 是 Kubernetes 系统中另外一个核心概念。Label是一系列的Key/value对，其中key与vaue由用户自己指定。Label可以附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去，Label通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。
可以通过指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便地进行资源分配、调度、配置、部署等管理工作。
service
service 定义一组 Pod 的访问规则。Service通过 Label 找到 Pod 组。
2、K8s集群架构组件
K8s 集群架构组件图
一个 Kubernetes 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点（）。
Master （主控节点）：集群中控制面板的功能，来管理整个集群，控制包括全局的角色和调度。Master 是 Kubernetes 集群 的大脑，它的主要职责是调度，即决定将应用放在哪里运行，实现高可用，可以运行多个 Master。
Master 中运行的组件：
-
API Server：集群的统一入口，各组件协调者，以RESTful API提供接口服务，所有对象资源的增删改查和监听操作都交给API Server处理后再提交给 etcd 存储。
-
Scheduler：实现集群节点的调度。根据调度算法为新创建的 Pod 选择一个Node 节点，可以任意部署，可以部署在同一个节点上，也可以部署在不同的节点上。调度算法考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
-
Controller Manager：处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager就是负责管理这些控制器的。
从逻辑上讲，每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。
这些控制器包括:
- 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
- 任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
- 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
- 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌
-
etcd：etcd 是兼具一致性和高可用性的键值数据库。用于保存集群状态数据，比如 Pod、Service 等对象信息，使用时需要为etcd 数据提供备份计划。
Node（工作节点）：Node 的职责是运行容器应用，提供Kubernetes运行时环境，以及维护 Pod。Node 由 Master 管理，Node 负责监控并汇报容器的状态，并根据 Master 的要求管理容器的生命周期。
Node 中运行的组件：
-
Kubelet：是Master在Node节点上的代理，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。 kubelet 不会管理不是由 Kubernetes 创建的容器。
Kubele 是主要的节点代理，它会监视已分配给节点的 pod，具体功能：
- 安装Pod所需的 volume。
- 下载Pod的Secrets。
- Pod中运行的 docker（或experimentally，rkt）容器。
- 定期执行容器健康检查。
-
Kube-proxy：在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
-
docker：Docker引擎，负责本机的容器创建和管理工作。