流量管理问题
请求被 Envoy 拒绝
请求被拒绝有许多原因。弄明白为什么请求被拒绝的最好方式是检查 Envoy 的访问日志。默认情况下,访问日志被输出到容器的标准输出中。运行下列命令可以查看日志:
$ kubectl logs PODNAME -c istio-proxy -n NAMESPACE
在默认的访问日志输出格式中,Envoy 响应标志位于响应状态码之后,如果您使用自定义日志输出格式,请确保包含 %RESPONSE_FLAGS%
。
参考 Envoy 响应标志查看更多有关响应标志的细节。
通用响应标志如下:
NR
:没有配置路由,请检查您的DestinationRule
或者VirtualService
配置。UO
:上游溢出导致断路,请在DestinationRule
检查您的熔断器配置。UF
:未能连接到上游,如果您正在使用 Istio 认证,请检查双向 TLS 配置冲突。
路由规则似乎没有对流量生效
在当前版本的 Envoy Sidecar 实现中,加权版本分发被观测到至少需要 100 个请求。
如果路由规则在 Bookinfo 这个例子中完美地运行,但在您自己的应用中相似版本的路由规则却没有生效,可能因为您的 Kubernetes service 需要被稍微地修改。为了利用 Istio 的七层路由特性 Kubernetes service 必须严格遵守某些限制。参考 Pods 和 Services 的要求查看详细信息。
另一个潜在的问题是路由规则可能只是生效比较慢。在 Kubernetes 上实现的 Istio 利用一个最终一致性算法来保证所有的 Envoy Sidecar 有正确的配置包括所有的路由规则。一个配置变更需要花一些时间来传播到所有的 sidecar。在大型的集群部署中传播将会耗时更长并且可能有几秒钟的延迟时间。
设置 destination rule 之后出现 503 异常
如果在您应用了一个 DestinationRule
之后请求一个服务立即发生了 HTTP 503 异常,并且这个异常状态一直持续到您移除或回滚了这个 DestinationRule
,那么这个 DestinationRule
大概为这个服务引起了一个 TLS 冲突。
举个例子,如果在您的集群里配置了全局的 mutual TLS,这个 DestinationRule
肯定包含下列的 trafficPolicy
:
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
否则,这个 TLS mode 默认被设置成 DISABLE
会使客户端 sidecar 代理发起明文 HTTP 请求而不是 TLS 加密了的请求。因此,请求和服务端代理冲突,因为服务端代理期望的是加密了的请求。
任何时候您应用一个 DestinationRule
,请确保 trafficPolicy
TLS mode 和全局的配置一致。
路由规则没有对 ingress gateway 请求生效
假设您正在使用一个 Ingress Gateway
和相应的 VirtualService
来访问一个内部的服务。举个例子,您的 VirtualService
配置可能和如下配置类似:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapp
spec:
hosts:
- "myapp.com" # 或者您正在通过 IP 而不是 DNS 测试 ingress-gateway(例如 http://1.2.3.4/hello),也可以配置成 "*"
gateways:
- myapp-gateway
http:
- match:
- uri:
prefix: /hello
route:
- destination:
host: helloworld.default.svc.cluster.local
- match:
...
您还有一个 VirtualService
将访问 helloworld 服务的流量路由至该服务的一个特定子集:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: helloworld
spec:
hosts:
- helloworld.default.svc.cluster.local
http:
- route:
- destination:
host: helloworld.default.svc.cluster.local
subset: v1
此时您会发现,通过 ingress 网关访问 helloworld 服务的请求没有直接路由到服务实例子集 v1,而是仍然使用默认的轮询调度路由。
Ingress 请求经由网关主机(如:myapp.com
)进行路由,网关主机将激活 myapp VirtualService
中的规则,将请求路由至 helloworld 服务的任何一个实例端点。
只有通过主机 helloworld.default.svc.cluster.local
访问的内部请求才会使用 helloworld VirtualService
,其中的规则直接将流量路由至服务实例子集 v1。
为了控制从 gateway 过来的流量,您需要在 myapp VirtualService
的配置中包含 subset 规则配置:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapp
spec:
hosts:
- "myapp.com" # 或者您正在通过 IP 而不是 DNS 测试 ingress-gateway(例如 http://1.2.3.4/hello),也可以配置成 "*"
gateways:
- myapp-gateway
http:
- match:
- uri:
prefix: /hello
route:
- destination:
host: helloworld.default.svc.cluster.local
subset: v1
- match:
...
或者,您可以尽可能地将两个 VirtualService
配置合并成一个:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapp
spec:
hosts:
- myapp.com # 这里不能使用“*”,因为这是与网格服务关联在一起的。
- helloworld.default.svc.cluster.local
gateways:
- mesh # 内部和外部都可以应用
- myapp-gateway
http:
- match:
- uri:
prefix: /hello
gateways:
- myapp-gateway # 只对 ingress gateway 严格应用这条规则
route:
- destination:
host: helloworld.default.svc.cluster.local
subset: v1
- match:
- gateways:
- mesh # 应用到网格中的所有服务
route:
- destination:
host: helloworld.default.svc.cluster.local
subset: v1
Envoy 在负载下崩溃
检查您的 ulimit -a
。许多系统有一个默认只能有打开 1024 个文件描述符的限制,它将导致 Envoy 断言失败并崩溃:
[2017-05-17 03:00:52.735][14236][critical][assert] assert failure: fd_ != -1: external/envoy/source/common/network/connection_impl.cc:58
请确保增大您的 ulimit。例如: ulimit -n 16384
Envoy 不能连接到 HTTP/1.0 服务
Envoy 要求上游服务使用 HTTP/1.1
或者 HTTP/2
协议流量。举个例子,当在 Envoy 之后使用 NGINX 来代理您的流量,您将需要在您的 NGINX 配置里将 proxy_http_version 设置为 “1.1”,因为 NGINX 默认的设置是 1.0。
示例配置为:
upstream http_backend {
server 127.0.0.1:8080;
keepalive 16;
}
server {
...
location /http/ {
proxy_pass http://http_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
...
}
}
TLS 配置错误
许多流量管理问题是由于错误的 TLS 配置 而导致的。 以下各节描述了一些最常见的错误配置。
将 HTTPS 流量发送到 HTTP 端口
如果您的应用程序向声明为 HTTP 的服务发送 HTTPS 请求,Envoy Sidecar 将在转发请求时尝试将请求解析为 HTTP, 这会使 HTTP 被意外加密,从而导致失败。
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: httpbin
spec:
hosts:
- httpbin.org
ports:
- number: 443
name: http
protocol: HTTP
resolution: DNS
虽然如果您有意在端口 443 上发送明文(如,curl http://httpbin.org:443
),上述配置可能是正确的,但是一般情况下,443 端口专用于 HTTPS 流量。
发送像 curl https://httpbin.org
这样的 HTTPS 请求(默认端口为443)将导致类似于 curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
的错误。
访问日志也可能显示如 400 DPE
的错误。
要解决这个问题,您应该将端口协议改为 HTTPS:
spec:
ports:
- number: 443
name: https
protocol: HTTPS
网关到 VirtualService
的 TLS 不匹配
将 VirtualService
绑定到网关时,可能会发生两种常见的 TLS 不匹配。
- 网关终止了 TLS,而
VirtualService
配置 TLS 路由。 - 网关启用 TLS 透传,而
VirtualService
配置了 HTTP 路由。
网关和 TLS termination
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: gateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- "*"
tls:
mode: SIMPLE
credentialName: sds-credential
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: httpbin
spec:
hosts:
- "*.example.com"
gateways:
- istio-system/gateway
tls:
- match:
- sniHosts:
- "*.example.com"
route:
- destination:
host: httpbin.org
在此示例中,当 VirtualService
使用基于 TLS 的路由时,网关将终止TLS。
因为在计算路由规则时 TLS 已经终止,所以 TLS 路由规则将无效。
使用这种错误配置,您将最终获得404响应,因为请求将发送到 HTTP 路由,但未配置 HTTP 路由。
您可以使用 istioctl proxy-config routes
命令确认这一点。
要解决这个问题,您应该切换 VirtualService
来指定 http
路由,而不是 tls
:
spec:
...
http:
- match: ...
网关和 TLS passthrough
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: gateway
spec:
selector:
istio: ingressgateway
servers:
- hosts:
- "*"
port:
name: https
number: 443
protocol: HTTPS
tls:
mode: PASSTHROUGH
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: virtual-service
spec:
gateways:
- gateway
hosts:
- httpbin.example.com
http:
- route:
- destination:
host: httpbin.org
在此配置中,VirtualService
试图将 HTTP 流量与通过网关的 TLS 流量进行匹配。
这将导致 VirtualService
配置无效。您可以使用 istioctl proxy-config listener
和 istioctl proxy-config route
命令观察到未应用 HTTP 路由。
要解决这个问题,您应该切换 VirtualService
以配置 TLS 路由。
spec:
tls:
- match:
- sniHosts: ["httpbin.example.com"]
route:
- destination:
host: httpbin.org
另外,您可以通过在网关中切换 tls
配置来终止 TLS,而不是通过它:
spec:
...
tls:
credentialName: sds-credential
mode: SIMPLE
双 TLS(TLS 源发起 TLS 连接)
将 Istio 配置为执行 TLS origination 时,您需要确保应用程序将纯文本请求发送到 sidecar,sidecar 将随后发起 TLS。
下述 DestinationRule
向 httpbin.org
服务发起 TLS 连接,但相应的 ServiceEntry
在端口 443 上将协议定义为 HTTPS。
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: httpbin
spec:
hosts:
- httpbin.org
ports:
- number: 443
name: https
protocol: HTTPS
resolution: DNS
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: originate-tls
spec:
host: httpbin.org
trafficPolicy:
tls:
mode: SIMPLE
使用此配置,Sidecar 期望应用程序在端口443上发送TLS通信 (如,curl https://httpbin.org
),但它也将在转发请求之前发起 TLS 连接。
这将导致对请求进行双重加密。
例如,发送 curl https://httpbin.org
之类的请求将导致错误:
(35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
。
您可以通过将 ServiceEntry
中的端口协议更改为 HTTP 来解决此示例:
spec:
hosts:
- httpbin.org
ports:
- number: 443
name: http
protocol: HTTP
请注意,使用此配置,您的应用程序将需要向端口 443 发送纯文本请求,例如 curl http://httpbin.org:443
,因为 TLS 连接不会更改端口。
但是,从 Istio 1.8 开始,您可以将 HTTP 端口 80 暴露给应用程序(例如,curl http://httpbin.org
),然后将请求重定向到 targetPort
443 以用于发起 TLS:
spec:
hosts:
- httpbin.org
ports:
- number: 80
name: http
protocol: HTTP
targetPort: 443
当为多个 Gateway 配置了相同的 TLS 证书导致 404 异常
多个网关配置同一 TLS 证书会导致浏览器在与第一台主机建立连接之后访问第二台主机时利用 HTTP/2 连接复用(例如,大部分浏览器)从而导致 404 异常产生。
举个例子,假如您有 2 个主机共用相同的 TLS 证书,如下所示:
- 通配证书
*.test.com
被安装到istio-ingressgateway
Gateway
将gw1
配置为主机service1.test.com
,选择器istio: ingressgateway
,并且 TLS 使用 gateway 安装的(通配)证书Gateway
将gw2
配置为主机service2.test.com
,选择器istio: ingressgateway
,并且 TLS 使用 gateway 安装的(通配)证书VirtualService
将vs1
配置为主机service1.test.com
并且 gateway 配置为gw1
VirtualService
将vs2
配置为主机service2.test.com
并且 gateway 配置为gw2
因为两个网关都由相同的工作负载提供服务(例如,选择器 istio: ingressgateway
),到两个服务的请求(service1.test.com
和 service2.test.com
)将会解析为同一 IP。
如果 service1.test.com
首先被接受了,它将会返回一个通配证书(*.test.com
)使得到 service2.test.com
的连接也能够使用相同的证书。
因此,Chrome 和 Firefox 等浏览器会自动使用已建立的连接来发送到 service2.test.com
的请求。
因为 gateway(gw1
)没有到 service2.test.com
的路由信息,它会返回一个 404 (Not Found) 响应。
您可以通过配置一个单独的通用 Gateway
来避免这个问题,而不是两个(gw1
和 gw2
)。
然后,简单地绑定两个 VirtualService
到这个单独的网关,比如这样:
Gateway
将gw
配置为主机*.test.com
,选择器istio: ingressgateway
,并且 TLS 使用网关挂载的(通配)证书VirtualService
将vs1
配置为主机service1.test.com
并且 gateway 配置为gw
VirtualService
将vs2
配置为主机service2.test.com
并且 gateway 配置为gw
不发送 SNI 时配置 SNI 路由
指定 hosts
字段的 HTTPS Gateway
将对传入请求执行 SNI 匹配。
例如,以下配置仅允许在 SNI 中匹配 *.example.com
的请求:
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- "*.example.com"
这可能会导致某些请求失败。
例如,如果您没有设置 DNS,而是直接设置主机标头,例如 curl 1.2.3.4 -H "Host: app.example.com"
,则 SNI 不会被设置,从而导致请求失败。
相反,您可以设置 DNS 或使用 curl
的 --resolve
标志。 有关更多信息,请参见安全网关。
另一个常见的问题是 Istio 前面的负载均衡器。 大多数云负载均衡器不会转发 SNI,因此,如果您要终止云负载均衡器中的 TLS,则可能需要执行以下操作之一:
- 将云负载均衡器改为 TLS 连接方式
- 通过将 hosts 字段设置为
*
来禁用Gateway
中的 SNI 匹配
常见的症状是负载均衡器运行状况检查成功,而实际流量失败。