How can Kyma support gradual rollout ( blue / green) deployments?

[abbi-gaurav]

Problem

As a developer, I do not have a clear and easy way to make rollout changes in a gradual manner with minimal blast radius (e.g. blue-green) deployments on Kyma. The current K8S / Istio semantics are either too complex or resource intensive and does not not work with API rules. I would expect Kyma to provide a simple abstraction to use it. I am not looking for an OOTB blue-green / canary support. I am asking for features that can help me implement it

Ref: https://github.tools.sap/kyma/backlog/issues/963

• Help customers to roll out their features in a stable manner
• Enable customers to improve the stability of SAP Software built on Kyma

Reasons

[2026-01-19]

• Kyma provide API rule as an abstraction. It is currently not possible to do canary, blue-green or gradual rollout when using API rule
• This leads the customers who wish to do canary, blue-green or gradual rollout to not use API rule and we would like to avoid it.

Attachments

What is currently possible?

• What capabilities Istio offer?
  • Istio offers traffic distribution with various semantics such as percentages, based on headers
  • Kyma API rule need to leverage those and expose them as features.

What would be the Kyma scope?

[2026-01-19]

• The goal is not to provide canary, blue-green or gradual rollout as a Kyma feature.
• It is to ensure that the abstractions provided by Kyma (API Rule) can support tools such as DwC, Jenkins or any other automation to implement canary, blue-green or gradual rollout.

What about unified gateway / DwC?

• UGW / DwC as well as other automation tooling can leverage the features provided by API rule to to implement canary, blue-green or gradual rollout

[2026-01-14]

• A possible idea was presented to architects and goats.
• They are ok with the proposed enrichment of the API rule

TODOs

• Add the details to description based on discussions so far
• Get feedback from stakeholders

[abbi-gaurav]

• Using plain Kubernetes semantics is costly and in-efficient.
  • e.g. for 5% traffic to canary, I will need a replica ratio of 1:20
• The proposed trafficDistribution: field can then be enhanced further to have more intelligent traffic splitting.
  • e.g. based on headers. This could be useful for targeted testing
• The API enhancement must be backward compatible.
  • So that if a customer does not specify trafficDistribution:, it must behave as previous versions

Istio offers traffic splitting via Virtual Service and destination rule:
We can consider enhancing API rule to incorporate these features.
Here is one proposed change to API Rule spec:

apiVersion: gateway.kyma-project.io/v2
kind: APIRule
metadata:
  name: canary-concept
spec:
  gateway: kyma-system/kyma-gateway
  hosts:
  - some-api
  rules:
  - methods:
    - GET
    - POST
    - PUT
    - PATCH
    - DELETE
    - HEAD
    - OPTIONS
    noAuth: true
    path: /*
    service:
      name: nginx
      namespace: default
      port: 80
      trafficDistribution: #new field
      - name: stable
        labels:
          version: v1 #labels on pod
          weight: 95
      - name: canary
        labels:
          version: v2 #labels on pod
          weight: 5

API Gateway will generate the following istio resources:

---
# generated virtualservice
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: canary-concept-hdhhdbv
spec:
  # Apply to traffic destined for the myapp service
  hosts:
  - some-api.kyma.domain
  http:
  - match:
    - uri:
        prefix: /
      method:
        regex: ^(GET|POST|PUT|PATCH|DELETE|HEAD|OPTIONS)$
    name: canary-concept
    # Traffic splitting configuration
    route:
    - destination:
        host: nginx
        # Route to stable subset (v1 pods)
        subset: stable
      # 95% of traffic goes to stable
      weight: 95
    - destination:
        host: nginx
        # Route to canary subset (v2 pods)
        subset: canary
      # 5% of traffic goes to canary
      weight: 5
---
# generated destinationrule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: canary-concept-hdhhdbv
spec:
  # Host matches the Kubernetes service name
  host: nginx.default.svc.cluster.local
  # Define subsets based on version labels
  subsets:
  - name: stable
    labels:
      # Matches pods with version: v1 label
      version: v1
  - name: canary
    labels:
      # Matches pods with version: v2 label
      version: v2

[abbi-gaurav]

Using plain Kubernetes semantics is costly and in-efficient.
e.g. for 5% traffic to canary, I will need a replica ratio of 1:20

[abbi-gaurav]

The proposed trafficDistribution: field can then be enhanced further to have more intelligent traffic splitting.
e.g. based on headers. This could be useful for targeted testing

[abbi-gaurav]

The API enhancement must be backward compatible.

So that if a customer does not specify trafficDistribution:, it must behave as previous versions

[marco-porru]

Solving the problem of multiple versions (blue/green deployments) is a clear target of DwC.
If someone would like to do blue/green should use DwC.
We should close this ticket. If anything is missing in DwC please report them.

[abbi-gaurav]

Solving the problem of multiple versions (blue/green deployments) is a clear target of DwC. If someone would like to do blue/green should use DwC. We should close this ticket. If anything is missing in DwC please report them.

@marco-porru, The problem is not about who should do blue-green deployment. The problem is that current Kyma API rule semantics do not support toolings on top such as DwC and others to do blue green / gradual rollout or canary releases.
The quetion is and as described in original description what Kyma can do so tools such as DwC and other users can implement Blue green when using API rule.

[marco-porru]

Feedback from DwC:

Hi Marco, DwC is not using the Kyma-specific APIRule CR. Instead we are implementing the progressive delivery functionality in the DwC control plane itself. I don't see the necessity to implement this feature. In my personal perspective and a non-DwC user I would see this feature-request as understandable and beneficial

[abbi-gaurav]

Feedback from DwC:

Hi Marco, DwC is not using the Kyma-specific APIRule CR. Instead we are implementing the progressive delivery functionality in the DwC control plane itself. I don't see the necessity to implement this feature. In my personal perspective and a non-DwC user I would see this feature-request as understandable and beneficial

Thanks @marco-porru , DwC at present does not use API rule and not all internal teams use DwC.
So can we conclude if it is a problem worth solving or do we need to have the messaging to always use DwC.

[marco-porru]

Feedback from DwC:

Hi Marco, DwC is not using the Kyma-specific APIRule CR. Instead we are implementing the progressive delivery functionality in the DwC control plane itself. I don't see the necessity to implement this feature. In my personal perspective and a non-DwC user I would see this feature-request as understandable and beneficial

Thanks @marco-porru , DwC at present does not use API rule and not all internal teams use DwC. So can we conclude if it is a problem worth solving or do we need to have the messaging to always use DwC.

Agree. It was exactly my comment as well. I think I already provided my opinion :-)