GKE 集群中托管的 ClamAV 无法解析 HEALTH CHECK

HEALTH CHECK not resolving for ClamAV hosted in GKE cluster

提问人:Vikram R 提问时间:11/16/2023 最后编辑:Vikram R 更新时间:11/16/2023 访问量:89

问:

无法解决 GKE 集群中端口 3310、7357 中托管的 clamAV:1.2 部署的运行状况检查相关问题。

我是这个 clamAV 概念的新手,并在带有入口的 GKE 中托管

面对一些后端服务处于不正常状态,在入口添加路由路径后对服务进行定义。enter image description here

我通过部署文件在 GKE 集群中部署了一个 clamAV:1.2 docker 映像。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: clam-av
spec:
  replicas: 1
  selector:
    matchLabels:
      run: clam-av
  template:
    metadata:
      labels:
        run: clam-av
    spec:
      nodeSelector:
        cloud.google.com/gke-nodepool: XXX-XXX-pool
      terminationGracePeriodSeconds: 60
      containers:
      - name: clamav-container
        image: clamav/clamav:1.2
        resources:
          requests:
            cpu: 200m
            memory: 1Gi
        imagePullPolicy: Always       
        ports:
        - containerPort: 3310
        # - containerPort: 7357
       

为此部署创建了一个服务文件

apiVersion: v1
kind: Service
metadata:
  name: clam-av-service
  annotations:
    cloud.google.com/backend-config: '{"default": "backend-for-clamAV"}'
spec:
  selector:
    run: clam-av
  ports:
  - name: http3310
    protocol: TCP
    port: 80
    targetPort: 3310
  # - name: http7357
  #   protocol: TCP
  #   port: 80
  #   targetPort: 7357
  type: ClusterIP

还创建了一个 BackendConfig:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: backend-for-clamAV
spec:
  timeoutSec: 150
  connectionDraining:
    drainingTimeoutSec: 150
  healthCheck:
    checkIntervalSec: 15
    port: 80
    type: HTTP
    requestPath: /
    healthyThreshold: 1
    unhealthyThreshold: 3
    timeoutSec: 15

尝试将spec.healthcheck.type设置为TCP,因为clamAV 3310是TCP连接。但 GCP 入口不支持 TCP。

任何解决此问题的建议将不胜感激。谢谢!

yaml kubernetes-health-check clamav

评论

0赞 blhsing 11/16/2023
这个问题属于 serverfault.com

答:

1赞 Fariya Rahmat 11/16/2023 #1

错误消息的状态表明只有少数后端受到影响,而不是不受影响Some backend services are in UNHEALTHYall backend services are in UNHEALTHY state.

请尝试以下故障排除步骤来解决问题

  1. 检查所有 Pod 是否都在运行,Pod 中的所有容器是否都已准备就绪,以及 Pod 状态是否为“正在运行”。使用以下命令。

    $ kubectl get po -n <命名空间>

    使用以下命令检查可疑 Pod 的日志:

    $ kubectl logs <podname> -c <containerName>

    通常,您应该检查指向负载均衡器的所有 Pod。

  2. 确认是否正确配置了 livenessProbe 和 readinessProbe,并且响应为 200。

    文档中所述:

目前,所有服务后端必须满足以下任一要求才能通过从 GCE 负载均衡器发送给它的 HTTP 运行状况检查: 1. 在“/”上用 200 进行响应。内容无关紧要。2. 在支持 Service 的 Pod 上公开任意 URL 作为就绪探测。

确保 readinessProbe 指向向 Ingress 公开的同一端口。

  1. 描述你的 ingress $ kubectl describe ingress <yourIngressName> 并检查后端。

  2. 运行命令 检查服务是否正确侦听端口 80。netstat -tnl \| grep 80

  3. 检查后端服务的运行状况检查日志,这将返回一个响应代码,这有助于进一步调试。

评论

0赞 Fariya Rahmat 11/16/2023
如果问题仍然存在,您也可以参考此 SO 链接
0赞 Vikram R 11/16/2023
我已经尝试了您之前提到的步骤,用于调试和确认目的。我已从入口中删除了路由。那么不健康的状态就不会到来。只有为clamAV添加路由时才会出现此问题。
0赞 Fariya Rahmat 11/16/2023
检查入口控制器的日志中,查看与添加 claimAV 路由相关的任何错误或警告。确保没有冲突的路径。
0赞 Vikram R 11/23/2023
为了更详细,我还发布了这个问题 github 问题 官方 clamAV 存储库。请在此处查看更详细的输入。
0赞 Vikram R 11/23/2023
友情链接: link