版本更新描述

在基于版本2的基础上继续优化 WordPress 网站的部署，其中的关键是让数据库 MariaDB 实现数据持久化。

架构图

网站的整体架构图变化不大，前面的 Nginx、WordPress 还是原样，只需要修改 MariaDB：

因为 MariaDB 由 Deployment 改成了 StatefulSet，所以我们要修改 YAML，添加“serviceName”“volumeClaimTemplates”这两个字段，定义网络标识和 NFS 动态存储卷，然后在容器部分用“volumeMounts”挂载到容器里的数据目录“/var/lib/mysql”，从而实现持久化。

优化步骤

修改MariaDB

# maria-sts.yml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: maria-sts
  name: maria-sts
		
spec:
  # headless svc
  serviceName: maria-svc

  # pvc
  volumeClaimTemplates:
  - metadata:
      name: maria-100m-pvc
    spec:
      storageClassName: nfs-client
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 100Mi

  replicas: 1
  selector:
    matchLabels:
      app: maria-sts

  template:
    metadata:
      labels:
        app: maria-sts
    spec:
      containers:
      - image: mariadb:10
        name: mariadb
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3306

        envFrom:
        - prefix: 'MARIADB_'
          configMapRef:
            name: maria-cm

        volumeMounts:
        - name: maria-100m-pvc
          mountPath: /var/lib/mysql

修改WordPress

StatefulSet 管理的每个 Pod 都有自己的域名，所以要把 WordPress 的环境变量改成 MariaDB 的新名字，也就是“maria-sts-0.maria-svc”：

apiVersion: v1
kind: ConfigMap
metadata:
  name: wp-cm

data:
  HOST: 'maria-sts-0.maria-svc'  #注意这里
  USER: 'wp'
  PASSWORD: '123'
  NAME: 'db'

检验StatefulSet的持久化存储是否生效

你可以把这些对象都删除后重新创建，再进入网站，看看是否原来的数据依然存在。或者更简单一点，直接查看 NFS 的存储目录，应该可以看到 MariaDB 生成的一些数据库文件：

部署 Dashboard

首先，你应该先去 Dashboard 的项目网站（https://github.com/kubernetes/dashboard），看一下它的说明文档，了解一下它的基本情况。

安装：

1	wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.0/aio/deploy/recommended.yaml

这个 YAML 里包含了很多对象，虽然文件比较大，但现在的你应该基本都能够看懂了，要点有这么几个：

所有的对象都属于“kubernetes-dashboard”名字空间。
Dashboard 使用 Deployment 部署了一个实例，端口号是 8443。
容器启用了 Liveness 探针，使用 HTTPS 方式检查存活状态。
Service 对象使用的是 443 端口，它映射了 Dashboard 的 8443 端口。

使用命令 kubectl apply部署：

1	kubectl apply -f dashboard.yaml

总结

API 对象

PersistentVolume：简称 PV，是 Kubernetes 对持久化存储的抽象，代表了 LocalDisk、NFS、Ceph 等存储设备，和 CPU、内存一样，属于集群的公共资源。

因为不同存储设备之间的差异很大，为了更好地描述 PV 特征，就出现了 StorageClass，它的作用是分类存储设备，让我们更容易去选择 PV 对象。

PV 一般由系统管理员来创建，我们如果要使用 PV 就要用 PVC（PersistentVolumeClaim）去申请，说清楚需求的容量、访问模式等参数，然后 Kubernetes 就会查找最合适的 PV 分配给我们使用。

手动创建 PV 的工作量很大，麻烦而且容易出错，所以就有了“动态存储卷”的概念，需要在 StorageClass 里绑定一个 Provisioner 对象，由它来代替人工，根据 PVC 自动创建出符合要求的 PV。

有了 PV 和 PVC，我们就可以在 Pod 里用“persistentVolumeClaim”来引用 PVC，创建出可供容器使用的 Volume，然后在容器里用“volumeMounts”把它挂载到某个路径上，这样容器就可以读写 PV，实现数据的持久化存储了。

持久化存储的一个重要应用领域就是保存应用的状态数据，管理有状态的应用，就要使用新的对象 StatefulSet，可以认为它是管理无状态应用对象 Deployment 的一个特例。

StatefulSet：YAML 描述和 Deployment 非常像，“spec”里只是多了一个“serviceName”字段，但它部署应用的方式却与 Deployment 差距很大——Deployment 创建的 Pod 是随机的名字，而 StatefulSet 会对 Pod 顺序编号、顺序创建，保证应用有一个确定的启动先后次序，这样就可以实现主从、主备等关系。

在使用 Service 为 StatefulSet 创建服务的时候，它也会为每个 Pod 单独创建域名，同样也是顺序编号，保证 Pod 有稳定的网络标识，外部用户就可以用这个域名来准确地访问到某个具体的 Pod。

StatefulSet 还使用“volumeClaimTemplates”字段来定义持久化存储，里面其实就是一个 PVC，每个 Pod 可以用这个模板来生成自己的 PVC 去申请 PV，实现存储卷与 Pod 的独立绑定。

通过启动顺序、稳定域名和存储模板这三个关键能力，StatefulSet 就可以很好地处理 Redis、MySQL 等有状态应用了。

应用管理

滚动更新

只要编写一个新的 YAML（Deployment、DaemonSet、StatefulSet），再用 kubectl apply 应用就可以了。Kubernetes 采用的是“滚动更新”策略，实际上是两个同步进行的“扩容”和“缩容”动作，这样在更新的过程中始终会有 Pod 处于可用状态，能够平稳地对外提供服务。

应用的更新历史可以用命令 kubectl rollout history 查看，如果有什么意外，就可以用 kubectl rollout undo 来回退。这两个命令相当于给我们的更新流程上了一个保险，可以放心大胆操作，失败就用“S/L 大法”。

资源配额

能够限制容器申请的 CPU 和内存数量，不至于过多或者过少，保持在一个合理的程度，更有利于 Kubernetes 调度。

健康检查（探针）

检查探针是 Kubernetes 内置的应用监控工具，有 Startup、Liveness、Readiness 三种，分别探测启动、存活、就绪状态，探测的方式也有 exec、tcpSocket、httpGet 三种。组合运用这些就可以灵活地检查容器的状态，Kubernetes 发现不可用就会重启容器，让应用在总体上处于健康水平。

集群管理

名字空间

Kubernetes 的集群里虽然有很多计算资源，但毕竟是有限的，除了要给 Pod 加上资源配额，我们也要为集群加上资源配额，方法就是用名字空间，把整体的资源池切分成多个小块，按需分配给不同的用户使用。

名字空间的资源配额使用的是“ResourceQuota”，除了基本的 CPU 和内存，它还能够限制存储容量和各种 API 对象的数量，这样就可以避免多用户互相挤占，更高效地利用集群资源。

系统监控

Kubernetes 提供了 Metrics Server 和 Prometheus 两个工具：

Metrics Server 专门用来收集 Kubernetes 核心资源指标，可以用 kubectl top 来查看集群的状态，它也是水平自动伸缩对象 HorizontalPodAutoscaler 的前提条件。
Prometheus，继 Kubernetes 之后的第二个 CNCF 毕业项目，是云原生监控领域的“事实标准”，在集群里部署之后就可以用 Grafana 可视化监控各种指标，还可以集成自动报警等功能。

网络通信

对于底层的基础网络设施，Kubernetes 定义了平坦的网络模型“IP-per-pod”，实现它就要符合 CNI 标准。常用的网络插件有 Flannel、Calico、Cilium 等，Flannel 使用 Overlay 模式，性能较低，Calico 使用 Route 模式，性能较高。

不会飞的章鱼

Kubernetes集群部署WordPress网站-版本3