DestinationRule

最新推荐文章于 2024-04-03 17:29:50 发布
最新推荐文章于 2024-04-03 17:29:50 发布
阅读量901 收藏 2
点赞数
分类专栏： Istio 文章标签： kubernetes istio
原文链接：https://istio.io/latest/zh/docs/reference/config/networking/destination-rule/
版权

DestinationRule

DestinationRule 定义在路由发生后应用于服务的流量的策略。这些规则指定负载均衡的配置、sidecar 的连接池大小以及离群值检测设置，以检测并从负载平衡池中清除不正常的主机。

下面的示例中，对 ratings 服务进行了简单的负载均衡。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN

可以通过定义给定名称的 subset 并覆盖在服务级别指定的设置来指定特定于版本的策略。下面的示例中，使用轮询负载均衡策略，将所有流量分配到名为 testversion 的子集，该子集由带有标签 version:v3 的 endpoints（如 pods）组成。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN
  subsets:
  - name: testversion
    labels:
      version: v3
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN

注意：为子集指定的策略直到路由规则明确发送流量到该子集才会生效。

流量策略也可以针对特定端口进行自定义。下面的示例中，对到端口 80 的所有流量使用 最小连接 负载均衡策略，而对到端口 9080 的流量使用 轮询 负载均衡策略。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings-port
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:                # Apply to all ports
    portLevelSettings:
    - port:
        number: 80
      loadBalancer:
        simple: LEAST_CONN
    - port:
        number: 9080
      loadBalancer:
        simple: ROUND_ROBIN

ConnectionPoolSettings

上游主机的连接池设置，这些设置应用于上游服务中的每个主机。连接池设置既可以应用于 TCP 级别，也可以应用于 HTTP 级别。

下面的示例中，将连接到 myredissrv 服务的连接限制为 100 个，连接超时为 30ms。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-redis
spec:
  host: myredissrv.prod.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 30ms
        tcpKeepalive:
          time: 7200s
          interval: 75s
字段类型描述是否必需
tcpTCPSettingsHTTP 和 TCP 上游连接的通用设置否
httpHTTPSettingsHTTP 连接池设置否

ConnectionPoolSettings.HTTPSettings

适用于 HTTP1.1/HTTP2/GRPC 连接的设置。

字段类型描述是否必需
http1MaxPendingRequestsint32到目标的 pending 状态 HTTP 请求的最大数目。默认是 2^32 - 1否
http2MaxRequestsint32对一个后端的最大请求数。默认是 2^32 - 1否
maxRequestsPerConnectionint32每个连接对后端的最大请求数。将该参数设置为 1 表示禁用 keep alive。默认是 0，表示不限制，最大是 2^29否
maxRetriesint32在给定时间内集群中所有主机可执行的最大重试次数。默认是 2^32 - 1否
idleTimeoutDuration上游连接池连接的空闲超时时间。空闲超时被定义为没有活动请求的时间段。如果没有设置，则默认为 1 小时。当达到空闲超时时，连接将被关闭。注意，基于请求的超时意味着 HTTP/2 PINGs 将不能保持连接。适用于 HTTP1.1 和 HTTP2 连接否
h2UpgradePolicyH2UpgradePolicy指定 HTTP1.1 连接是否应该为关联的目标升级到 HTTP2否

ConnectionPoolSettings.HTTPSettings.H2UpgradePolicy

HTTP1.1 升级到 HTTP2 连接的策略。

名称描述
DEFAULT使用全局默认配置
DO_NOT_UPGRADE不要升级到 HTTP2 连接，该选项会覆盖默认选项
UPGRADE升级到 HTTP2 的连接，该选项会覆盖默认选项

ConnectionPoolSettings.TCPSettings

HTTP 和 TCP 上游连接的通用设置。

字段类型描述是否必需
maxConnectionsint32到一个目标主机的 HTTP1/TCP 连接的最大数目。默认是 2^32 - 1否
connectTimeoutDurationTCP 连接的超时时间否
tcpKeepaliveTcpKeepalive如果设置该参数，则会在 socket 上设置 SO_KEEPALIVE 以启用 TCP Keepalives否

ConnectionPoolSettings.TCPSettings.TcpKeepalive

TCP keepalive。

字段类型描述是否必需
probesint32在确定连接失活之前要发送而没有响应的 keepalive 探测的最大数量。默认为使用操作系统级别的配置（除非被覆盖，Linux 默认为 9）否
timeDuration在 keep-alive 探针开始发送之前，连接需要处于空闲状态的时间。默认是使用操作系统级别的配置（除非被覆盖，Linux 默认为 7200s）否
intervalDurationkeep-alive 探针发送的时间间隔。默认是使用操作系统级别的配置（除非被覆盖，Linux 默认为 75s）否

DestinationRule

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

字段类型描述是否必需
hoststring服务注册表中的服务名称。从平台的服务注册表（如 Kubernetes services、Consul services）以及 ServiceEntry 声明的主机中查找服务名称。为服务注册表中不存在的服务定义的规则将被忽略。注意，host 字段适用于 HTTP 和 TCP 服务是
trafficPolicyTrafficPolicy要应用的流量策略（负载平衡策略，连接池大小，异常检测）否
subsetsSubset[]表示服务的各个版本的一个或多个子集。可以在子集级别覆盖流量策略否
exportTostring[]DestinationRule 暴露到的命名空间的列表。应用于服务的 DestinationRule 的解析发生在命名空间层次结构的上下文中，暴露 DestinationRule 可将其包含在其他命名空间中的服务的解析层次结构中。此功能可以控制 DestinationRule 跨命名空间边界的可见性。如果未指定命名空间，则默认情况下会将 DestinationRule 暴露到所有命名空间。. 作为保留，表示暴露 DestinationRule 到声明它的同一命名空间。类似的，* 作为保留，表示暴露到所有命名空间。注意：在当前版本中，该 exportTo 值限制为 . 或 *（即当前命名空间或所有命名空间）否

LoadBalancerSettings

应用于指定目标的负载均衡策略。下面的示例中，对所有流向 ratings 服务的流量使用 轮询 负载均衡策略。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN

下面的示例中，使用用户 cookie 作为 hash key，为同一 ratings 服务的基于散列的负载均衡器设置保持会话。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: user
          ttl: 0s
字段类型描述是否必需
simpleSimpleLB (oneof)是
consistentHashConsistentHashLB (oneof)是
localityLbSettingLocalityLoadBalancerSetting局部负载平衡器设置，将完全覆盖网格范围的设置，这意味着此对象与 MeshConfig 中的对象之间将不执行合并否

LoadBalancerSettings.ConsistentHashLB

基于一致性 hash 的负载平衡可用于基于 HTTP header、cookie 或其他属性提供软会话亲和性。此负载平衡策略仅适用于 HTTP 连接。当从目标服务添加、删除一个或多个主机时，与特定目标主机的亲和性会丢失。

字段类型描述是否必需
httpHeaderNamestring (oneof)基于特定 HTTP header 的 hash是
httpCookieHTTPCookie (oneof)基于特定 HTTP cookie 的 hash是
useSourceIpbool (oneof)基于源 IP 地址 的 hash是
minimumRingSizeuint64用于 hash 环的最小虚拟节点数。默认为 1024，更大的环尺寸会导致更细粒度的负载分布。如果负载平衡池中的主机数大于环数，则为每个主机分配一个虚拟节点否

LoadBalancerSettings.ConsistentHashLB.HTTPCookie

描述将用作一致性 hash 负载均衡器的 hash key 的 HTTP cookie。如果 cookie 不存在，则会生成它。

字段类型描述是否必需
namestringcookie 名称是
pathstring设置 cookie 的路径否
ttlDurationcookie 的存活时间是

LoadBalancerSettings.SimpleLB

无需调优的标准负载均衡算法。

名称描述
ROUND_ROBIN轮询 策略。默认
LEAST_CONN最小连接负载均衡算法，该算法选择两个随机的健康主机，并选择活动请求较少的主机
RANDOM随机负载均衡算法，随机选择一个健康主机。如果未配置运行状况检查策略，则随机负载均衡器的性能通常比轮询更好
PASSTHROUGH此选项会将连接转发到调用者请求的原始 IP 地址，而不做任何形式的负载均衡。必须谨慎使用此选项，它适用于高级用例

LocalityLoadBalancerSetting

位置加权的负载均衡可以根据流量的产生地点和终止地点来控制流量到 endpoints 的分配。这些地点是使用任意标签指定的，这些标签以 {region}/{zone}/{sub-zone} 的形式指定地点的层次结构。

给定一个包含工作负载的网格，并将其服务部署到 us-west/zone1/ 和 us-west/zone2/。下面的示例中，当访问服务的流量来自 us-west/zone1/ 中的工作负载时，80% 的流量将发送到 us-west/zone1/ 中的 endpoints，即相同的 zone，剩余的 20% 流量将发送到 us-west/zone2/ 中的 endpoints。这种设置旨在将流量路由到同一地点的 endpoints。

  distribute:
    - from: us-west/zone1/*
      to:
        "us-west/zone1/*": 80
        "us-west/zone2/*": 20
    - from: us-west/zone2/*
      to:
        "us-west/zone1/*": 20
        "us-west/zone2/*": 80

如果目标不是在跨区域和区域之间分配负载，而是限制故障转移的区域性以满足其他操作需求，则可以设置 failover 策略而不是 distribute 策略。

下面的示例中，为区域设置区域故障转移策略。假设服务驻留在 us-east、us-west 和 eu-west 中的区域中，指定当 us-east 中的 endpoints 变得不健康时，流量应故障转移到 eu-west 中的任何区域或子区域中的 endpoints。同样，us-west 也应故障转移到 us-east。

 failover:
   - from: us-east
     to: eu-west
   - from: us-west
     to: us-east
字段类型描述是否必需
distributeDistribute[]（可选）只能设置为 distribute 或 failover。指定跨不同区域和地理位置的负载均衡权重，如果为空，则根据区域内的 endpoints 数量设置区域权重否
failoverFailover[]（可选）只能设置为 distribute 或 failover。指定当本地区域中的 endpoints 变得不健康时，流量将转移到的区域。应与 OutlierDetection 一起使用以检测不健康的端点。注意：如果未指定 OutlierDetection，则此设置将不会生效否

LocalityLoadBalancerSetting.Distribute

描述源自 from 区域或子区域的流量如何在一组 to 区域中分配。指定区域的语法是 {region}/{zone}/{sub-zone}，规范的任何部分都允许使用通配符。例如：* 匹配所有地区，us-west/* 匹配 us-west 区域内的所有区域和子区域，us-west/zone-1/* 匹配 us-west/zone-1 内的所有子区域。

字段类型描述是否必需
fromstring原始位置，以 / 分隔，如 region/zone/sub_zone否
tomap<string, uint32>上游流量分配权重的映射。所有权重之和是 100，任何未分配权重的地区都不会收到任何流量否

LocalityLoadBalancerSetting.Failover

指定跨区域的流量故障转移策略。由于默认情况下支持区域和子区域故障转移，因此仅在操作员需要限制流量故障转移时才需要为区域指定此选项，以使全局故障转移到任何端点的默认行为不适用。当跨区域故障转移无法改善服务健康或由于其他原因（例如监管控制）而需要限制时，此功能很有用。

字段类型描述是否必需
fromstring原区域否
tostring当原区域的 endpoints 变得不健康时，流量将故障转移到目标区域否

OutlierDetection

一种断路器实现，用于跟踪上游服务中每个独立主机的状态，适用于 HTTP 和 TCP 服务。对于 HTTP 服务，持续为 API 调用返回 5xx 错误的主机将从连接池中移除一段预先定义好的时间。对于 TCP 服务，在测量连续错误指标时，到给定主机的连接超时或连接失败将被视为错误。

下面的示例中，将连接池大小设置为 100 个 HTTP1 连接，并且 reviews 服务的请求或连接不得超过 10 个。此外，它设置了 1000 个并发 HTTP2 请求的限制，并配置每 5 分钟扫描一次上游主机，以便任何连续出现 7 次 502、503 或 504 错误码的主机被移除 15 分钟。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews-cb-policy
spec:
  host: reviews.prod.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http2MaxRequests: 1000
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutiveErrors: 7
      interval: 5m
      baseEjectionTime: 15m
字段类型描述是否必需
consecutiveErrorsint32主机从连接池移除之前的错误数，默认是 5。当通过 HTTP 访问上游主机时，返回 502、503 或 504 将被视为错误。当通过不透明的 TCP 连接访问上游主机时，连接超时或连接失败都被视为错误否
intervalDuration移除扫描分析之间的时间间隔。格式：1h、1m、1s、1ms，必须 >= 1ms。默认是 10s否
baseEjectionTimeDuration最小移除持续时间。主机将在一段时间内保持被移除的状态，这个时间等于最小弹出持续时间与主机已移除次数的乘积。这样可以使系统自动增加不健康上游服务器的移除时间。格式：1h、1m、1s、1ms，必须 >= 1ms。默认是 30s否
maxEjectionPercentint32负载均衡池中可以移除的上游服务的最大主机百分比。默认是 10%否
minHealthPercentint32只要关联的负载平衡池至少有 minHealthPercent 的主机处于健康模式，就将启用异常检测。当负载平衡池中的健康主机百分比降至此阈值以下时，异常检测将被禁用，代理将在池中所有主机（正常和不正常）之间进行负载平衡。可以通过将此阈值设置为 0% 来禁用它。默认是 0%，因为它通常不适用于每个服务只有少量 Pod 的 Kubernetes 环境否

Subset

服务的 endpoints 的子集，子集可用于 A/B 测试或路由到特定服务版本的场景。此外，在服务级别定义的流量策略可以在子集级别被覆盖。

下面的示例中，对进入名为 testversion 的子集的所有流量使用 轮询 负载均衡策略，该子集由带有标签 version: v3 的 endpoints（如 Pod）组成。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN
  subsets:
  - name: testversion
    labels:
      version: v3
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN

注意：为子集指定的策略只有在路由规则明确发送流量到该子集时才会生效。

通常需要一个或多个标签来标识子集目的地，但是，当相应的 DestinationRule 表示支持多个 SNI 主机（如 Egress Gateway）的主机时，没有标签的子集可能是有意义的。在这种情况下，可以使用带有 TLSSettings 的流量策略来识别与指定子集相对应的特定 SNI 主机。

字段类型描述是否必需
namestring子集的名称。服务名称和子集名称可用于路由规则中的流量分流是
labelsmap<string, string>在服务注册表中的 endpoints 上进行标签过滤否
trafficPolicyTrafficPolicy应用于该子集的流量策略。子集继承在 DestinationRule 级别指定的流量策略，在子集级别指定的设置将覆盖在 DestinationRule 级别指定的相应设置否

TLSSettings

上游连接的 SSL/TLS 相关设置。下面的示例中，将客户端配置为使用双向 TLS 来连接到上游数据库集群。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: db-mtls
spec:
  host: mydbserver.prod.svc.cluster.local
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem

下面的示例中，将客户端配置为在与域名匹配 *.foo.com 的外部服务进行连接时使用 TLS。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: tls-foo
spec:
  host: "*.foo.com"
  trafficPolicy:
    tls:
      mode: SIMPLE

下面的示例中，将客户端配置为在与 ratings 服务连接时使用 Istio 双向 TLS。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ratings-istio-mtls
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
字段类型描述是否必需
modeTLSmode指示是否使用 TLS 保护与该端口的连接。此字段的值决定如何启用 TLS是
clientCertificatestring如果模式是 MUTUAL，则是必需字段。包含要使用的客户端 TLS 证书的文件的路径。如果模式是 ISTIO_MUTUAL，则该字段应为空否
privateKeystring如果模式是 MUTUAL，则是必需字段。保存客户端私钥的文件的路径。如果模式是 ISTIO_MUTUAL，则该字段应为空否
caCertificatesstring（可选）包含用于验证提供的服务器证书的根证书的文件的路径。如果省略，则代理将不会验证服务器的证书。如果模式是 ISTIO_MUTUAL，则该字段应为空否
subjectAltNamesstring[]验证证书中主题身份的备用名称列表。如果指定，则代理将验证服务器证书的主题替代名称是否与指定值之一匹配。如果指定，此列表将覆盖ServiceEntry 中的主题替代名称的值否
snistringTLS 握手期间要提供给服务器的 SNI 字符串否

TLSSettings.TLSmode

TLS 连接模式。

名称描述
DISABLE不建立到上游 endpoints 的 TLS 连接
SIMPLE发起到上游 endpoints 的 TLS 连接
MUTUAL通过提供用于身份验证的客户端证书，使用双向 TLS 来保护与上游的连接
ISTIO_MUTUAL通过提供用于身份验证的客户端证书，使用双向 TLS 来保护与上游的连接。与 MUTUAL 模式相比，该模式使用 Istio 自动生成的证书进行 mTLS 身份验证。使用该模式时，TLSSettings 中的所有其他字段均应为空

TrafficPolicy

应用于指定目标的流量策略，适用于所有目的端口。

字段类型描述是否必需
loadBalancerLoadBalancerSettings控制负载平衡器算法的设置否
connectionPoolConnectionPoolSettings控制与上游服务的连接量的设置否
outlierDetectionOutlierDetection用于控制从负载平衡池中移除不健康主机的设置否
tlsTLSSettingsTLS相关设置，用于连接到上游服务否
portLevelSettingsPortTrafficPolicy[]针对单个端口的流量策略。注意，端口级别设置将覆盖目标级别设置。当被端口级别设置覆盖时，在目标级别指定的流量设置将不会被继承，即端口级 别策略中省略的字段将应用缺省值否

TrafficPolicy.PortTrafficPolicy

应用于服务指定端口的流量策略。

字段类型描述是否必需
portPortSelector指定目标服务上要应用此策略的端口号否
loadBalancerLoadBalancerSettings控制负载平衡器算法的设置否
connectionPoolConnectionPoolSettings控制与上游服务的连接量的设置否
outlierDetectionOutlierDetection用于控制从负载平衡池中移除不健康主机的设置否
tlsTLSSettingsTLS相关设置，用于连接到上游服务否
最爱喝酸奶
关注
专栏目录
从技术架构的视角出发,介绍Istio的技术架构及各模块的功能实现原理
程序员光剑
07-29 983
2017年11月，IBM、Google、Lyft 联合宣布成立 Service Mesh 工作组，推出了 Istio 开源项目。Istio 是目前服务网格领域中最热门的开源产品之一，被众多云厂商和大型互联网公司采用并作为服务网格的默认解决方案。在过去的一年里，Istio 迅速崛起，其 Github Star 数量已经超过了 3万，持续火爆发展。Istio 是什么?Service mesh（服务网格）是由专门的服务代理组件 Envoy 和控制面板 Mixer 组成的专用基础设施层。
Service Mesh ——下一代微服务
程序员光剑
08-01 2044
Service Mesh（服务网格）这个词已经被越来越多的人们所熟知，但实际上它却是一个比较模糊的名词。由于种种原因，使得Service Mesh一直没有得到广泛关注，虽然它给微服务架构带来了很多好处，但同时也存在一些问题。近些年，随着容器技术、微服务架构、DevOps和云计算的普及，越来越多的人开始认识到微服务架构带来的巨大便利和商业价值，也越来越多的人开始关注Service Mesh这个新兴技术。因此，在大众的视野中，Service Mesh已经开始走向成熟。
DestinationRule详解
mark's technic world
05-25 3544
学习目标 什么是DestinationRule 与VirtualService一样，DestinationRule也是 Istio 流量路由功能的关键部分。您可以将虚拟服务视为将流量如何路由到给定目标地址，然后使用目标规则来配置该目标的流量。在评估虚拟服务路由规则之后，目标规则将应用于流量的“真实”目标地址。 特别是，您可以使用目标规则来指定命名的服务子集，例如按版本为所有给定服务的实例分组。然后可以在虚拟服务的路由规则中使用这些服务子集来控制到服务不同实例的流量。 目标规则还允许您在调用.
Istio系列学习(八)----Istio的目标规则:DestinationRule
我在深圳的这些日子的博客
01-24 2441
一、destinationRule 和 VirtualService的联系和区别 1）两者之间的关系 在讲解virtualService中，路由目标对象destination中会包含Service子集的subset字段，这个服务子集就是通过DestinationRule定义的。 两者都是用于流量治理，那应用场景有什么区别？ virtualService是一个虚拟的service，描述的是满足什么条件的流量被那个后端处理。类似于根据路径去匹配方法，是更开放的match条件。 DestinationRule描
Istio学习笔记——DestinationRule解析
最新发布
weixin_42236288的博客
04-03 1210
DestinationRule用于管理Istio服务网格中的流量路由和负载均衡。它通常与VirtualService一起使用，共同发挥作用，将流量标记分组并路由到具体服务【将一个服务通过subset再次进行分组】。DestinationRule主要用于定义服务的负载均衡方式、服务版本选择、故障恢复策略等，以及优化服务的性能和可靠性。
Istio系列学习(九)----DestinationRule的典型应用
我在深圳的这些日子的博客
01-26 697
一、定义subset 通过DestinationRule定义Subset，就可以配合VirtualService给每个Subset配置路由规 则 二、服务熔断 istio在功能上有异常点检查和连接池管理两种手段，一般结合使用。 连接池配置： 以上配置的效果是:为forecast服务配置最大80个连接，最大请求数为800，每个连接的请求数都不超过10个，连接超时是25毫秒; 异常点检查：在4分钟内若有某个forecast服 务实例连续出现5次访问异常，比如返回5xx错误，则该forecast服务实例将被隔
destinationRule\Gateway\ServiceEntry\SideCar配置详解
进化的深山猿
04-28 1845
3.3 destinationRule destinationRule 和 VirtualService的联系和区别 1）两者之间的关系 在讲解virtualService中，路由目标对象destination中会包含Service子集的subset字段，这个服务子集就是通过DestinationRule定义的。 2) 两者都是用于流量治理，那应用场景有什么区别？ virtualService是一个虚拟的service，描述的是满足什么条件的流量被那个后端处理。类似于根据路径去匹配方法，是更开放的martc
Istio 目标规则 (Destination Rule)
叶康铭的博客
10-05 5267
目标规则（Destination Rule）是 Istio 重要的资源对象之一，它不能独自使用，必须跟 Virtual Service 共同发挥作用，作用是将流量标记分组并路由到具体服务。 Destination Rule 还可以做什么 通常在生产场景下，用使用 Destination Rule 对用户进行身份、地址位置等条件的识别后的流量路由，例如部分用户优先享用新版本，则可以通过HTTP Header附加相关的字段进行识别，路由到新版本的服务上。或者在版本更新的时候，使用灰度发布，对新旧版本标记子集.
Istio流量控制资源对象
Micky_Yang的博客
07-03 3824
一、VirtualService资源 　　VirtualService（虚拟服务）在增强Istio流量管理的灵活性和有效性方面发挥着至关重要的作用。Virtualservice由一组路由规则组成，用于对服务实体（在Kubernetes中对应为Pod）进行寻址。如果有流量命中了某条路有规则，就会将其发送到对应的服务或者服务的一个版本/子集。 　　VirtualService描述了用户可寻址目标到网格内实际工作负载之间的映射。可寻址的目标服务使用hosts字段来指定，而网格内的实际负载由每个route配置项中d
Istio Client-go -- DestinationRules
曾浩
08-24 396
查看 DestinationRules package main import ( "context" "log" "github.com/owenliang/k8s-client-go/common" versionedclient "istio.io/client-go/pkg/clientset/versioned" v1 "k8s.io/apimachinery/pkg/apis/meta/v1" ) func main() { namespace := "bookinfo"
Istio三之VirtualService、Gateway、DestinationRule配置使用
qiaotl的博客
07-25 6548
通过实际例子演示如何配置VirtualService、Gateway、DestinationRule完成流量管理
hystrix对比服务网格istio的destinationrule
weixin_33736832的博客
04-23 275
使用难度 hystrix 每个项目都需要引入hystrix包，或者在框架里引入，并且官方仅支持java <!-- https://mvnrepository.com/artifact/com.netflix.hystrix/hystrix-core --> <dependency> <groupId>com.netflix.hystrix</gro...
DestinationRule实现Istio集群高级配置
weixin_41989934的博客
03-11 677
更多相关文章 istio基本概念 手把手教你部署istio控制平面 四个案例让你掌握istio网格功能 VirtualService实现Istio高级流量治理 一、DestinationRule CR资源规范 二、DestinationRule配置要点 DestinationRule用于配置路由完成之后的应用于服务的流量策略，即配置如何将流量调度至上游端点，同时也是为 VirtualService的Destination指定的目标提供具体的定义和实现；主要包括以下配置项： 负载均衡配置 Sideca.
Istio VirtualService 结合 DestinationRule 基础使用
baobaoxiannv的博客
05-10 2830
ps：istio 的官方提供的 bookinfo 例子已经很齐全了，但我很讨厌拿 bookinfo 当作示例。因为是别人已经提供好的，包括 yaml 文件你自己根本没有从中学习到什么，所以想自己写一些 demo、yaml 来使用。 step1: 前提 在这里默认你已经自己提供了 demo，才可以往下进行。demo 可以如下图所示： 中间三个 pod 是我自己提供的 demo 其他的请无视。java-demo-client 是客户端，会调用 java-demo-service 服务端，服务端我提供了两个版本
【08】DestinationRule 高级配置功能
weixin_38753143的博客
11-13 142
就会把这个pod驱逐出去，然后驱逐10秒后，重新对该pod检测，如果还是连续5次error，再驱逐，这次驱逐时长就会很长。和我们定义的异常点检测相吻合。异常点检测是被动的健康检查。给其中一个pod注入故障，使的请求这个pod的时候，返回5**错误。此时在访问demoapp服务，会出现访问出错5次。到达v11版本的负载均衡策略是一致性哈希。访问demoapp，流量到达v10版本，参考weight中定义；定义demoapp访问的路由规则。查看demoapp的pod。定义连接池的相关参数的。
Istio 流量管理核心资源 VirtualService（虚拟服务）/DestinationRule（目标规则）/ Gateway（网关）/ ServiceEntry（服务入口）
小楼一夜听春雨，深巷明朝卖杏花
07-13 1992
istio最重要的是数据平面有个组件叫sidecar，它里面是采用的envoy的代理转发器，拦截所有业务程序的流量，只要你的业务程序接入了istio，到你业务的流量会被proxy接管，最重要的就是管理流量。核心资源： 上面4个是lstio在流量管理实现的具体资源。也即是我们要实现流量管理策略，都是基于这些资源去配置的。 VirtualService（虚拟服务）： 这里创建了gateway，监听的地址是80，只创建监听的路口是不行的，不具备一个转发的功能，下面是其具体的路由规则，service名称和端口。虚拟
istio+k8s[kubernetes]技术讲解【基础+进阶版】
11-03
<p><img src="https://img-bss.csdnimg.cn/202011031157262573.png" alt="" /></p> <p><img src="https://img-bss.csdnimg.cn/202011031157427393.png" alt="" /></p> <p><img src="https://img-bss.csdnimg.cn/202011031157559233.png" alt="" /></p> <p><img src="https://img-bss.csdnimg.cn/202011031158074009.png" alt="" /></p> <p><img src="https://img-bss.csdnimg.cn/202011031158188486.png" alt="" /></p>
Istio入门
GY的的专栏
07-17 1318
1. 简介 在本教程中，我们将介绍服务网格的基础知识，并了解它如何实现分布式系统架构。 我们将主要关注Istio，它是服务网格的一种具体实现。在此过程中，我们将介绍Istio的核心架构。 2. 什么是服务网格? 在过去的几十年中，我们已经看到了单体应用程序开始拆分为较小的应用程序。此外，诸如Docker之类的容器化技术和诸如Kubernetes之类的编排系统加速了这一变化。 尽管在像Kubernetes这样的分布式系统上采用微服务架构有许多优势，但它也具有相当的复杂性。由于分布式服务必须相互通信，因
服务网格内部的 VirtualService 和 DestinationRule 配置深度解析
weixin_33858485的博客
03-31 3253
原文链接：请求都去哪了？（续） 书接前文，上文我们通过跟踪集群外通过 ingressgateway 发起的请求来探寻流量在 Istio 服务网格之间的流动方向，先部署 bookinfo 示例应用，然后创建一个监听在 ingressgateway 上的 GateWay 和 VirtualService，通过分析我们追踪到请求最后转交给了 productpage。 在继续追踪请求之前，先对之前的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值