极客时间《云原生训练营》学习笔记。

Kubernetes 基础架构-主要组件

主要组件的工作原理

image-20211209221959096

左边是Master节点，右面是计算节点。

Kubernetes 的主节点（Master Node）

apiserver 这是 Kubernetes 控制面板中唯一带有用户可访问 API 以及用户可交互的组件。API 服务器会暴露一个 RESTful 的 Kubernetes API 并使用 JSON 格式的清单文件（manifest files）。

是一个网关服务，接收所有的请求，我们细看它的功能，网关都要做认证授权的。然后认证，授权完了，还有一个准入的动作，准入的动作就是相当于我要去校验这个请求是不是合法，教验完了以后，把这个请求转发到ETCD数据库里面，

Cluster Data Store Kubernetes 使 用“etcd”。这是一个强大的、稳定的、高可用的键值存储，被Kubernetes 用于长久储存所有的 API 对象。

controller manager 被称为“kube-controller manager”，它运行着所有处理集群日常任务的控制器。包括了节点控制器、副本控制器、端点（endpoint）控制器以及服务账户等。

是用来观察整个集群的，用来监听不同的kubernetes对象，这里面有很多的控制器角色观察不同的kubernetes对象。一旦某些对象发生了变化，它就会发起一个重新配置的一个动作用来确保所有的应用都是健康活着的.

scheduler 调度器会监控新建的 pods（一组或一个容器）并将其分配给节点。

调度器跟contorleer manager了里面的contorller 逻辑其实是精类似的。但是调度器是一种特殊的控制器，那他怎么特殊呢？他只去关注那些创建出来的pod并且没有node绑定给这个pod的类型，这些pod说明是需要经过调度的。所以调度器就会把这些pod过滤出来，然后一个个去调度，它会从这边apiserver获取所有节点的状况，然后去按照一定的调度算法来为这个pod选择一个合适的节点。并且把这个节点的名字更新回到这个pod的属性里面，然后一旦这个pod跟某个节点发生了一个绑定关系，

Kubernetes 的工作节点（Worker Node）

Kubelet 负责调度到对应节点的 Pod 的生命周期管理，执行任务并将 Pod 状态报告给主节 点的渠道，通过容器运行时（拉取镜像、启动和停止容器等）来运行这些容器。它还会定期执行被请求的容器的健康探测程序。

这个节点就会观测到pod属性的变化，这个pod是和他绑定的，说明这个应用是要启在我本地，那我先去看看本地是不是已经启了这个应用，如果没启。说明要去创建，它需要通过运行时把这个进程拉起来（CRI），需要挂载网络(CNI)，需要挂载存储(CSI)，kubernetes就把这些东西全部都抽象出来，它会掉这些接口，然后完成这个pod的启动，

CRI（Container Runtime Interface）：容器运行时接口，提供计算资源 CNI（Container Network Interface）：容器网络接口，提供网络资源 CSI（Container Storage Interface）：容器存储接口，提供存储资源

kube-proxy 它负责节点的网络，在主机上维护网络规则并执行连接转发。它还负责对正在服务的 pods 进行负载平衡。

每个节点上还有一个proxy的进程，做什么的呢? 就是你这个应用pod进程跑起来以后你怎么提供服务呢？要去定一个service对象，这个对象就说我这10组pod要发布一个服务，发布一个web服务，别人可以通过域名来访问，对于这样的service它的负载均衡都是proxy配的，一旦配置完成了以后客户端就可以通过service提供的一个访问入口，去访问几个对应的服务。

etcd

image-20211209225936758

etcd 是 CoreOS 基于 Raft 开发的分布式 key-value 存储，可用于服务发现、共享配置以及一致性保障（如 数据库选主、分布式锁等）。 • 基本的 key-value 存储；

  • 监听机制；
  • key 的过期及续约机制，用于监控和服务发现；
  • 原子 CAS 和 CAD，用于分布式锁和 leader 选举。

直接访问 etcd 的数据

进入容器， 通过 etcd 进程查看启动参数

1
2
3
4
5
6

export ETCDCTL_API=3
etcdctl --endpoints https://localhost:2379 \n
--cert /etc/kubernetes/pki/etcd/server.crt \n
--key /etc/kubernetes/pki/etcd/server.key \n
--cacert /etc/kubernetes/pki/etcd/ca.crt \n
get --keys-only --prefix /

监听对象变化

1
2
3
4
5

etcdctl --endpoints https://localhost:2379 \n
--cert /etc/kubernetes/pki/etcd/server.crt \n
--key /etc/kubernetes/pki/etcd/server.key \n
--cacert /etc/kubernetes/pki/etcd/ca.crt \n
watch --prefix /registry/services/specs/default/mynginx

APIServer

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

  • 提供集群管理的 REST API 接口，包括:
    • 认证 Authentication；
    • 授权 Authorization；
    • 准入 Admission（Mutating & Valiating）。
  • 提供其他模块之间的数据交互和通信的枢纽（其他模块通过 APIServer 查询或 修改数据，只有 APIServer 才直接操作 etcd）。
  • APIServer 提供 etcd 数据缓存以减少集群对 etcd 的访问。

APIServer 是唯一一个与ETCD通信的组件，那么为什么呢？因为APIServer这边有一个Watch缓存。所以这个缓存就是相当于做了一定的保护，因为分布式的数据存储一定是慢的，那么多组件，每个组件都在不停的访问这些数据，那怎么办呢？所有的读操作都从APIServer去读。除非你的请求参数里指定，否则它不会击穿APIServer直接访问ETCD的，大部分读操作都是直接访问APIServer，写操作就会写到ETCD里，除了它提供认证授权和准入的这种机制就是用来从安全性来保护整个集群，通过缓存来保护后面的这个ETCD数据存储。

APIServer 展开

image-20211209230722164

APIHandler 处理你要访问哪个路径？应该交由哪个方式处理？

AuthN 认证

Rate Limit 限流， 看看我现在还能不能处理这个请求

Auditing 安全审计，记录访问日志

AuthZ k8s RBAC 鉴权

Aggregator 聚合器

Mutating Webhook 变形，一般处理这个请求一个加一个属性或者修改一个属性

Schema Validation 内置校验器

Validating Webhook 附加校验器

Aggregated APIServer apiserver扩展性，你可以开发自已的apiserver组件，内嵌到原生的apiserver里去

ETCD 所有的路径都过了以后， 才会存入ETCD

Controller Manager

  • Controller Manager 是集群的大脑，是确保整个集群动起来的关键；
  • 作用是确保 Kubernetes 遵循声明式系统规范，确保系统的真实状态（Actual State）与用户定义的期望状态（Desired State）一致；
  • Controller Manager 是多个控制器的组合，每个 Controller 事实上都是一个control loop，负责侦听其管控的对象，当对象发生变更时完成配置；
  • Controller 配置失败通常会触发自动重试，整个集群会在控制器不断重试的机 制下确保最终一致性（ Eventual Consistency）。

这个集合里面有很多的控制器，但是这些控制器，它里面的逻辑是大同小异。 都是生产者和消费者模型。

要注意的是 你接收到一个事件后这个事件放到队列里面，消费者把这个事件从队列里面取出来去做配置，如果配置失败了你应该把它丢回的队列里面去，否则的话，刚才那个事件就丢了，只有有这种不断重试机制，系统才叫最终一致性。最终一致性就是我不能保证一次就配好，但是我出错的时候都要会去重试。 当然 出错重试的时候要有一个按指数级等待的一个rate limit 以防把 apiserver 弄死。

控制器的工作流程

简单来说就是一个生产者、消费者模型

image-20211209230902465

Informer 的内部机制

image-20211209230923314

控制器的协同工作原理

image-20211209230947854

Scheduler

特殊的 Controller，工作原理与其他控制器无差别。 Scheduler 的特殊职责在于监控当前集群所有未调度的 Pod，并且获取当前集群所有节点的健康状况和资源 使用情况，为待调度 Pod 选择最佳计算节点，完成调度。 调度阶段分为：

  • Predict：过滤不能满足业务需求的节点，如资源不足、端口冲突等。
  • Priority：按既定要素将满足调度需求的节点评分，选择最佳节点。
  • Bind：将计算节点与 Pod 绑定，完成调度。

image-20211209231026039

Kubelet

Kubernetes 的初始化系统（init system）

  • 从不同源获取 Pod 清单，并按需求启停 Pod 的核心组件：
    • Pod 清单可从本地文件目录，给定的 HTTPServer 或 Kube-APIServer 等源头获取；
    • Kubelet 将运行时，网络和存储抽象成了 CRI，CNI，CSI。
  • 负责汇报当前节点的资源信息和健康状态；
  • 负责 Pod 的健康检查和状态汇报。

image-20211209231110060

Kube-Proxy

  • 监控集群中用户发布的服务，并完成负载均衡配置。
  • 每个节点的 Kube-Proxy 都会配置相同的负载均衡策略，使得整个集群的服务发现建立在分布式负载 均衡器之上，服务调用无需经过额外的网络跳转（Network Hop）。
  • 负载均衡配置基于不同插件实现：
    • userspace。
    • 操作系统网络协议栈不同的 Hooks 点和插件：
      • iptables；
      • ipvs

image-20211209231148785