调试 MinIO 的专业技巧：解决 Kubernetes 和裸机环境中的常见问题

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 安装相同的命名空间中。为此，请使用以下 yaml 创建一个名为debugger-pod.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 Added `myminio` successfully.

现在我们已经启动并运行了调试器 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 或 bastion 节点，然后按照上述相同的说明进行操作。

调试裸机

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

裸机安装偶尔会出错。以下是我们在安装过程中被问到的一些（不太常见的）陷阱子网或者松弛。这些陷阱与硬件或操作无关，但在任何环境下了解它们都是有用的。

文件权限

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

Assertion failed for MinIO.以下是完整的堆栈跟踪

# systemctl status minio.service ● minio.service - MinIO Loaded: loaded (/etc/systemd/system/minio.service; enabled; vendor preset: enabled) Active: inactive (dead) Assert: start assertion failed at Tue 2023-12-26 18:21:38 PST; 8s ago AssertFileIsExecutable=/usr/local/bin/minio was not met Docs: https://docs.min.io Dec 26 18:13:37 minio1 systemd[1]: minio.service: Starting requested but asserts failed. Dec 26 18:17:50 minio1 systemd[1]: Assertion failed for MinIO. Dec 26 18:21:38 minio1 systemd[1]: minio.service: Starting requested but asserts failed. Dec 26 18:21:38 minio1 systemd[1]: Assertion failed for MinIO.

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

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

 # ll /usr/local/bin/minio total 93804 -rwxr-xr-x 1 root root 96018432 Nov 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 total 4 drwxrwxr-x 2 minio-user minio-user 4096 Dec 27 09:58 data

SystemD 和 MinIO 配置：两个配置文件都应具有用户和组的root:root权限，如下所示

# ls -l /etc/default/minio -rw-r--r-- 1 root root 1330 Dec 27 09:52 /etc/default/minio # ls -l /etc/systemd/system/minio.service -rw-r--r-- 1 root root 941 Dec 26 17:13 /etc/systemd/system/minio.service

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

#与$对比

如果以上方法均不起作用，最好的方法是删除应用程序、目录和配置，然后以 root 用户身份重新开始安装。

端口冲突

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

 # lsof -n | grep (deleted) COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME nginx 13423 root 5u REG 253,3 42949672960 17 (deleted) minio 13423 minio 6u REG 253,3 0 18 (deleted) minio 13423 minio 7u REG 253,3 0 19 (deleted)

你可能会在 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

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

kill -9 5048

有时，即使终止了进程，服务仍可能无法启动或仍可能挂起，因为它保留了进程号但未释放它。这可能是由于已删除但仍被操作系统跟踪的文件造成的。您可以通过 LSOF 找到已删除的文件

lsof -n | grep '(deleted)'

最后但同样重要的是，如果没有遗留已删除的文件或挂起的进程，并且一切看起来都非常干净，那么最后的办法就是快速重启节点。这是一种实用的方法，可以关闭并清除所有挂起的文件和进程，以便您开始全新安装。

SUBNET 来救援

虽然很少见，但安装边缘情况总是存在的。MinIO 客户知道他们无需担心，因为他们可以通过以下方式快速向我们编写代码的工程师发送消息：子网门户。我们几乎见识过世间一切，因此尽管问题乍一看可能显得神秘或令人难以置信，但我们将利用我们多年来在各种环境中调试安装的经验，在短时间内为您提供帮助。