HAProxy 入口控制器服务更改了 GCP 上的 IP

Question

我在我的 GKE 集群中使用 HAProxy 作为入口控制器。并将 HAProxy 服务公开为 LoadBalancer 服务（内部）。

最近，我遇到了一个问题，即 HA-Proxy 服务更改了其 EXTERNAL-IP，并且流量停止路由到 HAProxy。这个问题在不同的日子里发生了多次（现在它已经停止了）。我必须手动将新的外部 IP 添加到该负载均衡器的前端，以允许流量到 HAProxy。
HAProxy 有两个 pod 运行，并且都运行了好几天，它们的日志中没有任何内容。我认为它与 Service 或 GCP LB 有关，而不是 HAProxy 本身。
恐怕我没有任何相关的日志。

我还是不知道，是什么导致了服务 IP 的变化。由于最近没有任何变化，并且集群和所有服务都正常运行了很多天，所以突然发生了这种情况。

之前有没有人遇到过类似的问题？或者我可以做些什么来避免将来出现此类问题？
什么可能导致 IP 发生变化？

这是我的服务的配置方式：

---
apiVersion: v1
kind: Service
metadata:
  labels:
    run: haproxy-ingress
  name: haproxy-ingress
  namespace: haproxy-controller
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
    networking.gke.io/internal-load-balancer-allow-global-access: "true"
    cloud.google.com/network-tier: "Premium"
spec:
  selector:
    run: haproxy-ingress
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
  - name: stat
    port: 1024
    protocol: TCP
    targetPort: 1024

找到一些日志：

Warning SyncLoadBalancerFailed 30m (x3570 over 13d) service-controller Error syncing load balancer: failed to ensure load balancer: googleapi: Error 409: IP_IN_USE_BY_ANOTHER_RESOURCE - IP '10.17.129.17' is already being used by another resource.
Normal EnsuringLoadBalancer 3m33s (x3576 over 13d) service-controller Ensuring load balancer

Answer 1

简短的回答是：External IP 服务是短暂的。
因为 HA-Proxy 控制器 pod 是重新创建的，所以 HA-Proxy 服务是使用临时 IP 创建的。

为避免此问题，我建议您使用可在 loadBalancerIP 字段中引用的静态 IP。

这可以通过以下步骤来完成：

• 保留静态 IP。 (link)
• 使用此 IP 创建服务 (link)

YAML 示例：

apiVersion: v1
kind: Service
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    app: hello
    tier: web
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer
  loadBalancerIP: "YOUR.IP.ADDRESS.HERE"

Answer 2

不幸的是，没有日志，很难确定。您应该检查 GKE 提供给 Cloud Logging 的审核日志，因为这可能会让您对发生的事情有所了解。一种选择是 GCP“糟糕”的 GLB 和 GKE 重新创建它，从而给它一个新的 IP。不过，我从未听说过 LB 会发生这种情况（它经常发生在节点上，但不是 LB）。更常见的情况是您运行了一些 kubectl 命令，无意中删除了 Service 对象，然后它被您设置的某个管理层（Argo、Flux、Helm Operator 等）重新创建，但再次删除+重新创建意味着它是一个新的 LB用一个新的IP。后一种情况应该在审核日志中可见，因此请务必检查。