Linux 知识库

Appearance

Kubernetes架构原理 ​

控制平面组件(Master节点) ​

控制平面组件构成了Kubernetes集群的"大脑"，负责集群的全局决策和管理

API Server (kube-apiserver) ​

  • 集群管理的唯一入口，提供RESTful API接口
  • 处理认证、授权、访问控制和API注册发现机制
  • 所有组件都通过API Server进行通信，不直接相互调用

etcd ​

etcd是分布式键值存储系统，作为Kubernetes的"记忆中心"，保存整个k8s集群的核心数据：

  • 分布式键值存储数据库，保存整个集群的状态和配置数据
  • 是Kubernetes集群中唯一有状态的组件
  • 存储所有资源对象(Pod、Service、Deployment等)的信息

Controller Manager (kube-controller-manager) ​

Controller Manager(kube-controller-manager)是集群的"自动修复系统"，管理中心，负则k8s集群的指令管理发出。

  • 运行各种控制器，确保集群实际状态与期望状态一致
  • 实现故障检测、自动扩展、滚动更新等功能

控制器包括：

  • Deployment Controller：确保Deployment定义的Pod副本数符合预期
  • ReplicaSet Controller：管理Pod副本数量
  • Node Controller：监控节点状态，处理节点故障
  • Service Controller：创建和更新Service资源
  • Namespace Controller：管理命名空间生命周期

kubectl ​

kubectl 是 Kubernetes 的标准命令行工具，用于与集群交互，管理资源（如 Pod、Deployment、Service 等）。开发者或运维人员通过它执行日常操作，例如部署应用、查看日志、调试问题等。

kubeadm ​

kubeadm 是官方提供的集群生命周期管理工具，专注于快速初始化和升级 Kubernetes 集群。它简化了主节点（Master）和工作节点（Worker）的部署流程。

Scheduler (kube-scheduler) ​

Scheduler(kube-scheduler)是集群的"调度中心"，负责：

  • Pod的调度，根据资源需求、亲和性等策略选择合适节点
  • 通过Watch机制监听未绑定的Pod，进行调度决策

Cloud Controller Manager (可选) ​

  • 在公有云环境中管理与云提供商相关的资源

  • 处理负载均衡器、云盘等云服务的创建和配置

工作节点组件(Node节点) ​

工作节点是实际运行容器化应用的"四肢"，执行控制平面的指令

Kubelet ​

Kubelet是节点上的"Pod管家"，负责接收来自controller-manager的指令具体执行资源的启停任务，功能包括：

  • 节点代理，管理Pod的生命周期
  • 与容器运行时(如Docker)交互，执行容器的创建、启动和停止
  • 监控节点资源使用情况并上报给API Server

Kube Proxy ​

Kube Proxy是集群的"网络代理"，负责k8s 中整个集群中各种资源之间的通信代理，实现：

  • 实现Service的负载均衡和网络代理功能
  • 通过维护iptables或IPVS规则实现流量转发
  • 为Pod提供集群内部的服务发现

扩展组件(Add-ons) ​

CoreDNS ​

CoreDNS是Kubernetes集群中负责DNS解析的核心组件，自Kubernetes 1.13版本起成为默认的DNS服务器，取代了早期的kube-dns。作为CNCF毕业项目，CoreDNS以其插件化架构、高性能和灵活性成为云原生环境下DNS解析的成熟解决方案。

  • 服务发现：将Kubernetes服务(如my-svc.default.svc.cluster.local)解析为ClusterIP或Pod IP，实现应用间通信
  • Pod域名解析：为每个Pod提供基于其IP地址的域名解析
  • 外部域名解析：将集群内的DNS请求转发到外部DNS服务器，解析外部域名(如www.example.com)
  • 自定义域名解析：通过Corefile配置文件支持自定义域名解析规则
  • 负载均衡：内置loadbalance插件，默认采用轮询策略分发流量至后端Pod
  • 反向DNS解析：支持IP地址到域名的反向解析(in-addr.arpa和ip6.arpa)

Calico ​

Calico采用纯三层网络模型，避免了传统Overlay网络的额外开销。每个Pod获得全局唯一、可路由的IP地址，通信就像在同一个局域网中的物理机一样直接高效。 无封装开销，性能更好；原生支持完整的 NetworkPolicy，适合生产环境、大规模集群及需要严格网络隔离的场景（如多租户、混合云）。

  • Pod创建：kubelet调用Calico CNI插件，为Pod分配IP并创建veth pair设备(一端在Pod内为eth0，一端在主机上为caliXXXXX)。
  • 路由传播：BIRD通过BGP协议将Pod IP路由信息广播给其他节点。
  • 跨节点通信：根据配置的网络模式(BGP/IPIP/VXLAN)实现Pod间通信。
  • 策略实施：Felix将NetworkPolicy转换为iptables/eBPF规则，实施访问控制

Flannel ​

纯 overlay 方案（默认 VXLAN/UDP 封装），配置简单，适合小规模测试或对性能要求不高的场景；但因封装解封装会有额外开销，且原生不支持 NetworkPolicy（需配合其他插件如 Calico 使用策略）。 简单说：Flannel 易上手但性能一般且需额外插件做策略；Calico 稍复杂但一站式解决网络+策略，性能更强。

Ingress Controller ​

  • 提供HTTP/HTTPS路由、负载均衡和SSL终止
  • 将外部请求路由到集群内部服务

K8S资源分类 ​

  • 工作负载：是指k8s集群中具体负责接受用户请求任务的应用

  • pod：k8s中的基本资源调度单位，k8s中一切活动都是pod为基本单位，它是一个容器的集合。

  • deployment：是pod集合，主要是运行无状态pod(web)，可以通过副本集控制pod的数量

  • statefulset: 是pod集群是有状态的pod集合(mysql)，可以通过副本集控制pod的数量

  • daemonset: 是pod集合。确保每个Node运行一个指定的Pod（如日志收集Agent）

  • job： Linux中的一次性定时任务

  • cronjob： Linux中的周期性定时任务

  • conifimap：记录工作负载配置信息，明文记录

  • secret：记录工作负载配置信息，记录敏感性，通过base64码转化记录

  • pv：存储卷

  • pvc：存储卷申请

  • service：Linux中四层代理，可实现各个资源负载均衡（代理proxy）

  • ingress：Linux中七层代理 （底层用的就是nginx）

  • rbac：权限的设置

组件协作流程 ​

以下是Kubernetes组件协作流程的Mermaid图表示，展示从创建Deployment到Pod运行的完整流程

  1. 用户请求阶段：
    • 用户通过kubectl提交Deployment创建请求
    • API Server接收请求并持久化到etcd
  2. 控制循环阶段：
    • Controller Manager检测并创建ReplicaSet
    • 确保实际Pod数量与期望状态一致
  3. 调度阶段：
    • Scheduler为Pod选择合适节点
    • 更新Pod的节点绑定信息
  4. 运行阶段：
    • 目标节点的kubelet创建容器
    • 容器运行时实际启动容器
    • 状态回馈到控制平面
  5. 网络配置阶段：
    • kube-proxy监听变化并更新网络规则
    • 建立Service到Pod的流量转发路径

Kubernetes通过这种松耦合的组件架构，实现了高度可扩展和灵活的容器编排能力，能够适应从开发测试到大规模生产环境的各种需求。