入站和出站流量的一般注意事项
首先查看Istio的路由：
![]()
当连connection访问Istio的某个成员时（假设一个入口网关，但它对每个成员都起作用），所有路由选择决定均基于主机名（host header字段）。
Ingress gateways为侦听某些端口上的连接，以及基于网关对象的某些主机名。网关配置会根据标签选择器选择要应用网关的Pod。网关对象应在网关容器所在的相同namespace中定义。
默认情况下，Ingress gateway不知道Istio的服务。为了使入口网关了解网格中的服务，必须定义VirtualService并将其应用于网关对象。当VirtualService与网关对象不在同一个命名空间中时（在大多数情况下是这种情况），应以NamespacedName格式（<namespace> / <gateway>）引用网关对象。
VirtualService可以与DestinationRule结合使用，以进行细粒度的流量管理。
然后，VirtualService将路由到Kubernetes服务的活动成员（自动发现）或ServiceEntry。ServiceEntries提供了手动定义无法自动发现的端点的功能，这些端点可能表示Istio外部的目标（位置：MESH_EXTERNAL）。
设计入口流量
对于入站流量，通常最好的做法是先让流量通过一个或多个入口网关，然后再启动服务。
在设计如何部署服务网格的入口网关时，需要考虑两个主要因素：
需要多少个入口网关？
入口网关和OpenShift路由器之间是什么关系？
在大多数情况下，每个Isito集群有一个入口网关就足够了。
但是，您可能会遇到需要其他网关的情况。场景包括何时需要支持两种截然不同的配置，或者何时需要物理隔离两种流量（此处是此配置的示例）。当您可能有多个入口网关时，另一个实例是入口网关需要由其命名空间中的各个租户拥有。
我们介绍三种入口网关部署模式：
![]()
![]()
![]()
OpenShift ServiceMesh Operator当前不支持最后一个配置设置，并且需要租户手动设置。
另一个需要考虑的点是最外围使用OpenShift router还是LoadBalancer服务公开给Istio的Ingress Gateway，如下图所示：
![]()
![]()
在上图中，我们可以看到两种情况，一种是将OpenShift路由器与入口网关链接在一起，另一种是将入口网关直接暴露出来。
从概念上讲，Router是流量进入OpenShift SDN的入口点，服务网格Ingress Gateway是流量进入网格的入口。
当流量为HTTP或SNI + TLS时，前一种情况更为合适，因为这是路由器支持的流量类型，并且增加的延迟不是问题。可以将服务网格控制平面配置为与要定义的网关对象一致地自动创建路由（ior_enabled：true）。
如果流量是路由器本身不支持的类型，或者具有良好的延迟性能很重要，则后一种情况更合适。在这些情况下，网格管理员需要配置LoadBalancer服务以及正确的DNS记录。DNS记录的创建可以在externalDNS externalDNS的帮助下自动进行（这里是一个示例）。
设计出口流量
对于出口流量，我们必须再次决定我们需要多少个出口网关。在某些情况下，答案可能是零。但是，在大多数情况下，拥有一个出口网关将很有用：
![]()
![]()
来自istio中的Pod的出站流量始终会经过envoy网关，因此即使没有通过envoy gateway，也对该流量进行了一定程度的控制。但是，出口网关可用于实现以下目的：
TLS发起和信任域转换。这允许两个PKI域共存。我们可以使用出口网关来终止来自服务网格内部PKI的TLS连接，并使用来自外部PKI的证书来发起新连接。
使用已知的出口IP。如果网状网中服务的出站连接需要源自已知IP，以便可以应用防火墙规则，则可以选择将所有出站连接转移到出口网关，然后在名称空间中定义出口IP， 网关已定义。
与egressIP用例相似，组织可能有要求，所有出站流量都需要根据这些要求来自一组特定的节点。包含要通过出口网关的流量并确保将出口网关Pod部署到那些节点上，是一种满足该要求的方法。
加强出口流量
可以创建EgressNetworkPolicies来强制实施，除了从部署出口网关的名称空间中，没有流量离开群集。我们还可以使用带有出口规则的网络策略来强制离开网状容器的流量保持在网状结构中（再次，我们需要保证用户无法管理网络策略）。
此外，可以将Istio配置为禁止对网格未知的地址进行路由。通常，如果应用程序尝试打开到网格未知的地址的连接，则Istio将使用DNS来解析该地址并执行请求。通过将global.outboundTrafficPolicy模式选项设置为REGISTRY_ONLY，我们可以将Istio配置为仅允许连接到已知地址（即，为其定义VirtualService的地址）。
为边缘流量配置OAuth身份验证
Istio可以验证OAuth令牌的有效性，作为其最终用户授权策略的一部分。但是，它无法处理不带有OAuth令牌的请求的OIDC身份验证工作流。
Istio假定将在网格外部进行初始身份验证（在其中创建令牌），但是显然两个用例（身份验证流程和令牌验证）密切相关。
实际上，对于许多应用程序，预期的行为是当令牌不可用时，应将用户重定向到身份验证流。
处理此用例的一种方法是在入口网关的前面添加一个能够处理身份验证工作流的OAuth-proxy。如下图所示，该容器甚至可以作为边车部署：
![]()
在实践中可以找到这种情况的示例。
您可以在此服务网格部署中添加更多网关，以防需要处理未经身份验证的流量或使用其他身份验证方法的流量。
通过身份验证工作流程创建令牌后，您可以配置入口网关以对其进行验证。此外，您可以配置网格中的所有服务以重新验证令牌，从而提高安全性。为了使其正常工作，您的服务需要在每个步骤中转发令牌。
为边缘流量配置TLS和mTLS
入口和出口网关对于配置应如何在不同的PKI信任域之间处理TLS连接很有用。Istio默认情况下使用内部信任域来管理自己的PKI，并且可以安全地假定网状网络之外还有其他信任域。
下图是捕获这种情况的图：
![]()
在上图中，我们可以看到使用服务网格中服务的应用程序位于信任域A中。在这种情况下，已经在消费者和入口网关之间配置了mTLS 。然后，应用程序对属于信任域B的外部服务进行出站呼叫。mTLS通过在出口网关上部署正确的证书进行配置（这是此部分的说明）。
通过在网关级别管理证书，我们实现了以下目标：
简化配置：没有一种将附加证书部署到Sidecar的简便方法，但是将证书材料添加到网关相对容易。
集中配置：网格中的所有服务都可以重用证书配置。
当然，我们可以通过部署CA捆绑包而不是客户端证书来建立常规的TLS部署，此决定不会影响服务网格租户。
如果有一种自动配置证书的机制，则可以大大简化这些类型的设置。Cert-manager Operator是该领域的理想选择。
配置边缘流量的速率限制
在某些情况下，可能有必要对来自网格的出站流量进行速率限制。当上游服务可能已基于定价层施加了限制或传统系统在一段时间内只能处理一定数量的请求或并发连接时，这些类型的流量控制很有用。
此外，不同的SLA可能适用于源自不同来源的流量，并且需要以不同的方式对这些流量类型进行速率限制。
可以将目的地规则和流量策略与断路器配合使用，以管理在从网格中传播时如何区分不同SLA的入站请求的优先级。
![]()
在上图中，我们演示了如何将分配了不同SLA类的两种不同入站请求（一种可以分配报头的方式）用于应用不同的目的地规则和相应的流量策略（此处为示例）。这些方法可用于维护健康的上游系统，并允许网格中的服务在达到极限时继续运行或应用断路器模式。
关于联邦Istio
有时候大家有将多个K8S集群上的istio统一管理与通讯的需求。
社区目前已经有方案：
https://istio.io/latest/docs/setup/install/multicluster/gateways/
![]()
