FAQ

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

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

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

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

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

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

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

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

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

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

Istio 使用了 Apache License 2.0。

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

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

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

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

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

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

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

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

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

它是希腊语中的 “sail”。

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

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

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

1. 使用 istioctl 安装

   具有高安全性的简单、合格的安装和管理方法。这是社区推荐的安装方法。

   优点:

   • 完整的配置和运行状态的验证。
   • 使用提供了扩展的配置、自定义选项的 IstioOperator API。
   • 不需要集群内的高权限 Pod 。通过执行 istioctl 命令修改。

   缺点:

   • 需要维护多个 Istio minor 版本的二进制文件。
   • istioctl 命令可能根据您的运行环境设置诸如 JWT_POLICY 之类的值，从而能够在不同的 Kubernetes 环境中进行不同的安装。

2. 使用 Istio Operator 安装

   没有 istioctl 二进制文件的简单安安装方式。这是推荐的方法。用于简单升级工作，无需考虑运行集群内的高权限 Controller。

   优点:

   • 具有与 istioctl install 相同的 API ，但是通过据群众具有高权限的 Controller Pod 通过完全声明的方式进行操作。
   • 使用提供了扩展的配置、自定义选项的 IstioOperator API。
   • 不需要管理多个 istioctl 的二进制文件。

   缺点:

   • 在集群内运行高权限的 Controller 会带来安全问题。

3. 使用 istioctl manifest generate 安装

   生成 Kubernetes 的配置清单，并通过 kubectl apply --prune 应用到集群中。该方法适用于需要严格审查或者增加配置清单的情况。

   优点:

   • Chart 是由与 istioctl install 和 Operator 里使用的相同的 IstioOperator API 生成的。
   • 使用提供了扩展的配置、自定义选项的 IstioOperator API。

   缺点:

   • 一些在 istioctl install 和 Operator 中会进行的检查将不会执行。
   • 与 istioctl install 相比，UX 的精简程度较低。
   • 错误报告没有 istioctl install 的错误报告详细、全面。

4. 使用 Helm (alpha) 安装

   使用 Helm 的 Chart 可以通过 Helm 的工作流程轻松的完成，并在升级的过程中自动清理资源。

   优点:

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

   缺点:

   • 相比于 istioctl install 和 Operator 相比，检查较少。
   • 一些高权限任务需要更多步骤，并且具有更高的复杂性。

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

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

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

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

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

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

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

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

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 认证，则来自 kubelet 的 HTTP 和 TCP 健康检查将不能正常工作，因为 kubelet 没有 Istio 颁发的证书。

有几种选择：

1. 使用 probe rewrite 将 liveness 和 readiness 的请求直接重定向到工作负载。有关更多信息，请参阅 Probe Rewrite。

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

3. 如果对 Istio 服务使用 PERMISSIVE 模式，那么他们可以接受 HTTP 和双向 TLS 流量。请记住，由于其他人可以通过 HTTP 流量与该服务进行通信，因此不强制执行双向 TLS。

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

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

proxyMetadata:
  SECRET_TTL: 48h

安装 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 都可以。

默认情况下，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。

默认情况下，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 的要求（即工作负载在容器组中绑定并侦听“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 实例需要监听 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，有两个 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 网络设置 。

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

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

match: source.name != "health"

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

您可以启用 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
  

是的。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 使用 Envoy的分布式追踪系统集成。由应用程序负责为后续传出请求转发追踪的 header 信息。

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

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（Sidecar 代理）代表所代理的应用程序将跟踪信息直接发送到跟踪后端。

Envoy：

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

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

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

对于基于 Mixer 的集成，Envoy：

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

Mixer：

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

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

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

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

尽管 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 时禁用追踪。

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

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

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

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

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

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

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

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

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

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

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

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

当应用了 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 规范，提供了开箱即用，通过 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 支持基于 TCP 的协议。此外，Istio 还为其他协议（如 http 和 mysql）提供路由和指标等功能。

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