Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add schema for subsets to DestinationRule & VirtualService #1433

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

S-mishina
Copy link
Contributor

@S-mishina S-mishina commented May 18, 2023

Purpose

To enable determining the threshold for circuit breaker on a client basis using the virtual service and destination rule generated by Flagger.

Desired Outcome

  • Virtual Service
----Partial excerpt-----
  http:
  - name: hoge1
    route:
      - destination:
          host: hoge-api-primary
          subset: hogehoge
        weight: 100
      - destination:
          host: hoge-api-canary
          subset: hogehoge
        weight: 0
      timeout: 10s
  - name: hoge2
    route:
      - destination:
          host: hoge-api-primary
          subset: hogehoge1
        weight: 100
      - destination:
          host: hoge-api-canary
          subset: hogehoge1
        weight: 0
      timeout: 10s
  • Destination Rule
----Partial excerpt-----
  subsets:
  - name: hogehoge
    trafficPolicy:
      outlierDetection:
        consecutive5xxErrors: 360
        interval: 3m
        baseEjectionTime: 30s
        maxEjectionPercent: 100
  - name: hogehoge1

The above manifests are what I want to generate with Flagger.

Changes Made

  • To determine the threshold on a client basis, it was necessary to define VS and DR settings by name. However, it was not possible to define a name in the current Flagger's Canary resource interface. Therefore, I created a new interface.
  • Using the newly created interface, I modified the generation of VS and DR.
  • I made modifications to Flagger to ensure that it still works with the existing interface (without name separation).
    • Added processing to adopt the previous interface if canary.spec.service.httpname is not defined.
      Existing interface:
      • canary.Spec.Service.Match
      • canary.Spec.Service.Rewrite
      • canary.Spec.Service.Timeout
      • canary.Spec.Service.Retries
      • canary.Spec.Service.CorsPolicy
      • canary.Spec.Service.Headers

Note: If both are defined, canary.spec.service.httpname takes precedence.

Testing Method

  • Verify that Flagger functions correctly by setting it up locally.

I hope this meets your requirements! Let me know if there's anything else I can assist you with.

Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
…in Istio Virtual Service

Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
@S-mishina S-mishina changed the title Add schema for subsets to destination rule Add schema for subsets to DestinationRule & VirtualService May 21, 2023
Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
Signed-off-by: S-mishina <seiryu.mishina@zozo.com>
@S-mishina
Copy link
Contributor Author

@stefanprodan

Thank you as always.
I want you to see this.

@stefanprodan
Copy link
Member

Given that Istio is moving to Gateway API, how are you going to do this type of config there?

@S-mishina
Copy link
Contributor Author

S-mishina commented Apr 11, 2024

@stefanprodan

Thanks for confirming!

Given that Istio is moving to the Gateway API, how should I configure it there?

Currently, I do not believe this can be done with the Gateway API. The detailed reasons are written below.

The Gateway API does not currently fully support the Istio API features (virtualservice and destinationrule), and the official Istio documentation also states that if that feature is not provided by HttpRoute, the virtualservice to realize it if the function is not provided by HttpRoute.

Also, Istio's documentation states that they will migrate to the Gateway API, but will support the Istio API at the same time for a while after migrating to the Gateway API.

Therefore, my team is not considering migrating until the Gateway API has the same functionality as the Istio API.

Flagger's feature of progressive delivery (weight switching) seems to be supported by the current Gateway API, but until the Gateway API is fully functional, it would be great if you could support both Gateway and Istio API patterns! I am still waiting for the Gateway API to be fully functional!

I may not fully understand the functionality of the Gateway API yet!

Sorry if I am wrong!

Once again, what I would like to achieve is.

  • The ability to set a timeout per client.
  • Ability to set trafficPolicy.outlierDetection by path or grouping per client.
    • match.uri
    • much.sourceLabels
      • Istio API example

If you can achieve the above, please let us consult with you as we are not particular about this PR method!

@S-mishina
Copy link
Contributor Author

PS:

Given that Istio is moving to the Gateway API, how should I set it up there?

If you simply want to change the timeout per application with the Gateway API, that is possible.
If you simply want to change the timeout per application using the Gateway API, In this PR example,
It might be better to generate an HttpRoute with name, namespace, and timeout in canary.spec.service.httpname.

However, currently there are many things that cannot be achieved with HttpRoute, so we would like to use virtualservice to achieve this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants