Question

我尝试将Ingress用于Google Kubernetes引擎上2个服务的负载均衡器：

这是为此的入口配置：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: basic-ingress

spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: web
          servicePort: 8080
      - path: /v2/keys
        backend:
          serviceName: etcd-np
          servicePort: 2379

其中网络是Google样本中的一些示例服务：

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: default
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    run: web
  type: NodePort

----
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: default
spec:
  selector:
    matchLabels:
      run: web
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - image: gcr.io/google-samples/hello-app:1.0
        imagePullPolicy: IfNotPresent
        name: web
        ports:
        - containerPort: 8080
          protocol: TCP

第二项服务是带有NodePort服务的ETCD集群：

---
apiVersion: v1
kind: Service
metadata:
  name: etcd-np
spec:
  ports:
  - port: 2379
    targetPort: 2379
  selector:
    app: etcd
  type: NodePort

但是我只能在日志中看到第一个入口规则才能正常工作

ingress.kubernetes.io/backends: {"k8s-be-30195--ebfd7339a961462d":"UNHEALTHY","k8s-be-30553--ebfd7339a961462d":"HEALTHY","k8s-be-31529--ebfd7339a961462d":"HEALTHY"}

我etcd-np正常工作，这不是etcd的问题，我认为问题是etcd服务器在GET / request上用404回答，并且在入口级别进行一些运行状况检查不允许使用它。

这就是为什么我有2个问题：

1）如何为入口上的每个后端路径提供运行状况检查

2）如何调试此类问题。我现在看到的是

kubectl describe ingress basic-ingress
Name:             basic-ingress
Namespace:        default
Address:          4.4.4.4
Default backend:  default-http-backend:80 (10.52.6.2:8080)
Rules:
  Host        Path  Backends
  ----        ----  --------
  *           
              /*         web:8080 (10.52.8.10:8080)
              /v2/keys   etcd-np:2379 (10.52.0.2:2379,10.52.2.4:2379,10.52.8.4:2379)
Annotations:  ingress.kubernetes.io/backends:
                {"k8s-be-30195--ebfd7339a961462d":"UNHEALTHY","k8s-be-30553--ebfd7339a961462d":"HEALTHY","k8s-be-31529--ebfd7339a961462d":"HEALTHY"}
              ingress.kubernetes.io/forwarding-rule: k8s-fw-default-basic-ingress--ebfd7339a961462d
              ingress.kubernetes.io/target-proxy: k8s-tp-default-basic-ingress--ebfd7339a961462d
              ingress.kubernetes.io/url-map: k8s-um-default-basic-ingress--ebfd7339a961462d
Events:       <none>

但是它没有向我提供有关此事件的任何信息

上

kubectl describe svc etcd-np

Name:                     etcd-np
Namespace:                default
Labels:                   <none>
Annotations:              Selector:  app=etcd
Type:                     NodePort
IP:                       10.4.7.20
Port:                     <unset>  2379/TCP
TargetPort:               2379/TCP
NodePort:                 <unset>  30195/TCP
Endpoints:                10.52.0.2:2379,10.52.2.4:2379,10.52.8.4:2379
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

Answer 1

根据doc。

通过入口公开的服务必须响应健康检查从负载均衡器。作为最终目的地的任何容器负载平衡流量必须执行以下一项操作以表明它很健康：

为HTTP路径上的GET请求提供状态为200 /的响应。

配置HTTP准备就绪探针。在就绪状态指定的路径上为HTTP个请求提供200 GET状态的响应探测。通过入口公开的服务必须指向相同的启用就绪探针的容器端口。

例如，假设一个容器指定了此就绪探测器：
...
readinessProbe:
  httpGet:
    path: /healthy
然后，如果容器/healthy路径的处理程序返回一个在HTTP 200状态下，负载均衡器将容器视为生还健康。

现在，由于ETCD在/health处具有运行状况终结点，因此准备情况探针看起来像

...
readinessProbe:
  httpGet:
    path: /health

如果在ETCD中启用了mTLS，这将变得有些棘手。为避免这种情况，请检查docs。

进入GKE。运行指定服务运行状况检查

1 个答案: