Istio 服务的健康检查

    1. 命令方式
    2. TCP 请求方式
    3. HTTP 请求方式

    本节将阐述如何在启用了双向 TLS 的 Istio 中使用这三种方式。

    注意，无论是否启用了双向 TLS 认证，命令和 TCP 请求方式都可以与 Istio 一起使用。HTTP 请求方式则要求启用了 TLS 的 Istio 使用不同的配置。

    首先，您需要配置健康检查并开启双向 TLS 认证。

    要为服务开启双向 TLS 认证，必须配置验证策略和目标规则。 按照以下步骤来完成配置：

    运行下面的命令创建命名空间：

    1. 配置验证策略，并运行：

      2. apiVersion: "authentication.istio.io/v1alpha1"
      3. kind: "Policy"
      4. metadata:
      5.   name: "default"
      6.   namespace: "istio-io-health"
      7. spec:
      8.   peers:
      9.   - mtls: {}
      10. EOF

    运行以下命令来部署服务：

    重复使用检查状态的命令来验证 Liveness 探针是否正常工作：

    本部分介绍，当双向 TLS 认证开启的时候，如何使用 HTTP 请求方式来做健康检查。

    Kubernetes 的 HTTP 健康检查是由 Kubelet 来发送的，但是 Istio 并未颁发证书给 liveness-http 服务。因此，当启用双向 TLS 认证之后，所有的健康检查请求将会失败。

    有两种方式来解决此问题：探针重写和端口分离。

    这种方式重写了应用程序的 PodSpec Readiness 和 Liveness 探针，以便将探针请求发送给 . Pilot agent 将请求重定向到应用程序，剥离 response body ，只返回 response code 。

    有两种方式来让 Istio 重写 Liveness 探针。

    通过安装参数，全局启用

    的时候使用 --set values.sidecarInjectorWebhook.rewriteAppHTTPProbe=true.

    或者，更新 Istio sidecar 注入的 map ：

    1. $ kubectl get cm istio-sidecar-injector -n istio-system -o yaml | sed -e 's/"rewriteAppHTTPProbe":false/"rewriteAppHTTPProbe":true/' | kubectl apply -f -

    上面的安装参数和注入的 map ，都指引着 Sidecar 注入过程中自动重写 Kubernetes pod 的 spec，以便让健康检查能够在双向 TLS 认证下正常工作。无需更新应用程序或者 pod 的 spec ：

    上面更改的配置 （通过安装参数或注入的 map ）会影响到所有 Istio 应用程序部署。

    对 pod 使用 annotation

    1. apiVersion: apps/v1
    2. kind: Deployment
    3. metadata:
    4.   name: liveness-http
    5. spec:
    6.   selector:
    7.     matchLabels:
    8.       app: liveness-http
    9.       version: v1
    10.   template:
    11.     metadata:
    12.         app: liveness-http
    13.         version: v1
    14.       annotations:
    15.         sidecar.istio.io/rewriteAppHTTPProbers: "true"
    17.       containers:
    18.       - name: liveness-http
    19.         image: docker.io/istio/health:example
    20.         ports:
    21.         - containerPort: 8001
    22.         livenessProbe:
    23.           httpGet:
    24.             path: /foo
    25.             port: 8001
    26.           initialDelaySeconds: 5
    27.           periodSeconds: 5

    这种方式可以使得在每个部署的应用上逐个启用健康检查并重写探针，而无需重新安装 Istio 。

    重新部署需要 Liveness 健康检查的应用程序

    以下的说明假定您通过安装选项全局启用了该功能，Annotation 同样奏效。

    Zip

    1. $ kubectl delete -f <(istioctl kube-inject -f @samples/health-check/liveness-http-same-port.yaml@)
    2. $ kubectl apply -f <(istioctl kube-inject -f @samples/health-check/liveness-http-same-port.yaml@)

    默认情况下未启用此功能。我们希望收到您的反馈， 是否应将其更改为 Istio 安装过程中的默认行为。

    另一种方式是使用单独的端口来进行运行状态检查和常规流量检查。

    运行下面的命令，重新部署服务：

    Zip

    1. $ kubectl delete -f <(istioctl kube-inject -f @samples/health-check/liveness-http.yaml@)
    2. $ kubectl apply -f <(istioctl kube-inject -f @samples/health-check/liveness-http.yaml@)

    稍等片刻，检查 pod 状态，确认 Liveness 探针在 ‘RESTARTS’ 列的工作状态是 ‘0’ 。

    1. $ kubectl get pod
    2. NAME                             READY     STATUS    RESTARTS   AGE
    3. liveness-http-67d5db65f5-765bb   2/2       Running   0          1m

    请注意， 的镜像公开了两个端口：8001 和 8002 (源码)。在这个部署方式里面，端口 8001 用于常规流量，而端口 8002 给 Liveness 探针使用。

    请按照如下操作删除上述步骤中添加的双向 TLS 策略和相应的目标规则：

    1. $ kubectl delete policies default
    2. $ kubectl delete destinationrules default