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

已知问题

贡献者

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

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

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

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

如果kubeconfig"文件包含多个上下文、则使用Asta Control Center管理集群将失败

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

在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

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

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

了解更多信息