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

wqsoz72f  于 2023-04-11  发布在  Kubernetes
关注(0)|答案(2)|浏览(81)

我是新来的,所以如果这是愚蠢的,请原谅我,🙂我已经在真实的硬件上使用Couchbase超过10年了。我一直在努力在Kubernetes中建立CB,似乎工作得很好。我也在使用Couchbase Autonomous Operator。工作得很好,到目前为止没有任何抱怨,功能正常。
然而,我一直在执行群集和CB操作员的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"}

我试着找出这到底意味着什么。我有一些怀疑,但我不知道如何解决它。
在上面的消息中值得注意的是,'cb-dev-0000'从未出现在消息的循环列表中。这些消息每隔几秒就会出现在couch base-operator pod日志中。
此外,如果我一次删除一个pod,它们将被K8s或CBO重新创建(真实的),然后它从不断重复的列表中消失。一旦我对所有pod都这样做,这个问题就停止了。
任何想法,问题,意见,这将是真的非常感谢
这一切都只是为了在这一点上测试,这里没有什么是生产,我只是试图验证Velero确实可以备份治疗床操作员和治疗床集群,并随后从下面的计划备份恢复它们。
我使用的是默认的Couchbase Operator安装,使用的是2.4.0
我使用的是一个非常基本的,功能齐全的couchase服务器集群安装yaml
我尝试使用此计划Velero备份,然后从该备份中恢复,我希望治疗床群集和治疗床操作员都能顺利恢复。
但实际情况是,我得到了一个功能正常的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'列在这些msgs tho的pod确实存在。我重申恢复CB集群是功能'正常'附近,因为我可以告诉,和CB操作员是唯一的事情报告这些类型的错误。
kubectl apply -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,这时我开始看到couch操作员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恢复几乎是随机的,没有在恢复的Couchbase pod中设置metadata.ownerReferences。有时它只在Couchbase Services和CB-dev-0000 pod中。有时它不在任何一个pod中。有时我在(过去)看到在所有pod中设置了metadata. ownerReferences(正确?)。
所以这仍然是一个谜,但这就是我到目前为止的情况。我看到其他人在各种聊天/论坛上提到他们在Velero上遇到了类似的问题。
我偷偷地希望我能找到一个丢失的参数或注解,这样我就可以特别地强制为某些对象恢复ownerReferences。

yizd12fk

yizd12fk1#

Velero不支持OwnerReferences的恢复。

nr7wwzry

nr7wwzry2#

正如Sathya S.所指出的,Velero似乎不能(可靠地)从它的备份中恢复元数据。

**我会补充一点,有时它会这样做。**这就是让我感到困惑的地方。至少在我的情况下,它似乎有一个模式。如果CB-dev-0000有它,那么服务也会。但是剩下的CB pod不会。否则所有的CB pod都“可能”设置了它,或者没有。至少在我在这里设置的例子中是这样。

Couchbase在他们的文档中提到不包括Velero备份中的“pod”和“services”。这一直在我的脑海中,但我有点不相信它。
事实证明,这对于Velero正确恢复我的Couchbase集群并避免Couchbase操作员日志中出现的“Pod被忽略,没有所有者”问题似乎至关重要。
一旦我从我的定时备份中删除了'pods'和'services',它创建了一个备份,然后我kubectl删除了我的Couchbase集群。然后我velero restore create --from-backup和wah-lah集群出现了。此外,我还注意到我创建的索引和Bucket文档也被恢复了。
这个问题最重要的是metadata.ownerReferences都设置正确。在回答这个问题之前,我已经这样做过几次了。这似乎是重要的事情。不要在备份中包括pod和服务。
“您可能已经注意到,没有备份Pod和服务。这是因为Operator将能够从群集ConfigMap、附加到永久卷声明的元数据以及CouchbaseCluster资源本身重新创建它们。同样,部署将能够重新创建Operator Pod。”~https://docs.couchbase.com/operator/current/tutorial-velero-backup.html#creating-a-velero-backup
最终,我所要做的就是从我的计划备份'includedResources' yaml中删除pod和服务,并删除/应用计划。

相关问题