第十七部分 Istio控制 Egress 流量

本文介绍如何在Istio服务Mesh中配置ServiceEntry,使集群内的服务能够访问外部HTTP和HTTPS服务,并通过示例展示如何设置超时规则。

简述

默认情况下,Istio服务Mesh中的Pod,由于其 iptables 将所有外发流量都透明的转发给了 Sidecar,所以这些集群内的服务无法访问集群之外的 URL,而只能处理集群内部的目标。本文主要介绍如何让Istio 集群中的服务访问外部的服务,即如何通过定义 ServiceEntry 来调用外部服务简单的对 Istio 进行配置,或要求其直接放行对特定 IP 范围的访问。

前提

  • 正确安装Istio
  • 安装实例程序sleep
  • 手动或自动注入sidecar
kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)

YAML具体内容如下:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: sleep
    spec:
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: pstauffer/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent

 

  • 将 SOURCE_POD 环境变量设置为已部署的 sleep pod:
export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})

在 Istio 中配置外部服务

通过配置 Istio ServiceEntry,可以从 Istio 集群中访问任何可公开外部的服务。 这里我们会使用 httpbin.org 以及 www.google.com 进行试验。

  • 配置外部服务

1.创建一个 ServiceEntry 对象,放行对一个外部 HTTP 服务的访问:

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: httpbin-ext
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS
  location: MESH_EXTERNAL
EOF

2.进入具体的服务Pod:

kubectl exec -it $SOURCE_POD -c sleep sh

3.向外部 HTTP 服务发出请求。

curl http://httpbin.org/headers
  • 配置外部 HTTPS 服务

1.创建一个 ServiceEntry 以允许访问外部 HTTPS 服务。

对于 TLS 协议(包括 HTTPS),除了 ServiceEntry 之外,还需要 VirtualService。 没有 VirtualService, ServiceEntry 所暴露的服务将不被定义。VirtualService 必须在 match 子句中包含 tls 规则和 sni_hosts 以启用 SNI 路由。

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: google
spec:
  hosts:
  - www.google.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS
  location: MESH_EXTERNAL
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: google
spec:
  hosts:
  - www.google.com
  tls:
  - match:
    - port: 443
      sni_hosts:
      - www.google.com
    route:
    - destination:
        host: www.google.com
        port:
          number: 443
      weight: 100
EOF

2.执行 sleep service 源 pod:

kubectl exec -it $SOURCE_POD -c sleep sh

3.向外部 HTTPS 服务发出请求:

curl https://www.google.com
  • 为外部服务设置路由规则

通过 ServiceEntry 访问外部服务的流量,和网格内流量类似,都可以进行 Istio 路由规则 的配置。下面我们使用 istioctl 为 httpbin.org 服务设置一个超时规则。在测试 Pod 内部,使用 curl 调用 httpbin.org 这一外部服务的 /delay 端点:

kubectl exec -it $SOURCE_POD -c sleep sh
time curl -o /dev/null -s -w "%{http_code}\n" http://httpbin.org/delay/5
200

real    0m5.024s
user    0m0.003s
sys     0m0.003s

这个请求会在大概五秒钟左右返回一个内容为 200 (OK) 的响应。退出测试 Pod,使用 kubectl  httpbin.org 外部服务的访问设置一个 3 秒钟的超时:

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin-ext
spec:
  hosts:
    - httpbin.org
  http:
  - timeout: 3s
    route:
      - destination:
          host: httpbin.org
        weight: 100
EOF

等待几秒钟之后,再次发起 curl 请求:

kubectl exec -it $SOURCE_POD -c sleep sh
time curl -o /dev/null -s -w "%{http_code}\n" http://httpbin.org/delay/5
504

real    0m3.149s
user    0m0.004s
sys     0m0.004s

这一次会在 3 秒钟之后收到一个内容为 504 (Gateway Timeout) 的响应。虽然 httpbin.org 还在等待他的 5 秒钟,Istio 却在 3 秒钟的时候切断了请求。

直接调用外部服务

如果想要跳过 Istio直接访问某个 IP 范围内的外部服务,就需要对 Envoy sidecar 进行配置,阻止 Envoy 对外部请求的劫持。不推荐此方式,详细了解请自行查阅文档。

总结

控制Egress流量,可以使用两种方式从 Istio 服务Mesh内部来完成对外部服务的调用:

  • 使用 ServiceEntry (推荐方式)
  • 配置 Istio sidecar,从它的重定向 IP 表中排除外部服务的 IP 范围

第一种方式(ServiceEntry)中,Mesh内部的服务不论是访问内部还是外部的服务,都可以使用同样的 Istio 服务Mesh的特性。我们通过为外部服务访问设置超时规则的例子,来证实了这一优势。第二种方式越过了 Istio sidecar proxy,让服务直接访问到对应的外部地址。然而要进行这种配置,需要了解云供应商特定的知识和配置。

 

<think>嗯,用户这次转向了服务网格领域,询问Istio Egress Gateway的功能定位。结合用户提供的四段引用材料,核心需要提炼Egress Gateway在服务网格架构中的不可替代性。 用户引用的材料[1]和[2]已经明确指出了关键点:Egress Gateway本质是服务网格的"边界守卫",专门治理出向流量。这让我想起TiDB里PD作为中央协调器的角色——虽然领域不同,但都是系统中承担特定关键功能的组件。不同的是,Egress Gateway采用代理模式而非PD的集中式管理。 特别注意到引用[3]提到的设计哲学:Gateway将L4-L6配置与L7配置解耦。这种分层设计很像网络协议栈,Egress Gateway相当于在传输层做统一拦截,再通过VirtualService绑定应用层路由规则。用户提供的材料[4]虽然偏重学习资源,但提到的Envoy Proxy正是Egress Gateway的技术底座。 用户可能隐含的深层需求是:为什么不能直接让Pod访问外部服务,非要加一层网关?这需要从三个维度解释:安全方面(集中策略实施点)、运维方面(统一流量观测点)、架构方面(屏蔽基础设施差异)。引用[2]提到的"无公网IP节点访问外部"就是典型场景。 突然意识到用户之前研究过TiDB集群故障影响,或许对高可用设计敏感。Egress Gateway本身支持多副本部署,但需要提醒用户:如果所有Egress Pod同时宕机,会导致外部访问完全中断——这点在架构设计时要考虑冗余。</think>Istio Egress Gateway 是服务网格的关键边界组件,其核心功能与作用可归纳为以下方面: --- ### **一、核心功能** 1. **统一出口流量控制** - 作为**专用出口代理**,强制所有出站流量(如访问外部 API、数据库)必须流经网关,实现集中式管理[^1][^2]。 - 示例配置: ```yaml apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-egressgateway spec: selector: istio: egressgateway servers: - port: number: 443 name: https protocol: HTTPS hosts: - "*.example.com" tls: mode: MUTUAL ``` 2. **安全策略实施** - **TLS 加密**:网关与外部服务间强制 HTTPS 通信,防止中间人攻击[^1]。 - **身份认证**:支持 mTLS 双向认证,确保外部服务合法性[^3]。 3. **流量监控与审计** - 集成 Prometheus 收集流量指标(如请求成功率、延迟)[^4]。 - 通过 Jaeger 实现出口流量的分布式追踪,定位跨域延迟问题。 --- ### **二、架构作用** #### 1. **解决网络限制问题** - **场景**:集群节点无公网 IP 时 - Egress Gateway 作为**唯一有公网 IP 的节点**,代理内部 Pod 访问外部服务[^2]。 - **场景**:合规性要求 - 满足“所有出口流量必须经专用审查节点”的安全规范[^2]。 #### 2. **解耦网络层与应用层** - **传统负载均衡器模式** 网关分离 L4-L6(端口/TLS)与 L7(HTTP 路由)配置[^3]: ```mermaid graph LR A[L4-L6配置] -->|绑定| B(Gateway) C[L7路由规则] -->|绑定| D(VirtualService) B --> E(外部服务) D --> E ``` - **优势**: - 网络运维人员管理 Gateway(基础设施层) - 开发人员管理 VirtualService(应用层)[^3] #### 3. **提升可观测性** - **统一监控出口流量** Kiali 面板可展示所有外部服务的依赖关系与性能指标[^4]: ![Kiali Egress 监控](https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway/kiali-egress-gateway.png) --- ### **三、典型应用场景** | **场景** | **Egress Gateway 作用** | **配置要点** | |--------------------------|--------------------------------------|--------------------------------| | **访问云数据库** | 加密数据库连接 + IP 白名单 | 配置 TLS 终止与 SNI 路由 | | **调用第三方 API** | 限流、重试策略集中管理 | 在 VirtualService 设置超时规则 | | **混合云架构** | 统一管理跨云服务出口点 | 多集群 Gateway 联邦 | | **安全审计合规** | 记录所有出站请求日志 | 启用 AccessLog 并对接 SIEM 系统 | --- ### **四、与 Ingress Gateway 对比** | **特性** | Egress Gateway | Ingress Gateway | |------------------|------------------------------------|----------------------------------| | **流量方向** | 内部 → 外部 | 外部 → 内部 | | **核心目标** | 控制出站安全与可见性 | 管理入站流量路由 | | **典型配置** | `ServiceEntry` + `Gateway` | `Gateway` + `VirtualService` | | **安全重心** | 外部服务认证 + 数据加密 | 用户认证 + DDoS 防护 | > **关键价值总结**:Egress Gateway 通过**集中化出口流量**,实现了服务网格的"零信任安全模型",同时提供网络策略统一管控点,是构建企业级安全网格的必备组件[^1][^4]。 ```mermaid graph TD A[服务网格内 Pod] -->|出站请求| B(Egress Gateway) B -->|加密+审计| C[外部服务] B --> D[Prometheus 监控] B --> E[Jaeger 追踪] B --> F[Kiali 拓扑图] ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值