在全局启用 istio 和 mTLS 的情况下公开虚拟服务

Question

我的服务网格上有这个配置：

• mTLS 全局启用，meshpolicy 默认
• 简单的 Web 部署在端口 8080 上公开为 clusterip
• 用于端口 80 的 http 网关和我的服务上的虚拟服务路由

这里是 gw 和 vs yaml

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway # Specify the ingressgateway created for us
  servers:
  - port:
      number: 80 # Service port to watch
      name: http-gateway
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: simple-web
spec:
  gateways:
  - http-gateway
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /simple-web
    rewrite:
      uri: /
    route:
    - destination:
        host: simple-web
        port:
          number: 8080

vs 和 gw 都在同一个命名空间中。 使用以下命令创建和公开部署：

k create deployment --image=yeasy/simple-web:latest simple-web
k expose deployment simple-web --port=8080 --target-port=80 --name=simple-web

通过 k get pods 我收到了这个：

pod/simple-web-9ffc59b4b-n9f85   2/2     Running

发生的情况是，从外部指向入口网关负载平衡器，我收到 503 HTTP 错误。 如果我尝试从 ingressgateway pod 卷曲，我可以访问 simple-web 服务。 为什么我无法访问启用 mTLS 的网站？正确的配置是什么？

Answer 1

正如@suren 在他的回答中提到的，这个问题在 istio 版本 1.3.2 中不存在。所以解决方案之一是使用更新的版本。

如果您选择将 istio 升级到较新版本，请查看文档 1.3 Upgrade Notice 和 Upgrade Steps，因为 Istio 仍在开发中，每个版本都会发生巨大变化。

正如 @Manuel Castro 在 cmets 中提到的，这很可能是 Avoid 503 errors while reconfiguring service routes 中解决的问题，而新版本可以更好地处理它们。

同时创建 VirtualServices 和 DestinationRules 来定义 使用单个 kubectl 调用（例如，kubectl apply -f myVirtualServiceAndDestinationRule.yaml 是不够的，因为资源传播（从配置服务器，即 Kubernetes API 服务器）到 Pilot 实例的最终 一致的方式。如果使用子集的 VirtualService 到达 在定义子集的 DestinationRule 之前，Envoy Pilot 生成的配置将引用不存在的上游 游泳池。这会导致 HTTP 503 错误，直到所有配置对象 Pilot 可以使用。

在部署期间暂时禁用mTLS 或使用permissive mode 应该可以避免此问题。

Answer 2

我刚刚安装了 istio-1.3.2 和 k8s 1.15.1，以重现您的问题，并且无需任何修改即可正常工作。这就是我所做的：

0.- 创建一个名为 istio 的命名空间并自动启用 sidecar 注入。

1.- $ kubectl run nginx --image nginx -n istio

2.- $ kubectl expose deploy nginx --port 8080 --target-port 80 --name simple-web -n istio

3.- $kubectl craete -f gw.yaml -f vs.yaml

注意：这些是您的文件。

测试：

$ curl a.b.c.d:31380/simple-web -I
HTTP/1.1 200 OK
server: istio-envoy
date: Fri, 11 Oct 2019 10:04:26 GMT
content-type: text/html
content-length: 612
last-modified: Tue, 24 Sep 2019 14:49:10 GMT
etag: "5d8a2ce6-264"
accept-ranges: bytes
x-envoy-upstream-service-time: 4


[2019-10-11T10:04:26.101Z] "HEAD /simple-web HTTP/1.1" 200 - "-" "-" 0 0 6 4 "10.132.0.36" "curl/7.52.1" "4bbc2609-a928-9f79-9ae8-d6a3e32217d7" "a.b.c.d:31380" "192.168.171.73:80" outbound|8080||simple-web.istio.svc.cluster.local - 192.168.171.86:80 10.132.0.36:37078 - -

为了确保 mTLS 已启用，这是来自 ingress-gateway describe 命令：

--controlPlaneAuthPolicy MUTUAL_TLS

所以，我不知道出了什么问题，但您可能希望完成这些步骤并丢弃一些东西。

注意：我在端口 31380 上攻击 istio 网关的原因是因为我的 k8s 现在在虚拟机上，我不想启动 GKE 集群进行测试。

编辑

刚刚使用您的映像部署了另一个部署，将其公开为 simple-web-2，然后再次工作。可能我对 istio 很幸运：

$ curl a.b.c.d:31380/simple-web -I
HTTP/1.1 200 OK
server: istio-envoy
date: Fri, 11 Oct 2019 10:28:45 GMT
content-type: text/html
content-length: 354
last-modified: Fri, 11 Oct 2019 10:28:46 GMT
x-envoy-upstream-service-time: 4

[2019-10-11T10:28:46.400Z] "HEAD /simple-web HTTP/1.1" 200 - "-" "-" 0 0 5 4 "10.132.0.36" "curl/7.52.1" "df0dd00a-875a-9ae6-bd48-acd8be1cc784" "a.b.c.d:31380" "192.168.171.65:80" outbound|8080||simple-web-2.istio.svc.cluster.local - 192.168.171.86:80 10.132.0.36:42980 - -

你的 k8s 环境是什么？

EDIT2

# istioctl authn tls-check curler-6885d9fd97-vzszs simple-web.istio.svc.cluster.local -n istio
HOST:PORT                                   STATUS     SERVER     CLIENT     AUTHN POLICY     DESTINATION RULE
simple-web.istio.svc.cluster.local:8080     OK         mTLS       mTLS       default/         default/istio-system