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

Istio Canary TCP service support #1564

Merged
merged 1 commit into from
Feb 7, 2024
Merged

Conversation

kubroid
Copy link
Contributor

@kubroid kubroid commented Dec 7, 2023

This PR is a response to the feature requested in #1556

The changes contained in the PR only add support for TCP Canary deployments if the user has configured Flagger to use the istio meshProvider.
When the user deploys their Canary document, Flagger will check if the Canary.service.appProtocol key has been set to TCP (case insensitive).

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
...
spec:
...
  service:
    appProtocol: tcp
...

If the value equals TCP then it will deploy the VirtualService document with a tcp section (instead of the default http section that it uses now without this feature). After the VirtualService document is deployed it will look similar to the below example:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
   name: tcp-service
  namespace: test
  ownerReferences:
  - apiVersion: flagger.app/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: Canary
    name: tcp-service
spec:
  gateways:
  - istio-ingress/tcp-service-gateway
  hosts:
  - '*'
  tcp:
  - route:
    - destination:
        host: tcp-service-primary
        port:
          number: 7070
      weight: 100
    - destination:
        host: tcp-service-canary
        port:
          number: 7070
      weight: 0

Notice the tcp section. Once the Canary switches to Progressing phase Flagger will be able to adjust the weight keys as expected during the evaluation period. Once completed, Flagger can promote the canary to the primary as expected. Likewise, if the canary fails the analysis, it will go into an error state just like it does normally.

If the user doesn't set the Canary.service.appProtocol key or they set it to anything other than TCP (like http) the Canary will be treated as it is now (without these changes) and Flagger will deploy the VirtualService document with the http section and it will also be able to update the weights as it normally does during canary deployments.

Closes: #1556

@stefanprodan
Copy link
Member

@kubroid can you please rebase with main and force push so that tests are run in CI.

Signed-off-by: Alexey Kubrinsky <akubrinsky@zetaglobal.com>
@codecov-commenter
Copy link

Codecov Report

Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (0a21699) 55.19% compared to head (4932527) 56.64%.
Report is 2 commits behind head on main.

Files Patch % Lines
pkg/router/istio.go 92.30% 3 Missing and 2 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1564      +/-   ##
==========================================
+ Coverage   55.19%   56.64%   +1.45%     
==========================================
  Files          85       85              
  Lines       10643     8543    -2100     
==========================================
- Hits         5874     4839    -1035     
+ Misses       4100     3033    -1067     
- Partials      669      671       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@stefanprodan stefanprodan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Thanks @kubroid 🎖️

@stefanprodan stefanprodan merged commit af1e210 into fluxcd:main Feb 7, 2024
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Feature request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for TCP Canary Deployments
3 participants