集群架构#

总架构图：

Controll plane（主节点） -> Node（从节点） + 一堆附加组件

k8s架构图

每一个大框可以看作一个服务器，也就是一个节点；因此这张图上有三个服务器，可以看出k8s的需求资源庞大

大致流程：

客户端 -> api-server(其中有命令行-http服务-k8s接口服务) -> pods

对就是这么简单

api-server 是交换api的核心，这个是最重要的

组件#

  • Controll Plane(Master)
  • Node(节点)
  • 附加的一些节点

这个真的是我看过的最详细的一张图了：

image-20240707231155144

Controll Plane (Master):

  1. api-server（核心）

    api-server 提供的是接口服务，基于 REST 风格开放k8s接口的服务

    所有的操作都是围绕 api-server 展开的, api-server 维护了各种功能api

    api-server 提供了 Master 到 Node 的交互

    [!IMPORTANT]

    对象的创建，删除，修改都是通过Kubernetes API，也就是Api-server组件提供的api接口实现的

    而这些api接口都是RESTFUL风格的，因此我们可以直接调用这些接口进行服务

  2. cloud-controller-manager

    云控制器管理器，第三方平台提供的控制器API

  3. kube-controller-manager

    管理控制器，管理各个类型的控制器(每个控制器就是一个进程)，针对k8s的各种资源进行管理

    那么控制器是什么东西呢？

    控制器就是管理Pod，node，等等各种层面的情况

    Controller-Manager 就相当于一个大管家，管理这么多的控制器

    节点控制器 | 任务控制器 | 端点分片控制器 | 服务账号控制器 |

  4. kube-scheduler

    调度器 负责将Pod 基于一定的算法，将其调用到更合适的节点上

  5. etcd

    即k8s的数据库，是键值类型存储的分布式数据库，实现集群高可用服务

Node(节点)：

  1. kubelet

    负责Pod的生命周期，存储，网络接口

  2. kube-proxy

    网络代理，对没了，但是这个网络代理是k8s内部的网络代理，如果要暴露网络对外，则需要反向代理(ngnix)

  3. Pod

    里面有容器，对有容器

  4. container-runtime(容器运行时) #不要把他直接认成Docker

    这个是容器运行时环境：Docker,containerd,CRI-O,就是为容器运行提供环境

附加组件(反正我现在不太了解)：

  1. kube-dns

    负责为整个集群提供 DNS 服务

  2. Ingress-Controller

    为服务提供外网入口

  3. Heapster

    提供资源监控，也可以用prometheus

  4. Dashboard

    GUI界面

  5. es

    日志收集