现在建网站赚钱吗google adwords关键词工具

张

张建站

2026/4/8 17:18:23

10分钟阅读

现在建网站赚钱吗,google adwords关键词工具,榆林市横山县建设局官方网站,建设银行官方网站登录从“node not found”到集群稳定#xff1a;一次彻底根治Kubernetes节点失联的实战指南如果你在凌晨三点被告警吵醒#xff0c;看到监控面板上某个节点状态变成 NotReady#xff0c;或者 kubectl get nodes 返回一个刺眼的 node not found 错误#xff0c;那种感觉就像在高…从“node not found”到集群稳定一次彻底根治Kubernetes节点失联的实战指南如果你在凌晨三点被告警吵醒看到监控面板上某个节点状态变成NotReady或者kubectl get nodes返回一个刺眼的node not found错误那种感觉就像在高速公路上开车时突然发现一个轮胎没气了。对于运维Kubernetes集群的工程师来说这种场景并不陌生。kubelet报出node not found或Error getting node表面上是节点信息获取失败但背后往往隐藏着从网络层到证书层再到配置和权限的一系列复杂问题。这篇文章不会给你一堆零散的命令而是带你构建一套从外到内、从表象到根源的系统性排查框架。我们会把这个问题拆解成清晰的层次让你下次遇到时能像老中医一样“望闻问切”快速定位病灶。1. 第一反应建立诊断基线避免盲目操作当告警响起你的第一反应不应该是重启kubelet或者kube-apiserver。盲目的重启可能会暂时掩盖问题但无法根治甚至可能让情况变得更糟。正确的做法是立刻收集关键信息建立问题诊断的基线。首先我们需要确认问题的范围。是单个节点失联还是多个节点同时出现问题这能帮你快速判断是节点本地问题还是集群层面的问题。# 在任何一个能连接到 API Server 的节点上执行 kubectl get nodes -o wide观察输出。如果某个节点的STATUS是NotReady并且AGE时间很久没有更新那基本可以确定是这个节点与 Master 失去了心跳。如果所有节点都正常但你的 Pod 调度失败并报node not found那可能是资源对象缓存或特定控制器的问题我们后面会讨论。接下来登录到出问题的节点本身。这是黄金法则永远不要只从集群外部判断节点内部状态。# 检查 kubelet 服务本身是否在运行 sudo systemctl status kubelet --no-pager -l # 查看 kubelet 最近的日志重点关注错误和警告 sudo journalctl -u kubelet --since 1 hour ago | grep -E \(Error|Failed|Warn|not found|refused)\ | head -30journalctl的输出是宝藏。一个典型的node not found根源日志可能长这样E0721 03:14:15.789012 21245 kubelet.go:2461] \Error getting node\ err\node \\\k8s-node-01\\\ not found\ E0721 03:14:15.789123 21245 reflector.go:138] k8s.io/client-go/informers/factory.go:134: Failed to watch *v1.Node: failed to list *v1.Node: Get \https://10.0.0.100:6443/api/v1/nodes?fieldSelectormetadata.name%3Dk8s-node-01limit500resourceVersion0\: dial tcp 10.0.0.100:6443: connect: connection refused看到connection refused了吗这立刻将我们的怀疑指向了网络连通性或API Server 服务可用性。但别急这只是第一层线索。提示养成使用--no-pager -l查看systemctl status的习惯它能显示完整的服务状态信息和最近的日志片段比简单的active (running)有用得多。为了建立一个完整的检查清单我们可以把初始排查要点归纳如下集群视角使用kubectl get nodes, cs, pods -n kube-system查看整体健康状况。节点视角检查kubelet服务状态、进程、以及关键日志。网络初步嗅探在节点上尝试telnet master-ip 6443或nc -zv master-ip 6443这是最直接的连通性测试。配置快照备份或记录当前的/etc/kubernetes/kubelet.conf和kubelet启动参数通过ps aux | grep kubelet获取。有了这些基线信息我们就可以开始分层深入了。2. 网络层深度排查打通节点与Master的“血脉”当日志出现connection refused或timeout时网络是首要嫌疑对象。但Kubernetes的网络排查不仅仅是“ping通”那么简单。我们需要检查多个层次。2.1 物理网络与防火墙这是最底层也最容易被云服务商或内部安全策略影响。检查点1基础连通性确保从节点到 Master 节点 API Server 服务端口默认6443的 TCP 连通性。ping用的是 ICMP而 API Server 使用 TCP所以ping通了不代表端口能通。# 使用 telnet 或 nc 测试 TCP 端口连通性 telnet MASTER_IP 6443 # 或者 nc -zv MASTER_IP 6443 # 如果上述命令卡住或失败检查本地防火墙 sudo iptables -L -n | grep 6443 sudo firewall-cmd --list-all # 如果使用 firewalld检查点2安全组与网络ACL云环境常见坑在阿里云、AWS、GCP 等云平台上安全组Security Group或网络ACLNetwork ACL规则会覆盖操作系统自身的防火墙。你需要确保节点的出站规则允许访问 Master 的 6443 端口。Master 的入站规则允许来自节点 IP 或整个 Pod/Service CIDR 网段对 6443 端口的访问。我见过太多案例是因为扩容节点后新节点的 IP 不在 Master 安全组的白名单里导致的。一个快速的验证方法是在 Master 节点上临时监听 6443 端口从问题节点尝试连接# 在 Master 节点上谨慎操作这会短暂影响 API Server sudo ss -ltnp | grep 6443 # 确认 6443 端口监听状态 # 如果 6443 被占用可以用 netcat 在另一个端口模拟监听 sudo nc -l -p 6444 # 在问题节点上 telnet MASTER_IP 6444检查点3路由与网络插件如果集群使用了 Calico、Flannel、Cilium 等网络插件还需要确保节点上的 CNI 插件工作正常。一个症状是节点状态可能是Ready但 Pod 网络不通或者kubelet因为 CNI 未就绪而无法上报完整节点状态虽然这通常报NetworkPluginNotReady。# 检查 CNI 插件二进制文件是否存在且可执行 ls -la /opt/cni/bin/ # 检查 CNI 配置文件 ls -la /etc/cni/net.d/ # 查看 kubelet 日志中是否有 CNI 相关错误 sudo journalctl -u kubelet | grep -i cni2.2 DNS 与主机名解析kubelet连接 API Server 时使用的是你在kubelet.conf或--kubeconfig参数中配置的服务器地址。这个地址可以是一个 IP也可以是一个域名如https://kubernetes.default.svc.cluster.local:6443。如果配置的是域名那么 DNS 解析失败就会导致连接错误。# 检查节点上配置的 API Server 地址 sudo cat /etc/kubernetes/kubelet.conf | grep server: # 尝试解析该地址如果是域名 nslookup your-apiserver-domain dig your-apiserver-domain # 检查节点的 /etc/hosts 文件看是否有错误或过时的静态映射 cat /etc/hosts一个经典的错误是在kubeadm init时使用了主机的hostname而这个hostname在/etc/hosts中没有正确映射到本机 IP或者在不同节点间无法解析。这时你需要确保所有节点包括 Master的/etc/hosts或内部 DNS 能正确解析所有节点的主机名和你在配置中使用的主机名。为了更清晰地对比不同网络故障现象我们可以参考下表故障现象可能原因排查命令/方向telnet: connect: Connection refused目标端口无服务监听防火墙/安全组拦截ss -ltnp查监听检查云安全组和本地iptablestelnet: connect: No route to host路由不可达对端主机宕机或网络隔离traceroute IP检查云网络ACL和子网路由表telnet: Connection timed out连接请求未收到响应可能是中间网络设备丢弃检查对端主机负载如conntrack满抓包分析curl: (6) Could not resolve hostDNS 解析失败nslookup检查/etc/resolv.conf和 DNS 服务间歇性连接失败网络抖动、负载均衡器问题、IPVS/iptables 规则冲突长期ping和telnet测试检查kube-proxy日志和模式3. 证书与身份认证Kubernetes的“信任基石”失效如果网络畅通无阻那么下一个最可能出问题的地方就是证书和身份认证。Kubernetes 集群内所有组件间的通信都是 TLS 加密的证书过期、损坏或不匹配会导致kubelet无法通过 API Server 的认证从而被拒绝连接。3.1 证书过期沉默的集群杀手这是生产环境中最常见的原因之一。kubeadm默认生成的证书有效期是一年。如果集群运行超过一年没有更新证书所有组件都会陆续“罢工”。症状不仅仅是node not foundkubectl get nodes可能也会报The connection to the server was refused。如何检查证书过期时间# 在 Master 节点上检查所有证书 sudo kubeadm certs check-expiration # 你会看到类似下面的输出 CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED admin.conf Dec 28, 2024 07:36 UTC 364d ca no apiserver Dec 28, 2024 07:36 UTC 364d ca no apiserver-etcd-client Dec 28, 2024 07:36 UTC 364d etcd-ca no apiserver-kubelet-client Dec 28, 2024 07:36 UTC 364d ca no controller-manager.conf Dec 28, 2024 07:36 UTC 364d ca no front-proxy-client Dec 28, 2024 07:36 UTC 364d front-proxy-ca no scheduler.conf Dec 28, 2024 07:36 UTC 364d ca no etcd-healthcheck-client Dec 28, 2024 07:36 UTC 364d etcd-ca no etcd-peer Dec 28, 2024 07:36 UTC 364d etcd-ca no etcd-server Dec 28, 2024 07:36 UTC 364d etcd-ca no重点关注apiserver-kubelet-client和apiserver证书它们直接关系到kubelet与 API Server 的相互认证。如果RESIDUAL TIME已经过期或只剩几天就需要立即更新。更新证书在 Master 节点上操作# 1. 备份现有证书非常重要 sudo cp -r /etc/kubernetes/pki /etc/kubernetes/pki.backup.$(date %Y%m%d) # 2. 更新所有证书 sudo kubeadm certs renew all # 3. 更新后你需要重启控制平面的静态 Pod因为证书文件被更新了但内存中的进程还在用旧的。 # 最简单的方法是移动 manifests 文件让 kubelet 自动重启 Pod。 sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/ sleep 10 # 等待 apiserver pod 被删除 sudo mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/ # 同样处理 controller-manager 和 scheduler sudo mv /etc/kubernetes/manifests/kube-controller-manager.yaml /tmp/ sudo mv /etc/kubernetes/manifests/kube-scheduler.yaml /tmp/ sleep 10 sudo mv /tmp/kube-controller-manager.yaml /etc/kubernetes/manifests/ sudo mv /tmp/kube-scheduler.yaml /etc/kubernetes/manifests/ # 4. 更新你的 admin.conf这样 kubectl 才能继续工作 sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config注意更新证书和重启控制平面组件会导致 API Server 有短暂的中断通常几十秒。务必在维护窗口操作并确保etcd是健康的。3.2 kubelet 客户端证书与 Bootstrap 流程除了 Master 的服务器证书kubelet也需要自己的客户端证书来向 API Server 证明“我是谁”。这个证书通常由集群的 CA 签发并存储在/var/lib/kubelet/pki/kubelet-client-current.pem一个指向最新证书的符号链接。如果这个证书损坏、被误删或者对应的 CSRCertificate Signing Request没有被批准kubelet就会认证失败。检查 kubelet 客户端证书# 查看当前使用的客户端证书 sudo ls -la /var/lib/kubelet/pki/kubelet-client-current.pem # 查看证书详细信息过期时间、CN等 sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep -A 2 -B 2 Validity如果证书有问题或者你是新加入的节点需要检查 CSR 状态# 在 Master 节点上列出所有 CSR kubectl get csr # 如果有 Pending 状态的 CSR查看其详情 kubectl describe csr csr-name # 批准一个 CSR确保你了解这个节点的身份 kubectl certificate approve csr-name对于新节点kubelet会使用一个引导令牌bootstrap token和引导 kubeconfig 文件/etc/kubernetes/bootstrap-kubelet.conf发起一个 CSR。如果这个过程卡住可能是引导令牌过期、引导配置错误或者 RBAC 权限不足。这时你需要检查kubelet日志中关于证书签名的部分。4. 配置与权限那些容易被忽略的细节排除了网络和证书我们就要深入到kubelet和集群的配置细节了。一个字符的错误或者一个权限的缺失都可能导致节点注册失败。4.1 kubelet 配置与启动参数kubelet的行为由其配置文件和命令行参数决定。关键的配置有两个地方一个是kubelet的 systemd 服务文件如/usr/lib/systemd/system/kubelet.service或/etc/systemd/system/kubelet.service.d/10-kubeadm.conf另一个是kubelet的配置文件/var/lib/kubelet/config.yaml。检查服务文件# 查看 kubelet 的实际启动命令 sudo systemctl cat kubelet # 或者通过进程查看 sudo ps aux | grep kubelet | grep -v grep重点关注以下几个参数--kubeconfig指向kubelet使用的 kubeconfig 文件通常是/etc/kubernetes/kubelet.conf。这个文件包含了访问 API Server 的地址、CA 证书和客户端证书。--bootstrap-kubeconfig引导阶段的 kubeconfig 文件。--node-ipkubelet对外宣告的节点 IP。如果设置错误比如是内网 IP但 Master 无法访问会导致通信问题。--hostname-override覆盖节点的主机名。慎用此参数除非你非常清楚自己在做什么。不匹配的主机名是很多node not found问题的元凶。检查 kubeconfig 文件sudo cat /etc/kubernetes/kubelet.conf确保server字段的地址是正确的、可访问的 API Server 端点。同时检查证书和密钥的路径是否正确文件是否存在且可读。4.2 RBAC 与 Node AuthorizerKubernetes 使用 RBAC基于角色的访问控制来管理权限。每个kubelet在集群中都有一个对应的User通常是system:node:nodeName。这个用户需要拥有对自己Node资源的get,update,patch等权限才能完成节点状态上报。如果节点的 RBAC 权限丢失例如误删了system:node相关的ClusterRoleBindingkubelet在尝试更新节点状态时就会收到403 Forbidden错误。检查节点的 RBAC 权限# 查看与 system:nodes 组相关的 ClusterRoleBinding kubectl get clusterrolebindings -o json | jq -r .items[] | select(.subjects[]?.namesystem:nodes) | .metadata.name # 通常你会看到 system:node 和 node-proxier 等。 # 查看 system:node ClusterRole 的权限规则 kubectl describe clusterrole system:node如果你怀疑是权限问题可以尝试手动为节点创建绑定但通常这不是根本原因因为kubeadm会处理好这些# 这是一个示例正常情况下不需要手动执行 kubectl create clusterrolebinding kubelet-node-binding --clusterrolesystem:node --usersystem:node:node-name4.3 资源冲突与污点容忍虽然不直接导致node not found但某些资源冲突会阻止kubelet正常启动其关键 Pod进而影响节点状态。例如如果kubelet要使用的端口如 10250被其他进程占用或者节点磁盘空间不足导致无法创建 Pod 沙盒kubelet会处于不健康状态。检查节点资源# 检查端口占用 sudo ss -ltnp | grep :10250 # 检查磁盘空间 df -h /var/lib/kubelet # 检查内存和 CPU 压力 free -h top另外如果 Master 节点也被打上了node-role.kubernetes.io/control-plane:NoSchedule污点而kubelet的启动参数或配置没有正确设置容忍度也可能导致 Master 上的kubelet无法运行必要的系统 Pod但这通常表现为其他错误。5. 高级场景与疑难杂症当你走完了前面四步大部分问题应该已经解决了。但如果你的节点依然“失联”那么可能遇到了更隐蔽的“疑难杂症”。下面分享几个我实际遇到过的案例。案例一IPVS 模式下的连接复用问题在一个使用kube-proxyIPVS 模式的大型集群中我们遇到过节点间歇性无法连接 API Server 的问题。抓包发现 TCP 握手成功但 SSL 握手失败。最终定位到是节点内核参数net.ipv4.vs.conn_reuse_mode设置为 1 时在特定负载下会导致 IPVS 对长连接如kubelet到 API Server 的 watch 连接的处理异常。将其改为 0 后问题解决。# 检查当前设置 sysctl net.ipv4.vs.conn_reuse_mode # 临时修改 sudo sysctl -w net.ipv4.vs.conn_reuse_mode0 # 永久修改写入 /etc/sysctl.conf echo net.ipv4.vs.conn_reuse_mode0 | sudo tee -a /etc/sysctl.conf sudo sysctl -p案例二etcd 存储压力与节点心跳丢失有一次一个节点的状态频繁在Ready和NotReady之间跳动。排查网络、证书、kubelet均无果。最后查看etcd监控发现etcd的磁盘写入延迟极高。kubelet的心跳Lease更新需要写入etcd当etcd因磁盘 IO 瓶颈响应缓慢时API Server 可能无法及时收到心跳从而认为节点失联。解决方案是优化etcd的存储后端使用 SSD并调整其运行参数。案例三错误的容器运行时端点当集群使用containerd作为容器运行时kubelet需要通过一个 Unix socket默认/run/containerd/containerd.sock与之通信。如果这个 socket 文件路径在kubelet配置/var/lib/kubelet/config.yaml中的containerRuntimeEndpoint中指定错误或者containerd服务没有启动kubelet就无法管理容器节点状态也会不健康。# 检查 containerd 状态 sudo systemctl status containerd # 检查 socket 文件 ls -la /run/containerd/containerd.sock # 检查 kubelet 配置 sudo grep -A2 -B2 containerRuntimeEndpoint /var/lib/kubelet/config.yaml案例四时钟不同步NTP 问题这是一个非常隐蔽的问题。如果节点和 Master 之间的系统时间相差太大超过几秒会导致 TLS 证书验证失败因为证书的有效期是基于时间戳的。确保所有集群节点都使用相同的 NTP 服务器并保持时间同步。# 检查时间同步状态 timedatectl status # 如果使用 chronyd chronyc sources -v处理完这些深层问题后别忘了最后一步验证修复。回到问题节点重启kubelet如果之前停止了然后观察日志并用kubectl get node node-name查看节点状态是否恢复为Ready。整个排查过程其实就是对 Kubernetes 节点生命周期和组件交互机制的一次深度理解。每一次故障都是让你对这套复杂系统认知加深的机会。