我们可以看到，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....

存储选择需要考虑的问题：不同的文件访问方式? 在关注存储之前，需要关注下面一些问题： “应用” 访问数据的方式是什么？ 一次读取 或 分块读取 一个连续的“流”传输最好的方式是什么 有序的 或 随机的 “数据的类型是什么”？ 数据库，Text，视频/音频，图像… 静态 / 固定 / 动态 是否需要数据共享？ 由应用共享 / 由存储共享 读 / 写 共享方面关注的问题？ Narrow (只需要更新部分内容，这可以共享特定部分内容，这将不是一个广泛共享) / Broad 安全和访问控制： 应用什么级别的的安全性？ 访问性会影响存储的选择： Local / Network 介质：光纤，以太网，SAS，SATA，PCIe… 有了这些问题，就可以引入存储的类型，以便选择最佳的存储（Balance performance and cost ） DAS Direct Attached Storage (DAS) 直接附加存储是指，直接连接到服务器存储系统，通俗来讲就是直接连接磁盘，服务器与存储系统之间“没有经过网络设备” (如交换机等)，服务器与存储直接由专用的“连接技术”进行连接，如 SCSI, 但现在更常见的是 “eSATA”, “SAS”, 或 “光纤通道”。 图：DAS结构图 Source：https://www.pcmag.com/encyclopedia/term/direct-attached-storage 图：DAS接口类型 Source：https://ramsaihan.wordpress.com/2017/10/16/the-sas-sata-scsi-and-ata-in-storage-and-peripheral-communication/ 外部连接 直连存储也可以通过连接电缆从服务器连接到存储设备，但服务器中必须存在 SAS、以太网或 FC 控制器，只有该服务器可以使用外部磁盘空间。因此直连存储也可以作为是服务器的扩展 SAS 作为连接介质价格低廉，但距离仅限于几米（最大 5 或 10 米，具体取决于制造商）；光纤通道的传输距离可达数公里，因此也可用作灾备系统。...

在配置好 github 仓库后，需要将对应的信息填写在 picgo 中，可以按照如下进行配置 仓库名：xxxx/xxx 无需写 github.com/xxx/xxx 分支名：直接填写分支名即可 Token：在 github 上面配置的仓库 token 设定存储路径：这里填写 github 仓库上传到的路径 设置自定义域名：https://cdn.jsdelivr.net/gh/<github_username>@<branch_name>/<repo_name>/<path> 例如：https://cdn.jsdelivr.net/gh/cylonchau/blogs@img/img/image-20241129232645456.png

本文是Ceph集群部署系列第2章 使用cephadm纯离线安装Ceph集群 使用cephadm纯离线安装Ceph集群 2 Ceph集群安装 - ceph-deploy Ceph集群安装 - ceph-deploy下线rgw 离线安装 - ceph-mds ceph-mds (metadata server daemon) 是 cephfs 功能中所需要的组件，是用于收集和管理文件系统名称空间，协调和共享 OSD 集群的组件。 cephadm 部署集群所有组件都打包在 ceph 镜像内，只需要修改一遍就可以全局离线安装了 要部署 cephfs 就需要有一个或多个 ceph-mds 使用 cephadm 部署 mds bash 1 2 ceph orch apply mds *<fs-name>* --placement="*<num-daemons>* [*<host1>* ...]" ceph orch apply mds kubernetes01 --placement="hostname01,hostname02,hostname03" 删除 mds bash 1 2 ceph config set mon mon_allow_pool_delete true ceph fs volume rm kubernetes01 --yes-i-really-mean-it 离线安装 - Ceph Object Gateway Ceph 从 0....

本文是Ceph集群部署系列第1章 使用cephadm纯离线安装Ceph集群 使用cephadm纯离线安装Ceph集群 2 Ceph集群安装 - ceph-deploy Ceph集群安装 - ceph-deploy下线rgw 开篇常例 - 概述 Ceph 是一个广泛使用的开源存储平台。 它提供高性能、可靠性和可扩展性。 Ceph 分布式存储系统提供了对象存储、块存储和文件级存储。 Ceph 旨在提供无单点故障的分布式存储系统。 在本教程中，将通过 ceph-adm 方式在 CentOS 7 上安装和构建 Ceph 集群。该实验的 Ceph 集群需要以下 Ceph 组件： Ceph OSD (ceph-osd) - 处理数据存储、数据复制和恢复；通常一个Ceph集群至少需要两台 OSD 服务器 。 Ceph Monitor (ceph-mon) - 监视集群状态、OSD 映射和 CRUSH 映射，我们在这里与 cephadm 或 OSD 公用一个节点 Ceph 元数据服务器 (ceph-mds) - 这是使用 CephFS 所需的组件。 有了上面的条件，我们实验环境所需要的节点如下： 三台服务器节点，CentOS 7 注：CentOS 7 可安装最高级别的 ceph 版本就是 O 版...

背景 在云原生环境中，特别是基于 Kubernetes，集群中的 “服务” 在与外部交互时，例如，一个外部的第三方 Web 服务/API 等，而监控这些不同的 endpoint 诊断服务可用性的一个关键点，这里将阐述基于 Kube-prometheus-stacks 如果做到可以监控外部 IP/URL，例如，HTTP/TCP/ICMP 等。 blackbox_exporter 是 Prometheus 官方维护的 exporter之一，是提供一种用于检测 HTTP/S、DNS、TCP 和 ICMP 端点的可用性。 基于 kube-prometheus-stack 安装 blackbox 本文使用了 helm 安装的 prometheus-community/prometheus-blackbox-exporter ，在安装前，需要自行修改要启动的 prober，与是否开启默认的 servicemonitor yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 secretConfig: false config: modules: ping: prober: icmp timeout: 5s icmp: preferred_ip_protocol: "ip4" http_2xx: prober: http timeout: 5s http: valid_http_versions: ["HTTP/1.1", "HTTP/2....

Prerequisites 具有一个 Kubernetes 集群 以部署 Spinnaker 可运行 Docker 的环境 (1 vCPU, 3.75 GB) 或者是 Ubuntu，用以安装 Halyard (用于 spinnaker 的服务) 对象存储 (MinIO)，用于持久化 Spinnaker 的数据 对象存储的 Bucket 的访问账号 安装执行步骤 安装 Halyard 可以直接使用 Docker 方式安装，这个没什么必要性，就是管理工具而已，参考附录1 [1] 首先创建映射目录 bash 1 2 mkdir ~/.hal -pv mkdir ~/.kubeconfig -pv 然后执行 docker run 运行容器 bash 1 2 3 4 5 6 7 docker run -d -p 8084:8084 -p 9000:9000 \ --name halyard --rm \ -v ~/.hal:/home/spinnaker/.hal \ -v ~/....

背景 Prometheus 是目前云原生架构中监控解决方案中的基石，而对于 “metrics”，“traces” 和 “logs” 是组成云原生架构中“可观测性”的一个基础，当在扩展 Prometheus，那么 Prometheus 提供的基础架构是无法满足需求的（高可用性和可扩展性）， 而高可用性与可扩展性是满足不断增长基础设施的一个基本条件。而 Prometheus 本身并没有提供“弹性”的集群配置，也就是说，多个副本的 Prometheus 实例，对于分布在每个 Pod 上的数据也会不一致，这时也需要保证指标的归档问题。 并且在一定的集群规模下，问题的出现远远大于 Prometheus 本身的能力，例如： 如何经济且搞笑的存储历史数据（TB, PB）？如何快速的查询历史数据？ 如何合并 Promehtues 多个实例收集来的副本数据？ 以及多集群间的监控？ 由于 TSDB 的块同步，Prometheus 严重依赖内存，使得 Prometheus 监控项的扩展将导致集群中的CPU/MEM 的使用加大 .. 解决 Thanos 是一款可以使 Prometheus 获得 ”长期存储“，并具体有”高可用性“ 的 Prometheus 的功能扩展，“Thanos” 源自希腊语“ Athanasios”，英文意思是”不朽“。这也正是 ”Thanos“ 提供的功能：”无限制的对象存储“，并与原生 Prometheus API 高度兼容，你可以理解为 Thanos API 就是 Prometheus API。 Cortexmetrics 与 Thanos 类似，是用通过将 Prometheus 实例的”存储“和”查询“等功能分离到独立的组件中，实现水平扩展。它使用对象存储来持久化历史指标，块存储（TSDB）是他的存储后端；此外，Cortex 还提供了多租户与多租户隔离等功能 联邦集群，联邦集群是 Prometheus 官方提供的一个概念，使用了联邦将允许 Prometheus 从另一个 Prometheus 中抓取选定的指标。可以使用的一些模型如下： 分层联邦：大规模的集群中，Prometheus 部署模型如一个”树形“，高级别的从多个低级实例中抓取指标，并存储聚合 跨服务联邦：Prometheus 从另一个 Prometheus 只抓取指定的数据 图：Prometheus 联邦 Source：https://www....

开始前的实验环境 Resources controller worker-1 worker-2 OS CentOS 7.9 CentOS 7.9 CentOS 7.9 Storage 20GB 20GB 20GB vCPU 2 2 2 RAM 4GB 4GB 4GB NIC 10.0.0.4 10.0.0.4 10.0.0.4 Kubernetes Version 1.19.10 1.19.10 1.19.10 选择匹配 Kubernetes 版本的 Calico 版本 通常情况下，查看 Calico 所支持的 Kubernetes 版本，可以通过路径 Install Calico ==> Kubernetes ==> System requirements 可以找到自己的 Kubernetes 集群所支持的 Calico 版本。 例如在实验环境中，Kubernetes 1.19 版本所支持的版本有 Calico 3.20，这个时候直接 apply 这个版本提供的资源清单即可 如何开启纯 BGP 模式 默认情况下下，Calico 使用的是 full mesh 和 IPIP， 如果想通过在部署时就修改关闭 IPIP 模式，可以通过修改资源清单中的环境变量来关闭 CALICO_IPV4POOL_IPIP: Never。...

Spinnaker的认证 spinnaker 中提供了认证 ( Authentication) 的机制流为 Deck <=> Gate <=> Identity Provider Deck 是 spinnaker 的 WEB UI (由 apache server服务的一组静态文件) Gate 是 API Gateway，所有的进入 Spinnaker 的流量都会通过 Gate 处理，这里完成 authentication 和 authorization。 Identity Provider：用于用户身份认证的外部服务或系统，例如 LDAP, OAuth 2.0(行业标准鉴权协议), SAML, X.509 等。 更多 spinnaker Authentication 工作流可以参考 Spinnaker 认证配置 启动配置 bash 1 hal config security authn oauth2 enable --no-validate 使用 hal 命令配置 redirect URI bash 1 hal config security authn oauth2 edit --pre-established-redirect-uri https://my-real-gate-address....

spinnaker 的模板是通过 spin 命令行去创建的，spin 是 spinnaker 的套件，可以使用 spin 获取到存在的pipeline与 template，还可以创建一个新的模板或者替换就得；cli获取到的数据是 json 类型 配置spin bash 1 2 3 4 5 6 7 mkdir ~/spin # Inside the dir, setup ‘config’ file using the sample # https://github.com/spinnaker/spin/blob/master/config/example.yaml #Sample ~/.spin/config gate: endpoint: http://demospin.net:9000/gateauth: enabled: false spin 配置文件 spin 默认从 ~/spin/config 读取配置，可以通过 –config 指定 spin 的配置文件。下面是一个官方给的一个 spin config 的 example，在配置时只需要选择一个认证方式即可 iap/x.509/oauth2 这个选择的是 oauth2 json 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 33 34 35 36 37 38 39 40 41 42 43 44 45 # NOTE: Copy this file to ~/....

原作者 Javier Martínez 背景 在学习 Kubernetes 调度时，有两个重要的概念，“request “与 “limit”，而对应的资源就是“内存” 与 “CPU” ，而这两个决定了 Pod 将如何调度；“request “与 “limit” 也是整个调度系统中的基数因子。 什么是 request 和 limit 在 Kubernetes 中，Limit 是容器可以使用的最大资源量，这表示 “容器” 的内存或 CPU 的使用，永远不会超过 Limit 配置的值。 而另一方面，Request 则是为 “容器” 保留的最低资源保障；换句话来说，Request 则是在调度时，容器被允许所需的配置。 图：Kubernetes 中Limit 和 Request 图示 Source：https://sysdig.com/blog/kubernetes-limits-requests/ 如何配置 request 和 limit 下列清单是 Deployment 的部署清单，他将部署一个 redis 与 一个 busybox yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 kind: Deployment apiVersion: extensions/v1beta1 … template: spec: containers: - name: redis image: redis:5....

背景 对于整个 Kubernetes 集群来说，随着业务不断地打磨，新增指标，那么对于 Prometheus 特性来说，那么内存 与 存储的使用势必是增加。这是对于存储压力是很重的，通常情况下，使用 Prometheus，都会是用于 Kubernetes 集群中，而 应用于 Kubernetes 集中的存储势必是 PVC 之类的网络存储。 这种场景中，我将尝试拆解如何分析和配置 Prometheus 以显著的减少其资源使用并解决高基数问题 高基数 基数 (cardinality) 通俗来说是一个集合中的元素数量 [1] 基数的来源通常为： label 的数量 series(指标) 的数量 时间：label 或者 series 随时间而流失或增加，通常是增加 那么这么看来高基数就是，label, series, 时间这三个集合的笛卡尔积，那么高基数的情况就很正常了。 而高基数带来的则是 Prometheus 资源使用，以及监控的性能。下图是 Grafana Lab 提到的一张图，很好的阐述了高基数这个问题 图：Prometheus中的基数 Source：https://grafana.com/blog/2022/02/15/what-are-cardinality-spikes-and-why-do-they-matter 如图所示：一个指标 server_responses 他的 label 存在两个 status_code 与 environment ，这代表了一个集合，那他的 label value 是 1~5xx，这个指标的笛卡尔积就是10。 那么此时存在一个问题，如何能定位 基数高不高，Grafana Lab 给出了下面的数据 [1]，但是我不清楚具体的来源或者如何得到的这些值。也就是 label:value 低基数：1: 5 标准基数：1: 80 高基数：1: 10000 为什么指标会指数级增长 在以 Kubernetes 为基础的架构中，随着抽象级别的提高（通常为Pod, Label, 以及更多抽象的拓扑），指标的时间序列也越来越多。因为在这种基础架构中，在传统架构中运行的一个应用的单个裸机，被许多运行分散在许多不同节点上的许多不同微服务的 Pod 所取代。在这些抽象层中的每一个都需要一个标签，以便可以唯一地标识它们，并且这些组件中的每一个都会生成自己的指标，从而创建其独特的时间序列集。...

场景 在配置代理后，GET 请求的变量全部失效，配置如下 text 1 2 3 location /fw { proxy_pass http://127.0.0.1:2952; } 我的需求是，/fw/ 的都发往 2952端口，但实际情况是404，原因为“在没有指定 URI 的情况下，在1.12版本后会传递原有的URI” 这时会导致一个404错误，因为我的后端接口本身就是 /fw/xxx/ 会出现重复 接下来做了一个变量传递 text 1 2 3 location ~* /fw/(?<section>.*) { proxy_pass http://127.0.0.1:2952/fw/$section; } 这时存在一个问题，就是 GET 请求的变量无法传递过去 解决 nginx 官方给出一个样例，说明了，存在某种情况下，nginx 不会确定请求 URI 中的部分参数 使用正则表达式时 在 localtion 名称内 例如，在这个场景下，proxy_pass 就会忽略原有的请求的URI，而将拼接后的请求转发 text 1 2 3 4 location /name/ { rewrite /name/([^/]+) /users?name=$1 break; proxy_pass http://127.0.0.1; } 那么这服务我遇到的问题，nginx官方给出了使用方式 当在 proxy_pass 中需要变量，可以使用 $request_uri; 另外也可以使用 $is_args$args 参数 来保证原有的请求参数被传递...

vue项目部署在裸机Linux上运行正常，部署在docker中nginx出现下列错误 text 1 Nginx "rewrite or internal redirection cycle while internally redirecting to "/index.html" 表现在用户界面 500 Internal Server Error 原因：nginx配置路径不对，改成正确的后恢复

基本概念 从版本 2.4 开始，如果包包含.config.yaml ，可以使用包配置，包配置可以使用配置文件来设置包中资源通用的值，例如 API 凭证、连接详细信息、限制和阈值。这些值在运行时可供操作和传感器使用。 包配置和 Action 参数之间的区别在于，配置通常包含包中所有资源通用的值，并且很少更改。动作参数是随每个动作调用动态提供的，并且可能会发生变化 - 例如，它们可能来自映射某些输入事件的规则。 包配置遵循基础架构即代码方法，并存储在特殊目录中的 YAML 格式文件中（默认情况下 /opt/stackstorm/configs）。每个包都为此配置文件定义自己的架构。 配置 Schema 配置文件的结构是一个 YAML 格式的文件，它定义了该包的配置文件。该配置由包作者自行编写，包含有关每个可用配置项的信息，例如名称, Secret等）。该文件已命名 config.schema.yaml 并位于包目录 /opt/stackstorm/packs/<mypack> 的根目录中。 这是一个示例包配置文件： yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 --- api_key: description: "API key" type: "string" required: true api_secret: description: "API secret" type: "string" secret: true required: true region: description: "API region to use" type: "string" required: true default: "us-east-1" private_key_path: description: "Path to the private key file to use" type: "string" required: false 在该示例中，配置文件由 4 项 配置组成 (api_key, api_secret, region, private_key_path)...