Kubernetes 入门学习笔记
Kubernetes 入门学习笔记
Kubernetes(简称 K8S)是当今容器编排领域的事实标准。它能够自动化部署、扩展和管理容器化应用,是云原生技术栈的核心组件。对于后端开发和运维人员来说,理解 K8S 的基本架构和工作负载类型是迈向云原生的重要一步。本文将从宏观架构到微观组件,带你系统了解 Kubernetes 的核心概念。
[图片占位符:Kubernetes 集群整体架构图]
一、K8S 集群架构
一个 Kubernetes 集群由一组被称为**节点(Node)**的机器组成,这些节点上运行着 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点,而 Master 节点本身也可以同时作为 Worker 节点使用。
简单来说:
- Master 节点:负责集群调度和控制,运行控制平面(Control Plane)
- Worker 节点:负责运行业务 Pod
这种架构类似于一个公司的管理层和执行层:Master 节点负责决策和调度,Worker 节点负责实际执行任务。
[图片占位符:Master 节点与 Worker 节点关系图]
二、Master 节点(控制平面)组件
Master 节点是整个集群的大脑,它由以下四个核心组件构成:
2.1 kube-apiserver
API Server 是 Kubernetes 控制平面的前端,也是集群的统一入口。所有的管理操作(无论是通过 kubectl 命令行、Web 界面还是其他客户端)都需要通过 API Server 来完成。
核心职责:
- 提供 RESTful API 接口
- 认证、授权和准入控制
- 所有组件之间的通信枢纽
- 是唯一与 etcd 直接交互的组件
可以把 API Server 理解为 Kubernetes 的"前台",所有请求都要先到前台登记处理。
2.2 etcd
etcd 是一个兼具一致性和高可用性的键值数据库,用来保存 Kubernetes 集群的所有数据,包括:
- 集群配置信息
- 节点状态
- Pod 定义和状态
- Service 和路由信息
- Secret 和 ConfigMap
关键特性:
- 使用 Raft 一致性算法保证数据一致性
- 生产环境通常部署 3 个或 5 个节点组成集群
- 是整个集群的唯一数据存储后端
etcd 相当于 Kubernetes 的"数据库",集群中的所有状态信息都存储在这里。etcd 的数据安全直接关系到整个集群的安全。
2.3 kube-scheduler
Scheduler 负责监视新创建的、未指定运行节点的 Pod,并为他们选择合适的节点运行。
调度决策考虑因素:
- 资源需求(CPU、内存)
- 硬件/软件/策略约束
- 亲和性和反亲和性规则
- 数据本地性需求
- 服务间的负载均衡
调度过程可以简化为两步:
- 过滤:找出所有满足 Pod 运行条件的节点
- 打分:对满足条件的节点按优先级打分,选择分数最高的节点
2.4 kube-controller-manager
Controller Manager 是运行控制器进程的控制平面组件。虽然从逻辑上讲每个控制器都是一个单独的进程,但为了降低复杂性,它们都被编译到同一个可执行文件中,在一个进程中运行。
主要控制器包括:
| 控制器 | 职责 |
|---|---|
| 节点控制器(Node Controller) | 节点出现故障时进行通知和响应 |
| 任务控制器(Job Controller) | 监测 Job 对象,创建 Pod 运行一次性任务 |
| 端点控制器(Endpoints Controller) | 填充 Endpoints 对象,关联 Service 与 Pod |
| 服务账户控制器(Service Account Controller) | 为新命名空间创建默认账户和 API 访问令牌 |
| 副本控制器(ReplicaSet Controller) | 维护 Pod 的副本数量 |
控制器的核心工作模式是控制循环:不断观察集群的实际状态,与期望状态进行对比,如果不一致就采取措施使其趋向一致。
[图片占位符:控制平面四大组件协作流程图]
三、Node 节点组件(Worker 节点)
Worker 节点是实际运行业务容器的地方。Master 节点本身也拥有这些组件,只是它主要运行业务 Pod 以外的控制平面 Pod。
3.1 kubelet
kubelet 是运行在每个节点上的代理程序,它保证容器都运行在 Pod 中。
核心职责:
- 接收 PodSpecs(通过各种机制提供),确保其中描述的容器处于运行状态且健康
- 向 Master 节点汇报节点状态
- 执行健康检查和存活探测
- 挂载存储卷
- 不会管理非 Kubernetes 创建的容器
kubelet 可以理解为节点上的"管家",它忠实地执行 Master 下达的指令。
3.2 kube-proxy
kube-proxy 是集群中每个节点上运行的网络代理,是实现 Kubernetes Service 概念的重要组件。
核心职责:
- 维护节点上的网络规则
- 允许从集群内部或外部的网络会话与 Pod 进行网络通信
- 如果操作系统提供了数据包过滤层并可用的话,kube-proxy 会通过它来实现网络规则
- 否则 kube-proxy 仅转发流量本身
kube-proxy 支持三种代理模式:
- iptables(默认):使用 iptables 规则进行流量转发
- IPVS:使用 IPVS(IP Virtual Server)进行负载均衡,性能更好
- userspace:最老的模式,性能较差,基本已弃用
3.3 容器运行时(Container Runtime)
容器运行时是负责运行容器的软件。Kubernetes 支持多种容器运行时:
| 运行时 | 说明 |
|---|---|
| Docker | 最广为人知的容器运行时,K8S 1.24 后不再直接支持,需通过 containerd |
| containerd | 从 Docker 中剥离出来的容器运行时,轻量高效 |
| CRI-O | 专门为 Kubernetes 设计的容器运行时 |
Kubernetes 通过 CRI(容器运行时接口)与容器运行时交互,使得用户可以根据需求选择不同的运行时实现。
[图片占位符:Worker 节点三大组件工作原理图]
四、集群插件(Addons)
插件使用 Kubernetes 资源(DaemonSet、Deployment 等)实现集群级别的功能。插件中命名空间域的资源属于kube-system命名空间。
4.1 DNS(必需)
几乎所有 Kubernetes 集群都应该有集群 DNS。它为 Kubernetes 服务提供 DNS 记录,Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。
容器中的应用可以通过服务名称而非 IP 地址来访问其他服务,这大大简化了服务发现和通信。
4.2 Web 界面(Dashboard)
Dashboard 是 Kubernetes 集群的通用 Web 用户界面,用户可以:
- 管理集群中运行的应用程序
- 进行故障排除
- 管理集群本身的配置
4.3 容器资源监控
容器资源监控将关于容器的一些常见时间序列度量值保存到集中的数据库中,并提供用于浏览这些数据的界面。
4.4 集群层面日志
集群层面日志机制负责将容器的日志数据保存到集中的日志存储中,提供搜索和浏览接口。
五、工作负载类型
Kubernetes 提供了多种内置的工作负载资源,适用于不同的应用场景。
5.1 Deployment
Deployment 是最常用的工作负载类型,适合管理无状态应用。
核心特点:
- 所有 Pod 都是相互等价的,可以在需要时被换掉
- 声明式地管理 Pod 和 ReplicaSet
- 支持滚动更新和回滚
- 支持扩缩容
apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentspec:replicas:3selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-name:nginximage:nginx:1.14.2ports:-containerPort:80典型场景:Web 服务器、API 服务、微服务等。
5.2 StatefulSet
StatefulSet 适合运行需要跟踪应用状态的 Pods,例如数据库、消息队列等。
核心特点:
- 每个 Pod 有稳定、唯一的网络标识符
- Pod 的启动和终止是有序的
- 每个 Pod 可以有独立的持久化存储(PersistentVolume)
- Pod 之间可以相互复制数据以提高可靠性
典型场景:MySQL 主从集群、ZooKeeper 集群、Kafka 集群等有状态服务。
5.3 DaemonSet
DaemonSet 确保每个(或某些)节点上运行一个 Pod 的副本。
核心特点:
- 每当向集群中添加新节点时,如果节点匹配 DaemonSet 的规约,就会调度一个 Pod 到该节点上运行
- 当节点从集群中移除时,Pod 会被回收
- 删除 DaemonSet 将清理它创建的所有 Pod
典型场景:
- 日志收集代理(如 Filebeat)
- 节点监控代理(如 Prometheus Node Exporter)
- 网络插件(如 Calico、Flannel)
- 存储守护进程
5.4 Job
Job 用于运行一次性任务,任务完成后 Pod 就会停止。
核心特点:
- 创建一个或多个 Pod,确保指定数量的 Pod 成功完成
- 成功完成的 Pod 不会被重新调度
- 可以设置重试策略和超时时间
apiVersion:batch/v1kind:Jobmetadata:name:data-migrationspec:template:spec:containers:-name:migrationimage:my-app:latestcommand:["python","migrate.py"]restartPolicy:NeverbackoffLimit:4典型场景:数据迁移、批量处理、系统初始化等一次性任务。
5.5 CronJob
CronJob 类似于 Linux 的 crontab,用于定时执行任务。
核心特点:
- 根据时间计划反复创建 Job
- 使用 Cron 格式的时间表达式
- 可以设置并发策略和历史限制
apiVersion:batch/v1kind:CronJobmetadata:name:daily-backupspec:schedule:"0 2 * * *"# 每天凌晨2点执行jobTemplate:spec:template:spec:containers:-name:backupimage:backup-tool:latestcommand:["./backup.sh"]restartPolicy:OnFailure典型场景:定时备份、定期清理、报表生成等周期性任务。
5.6 工作负载类型对比
| 类型 | 生命周期 | 状态管理 | 调度方式 | 典型场景 |
|---|---|---|---|---|
| Deployment | 持续运行 | 无状态 | 随机调度 | Web 服务、API |
| StatefulSet | 持续运行 | 有状态 | 有序调度 | 数据库、消息队列 |
| DaemonSet | 持续运行 | 节点级 | 每节点一个 | 日志、监控代理 |
| Job | 一次性 | 无 | 随机 | 数据迁移 |
| CronJob | 定时重复 | 无 | 随机 | 定时备份 |
[图片占位符:五种工作负载类型对比与选择决策树]
六、服务发现与网络基础
6.1 Service
在 Kubernetes 中,Pod 的 IP 地址不是固定的(Pod 可能会被销毁重建),因此需要 Service 来提供一个稳定的访问入口。
Service 定义了一个 Pod 的逻辑集合以及访问它们的策略。主要通过Label Selector来确定哪些 Pod 属于该 Service。
Service 类型:
| 类型 | 说明 |
|---|---|
| ClusterIP | 集群内部访问(默认) |
| NodePort | 通过节点端口暴露服务 |
| LoadBalancer | 使用云厂商的负载均衡器 |
| ExternalName | 映射到外部 DNS 名称 |
6.2 Label 与 Selector
Label 是附加在 Kubernetes 对象上的键值对,用于组织和选择对象。Selector 则用于通过 Label 筛选对象。
# Pod 定义中的 Labelmetadata:labels:app:nginxtier:frontend# Service 中的 Selectorspec:selector:matchLabels:app:nginx重要提示:当定义一个对象作用于另一个对象时,需要在 Selector 中引用目标对象的 Label 内容。
6.3 网络模型
Kubernetes 的网络模型有以下基本要求:
- 所有 Pod 之间可以直接通信,不需要 NAT
- 所有 Node 与所有 Pod 之间可以直接通信,不需要 NAT
- Pod 看到自己的 IP 与其他 Pod 看到它的 IP 是一致的
常见的网络插件(CNI)有:Calico、Flannel、Weave、Cilium 等。
[图片占位符:Kubernetes 网络模型示意图]
七、扩展与第三方工作负载
在庞大的 Kubernetes 生态系统中,除了内置的工作负载资源外,还可以通过**自定义资源定义(CRD)**添加第三方工作负载资源。
例如,如果你需要运行一组 Pod,但要求所有 Pod 都就绪后才执行操作(如高吞吐量的分布式任务),可以通过 CRD 实现相应的扩展并安装到集群中运行。
这种可扩展性是 Kubernetes 成为容器编排领域标准的重要原因之一。
八、学习路线建议
对于 K8S 初学者,建议按以下路线循序渐进:
- 入门阶段:理解集群架构、核心组件、Pod/Deployment/Service 基本概念
- 实践阶段:搭建本地集群(minikube/kind),部署第一个应用
- 进阶阶段:学习网络、存储、安全、Helm 包管理
- 生产阶段:高可用部署、监控告警、日志收集、故障排查
[图片占位符:K8S 学习路线图]
九、总结
Kubernetes 的核心架构可以概括为:
- 一个大脑:Master 节点的控制平面(API Server + etcd + Scheduler + Controller Manager)
- 一双腿脚:Worker 节点(kubelet + kube-proxy + 容器运行时)
- 五种武器:Deployment、StatefulSet、DaemonSet、Job、CronJob
- 一座桥梁:Service 实现服务发现与负载均衡
理解了这些核心概念,就掌握了 Kubernetes 的骨架。后续可以在实践中逐步深入网络策略、存储编排、自动扩缩容、安全策略等高级主题。
来源:整理自 zyh/K8S学习笔记.MD 学习笔记
