共计 3523 个字符，预计需要花费 9 分钟才能阅读完成。
本示例演示了在 Kubernetes 上装置 WordPress 和 MySQL，这两个利用都应用 PersistentVolumes 和 PersistentVolumeClaims 保留数据。
PersistentVolume（PV）是一块集群里由管理员手动提供，或 kubernetes 通过 StorageClass 动态创建的存储。PersistentVolumeClaim（PVC）是一个满足对 PV 存储须要的申请。PersistentVolumes 和 PersistentVolumeClaims 独立于 Pod 生命周期，在 Pod 重启、从新调度或删除过程中均能保留数据。
本示例中应用的是单实例 WordPress 和 MySQL Pods，故而不适用于生产环境。
:tipping_hand_man:
本教程中提供的文件应用 GA Deployment API，并且特定于 kubernetes 1.9 或更高版本。如果您心愿将本教程与 Kubernetes 的晚期版本一起应用，请相应地更新 API 版本，或参考本教程的晚期版本。
一、教程指标
- 创立 PersistentVolumeClaims 和 PersistentVolumes
-
创立
kustomization.yaml应用- Secret 生成器
- MySQL 资源配置
- WordPress 资源配置
- 利用整个 kustomization 目录
kubectl apply -k ./ - 革除示例
二、筹备开始
你必须领有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。
如果你还没有集群，参考 用 kubeadm 在 Debian 或 Ubuntu 中创立 k8s 集群。
三、教程开始
1 创立 PersistentVolumeClaims 和 PersistentVolumes
MySQL 和 WordPress 都须要一个 PersistentVolume 来存储数据。他们的 PersistentVolumeClaims 将在部署步骤中创立。
许多集群环境都装置了默认的 StorageClass。如果在 PersistentVolumeClaim 中未指定 StorageClass，则应用集群的默认 StorageClass。
创立 PersistentVolumeClaim 时，将依据 StorageClass 配置动静设置 PersistentVolume。
在本地群集中，默认的 StorageClass 应用
hostPath供应器。hostPath卷仅实用于开发和测试。应用hostPath卷，您的数据位于 Pod 调度到的节点上的/tmp中，并且不会在节点之间挪动。如果 Pod 死亡并被调度到集群中的另一个节点，或者该节点重新启动，则数据将失落。:tipping_hand_man:
如果要建设须要应用
hostPath设置程序的集群，则必须在 controller-manager 组件中设置--enable-hostpath-provisioner标记。
因为应用 StorageClass 必须要有一个存储后端服务器，通常在云服务商中应用 Kubernetes 集群时会提供，本地环境下想要应用，还需在本地自行创立一个存储服务器或虚拟机。
这不是本教程的重点，所以本教程应用手动创立的 PersistentVolume。
前面在创立 PVC 时，mysql 和 wordpress 都会申请一个 5G 的空间，此处将每个 PV 的空间设置为 5 G：
pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: wordpress-mysql-pv-volume-1
labels:
type: local
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/tmp"
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
labels:
app: wordpress
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wp-pv-claim
labels:
app: wordpress
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress
labels:
app: wordpress
spec:
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: Recreate
template:
metadata:
labels:
app: wordpress
tier: frontend
spec:
containers:
- image: wordpress:4.8-apache
name: wordpress
env:
- name: WORDPRESS_DB_HOST
value: wordpress-mysql
- name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-pass
key: password
ports:
- containerPort: 80
name: wordpress
volumeMounts:
- name: wordpress-persistent-storage
mountPath: /var/www/html
volumes:
- name: wordpress-persistent-storage
persistentVolumeClaim:
claimName: wp-pv-claim将上述两个配置文件补充到 kustomization.yaml：
cat <<EOF >>./kustomization.yaml
resources:
- mysql-deployment.yaml
- wordpress-deployment.yaml
EOF4 利用和验证
kustomization.yaml蕴含用于部署 WordPress 网站的所有资源以及 MySQL 数据库。您能够通过以下形式利用目录：
kubectl apply -k ./4.1 验证
-
通过运行以下命令验证 Secret 是否存在
kubectl get secrets
后果：
NAME TYPE DATA AGE
mysql-pass-kkcc2b926b Opaque 1 9s-
验证是否已动静配置 PersistentVolume
kubectl get pvc
应用 StoreClass 动态创建 PV 时可能要花费几分钟，应用本地创立的 PV 很快就能够绑定。
后果：
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql-pv-claim Bound wordpress-mysql-pv-volume-2 5Gi RWO 15s
wp-pv-claim Bound wordpress-mysql-pv-volume-1 5Gi RWO 15s-
验证 Pod 是否正在运行
kubectl get pods
NAME READY STATUS RESTARTS AGE
wordpress-c9cdf4bcb-f6q8s 1/1 Running 0 2m15s
wordpress-mysql-575f8bcc5d-fhmx5 1/1 Running 0 2m15s-
验证服务是否正在运行
kubectl get services wordpress
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
wordpress LoadBalancer 10.96.85.77 <pending> 80:31927/TCP 3m55s对外公开的端口为 31927。
-
拜访 WordPress
能够应用任一节点的 IP 加上面获取到的端口进行拜访。
本例中地址为 http://192.168.31.221:31927 或 http://192.168.31.222:31927 或 http://192.168.31.231:31927。
如果应用的是云服务商，那么下面的
EXTERNAL-IP将会有一个可拜访的 IP 地址，应用此 IP 地址加上面获取到的端口即可拜访 WordPress 页面了。
5 删除示例
运行上面的命令即可删除本教程创立的示例。
kubectl delete -k ./手动删除 PV。
kubectl delete -f pv.yaml
