【问题标题】:How Istio DestinationRule related to Kubernetes Service?Istio DestinationRule 与 Kubernetes Service 的关系如何?
【发布时间】:2023-03-26 15:21:01
【问题描述】:

我试图了解如何在 Istio 中进行负载平衡。

Istio DestinationRule 定义了 pod 之间流量平衡的规则。 K8s Service 类似管理 Pod 之间的流量负载均衡。

DestinationRule 定义主机,k8s 服务定义主机。

但没有 k8s 服务,请求失败,http 代码 503。

k8s Service 与 DestinationRule 的关系如何?

【问题讨论】:

  • k8s 服务在 Istio 中仍有 some 实用程序,但就像 Istio 正在以自己的方式重新解释它。我不知道幕后究竟发生了什么,但 istio 仍然使用服务名称和端口在某种程度上识别请求的目的地。然后,DestinationRules / VirtualServices 将扩展/细化路由;负载平衡发生在 Envoy 边车中。

标签: load-balancing istio


【解决方案1】:

Kubernetes 服务

Kubernetes 服务类型 ClusterIP 使用 kube-proxy 的 iptables 规则来分发请求。

文档说:

默认情况下,用户空间模式下的 kube-proxy 通过循环算法选择后端。

更多信息here

目标规则

如上所述here

您可以将虚拟服务视为将流量路由到给定目的地的方式,然后您可以使用目的地规则来配置该目的地的流量会发生什么。目的地规则在评估虚拟服务路由规则之后应用,因此它们适用于流量的“真实”目的地。

每个 HTTP 路由都必须有一个目标:路由或重定向。路由是一个转发目标,它可以指向 DestinationRules 中描述的服务的多个版本之一。与服务版本相关的权重决定了它接收的流量比例。

DestinationRule 定义了在路由发生后应用于服务的流量的策略。

还有here

当虚拟服务匹配规则并评估将流量路由到的目的地时,目的地规则定义服务的可用子集以发送流量。

例如,如果您的服务同时运行多个版本,您可以创建目标规则来定义到这些版本的路由。然后使用虚拟服务映射到由目标规则定义的特定子集,或将一定比例的流量拆分到特定版本。

503 没有 Kubernetes 服务

但没有 k8s 服务,请求失败,http 代码 503。

失败是因为没有在虚拟服务中指定的主机和目标规则。

例如,看看这个virtual service and destination rule

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews.prod.svc.cluster.local
  http:
  - name: "reviews-v2-routes"
    match:
    - uri:
        prefix: "/wpcatalog"
    route:
    - destination:
        host: reviews.prod.svc.cluster.local  <---
        subset: v2
  - name: "reviews-v1-route"
    route:
    - destination:
        host: reviews.prod.svc.cluster.local  <---
        subset: v1


apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews.prod.svc.cluster.local  <---
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

如果您检查host,那么您会看到指定了您的 kubernetes 服务,如果没有它,它将无法工作。


此外,在设置路由规则以将流量引导至服务的特定版本(子集)时,必须注意确保子集在用于路由之前可用。否则,在重新配置期间调用服务可能会返回 503 错误。

更多信息here

DestinationRule 定义主机,k8s 服务定义主机。

目标规则主机是您的 kubernetes 服务。 Kubernetes 服务主机是您的 pod, 您可能想知道,但我为什么需要服务?

正如提到的here

Kubernetes 服务是一种抽象,它定义了在集群中某处运行的一组逻辑 Pod,它们都提供相同的功能。创建时,每个服务都分配有一个唯一的 IP 地址(也称为 clusterIP)。此地址与服务的生命周期相关联,并且在服务存在期间不会更改。 Pod 可以配置为与 Service 通信,并且知道与 Service 的通信将自动负载平衡到属于 Service 成员的某个 Pod。

Kubernetes Service 与 DestinationRule 相关

我找不到它是如何工作的确切信息,所以我将解释我是如何理解它的。

您需要 Kubernetes 服务,这样虚拟服务和目标规则才能真正起作用。

由于 kubernetes 服务使用 kube-proxy 的 iptables 规则来分发请求,我假设 istio 目标规则可以用他自己的规则覆盖它,并通过 envoy sidecar 应用它们,因为您的网格服务发送和接收的所有流量(数据飞机流量)通过 Envoy 代理,从而可以轻松地引导和控制网格周围的流量,而无需对您的服务进行任何更改。

更多信息here


其他资源:


如果您还有其他问题,请告诉我。

【讨论】:

  • 嗨,Jakub!我仔细研究了你的答案,它非常有用。我更深入地挖掘了 Istio 以及我的理解,当 istio 在destinationrule 中定义子集时,它使用来自 kubernetes 服务的端点信息。 Istio envoy 负载均衡从 k8s 服务执行端点。我有一个问题:什么是虚拟服务主机名? VirtualService 主机不是 Kubernetes DNS 的一部分。我将流量路由到 k8s 服务,并且 envoy 通过主机名定义现有的 VirtualService ?
  • 嗨@PavelSerebryakov,我不确定你问的是主机还是目标字段,但它们都被很好地描述了herehere。虚拟服务为此使用 istio 注册表,例如,如果您在 Kubernetes 集群上安装了 Istio,那么 Istio 会自动检测该集群中的服务和端点。更多关于它here.
  • 如果此答案或任何其他答案对您有帮助或解决了您的问题,请将其标记为已接受或按stackoverflow rules 投票。
猜你喜欢
  • 2019-01-14
  • 2021-06-09
  • 2021-02-02
  • 2019-05-13
  • 2021-02-11
  • 2019-01-17
  • 1970-01-01
  • 2020-10-30
  • 2021-04-19
相关资源
最近更新 更多