Istio 是一个开放的、平台无关的服务网格，提供流量管理、策略执行和遥测收集功能。

开放：Istio 正在作为开源软件进行开发和维护。我们鼓励来自社区的贡献和反馈。

平台无关：Istio 不针对任何特定的部署环境。在开发的初始阶段，Istio 将支持基于 Kubernetes 的部署。但是，Istio 正在构建以实现对其他环境的快速和轻松适配。

服务网格：Istio 旨在管理微服务和应用程序之间的通信。无需更改底层服务，Istio 即可为所有服务间通信提供自动化的基础流量弹性、服务指标收集、分布式跟踪、流量加密、协议升级和高级路由功能。

更多详细信息，请参阅 Istio 服务网格

传统上，Istio 处理的大部分逻辑都直接构建在应用程序中。在整个服务集群中，管理此通信逻辑的更新可能是一个巨大的负担。Istio 提供了一个基础设施级别的解决方案来管理服务通信。

应用程序开发人员：通过 Istio 管理流量如何在服务之间流动，开发人员可以专注于业务逻辑并快速迭代新功能。

服务运营商：Istio 允许从单个集中控制点执行策略和监控网格，而与应用程序演变无关。因此，运营商可以通过简化的管理平面确保持续的策略合规性。

我们建议按照 入门页面 上的说明进行操作，该页面将安装演示配置以及 Istio 的主要示例应用程序 Bookinfo。然后，您可以使用此设置 逐步完成各种 Istio 指南，这些指南以教程的形式展示了智能路由、策略执行、安全、遥测等。

要开始将 Istio 与生产 Kubernetes 部署一起使用，请参阅我们的 部署模型 文档和 我应该使用哪种 Istio 安装方法？ 常见问题解答页面。

Istio 使用 Apache License 2.0。

Istio 项目由来自 Google 和 IBM 的团队与来自 Lyft 的 Envoy 团队合作启动。它已在 GitHub 上完全公开开发。

Istio 旨在成为平台无关的，最初专注于 Kubernetes。对于我们的 1.24 版本，Istio 支持运行 Kubernetes（1.28、1.29、1.30、1.31）的环境。

非常欢迎您的贡献。我们期待社区的反馈、补充和错误报告。

代码存储库托管在 GitHub 上。请参阅我们的 贡献指南 以了解如何贡献。

除了代码之外，还有 其他方法可以为 Istio 社区做出贡献，包括在我们的 讨论论坛、Slack 和 Stack Overflow 上。

查看 istio.io 上的 文档。文档包括 概念概述、任务指南、示例 和 完整的参考文档。

详细的开发人员级文档维护在我们的 Wiki 上

查看 操作指南 以查找解决方案，以及我们的 错误报告 页面以提交错误。

查看我们的 功能阶段页面 和 新闻 以了解最新情况。

它是希腊语中“帆”的意思。

如果您想与我们社区的成员进行实时互动，您可以加入我们位于 Istio 的 Slack 工作区。

除了简单的 入门 评估安装之外，还可以使用多种不同的方法来安装 Istio。您应该使用哪种方法取决于您的生产需求。以下是每种可用方法的一些优缺点列表

1. istioctl install

   最简单、最合格的安装和管理路径，安全性高。这是社区推荐的大多数用例的方法。

   优点

   • 彻底的配置验证和健康验证。
   • 使用 IstioOperator API，提供广泛的配置/自定义选项。

   缺点

   • 必须管理多个二进制文件，每个 Istio 次要版本一个。
   • istioctl 命令可以根据您的运行环境自动设置值，从而在不同的 Kubernetes 环境中生成不同的安装。

2. istioctl manifest generate

   生成 Kubernetes 清单，然后使用 kubectl apply --prune 应用。此方法适用于需要严格审计或增强输出清单的情况。

   优点

   • 资源是从与 istioctl install 中使用的相同的 IstioOperator API 生成的。
   • 使用 IstioOperator API，提供广泛的配置/自定义选项。

   缺点

   • istioctl install 中执行的一些检查未执行。
   • 与 istioctl install 相比，UX 不那么流畅。
   • 对于应用步骤，错误报告不如 istioctl install 强大。

3. 使用 Helm 安装

   使用 Helm 图表可以轻松与基于 Helm 的工作流集成，并在升级期间自动修剪资源。

   优点

   • 使用行业标准工具的熟悉方法。
   • Helm 原生版本和升级管理。

   缺点

   • 与 istioctl install 相比，检查和验证较少。
   • 一些管理任务需要更多步骤并且复杂性更高。

所有这些方法的安装说明都可以在 Istio 安装页面 上找到。

确保您的集群已满足 自动 sidecar 注射的前提条件。如果您的微服务部署在 kube-system、kube-public 或 istio-system 命名空间中，则它们将免于自动 sidecar 注射。请改用其他命名空间。

Istio 的 ztunnel 不会在 Kubernetes 集群中引入单点故障 (SPOF)。ztunnel 的故障仅限于单个节点，这被认为是集群中一个易出错的组件。它的行为与集群上运行的其他节点关键基础设施（例如 Linux 内核、容器运行时等）相同。在设计良好的系统中，节点故障不会导致集群故障。了解更多。

您可以随时使用 身份验证策略 和 目标规则 更改服务的双向 TLS 设置。有关更多详细信息，请参阅 任务。

身份验证策略 可以是网格范围的（影响网格中的所有服务）、命名空间范围的（同一命名空间中的所有服务）或服务特定的。您可以拥有策略或策略以任何您想要的方式为集群中的服务设置双向 TLS。

如果您使用 values.global.proxy.privileged=true 安装了 Istio，则可以使用 tcpdump 确定加密状态。此外，在 Kubernetes 1.23 及更高版本中，作为以特权方式安装 Istio 的替代方法，您可以使用 kubectl debug 在 临时容器 中运行 tcpdump。有关说明，请参阅 Istio 双向 TLS 迁移。

启用 STRICT 双向 TLS 时，非 Istio 工作负载无法与 Istio 服务通信，因为它们将没有有效的 Istio 客户端证书。

如果需要允许这些客户端，则可以将双向 TLS 模式配置为 PERMISSIVE，允许明文和双向 TLS。这可以针对单个工作负载或整个网格进行。

有关更多详细信息，请参阅 身份验证策略。

如果启用了双向 TLS，来自 kubelet 的 HTTP 和 TCP 健康检查将无法正常工作，除非进行修改，因为 kubelet 没有 Istio 发行的证书。

有几个选项

1. 使用探针重写将存活性探针和就绪性探针请求直接重定向到工作负载。有关更多信息，请参阅 探针重写。默认情况下启用此功能，并建议使用。

2. 为健康检查使用单独的端口，并在常规服务端口上仅启用双向 TLS。有关更多信息，请参阅 Istio 服务的健康检查。

3. 对工作负载使用 PERMISSIVE 模式，以便它可以接受明文和双向 TLS 流量。请记住，使用此选项不会强制执行双向 TLS。

对于在 Kubernetes 中运行的工作负载，其 Istio 证书的生命周期默认为 24 小时。

可以通过自定义 代理配置 的 proxyMetadata 字段来覆盖此配置。例如

proxyMetadata:
  SECRET_TTL: 48h

否。当在服务器工作负载上使用 traffic.sidecar.istio.io/excludeInboundPorts 时，Istio 仍然默认配置客户端 Envoy 发送双向 TLS。要更改此设置，您需要配置一个目标规则，并将双向 TLS 模式设置为 DISABLE，以便客户端向这些端口发送明文。

您可能会发现安装 Istio 后 MySQL 无法连接。这是因为 MySQL 是一种 服务器优先 协议，它可能会干扰 Istio 的协议检测。特别是使用 PERMISSIVE mTLS 模式可能会导致问题。您可能会看到错误消息，例如 ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0。

可以通过确保使用STRICT或DISABLE模式，或者所有客户端都配置为发送mTLS来解决此问题。有关更多信息，请参阅服务器优先协议。

是的。Istio为网格中的HTTP和普通TCP服务提供授权功能。了解更多。

通过遵循安全入口流量任务中的说明，可以将Istio Ingress配置为仅接受TLS流量。

可以，您可以。它在启用和禁用双向TLS的情况下均有效。

您可以使用Prometheus收集有关Istio的遥测数据。然后使用Prometheus的HTTP API查询这些数据。

与基于Mixer的遥测（又名v1）方法相比，代理内遥测（又名v2）降低了资源成本并提高了代理性能，并且是Istio中显示遥测的首选机制。但是，v1和v2之间报告的遥测数据存在一些差异，如下所示

• 缺少网格外流量的标签 代理内遥测依赖于Envoy代理之间的元数据交换来收集对等工作负载名称、命名空间和标签等信息。在基于Mixer的遥测中，此功能由Mixer执行，作为将请求属性与平台数据相结合的一部分。Envoy代理通过为HTTP协议添加特定的HTTP标头或为TCP协议增强ALPN协议来执行此元数据交换，如此处所述。这需要在客户端和服务器工作负载上注入Envoy代理，这意味着当一个对等方不在网格中时报告的遥测将缺少对等方属性，如工作负载名称、命名空间和标签。但是，如果两个对等方都注入了代理，则此处提到的所有标签都可以在生成的指标中使用。当服务器工作负载位于网格外时，服务器工作负载元数据仍会分发到客户端sidecar，导致客户端指标的服务器工作负载元数据标签被填充。

• TCP元数据交换需要mTLS TCP元数据交换依赖于Istio ALPN协议，该协议要求为Envoy代理启用双向TLS（mTLS），以便成功交换元数据。这意味着如果在集群中未启用mTLS，则TCP协议的遥测将不包含对等方信息，如工作负载名称、命名空间和标签。

• 没有为直方图指标配置自定义桶的机制 基于Mixer的遥测支持为直方图类型指标（如请求持续时间和TCP字节大小）自定义桶。代理内遥测没有此类可用机制。此外，代理内遥测中延迟指标可用的桶以毫秒为单位，而基于Mixer的遥测中则以秒为单位。但是，在代理内遥测中，默认情况下，在较低延迟级别下，延迟指标可用的桶更多。

• 短生命周期指标没有指标过期 基于Mixer的遥测支持指标过期，其中在可配置的时间段内未生成的指标将取消注册以供Prometheus收集。这在生成短生命周期指标的场景（例如一次性作业）中非常有用。取消注册指标可以防止报告将来不再更改的指标，从而减少Prometheus中的网络流量和存储。代理内遥测中没有此过期机制。解决方法可以在这里找到。

短生命周期指标会影响Prometheus的性能，因为它们通常是标签基数的主要来源。基数是标签唯一值数量的度量。要管理短生命周期指标对Prometheus的影响，您必须首先识别高基数指标和标签。Prometheus在其/status页面上提供基数信息。可以通过PromQL检索其他信息。有几种方法可以降低Istio指标的基数

• 禁用主机头回退。destination_service标签是高基数的一个潜在来源。如果Istio代理无法从其他请求元数据中确定目标服务，则destination_service的值默认为主机头。如果客户端使用各种主机头，这可能会导致destination_service出现大量值。在这种情况下，请按照指标自定义指南在整个网格中禁用主机头回退。要为特定工作负载或命名空间禁用主机头回退，您需要复制stats EnvoyFilter配置，将其更新为禁用主机头回退，并使用更具体的选择器应用它。此问题详细介绍了如何实现此目的。
• 从收集中删除不必要的标签。如果不需要具有高基数的标签，您可以通过指标自定义使用tags_to_remove将其从指标收集中删除。
• 规范化标签值，可以通过联合或分类来实现。如果需要标签提供的信息，您可以使用Prometheus联合或请求分类来规范化标签。

Mixer已在Istio 1.8版本中删除。如果您仍然依赖Mixer的内置适配器或任何网格外适配器进行网格扩展，则需要进行迁移。

对于内置适配器，提供了几个替代方案

• Prometheus和Stackdriver集成作为代理扩展实现。可以通过请求分类和Prometheus指标自定义实现对这两个扩展生成的遥测数据的自定义。
• 全局和本地速率限制（memquota和redisquota适配器）功能通过基于Envoy的速率限制解决方案提供。
• OPA适配器被基于Envoy ext-authz的解决方案取代，该解决方案支持与OPA策略代理集成。

对于自定义网格外适配器，强烈建议迁移到基于Wasm的扩展。请参阅有关Wasm模块开发和扩展分发的指南。作为临时解决方案，您可以在Mixer中启用Envoy ext-authz和gRPC访问日志API支持，这允许您将Istio升级到1.7之后的版本，同时仍然使用1.7 Mixer和网格外适配器。这将为您提供更多时间迁移到基于Wasm的扩展。请注意，此临时解决方案未经过实战检验，并且不太可能获得补丁修复，因为它仅在Istio 1.7分支上可用，该分支在2021年2月之后已超出支持窗口。

您可以使用docker-compose安装Prometheus。

您可以启用跟踪以确定Istio中请求的流程。

此外，您可以使用以下命令来了解更多有关网格状态的信息

• istioctl proxy-config：在Kubernetes中运行时检索有关代理配置的信息

  # Retrieve information about bootstrap configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config bootstrap productpage-v1-bb8d5cbc7-k7qbm
  Retrieve information about cluster configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config cluster productpage-v1-bb8d5cbc7-k7qbm
  Retrieve information about listener configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config listener productpage-v1-bb8d5cbc7-k7qbm
  Retrieve information about route configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config route productpage-v1-bb8d5cbc7-k7qbm
  Retrieve information about endpoint configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config endpoints productpage-v1-bb8d5cbc7-k7qbm
  Try the following to discover more proxy-config commands
  $ istioctl proxy-config –help
  

• kubectl get：获取有关网格中不同资源以及路由配置的信息

  # List all virtual services
  $ kubectl get virtualservices
  

是的。Prometheus是一个开源监控系统和时间序列数据库。您可以将Prometheus与Istio一起使用来记录跟踪Istio和服务网格中应用程序运行状况的指标。您可以使用Grafana和Kiali等工具可视化指标。请参阅Prometheus配置，了解如何启用指标收集。

一些注意事项

• 如果Prometheus pod在istiod pod生成所需的证书并将其分发到Prometheus之前启动，则需要重新启动Prometheus pod才能从受双向TLS保护的目标收集数据。
• 如果您的应用程序在专用端口上公开Prometheus指标，则应将该端口添加到服务和部署规范中。

Istio使用基于Envoy的跟踪与分布式跟踪系统集成。通过基于Envoy的跟踪集成，应用程序负责转发跟踪标头以进行后续传出请求。

您可以在Istio分布式跟踪（Jaeger、Lightstep、Zipkin）任务以及Envoy跟踪文档中找到其他信息。

Istio能够报告网格内工作负载到工作负载通信的跟踪跨度。但是，为了完整查看流量流，将各种跟踪跨度拼接在一起，应用程序必须在传入和传出请求之间传播跟踪上下文。

特别是，Istio依赖于应用程序传播B3跟踪标头以及Envoy生成的请求ID。这些标头包括

• x-request-id
• x-b3-traceid
• x-b3-spanid
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags
• b3

如果您使用 Lightstep，则还需要转发以下标头

• x-ot-span-context

如果您使用 OpenTelemetry 或 Stackdriver，则还需要转发以下标头

• traceparent
• tracestate

标头传播可以通过客户端库实现，例如 Zipkin 或 Jaeger。它也可以手动完成，如 分布式跟踪任务 中所述。

对于基于 Envoy 的跟踪集成，Envoy（sidecar 代理）代表被代理的应用程序直接将跟踪信息发送到跟踪后端。

Envoy

• 为请求生成请求 ID 和跟踪标头（即 X-B3-TraceId），这些请求流经代理
• 根据请求和响应元数据（例如响应时间）为每个请求生成跟踪跨度
• 将生成的跟踪跨度发送到跟踪后端
• 将跟踪标头转发到代理应用程序

Istio 支持基于 Envoy 的 Lightstep 和 Zipkin 集成，以及所有与 Zipkin API 兼容的后端，包括 Jaeger。

启用了跟踪的 Istio 最小配置文件 是 Istio 与 Zipkin 兼容后端集成的全部要求。

如果请求未提供，则 Istio sidecar 代理 (Envoy) 会生成初始的 标头。

尽管 Istio sidecar 将处理关联应用程序实例的入站和出站请求，但它没有隐式的方法将出站请求与导致它们的入站请求关联起来。这种关联只能通过应用程序从入站请求到出站请求传播相关信息（即标头）来实现。标头传播可以通过客户端库或手动完成。在 Istio 的分布式跟踪需要什么？ 中提供了进一步的讨论。

从 Istio 1.0.3 开始，跟踪的采样率已在 default 配置配置文件 中降低到 1%。这意味着 Istio 捕获的 100 个跟踪实例中只有 1 个将报告到跟踪后端。demo 配置文件中的采样率仍设置为 100%。有关如何设置采样率的更多信息，请参阅 此部分。

如果您仍然没有看到任何跟踪数据，请确认您的端口符合 Istio 端口命名约定，并且已公开相应的容器端口（例如，通过 pod 规范）以启用 sidecar 代理 (Envoy) 的流量捕获。

如果您只看到与出口代理关联的跟踪数据，而没有看到与入口代理关联的跟踪数据，则可能仍与 Istio 端口命名约定 相关。从 Istio 1.3 开始，出站流量的协议会自动检测。

Istio 通过 Envoy 目前支持基于百分比的跟踪生成的采样策略。有关如何设置此采样率的更多信息，请参阅 此部分。

如果您已安装启用了跟踪的 Istio，则可以按如下方式禁用它

# Fill <istio namespace> with the namespace of your istio mesh.Ex: istio-system
TRACING_POD=`kubectl get po -n <istio namespace> | grep istio-tracing | awk '{print $1}'`
$ kubectl delete pod $TRACING_POD -n <istio namespace>
$ kubectl delete services tracing zipkin   -n <istio namespace>
# Now, manually remove instances of trace_zipkin_url from the file and save it.

然后按照 分布式跟踪任务的清理部分 中的步骤操作。

如果您根本不希望使用跟踪功能，则在安装 Istio 时 禁用跟踪。

为此，您必须使用 Zipkin 兼容实例的完全限定域名。例如：zipkin.mynamespace.svc.cluster.local。

Istio 目前不支持发布/订阅和事件总线协议。任何使用这些技术的行为都是尽力而为的，并且可能会出现故障。

可以使用 kubectl get virtualservice -o yaml 查看规则

默认情况下，Istio 会捕获所有端口上的入站流量。您可以使用 traffic.sidecar.istio.io/includeInboundPorts pod 注解覆盖此行为以指定要捕获的端口的显式列表，或者使用 traffic.sidecar.istio.io/excludeOutboundPorts 指定要绕过的端口列表。

这两个 DestinationRule 设置都将发送双向 TLS 流量。使用 ISTIO_MUTUAL，Istio 证书将自动使用。对于 MUTUAL，必须配置密钥、证书和受信任的 CA。这允许与非 Istio 应用程序启动双向 TLS。

是的，从 Istio 1.10 开始，Istio 完全支持这些工作负载。

简单的 ingress 规范（带有主机、TLS 和基于精确路径的匹配）无需路由规则即可开箱即用。但是，请注意，ingress 资源中使用的路径不应包含任何 . 字符。

例如，以下 ingress 资源匹配 example.com 主机的请求，并将 /helloworld 作为 URL。

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-ingress
  annotations:
    kubernetes.io/ingress.class: istio
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /helloworld
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

但是，以下规则将无法工作，因为它们在路径中使用了正则表达式和 ingress.kubernetes.io 注解

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: this-will-not-work
  annotations:
    kubernetes.io/ingress.class: istio
    # Ingress annotations other than ingress class will not be honored
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /hello(.*?)world/
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

应用 CORS 配置 后，您可能会发现似乎没有任何反应，并想知道出了什么问题。CORS 是一个常见的被误解的 HTTP 概念，在配置时经常会导致混淆。

要理解这一点，可以退一步看看 什么是 CORS 以及何时应该使用它。默认情况下，浏览器对脚本发起的“跨域”请求有限制。例如，这可以防止网站 attack.example.com 向 bank.example.com 发起 JavaScript 请求并窃取用户的敏感信息。

为了允许此请求，bank.example.com 必须允许 attack.example.com 执行跨域请求。这就是 CORS 的作用所在。如果我们在启用了 Istio 的集群中提供 bank.example.com，我们可以配置一个 corsPolicy 来允许这样做

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bank
spec:
  hosts:
  - bank.example.com
  http:
  - corsPolicy:
      allowOrigins:
      - exact: https://attack.example.com
...

在这种情况下，我们明确允许单个来源；通配符对于非敏感页面很常见。

完成此操作后，一个常见的错误是发送类似于 curl bank.example.com -H "Origin: https://attack.example.com" 的请求，并期望请求被拒绝。但是，curl 和许多其他客户端将看不到被拒绝的请求，因为 CORS 是浏览器约束。CORS 配置只是在响应中添加 Access-Control-* 标头；如果响应不令人满意，则由客户端（浏览器）拒绝请求。在浏览器中，这是通过 预检请求 完成的。

目前，Istio 支持基于 TCP 的协议。此外，Istio 还为其他协议（如 http 和 mysql）提供了路由和指标等功能。

有关所有协议的列表以及如何配置协议的信息，请查看 协议选择 文档。