Kubernetes Gateway API

本文描述 Istio 和 Kubernetes API 之间的差异,并提供了一个简单的例子, 向您演示如何配置 Istio 以使用 Gateway API 在服务网格集群外部暴露服务。 请注意,这些 API 是 Kubernetes ServiceIngress API 的积极发展演进。

许多 Istio 流量管理文档均囊括了 Istio 或 Kubernetes API 的使用说明 (例如请参阅控制入站流量)。 通过参照入门指南, 您甚至从一开始就可以使用 Gateway API。

设置

  1. 在大多数 Kubernetes 集群中,默认情况下不会安装 Gateway API。如果 Gateway API CRD 不存在,请安装:

    1. $ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
    2. { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.0.0" | kubectl apply -f -; }
  2. 使用 minimal 配置安装 Istio:

    1. $ istioctl install --set profile=minimal -y

与 Istio API 的区别

Gateway API 与 Istio API(如 Gateway 和 VirtualService)有很多相似之处。 主资源使用相同的 Gateway 名称,并且这些资源服务于相类似的目标。

新的 Gateway API 致力于从 Kubernetes 的各种 Ingress 实现(包括 Istio)中吸取经验, 以构建标准化的,独立于供应商的 API。 这些 API 通常与 Istio Gateway 和 VirtualService 具有相同的用途,但有一些关键的区别:

  • Istio API 中的 Gateway 仅配置已部署的现有网关 Deployment/Service, 而在 Gateway API 中的 Gateway 资源不仅配置也会部署网关。 有关更多信息,请参阅具体部署方法
  • 在 Istio VirtualService 中,所有协议都在单一的资源中配置,
  • 而在 Gateway API 中,每种协议类型都有自己的资源,例如 HTTPRouteTCPRoute
  • 虽然 Gateway API 提供了大量丰富的路由功能,但它还没有涵盖 Istio 的全部特性。 因此,正在进行的工作是扩展 API 以覆盖这些用例,以及利用 API 的可拓展性 来更好地暴露 Istio 的功能。

配置网关

有关 API 的信息,请参阅 Gateway API 文档。

在本例中,我们将部署一个简单的应用程序,并使用 Gateway 将其暴露到外部。

  1. 首先部署一个 httpbin 测试应用:

    Zip

    1. $ kubectl apply -f @samples/httpbin/httpbin.yaml@
  2. 部署 Gateway API 配置,包括单个暴露的路由(即 /get):

    1. $ kubectl create namespace istio-ingress
    2. $ kubectl apply -f - <<EOF
    3. apiVersion: gateway.networking.k8s.io/v1beta1
    4. kind: Gateway
    5. metadata:
    6. name: gateway
    7. namespace: istio-ingress
    8. spec:
    9. gatewayClassName: istio
    10. listeners:
    11. - name: default
    12. hostname: "*.example.com"
    13. port: 80
    14. protocol: HTTP
    15. allowedRoutes:
    16. namespaces:
    17. from: All
    18. ---
    19. apiVersion: gateway.networking.k8s.io/v1beta1
    20. kind: HTTPRoute
    21. metadata:
    22. name: http
    23. namespace: default
    24. spec:
    25. parentRefs:
    26. - name: gateway
    27. namespace: istio-ingress
    28. hostnames: ["httpbin.example.com"]
    29. rules:
    30. - matches:
    31. - path:
    32. type: PathPrefix
    33. value: /get
    34. backendRefs:
    35. - name: httpbin
    36. port: 8000
    37. EOF
  3. 设置主机 Ingress 环境变量:

    1. $ kubectl wait -n istio-ingress --for=condition=programmed gateways.gateway.networking.k8s.io gateway
    2. $ export INGRESS_HOST=$(kubectl get gateways.gateway.networking.k8s.io gateway -n istio-ingress -ojsonpath='{.status.addresses[0].value}')
  4. 使用 curl 访问 httpbin 服务:

    1. $ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
    2. HTTP/1.1 200 OK
    3. server: istio-envoy
    4. ...

    请注意,使用 -H 标志可以将 Host HTTP 标头设置为 “httpbin.example.com”。这一步是必需的,因为 HTTPRoute 已配置为处理 “httpbin.example.com” 的请求, 但是在测试环境中,该主机没有 DNS 绑定,只是将请求发送到入口 IP。

  5. 访问其他没有被显式暴露的 URL 时,将看到 HTTP 404 错误:

    1. $ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/headers"
    2. HTTP/1.1 404 Not Found
    3. ...
  6. 更新路由规则也会暴露 /headers 并为请求添加标头:

    1. $ kubectl apply -f - <<EOF
    2. apiVersion: gateway.networking.k8s.io/v1beta1
    3. kind: HTTPRoute
    4. metadata:
    5. name: http
    6. namespace: default
    7. spec:
    8. parentRefs:
    9. - name: gateway
    10. namespace: istio-ingress
    11. hostnames: ["httpbin.example.com"]
    12. rules:
    13. - matches:
    14. - path:
    15. type: PathPrefix
    16. value: /get
    17. - path:
    18. type: PathPrefix
    19. value: /headers
    20. filters:
    21. - type: RequestHeaderModifier
    22. requestHeaderModifier:
    23. add:
    24. - name: my-added-header
    25. value: added-value
    26. backendRefs:
    27. - name: httpbin
    28. port: 8000
    29. EOF
  7. 再次访问 /headers,注意到 My-Added-Header 标头已被添加到请求:

    1. $ curl -s -HHost:httpbin.example.com "http://$INGRESS_HOST/headers"
    2. {
    3. "headers": {
    4. "Accept": "*/*",
    5. "Host": "httpbin.example.com",
    6. "My-Added-Header": "added-value",
    7. ...

部署方法

在上面的示例中,在配置网关之前,您不需要安装 Ingress 网关 Deployment。 因为在默认配置中会根据 Gateway 配置自动分发网关 DeploymentService。 但是对于高级别的用例,仍然允许手动部署。

自动部署

默认情况下,每个 Gateway 将自动提供相同名称的 ServiceDeployment。 如果 Gateway 发生变化(例如添加了一个新端口),这些配置将会自动更新。

这些资源可以通过以下几种方式进行定义:

  • Gateway 上的注释和标签复制到 ServiceDeployment。 这就允许配置从上述字段中读取到的内容, 如配置内部负载均衡器等。

  • Istio 提供了一个额外的注释来配置生成的资源:

    注解用途
    networking.istio.io/service-type控制 Service.spec.type 字段。例如,设置 ClusterIP 为不对外暴露服务,将会默认为LoadBalancer
  • 通过配置 addresses 字段可以显式设置 Service.spec.loadBalancerIP 字段:

    1. apiVersion: gateway.networking.k8s.io/v1beta1
    2. kind: Gateway
    3. metadata:
    4. name: gateway
    5. spec:
    6. addresses:
    7. - value: 192.0.2.0
    8. type: IPAddress
    9. ...

    请注意:仅能指定一个地址。

  • (高级用法)生成的 Pod 配置可以通过自定义注入模板进行配置。

资源附加和扩缩

资源附加目前是实验性的功能。

资源可以附加到 Gateway 进行自定义。 然而,大多数 Kubernetes 资源目前不支持直接附加到 Gateway, 但这些资源可以转为直接被附加到相应生成的 DeploymentService。 这个操作比较简单,因为这两种资源被生成时名称为 <gateway name>-<gateway class name> 且带有标签 istio.io/gateway-name: <gateway name>

例如,参照以下部署类别为 HorizontalPodAutoscalerPodDisruptionBudgetGateway

  1. apiVersion: gateway.networking.k8s.io/v1beta1
  2. kind: Gateway
  3. metadata:
  4. name: gateway
  5. spec:
  6. gatewayClassName: istio
  7. listeners:
  8. - name: default
  9. hostname: "*.example.com"
  10. port: 80
  11. protocol: HTTP
  12. allowedRoutes:
  13. namespaces:
  14. from: All
  15. ---
  16. apiVersion: autoscaling/v2
  17. kind: HorizontalPodAutoscaler
  18. metadata:
  19. name: gateway
  20. spec:
  21. # 通过引用与生成的 Deployment 匹配
  22. # 注意不要使用 `kind: Gateway`
  23. scaleTargetRef:
  24. apiVersion: apps/v1
  25. kind: Deployment
  26. name: gateway-istio
  27. minReplicas: 2
  28. maxReplicas: 5
  29. metrics:
  30. - type: Resource
  31. resource:
  32. name: cpu
  33. target:
  34. type: Utilization
  35. averageUtilization: 50
  36. ---
  37. apiVersion: policy/v1
  38. kind: PodDisruptionBudget
  39. metadata:
  40. name: gateway
  41. spec:
  42. minAvailable: 1
  43. selector:
  44. # 通过标签匹配生成的 Deployment
  45. matchLabels:
  46. istio.io/gateway-name: gateway

手动部署

如果您不希望使用自动部署,可以进行手动配置 DeploymentService

完成此选项后,您将需要手动将 Gateway 链接到 Service,并保持它们的端口配置同步。

要将 Gateway 链接到 Service,需要将 addresses 字段配置为指向单个 Hostname

  1. apiVersion: gateway.networking.k8s.io/v1beta1
  2. kind: Gateway
  3. metadata:
  4. name: gateway
  5. spec:
  6. addresses:
  7. - value: ingress.istio-gateways.svc.cluster.local
  8. type: Hostname
  9. ...

网格流量

使用 Gateway API 配置内部网格流量目前是一个还在开发的实验性特性

Gateway API 也可以用来配置网格流量。 具体做法是配置 parentRef 指向一个服务,而不是指向一个 Gateway。

例如,要将所有调用的头部添加到一个名为 example 的集群内 Service

  1. apiVersion: gateway.networking.k8s.io/v1beta1
  2. kind: HTTPRoute
  3. metadata:
  4. name: mesh
  5. spec:
  6. parentRefs:
  7. - group: ""
  8. kind: Service
  9. name: example
  10. rules:
  11. - filters:
  12. - type: RequestHeaderModifier
  13. requestHeaderModifier:
  14. add:
  15. - name: my-added-header
  16. value: added-value
  17. backendRefs:
  18. - name: example
  19. port: 80

有关更多详情和示例,请参阅其他流量管理

清理

  1. 卸载 Istio 和 httpbin 示例:

    Zip

    1. $ kubectl delete -f @samples/httpbin/httpbin.yaml@
    2. $ kubectl delete httproute http
    3. $ kubectl delete gateways.gateway.networking.k8s.io gateway -n istio-ingress
    4. $ istioctl uninstall -y --purge
    5. $ kubectl delete ns istio-system
    6. $ kubectl delete ns istio-ingress
  2. 如果不再需要这些 Gateway API CRD 资源,请移除:

    1. $ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.0.0" | kubectl delete -f -