Skip to content

Commit

Permalink
fix proposal of delivery according to review
Browse files Browse the repository at this point in the history 
Signed-off-by: LiZhenCheng9527 <[email protected]>
  • Loading branch information
@LiZhenCheng9527
LiZhenCheng9527 committed Nov 29, 2023
1 parent 31085fe commit ea1cdda
Showing 1 changed file with 99 additions and 120 deletions.
219 changes: 99 additions & 120 deletions docs/proposals/kuratorcd/kurator-cd.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -26,13 +26,11 @@ documentation such as release notes or a development roadmap.
A good summary is probably at least a paragraph in length.
-->

Kurator, as an open-source distributed cloud-native platform, has been pivotal in aiding users to construct their distributed cloud-native infrastructure, thereby facilitating enterprise digital transformation.

To further enhance its functionality, this proposal designs Kurator's Continuous Delivery feature to meet users' needs for automated distribution of verified code.
To further enhance Kurator's functionality, this proposal designs Kurator's Continuous Delivery feature to meet user's need for automated distribution of verified code.

By integrating Flagger, we aim to provide users with reliable, fast and unified Continuous Delivery, enabling them to easily distribute code across multiple clusters.

Base on Flagger, Kurator also offers A/B, Blue/Green and Canary distribution options. Meet the needs of the test verification release.
Base on Flagger, Kurator also offers A/B, Blue/Green and Canary distribution options. Meet the needs of the Continuous Delivery.

### Motivation

Expand Down Expand Up @@ -74,7 +72,7 @@ What is out of scope for this KEP? Listing non-goals helps to focus discussion
and make progress.
-->

- **Traffic distribution tools that Flagger can use other than istio are not supported** While Flagger is able to support a wide range of traffic distribution tools including istio, nginx for grey scale releases. However, Kuraotr currently only supports unified installation of istio in multiple clusters, and Kurator may implement unified installation of other traffic distribution tools in the future.
- **Traffic distribution tools other than istio are not supported** While Flagger is able to support a wide range of traffic distribution tools including istio, nginx for grey scale releases. However, Kurator currently only supports unified management of istio across clusters. Kurator may implement other traffic distribution tools in the future.

### Proposal

Expand All @@ -86,11 +84,11 @@ implementation. What is the desired outcome and how do we measure success?.
The "Design Details" section below is for the real
nitty-gritty.
-->
The purpose of this proposal is to introduce a unified Continuous Delivery for Kurator that supports A/B, Blue/Green, and Canary.The main objectives of this proposal are as follows:
The purpose of this proposal is to introduce a unified Continuous Delivery for Kurator that supports A/B, Blue Green, and Canary.The main objectives of this proposal are as follows:

Custom Resource Definitions (CRDs): Design CRDs to enable Uniform Continuous Delivery These CRDs will provide a structured approach to defining clusters and different configuration distribution rules to enable uniform configuration distribution.
Application Programming Interface (API): Design API to enable Uniform Continuous Delivery. Provide an API interface for defining configuration distribution rules for unified configuration distribution by extending the fields of application.

Fleet-Manager Implementation: The Cluster Manager component will be responsible for monitoring the CRDs and performing the defined functions. It will install Flagger on the clusters and handle potential errors or anomalies to ensure smooth operation.
Delivery Engine: The Delivery Engine is responsible for monitoring what is going on in the Application CRDs in the cluster and performing defined functions.

By integrating these enhancements, Kurator will provide users with a powerful and streamlined solution for managing the task of implementing Unified Configuration Distribution and simplifying the overall operational process.

Expand Down Expand Up @@ -193,61 +191,53 @@ type ApplicationSyncPolicy struct {
// +optional
Destination *ApplicationDestination `json:"destination"`

// Delivery defines the Continuous Delivery Configurations to be used.
// Rollout defines the rollout Configurations to be used.
// If specified, a uniform Continuous Delivery policy is configured for this installed object.
// +optional
Delivery *DeliveryConfig `json:"deliveryPolicy"`
Rollout *RolloutConfig `json:"rolloutPolicy,omitempty"`
}

type DeliveryConfig struct {
// Autoscale defines minreplicas and maxreplicas of horizontal Pod Autoscaler.
type RolloutConfig struct {
// Whether to install teseload for users. Default is true
// If set it to false, user need to install the testload himself.
// If set it to true or leave it blank, Kurator will install the flagger's testload.
// +optional
Autoscale *AutoscaleRef `json:"autoScale,omitempty"`
TestLoad bool `json:"testLoad,omitempty"`

// Whether or not the testload is installed by the user. The default is false.
// If set it to ture, user need to install the testload himself.
// If set it to false or leave it blank, Kurator will install the flagger's testload.
// Kurator only supports istio for now.
// New Provider will be added later.
// +optional
TestLoad bool `json:"testLoad"`

// DeliveryPolicy defines the Release Strategy of Object
DeliveryPolicy *DeliveryPolicy `json:"deliveryPolicy"`
}
```
TrafficRoutingProvider string `json:"trafficRoutingProvider,omitempty"`

Kurator generates horizontalpodautoscaler.autoscaling resources based on `autoscale` configurations as stable and to-be-verified versions. For instance tuning during testing
// Targetworkload specifies what workload to deploy the test to.
// Workload of type deployment or daemonSet.
TargetWorkload *TargetWorkloadReference `json:"targetWorkload"`

```concle
type AutoscaleRef struct {
// Primary is the metadata to add to the primary service.
// +optional
MinReplicas *int32 `json:"minReplicas,omitempty"`
Primary *CustomMetadata `json:"primary,omitempty"`

// Canary is the metadata to add to the canary service.
// +optional
MaxReplicas *int32 `json:"maxReplicas,omitempty"`
Canary *CustomMetadata `json:"canary,omitempty"`

// RolloutPolicy defines the Release Strategy of workload.
RolloutPolicy *RolloutPolicy `json:"rolloutPolicy"`
}
```

`Testload` indicates whether the user wants to install the test traffic load themselves. If you don't want to install the testload yourself, Kurator will install flagger's testload by default.

`DeliveryPolicy` defines the Continuous Delivery configuration for this installation object. Although in Kurator is not detailed into the canary release, A/B test and blue-green test. However, users can freely configure their own traffic validation policies through the DeliveryPolicy. Complete the release test.
`RolloutPolicy` defines the Continuous Delivery configuration for this installation workload. Although in Kurator is not detailed into the canary release, A/B test and blue-green test. However, users can freely configure their own traffic validation policies through the DeliveryPolicy. Complete the release test.

```console
// Note: refer to https://github.com/fluxcd/flagger/blob/main/pkg/apis/flagger/v1beta1/canary.go
type DeliveryPolicy struct {
// Kurator only supports istio for now.
// New Provider will be added later.
// +optional
TrafficRoutingProvider string `json:"trafficRoutingProvider,omitempty"`

// TargetObject specifies what object to deploy the test to.
// Objects of type deployment or daemonSet.
TargetObject *TargetObjectReference `json:"targetObject"`
type RolloutPolicy struct {
// Service is the configuration of the service pointing to the TargetObject.
Service *ServiceConfig `json:"service"`

// ServiceCfg is the configuration of the service pointing to the TargetObject.
ServiceCfg *ServiceConfig `json:"serviceCfg"`

// The virtualserviceCfg defines the configuration of the gateway, traffic distribution rules, and so on.
VirtualServiceCfg *VirtualServiceConfig `json:"virtualServiceCfg"`
// The TrafficRouting defines the configuration of the gateway, traffic distribution rules, and so on.
TrafficRouting *TrafficRoutingConfig `json:"trafficRouting"`

// TrafficAnalysis defines the validation process of a release
TrafficAnalysis *TrafficAnalysis `json:"trafficAnalysis,omitempty"`
Expand Down Expand Up @@ -280,7 +270,7 @@ TargetObjectReference contains enough information to let you locate the typed re

```concole
// Note: refer to https://github.com/fluxcd/flagger/blob/main/pkg/apis/flagger/v1beta1/canary.go
type TargetObjectReference struct {
type TargetWorkloadReference struct {
// API version of the referent
// +optional
APIVersion string `json:"apiVersion,omitempty"`
Expand All @@ -294,13 +284,13 @@ type TargetObjectReference struct {
}
```

The ServiceConfig is the configuration of the service that is generated according to the object specified in the TargetObject. The main thing is to specify the `Port` and `targetPort`.
The ServiceConfig is the configuration of the service that is generated according to the TargetWorkload. The main thing is to specify the `Port` and `targetPort`.

```console
// Note: refer to https://github.com/fluxcd/flagger/blob/main/pkg/apis/flagger/v1beta1/canary.go
type ServiceConfig struct {
// Name of the virtual Kubernetes generated by Flagger.
// Defaults to DeliveryPolicy.TargetObject.Name
// Name of the Kubernetes service generated by Kurator.
// Defaults to RolloutPolicy.TargetWorkload.Name
// +optional
Name string `json:"name,omitempty"`

Expand All @@ -313,26 +303,22 @@ type ServiceConfig struct {
PortName string `json:"portName,omitempty"`

// Target port number or name of the generated Kubernetes service.
// Defaults to CanaryService.Port
// Defaults to ServiceConfig.Port
// +optional
TargetPort intstr.IntOrString `json:"targetPort,omitempty"`

// AppProtocol of the service.
// https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol
// +optional
AppProtocol string `json:"appProtocol,omitempty"`

// PortDiscovery adds all container ports to the generated Kubernetes service.
// Defaults to true
PortDiscovery bool `json:"portDiscovery"`
}
```

Kurator will create a VirtualService resource based on the configuration in `VirtualServiceConfig` to distribute traffic.

```console
// Note: refer to https://github.com/fluxcd/flagger/blob/main/pkg/apis/flagger/v1beta1/canary.go
type VirtualServiceConfig struct {
type TrafficRoutingConfig struct {
// Timeout of the HTTP or gRPC request.
// +optional
Timeout string `json:"timeout,omitempty"`
Expand All @@ -342,60 +328,22 @@ type VirtualServiceConfig struct {
// +optional
Gateways []string `json:"gateways,omitempty"`

// Hosts attached to the generated Istio virtual service.
// Defaults to the service name
// +optional
Hosts []string `json:"hosts,omitempty"`

// If enabled, Flagger would generate Istio VirtualServices without hosts and gateway,
// If delegation enabled, Flagger would generate Istio VirtualServices without hosts and gateway,
// making the service compatible with Istio delegation.
// If delegation is enabled, Flagger makes the service compatible with Istio delegation,
// enabling configuration of traffic within the cluster
// Note that pilot env `PILOT_ENABLE_VIRTUAL_SERVICE_DELEGATE` must also be set.
// +optional
Delegation bool `json:"delegation,omitempty"`

// TrafficPolicy attached to the generated Istio destination rules.
// +optional
TrafficPolicy *istiov1alpha3.TrafficPolicy `json:"trafficPolicy,omitempty"`

// URI match conditions for the generated service.
// +optional
Match []istiov1alpha3.HTTPMatchRequest `json:"match,omitempty"`

// Retries policy for the generated virtual service.
// +optional
Retries *istiov1alpha3.HTTPRetry `json:"retries,omitempty"`

// Headers operations for the generated Istio virtual service.
// e.g.
// headers:
// request:
// add:
// x-some-header: "value"
// +optional
Headers *istiov1alpha3.Headers `json:"headers,omitempty"`

// Cross-Origin Resource Sharing policy for the generated Istio virtual service.
// e.g.
// corsPolicy:
// allowHeaders:
// - x-some-header
// allowMethods:
// - GET
// allowOrigin:
// - example.com
// maxAge: 24h
// +optional
CorsPolicy *istiov1alpha3.CorsPolicy `json:"corsPolicy,omitempty"`
// Mirror defines parameters for Mirror .
Mirror MirrorConfig `json:"mirror,omitempty"

// Primary is the metadata to add to the primary service.
// +optional
Primary *CustomMetadata `json:"primary,omitempty"`
// CanaryStrategy defines parameters for Canary deployment
CanaryStrategy CanaryConfig `json:"canaryStrategy,omitempty"

// Canary is the metadata to add to the canary service.
// +optional
Canary *CustomMetadata `json:"canary,omitempty"`
// TestingStrategy defines parameters for Blue Green or A/B deployment
TestingStrategy TestingConfig `json:"testingStrategy,omitempty"
}
```

Expand All @@ -407,18 +355,37 @@ type TrafficAnalysis struct {
// Schedule interval for this traffic analysis
Interval string `json:"interval"`
// Number of checks to run for A/B Testing and Blue/Green
// Max number of failed checks before the traffic analysis is terminated
Threshold int `json:"threshold"`
// Metric check list for this traffic analysis
// Flagger comes with two builtin metric checks: HTTP request success rate and duration.
// Can use either built-in metric checks or custom checks.
// If you want use custom checks, you can refer to https://docs.flagger.app/usage/metrics#custom-metrics.
// +optional
Iterations int `json:"iterations,omitempty"`
Metrics []Metric `json:"metrics,omitempty"`
// Webhook list for this traffic analysis
// +optional
Webhooks []Webhook `json:"webhooks,omitempty"`
// SessionAffinity represents the session affinity settings for a analysis run.
// +optional
SessionAffinity *SessionAffinity `json:"sessionAffinity,omitempty"`
}
// Setting up mirror traffic for a new version of workload.
type MirrorConfig struct {
// Enable traffic mirroring for Blue/Green
// +optional
Mirror bool `json:"mirror,omitempty"`
// Weight of the traffic to be mirrored in the range of [0, 100].
// +optional
MirrorWeight int `json:"mirrorWeight,omitempty"`
}
type CanaryConfig struct {
// Max traffic weight routed to canary test
// +optional
MaxWeight int `json:"maxWeight,omitempty"`
Expand All @@ -434,36 +401,42 @@ type TrafficAnalysis struct {
// Incremental traffic weight step for promotion phase
// +optional
StepWeightPromotion int `json:"stepWeightPromotion,omitempty"`
}
// Max number of failed checks before the traffic analysis is terminated
Threshold int `json:"threshold"`
// Percentage of pods that need to be available to consider primary as ready
// Defaults to 100
PrimaryReadyThreshold *int `json:"primaryReadyThreshold,omitempty"`
// Percentage of pods that need to be available to consider canary as ready
// Defaults to 100
CanaryReadyThreshold *int `json:"canaryReadyThreshold,omitempty"`
type TestingConfig struct {
// Number of checks to run for A/B Testing and Blue/Green
// +optional
Iterations int `json:"iterations,omitempty"`
// Metric check list for this traffic analysis
// Flagger comes with two builtin metric checks: HTTP request success rate and duration.
// Can use either built-in metric checks or custom checks.
// If you want use custom checks, you can refer to https://docs.flagger.app/usage/metrics#custom-metrics.
// A/B testing HTTP header match conditions
// +optional
Metrics []Metric `json:"metrics,omitempty"`
Match []istiov1alpha3.HTTPMatchRequest `json:"match,omitempty"`
// Webhook list for this traffic analysis
// Retries policy for the generated virtual service.
// +optional
Webhooks []Webhook `json:"webhooks,omitempty"`
Retries *istiov1alpha3.HTTPRetry `json:"retries,omitempty"`
// A/B testing HTTP header match conditions
// Headers operations for the generated Istio virtual service.
// e.g.
// headers:
// request:
// add:
// x-some-header: "value"
// +optional
Match []istiov1alpha3.HTTPMatchRequest `json:"match,omitempty"`
Headers *istiov1alpha3.Headers `json:"headers,omitempty"`
// SessionAffinity represents the session affinity settings for a analysis run.
// Cross-Origin Resource Sharing policy for the generated Istio virtual service.
// e.g.
// corsPolicy:
// allowHeaders:
// - x-some-header
// allowMethods:
// - GET
// allowOrigin:
// - example.com
// maxAge: 24h
// +optional
SessionAffinity *SessionAffinity `json:"sessionAffinity,omitempty"`
CorsPolicy *istiov1alpha3.CorsPolicy `json:"corsPolicy,omitempty"`
}
type Metric struct {
Expand Down Expand Up @@ -576,6 +549,12 @@ type SessionAffinity struct {
// +optional
MaxAge int `json:"maxAge,omitempty"`
}
// CustomMetadata holds labels and annotations to set on generated objects.
type CustomMetadata struct {
Labels map[string]string `json:"labels,omitempty"`
Annotations map[string]string `json:"annotations,omitempty"`
}
```

#### Test Plan
Expand Down

0 comments on commit ea1cdda

Please sign in to comment.