GLPI 10.0.18实战：5分钟搞定K8s部署与Ingress配置（含避坑指南）

GLPI 10.0.18实战：5分钟搞定K8s部署与Ingress配置（含避坑指南）

如果你正在寻找一个能打通IT资产管理、服务台工单和CMDB配置的开源解决方案，GLPI大概率已经进入了你的视野。但当你兴冲冲地打开官方文档，准备在Kubernetes里大展拳脚时，可能会发现事情没那么简单：官方没有提供容器镜像，Helm Chart是社区维护的，Ingress配置和持久化存储的选择也藏着不少“坑”。这篇文章就是为你准备的。我们不谈那些泛泛而谈的安装步骤，而是聚焦于如何在生产级的K8s环境中，用声明式的方式，快速、稳定地部署GLPI 10.0.18，并分享那些官方手册里不会告诉你的实战细节和优化技巧。目标很简单：让你在喝杯咖啡的时间里，就拥有一个可用的、配置得当的GLPI实例。

1. 部署前奏：理解架构与准备战场

在动手敲下kubectl apply之前，花几分钟理解GLPI在Kubernetes中的运行形态至关重要。这能帮你避开后续许多因“想当然”而导致的配置错误。

GLPI本质上是一个经典的LAMP（Linux, Apache, MySQL, PHP）应用。在K8s世界里，我们需要将其解耦并容器化：

• Web层：运行Apache和PHP的容器，负责处理HTTP请求和运行业务逻辑。
• 数据层：MySQL或MariaDB数据库，用于存储所有配置、资产数据和工单信息。强烈建议将其与Web层分离，使用独立的、有状态的服务（如云厂商的托管数据库服务或通过StatefulSet部署的数据库）。
• 存储层：GLPI需要持久化存储来保存上传的文件（如工单附件）、会话数据以及可能生成的报告。这部分必须通过PersistentVolume（PV）和PersistentVolumeClaim（PVC）来保障。

对于本次部署，我们将采用一个广受社区认可的第三方Helm Chart。虽然它不是官方出品，但经过了大量用户的实践检验，并且其维护者积极跟进GLPI的版本更新。使用Helm能让我们通过一份values.yaml文件集中管理所有配置，实现部署的版本化和可重复性。

注意：由于GLPI官方不提供容器镜像，选择可靠的第三方镜像源是第一步。建议优先选择Docker Hub上星标（Stars）高、更新频繁的镜像，并检查其Dockerfile是否基于安全的基础镜像（如php:8.2-apache）构建。

在开始前，请确保你的K8s集群环境已就绪：

# 检查集群节点状态
kubectl get nodes
# 确保Helm已正确安装并添加了所需的仓库
helm version
# 添加包含GLPI Chart的仓库（这里以某个社区仓库为例，实际操作时请替换为可靠的仓库地址）
helm repo add glpi-repo https://charts.你的可靠源.com
helm repo update

2. 核心部署：Helm Chart参数精讲与定制

我们假设你已经找到了一个名为glpi的Helm Chart。直接helm install是最简单的，但想要一个适合生产的部署，必须深入定制values.yaml。下面我们拆解几个最关键的配置部分。

镜像与版本控制 这是最容易出错的地方。在values.yaml中，你需要明确指定镜像仓库、标签以及拉取策略。

image:
  repository: username/glpi  # 替换为实际可用的镜像仓库
  tag: "10.0.18"             # 明确指定版本，避免使用latest标签
  pullPolicy: IfNotPresent

为什么不用latest？ 在生产环境中，使用latest标签会导致版本不可控，升级和回滚变得困难。明确指定版本号是运维的基本素养。

资源请求与限制（Resources） 不给容器设置资源限制，就像在高速公路上开车不限速，迟早会出问题。合理的资源配置能保证应用稳定，并避免单个Pod耗尽节点资源。

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "1Gi"
    cpu: "500m"

这个配置为GLPI的Web容器申请了0.25核CPU和512MB内存的初始资源，并设置了最高0.5核CPU和1GB内存的使用上限。你需要根据实际访问量和集群规模进行调整。

环境变量配置 GLPI的许多行为通过环境变量控制。以下是一些必备和推荐的设置：