暗能星系
    • 登录
    • 搜索

    三黍运维命令

    张渌
    1
    42
    16
    正在加载更多帖子
    • 从旧到新
    • 从新到旧
    • 最多赞同
    回复
    • 在新帖中回复
    登录后回复
    此主题已被删除。只有拥有主题管理权限的用户可以查看。
    • Z
      zhanglu 最后由 编辑

      kubectl -n rook-ceph get deployment rook-ceph-mon-bu -o yaml | grep -E "hostNetwork|dnsPolicy"

      1 条回复 最后回复 回复 引用 0
      • Z
        zhanglu 最后由 编辑

        hostNetwork: true
        dnsPolicy: ClusterFirstWithHostNet

        1 条回复 最后回复 回复 引用 0
        • Z
          zhanglu 最后由 编辑

          kubectl -n rook-ceph get pod -A | grep osd-prepare | grep node1

          kubectl -n rook-ceph get job | grep osd-prepare | grep node1
          kubectl -n rook-ceph delete job -l app=rook-ceph-osd-prepare
          watch "kubectl -n rook-ceph get pod -o wide | grep osd-prepare"

          1 条回复 最后回复 回复 引用 0
          • Z
            zhanglu 最后由 编辑

            kubectl -n rook-ceph delete job rook-ceph-osd-prepare-node1

            1 条回复 最后回复 回复 引用 0
            • Z
              zhanglu 最后由 编辑

              2026-05-21 13:28:38.632651 I | clusterdisruption-controller: deleting temporary blocking pdb with "rook-ceph-osd-host-node1" with maxUnavailable=0 for "host" failure domain "node1"
              2026-05-21 13:28:38.635906 I | clusterdisruption-controller: deleting temporary blocking pdb with "rook-ceph-osd-host-node2" with maxUnavailable=0 for "host" failure domain "node2"
              2026-05-21 13:28:38.638890 I | clusterdisruption-controller: deleting temporary blocking pdb with "rook-ceph-osd-host-node5" with maxUnavailable=0 for "host" failure domain "node5"
              2026-05-21 13:28:38.641451 I | clusterdisruption-controller: deleting temporary blocking pdb with "rook-ceph-osd-host-node6" with maxUnavailable=0 for "host" failure domain "node6"
              2026-05-21 13:28:38.644184 I | clusterdisruption-controller: deleting temporary blocking pdb with "rook-ceph-osd-host-node7" with maxUnavailable=0 for "host" failure domain "node7"
              2026-05-21 13:28:38.646663 I | clusterdisruption-controller: deleting temporary blocking pdb with "rook-ceph-osd-host-node8" with maxUnavailable=0 for "host" failure domain "node8"

              1 条回复 最后回复 回复 引用 0
              • Z
                zhanglu 最后由 编辑

                kubectl -n rook-ceph edit deployment rook-ceph-mon-bu

                hostNetwork: true
                dnsPolicy: ClusterFirstWithHostNet

                1 条回复 最后回复 回复 引用 0
                • Z
                  zhanglu 最后由 编辑

                  测试 3300 端口（最关键！）

                  nc -w 3 -zv 192.168.10.11 3300
                  nc -w 3 -zv 192.168.10.14 3300
                  nc -w 3 -zv 192.168.10.15 3300

                  测试 6789 端口

                  nc -w 3 -zv 192.168.10.11 6789

                  mount -t ceph 192.168.10.11:/,192.168.10.14:/,192.168.10.15:/ /cephfs_data -o name=admin,secret=AQA4NLvjX02ICBAA8p93aHTAM5M+0yPL3lPGaQ==

                  mount -t ceph 192.168.10.11:3300,192.168.10.14:3300,192.168.10.15:3300:/ /cephfs_data -o name=admin,secret=AQA4NLvjX02ICBAA8p93aHTAM5M+0yPL3lPGaQ==

                  1 条回复 最后回复 回复 引用 0
                  • Z
                    zhanglu 最后由 编辑

                    curl -v -k --connect-timeout 10 https://10.233.0.1:443

                    1 条回复 最后回复 回复 引用 0
                    • Z
                      zhanglu 最后由 编辑

                      kubectl get pods -n kube-system -o wide | grep kube-proxy | grep node4
                      iptables -L -n -v | grep 10.233.0.1

                      或者如果是 IPVS 模式

                      ipvsadm -ln | grep 10.233.0.1

                      1 条回复 最后回复 回复 引用 0
                      • Z
                        zhanglu 最后由 编辑

                        别慌，既然 ping 1450 大包能通，说明纯粹的底层网络（三层 IP 转发和大包物理传输）是完全健康的。

                        那为什么 curl 和 Calico 会死死卡在 TLS 握手的 Client Hello？这就好比电话拨通了，但只要一开始对暗号（加密握手），对方就突然挂机或不说话了。

                        为了帮你理清思绪，我们把复杂的网络剥离出来，用最直接的三个排查阶段来彻底定位：

                        🛠️ 第一阶段：1分钟排除网卡硬件特性干扰 (最可能)
                        在 IPVS/iptables 转发模式下，现代网卡会开启一些“硬件加速”功能。这些功能有时候会将 TLS 的长数据包切碎或改写校验和，导致 Master 收到后认为是坏包而直接丢弃，从而不回包。

                        请直接在 node4 上执行以下命令，强制关闭网卡的加速特性：

                        Bash

                        1. 安装 ethtool

                        yum install -y ethtool || apt-get install -y ethtool

                        2. 关闭主网卡的校验卸载和分片卸载（请把 eth0 换成你的实际物理网卡名）

                        ethtool -K eth0 tx off gso off tso off
                        测试：改完后，立刻再次在 node4 执行 curl -v -k https://10.233.0.1:443。

                        结果：如果通了，说明就是网卡特性作祟，问题解决！

                        🔍 第二阶段：确认是“单节点问题”还是“全局问题”
                        我们要确定这个 TLS 握手失败，是只发生在 node4 上，还是其他 Node 也有。

                        去其他正常运行的工作节点（比如 node2 或 node3） 执行相同的命令：

                        Bash
                        curl -v -k https://10.233.0.1:443
                        交叉对比：

                        如果只有 node4 卡死：说明问题百分之百在 node4 本身（网卡驱动、本地 kube-proxy、或者 node4 的本地 iptables/ipvs 状态表损坏）。

                        如果所有节点都卡死：说明是 Master 端的 API Server 顶不住了，或者 Master 本身的系统防火墙对 10.233.0.1 的 443 端口做了整体的策略限制（如限流、拒绝特定握手协议）。

                        📡 第三阶段：从“接收端（Master）”看真相
                        既然 node4 已经把 Client Hello 发出去了，我们去 Master 节点看看它到底收到了没有，或者为什么要拒绝。

                        登录到 Master 节点 (node1)。

                        实时查看 kube-apiserver 的日志，并过滤 node4 的物理内网 IP（假设 node4 的内网 IP 是 192.168.10.13）：

                        Bash
                        kubectl logs -n kube-system -l component=kube-apiserver --tail=100 -f | grep 192.168.10.13
                        在 node4 上同时运行 curl 触发报错，观察 Master 端的日志输出：

                        情况 A：Master 毫无日志反差。说明 node4 的 Client Hello 包在半路（云平台安全组、外部交换机、或 Master 的本地防火墙）被静默丢弃（Drop）了。

                        情况 B：Master 报错，类似 bad certificate 或 tls: alert。说明包到了，但 Master 嫌弃 node4 的客户端行为（可能是时间不同步、加密套件不匹配等），主动断开了连接。

                        1 条回复 最后回复 回复 引用 0
                        • Z
                          zhanglu 最后由 编辑

                          方案一：测试极端的低 MTU 绕过（最快见效的野路子）
                          之前我们测了物理网卡可以过 1450 的 ping，但 TLS 的应用层分片机制可能卡在宿主机的 TCP 握手协商上。我们直接把 node4 的物理网卡 MTU 砍到一个极低的值，迫使操作系统的 TCP 协议栈将所有包切成超级小的碎包发出，以此绕过中间设备的拦截。

                          在 node4 上执行：

                          Bash

                          强行将物理网卡 eno52 的 MTU 降到 1200

                          ip link set dev eno52 mtu 1200
                          测试：再次在 node4 执行 curl -v -k https://10.233.0.1:443。

                          原理：如果改成 1200 后突然通了，说明 node4 的物理上游链路依然存在严重的 PMTUD（路径MTU发现）黑洞。

                          方案二：检查并重置 node4 本身恶化的 iptables/IPVS 状态表
                          从最后一张图（image_576424.jpg）看，Calico 在拼命尝试连接多个内网 Master 的 IP（192.168.10.12:2379 等）。node4 本身的内核连接跟踪表（Conntrack）可能已经因为先前的 200 多次崩溃而溢出或卡死。

                          在 node4 上强行刷新网络规则：

                          Bash

                          清理可能导致 TCP 卡死的内核连接跟踪表

                          yum install -y conntrack-tools || apt-get install -y conntrack
                          conntrack -F

                          清理并重启 node4 本身的网络服务（如果是物理机可以考虑重启一下 node4 宿主机，这是最彻底的）

                          方案三：抓包看看到底是谁在“只收不回”
                          如果方案一和二都不行，我们需要用最原始的手段，看看到底是包没发出去，还是 Master 回了包 node4 没收到。

                          在 node4 上开一个窗口抓包：

                          Bash
                          tcpdump -i eno52 port 443 -w node4.pcap
                          在 node4 上开另一个窗口执行 curl 触发卡死。

                          把 node4.pcap 导出到电脑用 Wireshark 打开。

                          现象 A：如果看到大量的 TCP Retransmission（重传）来自 node4，说明 node4 发出了 Client Hello，但上游设备（交换机/防火墙）把它吃了，Master 压根没收到。

                          现象 B：如果看到了 Master 回应了包，但 node4 报错，说明是 node4 本身的内核防火墙（iptables）把回包给拦截了。

                          1 条回复 最后回复 回复 引用 0
                          • Z
                            zhanglu 最后由 编辑

                            tcpdump -r /root/node4_tls.pcap -nn -v
                            systemctl restart chronyd || ntpdate ntp.aliyun.com

                            1 条回复 最后回复 回复 引用 0
                            • Z
                              zhanglu 最后由 编辑

                              物理机推荐直接同步时间服务器

                              ntpdate ntp.aliyun.com || chronyc -a makestep

                              1 条回复 最后回复 回复 引用 0
                              • Z
                                zhanglu 最后由 编辑

                                tcpdump -r /root/node4_tls.pcap -nn -v | head -n 30

                                1 条回复 最后回复 回复 引用 0
                                • Z
                                  zhanglu 最后由 编辑

                                  第一步：去 Master 节点（node1）上大扫除
                                  请登录到你的 Master 节点 (node1)，执行以下命令，看看 Master 是不是在悄悄嫌弃 node4：

                                  Bash

                                  1. 检查 Master 的 iptables 中有没有针对 node4 IP 的拦截规则

                                  iptables -L -n -v | grep 192.168.10.13

                                  2. 如果你们系统开启了 IPVS，查看 conntrack 是否有 node4 的死连接冲突

                                  conntrack -L | grep 192.168.10.13

                                  3. 实时跟踪 Master 上的 API Server 日志，同时在 node4 运行 curl

                                  看看 Master 端有没有弹出来自 192.168.10.13 的 TLS 握手错误或拒绝日志

                                  kubectl logs -n kube-system -l component=kube-apiserver --tail=50 -f | grep 192.168.10.13
                                  第二步：最粗暴也最有效的验证（改 IP）
                                  如果你有权限，尝试修改一下 node4 的物理内网 IP（比如从 192.168.10.13 改成 .14 或其他空闲 IP），或者把 node4 网线拔了插到旁边 node6 的交换机端口上。

                                  如果改了 IP 或者换了端口瞬间通了，那就彻底抓到真凶了：就是 Master 内部或交换机针对旧 IP/旧端口做了安全拦截！

                                  第三步：看一眼抓包大结局
                                  把你之前在 node4 跑的 tcpdump 停止，用文本读出来看一眼：

                                  Bash
                                  tcpdump -r /root/node4_tls.pcap -nn -vv | head -n 50
                                  你只需要帮我确认：里面到底有没有来自 10.233.0.1 带有 [R] (Reset) 的包？

                                  如果没有（全是一成不变的单向发送）：实锤被半路 Drop（默默丢弃）。

                                  如果有（带有 [R]）：实锤被 Master Reject（显式拒绝）。

                                  咱们去 Master 节点上看一眼它的 iptables 规则或者 API Server 日志吧，真凶现在就在 Master 身上躲着呢！

                                  1 条回复 最后回复 回复 引用 0
                                  • Z
                                    zhanglu 最后由 编辑

                                    🚀 终极修复方案
                                    这个问题属于 Linux 内核网络路由冲突。请立刻按照以下两步在 Master 节点 (node1) 上执行，可以瞬间打破这个死锁：

                                    步骤一：关闭 Master 节点网卡的反向路径过滤（RP_Filter）
                                    Linux 内核为了防欺骗，默认会开启反向路径校验。如果它发现回包的路径和来包路径不一致，就会直接把包丢弃。

                                    在 Master 节点 (node1) 上执行：

                                    Bash

                                    临时关闭所有网卡的反向路径过滤

                                    sysctl -w net.ipv4.conf.all.rp_filter=0
                                    sysctl -w net.ipv4.conf.default.rp_filter=0

                                    刷新配置

                                    sysctl -p
                                    步骤二：强行清空这个卡死的 SYN_RECV 流表
                                    现在连接跟踪表里缓存了错误的连接状态，必须把它立刻踢掉：

                                    在 Master 节点 (node1) 上强行断开并清理针对 node4 的死连接：

                                    Bash
                                    conntrack -D -s 192.168.10.13

                                    或者直接清理目的地是 10.233.0.1 且状态坏掉的流表

                                    conntrack -D -d 10.233.0.1
                                    🧪 见证奇迹的时刻
                                    完成 Master 节点上的这两步操作后，立刻回到 node4 重新敲一下：

                                    Bash
                                    curl -v -k https://10.233.0.1:443
                                    这一次，握手流表被刷新，反向过滤关闭，TCP 状态应该能瞬间跨过 SYN_RECV 直接进入 ESTABLISHED。测一下看看，是不是直接通了？！

                                    1 条回复 最后回复 回复 引用 0
                                    • Z
                                      zhanglu 最后由 编辑

                                      tcpdump -r /root/node4_tls.pcap -nn -v | head -n 20

                                      1 条回复 最后回复 回复 引用 0
                                      • Z
                                        zhanglu 最后由 编辑

                                        TLS handshake, Client hello (1)

                                        1 条回复 最后回复 回复 引用 0
                                        • Z
                                          zhanglu 最后由 编辑

                                          kubectl logs -f calico-node-f42jj -n kube-system
                                          2026-05-24 10:12:48.021 [INFO][9] startup/startup.go 376: Early log level set to info
                                          2026-05-24 10:12:48.022 [INFO][9] startup/startup.go 392: Using NODENAME environment for node name
                                          2026-05-24 10:12:48.022 [INFO][9] startup/startup.go 404: Determined node name: node4
                                          2026-05-24 10:12:48.025 [INFO][9] startup/startup.go 436: Checking datastore connection
                                          2026-05-24 10:12:58.027 [INFO][9] startup/startup.go 451: Hit error connecting to datastore - retry error=Get "https://10.233.0.1:443/api/v1/nodes/foo": net/http: TLS handshake timeout

                                          1 条回复 最后回复 回复 引用 0
                                          • Z
                                            zhanglu 最后由 编辑

                                            1. 报错核心信息
                                              报错日志： Hit error connecting to datastore - retry error=Get "https://10.233.0.1:443/api/v1/namespaces/foo": net/http: TLS handshake timeout

                                            含义： Calico 正在尝试连接集群的 API Server 内网服务 IP（10.233.0.1:443），但在进行 TLS 握手（Handshake） 时超时了。

                                            Ping 测试结果： 您通过 ping 10.233.0.1 发现网络是通的，且延迟极低（~0.05ms）。这说明 三层网络（IP 路由）是通的，但四层（TCP）或七层（TLS/HTTP）存在阻断或异常。

                                            1. 可能的原因及排查步骤
                                              请按照以下顺序逐步排查：

                                            排查一：测试 TCP 443 端口是否真正可用
                                            ping 使用的是 ICMP 协议，即便 ping 得通，TCP 端口也可能被防火墙拦截或没有服务监听。
                                            在报错的节点上执行以下命令，检查 443 端口是否响应：

                                            Bash
                                            curl -k -v https://10.233.0.1:443

                                            或者使用 nc/telnet

                                            nc -zv 10.233.0.1 443
                                            如果连接超时（Timeout）或被拒绝（Refused）： 说明 443 端口在网络层或安全策略上被封锁了。请检查系统防火墙（如 firewalld、ufw 或 iptables 规则）。

                                            排查二：检查 Kubernetes API Server 的状态
                                            10.233.0.1 通常是 kube-apiserver 的 Service VIP。如果 API Server 挂了、过载或者响应极慢，就会导致 TLS 握手超时。
                                            在 Master 节点上查看 API Server 的运行状态和日志：

                                            Bash
                                            kubectl get pods -n kube-system | grep apiserver

                                            查看 apiserver 日志是否有报错或过载

                                            kubectl logs -n kube-system deploy/kube-apiserver # 如果是 deployment

                                            或者如果是静态 Pod：

                                            kubectl logs -n kube-system kube-apiserver-node1
                                            排查三：MTU（最大传输单元）不一致问题（常见于 Calico 环境）
                                            TLS 握手期间会传输很大的证书文件。如果节点网卡的 MTU 差异过大，导致大包被丢弃，就会出现“能 ping 通（小包），但 TLS 握手超时（大包）”的现象。

                                            在宿主机上查看网卡 MTU（如 eth0 或 bond0）：

                                            Bash
                                            ip link show
                                            检查 Kubespray 配置文件中 Calico 的 MTU 设置（通常在 roles/network_plugin/calico/defaults/main.yml 中），确保 Calico 的 MTU 比物理网卡小至少 20 字节（如果是 IPIP 模式）或 50 字节（如果是 VXLAN 模式）。

                                            排查四：检查系统时间同步
                                            TLS 证书验证对时间非常敏感。如果当前节点（node4）与 Master 节点的时间不一致，可能会导致证书校验环节卡住或失败。

                                            Bash
                                            date

                                            确保所有节点都启用了时钟同步（如 chronyd 或 ntpd）

                                            systemctl status chronyd

                                            1 条回复 最后回复 回复 引用 0
                                            • First post
                                              Last post
                                            Powered by 暗能星系