为什么选择 GitHub 作为 YUM 仓库？ 免费托管：GitHub 提供免费的文件存储和 HTTP 服务。 CDN：结合 jsDelivr 等 CDN 服务，可以加速用户的访问速度。 无成本：无需自己搭建服务器，降低维护成本。 使用便利：可以一条命令完成安装，无需再上传安装包了，也可以用来制作下线版本的 yum 仓库。 基本思路 YUM 仓库的核心是文件索引（repodata）和 HTTP 服务。GitHub 提供静态文件托管和 HTTP 访问支持，可以作为 YUM 仓库的存储平台。此外，可以通过 CDN 服务（如 jsDelivr）加速访问（可选）。 存储：将 RPM 包和仓库索引文件存储在 GitHub 仓库中。 访问：通过 GitHub 的 raw 文件访问路径或 jsDelivr 提供 HTTP 服务。 生成索引：使用 createrepo 工具生成 YUM 仓库的元数据（repodata）。 步骤 1：生成 repodata 安装 createrepo 工具 确保已安装 createrepo 工具，用于生成 YUM 仓库的元数据。 bash 1 sudo yum install createrepo -y 创建目录结构 为不同发行版（这里为 CentOS 7 和 Rocky 9）创建对应的目录结构：...

背景 在一次物理机断电回复后，Kubernetes 集群因断电或其他原因导致 etcd 启动时出现 “panic: lease ID must be 8-byte” 错误。本文记录如何诊断和修复 etcd 数据损坏，并恢复 Kubernetes 集群的过程。 问题描述 在尝试启动 etcd 服务时，日志显示以下错误： bash 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 46 47 48 49 50 51 {"level":"warn","ts":"2025-06-26T08:46:12....

本文是CoreDNS 开发系列第4章 CoreDNS 开发系列-1：CoreDNS核心概念和安装配置说明 CoreDNS 开发系列-2：CoreDNS插件详解 CoreDNS 开发系列-3：开发自定义插件 CoreDNS 开发系列-4：高并发域名平台架构设计 在本章节中将创建一个项目，旨在构建一个基于 CoreDNS 的域名系统，该项目目的是可以构建一个完整的 DNS 平台而不是管理平台，可以作为独立的 DNS Provider 运行业务域名解析；也可以作为企业内部 DNS的使用。 分层架构设计 系统采用四层架构设计： 视图层：也称为 API 层，负责提供 DNS 的管理后台， API 接口。 业务层：主要作为 CoreDNS Plugins 实现，用于集成 DNS Server。 数据层：视图层与业务层的联动，多数据库支持（SQLite/MySQL/PostgreSQL）、Redis 缓存、数据同步。 基础设施层：提供 command line 工具，并为 DNS Server 提供四层防火墙、监控告警数据。并提供整个公司生态的服务注册、服务发现等功能。 系统功能需求 功能模块 详细描述 优先级 View 支持多视图配置，智能解析 高 Zone 管理 DNS 区域管理与配置 高 域名管理 管理域中的域名解析 高 Transfer 与云 DNS 供应商数据同步 高 白名单 域名解析黑白名单控制，包含全局和单域名 高 证书管理 Let’s Encrypt 证书自动申请与续期 高 解析切换 提供多解析功能，实现故障切换 高 域名检测 域名可用性检测，可以配合切换功能完成故障自动切换 高 CDN 集成 CDN 切换与管理功能 中 运维工具 提供命令行工具 中 GeoIP 基于地理位置的智能 DNS 解析 低 外部系统注册 服务自动注册与发现 低 性能需求 性能指标 目标值 备注 QPS 100,000 一个 view 内的集群至少达到的值 项目分模块设计 视图层 模块名称 功能描述 域、域名管理 完成基础 Zone, Domain的管理功能 证书管理 Let’s Encrypt 证书自动申请与续期 View管理 管理域与业务层插件进行联动 白名单管理 域名解析黑白名单控制 Geo 管理 基于地理位置的智能 DNS 解析 CDN 集成 集成CDN联动功能 服务注册插件 提供全企业内的服务注册功能（View+业务） 业务层 模块名称 功能描述 实现方式 DNS 服务 DNS 查询处理、插件加载管理 原生 coredns 数据库 Zone, Domain 信息入库，通过库 Custom Plugin Redis 缓存插件 Zone, Domain 的热点缓存功能 Custom Plugin GeoIP 插件 基于地理位置的智能解析 Custom Plugin View View 的管理和配置 Custom Plugin 白名单 域名访问控制 Custom Plugin Transfer 区域传送与同步 Custom Plugin 基础设施层 模块名称 功能描述 实现技术 服务发现 服务注册与发现 Nacos DNS查询流程设计 多级缓存策略...

本文是CoreDNS 开发系列第3章 CoreDNS 开发系列-1：CoreDNS核心概念和安装配置说明 CoreDNS 开发系列-2：CoreDNS插件详解 CoreDNS 开发系列-3：开发自定义插件 CoreDNS 开发系列-4：高并发域名平台架构设计 在上一篇文章中，我们了解了 CoreDNS 的基本概念、安装和配置文件的说明，与 CoreDNS 中的插件，本文将从零开始，深入学习 CoreDNS 插件开发的完整流程，让您能够开发出满足特定业务需求的高质量插件。在最后我们学习一下 CoreDNS 中的外部插件用以引入开发思路，来解决我们平台中的一些难点。 代码构成 在学习开发插件之前，我们先需要了解下 CoreDNS 的代码目录构成。 text 1 2 3 4 5 6 7 8 9 10 11 coredns/ ├── core/ # 核心组件 │ ├── dnsserver/ # DNS 服务器实现 │ └── plugin/ # 插件管理框架 ├── plugin/ # 内置插件目录 │ ├── cache/ # 缓存插件 │ ├── forward/ # 转发插件 │ ├── kubernetes/ # Kubernetes插件 │ └── ....

需求分析 openvpn在调研时不支持分流配置，需求是openvpn的开启不要影响现有的网络环境。在经过调研，发现 openvpn配置文件可以使用一些指令来指定访问某些地址的路由经过openvpn的设备，这样就可以实现了流量分流。 配置指令说明 这里主要用到了下面的参数 指令 说明 dhcp-option 添加额外的网络参数，可以是在客户端配置，或者服务端推送，这里有指定 DNS redirect-gateway def1 使用这个 def1 flag 可以使用0.0.0.0/1 and 128.0.0.0/1 来覆盖默认路由，这里的好处是不会擦除原有的默认网关 route 可以在建立连接后，自动添加一些路由，并且在TUN/TAP设备关闭后，自动销毁 gateway 默认来自 第二参数或者默认网关，第二参数为 vpn_gateway 指远端的vpn地址 net_gateway 指 per-existing IP默认网关 route-nopull 当在客户端使用时，此选项有效禁止从Server将路由添加到客户端的路由表中，但是请注意，此选项仍然允许 Server 设置TCP/IP 客户端TUN/TAP接口的属性 （这里主要用作创建openvpn自己的网络接口）。 pull-filter 忽略server端push 的资源，这些选项就是来自 —pul 或者其他选项的，例如其他选项 dhcp-option/route/gateway 等。 最终的配置为 text 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 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 client proto udp explicit-exit-notify remote x....

问题描述 当获取了 EKS kubeconfig 后，使用该 kubeconfig 提示如下报错 bash 1 2 $ kubectl get pod --kubeconfig kubeconfig error: You must be logged in to the server (Unauthorized) 但该 IAM 用户已经存在了管理员权限了 问题原因 该文章有对这个问题进行描述 quote 您不是集群创建者 如果您的 IAM 实体未用于创建集群，说明您不是集群创建者。在这种情况下，请完成以下步骤，将您的 IAM 实体映射到 aws-auth ConfigMap 以允许访问集群 [1] 这里检查和文章描述一致, 但还是这样的问题 bash 1 2 3 4 5 6 $ aws sts get-caller-identity { "UserId": "AIDAXxxxxxxxIIWKMR22Q", "Account": "55555555496", "Arn": "arn:aws:iam::55555555496:user/eks-user" } quote 这是因为，必须将该用户作为集群的 Access 进行关联，而不是授权 “EKS*” 相关权限 图 - 集群用户 选择已经存在的 IAM 用户...

插件说明 Jenkins 有一个 aws credentials 插件，可以关联到 pipeline 中使用 https://plugins.jenkins.io/aws-credentials/ 官方也有给出示例，如何使用 pipeline 关联 ecr text 1 2 3 withCredentials([[ $class: 'AmazonWebServicesCredentialsBinding', credentialsId: 'plt-ia-dev-images-ecr-use1-read', roleArn: 'arn:aws:iam::130312249203:role/PullDockerImages', roleSessionName: 'PullDockerImages']]){ sh "aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin ecr_registry } 配置过程 创建一个 iam 用户，用于 jenkins 获取 ecr token使用 图 - IAM User 图创建用户 - 创建ecr-user note 不要选择 “Provide user access to the AWS Management Console - optional ” 权限可以选择 “AmazonEC2ContainerRegistryFullAccess”， 也可根据自己需求进行选择...

本文是CoreDNS 开发系列第2章 CoreDNS 开发系列-1：CoreDNS核心概念和安装配置说明 CoreDNS 开发系列-2：CoreDNS插件详解 CoreDNS 开发系列-3：开发自定义插件 CoreDNS 开发系列-4：高并发域名平台架构设计 在上一篇文章中，我们了解了 CoreDNS 的基本概念、安装和配置文件的说明。在本文将深入探讨 CoreDNS 的插件 (Plugins)，这是 CoreDNS 强大功能的核心所在。通过理解插件机制和核心插件的工作原理，我们将为后续开发自定义插件和构建 DNS 平台奠定坚实基础。 插件系统设计理念 通常情况下，CoreDNS Plugins在设计上围绕下面的原则进行的 单一职责：每个插件只负责自己负责的功能 链式处理：插件按配置顺序执行链处理请求 可插拔性：插件可以灵活组合和替换 扩展性：支持用户自定义插件开发插件来扩展功能 基于这些原则，使得 CoreDNS 非常强大，非常易于扩展性（对比与最流行的两款开源 DNS 产品来说，Bind, PowerDNS）。 CoreDNS与主流DNS服务产品的对比 下表是调研了三款最流行的 DNS 开源产品来对最符合本项目的后端作为对比，CoreDNS的灵活性相对比较适宜 特性 CoreDNS BIND9 PowerDNS 类型 权威/递归 权威/递归 权威/递归 AXFR/IXFR 支持 支持, trasfer 插件 支持 支持 view 支持（geo, view插件） 原生支持（view 指令） 支持（仅仅LMDB后端） 数据库支持 支持（通过自定义插件 mysql, redis） 有限 DLZ模块 (Dynamically Loadable Zones) [1] 原生有限支持 [2] DNSSEC 支持（NSEC） 全面支持（NSEC/NSEC3） 全面支持（NSEC/NSEC3） 扩展性 极佳（插件架构） 有限扩展，支持c语言库作为plugins 良好 易用性 高（简单配置，现代化） 中（配置复杂，需经验） 高（Web 界面、API） 社区与生态 活跃（CNCF 项目，Kubernetes 生态） 非常活跃（ISC 维护） 活跃（商业支持） 与本项目需求契合度 极高（插件化支持View, AXFR/IXFR, GEO） 高（原生支持VIEW, AXFR/IXFR） 高（数据库支持强，API 同步简单） CoreDNS插件的类型 CoreDNS插件分为两种类型插件，“In-tree Plugins” [3] 和 “External Plugins” [4]；“In-tree Plugins” 是 CoreDNS 官方在提供 coredns 二进制文件时就内置编译到程序内的插件，用户可以自己去配置使用这些插件；“External Plugins” 是包含 CoreDNS 官方与三方作者维护的插件，用户如果想使用的话，需要自行编译 coredns 版本使用。...

下载 openssh-9.9p 源码包 下载地址 下载之后解压看 README 和 INSTALL text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 libcrypto from either of LibreSSL or OpenSSL. Building without libcrypto is supported but severely restricts the available ciphers and algorithms. - LibreSSL (https://www.libressl.org/) 3.1.0 or greater - OpenSSL (https://www.openssl.org) 1.1.1 or greater LibreSSL/OpenSSL should be compiled as a position-independent library (i.e. -fPIC, eg by configuring OpenSSL as "....

本文是CoreDNS 开发系列第1章 CoreDNS 开发系列-1：CoreDNS核心概念和安装配置说明 CoreDNS 开发系列-2：CoreDNS插件详解 CoreDNS 开发系列-3：开发自定义插件 CoreDNS 开发系列-4：高并发域名平台架构设计 CoreDNS 概述 什么是CoreDNS CoreDNS 是一个由 Go 编写的灵活、可扩展的 DNS 服务器。他非常灵活，几乎全部功能都由 plugin 来实现，CoreDNS 官网也有说 “CoreDNS is powered by plugins.” 。Plugins 能够作为 “独立” 或和 CoreDNS “共同” 来执行 “DNS Function” 在 CoreDNS 中被设计为是一个由 “软件实现的 CoreDNS Plugin API”，例如 Kubernetes Provider 可以提供在 k8s 集群里的服务发现。再例如 file 可以提供作为一个 DB 来使用。 CoreDNS 的设计与 与 Caddy 一样也是通过 “插件” 进行扩展，并原生支持 Prometheus 也是 CoreDNS 的一大优势，这意味着我们可以将其连接到现有的 Prometheus 基础架构中进行监控、警报和仪表板管理。 CoreDNS 核心架构 Server：负责监听 DNS 查询请求 Plugins Chain：按照配置顺序串联起来的插件序列 Handler：每个插件实现的请求处理器 Middleware：在请求处理过程中的中间件 DNS 请求在 CoreDNS 中的处理流程如下：...

创建 Dockerfile, 因为需要 aws 命令，就不特别去安装了，直接使用 awslinux 的镜像 docker 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 FROM amazonlinux:2 RUN yum update -y && \ yum install -y awscli jq && \ yum clean all WORKDIR /app COPY refresh-ecr-credentials.sh ENV AWS_REGION=${AWS_REGION:-us-east-1} ENV REFRESH_INTERVAL=${REFRESH_INTERVAL:-3600} ENV CREDENTIALS_DIR=${CREDENTIALS_DIR:-/shared_credentials} ENV AWS_CREDENTIALS_FILE=${AWS_CREDENTIALS_FILE:-/opt/password} RUN mkdir -p ${CREDENTIALS_DIR} ~/.aws /opt && \ chmod 700 ${CREDENTIALS_DIR} ~/.aws /opt && \ chmod +x /app/refresh-ecr-credentials....

Amazon ECR 目前不支持镜像存储库的自动创建。当开发人员向 Amazon ECR 推送一个新进项，如果与其对应的存储库不存在，推送就会失败。Amazon ECR 相比起其他公有云，他的镜像是必须要求 dockerhub.io/test/nginx:version, 这里 nginx 才会被是为一个镜像存储库，而 GCP 的 Artifact registry 是 test (Project )才会被视为一个镜像存储库。这样对于存储仓库就不需要额外创建了。 下文阐述 Amazon ECR创建仓库的方法 方法1：awscli awscli 中有 create-repository 子命令，允许用户创建一个仓库 bash 1 aws ecr create-repository --repository-name ${REPO_NAME} 可以使用脚本来检测仓库是否存在 [1] bash 1 2 3 4 5 6 7 8 9 output=$(aws ecr describe-repositories --repository-names ${REPO_NAME} 2>&1) if [ $? -ne 0 ]; then if echo ${output} | grep -q RepositoryNotFoundException; then aws ecr create-repository --repository-name ${REPO_NAME} else >&2 echo ${output} fi fi 或 [1]...

原理 通常 Pod 体面终止的过程为：kubelet 先发送一个带有体面超时限期的 TERM（又名 SIGTERM，根据参数terminationGracePeriodSeconds来决定） 信号到每个容器中的主进程，将请求发送到容器运行时来尝试停止 Pod 中的容器。 停止容器的这些请求由容器运行时以异步方式处理。 这些请求的处理顺序无法被保证。许多容器运行时遵循容器镜像内定义的 STOPSIGNAL 值， 如果不同，则发送容器镜像中配置的 STOPSIGNAL，而不是 TERM 信号。 一旦超出了体面终止限期，容器运行时会向所有剩余进程发送 KILL 信号，之后 Pod 就会被从 API 服务器上移除。 如果 kubelet 或者容器运行时的管理服务在等待进程终止期间被重启， 集群会从头开始重试，赋予 Pod 完整的体面终止限期。 通常终止流程按照下面约束进行： 如果 Pod 中的容器之一定义了 preStop 回调 且 Pod 规约中的 terminationGracePeriodSeconds 未设为 0， kubelet 开始在容器内运行该回调逻辑。默认的 terminationGracePeriodSeconds 设置为 30 秒. 如果 Pod 未定义 preStop 回调，根据默认的 terminationGracePeriodSeconds 设置为 30 秒。进行 kill -9（无论terminationGracePeriodSeconds 有没有配置） 如果 preStop 回调在体面期结束后仍在运行，kubelet 将请求短暂的、一次性的体面期延长 2 秒。即 30 + 2 s 后删除Pod。...

ceph版本 nautilus 处理过程 查看 ceph 集群状态 bash 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 ceph -s cluster: id: baf87797-3ec1-4f2c-8126-bf0a44051b13 health: HEALTH_WARN 3 osds down 1 host (3 osds) down 1 pools have many more objects per pg than average Degraded data redundancy: 1167403/4841062 objects degraded (24.115%), 391 pgs degraded, 412 pgs undersized services: mon: 3 daemons, quorum 10....

问题描述 当在使用 docker login 登录 ECR 时需要获取对应的密钥，而在 aws 中可以运行 aws ecr get-login 以获取登录的密钥。这里存在的问题是，AWS ECR 的密钥有效期是 12 小时，必须做到每 12 小时轮换一次。在配置时，就需要解决 clouddriver 可以实时使用最新密钥登录来获取镜像仓库中容器版本。那么问题就变成了：如何可以解决这个限制并允许 Spinnaker 与 AWS ECR 交互？ 问题参考 ecr-token-refresh 在实施过程中，参考了 “Using AWS ECR with Spinnaker and Kubernetes” [1] 文章，这篇文章属于官方博客。在这里提到一个方法：“使用 sidecar 来间接刷新 aws ecr 密钥，来完成 clouddriver 可以正常获取密钥。 这里提到的一个项目 ”ecr-token-refresh“ [2] ，这是作者自己编写的一个程序，该程序会定期刷新 ecr 的身份验证令牌。 在参考这个项目实施时，官方提示是下面配置，但和其他传统的 spinnaker 镜像仓库的配置是相同的，要让 --password-file 是动态的。 bash 1 2 3 4 5 $ hal config provider docker-registry account add my-docker-registry \ --address https://<aws-account-number>....

本文是关于深入理解Kubernetes网络原理系列第3章 深入理解Kubernetes Pod网络原理 - 网络名称空间 深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术 深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理 深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 概述 这是我在 kubernetes 网络之旅中的中的第4部分，主要学习 CNI 规范（5要素，旧版本是4要素）。要深深记住这些，在后面旅程中常常被用到。 Notes 本文讲解均按照 1....

本文说明如何使用 Windows 10 创建单节点的 kind 集群 (KinD Kubernetes in Docker)。 先提条件 条件 版本 操作系统：Windows 10 或 Windows 11 May 2020 Update (build 19041) Docker in WSL2 推荐安装Docker Desktop WSL2 distro 镜像 这里采用Debian 内存 至少 8GB 内存 方式1：直接使用 docker desktop进行安装 软件 版本 Docker Desktop 4.8.1 WSL Linux Ubuntu 22 kubectl 使用 wsl ubuntu 22 作为客户端 安装 Docker Desktop 首先完成 Windows 开启 WSL2 和 安装好 Docker Desktop, 可以参考附录1 [1] 安装 kubectl 这里使用和 kind 版本一致的 kubectl 1....

filebeat helm chart 在配置 filebeatConfig 想配置成多配置文件模式，但是网上没有找到对应配置，单配置文件模式如下所示 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 filebeatConfig: filebeat.yml: | filebeat.inputs: - type: container paths: - /var/log/containers/*.log processors: - add_kubernetes_metadata: host: ${NODE_NAME} matchers: - logs_path: logs_path: "/var/log/containers/" output.elasticsearch: host: '${NODE_NAME}' hosts: '["https://${ELASTICSEARCH_HOSTS:elasticsearch-master:9200}"]' username: '${ELASTICSEARCH_USERNAME}' password: '${ELASTICSEARCH_PASSWORD}' protocol: https ssl.certificate_authorities: ["/usr/share/filebeat/certs/ca.crt"] 在网上有找到一个配置 [1] 是讲启用 filebeat module yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 filebeatConfig: filebeat....

loki的部署模式 grafana loki 在 helm 中版本变化很大，理解部署模式有助于快速 run 一组 loki 服务；loki 服务是一个单体二进制文件运行的微服务架构模式，具体运行的角色通过 -target 参数来区分运行什么组件。 单体模式 单体模式又称整体模式，源自官网 (Monolithic mode)，这个模式指的是 -target=all 时运行的服务。需要注意的是单体模式下，每天读写量为 20GB. Monolithic mode is useful for getting started quickly to experiment with Loki, as well as for small read/write volumes of up to approximately 20GB per day. [1] 该模式下loki 所有的组件都为二进制文件或者容器作为单一进程运行。 SSD SSD (Simple Scalable deployment mode) 简单可扩展部署模式，是 loki 对内部组件进行分类，当参数 target 我i -target=write , -target=read, -target=backend 时，是作为 SSD mode 启动。其中 write 和 backend 是有状态服务，read 是无状态服务。...

[转载] Hugo博客添加标签云 —— 素履coder...