《云原生网络数据面可观测性最佳实践》——二、全景剖析阿里云容器网络数据链路——6. ASM Istio 模式架构设计(上)

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 《云原生网络数据面可观测性最佳实践》——二、全景剖析阿里云容器网络数据链路——6. ASM Istio 模式架构设计(上)

近几年,企业基础设施云原生化的趋势越来越强烈,从最开始的IaaS化到现在的微服务化,客户的颗粒度精细化和可观测性的需求更加强烈。容器网络为了满足客户更高性能和更高的密度,也一直在高速的发展和演进中,这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。

 

为了提高云原生网络的可观测性,同时便于客户和前后线同学增加对业务链路的可读性,ACK产研和AES联合共建,合作开发ack net-exporter和云原生网络数据面可观测性系列,帮助客户和前后线同学了解云原生网络架构体系,简化对云原生网络的可观测性的门槛,优化客户运维和售后同学处理疑难问题的体验,提高云原生网络的链路的稳定性。image.png

图: 服务网格示例

image.png

图 Istio数据面示意图

 

Kubernetes的横空出现打破了底层服务器、底层网络等计算资源的界限,给业务的灵活部署、快速恢复、弹性伸缩,资源效率最大化带来了无限可能。

 

但是业务场景的‘贪婪’是无限的,随着微服务趋势大肆发展,业务上对于同一个service,不同版本和流量控制有着更精细化的颗粒度的需求,最好能实现Pod维度的流量控制,可观测性等等。这些在kubernetes上是无法实现的:

 

从流量角度,k8s最小控制维度是service其他比如金丝雀 等发布,借助各种ingress controller或者其他组件实现,并且这些也无法实现Pod之间流量和连接状态可观测性

k8s给服务微型化,小型化创造了条件如果前后端服务存在调用关心,他们如果使用共享通信库,则会在开发阶段就要求所有微服务使用相同逻辑语言和堆栈,这从某种程度上又大大限制微服务独立化,无法实现完全‘漠不关心’

将原来集成在同一个ECS上服务拆分成不同模块,这些模块之间调用涉及跨ECS等,那么必然需要在代码开发阶段需要考虑超时,重试,连接失败等逻辑机制,而这些与微服务最核心服务应用其实没有太大关系,但是开发工作往往耗费大量经历在逻辑设计上

 

那么,有没有办法实现上述和微服务的业务完全隔离呢?Istio的出现给这个带来了相对完美的解决方案,让应用这和开发者更加关注业务本身的开发迭代。Istio利用了k8s的Pod概念,会根据使用者的配置,在每个被注入的Pod部署时,自动注入istio-proxy 容器和initial 容器。

 

Initial容器的目的是通过修改Pod 单独网络命名空间的iptables规则,让需要代理的流量进入到istio-proxy 监听的端口,istio-proxy 监听出入 两个端口,根据网格配置,来实现对出入流量的代理实现和干预。而被同一个istio注入的载体,都被视为同一个服务网格之内,他们之间的调用已经脱离了service的层面,会命中相关的istio cluster配置的endpoint,这样我们就可以实现Pod维度的流量管理、观测性、安全性等配置。

 

1) Pod注入

ASM默认提供了一个Webhook控制器,可以将Sidecar代理自动添加到可用的Pod中。通过下面的命令可以看到ASM注入的集群有个 istio-sidecar-injector-1-15-3的mutatingwebhookconfiguration,查看webhook内容,可以看到其中一条就是有 istio-inject: enabled 标签的namespace  里的pod创建时候会自动注入。

image.pngimage.png

除了命名空间维度,还有Pod维度,其他注解方式等多种维度实现K8s集群是否被加入到Istio服务网格中。为了充分利用服务网格的所有特性,服务网格中ACK集群的应用Pod必须包含一个Sidecar代理。除了手动注入方式外,通常建议启用自动注入的方式来简化部署,ASM已经实现了注入配置的可视化操作,具体请见多种方式灵活开启自动注入

image.png

 

2) Pod流量转发

通过describe被注入的Pod,可以发现Pod中除了设置好的业务container,还多出两个容器:istio-proxy和init container:istio-init。这两个容器的镜像是一样的,只是运行的命令的不一样,这样的好处是只需要拉取一份镜像,节省了拉取镜像的时间。

image.png

 

3) Init Container

Init container 利用的是k8s的特性,一种具有特权的特殊容器,在Pod内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。每个Pod中可以包含多个容器和多个Init 容器。他与普通容器很像,但是有自己独特点:

 

多个init 容器是串行运行的。也就是说多个init 容器会依序运行,等上一个init 容器运行完毕结束后,才会开始运行下一个容器

只有等到所有init 容器全部运行结束退出后,业务容器才开始启动,在这之前,pod不会处于ready

如果Pod的Init 容器失败,kubelet 根据pod设置restartPolicy 进行相应action

 

既然现在了解了Init container的作用,那我们来看一下istio-init在启动的过程中做了哪些事情,可以通过下面的命令:

kubectl logs -n istio-inject productpage-v1-797d845774-dndmk -c istio-init

image.png

image.png

可以看到istio-init在启动过程中进行了一连串的iptables规则的生成和配置,比如出方向转发到15001端口;入方向转发到15006端口;访问15008端口,直接return不进行流量劫持等等。

 

那有什么办法可以自定义配置么?查看pod的信息可以看到相关配置的启动参数,也就通过相关规则实现了出入流量重定向到设置的端口。

image.png

 

-p: 所有出方向的流量被iptables重定向到15001端口

-z: 所有入方向的流量被iptables重定向到15006端口

-u: 用于排除用户ID为1337,可以视为envoy应用本身使用UID 1337

-m: 流量重定向模式,“REDIRECT” 或 “TPROXY”

-i: 重定向出方向的地址范围,“*” 表示重定向所有出站流量。

-x: 指将从重定向出方向中排除的IP 地址范围

-b: 重定向入站端口列表

-d: 重定向入站端口中排除的端口列表

 

我们从Pod的视角去观察,将Pod视为一个整体,里面有istio-proxy容器和业务容器APP container

入方向流量转发

image.png

 

根据上文的iptables 规则,我们可以归纳出被入方向代理转发的端口,比如80等,在Pod的网络命名空间netfilter模块经过流程是Client -> RREROUTING -> ISTIO_INBOUND -> ISTIO_IN_REDIRECT -> INPUT -> Envoy 15006(Inbound)-> OUTPUT -> ISTIO_OUTPUT -> POSTROUTING -> APP。这样就实现了入方向流量先被转发到sidecar容器后,在转发到业务容器的监听端口。其中在步骤5和6 之间,流量会按照设置好的istio规则进行处理。

 

出方向流量转发

image.png

 

根据上文的iptables 规则,我们可以归纳出被入方向代理转发的端口,比如80等,在Pod的网络命名空间netfilter模块经过流程是APP > OUTPUT -> ISTIO_OUTPUT -> ISTIO_REDIRECT -> Envoy 15001(Outbound)-> OUTPUT -> ISTIO_OUTPUT -> POSTROUTING -> DST。这样就实现了出方向流量先被转发到sidecar容器后,在转发到目的监听端口。其中在步骤d和e 之间,流量会按照设置好的istio规则进行处理。

入方向流量免转发

image.png

 

对于入方向的某些端口或者自定义端口,我们不需要它经过sidecar容器,iptables规则会设置将符合条件的入方向流量避免转发到15006端口,直接转发到业务容器监听端口 RREROUTING -> ISTIO_INBOUND -> INPUT -> APP。

 出方向流量免转发

image.png

 

对于出方向的某些端口或者自定义端口,我们不需要它经过sidecar容器,iptables规则会设置将符合条件的入方向流量避免转发到15001端口,直接离开Pod的网络命名空间 APP -> OUTPUT -> ISTIO_OUTPUT -> POSTROUTING -> DST。


更多精彩内容,欢迎观看:

《云原生网络数据面可观测性最佳实践》——二、全景剖析阿里云容器网络数据链路——6. ASM Istio 模式架构设计(中):https://developer.aliyun.com/article/1221373?spm=a2c6h.13148508.setting.16.15f94f0eCydDfj


相关文章
|
2月前
|
负载均衡 网络协议 开发者
掌握 Docker 网络:构建复杂的容器通信
在 Docker 容器化环境中,容器间的通信至关重要。本文详细介绍了 Docker 网络的基本概念和类型,包括桥接网络、宿主网络、覆盖网络和 Macvlan 网络等,并提供了创建、管理和配置自定义网络的实用命令。通过掌握这些知识,开发者可以构建更健壮和灵活的容器化应用,提高应用的可扩展性和安全性。
|
21天前
|
弹性计算 Kubernetes 网络协议
阿里云弹性网络接口技术的容器网络基础教程
阿里云弹性网络接口技术的容器网络基础教程
阿里云弹性网络接口技术的容器网络基础教程
|
27天前
|
Docker 容器
docker中检查容器的网络模式
【10月更文挑战第5天】
85 1
|
30天前
|
监控 Kubernetes 测试技术
掌握Docker网络模式:构建高效容器通信
【10月更文挑战第3天】本文深入探讨了Docker的网络模式,包括它们的工作原理、使用场景以及如何配置和优化容器间的通信。希望能够帮助开发者在项目中有效地应用Docker网络模式,构建高效的容器化应用。
|
2月前
|
NoSQL 应用服务中间件 Redis
Docker跨宿主机容器通信-通过网络跨宿主机互联
这篇文章介绍了Docker容器跨宿主机通信的实现方法,包括Docker的四种网络模式(host、none、container、bridge)以及如何通过修改网络配置和添加路由规则来实现不同宿主机上的容器之间的互联。
197 0
Docker跨宿主机容器通信-通过网络跨宿主机互联
|
2月前
|
网络协议 安全 开发者
掌握 Docker 网络:构建复杂的容器通信
在 Docker 容器化环境中,容器间的通信至关重要。本文详细介绍了 Docker 网络的基础知识,包括网络驱动、端口映射和命名等核心概念,并深入探讨了 Bridge、Host、Overlay 和 Macvlan 四种网络类型的特点及应用场景。此外,还提供了创建、连接、查看和删除自定义网络的命令示例,以及高级网络配置方法,如网络命名空间、DNS 解析和安全通信配置,帮助开发者构建更健壮的容器化应用。
|
2月前
|
Linux 调度 Docker
容器网络概述
【9月更文挑战第9天】容器技术利用如命名空间(namespace)和控制组(cgroup)等技术创建隔离环境,实现资源限制与独立运行。命名空间避免命名冲突,cgroup则能对CPU、内存等资源进行限制。容器状态可通过镜像保存并标准化,确保在任何环境中都能复现相同状态。
|
7天前
|
监控 安全 Cloud Native
云原生安全:Istio在微服务架构中的安全策略与实践
【10月更文挑战第26天】随着云计算的发展,云原生架构成为企业数字化转型的关键。微服务作为其核心组件,虽具备灵活性和可扩展性,但也带来安全挑战。Istio作为开源服务网格,通过双向TLS加密、细粒度访问控制和强大的审计监控功能,有效保障微服务间的通信安全,成为云原生安全的重要工具。
24 2
|
30天前
|
Kubernetes 安全 微服务
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
48 8
|
1月前
|
Kubernetes 负载均衡 安全
Istio在微服务中释放服务网格的力量
Istio在微服务中释放服务网格的力量
48 4