FAQ

在您搜索有关 Istio 和服务网格技术的信息时，我们希望此常见问题解答对您有所帮助

常见问题

Istio 是什么？

Istio 是一个开放的、与平台无关的服务网格，提供了流量管理，策略下发，和远程收集能力。

开放：Istio 是作为一个开源软件来开发和管理的。我们鼓励社区各界来贡献和反馈。

平台无关 ：Istio 不是针对某一个特定的部署环境的。在初始开发阶段，Istio 将会支持基于 Kubernetes 的部署。但是，Istio 将会建设成可以快速方便的适应其它环境。

服务网格 ：Istio 的设计目标是管理微服务间和应用程序间的通信问题。而不用修改底层服务，Istio 针对所有服务之间的通信提供了自动的基线流量弹性，服务指标收集，分布式追踪，流量加密，协议升级和高级路由功能。

更多介绍，请看这里 Istio 是什么

为什么我想用 Istio？

按照传统做法，Istio 处理的大多数逻辑都是直接构建到应用程序中的。在一组服务中，要管理更新这块通信逻辑是一个繁重的任务。Istio 提供了一个基础架构级的方案来解决管理服务通信问题。

应用开发者 ：利用 Istio 管理服务间的流量，开发者就可以专注于业务逻辑开发和快速迭代新特性。

服务运维者 ：Istio 可以从一个中心控制点进行策略控制和网格监控，而不依赖应用程序的发展。因此，运维者可以通过简化的管理平面确保持续的策略控制。

我如何开始使用 Istio ？

我们建议您按照入门上的说明进行操作，Istio 的主要示例应用程序Bookinfo 应用示范了安装配置。您可以使用此设置来浏览各种Istio指南，该指南中的案例包括了智能路由、策略执行、安全、遥测等。

要在现有 Kubernetes 上部署和使用 Istio，请参阅我们的安装说明文档。

Istio 的许可证是什么？

Istio 使用了 Apache License 2.0。

Istio 是如何诞生的?

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

目前支持哪些部署环境？

Istio 是设计和构建为平台无关的。对于 1.14 版本，Istio 支持运行容器编排的平台环境，比如 Kubernetes (1.21, 1.22, 1.23, 1.24)。

我该如何贡献？

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

代码托管在 GitHub。请阅读贡献指南学习如何贡献。

除了代码之外，还有其他为 Istio 社区做出贡献的方式，包括我们的 discussion forum，Slack 和 Stack Overflow。

文档在哪里？

在 istio.io 查看文档。文档包括概念概述，任务指南，指南，和完整的参考文档。

详细的开发人员级别文档保留在我们的 Wiki

Istio 不工作了应该怎么做？

查看操作指南寻找解决方案或者错误报告页面去提交错误。

Istio 的路线图是什么？

查看我们的功能状态页面和新闻获取最新动态。

“Istio” 这个词是什么意思？

它是希腊语中的 “sail”。

如何加入 Istio Slack 工作区？

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

安装

我应该使用哪种方式安装 Istio ?

除了简单地入门评估版安装之外，您还可以使用几种不同的方式安装 Istio 。您应该根据您的生产要求来选择安装方式。

下面列出了每种安装方式的优缺点：

使用 istioctl 安装
具有高安全性的简单、合格的安装和管理方法。这是社区推荐的安装方法。
优点:
- 完整的配置和运行状态的验证。
- 使用提供了扩展的配置、自定义选项的 IstioOperator API。
- 不需要集群内的高权限 Pod 。通过执行 istioctl 命令修改。
缺点:
- 需要维护多个 Istio minor 版本的二进制文件。
- istioctl 命令可能根据您的运行环境设置诸如 JWT_POLICY 之类的值，从而能够在不同的 Kubernetes 环境中进行不同的安装。
使用 Istio Operator 安装
没有 istioctl 二进制文件的简单安安装方式。这是推荐的方法。用于简单升级工作，无需考虑运行集群内的高权限 Controller。
优点:
- 具有与 istioctl install 相同的 API ，但是通过据群众具有高权限的 Controller Pod 通过完全声明的方式进行操作。
- 使用提供了扩展的配置、自定义选项的 IstioOperator API。
- 不需要管理多个 istioctl 的二进制文件。
缺点:
- 在集群内运行高权限的 Controller 会带来安全问题。
使用 istioctl manifest generate 安装
生成 Kubernetes 的配置清单，并通过 kubectl apply --prune 应用到集群中。该方法适用于需要严格审查或者增加配置清单的情况。
优点:
- Chart 是由与 istioctl install 和 Operator 里使用的相同的 IstioOperator API 生成的。
- 使用提供了扩展的配置、自定义选项的 IstioOperator API。
缺点:
- 一些在 istioctl install 和 Operator 中会进行的检查将不会执行。
- 与 istioctl install 相比，UX 的精简程度较低。
- 错误报告没有 istioctl install 的错误报告详细、全面。
使用 Helm (alpha) 安装
使用 Helm 的 Chart 可以通过 Helm 的工作流程轻松的完成，并在升级的过程中自动清理资源。
优点:
- 使用熟悉、常用的行业标准工具。
- Helm 原生的版本、升级管理。
缺点:
- 相比于 istioctl install 和 Operator 相比，检查较少。
- 一些高权限任务需要更多步骤，并且具有更高的复杂性。
Istio Operator
不建议在新安装时使用 Operator。虽然 Operator 将继续得到支持，新特性请求将不会被优先化。
Istio 操作符提供了一个安装路径，而不需要 istioctl 二进制文件。这可以用于简化升级工作流，其中不需要考虑集群内特权控制器的运行。此方法适用于不需要严格审计或增加输出清单的情况。
优点:
- 与 istioctl install 相同的 API，但驱动是通过集群中的一个带有完全声明式操作的控制器。
- IstioOperator API 提供了广泛的配置/定制选项。
- 不需要管理多个 istioctl 二进制文件。
缺点:
- 集群中运行的高权限控制器存在安全风险。

这些安装方式的安装向导在 Istio 安装页中。

Kubernetes - 我该如何调试 sidecar 自动注入的问题？

为了支持 sidecar 自动注入，请确保你的集群符合此前提条件。如果你的微服务是部署在 kube-system、kube-public 或者 istio-system 这些命名空间，那么就会被免除 sidecar 自动注入。请使用其他命名空间替代。

安全

在 Istio 安装完成之后，我应该如何开启/关闭双向 TLS？

您可以随时使用认证策略和目标规则来为您的服务设置双向 TLS 认证。请参阅任务以获取更多细节。

在同一集群中，我可以为部分服务开启 TLS 双向认证，并为其它服务关闭 TLS 双向认证吗？

认证策略可以配置为 mesh-wide（影响网络中的所有服务）、namespace-wide（namespace 中的所有服务）或某个特定服务。您可以根据需要对集群中的服务配置一种或多种 TLS 双向认证策略。

如何验证流量是否使用双向 TLS 加密？

如果您使用 values.global.proxy.privileged=true 安装 Istio，您可以使用 tcpdump 来确定加密状态。有关说明，请参见 Istio 双向 TLS 迁移。

如果全局启用 TLS 双向认证，那么非 Istio 服务还可以访问 Istio 服务吗？

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

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

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

如何让 Istio 服务访问非 Istio 服务？

Istio 会检测目标工作负载是否具有 Envoy 代理，如果没有则丢弃双向 TLS。设置明确的目标规则可以禁用双向 TLS。例如：

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: "api-server"
spec:
 host: "kubernetes.default.svc.cluster.local"
 trafficPolicy:
   tls:
     mode: DISABLE
EOF

当启用双向 TLS 认证时应该如何使用 Kubernetes liveness 和 readiness 对服务进行健康检查？

如果启用了双向 TLS 认证，则来自 kubelet 的 HTTP 和 TCP 健康检查将不能正常工作，因为 kubelet 没有 Istio 颁发的证书。

有几种选择：

使用 probe rewrite 将 liveness 和 readiness 的请求直接重定向到工作负载。有关更多信息，请参阅 Probe Rewrite。
使用单独的端口进行健康检查，并且仅在常规服务端口上启用双向 TLS。有关更多信息，请参阅 Istio 服务的运行状况检查。
如果对 Istio 服务使用 PERMISSIVE 模式，那么他们可以接受 HTTP 和双向 TLS 流量。请记住，由于其他人可以通过 HTTP 流量与该服务进行通信，因此不强制执行双向 TLS。

如何配置 Istio 证书的生命期？

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

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

proxyMetadata:
  SECRET_TTL: 48h

MySQL 连接故障排除

安装 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 是否支持授权？

支持。Istio 对网格中的 HTTP 服务和普通 TCP 服务提供授权特性支持了解更多。

Istio 中如何配置 Ingress 使其仅处理 TLS 连接？

依照安全入口流量任务中的描述进行配置，可以确保 Istio Ingress 只处理 TLS 连接。

我可以为 HTTPS 服务安装 Istio sidecar 吗？

可以，并且启用或禁用双向 TLS 都可以。

应用

我可以在 Istio mesh 中运行 Casandra 吗？

默认情况下，Cassandra 广播用于绑定（接受连接）到其他 Cassandra 节点的地址作为其地址。这通常是 Pod IP 地址，无需服务网格即可正常工作。但是，对于服务网格，此配置不起作用。Istio 需要（0.0.0.0）作为绑定地址。

有两个配置参数要注意： listen_address 和 broadcast_address 。为了在 Istio 网格中运行 Cassandra，应该将 listen_address 参数设置为 0.0.0.0，将 broadcast_address 参数设置为 Pod IP 地址。

这些配置参数在 Cassandra 配置目录（例如 /etc/cassandra）的 cassandra.yaml 中定义。有多种用于启动 Cassandra 的脚本（和 yaml 文件），应注意这些脚本如何设置这些参数。例如，一些用于配置和启动 Cassandra 的脚本使用环境变量 CASSANDRA_LISTEN_ADDRESS 的值来设置 listen_address。

我可以在 Istio 内部运行 Zookeeper 吗?

默认情况下，Zookeeper 通过监听 pod 的 IP 地址用来在服务间通信。而 Istio 和其他的服务网格需要监听在 0.0.0.0 地址上。

有一个配置参数可以来修改这个默认行为： quorumListenOnAllIPs。这个选项可以让 Zookeeper 监听所有地址。通过下面的命令将 Zookeeper 中的 $ZK_CONFIG_FILE 参数设置为 true。

$ echo "quorumListenOnAllIPs=true" >> $ZK_CONFIG_FILE

我可以在 Istio 网格内运行 Apache NiFi 吗？

在 Istio 上运行 Apache NiFi 是有一些挑战的。这些挑战来自集群运行的需求。例如，要求群集组件必须在整个群集范围内都可以唯一寻址的主机名。该要求与 Istio 的要求（即工作负载在容器组中绑定并侦听“0.0.0.0”）相冲突。

根据您 NiFi 配置和部署情况，有不同的方法来绕开这些问题。在 NiFi 中，至少有以下三种方法来指定群集网络应使用的主机名：

nifi.remote.input.host- 将提供给客户端以连接到该NiFi实例进行站点到站点通信的主机名。默认情况下使用 InetAddress.getLocalHost().getHostName() 来获取本机的主机名。在类似 UNIX 的操作系统上，这通常是来自 hostname 命令。
nifi.web.https.host-HTTPS主机。默认情况下为空白。jetty 服务器将在该主机名上运行，并且需要在整个群集中可寻址，以便与其他节点进行复制。
nifi.cluster.node.address- 节点的标准地址。默认情况下为空白。这也用于集群协调，并且需要在集群内唯一地寻址。

一些注意事项：

由于对上述唯一寻址的联网要求, 对 nifi.web.https.host 使用空白或 localhost 的设置在这种情况下将不起作用。
除非您对所有在 NiFi 部署中具有所有访问角色的用户都表示满意，否则 HTTP 并不是可行的解决方案，因为 NiFi 不会通过 HTTP 执行用户身份验证。
明确指定 NiFi 应该使用的网络接口可以帮助解决问题并允许NiFi工作：修改 nifi.properties，其中 xxx 是与工作IP对应的网络接口（因环境/云提供商而异），yyy 是容器/容器组的环回接口（即 lo ）：

nifi.web.https.network.interface.default = xxx
nifi.web.https.network.interface.lo = yyy

真实示例（适用于 IBM Cloud，也许适用于其他示例）如下所示：

nifi.web.https.network.interface.default = eth0
nifi.web.https.network.interface.lo = lo

我可以在 Istio 网格内运行 Redis 吗？

与在 Istio 服务网格中部署的其他服务类似，Redis 实例需要监听 0.0.0.0。每个 Redis 从属实例都应声明一个地址，主服务器可以使用该地址来访问它，但是，该地址不能是 0.0.0.0。

使用 Redis 配置参数 replica-announce-ip 来公布正确的地址。例如，使用以下步骤将 replica-announce-ip 设置为每个 Redis 从属实例的 IP 地址：

通过从属 StatefulSet 的 env 小节中定义的环境变量传递 Pod IP 地址：

- name: "POD_IP"
  valueFrom:
    fieldRef:
      fieldPath: status.podIP

另外，在 command 小节下添加以下内容：

echo "" >> /opt/bitnami/redis/etc/replica.conf
echo "replica-announce-ip $POD_IP" >> /opt/bitnami/redis/etc/replica.conf

我可以在 Istio 网格中运行 Elasticsearch 吗?

在 Istio 中运行 Elasticsearch，有两个 Elasticsearch 配置参数需要被正确设置：network.bind_host 和 network.publish_host。默认情况下，这些参数值被设置成 network.host 参数。如果 network.host 被设置成 0.0.0.0，Elasticsearch 很可能选择 pod IP 作为发布地址并且不需要更进一步的配置。

如果默认配置没有生效，你可以将 network.bind_host 设置为 0.0.0.0 并将 network.publish_host 设置为 pod IP，例如：

...
containers:
- name: elasticsearch
  image: docker.elastic.co/elasticsearch/elasticsearch:7.2.0
  env:
    - name: network.bind_host
      value: 127.0.0.1
    - name: network.publish_host
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
   ...

了解更多信息请查看 Elasticsearch 网络设置。

度量和日志

可以通过 REST 接口访问 Istio 指标吗？

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

如何控制 sidecar 上报数据？

有时会对访问的特定 URL 排除在上报之外，这样做是有用的。例如，你可能希望把健康检测的 URL 剔除。可以配置使用 match 语法来跳过匹配到的 URL 上报，比如：

match: source.name != "health"

如何管理短期指标？

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

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

如何迁移现有的 Mixer 功能？

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

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

Prometheus 和 Stackdriver 集成是作为代理扩展实现的。这两个扩展生成的 Telemetry 的定制可以通过请求分类和 Prometheus 指标定制来实现。
Global 和 Local Rate-Limiting (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月之后的支持窗口之外的。

Prometheus 适配器能在非 Kubernetes 环境下使用吗？

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

怎样查看 Istio 的请求都发生了什么？

您可以启用 tracing 以确定 Istio 中的请求是怎样流动的。

另外，您还可以使用如下命令以了解网格中的更多状态信息：

istioctl proxy-config：获取 Kubernetes 运行期间的 proxy 配置信息：

# 在指定的 pod 中 Envoy 实例的启动（bootstrap）配置信息。
$ istioctl proxy-config bootstrap productpage-v1-bb8d5cbc7-k7qbm

# 在指定的 pod 中 Envoy 实例的集群（cluster）配置信息。
$ istioctl proxy-config cluster productpage-v1-bb8d5cbc7-k7qbm

# 在指定的 pod 中 Envoy 实例的监听器（listener）配置信息。
$ istioctl proxy-config listener productpage-v1-bb8d5cbc7-k7qbm

# 在指定的 pod 中 Envoy 实例的路由（route）配置信息。
$ istioctl proxy-config route productpage-v1-bb8d5cbc7-k7qbm

# 在指定的 pod 中 Envoy 实例的端点（endpoint）配置信息。
$ istioctl proxy-config endpoints productpage-v1-bb8d5cbc7-k7qbm

# 查看更多 proxy-config 的用法可用如下命令
$ istioctl proxy-config --help

kubectl get：通过路由配置获取网格中不同资源的信息：
```
# 列出所有的 virtual services
$ kubectl get virtualservices
```

我可以使用 Prometheus 配合 Istio 抓取应用程序指标吗？

是的。Istio 附带 Prometheus 的配置，在启用或禁用双向 TLS 时启动收集应用程序指标的功能。

kubernetes-pods job 从没有双向 TLS 环境中的 pod 收集应用程序指标。当为 Istio 启用双向 TLS 时，kubernetes-pods-istio-secure job 从应用程序的 pod 中收集指标。

这两个 job 都要求将以下注释添加到需要从中收集应用程序指标的所有 deployment 中：

prometheus.io/scrape: "true"
prometheus.io/path: "<metrics path>"
prometheus.io/port: "<metrics port>"

一些注意事项：

如果 Prometheus pod 在 Istio Citadel pod 生成所需证书并将其分发给 Prometheus 之前启动，则 Prometheus pod 需要重启以便收集双向 TLS 保护的目标信息。
如果您的应用程序在专用端口上公开了 Prometheus 指标，则应将该端口添加到 service 和 deployment 规范中。

分布式追踪

如何使用 Istio 实现分布式追踪？

Istio 使用 Envoy的分布式追踪系统集成。由应用程序负责为后续传出请求转发追踪的 header 信息。

您可以在 Istio 分布式追踪（Jaeger, LightStep, Zipkin）任务以及 Envoy 追踪文档中找到更多信息。

使用 Istio 进行分布式追踪需要什么？

Istio 允许报告服务网格中工作负载到工作负载间通信的追踪 span。然而，为了将各种追踪 span 整合在一起以获得完整的流量图，应用程序必须在传入和传出请求之间传播追踪上下文信息。

特别是，Istio 依赖于应用程序传播 B3 追踪 headers 以及由 Envoy 生成的请求 ID。这些 header 包括:

x-request-id
x-b3-traceid
x-b3-spanId
x-b3-parentspanid
x-b3-sampled
x-b3-flags
b3

如果使用 LightStep，您还需要转发以下 header：

x-ot-span-context

Header 传播可以通过客户端库完成，例如 Zipkin 或 Jaeger。当然，这也可以手动完成，正如分布式追踪任务中所描述的那样。

基于 Envoy 的跟踪如何工作？

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

Envoy：

在请求代理时为请求生成请求 ID 和跟踪标头（例如 X-B3-TraceId）
根据请求和响应元数据（即响应时间）为每个请求生成跟踪范围
将生成的跟踪范围发送到跟踪后端
将跟踪头转发到代理的应用程序

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

基于 Mixer 的跟踪是如何工作的？

对于基于 Mixer 的跟踪集成，Mixer （通过 istio-telemetry 服务解决）提供了后端跟踪的集成。Mixer 集成允许操作员对分布式跟踪进行更高级别的控制，包括对跟踪范围中包含的数据进行细粒度选择。它还提供将跟踪发送给 Envoy 不直接支持的后端。

对于基于 Mixer 的集成，Envoy：

在请求流经代理时为请求生成 ID 和跟踪报头（例如，X-B3-TraceId）
调用 Mixer 进行常规异步遥测报告
将跟踪报头转发到代理的应用程序

Mixer：

基于 operator-supplied 配置为每个请求生成跟踪的范围
将生成的跟踪范围发送到 operator-designated 跟踪后端

使用 Istio 的 Stackdriver 跟踪集成是通过 Mixer 进行跟踪集成的一个示例。

分布式追踪所需的 Istio 最低配置是什么？

启用了追踪功能的 Istio 最低配置文件是 Istio 与 Zipkin 兼容后端集成所需的全部内容。

为什么要初始化生成 Zipkin (B3) HTTP header?

如果请求中没有 Zipkin (B3) HTTP header，Istio sidecar 代理(Envoy) 会自动生成初始化的 headers。

为什么 Istio 不能代替应用程序传播标头？

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

为什么我的请求没有被追踪？

从 Istio 1.0.3 开始，其 default 追踪采样率已经降低到 1%。配置文件。这意味着 Istio 捕获的 100 个追踪实例中只有 1 个将被报告给追踪后端。 demo 文件中的采样率仍设为 100%。有关如何设置采样率的更多信息，可参见本节。

如果您仍然没有看到任何追踪数据，请确认您的端口是否符合 Istio 端口命名规范，并公开适当的容器端口（例如，通过 pod spec）来启用 sidecar 代理（Envoy）能够对流量进行捕获。

如果您仅看到与出口代理相关联的跟踪数据，但没有看到与入口代理相关联的，那么它可能仍与 Istio 端口命名规范相关。请先了解 Istio 1.3 中自动检测出口流量的协议相关部分。

如何控制追踪数量？

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

如何禁用追踪？

如果您已经安装了启用追踪功能的 Istio，可以通过执行如下步骤禁用它：

# 用您的 Istio mesh 命名空间名填充下述命令中的 <istio namespace>。例如：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>
# 现在，手动从文件中移除 trace_zipkin_url 的实例，保存文件

然后遵循分布式追踪任务的清理部分的步骤进行后续操作。

如果您不想要追踪功能，那么就在安装 Istio 时禁用追踪。

Istio 是否能发送追踪信息到外部与 Zipkin 兼容的后端？

可以这么做，但是必须用 Zipkin 兼容实例的完全合格的域名。比如：zipkin.mynamespace.svc.cluster.local。

Istio 支持请求跟踪 vert.x 事件总线消息吗？

目前 Istio 不提供对发布/订阅和事件总线协议的支持。这些技术都遵循 best-effort 网络模型，网络传输容易遭到破坏。

Mixer 在 Istio 跟踪踪故事中扮演的什么角色？

默认情况下，Mixer 通过为 Envoy 代理已经选择的要跟踪请求生成自己的跨度来参与跟踪。这使操作员可以观察到网格中基于 Mixer 策略的执行机制的参与。如果在网格范围内禁用 istio-策略 配置，则 Mixer 不会以这种方式参与跟踪。

Mixer 作为 istio-telemetry 服务，也可用于生成数据平面流量的跟踪范围。Mixer 的 Stackdriver 适配器就是支持此功能的一个示例。

对于由 Mixer 生成的跟踪，Istio 仍然依靠 Envoy 生成跟踪上下文并将其转发到必须传播上下文的应用程序中。Envoy 它自己没有直接地发送追踪信息到追踪后端，而是 Mixer 根据操作员提供的配置从常规的 Envoy 报告中提取客户端和服务器范围。用这种方式，操作员可以精确地控制何时以及如何生成跟踪数据，并可以从跟踪中完全删除某些服务，或者为某些命名空间提供更详细的信息。

为什么在我的一些分布式追踪中会有 `istio-mixer` span？

Mixer 为到达 Mixer 并且带有追踪头的请求生成了应用级别的追踪。Mixer 为它做的任何关键工作都生成 span 并且打上了 istio-mixer 标签，包括分发到各个适配器。

在数据路径上 Envoy 缓存了到 Mixer 的调用。因此，通过 istio-policy 服务向 Mixer 发起的调用只是在一些特定的请求中会有，例如：缓存过期或者不一样的请求特性。由于这个原因，你会看到 Mixer 只参与了一些追踪。

要关闭 Mixer 的应用级别追踪 span，你必须编辑 istio-policy 的 deployment 配置，并且在命令行参数中删除 --trace_zipkin_url 参数。

流量管理

怎样查看在 Istio 中已配置的当前路由规则？

可以使用这个命令查看 kubectl get virtualservice -o yaml

Sidecar 代理在哪些端口上截获入站流量？

Istio 默认截获所有端口的入站流量。您可以通过 traffic.sidecar.istio.io/includeInboundPorts 这个 pod 注解指定一组端口来截获流量，或通过 traffic.sidecar.istio.io/excludeOutboundPorts 指定一组端口来放行流量，以更改这种默认行为。

MUTUAL 和 ISTIO_MUTUAL TLS 模式有什么区别?

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

Istio 可以与 StatefulSets 和 Headless Service 一起使用吗？

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

为什么我的 CORS 配置不起作用？

当应用了 CORS 配置后，您可能会发现看似什么也没发生，并想知道哪里出了问题。 CORS 是一个经常被误解的 HTTP 概念，在配置时经常会导致混淆。

要弄明白这个问题，有必要退后一步，看看 CORS 是什么，以及何时应该使用它。默认情况下，浏览器对脚本发起的 “cross origin” 请求有限制。例如，这可以防止网站 attack.example.com 向 bank.example.com 发出 JavaScript 请求，从而窃取用户的敏感信息。

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

apiVersion: networking.istio.io/v1beta1
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-* 头；如果响应不令人满意，则由客户端（浏览器）来拒绝请求。在浏览器中，这是通过预检请求来完成的。

我可以不配置任何路由规则，使用 Ingress 的标准配置吗？

简单的 Ingress 规范，提供了开箱即用，通过 Host,TLS 以及基本 Path 精确匹配就可以使用，无需配置路由规则。然而，Path 在使用 Ingress 资源时不应该有任何 . 字符。

比如，下面 Ingress 的资源匹配 Host 为 example.com 以及 URL 为 /helloworld 的请求。

$ kubectl create -f - <<EOF
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: simple-ingress
annotations:
  kubernetes.io/ingress.class: istio
spec:
rules:
- host: example.com
  http:
    paths:
    - path: /helloworld
      backend:
        serviceName: myservice
        servicePort: grpc
EOF

然而，这下面的规则将不工作，因为他们在 Path 中使用了匹配表达式，并且添加了 ingress.kubernetes.io 注解。

$ kubectl create -f - <<EOF
apiVersion: extensions/v1beta1
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/
      backend:
        serviceName: myservice
        servicePort: grpc
EOF

Istio 支持哪些协议？

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

对于所有协议列表以及协议配置信息，请查看文档协议选择。