Kubernetes介绍、架构介绍、组件介绍

wffeige
203 阅读5分钟

官方文档 kubernetes.io/zh-cn/

Kubernetes集群的节点类型

由Master和Worker两类节点组成

  • Master：控制节点 控制平面 决策方 劳心者

    • apiserver
    • controller
    • scheduler
    • etcd

  • Worker：工作节点 数据平面 工作方 劳力者

    • 运行容器 管理声明周期
    • kubelet
    • kube proxy
      • 服务发现 负载均衡器
      • 为pod 运行的服务 提供固定的访问入口、服务发现、负载均衡功能

kubectl/helm/dashoardUI工具 命令行, 可以调用API service 完成指令的执行

image.png

运行逻辑

  • Kubernetes将所有工作节点的存储、计算、网络资源集结在一起形成一台更加强大的“服务器”
  • 计算和存储接口通过Master之上的API Server暴露
  • 客户端通过API提交应用程序的运行请求，而后由Master通过 调度算法 将其自动指派至某特定的工作节点以Pod对象的形式运行
    • POD 容器集 可以N个容器
  • Master会自动处理因工作节点的添加、故障或移除等变动对Pod的影响
    • 外接存储卷 volume 独立于pod的生命周期

pod故障 会自动再创建出来的 但是容器中写入的数据 怎么办？

外接存储卷 volume 独立于pod的生命周期 容器内不写关键数据 需要持久化存储的数据 放到外部的卷中

Kubernetes集群架构

image.png

Kubernetes属于典型的Server-Client形式的二层架构

组件介绍

控制平面

Master节点上的组件 位于控制平面

数据平面

Worker节点上的组件 位于数据平面 按照控制平面的编排去创建 和 编排pod

ApiServer

  • 暴露restful风格的API http协议
  • kube proxy 和 Controller-Manager 会请求ApiServer
  • ApiServer的数据存储在Etcd 他自己本身只有表结构(类似model层) 实际的数据是放入到Etcd
  • 整个集群的API网关，相关应用程序为kube-apiserver
  • 基于http/https协议以REST风格提供，几乎所有功能全部抽象为“资源”及相关的“对象”
  • 声明式API，用于只需要声明对象的“终态” ，具体的业务逻辑由各资源相关的Controller负责完成
  • 无状态，数据存储于etcd中

Controller-Manager

决策中心

  • 负责实现客户端通过API提交的终态声明，相应应用程序为kube-controller-manager
  • 由相关代码通过一系列步骤驱动API对象的“实际状态”接近或等同“期望状态”
  • 工作于loop模式, 通过loop 保证实际状态和 用户期望状态 可以保持一致
  • route Controller
  • volume Controller
  • service Controller
  • node Controller
  • deployment Controller
  • replicaSet Controller

Scheduler

调度中心 负责选择POD创建到哪个节点

  • 调度器，负责为Pod挑选出（评估这一刻）最合适的运行节点
  • 相关程序为kube-scheduler

Etcd

  • 用于存储集群状态
  • 是一个kv存储
  • 集群状态数据存储系统，通常指的就是etcd
  • 仅会同API Server交互

Worker节点上的组件: 位于数据平面

Kubelet

  • 每个Worker节点需要运行一个Kubelet实例
    • 负责当前节点上的和容器相关的事务
    • 按照控制平面的编排去创建 和 编排pod
  • 调用CRI 创建计算资源 创建容器
  • 调用CSI 创建存储资源 对接外部的存储设备 为pod创建存储卷
  • 调用CNI 创建网络资源 对接外部的网络插件 为pod置备网络环境
    • 包括添加网络接口
    • 网络接口 加入虚拟网络
    • 网络接口 添加ip地址
  • Kubernetes集群于每个Worker节点上的代理，相应程序为kubelet
  • 接收并执行Master发来的指令，管理由Scheduler绑定至当前节点上的Pod对象的容器
  • 通过API Server接收Pod资源定义，或从节点本地目录中加载静态Pod配置
  • 借助于兼容CRI的容器运行时管理和监控Pod相关的容器

Kube Proxy

链路 请求--> proxy --> Pod

  • 负载均衡器

    • iptables ipvs两种方式

  • Kube Proxy为每一个pod化运行的服务提供固定访问入口

  • 服务发现 POD发现

  • 负载均衡的具体实现

  • 运行于每个Worker节点上，专用于负责将Service资源的定义转为节点本地的实现（也就是iptables规则）

    • iptables模式：将Service资源的定义转为适配当前节点视角的iptables规则
    • ipvs模式：将Service资源的定义转为适配当前节点视角的ipvs和少量iptables规则

  • 负责把发往 service的流量 发送到对应的node上的pod中

  • 需要运行在每一台主机上

  • 针对每个service 需要将service的定义 转换为iptables或ips规则, 然后配置在每个节点的内核上

    • 请求直接从内核转发到对应的节点上了
    • 将集群中的每一个节点 都视为动态可配置的负载均衡器

规范介绍

CRI(container runtime interface)

CRI 容器运行时接口 container runtime interface

容器运行时有以下几种:

  • docker-ce
    • docker-ce默认不支持 CRI规范 早期的docker不支持k8s 所以中间加了一个docker-shim的垫片
    • 后来docker-shim被废弃了
    • k8s 1.24 Kubelet通过内置一个docker-shim垫片中间层(废弃了)
    • cri-docker 支持了k8s和docker-ce交互
    • k8s 1.24+ Kubelet 通过 新项目 cri-docoer 和docker-ce通信
  • containerd
  • cir-o

编排卷 CSI(Container Storage Interface)

  • 对接外层存储设备
  • 树内卷: Kubelet内置的卷类型(卷插件、卷驱动) 称之为树内卷, In-Tree的卷
  • 树外卷: 第三方 用于扩展支持更多的第三方存储服务

编排网络 CNI(Container Network Interface)

  • 强依赖外部的第三方网络解决方案 主要有两类:
    • Overlay
    • Underlay
  • 常用的两个外部插件 Flannel Calico
avatar
文章
阅读
粉丝