Kubernetes 核心机制与运维实践知识精要
一、Kubernetes 网络模型与策略
1.1 CNM 与 CNI 容器网络模型对比
| 特性 | CNM（Container Network Model） | CNI（Container Network Interface） |
|---|---|---|
| 提出方 | Docker | Google + CoreOS |
| 最小单元 | 容器 | Pod |
| 守护进程依赖 | 依赖 dockerd | 不依赖任何守护进程 |
| 分布式存储 | 依赖外部 KV 数据库 | 使用自身 KV 数据库 |
| 灵活性 | 被 Docker 绑定 | 插件可随意替换 |
CNM 三大组件：
- Sandbox：容器的网络栈（network namespace）
- Endpoint：连接 Sandbox 到 Network（veth pair）
- Network：一组 Endpoint 的集合（Linux Bridge、VLAN 等）
CNI 核心概念：
- CNI Plugin：负责配置容器网络
- IPAM Plugin：负责分配容器 IP 地址
1.2 跨主机网络方案对比
| 方案 | 网络模型 | 性能 | 配置难度 | 网络策略支持 |
|---|---|---|---|---|
| Flannel VxLAN | Overlay（隧道封装） | 较低 | 简单 | 否 |
| Flannel host-gw | Underlay（路由转发） | 较高 | 简单 | 否 |
| Calico BGP | Underlay（三层路由） | 最高 | 中等 | ✅ 强支持 |
| Weave | Overlay（VxLAN） | 较低 | 中等 | 有限 |
| Macvlan | Underlay（二层） | 最高 | 中等 | 依赖外部 |
性能原则：Underlay 网络 > Overlay 网络（Overlay 存在额外封装/解封开销）
1.3 NetworkPolicy 实战要点
核心字段结构：
spec:podSelector:# 选择策略生效的 PodpolicyTypes:# Ingress / Egressingress:# 入站规则-from:# 来源：ipBlock / namespaceSelector / podSelectorports:egress:# 出站规则-to:# 目标：ipBlock / namespaceSelector / podSelectorports:选择器四种类型：
podSelector：同命名空间内选择特定 PodnamespaceSelector：选择特定命名空间的所有 PodnamespaceSelector + podSelector：特定命名空间中的特定 Pod（交集）ipBlock：选择特定 IP CIDR 范围（用于集群外部 IP）
默认策略模板：
| 策略 | 配置方式 |
|---|---|
| 允许所有入站 | ingress: [{}] |
| 拒绝所有入站 | 仅声明policyTypes: [Ingress]，无ingress规则 |
| 允许所有出站 | egress: [{}] |
| 拒绝所有出站 | 仅声明policyTypes: [Egress]，无egress规则 |
| 完全隔离 | policyTypes: [Ingress, Egress]，无具体规则 |
⚠️ 不能完成的工作：
- 特定于节点的策略
- 显式拒绝策略（模型默认是 deny，只能添加 allow）
- 禁止本地回路（localhost）或指向宿主的流量
二、Pod 调度控制
2.1 调度流程
过滤（Filtering）→ 评分（Scoring）→ 绑定（Binding）- 过滤：筛选满足 Pod 资源请求、端口、节点选择器等条件的节点
- 评分：对通过过滤的节点按优先级打分，选择最高分节点（随机平局）
2.2 四种调度约束方式
| 方式 | 说明 | 适用场景 |
|---|---|---|
nodeName | 直接指定节点名 | 调试/测试，优先级最高 |
nodeSelector | 基于节点标签匹配 | 简单场景（如 SSD 节点） |
nodeAffinity | 支持软/硬亲和性（requiredDuringScheduling/preferredDuringScheduling） | 灵活调度策略 |
podAffinity/AntiAffinity | 基于已有 Pod 标签调度 | 就近部署/分散部署 |
nodeAffinity 关键特性：
requiredDuringSchedulingIgnoredDuringExecution：必须满足（硬约束）preferredDuringSchedulingIgnoredDuringExecution：优先满足（软约束，带 weight 1-100）- 支持操作符：
In，NotIn，Exists，DoesNotExist，Gt，Lt - 标签变更不影响已运行 Pod
podAntiAffinity 典型场景：
podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:-labelSelector:matchExpressions:-key:appoperator:Invalues:[store]topologyKey:"kubernetes.io/hostname"确保同一 Deployment 的多个副本分散到不同节点。
2.3 Taint（污点）与 Toleration（容忍）
概念区分：
nodeAffinity：Pod 选 Node（“女选男”）Taint：Node 选 Pod（“男选女”）
污点操作命令：
# 添加污点kubectl taint nodes worker31CPU=L1:NoSchedule# 移除污点kubectl taint nodes worker31 CPU:NoSchedule-Effect 三种类型：
| Effect | 行为 |
|---|---|
NoSchedule | 新 Pod 不会调度到该节点（不影响已有 Pod） |
PreferNoSchedule | 尽量不调度（软性） |
NoExecute | 不能容忍则立即驱逐已有 Pod；可配合tolerationSeconds设置宽限期 |
自动添加的节点污点：
node.kubernetes.io/not-ready：节点未就绪node.kubernetes.io/unreachable：节点不可达node.kubernetes.io/memory-pressure：内存压力node.kubernetes.io/disk-pressure：磁盘压力
Kubernetes 自动为 Pod 添加
not-ready和unreachable的容忍度，默认tolerationSeconds=300s。
2.4 节点维护操作
| 命令 | 作用 |
|---|---|
kubectl cordon <node> | 标记为不可调度（SchedulingDisabled），新 Pod 不再调度上来 |
kubectl drain <node> | 驱逐节点上所有 Pod + 标记不可调度（需配合--ignore-daemonsets） |
kubectl uncordon <node> | 恢复可调度状态 |
三、HPA 弹性伸缩
3.1 Metrics Server 部署
# 下载并修改（添加 --kubelet-insecure-tls）wgethttps://github.com/kubernetes-sigs/metrics-server/releases/download/v0.7.1/components.yamlsed-i'/metric-resolution/a\ - --kubelet-insecure-tls'components.yaml kubectl apply-fcomponents.yaml支持的指标采集：
kubectl top nodekubectl top pod
3.2 HPA 核心参数
| 参数 | 默认值 | 说明 |
|---|---|---|
--horizontal-pod-autoscaler-sync-period | 15s | 指标拉取周期 |
--horizontal-pod-autoscaler-initial-readiness-delay | 30s | Pod 启动“预热期”，不参与计算 |
--horizontal-pod-autoscaler-downscale-stabilization | 5min | 缩容冷却窗口 |
扩容/缩容时序：
- 扩容：每 15s 采样 → 超过阈值 → 扩容动作 → 45s 冷却后再次扩容
- 缩容：需保持5 分钟低于阈值才触发缩容
⚠️ HPA 要求 Pod 必须设置
resources.limits才能正确计算 CPU/Memory 使用率。
3.3 HPA vs VPA 对比
| 维度 | HPA（横向） | VPA（纵向） |
|---|---|---|
| 扩缩方式 | 增减 Pod 副本数 | 调整 Pod 的 requests/limits |
| 是否重启 | ❌ 不重启 | ✅ 需要重启 Pod |
| 适用场景 | 流量波动大的无状态服务 | 资源配置不合理的长期服务 |
| 生产使用 | 非常普遍 | 较少 |
| 共存性 | — | 不可与 HPA 同时开启 |
四、资源配额与限制
4.1 ResourceQuota（命名空间级配额）
配额类型：
- 对象数量配额：pods、services、secrets、configmaps、PVCs、deployments 等
- 计算资源配额：
requests.cpu、requests.memory、limits.cpu、limits.memory
关键行为：
- 如果命名空间启用了 CPU/Memory 配额，则创建 Pod必须指定 requests 和 limits
- 配额是硬性限制，超限则返回
403 Forbidden
apiVersion:v1kind:ResourceQuotametadata:name:myquotaspec:hard:pods:"10"requests.cpu:"4"requests.memory:"8Gi"limits.cpu:"8"limits.memory:"16Gi"4.2 LimitRange（默认值与边界约束）
四类默认值：
default：limits 默认值defaultRequest：requests 默认值max：最大值上限min：最小值下限
约束关系：min ≤ defaultRequest ≤ default ≤ max
行为规则：
| 场景 | 结果 |
|---|---|
| 未指定 resources | 使用default和defaultRequest |
| 仅指定 limits | requests 自动等于 limits（而非 defaultRequest） |
| 仅指定 requests | limits 使用default |
| 指定值超出 min/max | 创建失败 |
支持资源类型：
Container：CPU、MemoryPod：Pod 内所有容器总和PersistentVolumeClaim：存储大小
创建
LimitRange的命名空间，即使没有ResourceQuota，也会对 Pod 资源进行默认填充。
五、健康检查（Probes）
5.1 三种探针类型
| 探针 | 失败后行为 | 用途 |
|---|---|---|
| LivenessProbe | 重启容器 | 检测应用死锁/挂起 |
| ReadinessProbe | 从 Service Endpoints 中移除 Pod IP | 控制流量是否接入 |
| StartupProbe | 失败则重启（等同于 Liveness） | 慢启动应用，成功前禁用其他探针 |
5.2 四种检查方法
| 方法 | 成功条件 |
|---|---|
httpGet | HTTP 状态码 200-399 |
exec | 命令退出码为 0 |
tcpSocket | 端口能建立 TCP 连接 |
grpc | gRPC 健康检查返回 “SERVING” |
5.3 探针配置参数
livenessProbe:initialDelaySeconds:5# 容器启动后多久开始探测periodSeconds:5# 探测周期timeoutSeconds:10# 超时时间successThreshold:1# 连续成功次数（判定健康）failureThreshold:3# 连续失败次数（判定不健康）5.4 健康检查的价值场景
- 扩容（Scale Up）：新 Pod 通过 Readiness 检测后才接入流量，避免请求发送到未就绪的 Pod
- 滚动更新（Rolling Update）：新版本启动失败时，旧版本不会被全部替换，业务持续可用
- 死锁恢复：Liveness 探针可检测到死锁并自动重启
六、认证与授权（RBAC）
6.1 API 访问控制三阶段
Authentication（认证）→ Authorization（鉴权）→ Admission Control（准入控制）- 认证：验证客户端身份（X509 证书、Token、Webhook 等）
- 鉴权：判断是否有权执行操作（RBAC/ABAC/Node/Webhook）
- 准入控制：修改或拒绝请求（如 LimitRanger、ResourceQuota）
6.2 用户类型
| 类型 | 说明 |
|---|---|
| 普通用户（User） | 由外部认证系统管理（证书、LDAP 等），Kubernetes 内无对应资源对象 |
| 服务账户（ServiceAccount） | Kubernetes API 管理，绑定到特定命名空间，可被 Pod 使用 |
认证插件优先级：服务账号令牌 → X509 客户端证书 → 静态令牌 → 启动引导令牌 → Webhook
6.3 RBAC 四类资源
| 资源 | 范围 | 说明 |
|---|---|---|
| Role | 命名空间级 | 定义命名空间内的权限 |
| ClusterRole | 集群级 | 定义集群范围的权限 |
| RoleBinding | 命名空间级 | 将 Role 绑定到 User/Group/SA |
| ClusterRoleBinding | 集群级 | 将 ClusterRole 绑定到 User/Group/SA |
6.4 预置 ClusterRole
| 角色 | 权限范围 |
|---|---|
view | 几乎所有资源的 get/list/watch（只读） |
edit | view + create/delete/patch/update |
admin | 命名空间内大部分资源的完全控制 |
cluster-admin | 集群所有资源的完全控制 |
6.5 创建用户与 kubeconfig
步骤概览：
1. openssl genrsa -out user.key 2048 2. openssl req -new -key user.key -out user.csr -subj "/CN=username/O=group" 3. 管理员用 CA 签发证书：openssl x509 -req -in user.csr -CA ca.crt -CAkey ca.key -out user.crt -days 365 4. 配置 kubeconfig：set-cluster / set-credentials / set-context 5. 授权：kubectl create clusterrolebinding user-role --clusterrole=view --user=username重要理解：
- Kubernetes不存储用户信息，只存储 RBAC 绑定关系
- 用户由外部认证系统（X509、LDAP 等）管理，符合“Do One Thing and Do It Well”设计哲学
- 删除 ClusterRoleBinding 即可回收权限；删除证书/CA 黑名单可阻止登录
6.6 ServiceAccount 与 Pod 身份
默认行为：
- 每个命名空间有
defaultServiceAccount - Pod 自动挂载 ServiceAccount Token 到
/var/run/secrets/kubernetes.io/serviceaccount/
Token 管理演进：
- v1.22 前：自动创建永久 Secret Token
- v1.22+：使用TokenRequest API生成绑定 Pod 生命周期的短期 Token（默认 1h 过期）
创建带授权的 ServiceAccount：
# 1. 创建 SAkubectl create sa deployer# 2. 绑定 ClusterRolekubectl create clusterrolebinding deployer-binding \--clusterrole=edit \--serviceaccount=namespace:deployer# 3. Pod 使用该 SAspec:serviceAccountName:deployer总结：核心知识速查表
| 模块 | 关键命令/文件 | 常见场景 |
|---|---|---|
| NetworkPolicy | kubectl get netpol | 微服务间访问控制 |
| 调度 | nodeSelector/nodeAffinity/taint | 专用节点、GPU 节点 |
| HPA | kubectl autoscale deployment | 应对流量高峰 |
| ResourceQuota | kubectl create quota | 多租户资源隔离 |
| LimitRange | 设置default/max/min | 防止 Pod 资源申请不规范 |
| Health Check | livenessProbe/readinessProbe | 滚动更新安全、死锁恢复 |
| RBAC | kubectl create role/clusterrole | 权限最小化控制 |
📌最佳实践提示：
- 生产环境必配：ResourceQuota + LimitRange + 健康检查（至少 Liveness + Readiness）
- HPA 搭配 PodDisruptionBudget 确保维护期间服务可用
- 使用dry-run验证资源配置：
--dry-run=client -o yaml