Kubernetes 负载平衡/故障转移外部 MariaDB PXC 集群节点的方式答案

【问题标题】：Kubernetes way to Load balance/Failover external MariaDB PXC cluster nodesKubernetes 负载平衡/故障转移外部 MariaDB PXC 集群节点的方式
【发布时间】：2021-10-25 17:10:37
【问题描述】：

我正在尝试设置对使用 MariaDB PXC 三节点集群设置的外部 MySQL 数据库的访问。

假设我的外部数据库节点有这些 IP 地址

172.16.10.100
172.16.10.101
172.16.10.102

如果其中一个节点出现故障，我希望 Kubernetes 自动将流量路由到仅可用的两个节点。

如果我在 kubernetes 中创建一个简单的服务和端点（如下所示），它会自动进行故障转移吗？

#
# Service
#
kind: Service
apiVersion: v1
metadata:
  name: mariadb-service
spec:
  clusterIP: None
  sessionAffinity: None
  ports:
  - port: 3306
    protocol: TCP
    targetPort: 3306
---
#
# Endpoints
#
kind: Endpoints
apiVersion: v1
metadata:
  name: mariadb-service
subsets:
  - addresses:
      - ip: 172.16.10.100
      - ip: 172.16.10.101
      - ip: 172.16.10.102
    ports:
      - port: 3306
        protocol: TCP

【问题讨论】：

您使用的是哪个云提供商？
@Bazhikov 没有云提供商，这是一个本地 kubernetes 集群
抱歉回复晚了。外部数据库是什么意思，是在集群之外吗？
是的，数据库在 Kubernetes 集群之外运行，数据库设置在 3 节点多主集群中，因此如果一个节点发生故障，客户端服务可以切换到其他可用节点来访问数据库。

标签： kubernetes mariadb

【解决方案1】：

请注意：

Kubernetes 不提供用于裸机集群的网络负载平衡器（LoadBalancer 类型的服务）的实现。 Kubernetes 附带的网络负载均衡器的实现都是调用各种 IaaS 平台（GCP、AWS、Azure ……）的胶水代码。如果您没有在受支持的 IaaS 平台（GCP、AWS、Azure...）上运行，LoadBalancers 在创建时将无限期地保持在“待定”状态。

我找到了将 LoadBalancer 与本地 Kubernetes 集群一起使用的选项 - 即 MetalLB

MetalLB 旨在通过提供与标准网络设备集成的网络负载平衡器实现来纠正这种不平衡，以便裸机集群上的外部服务也尽可能“工作”。

查看您喜欢的requirements 和installation options。

MetalLB respects the spec.loadBalancerIP parameter，因此如果您希望使用特定地址设置您的服务，您可以通过设置该参数来请求它。 MetalLB 还支持请求特定的地址池，如果您想要某种地址但不关心具体是哪一个。要从特定池请求分配，请将 metallb.universe.tf/address-pool 注释添加到您的服务，并将地址池的名称作为注释值。例如：

apiVersion: v1
kind: Service
metadata:
  name: nginx
  annotations:
    metallb.universe.tf/address-pool: production-public-ips
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

对于address-pool annotation，您可以这样定义：

address-pools:
  name: production-public-ips
  protocol: TCP
  addresses:
  - ip: 172.16.10.100
  - ip: 172.16.10.101
  - ip: 172.16.10.102
  ports:
  - port: 3306

查找完整的用法示例here。

但是，没有实施健康检查，这是您的主要选择。

有一个理想的 issue example on GitHub 和 this thread 解释了为什么没有为 Kubernetes CRD 实施健康检查。

如果我们跳入 Kubernetes 概念，这个用例是不可行的，你可以寻找一些自定义端点控制器：

readinessProbe：指示容器是否准备好响应请求。如果就绪探测失败，端点控制器会从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址。初始延迟之前的默认就绪状态是失败。如果 Container 不提供就绪探测，则默认状态为 Success。

更多信息请到official documentation

【讨论】：