应用程序要求
Istio 为应用程序提供了大量的功能，而对应用程序代码本身几乎没有影响。 许多 Kubernetes 应用程序可以部署在启用 Istio 的集群中，而不需要对应用程序做任何修改。 然而，在部署启用 Istio 的应用程序时，需要特别注意 Istio Sidecar 模型造成的影响。 本文介绍了针对这些应用程序的注意事项以及启用 Istio 的具体要求。
Pod 要求
作为 Istio 服务网格中的一部分，Kubernetes 集群中的 Pod 和 Service 必须满足以下要求：
应用 UID：确保您的 Pod 不会被 ID（UID）为
1337的用户运行应用，因为1337是为 Sidecar 代理保留的。NET_ADMIN和NET_RAW权限：如果您的集群强制执行了 Pod 安全策略， 必须给 Pod 配置NET_ADMIN和NET_RAW权限。如果您使用 Istio CNI 插件，可以不配置。要检查您的 Pod 是否有
NET_ADMIN和NET_RAW权限，您需要检查这些 Pod 的服务账户是否有NET_ADMIN和NET_RAW权限的 Pod 安全策略。如果您没有在 Pod 部署中指定服务账户， Pod 会使用其命名空间中的默认服务账户运行。要列出服务账户的权限，请在下面的命令中用您的值替换
<your namespace>和<your service account>。$ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:<your namespace>:<your service account>) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done例如，要检查
default命名空间中的default服务账户，运行以下命令：$ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:default:default) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done如果您在服务账户的允许策略的功能列表中看到
NET_ADMIN、NET_RAW或*， 则您的 Pod 有权限运行 Istio Init 容器。否则， 您将需要提供权限。Pod 标签（label）：我们建议使用 Pod 标签显式声明带有应用程序标识符和版本的 Pod。 这些标签将上下文信息添加到 Istio 收集的指标和遥测数据中。 每个值都是从多个标签中读取的，按优先级从最高到最低的顺序排列：
- 应用程序名称：
service.istio.io/canonical-name、app.kubernetes.io/name或app。 - 应用程序版本：
service.istio.io/canonical-revision、app.kubernetes.io/version或version。
- 应用程序名称：
已命名 Service 端口：可以选择已命名 Service 端口用于显式指定协议。 更多详细信息请参见协议选择。 如果一个 Pod 属于多个 Kubernetes Service， 这些 Service 不能对不同的协议（例如 HTTP 和 TCP）使用相同的端口号。
Istio 使用的端口
Istio Sidecar 代理（Envoy）使用以下端口和协议。
| 端口 | 协议 | 描述 | 仅限 Pod 内部 |
|---|---|---|---|
| 15000 | TCP | Envoy 管理端口（命令/诊断） | 是 |
| 15001 | TCP | Envoy 出站 | 否 |
| 15004 | HTTP | 调试端口 | 是 |
| 15006 | TCP | Envoy 入站 | 否 |
| 15008 | H2 | HBONE mTLS 隧道端口 | 否 |
| 15020 | HTTP | 从 Istio 代理、Envoy 和应用程序合并的 Prometheus 遥测 | 否 |
| 15021 | HTTP | 健康检查 | 否 |
| 15053 | DNS | DNS 端口，如果启用了捕获 | 是 |
| 15090 | HTTP | Envoy Prometheus 遥测 | 否 |
Istio 控制平面（istiod）使用以下端口和协议。
| 端口 | 协议 | 描述 | 仅限本地主机 |
|---|---|---|---|
| 443 | HTTPS | Webhook 服务端口 | 否 |
| 8080 | HTTP | 调试接口（已弃用，仅限容器端口） | 否 |
| 15010 | GRPC | XDS 和 CA 服务（纯文本，仅用于安全网络） | 否 |
| 15012 | GRPC | XDS 和 CA 服务（TLS 和 mTLS，推荐用于生产） | 否 |
| 15014 | HTTP | 控制平面监控 | 否 |
| 15017 | HTTPS | Webhook 容器端口，从 443 转发 | 否 |
服务器优先协议
一些协议是 “服务器优先” 协议，这意味着服务器将发送第一个字节。这可能会对
PERMISSIVE
mTLS 和自动协议选择产生影响。
这两个功能都通过检查连接的初始字节来确定协议，这与服务器优先协议不兼容。
为了支持这些情况，
请按照显式协议选择步骤将应用程序的协议声明为 TCP。
已知以下端口通常承载服务器优先协议，并自动假定为 TCP：
| 协议 | 端口 |
|---|---|
| SMTP | 25 |
| DNS | 53 |
| MySQL | 3306 |
| MongoDB | 27017 |
因为 TLS 通信不是服务器优先的，所以 TLS 加密的服务器优先流量将与自动协议检测一起使用，只要您确保所有经过 TLS 嗅探的流量都已加密：
- 将服务器的
mTLS模式设置为STRICT。这将对所有请求强制执行 TLS 加密。 - 将服务器的
mTLS模式设置为DISABLE。这将禁用 TLS 嗅探，允许使用服务器优先协议。 - 配置所有客户端发送
TLS流量，通常通过DestinationRule或依赖自动 mTLS。 - 将您的应用程序配置为直接发送 TLS 流量。
出站流量
为了支持 Istio 的流量路由功能，离开 Pod 的流量可能与未部署 Sidecar 时的流量不同。
对基于 HTTP 的流量，流量根据 Host 标头进行路由。如果目标 IP 和 Host
标头未对齐，这可能会导致意外行为。例如，curl 1.2.3.4 -H "Host: httpbin.default"
请求将被路由到 httpbin 服务，而不是 1.2.3.4。
对不基于 HTTP 的流量（包括 HTTPS），Istio 无法访问 Host 标头，
因此路由决策基于服务 IP 地址。
这意味着直接调用 Pod（例如，curl <POD_IP>），而不匹配 Service。
虽然流量可以通过，
但它不会获得 mTLS 加密、流量路由和遥测等完整的 Istio 功能。
相关的更多信息，请参阅流量路由页面。