Kubernetns LB方案：无需云厂商的动态DNS和负载均衡

我们经常谈论托管Kubernetes或在云中运行的Kubernetes，但我们也在非云的环境（例如VMware或裸机服务器）上运行Kubernetes。

您可能还会听到很多有关云供应商集成的经典案例：您可以获取无密码凭据来访问托管服务，无需手动干预即可配置云负载均衡器，自动创建DNS条目等。

在本地运行时，通常无法使用这些集成功能，除非您使用的是受支持的云平台（如 OpenStack）。那么当在裸机或VM上运行时，如何获得Cloud Native环境的自动化优势？

所以让我们一步一步去看我们所想实现的功能。

本文中使用的所有清单均可在github项目中(https://github.com/clusterfrak-dynamics/gitops-template)获取。

GitOps

与往常一样，我们使用GitOps和FluxCD将我们的资源部署到集群中，无论它们是在云上还是在本地。你可以参考跟多我们关于Flux的文章。

首先，您可以使用我们的GitOps模板，并根据需要对其进行自定义。kubectl如果更合适，您也可以直接部署清单 。

以下让我们深入研究我们的组件。

负载均衡

在云上运行kubernetns时，通常可以立即使用Load Balancer。在裸机或VM上运行时，负载均衡器保持pending不可用状态。

因此，首先，我们希望我们的服务类型LoadBalancer不处于pending不可用状态，并且能够在需要时提供动态负载平衡器，而无需手动配置haproxy或其他类似的服务。

metallb可以提供两种模式的虚拟负载均衡器的实现：

• BGP协议

• ARP

后者更简单，因为它可以在几乎任何二层网络上工作，而无需进一步配置。

在ARP模式下，metallb的配置非常简单。您只需要给它提供一些可以使用的IP就可以了。

配置清单可在此处或官方文件中找到。要配置所需的IP地址，可以使用ConfigMap完成。

metallb-config.yaml：

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 10.10.39.200-10.10.39.220

您还需要生成一个密钥来加密Metallb组件通信，您可以使用以下脚本来生成Kubernetes secret yaml：

kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)" -o yaml --dry-run=client > metallb-secret.yaml

部署完所有内容后，您应该在metallb-system namespace内看到相应的pods ：

NAME                          READY   STATUS    RESTARTS   AGE
controller-57f648cb96-tvr9q   1/1     Running   0          2d1h
speaker-7rd8p                 1/1     Running   0          2d1h
speaker-7t7rg                 1/1     Running   0          2d1h
speaker-8qm2t                 1/1     Running   0          2d1h
speaker-bks4s                 1/1     Running   0          2d1h
speaker-cz6bc                 1/1     Running   0          2d1h
speaker-h8b54                 1/1     Running   0          2d1h
speaker-j6bss                 1/1     Running   0          2d1h
speaker-phvv7                 1/1     Running   0          2d1h
speaker-wdwjc                 1/1     Running   0          2d1h
speaker-xj25p                 1/1     Running   0          2d1h

现在，我们准备测试负载均衡器。为此，我们直接进入下一个主题。

Ingress controller

在云上运行时，除了经典的4层负载均衡器以外，您有时还可以在GCP和AWS上获得7层负载均衡器（例如，应用程序负载均衡器）。但是它们的功能有限，而且成本效益不高，而且您经常需要一个ingress controller来管理来自Kubernetes集群的流量。

这个ingress controller通常通过服务类型为LoadBalancer在外部发布。这就是为什么我们以前的metallb部署会派上用场。

第一个也是最常用的ingress controller之一是nginx-ingress，它可以轻松地与Helm一起部署。

由于我们将Flux与Helm Operator结合使用，因此根据我们使用的Helm，您可以参考以下values.yaml配置：

因为我们将Flux与Helm Operator结合使用，所以我们使用了一个Helm Release 的版本，您可以从中得到values.yaml，以下展示了我们的配置：

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: nginx-ingress
  namespace: nginx-ingress
spec:
  releaseName: nginx-ingress
  chart:
    repository: https://kubernetes-charts.storage.googleapis.com
    version: 1.36.3
    name: nginx-ingress
  values:
    controller:
      publishService:
        enabled: true
      kind: "DaemonSet"
      service:
        enabled: true
        externalTrafficPolicy: Local
      daemonset:
        hostPorts:
          http: 80
          https: 443
    defaultBackend:
      replicaCount: 2
    podSecurityPolicy:
      enabled: true