深入解析：K8S RD: Kubernetes运维核心指南：污点调度、网络架构与全链路故障排查实战

污点（Taint）与容忍度（Toleration）

污点（Taint） 用于在 Node 节点 上标记排斥策略，阻止不符合条件的 Pod 调度到该节点，核心作用是实现节点分组管理。例如：若需禁止某类 Pod 部署到特定节点，可在目标 Node 上添加污点标签。

污点容忍度（Toleration） 允许 Pod 被调度到含污点的 Node 节点，需与污点配合使用。典型场景：当特定 Pod（如专用硬件依赖型应用）必须部署到含污点的节点时，需为 Pod 配置容忍度声明。

作用与协同机制

• 污点：标记节点以阻止非常定Pod调度，实现节点分组管理（如专用硬件节点）。

  # 语法
  kubectl taint nodes <node-name> key=value:effect# 示例kubectl taint nodes node1 key=value:NoSchedule  # 添加污点 

• 容忍度：允许特定Pod调度到含污点的节点（如日志采集服务）。
• 容忍度需在 Pod 的 YAML 中定义 tolerations 字段，匹配污点的键值对。

  tolerations:
  - key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

• 容忍度需在 Pod 的 YAML 中定义 tolerations 字段，匹配污点的键值对。

技术逻辑：节点打污点 → Pod配置匹配容忍度 → Pod可调度至目标节点。

Service的四种类型

类型	作用	适用场景
ClusterIP	分配虚拟IP供集群内部访问，提供负载均衡（默认类型）	集群内服务通信
NodePort	通过节点IP+端口（30000-32767）暴露服务	外部访问集群应用
LoadBalancer	由云厂商创建外部负载均衡器转发请求（NodePort升级版）	公有云环境
ExternalName	将Service映射到外部域名（如www.baidu.com）	集群内访问外部服务

• ClusterIP（默认类型）

  • 分配虚拟 IP 作为集群内部统一入口，提供负载均衡能力。
  • 仅限集群内部访问，不暴露到外部网络。

• NodePort

  • 通过 Node 节点的 IP + 端口 暴露服务，支持外部客户端访问。
  • 流量路径：外部请求 → NodeIP:Port → Service → 后端 Pod。

• LoadBalancer

  • NodePort 的扩展，依赖云厂商创建外部负载均衡器，将流量转发至 NodePort。
  • 仅适用于公有云环境（如 AWS ALB、GCP Load Balancer）。

• ExternalName

  • 将 Service 名称映射到集群外部域名，实现集群内服务访问外部资源。
  • 例：集群内访问 k8s-svc 自动解析为 www.external.com。

ExternalName配置示例：

apiVersion: v1
kind: Service
metadata:
name: k8s-external-svc
spec:
type: ExternalName
externalName: www.kubernetes.io

• 集群内访问 k8s-external-svc 将解析到 www.kubernetes.io。
• 支持场景：绑定外部域名或跨命名空间的内部域名。

Service代理模式

模式	技术原理	特点
iptables	基于Linux内核防火墙规则	默认模式，适合中小规模集群
IPVS	基于LVS负载均衡技术，支持轮询算法	高性能，适合大规模集群

Kubernetes服务暴露方式

1. NodePort
   • 直接通过节点IP和端口暴露服务。
2. LoadBalancer
   • 依赖云厂商创建外部负载均衡器（如AWS ELB），云厂商提供负载均衡器（需公有云支持）
3. Ingress

• 基于域名和路径的七层代理，分流到不同 Service（如 example.com/app1 → app1-svc）
• 基于域名/路径的七层代理（需Ingress Controller如Nginx）

Prometheus监控组件

组件	功能
Alertmanager	接收告警并推送至邮件/钉钉/微信，需配置Webhook地址
Exporters	采集资源数据（NodeExporter采集节点指标，MySQLExporter采集数据库指标）
Prometheus Server	核心组件，集成cAdvisor采集容器指标，关联Exporter和Alertmanager
kube-state-metrics	监控Kubernetes资源对象状态（如Pod/Deployment）
Grafana	可视化监控数据，数据源指向Prometheus

工作流：
Exporters 采集数据 → Prometheus 聚合 → Alertmanager 触发告警 → Grafana 展示

Prometheus 关联 Alertmanager 配置片段
alerting:
alertmanagers:
- static_configs:
- targets: ['alertmanager:9093']  # Alertmanager 服务地址 

钉钉告警配置流程：

1. 创建钉钉机器人获取Webhook地址。
2. 部署prometheus-webhook-dingtalk服务并配置Webhook。
3. Alertmanager配置指向该服务地址：

   alerting:
   alertmanagers:
   - static_configs:
   - targets: ['webhook-dingtalk:8060']  # 钉钉服务地址 

Pod常见状态及排查

状态	原因	排查措施
Pending	资源不足、污点未容忍、亲和性冲突	检查节点资源/污点/标签匹配
ContainerCreating	节点故障、网络异常、存储卷挂载失败	验证节点状态/网络连通性/PVC配置
ImagePullBackOff	镜像名错误、仓库认证失败、网络超时	检查镜像名/Secret配置/网络连通性
CrashLoopBackOff	容器进程崩溃、配置错误	查看容器日志/资源限制/启动命令
Error	依赖资源缺失（ConfigMap/Secret未创建）	校验关联资源是否存在
Terminating	容器异常退出或手动删除中	检查应用日志或kubectl describe pod
Unknown	节点失联	修复节点网络或kubelet服务

故障节点处理流程

1 ） 驱逐Pod：

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

• 将节点上的 Pod 迁移至其他节点，确保服务不中断。

2 ） 重置节点：

kubeadm reset
systemctl stop kubelet docker
rm -rf /etc/cni/net.d /var/lib/kubelet/* /var/lib/etcd
ip link delete cni0  # 清理网络接口 

节点维护：

• 停止服务：systemctl stop kubelet docker
• 清理文件：删除 /var/lib/kubelet、CNI 配置及旧网络接口。

3 ）重新加入集群：

kubeadm reset
systemctl start docker
kubeadm join <master-ip>:<port> --token <token># 或kubeadm join <master-ip>:6443 --token <token> --discovery-token-ca-cert-hash <hash>

健康检查探针类型

探针类型	检测方式	成功条件
HTTP GET	发送HTTP请求到容器端口	返回2xx/3xx状态码
TCP Socket	尝试建立TCP连接	端口可连通
Exec	在容器内执行命令	命令退出码为0

HTTP GET探针示例：

livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15  # 容器启动后等待时间 
periodSeconds: 5         # 检查频率 

Kubernetes网络通信模型

1. 同一Pod内容器通信
   • 通过localhost和共享网络命名空间直接通信。
2. Pod间通信
   • 跨节点依赖CNI插件（如Flannel/Calico）提供 overlay 网络，分配IP并路由。
   • 同节点：通过 CNI 网桥（如 docker0）。
   • 跨节点：通过 Overlay 网络（如 Flannel VXLAN）。
3. Pod与Service通信
   • 通过ClusterIP负载均衡到后端Pod
   • 通过 ClusterIP 经 iptables/IPVS 转发
4. 外部访问通信
   • 使用NodePort/LoadBalancer/Ingress暴露服务。

网络插件对比

插件	特点	适用场景
Flannel	提供Overlay网络（VXLAN/Host-GW模式）	简单网络环境
Calico	支持网络策略（NetworkPolicy）、BGP路由	需安全隔离的场景
Canal	Flannel+Calico组合	平衡性能与安全性

Flannel模式差异：

• VXLAN：
  • 叠加网络，通过 flannel.1 虚拟网卡跨节点通信。
  • 通用性强，通过叠加网络封装跨节点流量。
• Host-GW：
  • 宿主机作网关，性能更高（需节点间二层互通）。

网络超时排查步骤：

1. 检查 CNI 插件状态：kubectl get pods -n kube-system
2. 验证 Pod 网段与宿主机网段是否重叠（需隔离）。
3. 跨节点通信测试：kubectl exec <pod> ping <目标 Pod IP>
4. 抓包分析：tcpdump -i eth0 port 80

Pod网络故障排查

故障类型	排查方法
Pod间通信超时	检查CNI插件状态/节点路由表/网段冲突（ip route show）
Pod与宿主机通信失败	验证宿主机防火墙/网桥配置（brctl show）
Pod无法访问外网	检测NAT配置/DNS解析（nslookup）/抓包分析（tcpdump -i eth0 port 53）
Service访问超时	确认宿主机开启IP转发（sysctl net.ipv4.ip_forward=1）

Pod间通信超时

• 检查CNI插件状态（kubectl get pods -n kube-system）。
• 确认Pod网段与宿主机网段无重叠。

Pod 访问外网超时：

• 排查宿主机网络和 DNS：
  bash kubectl exec <pod-name> -- ping 8.8.8.8 # 测试外网连通性 kubectl exec <pod-name> -- nslookup baidu.com # 检查 DNS 解析 kubectl exec <pod> -- tcpdump -i eth0 host www.baidu.com #抓包分析
  * 宿主机网络测试：ping 8.8.8.8
  * Pod内DNS测试：nslookup www.baidu.com
• 抓包分析：tcpdump -i eth0 -n host <目标IP>

访问 Pod/Service IP 超时处理

• 关键步骤：启用宿主机 IP 转发：

  sysctl net.ipv4.ip_forward=1

• 验证 iptables/IPVS 规则是否生效：

  iptables -t nat -L KUBE-SERVICES  # 查看 Service 规则 
  ipvsadm -Ln                      # 检查 IPVS 转发表 

Pod 生命周期核心阶段

Pending → ContainerCreating → Running → Terminating

1. Pending：调度中（等待资源分配）。
2. Running：容器正常运行。
3. Terminating：删除中（执行preStop钩子）。

Pod状态正常但应用异常的原因

1. 端口映射错误：Service的targetPort与容器监听端口不匹配
2. 应用逻辑缺陷：代码异常或未处理依赖（需结合日志排查）
3. 依赖服务故障：数据库/配置中心不可用（验证Endpoint连通性）
4. 内存泄漏/OOM：
   • 监控容器内存使用（kubectl top pod），策略阻止通信或 DNS 解析失败，进程僵死但容器状态未更新
   • OOM 导致进程僵死（检查 kubectl describe pod 的 OOMKilled 事件）
5. 网络策略限制：NetworkPolicy阻断流量
6. 环境变量错误：配置值不合法

CoreDNS故障排查

1 ) 资源检查：

CPU/内存是否耗尽：top 或 kubectl top pods

kubectl top pods -n kube-system  # 确认CPU/内存是否耗尽 

2 ) 日志分析：

kubectl logs -n kube-system <coredns-pod># 或kubectl logs -f <coredns-pod> -n kube-system

3 ) 网络验证：

• 测试节点间互通：ping <目标节点IP> 或 traceroute
• DNS解析测试：

  kubectl exec <test-pod> -- nslookup kubernetes.default.svc.cluster.local

• DNS 流量分析：tcpdump -i eth0 port 53

4 ）依赖项检查：

• 确认 etcd/Kubernetes API 服务正常

5 ) 配置校验：

kubectl get configmap/coredns -n kube-system -o yaml  # 检查Corefile 

6 ）安全策略：

• 检查 NetworkPolicy 或防火墙是否拦截 DNS 流量（默认 UDP 53）

节点NotReady状态处理

场景	原因	解决方案
新集群节点NotReady	CNI网络插件未安装	部署Flannel/Calico
运行中节点异常	资源耗尽（CPU/内存/磁盘）	清理资源或扩容节点
	kubelet故障	systemctl restart kubelet
通用检查	查看详细事件	kubectl describe node <node-name>

1. 初始部署问题：
   • 网络插件未安装（如 Flannel/Calico）。
2. 运行中故障：
   • 宿主机资源耗尽（CPU/内存/磁盘）。
   • kubelet 服务异常：重启 systemctl restart kubelet。
3. 深度排查：
   • 查看节点详情：kubectl describe node <node-name>。
   • 检查系统日志：journalctl -u kubelet。

关键总结

• 调度控制：污点与容忍度实现节点精细调度。
• 服务暴露：
  • 内部访问：ClusterIP
  • 外部访问：NodePort/LoadBalancer/Ingress
  • 外部服务映射：ExternalName
• 网络设计：
  • 性能优先：Calico BGP模式或Flannel Host-GW
  • 策略需求：Calico NetworkPolicy
• 故障排查核心：
  • Pod状态异常 → 分析日志+资源监控
  • 网络故障 → 验证CNI插件+宿主机配置（IP转发/网段隔离

关键总结

• 污点与容忍度：通过节点标记和 Pod 豁免实现精细调度控制。
• Service 类型：根据访问需求选择 ClusterIP（内部）、NodePort/LoadBalancer（外部）或 ExternalName（外部服务映射）。
• 网络设计：CNI 插件选型需平衡功能（如 Flannel 简单 vs Calico 策略支持）和性能（host-gw > VXLAN）。
• 故障排查：
  • Pod 状态异常需结合日志和资源监控定位。
  • 网络问题优先验证 CNI 插件和宿主机配置（IP 转发、网段冲突）。
• 监控体系：Prometheus 组件分工明确，Exporter 数据采集 → Server 聚合 → Alertmanager 告警 → Grafana 可视化。