调试 MinIO 安装

AJ AJ 于 DevOps 2024 年 1 月 19 日

MinIO 部署形态各异。我们支持在任何版本的 Linux 上进行裸机安装、在任何版本的 Kubernetes（包括 Red Hat OpenShift）上进行容器化安装，以及在几乎任何可以部署小型轻量级单二进制文件的地方进行安装。但灵活性也意味着不可避免地会遇到边缘情况问题，需要调试。

在这篇博文中，我们将向您展示如何调试在 Kubernetes 中运行的 MinIO 安装，以及在进行裸机安装时可能会遇到的一些常见问题以及如何解决它们。

Kubernetes 调试器 Pod

有几种方法可以访问 Kubernetes 集群中运行的 MinIO API。我们可以使用 `kubectl port-forwarding` 或设置监听 `NodePort` 的 `Service` 来访问 API。这两种方法都提供了一种从网络外部访问服务的方法，但它们也存在一个主要缺点：您只能访问 NodePort 或端口转发所引用的服务，并且只能访问可用端口（而不是应用程序的通常配置）。例如，您必须通过随机分配的 `3xxxx` 端口访问通常位于 `9000` 端口的 MinIO API。

如果我说有一种更好的方法，而且它并不新颖呢？在调试应用程序时，您需要完全访问本地运行时环境，以便使用各种工具来排查和调试集群。一种方法是启动一个“busybox”样式的 Pod，并安装调试应用程序所需的所有工具。

首先，将一个 `Pod` 启动到与您的 MinIO 安装相同的命名空间中。为此，请创建一个名为 `debugger-pod.yaml` 的 yaml 文件，其中包含以下 yaml。

apiVersion: v1

kind: Pod

metadata

name: mc

labels

app: mc

spec

containers

- image: minio/mc:latest

command

- "sleep"

- "604800"

imagePullPolicy: IfNotPresent

name: mc

restartPolicy: Always

上面的 Pod 配置正在拉取 MinIO `mc` 工具的镜像。为了确保 Pod 不只是启动然后退出，我们添加了一个 `sleep` 命令。

保存 yaml 后，将配置应用到 MinIO 集群运行的 Kubernetes 命名空间。

kubectl apply -f debugger-pod.yaml

Pod 启动并运行后，通过 shell 访问它。

$ kubectl exec -i -t -n default mc -c mc -- sh -c "(bash || ash || sh)"

[root@mc /]#

然后使用 `mc`，您可以访问 MinIO 集群。

[root@mc /]# mc alias set myminio --insecure

成功添加 `myminio`。

现在我们已经启动并运行了调试器 Pod，您可以在同一个网络中直接对集群执行操作。例如，如果由于站点离线或硬件故障导致复制中断，您可以使用以下命令将任何待复制的对象重新同步。

[root@mc /]# mc admin replicate resync start minio1 minio2

[root@mc /]# mc admin replicate resync status minio1 minio2

✔ ✔ ✔

ResyncID: 2248d1d1-633f-4d61-b938-d8ea0b9b2d31

Status: Completed

Objects: 2225

Versions: 2225

FailedObjects: 0

Throughput: 5.3 MiB/s

IOPs: 124.23 objs/s

Transferred: 94 MiB

Elapsed: 17.909833202s

CurrObjName: testbucket/web-app/tsconfig.json

您运行调试器 Pod 的另一个原因是，如果您的 Pod 中存在一些文件系统权限或无效组配置，您可以使用调试器 Pod 更新它们。

[root@mc /]# chgrp -R 1000780050 .minio.sys/

上述调试方法也适用于裸机环境。例如，您可以启动一个安装了 mc 的 busybox 或堡垒节点，并按照上述相同的说明进行操作。

调试裸机

裸机 Linux 安装是最直接的。实际上，只需几个命令即可将 MinIO 安装并运行，并使用 SystemD。有关详细信息，请参阅使用 SystemD 配置 MinIO。

偶尔，裸机安装会出错。以下是一些我们被问及的（不常见的）陷阱，SUBNET 或 Slack。这些陷阱与硬件或操作系统无关，但在任何环境中了解它们都很有用。

文件权限

最常见的陷阱之一是 MinIO 二进制文件和配置文件的文件权限。如果发生这种情况，当您使用 SystemD 启动 MinIO 时，您将看到

断言 MinIO 失败。 以下是完整的堆栈跟踪

# systemctl status minio.service

● minio.service - MinIO

已加载：已加载 (/etc/systemd/system/minio.service；已启用；供应商预设：已启用)

活动：非活动（已停用）

断言：断言在太平洋标准时间 2023 年 12 月 26 日 18:21:38 周二开始失败；8 秒前

AssertFileIsExecutable=/usr/local/bin/minio 未满足

文档：https://docs.min.io

12 月 26 日 18:13:37 minio1 systemd[1]：minio.service：已请求启动，但断言失败。

12 月 26 日 18:17:50 minio1 systemd[1]：断言 MinIO 失败。

12 月 26 日 18:21:38 minio1 systemd[1]：minio.service：已请求启动，但断言失败。

12 月 26 日 18:21:38 minio1 systemd[1]：断言 MinIO 失败。

这可能是由多种原因造成的，让我们逐个检查。

MinIO 二进制文件：在本例中位于 /usr/local/bin/minio 的二进制文件需要分别对用户和组具有 root:root 权限。

# ll /usr/local/bin/minio

共 93804

-rwxr-xr-x 1 root root 96018432 11 月 15 日 16:35 minio*

MinIO 服务用户和组：出于安全目的，MinIO 服务需要在唯一的 Linux 用户和组下运行，绝不以 root 用户身份运行。默认情况下，我们对用户和组名使用 minio-user。在 SystemD 服务配置文件中，您应该看到类似这样的内容

User=minio-user

Group=minio-user

MinIO 数据目录：存储 MinIO 数据的目录需要由 minio-user:minio-user 或您决定以其运行 MinIO 服务的任何用户拥有。

# ls -l /mnt

共 4

drwxrwxr-x 2 minio-user minio-user 4096 12 月 27 日 09:58 data

SystemD 和 MinIO 配置：两个配置文件都应该具有 root:root 权限，分别对用户和组进行如下操作

# ls -l /etc/default/minio

-rw-r--r-- 1 root root 1330 12 月 27 日 09:52 /etc/default/minio

# ls -l /etc/systemd/system/minio.service

-rw-r--r-- 1 root root 941 12 月 26 日 17:13 /etc/systemd/system/minio.service

以 Root 身份运行：整个安装过程应该以 root 身份运行。如果您的用户有权限，您也可以尝试 sudo，但建议以 root 身份运行，因为安装需要将文件放置在只有 root 用户可以访问的许多位置。您的 bash 提示符应该具有 # 而不是 $，如下所示

# vs $

如果上述方法均无效，最好的方法是删除应用程序、目录和配置，并以 root 用户身份重新开始安装。

端口冲突

另一个常见问题是与已删除但仍保留进程的文件相关的，这会导致端口冲突。即使服务未运行，您也可能无法在现有端口上启动新服务，或者正在运行的服务将出现异常行为（例如不允许您登录）。

# lsof -n | grep (deleted)

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME

nginx 13423 root 5u REG 253,3 42949672960 17 (已删除)

minio 13423 minio 6u REG 253,3 0 18 (已删除)

minio 13423 minio 7u REG 253,3 0 19 (已删除)

您可能会在 MinIO 安装上看到以下错误

登录失败 net::ERR_FAILED
500 内部服务器错误
401 未经授权

上面的屏幕截图显示了内部服务器错误和未经授权的错误。虽然从表面上看，尚不清楚是什么导致了此错误，但我们可以利用一些 Linux 知识来调试应该查找的内容以找出原因，让我们仔细看看。

有几种方法可以调试此问题，首先让我们检查一下在同一节点上是否运行了多个 MinIO 进程

# ps aux | grep -i minio

minio-u+ 5048 0.3 1.7 1594008 144384 ? Ssl 11:03 0:01 /usr/local/bin/minio server --console-address :9001 /mnt/data/disk1/minio

minio-u+ 9276 0.3 1.7 1594208 144301 ? Ssl 11:25 0:01 /usr/local/bin/minio server --console-address :9001 /mnt/data/disk1/minio

如上所示，有两个 MinIO 进程正在运行。首先，杀死较旧或运行时间最长的进程，在本例中，似乎是进程 ID 5048。

kill -9 5048

有时，即使在杀死进程后，服务仍然可能无法启动或仍然会挂起，因为它已经保留了进程号但没有释放。这可能是由于已删除但操作系统仍在跟踪的文件导致的。您可以通过 LSOF 查找已删除的文件

lsof -n | grep '(deleted)'

最后但并非最不重要的是，如果没有任何已删除的文件或挂起的进程，并且如果一切看起来都非常干净，最后的手段是快速重新启动节点。这是一种简单明了的方法，它会关闭并清除所有挂起的文件和进程，以便您重新开始安装。

SUBNET 来救援

尽管很少见，但安装边缘情况始终存在。MinIO 客户知道他们无需担心，因为他们可以通过 SUBNET 门户快速向我们的工程师（他们编写了代码）发送消息。我们已经看到了几乎所有情况，所以虽然这个问题最初看起来很神秘或令人费解，但我们会运用我们在许多不同环境中调试安装的多年专业知识来帮助您快速解决问题。

如果您在排查故障和调试 MinIO 安装方面有任何问题，请务必在 Slack 上与我们联系！