使用额外的 Istio Ingress 网关增强 Kubernetes 流量路由

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

1. 引言

Istio 是一个强大的服务网格，可为 Kubernetes 工作负载提供高级流量管理、安全性和可观测性。默认情况下，Istio 部署单个Ingress Gateway来处理外部流量。但是，在某些情况下（例如流量分段、多租户或性能提升），您可能需要额外的 Ingress Gateway来更高效地路由流量。

本博客探讨了设置额外的 Istio Ingress 网关的原因和方法，并提供了实际操作步骤、最佳实践和关键配置。

为什么要使用额外的入口网关？

使用额外的 Istio Ingress 网关具有以下几个优点：

流量隔离：根据工作负载的特定需求路由流量（例如，API 流量与 UI 流量或事务性应用程序与非事务性应用程序）。
多租户：不同的团队可以拥有自己的网关，同时仍然可以使用共享的服务网格。
可扩展性：将流量分配到多个网关，以高效处理更高的负载。
安全与合规：对特定的网关实例应用不同的安全策略。
灵活性：您可以根据项目或应用程序的需要创建任意数量的附加入口网关。
最佳实践： Kubernetes 团队经常使用HorizontalPodAutoscaler (HPA)、PodDisruptionBudget (PDB)、Services、Gateway 和基于区域的过滤（通过 Envoy Filters）来增强可靠性和性能。

2. 理解 Istio 架构

Istio IngressGateway 和 Sidecar Proxy：确保安全流量

在 Istio 服务网格中，每个 pod 都需要一个 Istio-Proxy (Envoy) sidecar来处理流量。

如果没有边车代理，应用程序就无法进行内部通信或与外部资源通信。
Istio IngressGateway管理外部流量入口，但依靠sidecar 代理来强制执行安全和路由策略。
这实现了跨微服务的零信任网络、可观测性和弹性。

流量如何流经边车代理

所有流量——无论是来自外部客户端还是在服务之间——都通过Envoy sidecar。
Sidecar 可以实现交通控制、负载均衡、安全执行和监控。
该架构确保服务之间安全、可观察且策略驱动的通信。

Istio架构的关键组件

入口网关：处理外部流量，根据策略路由请求。
Sidecar Proxy：确保所有服务之间的通信都遵循 Istio 管理的规则。
控制平面：管理流量控制、安全策略和服务发现。

通过利用这些组件，组织可以配置多个 Istio 入口网关，以增强跨多云环境的流量分段、安全性和性能。

下图说明了 Istio网关资源、 主入口网关、附加入口网关、服务网格和控制平面如何交互以管理 Kubernetes 流量。

该图展示了如何：

来自外部客户端的流量通过云负载均衡器路由到Istio 网关资源。
入口网关处理流量并将其转发到相应的服务网格组件。
Istio控制平面管理整个网状网络中的流量策略、安全强制执行和服务发现。

3. Istio 单入口网关或多入口网关中的流量流

部署多个入口网关后，流量会根据应用程序类型（用户界面、API 或事务服务）流经不同的网关。流程如下：

外部客户端的请求首先到达云负载均衡器，然后负载均衡器将流量转发到 Istio 网关，Istio 网关再将其路由到正确的入口网关。
虚拟服务定义了哪个后端服务应该处理请求。
Envoy代理（边车）确保流量遵循定义的策略。
流量到达了正确的后端服务。

4. 对比：单入口网关与多入口网关

在单入口网关架构中，所有流量都通过单个网关路由，这可能会造成瓶颈和安全隐患。另一方面，多入口网关架构可以更好地对 API、UI 和基于事务的工作负载进行流量分段，通过隔离敏感流量来增强安全性，并实现可扩展性和高可用性，确保每种类型的请求都能得到最佳处理。

下图比较了单个 Istio Ingress 网关与多个 Ingress 网关在处理 API 和 Web 流量方面的差异。

对比分析的主要结论：

单个Istio 入口网关将所有流量路由到单个入口点，这可能会成为瓶颈。
多个入口网关可以更好地进行流量分段，分别处理 API 流量和 UI 流量。
可以针对每个网关定义安全策略和扩展策略，使其成为多云或多区域部署的理想选择。

5. 设置额外的入口网关

额外的入口网关如何改善流量路由

下图展示了多个 Istio Ingress 网关如何高效地管理 API、UI 和事务流量。

工作原理

云负载均衡器将流量转发到 Istio 网关资源，由该资源确定路由规则。

流量被定向到不同的入口网关

主入口网关处理用户界面流量

API入口网关处理API请求

交易入口网关确保金融交易和支付得到安全处理。

服务网格负责执行安全性、流量策略和可观测性。

步骤 1：安装 Istio 并配置 Operator

先决条件

已安装 Istio 的 Kubernetes 集群
已安装 Helm 以部署 Istio 组件

请确保您已安装 Istio。如果尚未安装，请使用以下命令进行安装：

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=$(istio_version) TARGET_ARCH=x86_64 sh -

export PATH="$HOME/istio-$ISTIO_VERSION/bin:$PATH"

初始化 Istio Operator：

istioctl operator init

验证安装情况：

kubectl get crd | grep istio

另一种安装方式是使用 Helm。

为了提高灵活性和可重用性，可以使用 Helm Charts 来管理 Istio 入口网关配置。这使得团队能够定义可自定义的 values.yaml 文件并动态部署网关。

helm upgrade --install istio-ingress istio/gateway -f values.yaml

这样可以实现动态配置管理，从而更容易管理多个入口网关。

步骤 2：使用 IstioOperator 配置其他入口网关

创建 Istio Operator 配置文件（additional-ingressgateway.yaml）以根据需要定义新的网关。以下示例配置展示了如何为不同类型的流量创建多个额外的入口网关。

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: additional-ingressgateways
  namespace: istio-system
spec:
  components:
    ingressGateways:
    - name: istio-ingressgateway-ui
      enabled: true
      k8s:
        service:
          type: LoadBalancer
    - name: istio-ingressgateway-api
      enabled: true
      k8s:
        service:
          type: LoadBalancer

步骤 3：Helm 的其他配置示例

以下是增强入口网关设置的关键 Kubernetes 对象的示例配置：

水平舱自动扩缩器 (HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ingressgateway-hpa
  namespace: istio-system
spec:
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: istio-ingressgateway

Pod 中断预算 (PDB)

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: ingressgateway-pdb
  namespace: istio-system
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: istio-ingressgateway

基于区域的使者过滤器

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: region-header-filter
  namespace: istio-system
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.http_connection_manager
            subFilter:
              name: envoy.filters.http.router
      proxy:
        proxyVersion: ^1\.18.*
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.lua
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
          inlineCode: |
            function envoy_on_response(response_handle)
              response_handle:headers():add("X-Region", "us-eus");
            end

步骤 4：部署其他入口网关

使用 istioctl 应用配置：
istioctl install -f additional-ingressgateway.yaml

确认新的入口网关正在运行：
kubectl get pods -n istio-system | grep ingressgateway

步骤 5：为每个入口定义网关资源

每个入口网关都应该有一个对应的网关资源。以下示例展示了如何为 UI、API、事务性流量和非事务性流量分别定义网关。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-ui-gateway
  namespace: default
spec:
  selector:
    istio: istio-ingressgateway-ui
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "ui.example.com"

对API、事务性和非事务性入口网关重复类似的配置。

步骤 6：使用虚拟服务路由流量

网关配置完成后，创建虚拟服务来控制流向各个服务的流量。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-api-service
  namespace: default
spec:
  hosts:
  - "api.example.com"
  gateways:
  - my-api-gateway
  http:
  - route:
    - destination:
        host: my-api
        port:
          number: 80

对UI 服务、事务性服务和非事务性服务重复类似的配置。

6. 通过额外的入口网关实现弹性与高可用性

在 Kubernetes 环境中部署额外的 IngressGateway可以增强其弹性和容错能力。

如果主入口网关发生故障，其他入口网关可以无缝接管流量。
在执行滚动升级或 Kubernetes 版本升级时，分离入口流量可以降低停机风险。
在多区域或多云 Kubernetes 集群中，额外的入口网关可以更好地控制区域流量并遵守当地法规。

7. 最佳实践与经验教训

许多团队忘记了必须将 Istio sidecar 注入到每个应用程序 pod 中，以确保服务之间的通信。

部署其他入口网关时，请考虑实施以下措施：
水平 Pod 自动扩缩器 (HPA)：根据 CPU 和内存使用情况自动扩缩入口网关。
Pod 中断预算 (PDB)：确保在节点升级或故障期间的高可用性。
基于区域的过滤（Envoy 过滤器）：通过动态设置请求标头中的相应区域来优化流量路由。
专用服务和网关：独立的逻辑实体，以实现更好的安全性和流量隔离。
请确保您的命名空间中已启用自动 Sidecar 注入：kubectl label namespace <您的命名空间> istio-injection=enabled
使用以下命令验证所有 Pod 是否都拥有 sidecar：kubectl get pods -n <你的命名空间> -o wide
如果没有边车，服务将无法通信，导致请求失败和流量中断。
升级其他入口网关时，请考虑以下事项：
升级前备份：

kubectl get all -n istio-system -o yaml > istio-backup.yaml

删除旧的 Istio 配置（如有需要） - 如果您要升级或修改 Istio，请删除过时的配置：

kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector

kubectl get crd --all-namespaces | grep istio | awk '{print $1}' | xargs kubectl delete crd

升级过程中，请确保更新 proxyVersion、部署镜像和服务标签，以避免兼容性问题。
缩减 Istio Operator 规模：升级前，请缩减 Istio Operator 规模以避免中断。

kubectl scale deployment -n istio-operator istio-operator --replicas=0

8. 使用 Grafana 进行监控和可观测性分析

借助 Istio 内置的监控功能，Grafana 控制面板可以按入口类型对流量进行分类：

分别监控 API、UI、事务性流量和非事务性流量。
使用基于 Prometheus 的指标，快速识别生产环境中出现问题时受影响的流量类型。
可以在 Grafana 和 Prometheus 中监控 Istio 网关指标，以跟踪流量模式、延迟和错误。
它提供实时指标，用于故障排除和性能优化。
设置异常情况和高错误率警报。

9. 结论

在 Kubernetes 环境中部署多个 Istio Ingress Gateway 可以显著增强流量控制、可扩展性、安全性和可观测性。通过将流量划分到专用的 Ingress Gateway（例如用于 UI、API、事务性服务和非事务性服务），团队可以实现更高的隔离性、负载均衡和策略执行效率。

这种方法在多云 Kubernetes 环境中尤为重要，例如Azure AKS、Google GKE、Amazon EKS、Red Hat OpenShift、VMware Tanzu Kubernetes Grid、IBM Cloud Kubernetes Service、Oracle OKE 和自管理 Kubernetes 集群，因为在这些环境中，必须仔细管理区域流量路由、故障转移处理和安全合规性。

通过借鉴最佳实践，包括：

用于服务间安全的边车代理
HPA（HorizontalPodAutoscaler）用于自动扩缩容
PDB（PodDisruptionBudget）可用性
Envoy 过滤器用于智能流量路由
基于 Helm 的动态配置部署

企业可以构建高度弹性和高效的 Kubernetes 网络堆栈。

此外，Grafana 和 Prometheus 等监控仪表板能够深入观察入口流量模式、延迟趋势和故障点，从而实现对流量的实时跟踪、快速的根本原因分析和主动的问题解决。

通过 遵循这些原则，组织可以优化其基于 Istio 的服务网格架构，从而确保在分布式云环境中实现高可用性、增强的安全态势和无缝性能。

参考

原文发表于https://dzone.com。

文章来源：https://dev.to/prabhucse/enhancing-kubernetes-traffic-routing-with-an-additional-istio-ingress-gateway-55i5

分享

使用额外的 Istio Ingress 网关增强 Kubernetes 流量路由 DEV 的全球展示挑战赛，由 Mux 呈现：展示你的项目！