【云原生】Kubernetes 的组件与架构

引语

在上篇文章，我们介绍了 Kubernetes 是什么，它能够对容器进行编排，也就是说是容器的管理者，为容器做负载均衡、挂载存储系统、自动化部署和回滚、自我修复、自动装箱，那么 Kubernetes 是如何做到这些的呢？这就不得不提到 Kubernetes 的下面的这些重要组件了：

• 集群组件
• 核心概念
• 集群安装

1、集群组件

在MySQL、Redis……中我们就接触到集群这个概念了，要保证一个服务的可靠，集群是一个重要的方案，Kubernetes的集群中也有不同的角色，各司其职

• 集群 cluster ：将同一个软件服务多个节点组织在一起共同为系统提供服务过程称之为该软件的集群。

• k8s 集群中结点的角色有两种：

  • master 结点 / control plane 控制节点，主要用于容器的管理、调度、资源分配
  • work node 工作节点，实实在在运行容器

当部署完 Kubernetes，便拥有了一个完整的集群，一组工作机器，称为节点，会运行容器化应用程序。每个集群至少要有一个工作节点。工作节点会托管Pod，而 Pod 就是作为应用负载的组件，它其实不是容器，而是把容器包装了一层，控制平面管理集群中的工作节点和Pod

这张图摘自 Kubernetes 官网，在这张图中我们可以看到，一个 Kubernetes 集群，除了有我们看到的 Node 结点，其中还有Control Plane（其中包含kube-apiserver、etcd、kube-scheduler、kube-controller-manager、kube-controller-manager）

在下面我们就分别介绍 Kubernetes 集群中的各个组件以及它们的作用：

1.1 控制平面组件（Control Plane Components）

控制平面组件会为集群做出全局决策，例如资源的调度、检测和响应集群事件

控制平面组件可以在集群的任何结点上运行，但是一般情况会在同一台计算机上启动所有控制平面组件，而不会再此计算机上运行用户容器

• kube-apiserver
  API server 是 Kubernetes 控制平面的组件，其实就是 Kubernetes 提供的 API 总入口，我们操作 Kubernetes 写的命令就会第一时间被 API server 接受到，负责处理接受请求的工作，kube-apiserver 是 API server 的主要实现，也就是使用的主要是 kube-apiserver ，因为它实现了水平扩缩，可以运行多个实例达到负载均衡的目的

• etcd
  一致且高可用的键值存储，用作 Kubernetes 的所有集群数据的后台数据库，也就是集群元数据，集群的相关信息都存在这个数据库中

• kube-scheduler
  负责调度的组件，负责监视新创建的、未指定运行节点的 Pods，并分配结点给 Pods 去运行，分配的时候考虑的因素有：

  1. Pod 的资源需求、软硬件以及策略约束
  2. 亲和性和反亲和性规范 （其实就是我们在运行 Pod 的时候去指定它能在哪个结点上运行就是亲和性，指定不能再哪个结点上运行就是反亲和性）
  3. 数据位置
  4. 工作负载之间的干扰和最后时限

• kube-controller-manager
  与kube-apiserver类似的是：kube-controller-manager 是 Controller Manager 的主要实现，它主要负责运行控制器进程
  控制器：在 Kubernetes 中存在以下四种控制器，我们在运行 Pod 的时候可以指定控制器

  • 节点控制器（Node Controller）：负责在节点出故障的时候进行通知和响应
  • 任务控制器（Job Controller）：检测一次性任务的 Job 对象，然后创建 Pods 来运行这些任务
  • 端点分片控制器（EndpointSlice Controller）：通过 Service 和 Pod 之间的连接去暴露 Pod 的外部服务
  • 服务账号控制器（ServiceAccount Controller）：为新的命名空间创建默认的服务账号
    从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，他们都被编译到同一个可执行文件中，并在同一个进程中运行

• cloud-controller-manager
  这是一个可选的组件，它嵌入了特定云平台的控制逻辑，也就是把集群连接到云提供商的 API 上，因此如果在自己的环境或者本地计算机中运行学习环境，部署的集群是不需要这个组件的，与kube-controller-manager 类似，它也是负责运行控制器进程
  下面的控制器都包含对云平台驱动的依赖：

  • 节点控制器：用于在节点终止响应之后检查云提供商以确定节点是否已经被删除了
  • 路由控制器：用于在底层云基础架构中设置路由
  • 服务控制器：用于创建、更新和删除云提供商负载均衡器

1.2 Node 组件

节点组件会在每一个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行环境，负责维护运行 Pod，也就是容器的运行由Node 组件负责

• kubelet
  会在每一个节点上运行，保证容器都运行在 Pods 中
  也就是说，kubelet 会接受各类机制提供的配置文件，然后确保这些配置文件描述的容器能够正常的运行，它是不会管理非 Kubernetes 创建的容器
• kube-proxy
  用于实现内外部网络交互的规则，如果想把 Pod 暴露给外部提供服务，也就是负责容器与外界的网络通信，就需要配置网络规则，允许从集群内部或者外部的网络与集群内的容器进行网络通信
• 容器运行时（Container Runtime）
  Pod 是需要包裹 Container，那么就需要运行容器的环境
  Kubernetes 支持许多容器的运行环境，例如 Containerd、CRI-0、Docker 以及 Kubernetes CRI 的其他任何实现

1.3 插件（Addons）

• DNS
  尽管它是插件，但其实它可以说是一个必须组件，几乎所有的 Kubernetes 集群都有 DNS 服务
• Web 界面（仪表盘）
  Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面，管理集群中运行的应用的程序
• 容器资源监控
  容器资源监控就是把一些常见的时间序列度量值保存到一个集中的数据中，并提供浏览这些数据的可视化页面
• 集群层面日志
  集群层面日志负责把日志数据保存到一个集中的日志存储中，并提供搜索和浏览的接口

2、集群搭建

• minikube
  只是一个 Kubernetes 的模拟器，只有一个节点的集群，它的 master 和 worker 都在一起，用于测试
• 裸机安装
  至少需要两台机器（一个主节点、一个工作节点），需要自己安装 Kubernetes 组件，配置更麻烦缺点：配置麻烦、缺少生态支持、没有负载均衡器、云存储
• 直接使用云平台 Kubernetes可视化搭建，只需要几步就可以创建好一个集群优点：安装简单、生态齐全、有负载均衡器、云存储
• k3s
• 安装简单，脚本自动完成优点：轻量级、配置要求低、安装简单、生态齐全

这里就没有演示如何进行集群的搭建，其中 minikube 是使用 Docker 的可视化工具进行自动搭建，而裸机安装一般是用于学习使用，博主就是裸机搭建的，需要较大的运行内存，或者使用云服务器

总结

本篇博客更加深入的了解了 Kubernetes 里面的组件，以及一个 Kubernetes 集群中各个组件的作用，总的来讲是三大类组件：控制平面组件、Node结点、插件：

• 其中控制平面组件一般单独运行在一个机器上，而不部署 Pod
• Node 结点是让 Pod 正常的运行以及维护
• 插件就因人而异了，不过 DNS 插件可以说一个必须的插件，后续的学习中还会使用到另外的插件，用于查看响应的时间