跳至主要内容

集群操作员故障排除

使用这些信息来解决 RabbitMQ 集群 Kubernetes 操作员的常见问题。

请注意，以下信息可能对 Kubernetes 部署中的“自行操作” (DIY) RabbitMQ 有帮助，但这些环境不是其主要关注点。

常见情况和错误​

某些错误有专门的部分

RabbitMQ 集群无法部署​

创建 RabbitMQ 实例后，它在几分钟内不可用，并且 RabbitMQ Pod 无法运行。

此类故障的常见原因是

  • 集群中的 CPU 或内存不足
  • imagePullSecrets 配置不正确。这会阻止从 Docker 注册表拉取镜像。
  • storageClassName 配置不正确。

解决此问题的潜在解决方案

  • 运行 kubectl describe pod POD-NAME 查看是否有任何警告（例如：0/1 nodes are available: 1 Insufficient memory.）。
  • 更正 imagePullSecrets 和 storageClassName 配置。请参阅 imagePullSecrets、持久性 和 更新 RabbitMQ 实例。
  • 如果在更新上述配置后问题仍然存在，请按照 检查实例的状态 中的过程查看 RabbitMQ 集群资源的状态。

如果部署到资源受限的集群（例如，本地环境，如 kind 或 minikube），您可能需要调整集群的 CPU 和/或内存限制。查看 资源限制示例，了解如何操作。

Pod 无法创建​

如

pods POD-NAME is forbidden: unable to validate against any pod security policy: []

作为 Kubernetes 操作员部署的底层 ReplicaSet 的事件，或作为 RabbitmqCluster 的底层 StatefulSet 的事件。

如果为 Kubernetes 集群启用了 Pod 安全策略准入控制，但您尚未创建必要的 PodSecurityPolicy 和相应的基于角色的访问控制 (RBAC) 资源，则会发生这种情况。

可能的解决方案是按照 Pod 安全策略 中的过程创建 Pod 安全策略和 RBAC 资源。

Pod 在启动时重启​

RabbitMQ 容器可能会在 Pod 启动时失败并记录一条消息，例如

epmd error for host rabbitmq-server-1.rabbitmq-nodes.mynamespace: nxdomain (non-existing domain)

或

Error during startup: {error,no_epmd_port}

Pod 会重启，并最终变为 Ready 状态。

由于 RabbitMQ 节点 在引导期间解析其自身和对等主机名，因此 CoreDNS 缓存超时可能需要从默认的 30 秒减少 到 5-10 秒范围内的值。

处于 CrashLoopBackOff 状态的 Pod​

由于 Kubernetes 会重启失败的 Pod，如果 RabbitMQ 节点无法启动，它可能会进入 CrashLoopBackOff 状态 - 它尝试启动、失败并再次重启。在这种情况下，如果需要访问 Pod 或其数据，可能难以调试或解决问题。

在某些情况下，您知道可以通过启动一个新的节点来解决问题，该节点会从集群中的其他节点同步所有内容。以下是您可以执行的操作

以下过程将完全删除 Pod（RabbitMQ 节点）及其磁盘。这意味着该节点上的数据将丢失。请确保您了解后果。

  1. kubectl rabbitmq pause-reconciliation RMQ_NAME（或者，如果您没有 kubectl-rabbitmq 插件/CLI，则添加一个标签）- 这意味着操作员不会“修复”（覆盖）对底层对象的手动更改。
  2. kubectl delete statefulset --cascade=orphan RMQ_NAME-server - 删除 statefulset，使其不会“修复”Pod（在我们删除它后重新创建丢失的 Pod）。
  3. kubectl delete pod RMQ_SERVER-server-2（您可以在这里删除任何 Pod）。
  4. kubectl delete pvc RMQ_NAME-server-2
  5. kubectl delete pv PV_NAME（如果需要）（这将完全删除先前的磁盘/数据）。
  6. kubectl rabbitmq resume-reconciliation RMQ_NAME（或删除标签）- 操作员通过重新创建 StatefulSet 来修复部署，而 StatefulSet 会重新创建丢失的 Pod 和 PVC。

您也可以将此过程适应其他情况 - 例如，与其删除磁盘，您可以启动一个 Pod 并将卷附加到它以调查其内容。

此过程的唯一 RabbitMQ 特定部分是第一步和最后一步。 详细了解如何暂停 RabbitmqCluster 协调。其他命令是常见的 Kubernetes 管理任务。

Pod 卡在终止状态​

症状：“删除 RabbitmqCluster 实例后，一些 Pod 卡在终止状态。RabbitMQ 仍在受影响的 Pod 中运行。”

原因：“可能的原因是 RabbitMQ 中遗留的仲裁队列。”

解决此问题的潜在解决方案

  • 确保队列中没有消息，或者删除这些消息是可以接受的。
  • 通过运行以下命令强制删除队列
kubectl delete pod --force --grace-period=0 POD-NAME

此示例使用 Pod 名称

kubectl delete pod --force rabbit-rollout-restart-server-1
# warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
# pod 'rabbit-rollout-restart-server-1' force deleted

要查看实例的状态，请运行以下命令

kubectl -n NAMESPACE get all

其中 NAMESPACE 是实例的 Kubernetes 命名空间。

例如

kubectl -n rmq-instance-1 get all
# NAME                   READY   STATUS    RESTARTS   AGE
# pod/example-server-0   1/1      Running   0          2m27s
<br/>
# NAME                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                        AGE
# service/example-nodes      ClusterIP   None             None        4369/TCP                       2m27s
# service/example            ClusterIP   10.111.202.183   None        5672/TCP,15672/TCP,15692/TCP   2m28s
<br/>
# NAME                             READY   AGE
# statefulset.apps/example-server  1/1     2m28s

集群操作员在启动时失败​

部署 RabbitMQ 集群操作员后，它在启动过程中失败，并且其 Pod 被重启。

此类故障的常见原因是

  • 操作员无法连接到 Kubernetes API。

解决此问题的潜在解决方案

  • 检查操作员是否仍在崩溃。Pod 重启解决了许多临时问题，因此重启是一个症状，而不是问题。
  • 检查操作员日志（kubectl -n rabbitmq-system logs -l app.kubernetes.io/name=rabbitmq-cluster-operator）。
  • 您可能会看到类似以下错误
    • 无法获取 API 组资源
    • Get https://ADDRESS:443/api: connect: connection refused
  • 检查您的 Kubernetes 集群是否正常运行，尤其是 kube-apiserver 组件。
  • 检查是否有任何安全网络策略会阻止操作员访问 Kubernetes API 服务器。

RabbitMQ 集群状态条件​

RabbitMQ 实例具有 status.conditions，用于描述 RabbitMQ 集群的当前状态。要获取状态，请运行

kubectl describe rmq RMQ_NAME

示例状态条件可能如下所示

Name:         test-rabbit
Namespace:    rabbitmq-system
API Version:  rabbitmq.com/v1beta1
Kind:         RabbitmqCluster
...
Status:
  Binding:
    Name:  sample-default-user
  Conditions:
    Last Transition Time:  2023-07-07T11:57:10Z
    Reason:                AllPodsAreReady
    Status:                True
    Type:                  AllReplicasReady # true when all RabbitMQ pods are 'ready'
    Last Transition Time:  2023-07-07T11:57:10Z
    Reason:                AtLeastOneEndpointAvailable
    Status:                True
    Type:                  ClusterAvailable # true when at least one RabbitMQ pod is 'ready'
    Last Transition Time:  2023-07-07T11:55:58Z
    Reason:                NoWarnings
    Status:                True
    Type:                  NoWarnings
    Last Transition Time:  2023-07-07T11:57:11Z
    Message:               Finish reconciling
    Reason:                Success
    Status:                True
    Type:                  ReconcileSuccess
...

如果状态条件 ReconcileSuccess 为 false，则意味着最后一次协调失败，并且 RabbitMQ 集群配置可能已过期。查看集群操作员日志以了解协调失败的原因。

要获取操作员日志

kubectl -n rabbitmq-system logs -l app.kubernetes.io/name=rabbitmq-cluster-operator
© 2024 RabbitMQ. All rights reserved.