共计 5237 个字符，预计需要花费 14 分钟才能阅读完成。
作者：宇轩辞白，运维研发工程师，目前专一于云原生、Kubernetes、容器、Linux、运维自动化等畛域。
前言
2023 年 7 月 23 日在我的项目上线前夕，K8s 生产环境呈现故障，通过紧急修复之后，K8s 环境恢复正常；另外咱们环境引入了 KubeSphere 云原生平台技术，为了不便研发人员对于 K8s 权限的细粒度治理，我方手动将 K8s Namespace（生产环境业务命名空间）退出到 KubeSphere 中的 Workspace（企业空间），就在此时，产生了让人后背一凉、极度可怕的事变，就是生产命名空间（Namespace）被主动删除了，相熟 K8s 的人都晓得，这意味着该命名空间下的所有数据，都被清空了。
问题简述
事变的前因后果
咱们我的项目环境有两套 K8s 集群（即生产 / 测试），两套 K8s 环境筹备结束之后，别离在两套 K8s 引入 KubeSphere 云原生平台，打算通过 KubeSphere 启用多集群模式去治理两套 K8s：生产 K8s 集群将设置为 Host 主集群，测试环境 K8s 设置为 Member 集群。在此期间所有准备就绪，就等次日正式对外上线。
在 2023 年 7 月 22 号早晨七点非常，突然收到研发人员反馈：测试环境 KubeSphere 平台无奈失常应用，数据库都无奈关上。
随后我开展排查，发现整个 KubeSphere 平台都瘫痪了。通过确认，是因第三方客户技术人员做资源克隆，间接性影响了生产环境。
排查未果，情急之下我间接卸载了 KubeSphere 进行重装，重装之后临时复原了失常。随后我将两套 K8s 集群重新加入到 KubeSphere 平台托管，再将 K8s 的 Namespace 退出到 KubeSphere 所创立好的 WorkSpace 进行治理。
就在此刻，我发现退出到 WorkSpace 的 Namespace 竟在顷刻间主动删除，以致我 NameSpace 下的所有生产数据资源全副失落。我认为是 Workspace 的问题，因而重建新的 Workspace 测试进行测试，后果同样被删除。
此时此刻，我心想，坏了出小事了！
集群环境
- Kubesphere 3.3.1
- K8s v1.22
[root@k8s-master01 ~]# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
[root@k8s-master01 ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master01 Ready,SchedulingDisabled <none> 51d v1.22.0
k8s-master02 Ready,SchedulingDisabled <none> 51d v1.22.0
k8s-master03 Ready,SchedulingDisabled <none> 51d v1.22.0
k8s-node01 Ready <none> 51d v1.22.0
k8s-node02 Ready <none> 51d v1.22.0
k8s-node03 Ready <none> 51d v1.22.0
k8s-node04 Ready <none> 12d v1.22.0
k8s-node05 Ready <none> 12d v1.22.0
[root@k8s-master01 ~]# kubectl get cluster
NAME FEDERATED PROVIDER ACTIVE VERSION
host true KubeSphere true v1.22.0
test-host true v1.22.0
[root@k8stst-master01 ~]# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
[root@k8stst-master01 ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8stst-master01 Ready,SchedulingDisabled <none> 58d v1.22.0
k8stst-master02 Ready,SchedulingDisabled <none> 58d v1.22.0
k8stst-master03 Ready,SchedulingDisabled <none> 58d v1.22.0
k8stst-node01 Ready <none> 58d v1.22.0
k8stst-node02 Ready <none> 58d v1.22.0剖析排查
故障演示
创立一个名为 testv1 的 Namespace，而后将其退出到名为 ws1 的 Workspace 中。
将 testv1 调配至 ws1 下，点击确定右上角就呈现了谬误提醒。
role.rbac.authorization.k8s.io"admin" not fount
这示意在 K8s 集群中没有找到名为 admin 的 KubeSphere role。这个谬误通常产生在试图为 KubeSphere 增加或配置角色时，应用了一个不存在的角色名称。此时咱们持续往下看。
退出之后你会发现，Namespace 已处于主动删除状态中。
而后我发现方才创立的 Namespace testv1 这个命名空间的确被删除了。
而且这个删除是彻底的，在 Etcd 中都找不到丝毫痕迹。
随后我进一步开展排查，想通过 kubefed-controller-manager pod 日志寻找一些有价值的线索。
#kubectl -n kube-federation-system get pod
NAME READY STATUS RESTARTS AGE
kubefed-admission-webhook-6f9f5dcbbf-8krrp 1/1 Running 1 (13d ago) 13d
kubefed-controller-manager-78c4dbc5f8-bbqj6 1/1 Running 0 11d
kubefed-controller-manager-78c4dbc5f8-qvsrb 1/1 Running 0 11d
#kubectl -n kube-federation-system logs -f kubefed-controller-manager-78c4dbc5f8-qvsrb你能够手动模仿将 Namespace 退出到 Workspace 的同时，实时输入
kubefed-controller-manager日志信息。
能够看到，在 Namespace 退出 Workspace 之后，Namespace 就被干掉了。
最初我查看了 KubeSphere Workspace 的状态，发现 Workspace 不稳固，从景象上看 Host 集群中 Workspace 被不停的创立和删除。
分析判断
首先咱们能够将问题范畴放大至 KubeSphere 多集群治理这里，该性能应用了 Kubefed 这个组件，思考以下几点疑难：
- 问题 1：为什么重装了 KubeSphere 之后会呈现这种状况呢？难道是我卸载之后再重装，该环境没有彻底清除洁净？
- 问题 2：什么状况会导致创立一个 Namespace 退出到 Workspace 之后会被删除掉呢？
- 问题 3：这外面的逻辑是什么样的呢？
以上，我带着疑难翻阅了 KubeSphere 多集群治理 Kubefed 托管的相干官网，得悉，Kubefed 托管是指在 KubeSphere 平台上通过 Kubefed 控制器来治理和操作多个 K8s 集群的联邦个性：
- Kubefed 控制器：Kubefed 是一个 K8s 控制器，用于提供联邦个性，使得多个 K8s 集群能够联结治理。Kubesphere 通过部署 Kubefed 控制器来实现对多集群的联邦治理。
- 联邦 API 服务器：Kubefed 控制器在每个 K8s 集群上启动一个联邦 API 服务器。这些联邦 API 服务器互相通信，用于治理联邦资源和配置。
- 联邦配置：在 KubeSphere 中配置联邦相干的资源，例如联邦命名空间、联邦服务、联邦正本集等。这些联邦资源将通过联邦 API 服务器进行同步和治理。
- 联邦管制：Kubefed 控制器会周期性地查看联邦资源的状态和配置，并依据配置的策略主动进行同步和调度。例如，当创立一个联邦正本集时，Kubefed 控制器会将该正本集在各个联邦集群中进行创立和调度。
- 跨集群资源拜访：通过联邦个性，能够在一个集群中拜访和治理其余集群的资源。在 KubeSphere 中，能够通过联邦命名空间和联邦服务来实现跨集群的资源拜访和通信。总而言之，KubeSphere Kubefed 托管通过部署 Kubefed 控制器和联邦 API 服务器，联合联邦配置和管制机制，实现了对多个 K8s 集群的联邦治理和操作。
验证问题猜测
通过剖析，我有了一点点脉络。很有可能以后的主集群 Host 被多个 Kubefed 托管产生了抵触。但为什么产生抵触？可能过后卸载 KubeSphere 没有清理洁净：过后删除只是通过脚本清理了 KubeSphere-system 相干 pod，然而 Kubefed 相干资源没有清理掉，当重新配置新 Host 集群的时候，导致以后的 Host 集群被多个 Kubefed 托管产生了抵触。
一个是以后集群的 Kubefed，因创立的 Workspace 关联了 Host 集群，所以 Kubefed 会在 Host 上创立出 Workspace，然而在此之前，这个 Host 集群也被另外一个 Kubefed 进行托管，因为创立进去的 Workspace 带有 kubfed.io/managed: 'true' 这个标签，此时就会产生抵触，导致 Workspace 不停的被创立和删除。
为了验证该猜测，我把以后集群中的 Kubefed controller 进行（可设置为 0），而后再手动创立一个 Workspace 并打上 kubfed.io/managed: 'true' 标签，验证一下是否依然被删除。
#kubectl get deployment -n kube-federation-system
进行以后 kubefed controller
#kubectl scale deployment kubefed-controller-manager --replicas=0 -n kube-federation-system
deployment.apps/kubefed-controller-manager scaledDeployment 正本控制器设置为 0 之后，再手动将 Namespace 退出 Workspace。此时发现 Namespace 没有被删除，Workspace 也没有呈现一直创立删除等景象。
最初咱们再将设置为 0 的 Kubefed controller 还原回来。
问题解决
通过上述验证发现：将以后的 kubefed controller-manager 停掉，而后再创立的 Workspace 在退出了 Namespace 之后，没有持续被删除，等再将 Kubefed controller 还原之后，Workspace 又呈现之前的景象。
此时就能够判定，除了以后 Host 集群中的 Kubfed 之外，很有可能原始 Host 集群的 Kubfed 没有被删除。也就是说两个雷同的 Host Kubefed 同时托管以后的 Host 集群，自然而然就会对以后 Host 集群产生了影响，究其原因，在起初卸载 KubeSphere 环境的时候，没有正确的将 Kubefed Host 集群中移除，当新的 Kubefed Host 起来之后，就会造成抵触。
此时咱们通过 kubectl get kubefedclusters.core.kubefed.io -n kube-federation-system 能够看到两个 cluster，别离是以后的 Host cluster 和 Member cluster，以后的 Host 集群（能够了解为集群中部署的 Kubfed 治理了本人）和 Member 集群都被托管到了 Host 集群中部署的 Kubfed，并通过 KubeSphere 进行治理。
查看 kubefed 联邦集群的信息
#kubectl get kubefedclusters.core.kubefed.io -n kube-federation-system 通过 api 地址来判断以后是否异样的 host cluster
#kubefedclusters.core.kubefed.io -n kube-federation-system -o yaml最得当的方法就是将原始的 Kubefed cluster 删除：
#kubectl delete kubefedclusters.core.kubefed.io produce-trt -n kube-federation-system
此时你会发现，问题失去解决。
总结
通过本次事变，我学习了很多，意识到了本人的有余。我依然须要在云原生这个畛域去深耕积淀。
对于运维来讲，我感觉遇到问题是一件侥幸的事件。只管这些问题会让你解体甚至自我狐疑，但却是一个个成长的契机。运维的外围竞争力就是解决问题的能力。
遇到问题，你须要搞清楚外面的逻辑原理，这样能力更好的解决。所以，解决问题的过程也是一个学习的过程。
本文由博客一文多发平台 OpenWrite 公布！
