当前位置：首页 > article >正文

《基于 Kubernetes 的 WordPress 高可用部署实践：从 MariaDB 到 Nginx 反向代理》

article 2025/9/28 20:59:42

手把手教你用 Kubernetes 部署高可用 WordPress 博客

本实验通过 Kubernetes 容器编排平台，完整部署了一个高可用的 WordPress 网站架构，包含 MariaDB 数据库、WordPress 应用和 Nginx 反向代理三大核心组件。实验涵盖了从基础环境准备到最终服务暴露的全流程，展示了云原生技术栈在实际应用中的完整实现。

1. 网站基本架构

实验采用经典的三层架构设计：

数据层：MariaDB 数据库容器化部署
应用层：WordPress 多副本容器部署
接入层：Nginx 反向代理服务

实验环境（如果只是学习环境也可以只用一个有k8s环境的Master节点完成本实验部署）

Kubernetes 集群：1个 Master 节点 + 2个 Worker 节点
容器运行时：Docker
核心组件版本：
- Kubernetes v1.28.2
- MariaDB 10
- WordPress 5
- Nginx (Alpine 版)

2. 部署 MariaDB

（1）检查kubelet状态，确认核心组件（如 kube-apiserver）是否以 Pod 形式运行

sudo systemctl status kubeletkubectl get pods -n kube-system

（2）定义一个 MariaDB 数据库的 Kubernetes 部署

mkdir mari-ng-wd
cd mari-ng-wd/
vim maria-cm.yaml

apiVersion: v1
kind: ConfigMap
metadata:name: maria-cm
data:DATABASE: "db"USER: "wp"PASSWORD: "123"ROOT_PASSWORD: "123"

部分1：

maria-cm.yaml - ConfigMap 配置
作用：存储 MariaDB 的配置数据（以键值对形式）。
关键字段：
• DATABASE: 数据库名称（db）
• USER: 数据库用户（wp）
• PASSWORD: 用户密码（123）
• ROOT_PASSWORD: root 用户密码（123）
用途：
将数据库配置（如账号密码）与容器镜像解耦，便于灵活修改（无需重新构建镜像）。

vim maria-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:name: marialabels:app: wordpressrole: database
spec:replicas: 1selector:matchLabels:app: wordpressrole: databasetemplate:metadata:labels:app: wordpressrole: databasespec:containers:- name: mariaimage: mariadb:10ports:- containerPort: 3306envFrom:- prefix: "MARIADB_"configMapRef:name: maria-cm

部分2：

maria-deploy.yaml - Deployment 配置
作用：定义如何部署 MariaDB 容器。
关键部分：
• 镜像: mariadb:10（官方 MariaDB 10.x 版本镜像）
• 端口: 暴露 3306（MySQL/MariaDB 默认端口）
• 环境变量注入:
通过 envFrom 将 maria-cm 的所有数据以 MARIADB_ 为前缀注入容器，例如：
◦ DATABASE → MARIADB_DATABASE=db
◦ USER → MARIADB_USER=wp
◦ 其他变量同理。
MariaDB 的自动配置：
MariaDB 官方镜像会识别特定前缀（MARIADB_）的环境变量来自动初始化数据库：
1. 创建指定数据库（db）
2. 创建用户 wp 并设置密码 123
3. 设置 root 密码为 123

分别用于创建 MariaDB 数据库的配置（ConfigMap）和部署（Deployment）资源

kubectl create -f maria-cm.yamlkubectl create -f maria-deploy.yaml

（3）获取正确pod名称并查看该 Pod 容器内部的所有环境变量

# 查看 Deployment 是否正常
kubectl get deployments# 查看 Pod 名称及状态
kubectl get pods# 在指定的 Kubernetes Pod 中执行 env 命令，查看该 Pod 容器内部的所有环境变量
kubectl exec maria-88449d778-gv4c4 -- env# 最后需要查看一下mariadb的信息
kubectl get po -o wide

出现问题（如果查看成功可以跳过问题解决的这一步）：

kubectl exec maria-88449d778-gv4c4 -- env 执行失败

查看节点状态，发现节点状态异常

Master 节点：Ready，但有污点（node-role.kubernetes.io/control-plane:NoSchedule），默认不允许调度普通 Pod。

允许 Pod 调度到 Master 节点（临时方案）

让 Pod 调度到 Master：

# 去除 Master 的污点
kubectl taint nodes master node-role.kubernetes.io/control-plane:NoSchedule-

1.等待 Pod 完全启动：
ContainerCreating 表示正在拉取镜像并启动容器，稍等片刻后再次检查：

kubectl get pods -o wide

如果状态变为 Running，说明 Pod 已正常运行。
2. 进入 Pod 并验证 MariaDB：
使用正确的 Pod 名称（如 maria-88449d778-gv4c4）进入容器：

kubectl exec -it maria-88449d778-gv4c4 -- bash

在容器内验证环境变量和数据库：

echo $MARIADB_DATABASE  # 应输出 "db"
mysql -u wp -p123       # 登录 MariaDB

3. 测试数据库连接：
在 Pod 内执行以下命令验证数据库是否正常：

SHOW DATABASES;
USE db;
SHOW TABLES;

3. 部署 Wordpress

（1）定义了一个 Kubernetes 的 `ConfigMap` 对象

vim wp-cm.yamlapiVersion: v1
kind: ConfigMap
metadata:name: wp-cm
data:HOST: '10.244.0.4'     # 这个IP一定要与mariadb数据库绑定USER: 'wp'PASSWORD: '123'NAME: 'db'

这个 ConfigMap 的作用是存储与 MariaDB 数据库连接相关的配置信息，其他 Kubernetes 资源（如运行 WordPress 的 Deployment）可以通过 envFrom 等方式从这个 ConfigMap 中获取这些配置数据，以便正确连接到 MariaDB 数据库进行数据操作。

（2）定义一个 Kubernetes Deployment 对象，用于部署 WordPress 应用

vim wp-deploy.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: wordpresslabels:app: wordpressrole: web
spec:replicas: 3selector:matchLabels:app: wordpressrole: webtemplate:metadata:labels:app: wordpressrole: webspec:containers:- image: wordpress:5name: wordpressimagePullPolicy: IfNotPresentports:- containerPort: 80envFrom:- prefix: 'WORDPRESS_DB_'configMapRef:name: wp-cm

这个配置文件的核心功能是：

创建一个名为 wordpress 的 Deployment
管理 3 个运行 WordPress 的 Pod
使用 wp-cm ConfigMap 中的数据配置 WordPress 数据库连接信息
将 WordPress 容器的 80 端口暴露出来

（3）Kubernetes 集群中创建由 wp-cm.yaml 和 wp-deploy.yaml 文件定义的资源

kubectl create -f wp-cm.yaml -f wp-deploy.yaml

（4）获取当前 Kubernetes 集群中 Pod（容器组）的相关信息。

kubectl get po

4. 设置端口映射

（1）端口映射

nohup kubectl port-forward --address 0.0.0.0 deployments/wordpress 8080:80 &

当前监听127.0.0.1 上的8080是不能够被外部访问的，只能是本机；要想让外部访问到需要端口映射改为：

nohup ... & 忽略输入并将输出追加到 nohup.out，再掉到后台执行，若要关闭可以使用 fg 调到前台，使用 Ctrl+C 停止运行进程。

（2）jobs 用来查后台进程

可以看到当前后台序号为1；那么杀后台进程的方式为： kill %1 ,1为查到的后台进程序号

（3）查看监听端口信息

# 下载工具包
sudo yum install net-tools# netstat -anpt | grep 8080

netstat 输出 验证了：
- 主机的 8080 端口确实在被 kubectl 监听。
- 之前有过与其他 Pod（IP 为 10.244.0.2 和 10.244.0.3）的通信，可能是 WordPress 容器。

5. 部署 Nginx 容器

（1）修改配置文件

WordPress 网站使用了 URL 重定向，直接使用“8080”会导致跳转故障，所以为了让网站正常工作，还应该在 Kubernetes 之外启动 Nginx 反向代理，保证外界看到的仍然是“80”端口号。

vim nginx.confserver {listen 80;default_type text/html;
location / {proxy_http_version 1.1;proxy_set_header Host $host;proxy_pass http://127.0.0.1:8080;}
}

（2）启动指定容器

使用 Docker 启动了 Nginx 容器（--net=host），将 80 端口的请求转发到 127.0.0.1:8080，从而实现通过 80 端口访问 WordPress。实现Nginx 反向代理

docker run -d --name nginx --rm --net=host -v ./nginx.conf:/etc/nginx/conf.d/default.conf nginx:alpine

docker run: 这是Docker的基本命令，用于从指定的镜像启动一个新的容器。

-d: 这是“--detach”的简写，意思是让容器在后台运行。

--name nginx: 为这个容器指定一个名称，这里命名为“nginx”。

--rm: 当容器退出时自动删除容器。

--net=host: 使用主机的网络堆栈而不是Docker的默认网络堆栈。这意味着容器将使用主机的网络配置。

-v ./nginx.conf:/etc/nginx/conf.d/default.conf: 这是“--volume”参数，用于挂载文件或目录。这里，它将主机上的“nginx.conf”文件挂载到容器的“/etc/nginx/conf.d/default.conf”路径上。

nginx:alpine: 这是要运行的Docker镜像的名称和标签。

（3）访问测试WordPress

在浏览器中直接输入 http://10.1.1.85 ，Nginx 会把请求代理到 WordPress 服务，正常情况下就能进入如图所示的 WordPress 安装页面。

过程：通过浏览器访问服务器的公网 IP（如 http://10.1.1.85），Nginx 会将请求转发到 127.0.0.1:8080，最终到达 WordPress Pod。

http://10.1.1.85/wp-admin/install.php

后续自行部署网站，也可使用 PV+PVC 实现 K8S 集群数据持久化

实验结论

架构验证成功
- 实现了 WordPress (前端) + MariaDB (后端) + Nginx (反向代理) 的经典三层架构，全部运行在 Kubernetes 集群中，验证了容器化应用的灵活性和可扩展性。
- 通过 ConfigMap 分离配置与镜像，使数据库账号、密码等关键信息可动态管理。
关键技术点
- MariaDB 自动化初始化：利用 MARIADB_ 前缀环境变量自动创建数据库和用户。
- 跨 Pod 通信：WordPress 通过 ConfigMap 中的数据库 IP (10.244.0.4) 成功连接 MariaDB。
- Nginx 反向代理：解决 WordPress URL 重定向问题，对外隐藏真实端口（8080→80）。
问题与解决
- Pod 调度问题：Master 节点默认污点导致 Pod 无法调度，通过 kubectl taint 临时去除污点解决。
- 生产环境建议：
  - 使用 Secret 替代 ConfigMap 存储密码。
  - 为数据库添加 PersistentVolume 防止数据丢失。
扩展性验证
- WordPress 部署了 3 个副本（replicas: 3），验证了 Kubernetes 的横向扩展能力。