我是新来的，所以如果这是愚蠢的，请原谅我，🙂我已经在真实的硬件上使用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。

2条答案

按热度按时间

yizd12fk1#

Velero不支持OwnerReferences的恢复。

赞(0）回复(0）举报 2023-04-11

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和服务，并删除/应用计划。

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

2条答案

相关问题

热门标签

最新问答