K8S相同后端存储在2个K8S集群PVC数据直接拷贝

最新推荐文章于 2025-01-06 15:05:52 发布
原创 最新推荐文章于 2025-01-06 15:05:52 发布 · 1.8k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kubernetes #linux #docker

博客介绍了K8S集群间PVC数据拷贝的操作方法。先将nfs - server的所有目录挂载到集群1本地服务器，核实集群1的PVC数据，查看其在后端存储的名称；接着在集群2创建新的PVC并查看其在后端存储的名称；最后将集群1的PVC数据拷贝到集群2的新PVC中，同时提醒拷贝数据库最好停库操作。

k8s数据通常保存在nfs-server里面，本例子将整个nfs-server的k8s数据挂载在集群1的master机器。
集群1: gz-kubesphere-master01
集群2: gz2-k8s-master01
注意：拷贝数据库，最好停库拷贝，在线拷贝会导致数据不一致。

一、核实集群1的PVC数据

1 挂载nfs-server的所有目录到本地服务器

mount -t nfs 10.186.100.13:/volume2/EHR /mnt

2 进入/mnt即可看到nfs所有数据

cd /mnt
ls -ls
.......
monitoring-elasticsearch-data-elasticsearch-data-1-pvc-c57aac19-e76f-445d-9dbf-f7dc421cca38
monitoring-elasticsearch-master-elasticsearch-master-0-pvc-7b063b9c-124e-432b-a5bc-0f49044d7b8c
monitoring-elasticsearch-master-elasticsearch-master-1-pvc-335bba0b-abaa-4951-bee9-e06e15d3ba94
monitoring-grafana-nfs-pvc-pvc-2a8815df-e94b-492a-87ec-69d0d06baeaa
monitoring-nfs-loki-0-pvc-b7ee4997-e762-484f-9dfd-d102dda57251
monitoring-pvc-backup-mysql-pvc-48a4bb5c-0390-40c0-a397-ea4f777c2940
monitoring-pvc-mysql-0-pvc-98344a63-3801-4050-b851-46b1aafd708d
monitoring-pvc-mysql-1-pvc-aadf0550-689a-4fb8-a26e-8303078cf97b
rds-pvc-backup-mysql-pvc-154e1f91-06fa-4c21-867d-9e59d0ad7f9b
rds-pvc-mysql-0-pvc-f8badc6d-e11c-4c27-8b94-5627df0050bb
rds-pvc-mysql-1-pvc-898d9512-4068-42ab-9a01-4c0b6a905755
usopa-test-pvc-backup-mysql-pvc-4b5125a3-d338-4d1c-8b7d-ce7e56b75183
wangjinxiong
wangjinxiong-gitlab-pvc-config-pvc-41deed8d-b3c0-4f39-b986-e54abacc53ac
wangjinxiong-gitlab-pvc-data-pvc-b4d00659-0408-4f29-8178-2184c876b5d0
wangjinxiong-gitlab-pvc-logs-pvc-428ab448-6729-4b6a-b183-7d1aea6e2948
wangjinxiong-mysql0527-pvc-pvc-888d6778-b035-48d9-81bf-e5e3f4123f68
wangjinxiong-nfs-pvc1-pvc-f1e5ef44-b720-4458-bafc-5df6bc89a42b
wangjinxiong-nfs-server-pvc2-pvc-496a4757-6262-42ae-81db-99dab70cbd07
wangjinxiong-pvc0530-pvc-731be493-61b4-4ca3-a146-361fc3c20d08
work-infinity-prod-pvc-backup-mysql-pvc-c4e42d99-c7e5-47b6-b762-30ec61ddfa44
work-infinity-prod-work-infinity-prod-mysql-0-pvc-09f1410b-f0ea-4608-8d90-bc29c9559682
work-infinity-prod-work-infinity-prod-mysql-1-pvc-2e31d1d1-18e5-4527-bd63-61ef0d6787f7
work-infinity-prod-work-infinity-prod-rabbitmq1-pvc1-pvc-15b48eaa-b20f-4987-9e75-9d5c80fa9040
work-infinity-prod-work-infinity-prod-redis-pvc1-pvc-1c83a3b5-7eab-429a-b39c-021d4a3147aa
work-infinity-test-work-infinity-test-mysql-pvc1-pvc-5962b1b7-1a02-4d4d-bc0c-6a8394278d10
work-infinity-test-work-infinity-test-rabbitmq1-pvc1-pvc-5f76626d-64d8-46ce-b5c2-54e470841613
work-infinity-test-work-infinity-test-redis-pvc1-pvc-5ecd2cb1-29bf-4b2c-b7c0-1b8e42015b4c
xr-dev-mysql-pvc1-pvc-e8ef0d9e-9548-4536-b025-3b49e1e1ca79
xr-dev-redis-data-redis-master-0-pvc-e8790ffd-deb9-44e7-a854-2d620b30d8df
zhangfangrui-pvc-backup-mysql-pvc-48d34e7c-0372-405a-ab50-86d316f42708
zhangfangrui-pvc-mysql-0-pvc-3b515c4e-e360-432b-b283-3f02bb3fb0a1
zhangfangrui-pvc-mysql-1-pvc-1196f1a5-c6f9-4d18-9e7a-4b4bfcc06f0e
zhaodengke-grafana-pvc-16595777-6d34-4ae8-a2d1-a7bdcd88a371
zhaodengke-prometheus-k8s-db-prometheus-k8s-0-pvc-379e5dc7-02a9-4aa4-bb1e-1f73e99ed372

3 查看集群1的pvc，后端存储sc为nfs-synology

[root@gz-kubesphere-master01 mnt]# kubectl get pvc -n it2
NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-mysql-0          Bound    pvc-632b8acd-41ba-4231-9fb4-b1a115c44529   20Gi       RWO            nfs-synology   112d

4 查看pvc所在的pv在后端存储的名称

[root@gz-kubesphere-master01 mnt]# kubectl describe pv pvc-632b8acd-41ba-4231-9fb4-b1a115c44529
Name:            pvc-632b8acd-41ba-4231-9fb4-b1a115c44529
Labels:          <none>
Annotations:     pv.kubernetes.io/provisioned-by: nfs-provisioner-01
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    nfs-synology
Status:          Bound
Claim:           it2/pvc-mysql-0
Reclaim Policy:  Delete
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        20Gi
Node Affinity:   <none>
Message:         
Source:
Type:      NFS (an NFS mount that lasts the lifetime of a pod)
Server:    10.186.100.13
Path:      /volume2/EHR/it2-pvc-mysql-0-pvc-632b8acd-41ba-4231-9fb4-b1a115c44529
ReadOnly:  false
Events:        <none>

以上it2-pvc-mysql-0-pvc-632b8acd-41ba-4231-9fb4-b1a115c44529即为后端的目录名称
进入/mnt查看

[root@gz-kubesphere-master01 mnt]# ls -ls | grep it2-pvc-mysql-0-pvc-632b8acd-41ba-4231-9fb4-b1a115c44529
0 drwxrwxrwx 1     501 root   2972 7月   6 06:45 it2-pvc-mysql-0-pvc-632b8acd-41ba-4231-9fb4-b1a115c44529

源pvc: it2-pvc-mysql-0-pvc-632b8acd-41ba-4231-9fb4-b1a115c44529

二、集群2创建新的PVC

1 在集群2创建一个空pvc

[root@gz2-k8s-master01 /]# kubectl  get pvc -n it2-dev
NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-mysql-0          Bound    pvc-481fa4ef-3056-4286-8850-15dc07cceb0c   20Gi       RWO            nfs-synology   17m

2 查看pvc所在的pv在后端存储的名称：

[root@gz2-k8s-master01 /]# kubectl  describe pv pvc-481fa4ef-3056-4286-8850-15dc07cceb0c -n it2-dev 
Name:            pvc-481fa4ef-3056-4286-8850-15dc07cceb0c
Labels:          <none>
Annotations:     pv.kubernetes.io/provisioned-by: nfs-provisioner-01
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    nfs-synology
Status:          Bound
Claim:           it2-dev/pvc-mysql-0
Reclaim Policy:  Delete
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        20Gi
Node Affinity:   <none>
Message:         
Source:
    Type:      NFS (an NFS mount that lasts the lifetime of a pod)
    Server:    10.186.100.13
    Path:      /volume2/EHR/it2-dev-pvc-mysql-0-pvc-481fa4ef-3056-4286-8850-15dc07cceb0c
    ReadOnly:  false
Events:        <none>

it2-dev-pvc-mysql-0-pvc-481fa4ef-3056-4286-8850-15dc07cceb0c即为后端的目录名称
进入/mnt查看

cd /mnt
[root@gz-kubesphere-master01 mnt]# ls -ls | grep it2-dev-pvc-mysql-0-pvc-481fa4ef-3056-4286-8850-15dc07cceb0c
0 drwxrwxrwx 1     501 root    636 7月   6 10:02 it2-dev-pvc-mysql-0-pvc-481fa4ef-3056-4286-8850-15dc07cceb0c

目标pvc: it2-dev-pvc-mysql-0-pvc-481fa4ef-3056-4286-8850-15dc07cceb0c

三、将数据拷贝到新的PVC

cp源目录： 第一步的源pvc
cp目标目录： 第二步的目标pvc

cd /mnt
cp -r it2-pvc-mysql-0-pvc-632b8acd-41ba-4231-9fb4-b1a115c44529/* it2-dev-pvc-mysql-0-pvc-481fa4ef-3056-4286-8850-15dc07cceb0c/
K8S二进制部署详解，一文教会你部署高可用K8S集群
景天科技苑
02-07 5660
虽然kubeadm方式搭建K8S比较简单，但是对里面的原理都不清楚的话，生产中使用功能可能不便于排查故障。二进制方式部署的k8s集群比较稳定。 二进制方式搭建：在官网下载相关组件的二进制包，如果手动安装，对kubernetes理解也会更全面。 Kubeadm和二进制都适合生产环境，在生产环境运行都很稳定，具体如何选择，可以根据实际项目进行评估。
k8s集群部署springboot项目
congge
01-01 1万+
k8s集群部署springboot项目
k8s集群下mysql容器更换pvc存储迁移数据，报错InnoDB: Your database may be corrupt
jiang0615csdn的博客
01-31 2093
k8s集群下mysql容器更换pvc存储迁移数据，报错InnoDB: Your database may be corrupt
k8s跨namespace复制pvc方式之一
小末的博客
03-08 4646
前言 今天发现小伙伴把mysql的pod部署到了default命名空间下，而且已经用了好久，而恰巧我们清理k8s空间，就把他pod删了，哈哈哈哈~ default命名空间禁止部署业务pod，幸好pvc还在，那如何把default命名空间下的的pv复制到别的namespace下呢，其中有一个比较简单的办法。 复制过程 用一张图表示： ...
k8s:PV 的使用
m0_50434960的博客
03-13 593
PV 的使用 我们有通过hostPath 或者 emptyDir 的方式来持久化我们的数据，但是显然我们还需要更加可靠的存储来保存应用的持久化数据，这样容器在重建后，依然可以使用之前的数据。但是显然存储资源和 CPU 资源以及内存资源有很大不同，为了屏蔽底层的技术实现细节，让用户更加方便的使用，Kubernetes便引入了 PV 和 PVC 两个重要的资源对象来实现对存储的管理。 概念 PV 的全称是：PersistentVolume（持久化卷），是对底层的共享存储的一种抽象，PV 由管理员进行创建和配置，
PV和PVC实现Pod自动迁移、MySQL数据持久化
09-01 669
MySQL基于PV和PVC实现数据持久化 演示如何为 MySQL 数据库提供持久化存储，步骤为： 创建 PV 和 PVC。 部署 MySQL。 向 MySQL 添加数据。 模拟节点宕机故障，Kubernetes 将 MySQL 自动迁移到其他节点。 验证数据一致性。 第一步：控制节点部署NFS [root@ken1 ~]# cat /etc/exports...
k8s业务迁移与服务部署实践
MyySophia的博客
03-16 1251
在整个过程中，我们所有的操作分为了三个层面，最底层的操作系统，中间层的运行环境，上层的应用服务。除了浏览官方的helm仓库安装应用外，自定义服务部署也可以使用helm方式实现，开发者只需要按照 Helm Chart 的格式，将应用所需的资源文件包装起来，通过模版化 (Templating) 的方式将一些可变字段（比如我们之前提到的暴露哪个端口、使用多少副本）暴露给用户，最后将封装好的应用包，就完成了Helm Chart的制作，最后集中存放在统一的仓库中供其他用户浏览下载。
K8s集群搭建ansible部署脚本
04-21
我个人给公司开发的使用ansible部署k8s的脚本，支持vagrant调用ansbile，和直接ansible执行两种方式。k8s二进制组件使用最新的1.23.5 部署以下模块内容包括： preinstall 安装前准备，主机环境初始化，二进制文件...
K8s使用Ceph作为后端存储
xinhuixu博客
07-27 2042
RGW（RADOS Gateway））：对象存储网关，接口与S3和Swift兼容。Ceph是一个开源的分布式存储系统，具有高扩展性、高性能、高可靠性等特点，提。是ceph的核心概念， 服务端数据均衡和恢复的最小粒度；Ceph目前最新版本16（P版），市面上应用最广泛的是12（L版）支持对象存储、块存储和文件系统。对象存储集群，Ceph核心，实现用户数据分配、故障转移等集群操作。ceph-deploy：ceph集群部署节点，负责集群整体部署，是存储对象的逻辑分区，它规定了数据冗余的类型和对应的副本。
部署多控制节点k8s集群、删除k8s集群
m0_62958037的博客
01-06 1477
本文从使用代理以及不使用代理两种方式来搭建了一套多控制节点的k8s集群，以及如何删除重置k8s集群
k8s之持久化存储PV、PVC
WuDan_1112的博客
08-07 2836
4.1 使用explain 查看pv的定义方式查看pv的定义方式 ：FIELDS:metadata: #由于 PV 是集群级别的资源，即 PV 可以跨 namespace 使用，所以 PV 的 metadata 中不用配置 namespacename:spec4.2、查看pv定义的规格spec:nfs:（定义存储类型）path:（定义挂载卷路径）server:（定义服务器名称）accessModes:（定义访问模型，有以下三种访问模型，以列表的方式存在，也就是说可以定义多个访问模式）......
K8S中的PV&&PVC
荣山的博客
10-06 2695
K8S中的PV&&PVC
K8s持久化存储PV和PVC（通俗易懂）
热门推荐
hanjinjuan的博客
10-14 2万+
一、PV和PVC的引入 Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。 拿前面 AWS EBS 的例子来说，要使用 Volume，Pod 必须事先知道如下信息： 当前 Volume 来自 AWS EBS。 EBS Volume 已经提前创建，并且知道确切的 volume-id。 Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息： 要么询问管理员。 要么自己就是管理员。 这样就带来一个管理上的问题：应用开发人员和系统
K8s存储之（ 挂载存储、PVC/PV、回收策略）
MCB134的博客
05-29 4371
这里定义5个PV，并且定义挂载的路径以及访问模式，还有PV划分的大小。
Kubernetes 小白学习笔记（18）--集群存储-volume、PV、PVC
软件工程小施同学 的专栏
10-20 405
内容来自： https://coding.imooc.com/class/284.html
k8s pv & pvc
喝醉酒的小白
12-28 7060
ka get pvc ka get svc --service k8s pvc的使用
多个kubernetes集群如何实现共享同一个存储
weixin_45842494的博客
07-06 1551
引言 今天工作的时候想了一个问题：项目上使用的是双集群部署应用，但是使用的存储却只有一个，还起来一个怪有趣的名字，叫“多中心共享存储”。这样做的优点很明显，一个存储实现了多集群的数据共享，这个也很好理解，虽然是多个集群，但是应用却是相同的，数据理应可以共享。那么是如何做的呢？思考许久，想到了破解方法。 环境准备 服务器准备 准备了7台服务器，这些服务器在同一个网络之内，可以互相访问。6台服务器可以建两个kubernetes集群（一主两从），还有一台作为NFS文件系统的主节点。 资源分配 k8s集
基于 JuiceFS 的 KubeSphere DevOps 项目数据迁移方案
KubeSphere
09-15 603
方案背景和目的 KubeSphere 自发布以来已有 2 年之久，从 2.1.0 版本至目前最新版本 3.3。开发人员的编译构建都基于环境平台的 DevOps 功能（底层是 jenkins）实现，如果 DevOps 项目较多产生的流水线记录数据也会比较多，记录的数据存储方式默认是基于 Openebs 去做的，存储介质依赖于 ECS 宿主机 local 本地磁盘的风险是比较大的考虑到宿主机硬盘的不可靠性，随时会发生宕机导致流水线记录数据丢失造成严重影响。本教程经过本地研发平台测试通过了使用开源项目 juice
k8s后端服务没读取到配置字典
最新发布
07-15
<think>我们正在解决Kubernetes中后端服务未正确读取ConfigMap或环境变量配置的问题。根据引用内容，我们有几个关键点需要注意： 1. ConfigMap挂载到Pod中的配置文件更新问题：Kubernetes默认会在一段时间内（由kubelet的--sync-frequency参数控制，默认1分钟）将更新后的ConfigMap内容同步到Pod的挂载点。但是，应用程序可能需要重新加载配置（例如通过发送SIGHUP信号或使用热加载机制）才能生效。 2. 环境变量（ENV）在容器启动时注入，之后不会更新。因此，如果ConfigMap更新，通过环境变量注入的配置不会改变，必须重启Pod。 3. 同一个namespace中的pod的环境变量是不断累加的（这个可能是指从多个ConfigMap或Secret累加环境变量，但同样不会动态更新）。 用户的问题可能是：更新了ConfigMap后，后端服务没有读取到新的配置。 根据以上引用，我们可以总结出以下可能的原因和解决方案： 可能原因： 1. 配置是通过环境变量注入的：环境变量在容器启动时确定，不会更新。 2. 配置是通过volume挂载的，但应用程序没有重新加载配置（即使文件已经更新）。 3. kubelet同步延迟（最多1分钟，默认情况下）。 解决方案： 1. 如果使用环境变量，则必须重启Pod才能更新环境变量。可以考虑使用滚动更新（例如，修改Pod模板的注解来触发重新部署）或先缩容再扩容。 2. 如果使用volume挂载，确保应用程序能够检测文件变化并重新加载配置。如果应用程序不支持，可能需要重启Pod。 3. 为了减少同步延迟，可以调整kubelet的--sync-frequency参数（但不建议，因为会增加资源消耗，尤其在大规模集群中）。 4. 另一种方法是使用子路径（subPath）挂载单个文件，但注意：使用子路径挂载的文件在ConfigMap更新时不会被更新（除非在更新ConfigMap后删除并重新创建Pod，或者使用其他方法）。所以通常建议不使用子路径挂载，而是挂载整个目录。 引用[4]提到，即使挂载的文件更新了，应用程序可能没有重新加载。因此，我们需要确保应用程序有重新加载配置的机制。 另外，引用[3]提到，修改ConfigMap后，可以通过修改Pod的注解来触发重新部署（例如，添加一个时间戳注解），从而强制重新挂载ConfigMap。 步骤总结： 1. 确认配置的加载方式：环境变量还是文件挂载？ 2. 如果是环境变量，需要重启Pod（滚动更新、缩容再扩容等）。 3. 如果是文件挂载，检查文件是否已经更新（进入Pod查看文件内容）。 4. 如果文件已经更新，但应用程序未重新加载，需要配置应用程序的热加载功能，或者重启Pod。 5. 如果文件没有更新，检查kubelet同步状态，或者等待最多1分钟（默认）。如果不想等待，可以尝试重启Pod。 另外，引用[2]提到，在SpringBoot项目中，可以通过使用spring-cloud-kubernetes来动态刷新配置（需要应用程序支持）。这需要添加相应的依赖和配置。 因此，具体到后端服务，如果是Java SpringBoot应用，可以考虑使用spring-cloud-kubernetes的@RefreshScope来实现配置刷新（通过访问/actuator/refresh端点）。 但是，如果应用不支持动态刷新，那么只能重启Pod。 操作建议： 1. 检查Pod的配置方式（环境变量还是卷挂载）： - 环境变量：重启Pod。 - 卷挂载：检查文件是否更新。 2. 如果文件已更新，应用未重新加载，考虑添加应用的热加载支持，或者重启Pod。 3. 如果文件未更新，等待一段时间（1分钟内）或重启Pod。 强制重新挂载ConfigMap（不重启Pod）的方法：更新ConfigMap后，删除并重新创建Pod（使用滚动更新策略）或者使用以下技巧（通过修改Pod的注解来触发重新部署）： kubectl patch deployment <deployment-name> -p '{"spec":{"template":{"metadata":{"annotations":{"version/config":"'$(date +%s)'"}}}}}' 这个命令会更新部署的Pod模板，触发滚动更新，从而重新挂载ConfigMap。 注意：如果使用子路径挂载，则无法通过更新ConfigMap来更新文件（除非重启Pod，且子路径挂载的文件在容器运行期间不会更新）。因此，避免使用子路径挂载需要动态更新的配置文件。 总结排查步骤： 1. 确认ConfigMap已经更新： kubectl get configmap <configmap-name> -o yaml 2. 确认Pod是否使用了该ConfigMap（通过环境变量或卷挂载）： kubectl describe pod <pod-name> 3. 如果是环境变量，则重启Pod（例如，通过滚动更新部署）。 4. 如果是卷挂载，进入Pod查看文件内容： kubectl exec -it <pod-name> -- cat /path/to/mounted/config/file 5. 如果文件内容已经更新，但应用程序没有重新加载，则检查应用程序的配置重新加载机制。 6. 如果文件内容没有更新，等待1分钟再检查，或者重启Pod。 7. 如果应用程序不支持热加载，则只能重启Pod来使新配置生效。 8. 对于需要动态更新的场景，考虑使用支持热加载的配置方式（如Spring Cloud Kubernetes）或者使用其他配置中心（如Spring Cloud Config）。 根据引用[4]，kubelet同步配置的周期是1分钟，所以如果更新ConfigMap后立即检查，可能还没有同步到Pod，需要等待。 最后，如果用户的问题是关于环境变量的，那么必须重启Pod。 生成相关问题： 1. 如何让Kubernetes中的应用程序动态更新ConfigMap的配置？ 2. Kubernetes中ConfigMap通过环境变量和卷挂载有何区别？ 3. 如何在不重启Pod的情况下更新挂载的ConfigMap？ 4. 如何检查Kubernetes Pod中的环境变量和挂载的配置文件？ 5. 在SpringBoot应用中如何集成Kubernetes ConfigMap实现动态配置更新？</think>### Kubernetes 后端服务未读取 ConfigMap 或环境变量配置的排查指南 #### 一、核心问题分析 当 Kubernetes 后端服务未正确读取 ConfigMap 或环境变量时，通常由以下原因导致： 1. **环境变量注入时机问题** Kubernetes 在容器启动时注入环境变量，之后不会更新。若 ConfigMap 更新后未重启 Pod，环境变量值不会刷新[^1]。 *示例*： ```yaml env: - name: APP_CONFIG valueFrom: configMapKeyRef: name: my-config key: config.json ``` 2. **ConfigMap 挂载更新延迟** - 默认情况下，kubelet 每 1 分钟同步一次 ConfigMap（由 `--sync-frequency` 控制）[^4]。 - 即使文件更新，应用程序可能未主动重新加载配置（如 Nginx 需手动触发重载）[^3]。 3. **挂载方式错误** 使用 `subPath` 挂载单个文件时，ConfigMap 更新**不会**同步到容器内[^4]。 4. **配置引用错误** ConfigMap 未正确关联到 Deployment 或 Pod，或键名（Key）拼写错误。 --- #### 二、排查步骤与解决方案 ##### 1. 确认环境变量注入状态 ```bash # 检查 Pod 的环境变量 kubectl exec <pod-name> -- env | grep <变量名> # 查看 ConfigMap 内容 kubectl get configmap <configmap-name> -o yaml ``` **解决方案**： - 若环境变量未更新，需重启 Pod（滚动更新或缩容/扩容）[^1]。 - 避免依赖环境变量传递动态配置，改用卷挂载。 ##### 2. 验证 ConfigMap 挂载 ```bash # 进入容器查看挂载文件内容 kubectl exec -it <pod-name> -- cat /etc/config/<file-name> # 检查文件更新时间 kubectl exec <pod-name> -- ls -l /etc/config/ ``` **解决方案**： - 若文件未更新： - 等待 1 分钟（kubelet 同步周期）[^4]。 - 执行强制同步：删除 Pod 触发重建（需确保副本数 >1）。 - **禁用 `subPath`**： ```yaml volumes: - name: config-volume configMap: name: my-config volumeMounts: - name: config-volume mountPath: /etc/config # 直接挂载目录而非文件 ``` ##### 3. 应用程序重新加载配置 - **手动触发**： ```bash # 例如 Nginx 重载配置 kubectl exec <pod-name> -- nginx -s reload ``` - **自动热更新**： 使用工具如 `Reloader` 监控 ConfigMap 变化并自动重启 Pod： ```bash kubectl apply -f https://github.com/stakater/Reloader/releases/latest/download/reloader.yaml ``` 在 Deployment 添加注解： ```yaml metadata: annotations: reloader.stakater.com/auto: "true" ``` ##### 4. Spring Boot 集成方案 若后端服务为 Spring Boot： 1. 添加依赖： ```xml <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-client-config</artifactId> </dependency> ``` 2. 通过 `@RefreshScope` 动态更新配置： ```java @RestController @RefreshScope public class MyController { @Value("${custom.property}") private String value; } ``` 3. 访问端点刷新配置： ```bash curl -X POST http://pod-ip:port/actuator/refresh ``` [^2] --- #### 三、最佳实践 1. **优先使用卷挂载而非环境变量**： 环境变量适合静态配置，卷挂载支持动态更新[^3]。 2. **避免 `subPath` 挂载文件**： 如需挂载单个文件，改用符号链接或启动脚本拷贝文件。 3. **调整同步频率（谨慎操作）**： 修改 kubelet 参数（仅适用于测试环境）： ```bash # 编辑 /etc/kubernetes/kubelet.conf syncFrequency: 5s # 降低同步延迟，但增加节点负载[^4] ``` 4. **配置健康检查**： 添加 `readinessProbe` 检测配置加载状态： ```yaml readinessProbe: exec: command: ["/bin/sh", "-c", "test -f /etc/config/validated"] initialDelaySeconds: 5 periodSeconds: 5 ``` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值