暗能星系
    • 登录
    • 搜索

    三黍运维命令

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

      ceph config get osd osd_max_backfills
      ceph config get osd osd_recovery_max_active
      ceph config get osd osd_recovery_op_priority

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

        moren:
        bash-4.4$ ceph config get osd osd_max_backfills
        1
        bash-4.4$
        bash-4.4$ ceph config get osd osd_recovery_max_active
        0
        bash-4.4$ ceph config get osd osd_recovery_op_priority
        3

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

          提高每个 OSD 允许的最大并发恢复操作数（默认通常是 3 或 5）

          ceph config set osd osd_max_backfills 16
          ceph config set osd osd_recovery_max_active 16

          提高恢复线程的优先级（值越小优先级越高，默认通常是 10）

          ceph config set osd osd_recovery_op_priority 3

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

            2026-05-18 01:13:11.562102 I | clusterdisruption-controller: all "host" failure domains: [node1 node2 node3 node5 node6 node7 node8]. osd is down in failure domain: "". active node drains: false. pg health: "cluster is not fully clean. PGs: [{StateName:active+clean Count:1972} {StateName:active+remapped+backfilling Count:104} {StateName:active+clean+scrubbing+deep Count:21}]"

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

              csi-cephfsplugin-2hwcz csi-cephfsplugin-2zjmb csi-cephfsplugin-djtn9 csi-cephfsplugin-fpr72 csi-cephfsplugin-kltj4 csi-cephfsplugin-lz5gv csi-cephfsplugin-provisioner-7769f7b7fb-pk44w csi-cephfsplugin-provisioner-7769f7b7fb-zg99t csi-cephfsplugin-ptq9l csi-rbdplugin-8cb99 csi-rbdplugin-bl9vv csi-rbdplugin-dlxlg csi-rbdplugin-fc6r7 csi-rbdplugin-h4jl4 csi-rbdplugin-provisioner-6585465959-k9hr6 csi-rbdplugin-provisioner-6585465959-nwzxf csi-rbdplugin-v2sb8 csi-rbdplugin-w9skr

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

                kubectl -n rook-ceph get cephcluster -o yaml | grep -A 5 -B 2 network

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

                  kubectl -n rook-ceph get pod -l app=rook-ceph-mon -o jsonpath='{.items[0].spec.hostNetwork}'

                  kubectl -n rook-ceph get pod -o wide -l app=rook-ceph-mon

                  kubectl -n rook-ceph logs -l app=rook-ceph-operator --tail=200 | grep -Ei "network|error|failed"

                  kubectl -n rook-ceph get events --sort-by='.metadata.creationTimestamp' | grep -i network

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

                    kubectl -n rook-ceph get cephcluster rook-ceph -o jsonpath='{.spec.network}'

                    kubectl -n rook-ceph describe cephcluster rook-ceph | grep -A 10 -i "Events:"

                    kubectl -n rook-ceph get cephcluster rook-ceph -o jsonpath='{.status.conditions}'

                    kubectl -n rook-ceph edit cephcluster rook-ceph

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

                      network:
                      provider: host
                      selectors:
                      public: "192.168.x.0/24" # 换成你 node1-node8 物理内网实际的 IP 段
                      cluster: "192.168.x.0/24" # 如果是单网卡，写一样的；双网卡写心跳专属网段

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

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

                        1 条回复 最后回复 回复 引用 0
                        • 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
                                            • First post
                                              Last post
                                            Powered by 暗能星系