profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/l8huang/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

l8huang/cocos2d-x 0

cocos2d-x for C++

l8huang/community 0

Istio governance material.

l8huang/envoy 0

Cloud-native high-performance edge/middle/service proxy

l8huang/freegemas 0

Automatically exported from code.google.com/p/freegemas

l8huang/grpc 0

The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#)

l8huang/HoudiniEngineForUnreal 0

Houdini Engine Plugin for Unreal Engine 4

l8huang/istio 0

Connect, secure, control, and observe services.

pull request commentistio/api

Support Envoy Native Subset Load Balancing[WIP]

Can you write a proposal first?

see RFC: Support Envoy Native Subset Load Balancing

l8huang

comment created time in a month

issue commentistio/istio

Support Envoy Native Subset Load Balancing

That can be specified in DR along with subsets. When this is specified, Istio can look at pod lables and match with the label names given here and create a new subset for each unique combination. The subset name can be derived from value of labels i.e. value_1.value_2.value3 so that it becomes unique.

Looks like Istio need to generated different clusters for different value of labels. This could cause scalability issue for large cluster, and it's overkill if the use case is accessing single endpoint in a EDS cluster which has 1k endpoints, because 1k subsets(clusters) will be created.

l8huang

comment created time in a month

issue commentistio/istio

Support Envoy Native Subset Load Balancing

RFC: Support Envoy Native Subset Load Balancing is created(don't have permission to move it to istio community drive for now, trying to do so).

Istio API change is in PR https://github.com/istio/api/pull/2082.

@ramaraochavali PTAL

l8huang

comment created time in a month

PR opened istio/api

Support Envoy Native Subset Load Balancing

This PR include changes to VirtualService and DestinationRule for supporting Envoy native subset load balancing.

design doc link will be added after it's moved into istio community drive.

+8683 -761

0 comment

27 changed files

pr created time in a month

issue commentistio/istio

Support Envoy Native Subset Load Balancing

@ramaraochavali I'm glad that it could be useful, I will create a design doc for review.

l8huang

comment created time in a month

create barnchl8huang/istio-api

branch : api-vs-dr

created branch time in 2 months

issue commentistio/istio

Support Envoy Native Subset Load Balancing

Yes, when subsetlb is enabled for a cluster, EDS size will be increased because adding endpoint IP in metadata, but considering EDS are sharded, this should be ok(this will be verified by LnP test).

Glad to know there are similar use case. Please kindly let me know If this feature request makes sense, I'm willing to submit a design doc if this feature is substantial enough; otherwise, I guess I can begin with an api PR for updating VirtualService and DestinationRule.

l8huang

comment created time in 3 months

issue openedistio/istio

Support Envoy Native Subset Load Balancing

Objective

Support routing HTTP request to a specific backend endpoint through ingress gateway. In our use case, there are some existing tools that monitor k8s Pods. After moving k8s Pods into mesh and Istio mutual TLS being enabled, these tools can’t access Pod anymore and they can’t be run in mesh. The problem can be resolved by making these tools send requests to ingress gateway and routing the request to the specified endpoint.

Replacing current DestinationRule Subset implementation with Envoy subset load balancing is not the goal of this feature request.

Background

Currently Istio generates one Envoy cluster for each subset defined in DestinationRule, backend endpoints are grouped into subset by labels. For using subset, labels are defined in Deployment/Pod spec, subsets are defined in DestinationRule, and route rules are defined in VirtualService, basically everything is defined statically.

It’s not practical to use the DestinationRule subset to route requests to any single specified endpoint without updating DestinationRule/VirtualService spec. If a service has a lot of endpoints(e.g. >1000), the size of RDS/CDS/EDS config will increase dramatically.

Requirements

In our use case, client needs to send HTTP requests to a specific endpoint of a service through ingress gateway, the destination endpoint can be specified by a HTTP header. This feature can be enabled for specific virtual hosts or route, e.g. only allowed for host foo.example.com for URI path `/foo’. When a new Pod is created or deleted, there is no need to update DestinationRule/VirtualService for adding new subset/route rule or clean up old subset/route rule.

Design Ideas

Envoy’s Subset Load Balancing comes in handy for this use case, endpoint can be generated with metadata in namespace envoy.lb, then Envoy Header-To-metadata filter can be used to transform header into metadata in namespace envoy.lb. In this way, the destination endpoint can be selected through a header, no need to update DestinationRule/VirtualService.

In our use case, an endpoint’s IP address can be used as metadata to select the endpoint. For adding its IP address as a metadata, a replacement pattern %ENDPOINT_IP% can be used, the DestinationRule spec could be:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
spec:
  subsetLB: # Envoy subset LB config
    metadata:
        endpoint-ip: %ENDPOINT_IP%  # in metadata namespace `envoy.lb` 
    fallbackPolicy: NO_FALLBACK
  subsets:
  - name: v1
    subsetLB: # this can also be applied to DestinationRule Subset
      metadata:
          endpoint-ip: %ENDPOINT_IP% 
      fallbackPolicy: NO_FALLBACK

The generated endpoint config will be:

{
    "endpoint": {
        "address": {
            "socket_address": {
                "address": "192.168.0.100",
                "port_value": 8080
            }
        }
    },
    "metadata": {
        "filter_metadata": {
...
            "envoy.lb": {
                "endpoint-ip": "192.168.0.100"
            }
        }
    },
...
}

The corresponding subset LB config in Envoy Cluster should be:

{
    "cluster": {
 ...
        "lb_subset_config": {
            "subset_selectors": [
                {
                    "keys": [
                        "endpoint-ip"
                    ],
                    "single_host_per_subset": true
                }
            ]
        }
    }
}

A sample VirtualService for adding metadata to HTTP requests match /foo could be:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
...
spec:
  hosts:
  - foo.example.com
  http:
  - match:
    - uri:
        prefix: "/foo"
      headers:
        request:
...
          subsetLb:  # transform header into metadata namespace `envoy.lb` 
          - header: destination-endpoint 
            on_header_present:# same as header_to_metadata KeyValuePair,
                              # but no metadata_namespac field, so user
                              # can’t add metadata to other namespace
              key: endpoint-ip
              type: STRING
            remove: false
...

The generated Header-To-Metadata filter config will be :

route_config:
  virtual_hosts:
  - domains:
    - "foo.example.com"
    routes:
    - match:
        prefix: "/foo"
      typed_per_filter_config:
        envoy.filters.http.header_to_metadata:
          "@type": "type.googleapis.com/envoy.extensions.filters.http.header_to_metadata.v3.Config"
          request_rules:
          - header: instance
            on_header_present:
              metadata_namespace: envoy.lb
              key: instance
              type: STRING
            remove: false

Affected product area (please put an X in all that apply)

[ ] Docs [ ] Installation [x] Networking [ ] Performance and Scalability [ ] Extensions and Telemetry [ ] Security [ ] Test and Release [ ] User Experience [ ] Developer Infrastructure

Affected features (please put an X in all that apply)

[ ] Multi Cluster [ ] Virtual Machine [ ] Multi Control Plane

Additional context

created time in 3 months

issue closedistio/istio

Support Pod enpoint's weight setting

WorkloadEntry provides a way to set non-Pod endpoint's weight:

apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
  name: foo
spec:
  address: 192.168.0.1
  weight: 8080
  labels:
    app: foo

As https://istio.io/latest/blog/2020/workload-entry/ said:

Notice that the ServiceEntry can reference both Pods and WorkloadEntries, using the same selector. VMs and Pods can now be treated identically by Istio, rather than being kept separate.

But when we use a ServiceEntry to reference both Pods and WorkloadEntries, and want to do traffic splitting by setting weight, currently Pod endpoint's weight can't be specified, the generated Envoy endpoint's wight is 1:

          {
           "endpoint": {
            "address": {
             "socket_address": {
              "address": "192.168.0.100",
              "port_value": 8080
             }
            }
           },
           "load_balancing_weight": 1
          },

For making the traffic splitting case works, Istio should support Pod endpoint weight setting.

This case was mentioned in another issue's comment:

For this, workloadentry allows setting weight, but i donot think we can do that for a pod. If we do have the use case, we can provide a way to do that.

Originally posted by @hzxuzhonghu in https://github.com/istio/istio/issues/25898#issuecomment-676206810

Affected product area (please put an X in all that apply)

[ ] Docs [ ] Installation [x] Networking [ ] Performance and Scalability [ ] Extensions and Telemetry [ ] Security [ ] Test and Release [ ] User Experience [ ] Developer Infrastructure

Affected features (please put an X in all that apply)

[ ] Multi Cluster [ ] Virtual Machine [ ] Multi Control Plane

closed time in 3 months

l8huang

issue closedistio/istio

Support delta_grpc ADS API

Describe the feature request

Envoy is going to support DELTA_GRPC. For Istio, I wonder if DELTA_GRPC is in road-map.

We encountered scalability issue with 5k RouteConfig and 20k ClusterConfig, that caused us withdrawing traffic migration to Istio ingress gateway. Looks like such kind of scalability issue can be resolved by using DELTA_GRPC, so we are looking for working on it, please kindly let me know if any one already working on it, so we can avoid overlapped effort or collaborate.

[X ] Performance and Scalability

closed time in 3 months

l8huang

push eventl8huang/community

Lei Huang

commit sha c60463820b37199218c43b889052ab539c544ecc

add l8huang to member list

view details

push time in 3 months

PR opened istio/community

add lhuang8 to member list

The most common reason to send a PR to this repository is to join the Istio org. If you are joining, please fill out this template. If you are not, please delete all the below.

List your company name, or indicate Individual if you're not affiliated with a company: eBay

Provide a link to at least one PR that you have successfully pushed to one of the Istio repos: istio/istio#31644 istio/istio#30383

+1 -0

0 comment

1 changed file

pr created time in 3 months

push eventl8huang/community

lhuang8

commit sha 6aba076f8fad088fcc15e9ba9d0cd12fdc3d3c90

add lhuang8 to member list

view details

push time in 3 months

create barnchl8huang/community

branch : add-member

created branch time in 3 months

fork l8huang/community

Istio governance material.

https://istio.io/community

fork in 3 months