当前位置: 首页 > 知识库问答 >
问题:

GCP HTTP(S)负载均衡器忽略GKE readinessProbe规范

宇文智敏
2023-03-14

我已经看到了这个问题;好了,我正在做答案里的所有事情。

使用GKE,我为包含两个几乎相同部署的kubernetes集群部署了一个基于GCP HTTP(S)负载均衡器的入口:同一应用程序的生产和开发实例。

我在每个pod模板上设置了一个专用端口,用于负载平衡器的健康检查,这样它们就不会受到来自主HTTP端口根路径的重定向的影响。然而,健康检查总是失败。

从这些文档中,我向我的部署添加了一个readinessProbe参数,负载均衡器似乎完全忽略了这个参数。

我已经验证了:p就绪(9292;专用健康检查端口)上的服务器使用以下(在单独的终端中)正确运行:

➜ kubectl port-forward deployment/d-an-server p-ready
➜ curl http://localhost:9292/ -D -
HTTP/1.1 200 OK
content-length: 0
date: Wed, 26 Feb 2020 01:21:55 GMT

我错过了什么?

以下配置有几个注意事项:

  • <代码>${…} 变量
  • 第二个服务(s-an-server-dev)几乎与第一个服务完全相同(有自己的部署),只是名称和标签上有后缀-dev
apiVersion: "apps/v1"
kind: "Deployment"
metadata:
  name: "d-an-server"
  namespace: "default"
  labels:
    app: "a-an-server"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: "a-an-server"
  template:
    metadata:
      labels:
        app: "a-an-server"
    spec:
      containers:
        - name: "c-an-server-app"
          image: "gcr.io/${PROJECT_ID}/an-server-app:${SHORT_SHA}"
          ports:
            - name: "p-http"
              containerPort: 8080
            - name: "p-ready"
              containerPort: 9292
          readinessProbe:
            httpGet:
              path: "/"
              port: "p-ready"
            initialDelaySeconds: 30
apiVersion: "v1"
kind: "Service"
metadata:
  name: "s-an-server"
  namespace: "default"
spec:
  ports:
    - port: 8080
      targetPort: "p-http"
      protocol: "TCP"
      name: "sp-http"
  selector:
    app: "a-an-server"
  type: "NodePort"
apiVersion: "networking.k8s.io/v1beta1"
kind: "Ingress"
metadata:
  name: "primary-ingress"
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "primary-static-ipv4"
    networking.gke.io/managed-certificates: "appname-production-cert,appname-development-cert"
spec:
  rules:
    - host: "appname.example.com"
      http:
        paths:
          - backend:
              serviceName: "s-an-server"
              servicePort: "sp-http"
    - host: "dev.appname.example.com"
      http:
        paths:
          - backend:
              serviceName: "s-an-server-dev"
              servicePort: "sp-http-dev"

共有1个答案

米子轩
2023-03-14

我认为这里发生的事情是GKE ingress根本没有被告知9292端口。您在入口中引用的是端口8080。

您需要确保以下内容:

1.服务的目标端口字段必须指向pod端口的容器端口值或名称。

2、准备就绪探测器必须暴露在与入口中指定的服务端口匹配的端口上。

 类似资料:
  • 负载均衡(Load balancing)是一种计算机网络技术,用来在多个计算机(计算机集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载,以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。 使用带有负载均衡的多个服务器组件,取代单一的组件,可以通过冗余提高可靠性。负载均衡服务通常是由专用软体和硬件来完成。 负载均衡最重要的一个应用是利用多台服务器提供单一服务,这种方案有

  • 负载均衡包括负载均衡实例、访问控制及证书。 实例 负载均衡实例是一个运行的负载均衡服务,通过设置的虚拟IP接收流量并将其转发分配给后端服务器。 访问控制 访问控制用于设置访问负载均衡的IP白名单或IP黑名单。 证书 当在负载均衡实例上配置HTTPS监听转发来自HTTPS协议的请求时,需要配置证书。

  • 一个简单的负载均衡的示例,把www.domain.com均衡到本机不同的端口,也可以改为均衡到不同的地址上。> http { : upstream myproject { : server 127.0.0.1:8000 weight=3; : server 127.0.0.1:8001; : server 127.0.0.1:8002; : server 127.0.0.1:8003; : }

  • SOFARPC 提供多种负载均衡算法,目前支持以下五种: 类型 名称 描述 random 随机算法 默认负载均衡算法。 localPref 本地优先算法 优先发现是否本机发布了该服务,如果没有再采用随机算法。 roundRobin 轮询算法 方法级别的轮询,各个方法间各自轮询,互不影响。 consistentHash 一致性hash算法 同样的方法级别的请求会路由到同样的节点。 weightRou

  • 本节将会讨论常见的分布式系统负载均衡手段。 6.5.1 常见的负载均衡思路 如果我们不考虑均衡的话,现在有n个服务节点,我们完成业务流程实际上只需要从这n个中挑出其中的一个。有几种思路: 按顺序挑: 例如上次选了第一台,那么这次就选第二台,下次第三台,如果已经到了最后一台,那么下一次从第一台开始。这种情况下我们可以把服务节点信息都存储在数组中,每次请求完成下游之后,将一个索引后移即可。在移到尽头时

  • 当过滤器需要获取到上游群集中的主机连接时,群集管理器使用负载平衡策略来确定选择哪个主机。负载平衡策略是可插入的,并且在配置中以每个上游集群为单位进行指定。请注意,如果没有为群集配置积极的健康检查策略,则所有上游群集成员都被视为健康。 支持的负载平衡策略 轮训 这是一个简单的策略,每个健康的上游主机按循环顺序选择。 权重最小请求 请求最少的负载均衡器使用O(1)算法来选择两个随机的健康主机,并选择活