一、Kubernetes 网络模型与策略1.1 CNM 与 CNI 容器网络模型对比特性CNMContainer Network ModelCNIContainer Network Interface提出方DockerGoogle CoreOS最小单元容器Pod守护进程依赖依赖 dockerd不依赖任何守护进程分布式存储依赖外部 KV 数据库使用自身 KV 数据库灵活性被 Docker 绑定插件可随意替换CNM 三大组件Sandbox容器的网络栈network namespaceEndpoint连接 Sandbox 到 Networkveth pairNetwork一组 Endpoint 的集合Linux Bridge、VLAN 等CNI 核心概念CNI Plugin负责配置容器网络IPAM Plugin负责分配容器 IP 地址1.2 跨主机网络方案对比方案网络模型性能配置难度网络策略支持Flannel VxLANOverlay隧道封装较低简单否Flannel host-gwUnderlay路由转发较高简单否Calico BGPUnderlay三层路由最高中等✅ 强支持WeaveOverlayVxLAN较低中等有限MacvlanUnderlay二层最高中等依赖外部性能原则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支持操作符InNotInExistsDoesNotExistGtLt标签变更不影响已运行 PodpodAntiAffinity 典型场景podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:-labelSelector:matchExpressions:-key:appoperator:Invalues:[store]topologyKey:kubernetes.io/hostname确保同一 Deployment 的多个副本分散到不同节点。2.3 Taint污点与 Toleration容忍概念区分nodeAffinityPod 选 Node“女选男”TaintNode 选 Pod“男选女”污点操作命令# 添加污点kubectl taint nodes worker31CPUL1:NoSchedule# 移除污点kubectl taint nodes worker31 CPU:NoSchedule-Effect 三种类型Effect行为NoSchedule新 Pod 不会调度到该节点不影响已有 PodPreferNoSchedule尽量不调度软性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的容忍度默认tolerationSeconds300s。2.4 节点维护操作命令作用kubectl cordon node标记为不可调度SchedulingDisabled新 Pod 不再调度上来kubectl drain node驱逐节点上所有 Pod 标记不可调度需配合--ignore-daemonsetskubectl uncordon node恢复可调度状态三、HPA 弹性伸缩3.1 Metrics Server 部署# 下载并修改添加 --kubelet-insecure-tlswgethttps://github.com/kubernetes-sigs/metrics-server/releases/download/v0.7.1/components.yamlsed-i/metric-resolution/a\ - --kubelet-insecure-tlscomponents.yaml kubectl apply-fcomponents.yaml支持的指标采集kubectl top nodekubectl top pod3.2 HPA 核心参数参数默认值说明--horizontal-pod-autoscaler-sync-period15s指标拉取周期--horizontal-pod-autoscaler-initial-readiness-delay30sPod 启动“预热期”不参与计算--horizontal-pod-autoscaler-downscale-stabilization5min缩容冷却窗口扩容/缩容时序扩容每 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 ForbiddenapiVersion:v1kind:ResourceQuotametadata:name:myquotaspec:hard:pods:10requests.cpu:4requests.memory:8Gilimits.cpu:8limits.memory:16Gi4.2 LimitRange默认值与边界约束四类默认值defaultlimits 默认值defaultRequestrequests 默认值max最大值上限min最小值下限约束关系min ≤ defaultRequest ≤ default ≤ max行为规则场景结果未指定 resources使用default和defaultRequest仅指定 limitsrequests 自动等于 limits而非 defaultRequest仅指定 requestslimits 使用default指定值超出 min/max创建失败支持资源类型ContainerCPU、MemoryPodPod 内所有容器总和PersistentVolumeClaim存储大小创建LimitRange的命名空间即使没有ResourceQuota也会对 Pod 资源进行默认填充。五、健康检查Probes5.1 三种探针类型探针失败后行为用途LivenessProbe重启容器检测应用死锁/挂起ReadinessProbe从 Service Endpoints 中移除 Pod IP控制流量是否接入StartupProbe失败则重启等同于 Liveness慢启动应用成功前禁用其他探针5.2 四种检查方法方法成功条件httpGetHTTP 状态码 200-399exec命令退出码为 0tcpSocket端口能建立 TCP 连接grpcgRPC 健康检查返回 “SERVING”5.3 探针配置参数livenessProbe:initialDelaySeconds:5# 容器启动后多久开始探测periodSeconds:5# 探测周期timeoutSeconds:10# 超时时间successThreshold:1# 连续成功次数判定健康failureThreshold:3# 连续失败次数判定不健康5.4 健康检查的价值场景扩容Scale Up新 Pod 通过 Readiness 检测后才接入流量避免请求发送到未就绪的 Pod滚动更新Rolling Update新版本启动失败时旧版本不会被全部替换业务持续可用死锁恢复Liveness 探针可检测到死锁并自动重启六、认证与授权RBAC6.1 API 访问控制三阶段Authentication认证→ Authorization鉴权→ Admission Control准入控制认证验证客户端身份X509 证书、Token、Webhook 等鉴权判断是否有权执行操作RBAC/ABAC/Node/Webhook准入控制修改或拒绝请求如 LimitRanger、ResourceQuota6.2 用户类型类型说明普通用户User由外部认证系统管理证书、LDAP 等Kubernetes 内无对应资源对象服务账户ServiceAccountKubernetes API 管理绑定到特定命名空间可被 Pod 使用认证插件优先级服务账号令牌 → X509 客户端证书 → 静态令牌 → 启动引导令牌 → Webhook6.3 RBAC 四类资源资源范围说明Role命名空间级定义命名空间内的权限ClusterRole集群级定义集群范围的权限RoleBinding命名空间级将 Role 绑定到 User/Group/SAClusterRoleBinding集群级将 ClusterRole 绑定到 User/Group/SA6.4 预置 ClusterRole角色权限范围view几乎所有资源的 get/list/watch只读editview create/delete/patch/updateadmin命名空间内大部分资源的完全控制cluster-admin集群所有资源的完全控制6.5 创建用户与 kubeconfig步骤概览1. openssl genrsa -out user.key 2048 2. openssl req -new -key user.key -out user.csr -subj /CNusername/Ogroup 3. 管理员用 CA 签发证书openssl x509 -req -in user.csr -CA ca.crt -CAkey ca.key -out user.crt -days 365 4. 配置 kubeconfigset-cluster / set-credentials / set-context 5. 授权kubectl create clusterrolebinding user-role --clusterroleview --userusername重要理解Kubernetes不存储用户信息只存储 RBAC 绑定关系用户由外部认证系统X509、LDAP 等管理符合“Do One Thing and Do It Well”设计哲学删除 ClusterRoleBinding 即可回收权限删除证书/CA 黑名单可阻止登录6.6 ServiceAccount 与 Pod 身份默认行为每个命名空间有defaultServiceAccountPod 自动挂载 ServiceAccount Token 到/var/run/secrets/kubernetes.io/serviceaccount/Token 管理演进v1.22 前自动创建永久 Secret Tokenv1.22使用TokenRequest API生成绑定 Pod 生命周期的短期 Token默认 1h 过期创建带授权的 ServiceAccount# 1. 创建 SAkubectl create sa deployer# 2. 绑定 ClusterRolekubectl create clusterrolebinding deployer-binding \--clusterroleedit \--serviceaccountnamespace:deployer# 3. Pod 使用该 SAspec:serviceAccountName:deployer总结核心知识速查表模块关键命令/文件常见场景NetworkPolicykubectl get netpol微服务间访问控制调度nodeSelector/nodeAffinity/taint专用节点、GPU 节点HPAkubectl autoscale deployment应对流量高峰ResourceQuotakubectl create quota多租户资源隔离LimitRange设置default/max/min防止 Pod 资源申请不规范Health ChecklivenessProbe/readinessProbe滚动更新安全、死锁恢复RBACkubectl create role/clusterrole权限最小化控制最佳实践提示生产环境必配ResourceQuota LimitRange 健康检查至少 Liveness ReadinessHPA 搭配 PodDisruptionBudget 确保维护期间服务可用使用dry-run验证资源配置--dry-runclient -o yaml