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。
其他资源:
如果您还有其他问题,请告诉我。