《基于 Kubernetes 的 WordPress 高可用部署实践：从 MariaDB 到 Nginx 反向代理》
手把手教你用 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.yamlapiVersion: 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.yamlapiVersion: 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 # 登录 MariaDB3. 测试数据库连接： 在 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-cmConfigMap 中的数据配置 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 容器。
- 主机的 8080 端口确实在被
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 的横向扩展能力。
-