Kubernetes 上的 Couchbase Autonomous Operator 报告 Pod 被忽略，Velero 恢复后没有所有者

问：

我是新来的，所以如果这很愚蠢，请原谅我🙂，我已经在真正的硬件上使用 Couchbase 超过 10+ 年了。我一直在努力在 Kubernetes 中建立 CB，这似乎工作得很好。我也在使用 Couchbase Autonomous Operator。效果很好，到目前为止没有正常运行的抱怨。

但是，我一直在努力执行集群和CB Operator的Velero备份和还原。我以为上周早些时候我终于让它工作了，但最近一次尝试从 Velero 备份恢复再次导致 CBO 日志中出现这样的消息：

{"level":"info","ts":1680529171.8283288,"logger":"cluster","msg":"Reconcile completed","cluster":"default/cb-dev"}                                       
{"level":"info","ts":1680529172.0289326,"logger":"cluster","msg":"Pod ignored, no owner","cluster":"default/cb-dev","name":"cb-dev-0002"}
{"level":"info","ts":1680529172.0289645,"logger":"cluster","msg":"Pod ignored, no owner","cluster":"default/cb-dev","name":"cb-dev-0003"}
{"level":"info","ts":1680529172.0289707,"logger":"cluster","msg":"Pod ignored, no owner","cluster":"default/cb-dev","name":"cb-dev-0001"} 
{"level":"info","ts":1680529172.0289757,"logger":"cluster","msg":"Pod ignored, no owner","cluster":"default/cb-dev","name":"cb-dev-0004"}

我试图找到这到底意味着什么。我有一些怀疑，但我不知道如何解决它。

在上面的 msg 中值得注意的是，“cb-dev-0000”从未出现在重复的 msg 列表中。这些消息每隔几秒钟就会出现在 couchbase-operator pod 日志中。

此外，如果我一次删除一个 pod，它们将由 K8s 或 CBO（不确定）重新创建，然后它会从不断重复的列表中消失。一旦我对所有这些人这样做，这个问题就会停止。

对此的任何想法、问题和评论将不胜感激

目前，这仅用于测试，这里没有任何内容用于生产，我只是想验证 Velero 确实可以备份 Couchbase Operator 和 Couchbase Cluster，然后从下面的计划备份中恢复它们。

我正在使用 2.4.0 使用默认的 couchbase 运算符安装

我正在使用一个非常基本的、功能强大的 couchase 服务器集群安装 yaml

我尝试使用此 Schedule Velero Backup，然后从此备份中恢复，我希望 Couchbase Cluster 和 Couchbase Operator 都能毫无问题地恢复。

但是发生的情况是，我得到了一个功能性的 CB 集群，以及一个不断记录消息的 CBO，如下所示：

{"level":"info","ts":1680529171.8283288,"logger":"cluster","msg":"Reconcile completed","cluster":"default/cb-dev"}                                       
{"level":"info","ts":1680529172.0289326,"logger":"cluster","msg":"Pod ignored, no owner","cluster":"default/cb-dev","name":"cb-dev-0002"}
}

这可能很重要，我不知道我从未在这些消息中看到“cb-dev-0000”，因为 pod 确实存在。我重申，据我所知，恢复CB集群在附近“正常”运行，CB操作员是唯一报告这些类型错误的人。

kubectl 应用 -f schedule.yaml

其中 schedule.yaml 包含以下内容：

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: dev-everything-schedule
  namespace: velero
spec:
  schedule: 0 * * * *
  template:
    metadata:
      labels:
        velero.io/schedule-name: dev-everything-schedule
    storageLocation: default
    includeClusterResources: true
    includedNamespaces:
    - kube-public
    - kube-system
    - istio-system
    - velero
    - default
    - cert-manager
    - kube-node-lease
    excludedResources:
    includedResources:
    - authorizationpolicies.security.istio.io
    - backuprepositories.velero.io
    - backupstoragelocations.velero.io
    - backups.velero.io
    - certificaterequests.cert-manager.io
    - certificates.cert-manager.io
    - cert-manager-webhook
    - challenges.acme.cert-manager.io
    - clusterissuers.cert-manager.io
    - clusterrolebindings.rbac.authorization.k8s.io
    - clusterroles.rbac.authorization.k8s.io
    - configmaps
    - controllerrevisions
    - couchbaseautoscalers.couchbase.com
    - couchbasebackuprestores.couchbase.com
    - couchbasebackups.couchbase.com
    - couchbasebuckets.couchbase.com
    - couchbaseclusteroauths
    - couchbaseclusters.couchbase.com
    - couchbasecollectiongroups.couchbase.com
    - couchbasecollections.couchbase.com
    - couchbaseephemeralbuckets.couchbase.com
    - couchbaseevents
    - couchbasegroups.couchbase.com
    - couchbasememcachedbuckets.couchbase.com
    - couchbasemigrationreplications.couchbase.com
    - couchbasereplications.couchbase.com
    - couchbaserolebindings.couchbase.com
    - couchbasescopegroups.couchbase.com
    - couchbasescopes.couchbase.com
    - couchbaseusers.couchbase.com
    - cronjobs
    - csidrivers
    - csistoragecapacities
    - customresourcedefinitions.apiextensions.k8s.io
    - daemonsets
    - deletebackuprequests
    - deletebackuprequests.velero.io
    - deployments
    - destinationrules.networking.istio.io
    - downloadrequests.velero.io
    - endpoints
    - endpointslices
    - eniconfigs.crd.k8s.amazonaws.com
    - envoyfilters.networking.istio.io
    - events
    - gateways
    - gateways.networking.istio.io
    - horizontalpodautoscalers
    - ingressclassparams.elbv2.k8s.aws
    - ingresses
    - issuers.cert-manager.io
    - istiooperators.install.istio.io
    - item_istiooperators
    - item_wasmplugins
    - jobs
    - leases
    - limitranges
    - namespaces
    - networkpolicies
    - orders.acme.cert-manager.io
    - peerauthentications.security.istio.io
    - persistentvolumeclaims
    - persistentvolumes
    - poddisruptionbudgets
    - pods
    - podtemplates
    - podvolumebackups.velero.io
    - podvolumerestores.velero.io
    - priorityclasses.scheduling.k8s.io
    - proxyconfigs.networking.istio.io
    - replicasets
    - replicationcontrollers
    - requestauthentications.security.istio.io
    - resourcequotas
    - restores.velero.io
    - rolebindings.rbac.authorization.k8s.io
    - roles.rbac.authorization.k8s.io
    - schedules.velero.io
    - secrets
    - securitygrouppolicies.vpcresources.k8s.aws
    - serverstatusrequests.velero.io
    - serviceaccounts
    - serviceentries
    - serviceentries.networking.istio.io
    - services
    - sidecars.networking.istio.io
    - statefulsets
    - targetgroupbindings.elbv2.k8s.aws
    - telemetries.telemetry.istio.io
    - telemetry
    - validatingwebhookconfiguration.admissionregistration.k8s.io
    - virtualservices.networking.istio.io
    - volumesnapshotlocations.velero.io
    - wasmplugins.extensions.istio.io
    - workloadentries.networking.istio.io
    - workloadgroups.networking.istio.io
    ttl: 12h

我 kubectl 删除集群和操作员，然后使用如下方式从 Velero 备份中恢复它们：

velero restore create dev-everything-schedule-20230331160030 --from-backup dev-everything-schedule-20230331160030

它恢复了集群和 cbo，这时我开始在 couchbase-operator pod 日志中看到日志。

更新：

深入研究 pods/namespaces/default/cb-dev-0000.json下的 Velero Backup 的 JSON 文件并将其与cb-dev-0001.json进行比较，我刚刚发现了可能与此问题相关的主要差异：

{
    "apiVersion": "v1",
    "kind": "Pod",
    "metadata": {
        ...
        "name": "cb-dev-0000",
        "namespace": "default",
        "ownerReferences": [
            {
                "apiVersion": "couchbase.com/v2",
                "blockOwnerDeletion": true,
                "controller": true,
                "kind": "CouchbaseCluster",
                "name": "cb-dev",
                "uid": "xxxxxxx-xxxx-xxxx-xxxx-xxxxxx"
            }
        ],
        "resourceVersion": "xxxxxxx",
        "uid": "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"
    }
    ...
}

现在 cb-dev-0001（CBO 中不断记录的其中之一）也是如此

{
    "apiVersion": "v1",
    "kind": "Pod",
    "metadata": {
        ...
        "name": "cb-dev-0001",
        "namespace": "default",
        "resourceVersion": "xxxxxxx",
        "uid": "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"
    }
    ...
}

cb-dev-0001、0002、0003、0004 的 Velero 备份中缺少 ownerReferences。现在我想我正在做一些事情。

我不知道为什么 Velero 会发现这个并将其存储在一个 POD 的备份中，而不是所有 POD。但我认为这是一条线索......

还在打猎......

更新2：

我已经确认 Velero 每次都正确地将 couchbase 对象的备份存储在其 JSON 文件中（从我目前所看到的）。

但是，velero restore 几乎随机地没有在还原的 Couchbase pod 中设置 metadata.ownerReferences。有时它只在 Couchbase 服务和 CB-dev-0000 pod 中。有时它不在他们中的任何一个中。有时我（过去）在所有这些场景中看到过（正确吗？

所以这仍然是一个谜，但这就是我目前所处的位置。我看到其他人在各种聊天/论坛上提到他们在使用 Velero 时遇到了类似的问题。

我暗暗希望我能找到一个缺失的参数或注释，因为我可以专门强制恢复某些对象的ownerReferences。但我还没有看到......