k8s 基础知识001

k8s架构：
Kubernetes 主要由以下几个核心组件组成：

• etcd 保存了整个集群的状态；
• kube-apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；
• kube-controller-manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• kube-scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
• kubelet 负责维持容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理；
• Container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI），默认的容器运行时为 Docker；
• kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；

image.png

除了核心组件，还有一些推荐的 Add-ons：

• kube-dns 负责为整个集群提供 DNS 服务
• Ingress Controller 为服务提供外网入口
• Heapster 提供资源监控
• Dashboard 提供 GUI
• Federation 提供跨可用区的集群
• Fluentd-elasticsearch 提供集群日志采集、存储与查询

核心组件简介
Etcd
Etcd 是 CoreOS 基于 Raft 开发的分布式 key-value 存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）
主要功能：

• 基本的 key-value 存储
• 监听机制
• key 的过期及续约机制，用于监控和服务发现
• 原子 CAS 和 CAD，用于分布式锁和 leader 选举
  在k8s中用来保存集群状态。

kube-apiserver
kube-apiserver 是 Kubernetes 最重要的核心组件之一，主要提供以下的功能

• 提供集群管理的 REST API 接口，包括认证授权、数据校验以及集群状态变更等
• 提供其他模块之间的数据交互和通信的枢纽（其他模块通过 API Server 查询或修改数据，只有 API Server 才直接操作 etcd）
  在k8s中用来提供资源唯一入口，并提供认证、授权、访问控制等功能，同时还会提供api的注册发现机制

kube-scheduler
ube-scheduler 负责分配调度 Pod 到集群内的节点上，它监听 kube-apiserver，查询还未分配 Node 的 Pod，然后根据调度策略为这些 Pod 分配节点（更新 Pod 的 NodeName 字段）。
调度器需要充分考虑诸多的因素：

• 公平调度
• 资源高效利用
• QoS
• affinity 和 anti-affinity
• 数据本地化（data locality）
• 内部负载干扰（inter-workload interference）
• deadlines
  在k8s中负责给prod按照一定负载均衡算法分配node机器。

Controller Manager
Controller Manager 由 kube-controller-manager 和 cloud-controller-manager 组成，是 Kubernetes 的大脑，它通过 apiserver 监控整个集群的状态，并确保集群处于预期的工作状态。
在k8s中起到维护集群状态，监控整个集群健康状况（metrice），有故障检测，自动扩展、滚动更新等功能，实现集群的高可用。

image.png

Kubelet
每个Node节点上都运行一个 Kubelet 服务进程，默认监听 10250 端口，接收并执行 Master 发来的指令，管理 Pod 及 Pod 中的容器。每个 Kubelet 进程会在 API Server 上注册所在Node节点的信息，定期向 Master 节点汇报该节点的资源使用情况，并通过 cAdvisor 监控节点和容器的资源。
在k8s上主要负责节点管理（包括节点的注册、状态更新）：

• Kubelet 可以通过设置启动参数 --register-node 来确定是否向 API Server 注册自己；
• 如果 Kubelet 没有选择自注册模式，则需要用户自己配置 Node 资源信息，同时需要告知 Kubelet 集群上的 API Server 的位置；
• Kubelet 在启动时通过 API Server 注册节点信息，并定时向 API Server 发送节点新消息，API Server 在接收到新消息后，将信息写入 etcd

kubelet 工作原理：
如下 kubelet 内部组件结构图所示，Kubelet 由许多内部组件构成

• Kubelet API，包括 10250 端口的认证 API、4194 端口的 cAdvisor API、10255 端口的只读 API 以及 10248 端口的健康检查 API
• syncLoop：从 API 或者 manifest 目录接收 Pod 更新，发送到 podWorkers 处理，大量使用 channel 处理来处理异步请求
• 辅助的 manager，如 cAdvisor、PLEG、Volume Manager 等，处理 syncLoop 以外的其他工作
• CRI：容器执行引擎接口，负责与 container runtime shim 通信
• 容器执行引擎，如 dockershim、rkt 等（注：rkt 暂未完成 CRI 的迁移）
• 网络插件，目前支持 CNI 和 kubenet

pod管理：
Kubelet 以 PodSpec 的方式工作。PodSpec 是描述一个 Pod 的 YAML 或 JSON 对象。 kubelet 采用一组通过各种机制提供的 PodSpecs（主要通过 apiserver），并确保这些 PodSpecs 中描述的 Pod 正常健康运行。(就是.yml配置文件中的spec)
获取Pod清单：Kubelet 通过 API Server Client(Kubelet 启动时创建)使用 Watch 加 List 的方式监听 "/registry/nodes/$ 当前节点名" 和 “/registry/pods” 目录，将获取的信息同步到本地缓存中。(本质就是watch-listen机制)
创建和修改 Pod 任务，执行流程：

• 为该 Pod 创建一个数据目录；
• 从 API Server 读取该 Pod 清单；
• 为该 Pod 挂载外部卷；
• 下载 Pod 用到的 Secret；
• 检查已经在节点上运行的 Pod，如果该 Pod 没有容器或 Pause 容器没有启动，则先停止 Pod 里所有容器的进程。如果在 Pod 中有需要删除的容器，则删除这些容器；
• 用 “kubernetes/pause” 镜像为每个 Pod 创建一个容器。Pause 容器用于接管 Pod 中所有其他容器的网络。每创建一个新的 Pod，Kubelet 都会先创建一个 Pause 容器，然后创建其他容器。
• 为 Pod 中的每个容器做如下处理：
  1. 为容器计算一个 hash 值，然后用容器的名字去 Docker 查询对应容器的 hash 值。若查找到容器，且两者 hash 值不同，则停止 Docker 中容器的进程，并停止与之关联的 Pause 容器的进程；若两者相同，则不做任何处理；
  2. 如果容器被终止了，且容器没有指定的 restartPolicy，则不做任何处理；
  3. 调用 Docker Client 下载容器镜像，调用 Docker Client 运行容器。

pod启动流程（参考的非官网文档，需要看源码验证）
一般我们在创建pod的过程中都是，执行kubectl命令去apply对应的yaml文件，但是在执行这个操作的过程到pod被完成创建，k8s的组件都做了哪些操作呢？下面我们简要说说pod被创建的过程。

image.png