Question

因此，我们正在使用全局mtl部署istio 1.0.2，到目前为止一切进展顺利。为了进行健康检查，我们已为服务添加了单独的端口，并根据文档进行了配置：

https://istio.io/docs/tasks/traffic-management/app-health-check/#mutual-tls-is-enabled

我们的应用程序端口现在位于8080上，而运行状况检查端口位于8081上。完成此操作后，Kubernetes可以进行运行状况检查，并且服务似乎可以正常运行。

但是，我们的监视解决方案无法运行状况检查端口。

该监视应用程序也位于kubernetes中，当前位于网格外部。上面的文档说：

由于Istio代理仅拦截在containerPort字段中明确声明的端口，因此无论是否启用Istio双向TLS，到8002端口的流量都会绕过Istio代理。e

这是我们配置它的方式。因此，在我们的情况下，8081应该位于网格外部：

livenessProbe:
  failureThreshold: 3
  httpGet:
    path: /manage/health
    port: 8081
    scheme: HTTP
  initialDelaySeconds: 180
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 1
name: <our-service>
ports:
- containerPort: 8080
  name: http
  protocol: TCP
readinessProbe:
  failureThreshold: 3
  httpGet:
    path: /manage/health
    port: 8081
    scheme: HTTP
  initialDelaySeconds: 10
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 1

但是，我们无法从网格外部的另一个容器访问8081。

例如：

curl http://<our-service>:8081/manage/health
curl: (7) Failed connect to <our-service>:8081; Connection timed out

如果我们尝试从istio网格中的另一个容器中抛出404，这可能是预期的。

我尝试使用以下目标规则：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: <our-service>-health
spec:
  host: <our-service>.namepspace.svc.cluster.local
  trafficPolicy:
    portLevelSettings:
    - port:
        number: 8081
      tls:
        mode: DISABLE

但这只会杀死内部和通过入口网关到服务的所有连接。

Answer 1

根据官方的Istio Documentation端口8081将无法通过Istio Envoy，因此您的服务网格之外的其他Pod将无法访问，因为Istio代理仅确定{{ 1}}通过Pod的服务进行传输。

如果在Pod之间构建没有TLS身份验证的Istio服务网格，则可以选择使用相同的端口作为通往Pod服务的基本网络路由以及“就绪/活跃”探针。

但是，如果您同时使用端口8001进行正常通信和活动探针，启用双向TLS后，运行状况检查将失败，因为 HTTP请求是从Kubelet发送的，它不发送客户端 liveness-http服务的证书。

假设Istio Mixer提供了三个Prometheus endpoints，则可以考虑使用Prometheus作为主要监视工具，以便收集和分析网格度量。

配置istio后访问服务运行状况检查端口

1 个答案: