4个步骤排查istio服务网格的网络问题

标签: istio 服务 网格 | 发表时间:2020-10-12 11:51 | 作者:Kingsluck
出处:http://weekly.dockone.io

对 istio 用户而言,最常见的场景之一是将 istio 用作 ingress 网关,通过其暴露微服务给外部客户端访问。具体而言有两种典型的方式。一种是只运行业务服务的容器,不携带 sidecar。另一种是运行携带 sidecar 的 Pod,业务服务和 ingress 网关之间建立 mTLS 双向认证进行通信。

最近,笔者帮一位 istio 用户排查问题:为什么通过 istio ingress 网关暴露的服务不能被 istio 网格外部的 CURL 客户端访问到。下文记录了笔者排查问题时的关键步骤,希望能帮助到遇到类似问题的用户。

1. 使用 istioctl analyzer 命令

使用 istioctl analyzer 命令排查和故障服务相关的每个 istio 资源,这是我最喜欢用的 istioctl 命令。

Analyzer允许用户检查特定命名空间(namespace)或是整个 Kubernetes 集群里的每一个YAML文件。最佳实践是,在用户部署 istio 资源之前,用 analyzer 命令检查 istio 待部署资源(如 gateway,virtual service)相关的 YAML 文件。这可以帮助用户提前发现问题。

shell
$ istioctl analyze helloworld-gw-nlb.yaml -n istio-system
✔ No validation issues found when analyzing namespace: istio-system.


如果 istio 资源已经生效,用户还可以将analyzer命令作用于整个集群,以检查现有集群是否存在和用户冲突的路由(route)。执行 istioctl analyze --all-namespaces 可以检查整个集群。

2. 验证 secret 是否被正确加载

出于安全考虑,用户会以加密的方式访问服务,可能是单边TLS或双向TLS认证。用户要确保 secret 在 ingress 网关中被正确加载,以便 ingress 网关能对入站流量进行加密。

istioctl proxy-config secret 命令可以帮助用户检查 ingress 网关中加载了哪些 secret,还可以通过它验证secret 的加载的时间及其有效时长。例如,下面的命令列出了ingress 网关加载的名为 mycluster-wdc06-b-406454-85f044fc29ce613c264409c04a76c95d-0001 secret 的具体信息,它是在安装 istio 过程中默认生成在 istio-system 命名空间下的。

shell
$ istioctl proxy-config secret istio-ingressgateway-768c6bf77b-2k7hm.istio-system
RESOURCE NAME TYPE STATUS VALID CERT SERIAL NUMBER NOT AFTER NOT BEFORE
mycluster-wdc06-b-406454-85f044fc29ce613c264409c04a76c95d-0001 Cert Chain ACTIVE true 415111668488852830681974512193801089848052 2020-12-05T09:43:42Z 2020-09-06T09:43:42Z


3. 检查 istio 网络资源

接下来就轮到检查边缘服务(edge serivce)相关的 gateway、virtual service 资源,以确保它们被正确地引用。

对于 gateway 资源,需要验证以下几点:

  • a. gateway 的命名空间正确,和网关所部署的命名空间一致。

  • b. gateway 中 credentialName 要和上述步骤2中网关加载的 secret 名称一致。在 istio1.7 版本中,secret 要和 gateway 归属于同一个命名空间。

  • c. host 字段填写正确。如果 virtual service 部署在了另一个命名空间,笔者建议在 host 字段加上该命名空间作为前缀。例如,hello/.。

  • d. 如果用户使用了自定义网关,确保选择器(selector)匹配。相关 gateway 资源的选择器必须和网关 deployment 的选择器匹配。


helloworld-gw-nlb.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: helloworld-gateway
namespace: istio-system # step a
spec:
selector:
istio: ingressgateway # step d
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: mycluster-wdc06-b-406454-85f044fc29ce613c264409c04a76c95d-0001 # step b
hosts:
- "hello/hello.mycluster-wdc06-b-406454-85f044fc29ce613c264409c04a76c95d-0001.us-east.containers.appdomain.cloud". #step c


对于 virtual service 则需要注意以下几点:

  • a. 确保 gateway 字段引用正确。如果 virtual service 引用了另一个命名空间的 gateway 对象,要在
    gateway前加上该命名空间作为前缀。

  • b. host 字段要和 gateway 资源里指定的值一致。

  • c. 确保 route 配置了正确的目标地址。当涉及到多个命名空间的流量转发时,host字段要补全。


helloworld-vs.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld
namespace: hello # step a
spec:
hosts:
- "hello.mycluster-wdc06-b-406454-85f044fc29ce613c264409c04a76c95d-0001.us-east.containers.appdomain.cloud" # step b
gateways:
- istio-system/helloworld-gateway # step a
http:
- match:
- uri:
exact: /hello
route:
- destination:
host: helloworld.hello.svc.cluster.local # step c
port:
number: 5000


4. 检查 ingress 网关的日志

检查ingress网关的日志,验证请求被网关正确接收,检查是否有错误日志。可以通过这篇文档

Requests are rejected by Envoy 查阅如何分析 ingress 网关日志及常见错误码释义。

有时候,为了方便查错,需要打开 ingress 网关的debug日志,可以通过如下命令实现:

istioctl proxy-config log {ingress-pod}.istio-system --level

或者通过以下命令检查Envoy配置是否正确:

istioctl dashboard envoy {ingress-pod}.istio-system

可以通过 Debugging Envoy and Istiod了解如何debug Envoy配置。

总结

通过以上技巧,笔者希望能帮助到大家快速定位排查 istio 相关的网络问题。

如果你还有问题,欢迎随时访问链接 Istio GitHub issuecollect all required information,提出你的issue。希望你有一个愉快的istio使用体验,无论你是否在 IBM 云上的 istio。

原作者:Lin Sun
原文地址: 4 steps to debug your edge microservices in an Istio service mesh

相关 [istio 服务 网格] 推荐:

4个步骤排查istio服务网格的网络问题

- - DockOne.io
对 istio 用户而言,最常见的场景之一是将 istio 用作 ingress 网关,通过其暴露微服务给外部客户端访问. 一种是只运行业务服务的容器,不携带 sidecar. 另一种是运行携带 sidecar 的 Pod,业务服务和 ingress 网关之间建立 mTLS 双向认证进行通信. 最近,笔者帮一位 istio 用户排查问题:为什么通过 istio ingress 网关暴露的服务不能被 istio 网格外部的 CURL 客户端访问到.

Istio 中的服务和流量的抽象模型

- - IT瘾-dev
本文介绍了 Istio 和 Kubernetes 中的一些服务和流量的抽象模型. 虽然 Istio 一开始确定的抽象模型与对接的底层平台无关,但目前来看基本绑定 Kubernetes,本文仅以 Kubernetes 说明. 另外在 ServiceMesher 社区中最近有很多关于 Istio、Envoy、Kubernetes 之中的服务模型关系的讨论,本文作为一个开篇说明,Kubernetes 和 Isito 之间有哪些共有的服务模型,Istio 在 Kubernetes 的服务模型之上又增加了什么,为什么说 Kubernetes service 存在的意义仅剩下做服务发现.

微服务全链路跟踪:jaeger集成istio,并兼容uber-trace-id与b3 - lipeng的个人空间 - OSCHINA

- -
微服务全链路跟踪:grpc集成zipkin. 微服务全链路跟踪:grpc集成jaeger. 微服务全链路跟踪:springcloud集成jaeger. 微服务全链路跟踪:jaeger集成istio,并兼容uber-trace-id与b3. 微服务全链路跟踪:jaeger集成hystrix. 公司有自己的一套基于k8s的paas系统,并且集成了istio,这里主要是想讲解下springcloud服务如何集成istio.

istio 原理简介

- - 掘金 架构
由于 istio 自 1.5 版本以后架构上有了较大变化,控制面从多组件变成了单体的 istiod 组件,所以下文会先介绍 1.5 之前的架构,再介绍 1.5 之后的,是一个由繁到简的过程. istio 1.5 之前架构. Istio 的架构分为控制平面和数据平面. 数据平面:由一组智能代理(Envoy)以 sidecar 模式部署,协调和控制所有服务之间的网络通信.

Istio 常见的 10 个异常分析

- - DockOne.io
本文总结了使用 Istio 常见的 10 个异常. Istio 支持多平台,不过 Istio 和 Kubernetes 的兼容性是最优的,不管是设计理念,核心团队还是社区, 都有一脉相承的意思. 但 Istio 和 Kubernetes 的适配并非完全没有冲突,一个典型问题就是 Istio 需要 Kubernetes Service 按照协议进行端口命名(Port Naming).

Istio究竟是干嘛的? - 知乎

- -
当微服务架构体系越来越复杂的时候,需要将“业务服务”和“基础设施”解耦,将一个微服务进程一分为二:. 一个进程实现业务逻辑,biz,即上图白色方块. 一个进程实现底层技术体系,proxy,即上图蓝色方块,负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施,都放到这一层实现. biz不管是调用服务,还是提供服务,都只与本地的proxy进行本地通信.

使用 Istio 进行金丝雀部署

- -
本篇博客最后更新时间 2018 年 5 月 16 号,采用了最新版本的流量管理模型. Istio项目的一大好处就是为服务金丝雀方式部署提供了控制便利. 金丝雀部署(或上线)背后的想法是通过让一小部分用户流量引入的新版本进行测试,如果一切顺利,则可以增加(可能逐渐增加)百分比,逐步替换旧版本. 如在过程中出现任何问题,则可以中止并回滚到旧版本.

实践k8s istio熔断 - fat_girl_spring - 博客园

- -
熔断主要是无感的处理服务异常并保证不会发生级联甚至雪崩的服务异常. 在微服务方面体现是对异常的服务情况进行快速失败,它对已经调用失败的服务不再会继续调用,如果仍需要调用此异常服务,它将立刻返回失败. 与此同时,它一直监控服务的健康状况,一旦服务恢复正常,则立刻恢复对此服务的正常访问. 这样的快速失败策略可以降低服务负载压力,很好地保护服务免受高负载的影响.

知乎落地的 Service Mesh Istio

- -
在知乎,我们很早就进行了非常彻底的容器化部署. 全站在线运行的微服务数量高达两千多个. 这些微服务通过我们自己维护的 RPC 框架和 Kodor 体系来实现服务互联的能力. 在这其中,我们也存在一系列的问题:. 各种基础组件维护成本比较高,单点风险存在. 各语言客户端特性难以统一,熔断、重试等特性实现颇有不同,且不能做到动态线上进行调整.

如何理解 Istio 中的 VirtualService 和 DestinationRule?

- - Jimmy Song - 专注于探索后 Kubernetes 时代的云原生新范式 – 博客
Istio 在刚开源的时候就定义了几十个 CRD,其中用于流量治理的有 RouteRule、 DestinationPolicy、 EgressRule 等,后来推出了 v1alpha3 API 使用 VirtualService 和 DestinationRule 等取代了之前的 API.