【k8s】k8s ConfigMap的查看和回滚

2024-09-02 本文已影响0人 Bogon

如何查看 k8s中某个工程的 ConfigMap？

$ kubectl  get  cm  -n test | grep  test-service 

test-service-202308270408-pt-test-20230824091238        1      373d
test-service-202308281401-pt-test-20230824091238        1      371d
test-service-202308281407-pt-test-20230824091238        1      371d
test-service-202308281423-pt-test-20230824091238        1      371d
test-service-202308281601-pt-test-20230824091238        1      371d
test-service-202308291500-pt-test-20230824091238        1      370d
test-service-202308312247-pt-test-20230824091238        1      368d
test-service-202308312313-pt-test-20230824091238        1      368d
test-service-202311021918-pt-test-20230824091238        1      305d
test-service-202311302333-pt-test-20231130183114        1      277d
test-service-202405172205-pt-test-20240507201033        1      108d
test-service-202405272240-pt-test-20240527191014        1      98d

你的 kubectl get cm -n test | grep test-service 输出显示了在 Kubernetes 集群中命名空间 test 下所有以 test-service 开头的 ConfigMap 对象的列表。

下面是对输出的详细解读：

输出格式解释

输出的每一行表示一个 ConfigMap 资源，包含以下信息：

ConfigMap 名称：例如 test-service-202308270408-pt-test-20230824091238。这是 ConfigMap 的完整名称，其中包含了时间戳和其他标识符。
数量：例如 1。表示 ConfigMap 的副本数量（通常 ConfigMap 不会有多个副本，所以这里都是 1）。
年龄：例如 373d。表示 ConfigMap 自创建以来的时间。d 代表天数，h 代表小时数等。

ConfigMap 名称解析

ConfigMap 名称通常是由前缀和时间戳等信息组成的。对于你的例子，名称的格式是：

前缀：test-service
时间戳：例如 202308270408，这是 ConfigMap 创建的日期和时间，格式是 YYYYMMDDHHMM。
其他标识符：例如 pt-test-20230824091238，这个部分可能用于表示某种标识符或版本信息。

输出的具体解读

test-service-202308270408-pt-test-20230824091238 1 373d
- 名称：test-service-202308270408-pt-test-20230824091238
- 数量：1
- 年龄：373d（表示这个 ConfigMap 已经存在了 373 天）
test-service-202308281401-pt-test-20230824091238 1 371d
- 名称：test-service-202308281401-pt-test-20230824091238
- 数量：1
- 年龄：371d（表示这个 ConfigMap 已经存在了 371 天）

...

test-service-202405272240-pt-test-20240527191014 1 98d
- 名称：test-service-202405272240-pt-test-20240527191014
- 数量：1
- 年龄：98d（表示这个 ConfigMap 已经存在了 98 天）

总结

ConfigMap 的创建时间 可以从名称中的时间戳部分看到。例如 202308270408 表示这个 ConfigMap 在 2023 年 8 月 27 日 04:08 创建。
年龄是从创建时间到现在的时间差。通过年龄，可以判断 ConfigMap 的存活时间。

这类信息通常用于追踪配置变更、调试和资源管理。

如何回滚到某个特定的 ConfigMap？

要回滚到某个特定的 ConfigMap，可以按照以下步骤操作：

获取目标 ConfigMap 内容：

kubectl get cm <ConfigMap-Name> -n test -o yaml > <ConfigMap-Name>.yaml

例如：

kubectl get cm test-service-202308270408-pt-test-20230824091238 -n test -o yaml > rollback-configmap.yaml

删除现有的 ConfigMap（如果需要用新的 ConfigMap 覆盖现有配置）：
```
kubectl delete cm <Current-ConfigMap-Name> -n test
```
注意：这个操作会删除现有的 ConfigMap。

应用目标 ConfigMap：

kubectl apply -f <ConfigMap-Name>.yaml -n test

例如：

kubectl apply -f rollback-configmap.yaml -n test

验证回滚：
确保应用已经正确使用了新的 ConfigMap，查看相关 Pod 的状态，确保配置生效。

这些步骤可以帮助你回滚到之前的配置状态，确保在执行操作之前对当前状态做好备份。

Kubernetes 中保留 ConfigMap（CM）的历史记录的意义

在 Kubernetes 中保留 ConfigMap（CM）的历史记录有几个重要的意义：

1. 版本管理和回滚

保留历史 ConfigMap 允许你能够在配置出现问题时回滚到之前的版本。
你可以查看不同时间点的配置变更，并根据需要恢复到特定的版本。
这对于调试和修复问题非常有用，尤其是在配置引发的错误或故障时。

2. 审计和合规

历史 ConfigMap 帮助满足审计和合规要求。
在某些环境中，保留配置历史是为了能够追踪配置变更的记录，确保能够在出现问题时追溯到原始配置。

3. 配置管理

通过保留历史记录，你可以了解配置的演变过程。
这对于调试复杂问题、分析配置变更对应用的影响、以及对应用进行优化和调整是非常有帮助的。

4. 灾难恢复

如果当前配置导致系统出现不可预料的问题或故障，保留历史 ConfigMap 可以帮助快速恢复到之前的稳定状态，从而减少系统宕机时间和业务中断。

5. 实验和验证

在某些情况下，开发人员可能需要尝试不同的配置来验证效果。
保留历史配置可以让他们在测试之后迅速恢复到稳定的配置，避免因试验配置引发的不稳定问题。

实现历史保留的方法

虽然 Kubernetes 自身不会自动保存历史 ConfigMap，但有一些方法可以实现这种需求：

命名约定：
- 通过在 ConfigMap 名称中包含时间戳或版本号来手动管理历史记录。例如，developerplatform-service-202308270408 表示某个时间点的配置。
自动化脚本：
- 使用 CI/CD 工具或 Kubernetes Operator 编写脚本，自动保存每次配置更改的历史记录，并使用一定的策略来管理历史版本。
备份工具：
- 使用 Kubernetes 备份工具（如 Velero）定期备份 ConfigMap 和其他 Kubernetes 资源。这样可以在需要时恢复到某个备份点。

总结

保留 ConfigMap 的历史记录对于有效的配置管理、故障恢复、审计和优化等都有重要意义。通过有效的版本控制和备份策略，可以确保在配置变更过程中有足够的灵活性和保障。