K8S v1.10 + Docker 17.09 集群部署：3个常见网络与证书问题深度排错

当你在二进制部署Kubernetes集群时，网络连通性和TLS证书配置往往是两个最令人头疼的问题。本文将深入剖析三个典型故障场景：etcd启动失败、kube-apiserver无法访问以及Node节点NotReady状态，并提供一套完整的诊断与修复方案。

1. 诊断工具箱准备

在开始排错前，建议准备以下基础检查工具：

# 网络连通性检查工具集
sudo yum install -y telnet nmap nc tcpdump iproute

# 证书检查工具
openssl version
cfssl version

连通性检查清单 应包含以下关键项：

检查项	命令示例	预期结果
节点间TCP连通性	telnet <IP> 6443	连接成功
端口监听状态	netstat -tulnp | grep 6443	服务监听指定端口
防火墙规则	iptables -L -n -v	无阻断关键端口的规则
路由表	ip route show	网络路由正常
DNS解析	nslookup kubernetes.default	能解析集群内部域名

2. etcd启动失败：证书与集群初始化问题

etcd作为Kubernetes的数据存储核心，其启动失败通常表现为以下症状：

journalctl -u etcd -f
报错示例：x509: certificate signed by unknown authority

2.1 根因分析流程

graph TD
    A[etcd启动失败] --> B{检查日志}
    B --> C[证书错误]
    B --> D[集群配置错误]
    C --> E[验证证书链]
    D --> F[检查成员列表]
    E --> G[重新生成证书]
    F --> H[重置集群]

2.2 具体修复步骤

证书问题修复 ：

# 重新生成etcd证书（需在CA服务器操作）
cat > etcd-csr.json <<EOF
{
  "CN": "etcd",
  "hosts": [
    "127.0.0.1",
    "${MASTER_IP}"
  ],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [{
    "C": "CN",
    "ST": "Shanghai",
    "L": "Shanghai"
  }]
}
EOF

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem etcd-csr.json | cfssljson -bare etcd

集群初始化问题 ：

# 备份数据后重置etcd集群
sudo systemctl stop etcd
sudo rm -rf /var/lib/etcd/*
sudo etcd --initial-cluster-token=etcd-cluster-new \
          --initial-advertise-peer-urls=https://${MASTER_IP}:2380 \
          --initial-cluster=default=https://${MASTER_IP}:2380

3. kube-apiserver无法访问：TLS与网络策略

当kubectl命令返回 The connection to the server was refused 时，通常意味着API Server不可达。

3.1 四层诊断法

1. 物理层 ：

   ping ${APISERVER_IP}
   

2. 网络层 ：

   traceroute ${APISERVER_IP} -p 6443
   

3. 传输层 ：

   nc -zv ${APISERVER_IP} 6443
   

4. 应用层 ：

   curl -k https://${APISERVER_IP}:6443/version
   

3.2 常见修复方案

证书配置错误 ：

# 检查证书有效期
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates

# 更新证书（kubeadm环境）
kubeadm alpha certs renew all

服务启动参数检查 ：

# 确认监听地址包含节点IP
ps aux | grep kube-apiserver | grep -- --advertise-address

4. Node节点NotReady：组件通信与网络插件

Node节点NotReady通常伴随以下组件问题：

kubectl describe node ${NODE_NAME}
显示原因：KubeletNotReady / NetworkPluginNotReady

4.1 组件状态检查表

组件	检查命令	健康标准
kubelet	systemctl status kubelet	Active (running)
kube-proxy	journalctl -u kube-proxy	无证书错误日志
docker	docker ps	能正常启动容器
CNI插件	ls /etc/cni/net.d/	有正确配置文件

4.2 网络插件修复示例

以Flannel为例的典型修复流程：

# 清理旧网络配置
ip link delete cni0
ip link delete flannel.1

# 重新应用网络配置
kubectl delete -f kube-flannel.yml
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

5. 高级排错技巧

对于复杂网络问题，可采用以下深度诊断方法：

数据包捕获分析 ：

# 在Master节点捕获API Server流量
tcpdump -i any -nn -w apiserver.pcap port 6443

证书链验证 ：

openssl verify -CAfile /etc/kubernetes/pki/ca.crt \
               -untrusted /etc/kubernetes/pki/apiserver.crt \
               /etc/kubernetes/pki/apiserver-kubelet-client.crt

etcd健康检查 ：

ETCDCTL_API=3 etcdctl --endpoints=https://${ETCD_IP}:2379 \
                      --cacert=/etc/kubernetes/pki/etcd/ca.crt \
                      --cert=/etc/kubernetes/pki/etcd/server.crt \
                      --key=/etc/kubernetes/pki/etcd/server.key \
                      endpoint health

记住，在二进制部署环境中，每个组件的日志都是黄金信息源。养成第一时间检查 journalctl -u <service> 的习惯，能帮你快速定位80%的集群问题。