如何在Kubernetes上运行高度可用的WordPress和MySQL

下面的WordPress教程专栏将向您介绍在Kubernetes上运行高度可用的WordPress和MySQL。希望对有需要的朋友有帮助！

在Kubernetes上运行高度可用的WordPress和MySQLWordPress是编辑和发布Web内容的主流平台。在本教程中，我将逐步介绍如何使用Kubernetes来构建一个高可用性(HA)的WordPress部署。

WordPress由两个主要组件组成:WordPress PHP服务器和用于存储用户信息、帖子和网站数据的数据库。我们需要使整个应用程序中的这两个组件在具有高可用性的同时具有容错能力。

当硬件和地址发生变化时，可能很难运行高可用性服务:很难维护。有了Kubernetes及其强大的网络组件，我们可以部署高度可用的WordPress站点和MySQL数据库，而无需(几乎无需)输入一个IP地址。

在本教程中，我将向您展示如何在Kubernetes中创建存储类、服务、配置映射和集合，如何运行高可用性MySQL，以及如何在数据库服务上挂载高可用性WordPress集群。如果你没有Kubernetes集群，你可以在亚马逊、谷歌或Azure上轻松找到并启动它们，或者在任何服务器上使用Rancher Kubernetes Engine (RKE)。

架构现在让我简单介绍一下我们将使用的技术和功能:WordPress应用程序文件的存储:带有GCE持久磁盘备份的NFS存储数据库集群:带有xtrabackup用于奇偶校验的MySQL应用程序级别:WordPress DockerHub镜像负载平衡和安装在NFS存储上的网络:基于Kubernetes的负载平衡器和服务网络。

该架构如下所示:

在Kubernetes的K8s中创建存储类、服务和配置映射，状态集提供了一种定义pod初始化顺序的方式。我们将使用一个有状态的MySQL集合，因为它可以确保我们的数据节点在启动时有足够的时间复制以前的pods中的记录。我们以这样的方式配置这个状态集，使得MySQL主机可以在其他连接的机器之前启动，因此当我们扩展时，我们可以直接将克隆从主机发送到连接的机器。

首先，我们需要创建一个持久的卷存储类和配置映射，以便根据需要应用主从配置。我们使用持久卷来避免数据库中的数据局限于集群中的任何特定单元。当MySQL主机pod丢失时，这种方法可以防止数据库丢失数据。当主机盒丢失时，它可以使用xtrabackup重新连接到连接的机器，并将数据从连接的机器复制到主机。MySQL复制负责依赖主机的复制，xtrabackup负责依赖主机的复制。

为了动态分配持久卷，我们使用GCE持久磁盘来创建存储类。但是，Kubernetes为持久卷提供了各种存储方案:

# storage-class . YAML kind:storageclaspiversion:storage.k8s.io/v1metadata:名称:slow provisioner:kubernetes.io/ Gce-PD参数:type:PD-standard zone:us-central a创建一个类并使用指令$ ku bectl create-f storage-class . YAML部署它

接下来，我们将创建configmap，它指定了MySQL配置文件中设置的一些变量。这些不同的配置与pod本身的选择有关，但它们也为我们提供了一种管理潜在配置变量的便捷方式。

创建一个名为mysql-configmap.yaml的YAML文件来处理配置，如下所示:

# MySQL-config map . YAML版本:v1k ind:configmap metadata:name:MySQL标签:app: mysqldata: master.cnf: | #仅在主服务器上应用此配置。

使用指令＄ku bectl create-f nfs . YAML来部署NFS服务。现在，我们需要运行$ ku bectl describe services NFS-server来获取IP地址，稍后会用到它。

注意:将来，我们可以使用服务名将这些联系在一起，但是现在您需要硬编码IP地址。

# WordPress . yamlapiversion:v1 kind:service metadata:name:WordPress labels:app:WordPress spec:ports:-port:80选择器:app:WordPress tier:frontend type:load balancer-API version:v1 kind:PersistentVolumemetadata:name:NFS spec:capacity:storage:20G access modes:-read writem any NFS:# FIXME:使用正确的IP服务器: lt的IP = ；"= "nfs = "service = " gt路径: / ；-API version:v1 kind:PersistentVolumeClaimmetadata:name:NFS spec:access modes:-read write many storage class name: ；"资源:请求:存储:20G - apiVersion: apps/v1beta1 #对于1.8.0之前的版本，使用apps/v1 beta 1 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.9-Apache name:WORDPRESS env:-name:WORDPRESS _ DB _ HOST value:MySQL-name:word"端口:-container port:80 name:wordpress volume mounts:-name:WordPress-persistent-storage mount path:/var/www/html volumes:-name:WordPress-persistent-storage persistent volume claim:claim name:NFS我们现在已经创建了一个持久性卷声明，建立与我们之前创建的NFS服务的映射，然后将该卷附加到WordPress pod，即/Var/www/html根目录，这也是WordPress的安装位置。集群中WordPress pods的所有安装和环境都保留在这里。有了这些配置，我们可以启动和拆除任何WordPress节点，而数据可以保留。因为NFS服务需要经常使用物理卷，所以该卷将保持不变，不会被回收或错误分配。

使用$ kubectl create -f wordpress.yaml指令来部署wordpress实例。默认情况下，只有一个WordPress实例会运行，您可以使用$ ku bectl scale-replicas = < number of = ；&;副本= &; gt部署/wordpress扩展了wordpress实例的数量。

要获得wordpress服务负载平衡器的地址，您需要输入$ kubectl get services wordpress，并从结果中获得EXTERNAL-IP字段，以导航到WordPress。

弹性测试还可以。现在我们已经部署了服务，让我们来分解它们，看看我们的高可用性架构是如何处理这些混乱的。在这种部署模式中，唯一剩下的单点故障是NFS服务(原因总结在本文结尾的结论中)。您应该能够测试任何其他服务，看看应用程序如何响应。现在我已经启动了三份WordPress服务，以及MySQL服务中的一个主节点和两个附属节点。

首先，让我们杀掉其他的，只留下一个WordPress节点，看看应用程序如何响应:$ ku bectl scale-Replicas = 1 deployment/WordPress现在我们应该看到WordPress部署的pod数量减少了。$ kubectl get pods应该能看出WordPress pods的操作已经变成了1/1。

点击WordPress服务IP，我们会看到和以前一样的站点和数据库。如果想延长恢复时间，可以使用$ ku bectl scale-replicas = 3 deployment/WordPress。同样，我们可以看到数据包在三种情况下被留下。

下面测试一下MySQL的状态集。我们使用指令来减少备份的数量:$ ku bectl scale stateful sets MySQL-replicas = 1。我们将看到两个卫星从这个实例中丢失。如果此时主节点丢失，它保存的数据将保存在GCE永久磁盘上。但是，您必须手动从磁盘恢复数据。

如果三个MySQL节点都关闭了，那么当新节点出现时，它们将无法被复制。但是，如果一个主节点出现故障，将自动启动一个新的主节点，并通过xtrabackup重新配置来自从属节点的数据。因此，在运行生产数据库时，我不建议使用小于3的复制因子来运行它。在结论部分，我们将讨论对于有状态数据有什么更好的解决方案，因为Kubernetes并不是真正为有状态数据设计的。

结论和建议到目前为止，您已经完成了在Kubernetes中构建和部署高可用WordPress和MySQL的安装！

然而，尽管有这种影响，你的研究之旅可能还远未结束。也许你没有注意到在我们的安装中仍然有一个单点故障:NFS服务器在WordPress pods之间共享/var/www/html目录。该服务代表单点故障，因为如果它不运行，html目录将在使用它的pod上丢失。在教程中，我们为服务器选择了一个非常稳定的镜像，可以在生产环境中使用，但是对于真正的生产部署，可以考虑使用GlusterFS打开WordPress实例共享的目录进行更多的读写。

这个过程包括在Kubernetes上运行一个分布式存储集群。实际上，这不是由Kubernetes构建的，所以尽管它工作得很好，但对于长期部署来说，它不是一个理想的选择。

对于数据库，我个人推荐使用托管关系数据库服务来托管MySQL实例，因为无论是Google的CloudSQL还是AWS的RDS都以更合理的价格提供了高可用性和冗余处理，并且不需要担心数据完整性。Kuberntes不是围绕有状态应用程序设计的，其中构建的任何状态都是事后才想到的。目前，有大量的解决方案可以在选择数据库服务时提供所需的保证。

也就是说，上面的介绍是一个理想的过程，它从Kubernetes教程和web中找到的例子中创建了一个相关的、现实的Kubernetes例子，并且包含了Kubernetes 1.8.x中的所有新特性

希望通过这篇指南，你能在部署WordPress和MySQL时获得一些惊喜的体验，当然也希望你的操作正常。

这就是如何在Kubernetes上运行高度可用的WordPress和MySQL的细节。更多请关注主机参考其他相关文章！

这几篇文章你可能也喜欢：

• 暂无相关推荐文章

本文由主机参考刊发，转载请注明：如何在Kubernetes上运行高度可用的WordPress和MySQL https://zhujicankao.com/84254.html