Istio 中的各组件端口及功能详解

标签: istio 端口 功能 | 发表时间:2022-05-08 10:18 | 作者:
出处:https://jimmysong.io/blog/

在我的前两篇博客中:

我向你详细介绍了 Istio 数据平面中的流量,但数据平面并不能孤立的存在,本文将向你展示 Istio 中的控制平面和数据平面各组件的端口及其功能,有助于你了解这些流量之间的关系及故障排查。

Istio 中的组件及端口示意图

按照习惯,我们首先展示一个全局示意图。下图展示的是 Istio 数据平面中 sidecar 的组成,以及与其交互的对象。

Istio sidecar 组成示意图

我们可以使用 nsenter 命令进入Bookinfo 示例的 productpage Pod的网络空间,查看其内部监听的端口信息。

Istio sidecar 中监听的端口信息

从图中我们可以看到除了 productpage 应用本身监听的 9080 端口以外,Sidecar 容器还有监听大量的其他端口,如 150001500115004150061502115090 等,你可以在 Istio 文档上了解 Istio 中使用的端口。

我们再进入 productpage Pod 中,使用 lsof -i 命令查看它打开的端口,如下图所示。

Productpage Pod 中打开的端口

我们可以看到其中有 pilot-agentistiod 建立了 TCP 连接,上文中所述的监听中的端口,还有在 Pod 内部建立的 TCP 连接,这些连接对应了文章开头的示意图。

Sidecar 容器( istio-proxy )的根进程是 pilot-agent,启动命令如下图所示:

Sidecar 中的进程

从图中我们可以看到,它 pilot-agent 进程的 PID 是 1,是它拉起了 envoy 进程。

istiod 的 Pod 中查看它打开的端口,如下图所示。

Istiod 中的端口

我们可以看到其中的监听的端口、进程间和远程通信连接。

Istio 中各端口的功能概述

这些端口在你进行问题排查时可以起着举足轻重的作用。下面将根据端口所在的组件和功能分类描述。

Istiod 中的端口

Istiod 中的端口相对比较少且功能单一:

  • 9876:ControlZ 用户界面,暴露 istiod 的进程信息
  • 8080: istiod 调试端口,通过该端口可以查询网格的配置和状态信息
  • 15010:暴露 xDS API 和颁发纯文本证书
  • 15012:功能同 15010 端口,但使用 TLS 通信
  • 15014:暴露控制平面的指标给 Prometheus
  • 15017:Sidecar 注入和配置校验端口

Sidecar 中的端口

从上文中,我们看到 sidecar 中有众多端口:

  • 15000:Envoy 管理接口,你可以用它来查询和修改 Envoy 代理的的配置,详情请参考 Envoy 文档
  • 15001:用于处理出站流量。
  • 15004:调试端口,将在下文中解释。
  • 15006:用于处理入站流量。
  • 15020:汇总统计数据,对 Envoy 和 DNS 代理进行健康检查,调试 pilot-agent 进程,将在下文中详细解释。
  • 15021:用于 sidecar 健康检查,以判断已注入 Pod 是否准备好接收流量。我们在该端口的 /healthz/ready 路径上设置了就绪探针,Istio 把 sidecar 的就绪检测交给了 kubelet,最大化利用 Kubernetes 平台自身的功能。 envoy 进程将健康检查路由到 pilot-agent 进程的 15020 端口,实际的健康检查将发生在那里。
  • 15053:本地 DNS 代理,用于解析 Kubernetes DNS 解析不了的集群内部域名的场景。
  • 15090:Envoy Prometheus 查询端口, pilot-agent 将通过此端口收集统计信息。

以上端口可以分为以下几类:

  • 负责进程间通信,例如 15001、15006、15053
  • 负责健康检查和信息统计,例如 150021、15090
  • 调试:15000、15004

下文将对几个重点端口详解。

15000 端口

15000 是 Envoy 的 Admin 接口,该接口允许我们修改 Envoy,并获得一个视图和查询指标和配置。

管理接口由一个具有多个端点的 REST API 和一个简单的用户界面组成,你可以使用下面的命令开启 productpage Pod 中的 Envoy 管理接口视图。

   kubectl -n default port-forward deploy/productpage-v1 15000

在浏览器中访问 http://localhost:15000,你将看到 Envoy Admin 界面如下图所示。

Envoy Admin 界面

15004 端口

通过 pilot-agent 代理 istiod 8080 端口上的调试端点,你可以进入数据平面 Pod 中访问 localhost 的 15004 端口查询网格信息,其效果与下面的 8080 端口等同。

8080 端口

你还可以在本地转发 istiod 8080 端口,请运行下面的命令。

   kubectl -n istio-system port-forward deploy/istiod 8080

在浏览器中访问 http://localhost:8080/debug,你将看到调试端点,如下图所示。

Pilot 调试控制台

当然,这只是一种获取网格信息和调试网格的方式,你还可以使用 istioctl 命令或 Kiali 来调试,那样将更加高效和直观。

15020 端口

15020 端口有三大功能:

  1. 汇总统计数据:查询 15090 端口获取 envoy 的指标,也可以配置查询应用程序的指标,将 envoy、应用程序和自身的指标汇总以供 Prometheus 收集。对应的调试端点是 /stats/prometheus
  2. 对 Envoy 和 DNS 代理进行健康检查:对应的调试端点是 /healthz/ready/app-health
  3. 调试 pilot-agent 进程:对应的调试端点是 /quitquitquitdebug/ndsz/debug/pprof

下图展示的是使用本地端口转发后,在浏览器中打开 http://localhost:15020/debug/pprof 看到的调试信息。

pprof 端点

图中信息展示的是 pilot-agent 的堆栈信息。

总结

通过对 Istio 中各组件端口的了解,你应该对 Istio 中各组件的关系及其内部流量有了更进一步的认识,熟悉这些端口的功能,有助于对网格的故障排除。

相关 [istio 端口 功能] 推荐:

Istio 中的各组件端口及功能详解

- - Jimmy Song - 云原生|开源|社区 – 博客
Istio 中的 Sidecar 注入、透明流量劫持及流量路由过程详解. Sidecar 中的流量类型及 iptables 规则详解. 我向你详细介绍了 Istio 数据平面中的流量,但数据平面并不能孤立的存在,本文将向你展示 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 中的服务和流量的抽象模型

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

洞若观火:使用 OpenTracing 增强 Istio 的调用链跟踪

- - IT瘾-dev
分布式调用跟踪和Opentracing规范. 什么是Opentracing. CNCF Opentracing项目. Opentracing概念模型. Opentracing数据模型. Istio对分布式调用跟踪的支持. 使用Opentracing来传递分布式跟踪上下文. 在Istio调用跟踪链中加入方法级的调用跟踪信息.

Service Mesh 最火项目: Istio 架构解析

- - IT瘾-tuicool
Istio 是一个开源的服务网格,可为分布式微服务架构提供所需的基础运行和管理要素. 随着各组织越来越多地采用云平台,开发者必须使用微服务设计架构以实现可移植性,而运维人员必须管理包含混合云部署和多云部署的大型分布式应用. Istio 采用一种一致的方式来保护、连接和监控微服务,降低了管理微服务部署的复杂性.