• istio路由配置


    istio路由配置##

      istio的代理配置参考文档:

    1.Istio v1aplha3路由API介绍###

    详细介绍: https://istio.io/blog/2018/v1alpha3-routing/

    在一个典型的网格中,通常有一个或多个用于终结外部 TLS 链接,将流量引入网格的负载均衡器(我们称之为 gateway). 然后流量通过边车网关(sidecar gateway)流经内部服务.应用程序使用外部服务的情况也很常见(例如访问 Google Maps API),一些情况下,这些外部服务可能被直接调用;但在某些部署中,网格中所有访问外部服务的流量可能被要求强制通过专用的出口网关(Egress gateway).下图描绘了网关在网格中的使用情况.

    考虑到上述因素,v1alpha3引入了以下这些新的配置资源来控制进入网格,网格内部和离开网格的流量路由。

    1.Gateway

    2.VirtualService

    3.DestionRule

    4.ServiceEntry

    下图描述了跨多个配置资源的控制流程

    GateWay####

    Gateway 用于为 HTTP / TCP 流量配置负载均衡器,并不管该负载均衡器将在哪里运行。 网格中可以存在任意数量的 Gateway,并且多个不同的 Gateway 实现可以共存。 实际上,通过在配置中指定一组工作负载(Pod)标签,可以将 Gateway 配置绑定到特定的工作负载,从而允许用户通过编写简单的 Gateway Controller 来重用现成的网络设备。

    对于入口流量管理,您可能会问: 为什么不直接使用 Kubernetes Ingress API ? 原因是 Ingress API 无法表达 Istio 的路由需求。 Ingress 试图在不同的 HTTP 代理之间取一个公共的交集,因此只能支持最基本的 HTTP 路由,最终导致需要将代理的其他高级功能放入到注解(annotation)中,而注解的方式在多个代理之间是不兼容的,无法移植。

    Istio Gateway 通过将L4-L6配置与L7配置分离的方式克服了 Ingress 的这些缺点。 Gateway 只用于配置L4-L6功能(例如,对外公开的端口,TLS 配置),所有主流的L7代理均以统一的方式实现了这些功能。 然后,通过在 Gateway 上绑定 VirtualService 的方式,可以使用标准的 Istio 规则来控制进入 Gateway 的 HTTP 和 TCP 流量。

    例如,下面这个简单的 Gateway 配置了一个 Load Balancer,以允许访问 host bookinfo.com 的 https 外部流量进入网格中:

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: bookinfo-gateway 
    spec:
      servers:
      - port:
          number: 443
          name: https
          protocol: HTTPS
        hosts:
        - bookinfo.com
        tls:
          mode: SIMPLE
          serverCertificate: /tmp/tls.crt
          privateKey: /tmp/tls.key
    

    要为进入上面的 Gateway 的流量配置相应的路由,必须为同一个 host 定义一个 VirtualService(在下一节中描述),并使用配置中的 gateways 字段绑定到前面定义的 Gateway 上:

    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: bookinfo
    spec:
      hosts:
        - bookinfo.com
      gateways:
      - bookinfo-gateway # <---- bind to gateway
        http:
      - match:
        - uri:
            prefix: /reviews
        route:
        ...
    

    Gateway 可以用于建模边缘代理或纯粹的内部代理,如第一张图所示。 无论在哪个位置,所有网关都可以用相同的方式进行配置和控制。

    Virtual Service####

    用一种叫做 “Virtual services” 的东西代替路由规则可能看起来有点奇怪,但对于它配置的内容而言,这事实上是一个更好的名称,特别是在重新设计 API 以解决先前模型的可扩展性问题之后。

    实际上,发生的变化是:在之前的模型中,需要用一组相互独立的配置规则来为特定的目的服务设置路由规则,并通过 precedence 字段来控制这些规则的顺序;在新的 API 中,则直接对(虚拟)服务进行配置,该虚拟服务的所有规则以一个有序列表的方式配置在对应的 VirtualService 资源中。

    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: reviews
    spec:
      hosts:
        - reviews
      http:
      - match:
        - headers:
            cookie:
              regex: "^(.*?;)?(user=jason)(;.*)?$"
        route:
        - destination:
            host: reviews
            subset: v2
      - route:
        - destination:
            host: reviews
            subset: v1
    

    VirtualService描述了一个或多个用户可寻址目标到网格内实际工作负载之间的映射。在上面的示例中,这两个地址是相同的,但实际上用户可寻址目标可以是任何用于定位服务的,具有可选通配符前缀或 CIDR 前缀的 DNS 名称。 这对于应用从单体架构到微服务架构的迁移过程特别有用,单体应用被拆分为多个独立的微服务后,采用 VirtualService 可以继续把多个微服务对外暴露为同一个目标地址,而不需要服务消费者进行修改以适应该变化。

    DestinationRule####

    DestinationRule 配置将流量转发到服务时应用的策略集。 这些策略应由服务提供者撰写,用于描述断路器,负载均衡设置,TLS 设置等.

    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: reviews
    spec:
      host: reviews
      trafficPolicy:
        loadBalancer:
          simple: RANDOM
      subsets:
      - name: v1
        labels:
          version: v1
      - name: v2
        labels:
          version: v2
        trafficPolicy:
          loadBalancer:
            simple: ROUND_ROBIN
      - name: v3
        labels:
          version: v3
    

    ServiceEntry###

    ServiceEntry 用于将附加条目添加到 Istio 内部维护的服务注册表中。 它最常用于对访问网格外部依赖的流量进行建模,例如访问 Web 上的 API 或遗留基础设施中的服务。

    所有以前使用 EgressRule 进行配置的内容都可以通过 ServiceEntry 轻松完成。 例如,可以使用类似这样的配置来允许从网格内部访问一个简单的外部服务:

    apiVersion: networking.istio.io/v1alpha3
    kind: ServiceEntry
    metadata:
      name: foo-ext
    spec:
      hosts:
      - foo.com
        ports:
      - number: 80
        name: http
        protocol: HTTP
    

    也就是说,ServiceEntry 比它的前身具有更多的功能。首先,ServiceEntry 不限于外部服务配置,它可以有两种类型:网格内部或网格外部。网格内部条目只是用于向网格显式添加服务,添加的服务与其他内部服务一样。采用网格内部条目,可以把原本未被网格管理的基础设施也纳入到网格中(例如,把虚机中的服务添加到基于 Kubernetes 的服务网格中)。网格外部条目则代表了网格外部的服务。对于这些外部服务来说,双向 TLS 身份验证是禁用的,并且策略是在客户端执行的,而不是在像内部服务请求一样在服务器端执行策略。

    由于 ServiceEntry 配置只是将服务添加到网格内部的服务注册表中,因此它可以像注册表中的任何其他服务一样,与 VirtualService 和/或 DestinationRule 一起使用。例如,以下 DestinationRule 可用于启动外部服务的 双向 TLS 连接:

    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: foo-ext
    spec:
      name: foo.com
      trafficPolicy:
        tls:
          mode: MUTUAL
          clientCertificate: /etc/certs/myclientcert.pem
          privateKey: /etc/certs/client_private_key.pem
          caCertificates: /etc/certs/rootcacerts.pem
    

    istio例子###

    所有服务都是通过一个边缘代理(istio自己提供ingressgateway),根据不同的域名转发到不同的服务.现在给出两个例子.

    服务service-dev的配置:

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: service-dev-gateway
      namespace: im
    spec:
      selector:
        istio: ingressgateway # use istio default controller
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:
        - service-dev.com
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: service-dev-vs
      namespace: im
    spec:
      hosts:
      - service-dev.com
      gateways:
      - service-dev-gateway
      http:
      - route:
        - destination:
            host: service-dev.im.svc.cluster.local
            subset: v1
        retries:
          attempts: 3
          perTryTimeout: 100ms
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: service-dev-dr
      namespace: im
    spec:
      host: service-dev.im.svc.cluster.local
      subsets:
      - name: v1
        labels:
          version: v1
      trafficPolicy:
        outlierDetection:
          consecutiveErrors: 6
          interval: 1m
          baseEjectionTime: 30s
          maxEjectionPercent: 80
    

    服务service-deny的配置:

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: service-deny-gateway
      namespace: im
    spec:
      selector:
        istio: ingressgateway # use istio default controller
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:
        - service-deny.com
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: service-deny-vs
      namespace: im
    spec:
      hosts:
      - service-deny.com
      gateways:
      - service-deny-gateway
      http:
      - route:
        - destination:
            host: service-deny.im.svc.cluster.local
            subset: v1
        retries:
          attempts: 3
          perTryTimeout: 100ms
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: service-deny-dr
      namespace: im
    spec:
      host: service-deny.im.svc.cluster.local
      subsets:
      - name: v1
        labels:
          version: v1
      trafficPolicy:
        outlierDetection:
          consecutiveErrors: 6
          interval: 1m
          baseEjectionTime: 30s
          maxEjectionPercent: 80
    

    上面两配置中: 都是配置各自一个gateway,定义特定的hosts.然后配置一个virtualservice绑定特定的gateway,指定的host根据指定的路由规则,路由到desinationrule.desinationrule查找host为service-dev(service-deny)并且标签为version: v1的服务.trafficPolicy是熔断处理,间隔1分钟内出现6次错误,把上游服务下线30S.下线的服务不能超过总的80%.

  • 相关阅读:
    jetcache 二级缓存使用
    hutool-crypto 依赖 Aes加密,解密
    springboot下的logback-spring配置文件以及使用方式
    docker 实现多个端口映射
    zookeeper部署启动异常,8080端口被占用。
    docker tomcat 文件传递
    关于注解AOP,基于类和方法的实现
    idea 创建file找不到java文件时....
    idea 将项目代码提交到github中
    java第八天---多态、抽象、接口
  • 原文地址:https://www.cnblogs.com/mathli/p/10056130.html
Copyright © 2020-2023  润新知