我是新来的，所以如果这件事很愚蠢，请原谅我，我已经在真正的硬件上使用Couchbase超过10年了。我一直致力于在Kubernetes中建立CB，这似乎很好。我也在使用Couchbase Autonomous Operator。效果很好，到目前为止功能正常，没有任何抱怨。
然而，我一直在执行集群和CB操作员的Velero备份和恢复。上周早些时候，我以为我终于可以使用它了，但最近一次尝试从Velero备份中恢复时，国会预算办公室的日志中再次出现了这样的消息：
{"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"从未出现在消息的重复列表中。这些消息每隔几秒钟就会出现在couchbase操作员pod日志中。
此外，如果我一次删除一个pod，它们将由K8或CBO重新创建(不确定)，然后它从不断重复的列表中消失。一旦我对他们所有人都这样做了，这个问题就停止了。
非常感谢您对此提出的任何想法、问题和评论
这一切都只是为了测试，这里没有任何东西是为了生产，我只是试图验证Velero确实可以备份Couchbase Operator和Couchbase Cluster，然后从下面的Schedule backup中恢复它们。
我使用默认的沙发床操作员安装2.4.0
我使用的是一个非常基本、功能强大的couchase服务器集群安装yaml
我尝试使用这个Schedule Velero备份，然后从这个备份中恢复，我希望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"在这些消息中列出，尽管吊舱确实存在。我重申，据我所知，恢复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从备份dev-everything-schedule-20230331160030创建dev-everyhing-schedule-20230331 160030
它恢复了集群和cbo，这就是我开始在couchbaseoperatorpods日志中看到日志的时候。
更新：
深入研究pods/namespaces/default/cb-dev-0000.JSON下Velero备份的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-00010002300030004的Velero备份中丢失。现在我想我发现了什么。
我不知道为什么Velero会找到这个并将其存储在一个POD的备份中，而不是所有POD。但我认为这是一条线索。。。
还在狩猎。。。
更新2：
我已经确认，Velero每次都会正确地将couchbase对象的备份存储在JSON文件中(从我目前看到的情况来看)。
然而，velero恢复几乎是随机的，不会在恢复的Couchbase pod中设置metadata.ownerReferences。有时它只在Couchbase Services和CB-dev-0000吊舱中。有时它不在他们中的任何一个身上。有时我在(过去)所有的场景中都看到过(正确吗？)。
所以这仍然是个谜，但这就是我目前的处境。我看到其他人在各种聊天/论坛上提到，他们在Velero身上也遇到过类似的问题。
我私下里希望我能找到一个缺失的参数或注释，如果我能特别强制恢复某些对象的所有者引用的话。但我还没看到。。。
正如Sathya S.所指出的，Velero似乎无法(可靠地)恢复元数据。它的备份中的OwnerReferences。
我还要补充一点，有时确实如此这就是我的困惑。至少在我的情况下，它似乎有一种模式。如果CB-dev-0000有，那么服务部门也会。但剩下的CB吊舱不会。否则，他们中的所有人都"可能"设置了它，或者没有一个。至少在我设置的示例中是这样。
Couchbase在其文档中指出，Velero备份中不包括"pod"one_answers"services"。这件事一直萦绕在我的脑海中，但我有点不相信它
事实证明，这似乎是Velero正确恢复我的Couchbase集群并避免"；Pod被忽略，没有所有者"；Couchbase操作员日志中出现的问题。
一旦我从定时备份中删除了"pod"one_answers"services"，它创建了一个备份，然后我kubectl删除了我的Couchbase集群。然后我从备份中恢复创建集群。此外，我还将注意到，我创建的Indexes和Bucket文档也已恢复。
这个问题最重要的是metadata.ownerReferences都设置正确。在回答这个问题之前，我已经做了好几次了。这似乎是最重要的事情。不要在备份中包含pod和服务。
"您可能已经注意到，pod和服务都没有备份。这是因为操作员将能够从集群ConfigMap、附加到持久卷声明的元数据以及CouchbaseCluster资源本身重新创建它们。同样，部署将能够重新创建操作员吊舱&"；~https://docs.couchbase.com/operator/current/tutorial-velero-backup.html#creating-a-velero-备份
最终，我所要做的就是从我的时间表备份"includedResources"yaml中删除pod和服务，并删除/应用时间表。
还原Velero不支持的OwnerReferences。