Skip to main content
本产品推出了新版本。
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

已知问题

贡献者
PDF

还原应用程序会导致 PV 大小大于原始 PV

如果在创建备份后调整永久性卷的大小，然后从该备份还原，则此永久性卷的大小将与 PV 的新大小匹配，而不是使用备份的大小。

使用特定版本的 PostgreSQL 时应用程序克隆失败

使用 BitNami PostgreSQL 11.5.0 图表时，同一集群中的应用程序克隆始终会失败。要成功克隆，请使用图表的早期或更高版本。

使用服务帐户级别 OCP 安全上下文限制（ SCC ）时应用程序克隆失败

如果在 OpenShift 容器平台集群的命名空间中的服务帐户级别配置了原始安全上下文约束，则应用程序克隆可能会失败。如果应用程序克隆失败、它将显示在Astra控制中心的受管应用程序区域中、并显示状态 Removed。请参见 "知识库文章" 有关详细信息 …​

如果在管理集群后添加了volumesnapshotclass、则应用程序备份和快照将失败

备份和快照失败、并显示 UI 500 error 在此情景中。作为临时解决策 、刷新应用程序列表。

使用设置的存储类部署应用程序后，应用程序克隆将失败

在部署应用程序并明确设置存储类后(例如、 helm install …​-set global.storageClass=netapp-cvs-perf-extreme)、之后尝试克隆应用程序时、目标集群必须具有最初指定的存储类。
将具有显式设置的存储类的应用程序克隆到没有相同存储类的集群将失败。此情况下没有恢复步骤。

如果默认的 kubeconfig 文件包含多个上下文，则使用 Astra 控制中心管理集群将失败

不能将 kubeconfig 与多个集群和上下文结合使用。请参见 "知识库文章" 有关详细信息 …​

升级到Astra Control Center 23.04后、某些Pod无法启动

升级到Astra Control Center 23.04后、某些Pod可能无法启动。对于临时解决策 、请按照以下步骤手动重新启动受影响的Pod：

  1. 查找受影响的Pod、将<namespace> 替换为当前命名空间：

    kubectl get pods -n <namespace> | grep au-pod

    受影响的Pod的结果如下所示：

    pcloud-astra-control-center-au-pod-0 0/1 CreateContainerConfigError 0 13s

  2. 重新启动每个受影响的Pod、将<namespace> 替换为当前命名空间：

    kubectl delete pod pcloud-astra-control-center-au-pod-0 -n <namespace>

在从23.04升级到23.04.2的清除阶段之后、某些Pod会显示错误状态

升级到Astra Control Center 23.04.2后、某些Pod可能会在中显示错误
与相关的日志 task-service-task-purge：

kubectl get all -n netapp-acc -o wide|grep purge

pod/task-service-task-purge-28282828-ab1cd     0/1     Error       0             48m     10.111.0.111   openshift-clstr-ol-07-zwlj8-worker-jhp2b   <none>           <none>

此错误状态表示清理步骤未正确执行。已成功整体升级到23.04.2。运行以下命令以清理任务并删除错误状态：

kubectl delete job task-service-task-purge-[system-generated task ID] -n <netapp-acc or custom namespace>

在Isio环境中、监控POD可能会崩溃

如果在Istio环境中将Astra控制中心与Cloud Insights 配对、则 telegraf-rs POD可能会崩溃。作为临时解决策，请执行以下步骤：

  1. 找到崩溃的POD：

    kubectl -n netapp-monitoring get pod | grep Error

    您应看到类似于以下内容的输出：

    NAME READY STATUS RESTARTS AGE
telegraf-rs-fhhrh 1/2 Error 2 (26s ago) 32s

  2. 重新启动崩溃的Pod、更换 <pod_name_from_output> 使用受影响POD的名称：

    kubectl -n netapp-monitoring delete pod <pod_name_from_output>

    您应看到类似于以下内容的输出：

    pod "telegraf-rs-fhhrh" deleted

  3. 确认POD已重新启动且未处于错误状态：

    kubectl -n netapp-monitoring get pod

    您应看到类似于以下内容的输出：

    NAME READY STATUS RESTARTS AGE
telegraf-rs-rrnsb 2/2 Running 0 11s

通过代理进行连接时、NetApp Cloud Insights 中不会显示受管集群

当Astra控制中心通过代理连接到NetApp Cloud Insights 时、受管集群可能不会显示在Cloud Insights 中。作为临时解决策 、在每个受管集群上运行以下命令：

kubectl get cm telegraf-conf -o yaml -n netapp-monitoring | sed '/\[\[outputs.http\]\]/c\    [[outputs.http]]\n    use_system_proxy = true' | kubectl replace -f -
kubectl get cm telegraf-conf-rs -o yaml -n netapp-monitoring | sed '/\[\[outputs.http\]\]/c\    [[outputs.http]]\n    use_system_proxy = true' | kubectl replace -f -
kubectl get pods -n netapp-monitoring --no-headers=true | grep 'telegraf-ds\|telegraf-rs' | awk '{print $1}' | xargs kubectl delete -n netapp-monitoring pod

当 Astra Trident 脱机时，应用程序数据管理操作失败，并显示内部服务错误（ 500 ）

如果应用程序集群上的 Astra Trident 脱机（并恢复联机），并且在尝试应用程序数据管理时遇到 500 个内部服务错误，请重新启动应用程序集群中的所有 Kubernetes 节点以还原功能。

了解更多信息