kubernetes 核心内容梳理

kubernetes 核心内容梳理

tk_sky 134 2024-02-29

kubernetes 核心内容梳理

正向梳理下 k8s 的比较重要的基础内容

背景

k8s 的时代背景：物理机 -> 虚拟机 -> 容器

物理机缺点：

  • 部署慢
  • 成本高
  • 资源浪费
  • 扩展和迁移成本高

虚拟机优点：

  • 易部署
  • 资源池
  • 资源隔离
  • 易扩展

虚拟机缺点：每台虚拟机都要安装操作系统，占用资源

容器优点：

  • 共享操作系统，不用额外的操作系统开销
  • 一致的运行环境，相同镜像行为相同
  • 镜像更小，因为不需要打包os
  • 启动更快

为什么需要容器编排技术：

  • 容器可以自动装箱
  • 可以水平扩缩
  • 可以自动化上线和回滚
  • 可以自我修复
  • 可以做服务发现与负载均衡

架构

image-20240229224201261

在 k8s 中，由 Master 节点 和 Node 节点共同构成一个集群。Master 节点组成控制平面，Node 节点则负责承载被调度的容器。当然，Master 节点也可以承载容器。

Master

Master 节点包含的组件有：

  • etcd：分布式 kv 存储，使用 raft 协议，保存集群的元信息和各种需要一致性的数据
  • API Server：集群统一入口，以 restful 风格操作，交由 etcd 对操作落盘。提供认证、授权、访问控制、API 注册和发现等机制。可以通过 kubectl 命令行工具或者 sdk 访问。
  • Scheduler：调度器，选择 node 节点部署容器
  • Controller Manager：处理集群中常规后台任务，一种资源对应一个控制器，同时监控集群状态，确保实际状态和最终状态一致

Worker

Worker 节点包含的组件有：

  • kubelet：负责管理本机的容器，向上汇报数据给 Api Server
  • Container Runtime：容器运行时，如 docker
  • kube-proxy：实现服务抽象的组件，屏蔽 pod IP 变化以及负载均衡

系统流程

以使用 kubectl 创建一个 pod 为例：

  • 使用 kubectl 工具向 api server 发送一个请求
  • api server 将请求放在 etcd 中
  • controller manager 会收到一个通知
  • controller manager 发现集群现状和预期不一致，因此要创建 pod，通知到 scheduler
  • scheduler 选择空闲的 worker 节点，通过 api server 更新 pod 的定义
  • api server 通知该节点上的 kubelet
  • kubelet 指示容器运行时创建对应的容器
  • 容器运行时下载镜像并启动容器

核心概念

Pod

  • pod 是最小的调度单元
  • pod 会包含一个或多个容器（Container）
  • pod 内的容器共享存储和网络，通过 localhost 通信
  • 容器健康检查：pod 使用探针 probe 通过 sh 脚本、tcp 或者 http 的方式检测容器的健康，出现异常时 pod 会根据配置的策略做操作，探针的种类包括 startup（启动后不做后续检测）、liveness（一直检查应用是否正常）、readiness（检查是否正常对外提供服务，否则不切量）
  • 可以使用 limits 字段限制容器的 cpu 时间片或内存占用等
  • 配合 HorizontalPodAutoScaler，HPA，可以完成自动扩缩容。

Deployment 和 ReplicaSet

  • 定义一组 pod 的副本数量和版本
  • 通过控制器维护 pod 的数目
  • 自动恢复失败的 pod
  • 面向一般应用的管理
  • Deployment 是对 replicaSet 的封装，增加了 replicaSet 状态监控、灰度和回滚功能

Service

  • 本质是一个四层负载均衡组件，反向代理 pod
  • 提供固定对外 IP 和负载均衡
  • pod 发生变化时，service 会通过 controller manager 实时监控到
  • 使用 ClusterIP 模式进行内部访问，或者 NodePort 模式开放对外端口访问

Ingress

  • 本质是一个七层网关组件，利用网关细分请求，再转发给各个 service
  • Ingress 将配置定义和转发程序分别拆分为 Ingress对象的 rule 和 Ingress Controller，一般由社区实现

DaemonSet

  • 每个 node 仅部署一个的特殊 pod，守护进程
  • 确保被调度到每个可用节点上
  • 用于配合集群监控、收集宿主机负载、日志等

PV 与 PVC

是管理 docker volume 的存储体系，包括：

  • PV：预制的资源实体，可以是指定大小的磁盘空间、临时资源或 NFS 等
  • PVC：代表一份使用空间的申请，描述了 pod 需要的空间大小和类型。申请之后，PersistentVolumeController 会不断尝试进行 PV 与 PVC 的自动绑定。如果找不到合适的 PV，pod 会启动失败。
  • StorageClass：自动创建 PV 并执行 PV 与 PVC 的绑定，不用再手动创建 PV。可以自定义设置与不同的存储插件绑定，比如 NFS 或 ceph。

有状态服务

如果有数据持久化，也就是 PV、pod 之间的强依赖关系，或者有服务间依赖、主从关系，就属于有状态服务。

  • StatefulSet：解决拓扑（服务间依赖关系）的问题，重启时会按顺序启动，保证拓扑结构稳定；数据持久化时固定声明的 pvc，且 pvc 不会因为 pod 删除而消失，新 pod 建立时会寻找旧 pod 的 PVC，重新绑定。
  • Operator：用编程的方式解决 StatefulSet 功能比较死板的问题，利用自定义API，直接去用代码完成自动化工作，本质是对 k8s 的扩展。

分布式配置

  • ConfigMap：存储在 k8s 控制面，支持实时更新，一样以资源的形式定义
  • Secret：加密的 ConfigMap

总结

k8s 以容器技术为依托，围绕 pod 这一核心概念，扩展出了大规模服务部署、运维和调度的功能，同时融合了很多现代运维和服务治理能力，包括滚动更新、灰度发布、健康检查、复杂均衡、自动扩缩容、资源隔离、服务隔离、路由网关、服务发现、分布式配置等。

容器 云原生