我们可以看到，kube-proxy 有一个 –cluster-cidr 的参数，我们就来解开这个参数究竟有没有用 bash 1 2 $ kube-proxy -h|grep cidr --cluster-cidr string The CIDR range of pods in the cluster. When configured, traffic sent to a Service cluster IP from outside this range will be masqueraded and traffic sent from pods to an external LoadBalancer IP will be directed to the respective cluster IP instead 可以看到，参数说明是说，如果配置，那么从外部发往 Service Cluster IP 的流量将被伪装，从 Pod 发往外部 LB 将被直接发往对应的 cluster IP。但实际上做了什么并不知道，那么就从源码解决这个问题。 首先我们知道，参数是作为 kube-proxy server 的参数，位于 cmd/kube-proxy 下，而对应的逻辑则位于 pkg/kube-proxy 下，参数很明显，就是 clusterCIDR，那么我们就寻找这个参数的调用即可。...

测试上传/下载对象 存取故据时，客户端必须首先连接至RAD05集群上某存储地，而后根据对像名称由相关的中CRUSH规则完成数据对象寻址。于是为了测试集群的数据存储功能，首先创建一个用于测试的存储池mypool，并设定其PG数量为16个。 sh 1 ceph osd pool create mypool 16 16 而后，即可将测试文件上传至存储池中。例如下面的rados put命令将/etc/hosts rados lspool 显示存储池 rmpool 删除存储池 mkpool 创建存储池 rados mkpool mypool 32 32 sh 1 2 rados mkpool {name} {pgnum} {pgpnum} rados mkpool test 32 32 sh 1 2 $ ceph osd pool create testpool 32 32 pool 'testpool' created 列出存储池 text 1 2 3 4 5 6 7 8 9 $ ceph osd pool ls mypool rbdpool testpool $ rados lspools mypool rbdpool testpool 而后即可将测试文件上传到存储池中，例如将rados put命令将/etc/issue文件上传至testpool存储池，对象名称仍然较保留文件名issue，而rados ls可以列出指定存储池中的数据对象...

Rebalance 当 Ceph 集群在扩容/缩容后，Ceph会更新 Cluster map, 在更新时会更新 Cluster map 也会更新 “对象的放置” CRUSH 会平均但随机的将对象放置在现有的 OSD 之上，在 Rebalancing 时，只有少量数据进行移动而不是全部数据进行移动，直到达到 OSD 与 对象 之间的平衡，这个过程就叫做 Ceph 的 Rebalance。 需要注意的是，当集群中的 OSD 数量越多，那么在做 Rebalance 时所移动的就越少。例如，在具有 50 个 OSD 的集群中，在添加 OSD 时可能会移动 1/50th 或 2% 的数据。 如下图所示，当前集群有两个 OSD，当在集群中添加一个 OSD，使其数量达到3时，这个时候会触发 Rebalance，所移动的数量为 OSD1 上的 PG3 与 OSD2 上的 PG 6和9 图：Ceph Rebalancing 示意图 Source：https://access.redhat.com/documentation/zh-cn/red_hat_ceph_storage/4/html/architecture_guide/ceph-rebalancing-and-recovery_arch Balancer 执行 Rebalance 的模块时 Balancer，其可以优化 OSD 上的放置组 (PG) ，以实现平衡分配。 可以通过命令查看 balancer 的状态 bash 1 ceph balancer status https://docs....

Overview 阅读完本文，您当了解 Kubernetes 卷 CephFS 在 kubernetes 中的挂载 Kubelet VolumeManager 本文只是个人理解，如果有大佬觉得不是这样的可以留言一起讨论，参考源码版本为 1.18.20，与高版本相差不大 VolumeManager VolumeManager VM 是在 kubelet 启动时被初始化的一个异步进程，主要是维护 “Pod" 卷的两个状态，”desiredStateOfWorld“ 和 ”actualStateOfWorld“； 这两个状态用于将节点上的卷 “协调” 到所需的状态。 VM 实际上包含三个 “异步进程” (goroutine)，其中有一个 reconciler 就是用于协调与挂载的，下面就来阐述 VM 的挂载过程。 VM中的重要组件 actualStateOfWorld mountedPod desiredStateOfWorld VolumeToMount podToMount VM的组成 VM 的代码位于，由图可以看出，主要包含三个重要部分： reconciler：协调器 populator：填充器 cache：包含 ”desiredStateOfWorld“ 和 ”actualStateOfWorld“ 图：VM的目录组成 在代码结构上，volumeManager 如下所示 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 // volumeManager implements the VolumeManager interface type volumeManager struct { // DesiredStateOfWorldPopulator 用来与 API 服务器通信以获取 PV 和 PVC 对象的 API 客户端 kubeClient clientset....

背景 目前的 Kubernetes 集群资源面板是基于集群的使用资源，因为是多集群，业务同时运行字啊不同集群上，如果通过 label 来划分业务使用的资源情况，这个才是真的和每个集群的每个业务使用的资源有关。 对于这种场景的划分，Kubernetes 中有一个专门的名词是 Pod 的拓扑域；基于这些需要做的事情就如下步骤 首先确定node label可以搜集到，如果不存在需要收集 当收集到node label 时，需要根据对应的 label 将一个域中的 根据域（label）做变量注入到 对应的查询语句中以生成图表 收集 node label 在使用 kube-prometheus-stack 中收集 kubernetes 的 node label 需要手动启动参数 - --metric-labels-allowlist=nodes=[*] 才可以收集到 node label，手动给Node 打上标签，test 拓扑域 为 aaaa bbbb两个 在 helm 中直接增加如下： bash 1 - nodes=[*] 查看 label bash 1 2 3 4 $ kubectl get node --show-labels NAME STATUS ROLES AGE VERSION LABELS node01 Ready <none> 13d v1.16.10 beta....