#服务网格
云原生服务网络管控基础设施
多地域服务网格的网络架构如何保障高可用通信？
什么是服务网格（Service Mesh）
服务网格（Service Mesh）是一种基础设施层技术，用于处理服务间通信。它的主要作用是解决服务间通信的复杂性，以提升应用程序的可维护性和可靠性。服务网格通常利用代理（agent）来拦截、处理和路由服务间的所有流量，从而实现服务治理、流量管理等功能。
举例：使用服务网格技术，一个在应用程序中由许多微服务构成的系统可以在不修改代码的情况下，为每个服务提供统一的安全策略、负载均衡、故障恢复等特性。
腾讯云的服务网格产品是腾讯云服务网格（Tencent Service Mesh，简称 TSM）。它是一个用于处理服务间通信的专用网络基础设施层，提供了流量管理、服务发现、请求路由、负载均衡等功能，可以帮助用户轻松构建、部署和管理现代微服务应用程序。... 展开详请
原因
已采纳
Pod 属于 StatefulSet，使用 headless service，在 istio 中对 headless service 的支持跟普通 service 不太一样，如果 pod 用的普通 service，对应的 listener 有兜底的 passthrough，即转发到报文对应的真实目的IP+Port，但 headless service 的就没有，我们理解是因为 headless service 没有 vip，它的路由是确定的，只指向后端固定的 pod，如果路由匹配不上就肯定出了问题，如果也用 passthrough 兜底路由，只会掩盖问题，所以就没有为 headless service 创建 passthrough 兜底路由。同样的业务，上了 istio 才会有这个问题，也算是 istio 的设计或实现问题。... 展开详请
示例场景
已采纳
解决方案
已采纳
使用网格一般不要直接访问 Pod IP，应该访问 service。如果实在有场景需要，同集群访问 statefulset pod ip 时带上 host，可以匹配上 headless service 路由，避免匹配不到发生 404。
解决方案
已采纳
可以通过 EnvoyFilter 调整 max_request_headers_kb 字段来提升 header 大小限制。
EnvoyFilter 示例（istio 1.6 验证通过）：
高版本兼容上面的 v2 配置，但建议用 v3 的 配置 (istio 1.8 验证通过)：
若 header 大小超过 96 KiB，这种情况本身也很不正常，建议将这部分数据放到 body。... 展开详请
现象
已采纳
Istio 使用 Envoy 作为数据面转发 HTTP 请求，而 Envoy 默认要求使用 HTTP/1.1 或 HTTP/2，当客户端使用 HTTP/1.0 时就会返回 426 Upgrade Required。
常见的 nginx 场景
已采纳
如果用 nginx 进行 proxy_pass 反向代理，默认会用 HTTP/1.0，你可以显示指定 proxy_http_version 为 1.1：
压测场景
解决方案：让 istio 支持 HTTP/1.0
已采纳
有些 SDK 或框架可能会使用 HTTP/1.0 协议，比如使用 HTTP/1.0 去资源中心/配置中心 拉取配置信息，在不想改动代码的情况下让服务跑在 istio 上，也可以修改 istiod 配置，加上 PILOT_HTTP10: 1 的环境变量来启用 HTTP/1.0，这个在 TCM 中已产品化，可以在网格基本信息页面的高级设置中开启：... 展开详请
现象
已采纳
原因分析
已采纳
此状态码说明 http 请求 header 大小超限了，默认限制为60KiB，由 HttpConnectionManager 配置的 max_request_headers_kb 字段决定，最大可调整到96KiB：
现象
已采纳
管理员云账号自授权
最佳实践
已采纳
规避方案
已采纳
规避方案为调整 sidecar 注入顺序。
在 istio 1.7，社区通过给 istio-injector 注入逻辑增加一个叫 HoldApplicationUntilProxyStarts 的开关来解决了该问题，开关打开后，proxy 将会注入到第一个 container。
示例：
查看 istio-injector 自动注入使用的 template，可以知道如果打开了 HoldApplicationUntilProxyStarts 就会为 sidecar 添加一个 postStart hook：
它的目的是为了阻塞后面的业务容器启动，sidecar 完全启动后才开始启动后面的业务容器。
开关配置分为全局和局部两种，下面介绍两种启用方法。
需要注意的是，打开开关后，意味着业务容器需要等 sidecar 完全 ready 后才能启动，会让 Pod 启动速度变慢一些。在需要快速扩容应对突发流量场景可能会显得吃力，所以建议是自行评估业务场景，利用局部配置的方法，只给需要的业务打开此开关。
在 TCM 中对这个进行了产品化，您可以在网格基本信息页的高级设置中，将 Sidecar 就绪保障开关打开，就相当于对所有 Sidecar 默认开启 holdApplicationUntilProxyStarts: true。... 展开详请
安全组没放通 NodePort
已采纳
TCM 安装的 ingressgateway ，暴露方式默认使用 CLB 绑定节点 NodePort，所以流量链路是: client –> CLB –> NodePort –> ingressgateway。
关键链路在于 CLB –> NodePort，CLB 转发的数据包不会做 SNAT，所以报文到达节点时源 IP 就是 client 的公网 IP，如果节点安全组入站规则没有放通 client –> NodePort 链路的话，是访问不通的。
解决方案1： 节点安全组入站规则对公网访问 NodePort 区间端口(30000-32768):
解决方案2： 若担心直接放开整个 NodePort 区间所有端口有安全风险，可以只暴露 ingressgateway service 所用到的 Nodeport。
解决方案3： 若只允许固定 IP 段的 client 访问 ingressgateway，可以只对这个 IP 段放开整个 NodePort 区间所有端口。
解决方案4： 为 ingressgateway 启用 CLB 直通 Pod，这样流量就不经过 NodePort，所以就没有此安全组问题。启用 CLB 直通 Pod 需要集群网络支持 VPC-CNI，详细请参考 如何启用 CLB 直通 Pod 。... 展开详请
腾讯云开发者
