When a project is being deployed to a K8s Cluster, FlexDeploy offers the ability to configure a Helm Chart and/or deployment strategies for the deployment. Both configurations are done on the follow tab:

Field Summary

Name	Description	Notes
Deployment Name	This is the K8s deployment name. The field is a groovy script by default so be sure to enclose literal strings in quotes.	Result after a deployment: kubectl get deployments NAME springboot1.0.5
Manifests to deploy	Actual K8s manifest files for your deployment. Files will run from top to bottom.	Usually consists of a deployment.yaml and service.yaml. To make use of the Deployment Name field above, your deployment.yaml should use FD_KN_DEPLOYMENT_NAME flexdeploy property and can also use the FD_PROJECT_DOCKER_IMAGE_NAME property configured on the docker tab. deployment.yaml Expand source apiVersion: apps/v1beta1 kind: Deployment metadata: name: ${{FD_KN_DEPLOYMENT_NAME}} spec: replicas: 1 template: metadata: labels: app: superapp fd_deployment_name: ${{FD_KN_DEPLOYMENT_NAME}} fd_app_name: SpringBoot spec: containers: - name: superapp image: ${{FD_PROJECT_DOCKER_IMAGE_NAME}} ports: - containerPort: 8080 service.yaml Expand source apiVersion: v1 kind: Service metadata: name: superapp spec: selector: app: superapp ports: - port: 8080 targetPort: 8080
Blue/Green Istio Manifest	Istio manifest file to apply when running BlueGreen deployment strategies. If using a different strategy you can leave this blank.	The BlueGreen strategy is effectively an 'On/Off Switch' for your pods. When using this strategy all of your pods will deploy with a BLUE label, meanwhile traffic is always routed to GREEN labels. Testers and QA will test BLUE pods through back doors and other means. When ready you can 'flip' the switch to label all BLUE pods as GREEN resulting in them opening up for regular traffic. As you can see in the below manifest file, the GREEN route will always receive 100 percent of the traffic through the Istio Mesh. istio-bg.yaml Expand source apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: superapp spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: superapp spec: host: superapp subsets: - name: green labels: fd_version: green - name: blue labels: fd_version: blue --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: superapp spec: gateways: - superapp hosts: - superapp http: - match: - uri: prefix: /version route: - destination: port: number: 8080 host: superapp subset: green weight: 100 - destination: port: number: 8080 host: superapp subset: blue weight: 0
Canary Istio Manifest	Istio Manifest file to apply when running the Canary deployment strategy. If using a different deployment strategy you can leave this blank.	Canary is similar to the BlueGreen strategy but instead of being an 'On/Off Switch' think of it as a 'Dimmer Switch'. Instead of cutting all traffic over in one moment you can adjust the weights as you go. For example, you can start at routing 90 percent of traffic to GREEN and 10 percent to BLUE, then 70/30, then 50/50, then full cut-over at 0/100. You will notice the the manifest file looking similar to the BlueGreen manifest with the exception that we can see FlexDeploy variables used in the weight fields (Check out the pipeline documentation to see where these weights are set): istio-canary.yaml Expand source apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: superapp spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: superapp spec: host: superapp subsets: - name: green labels: fd_version: green - name: blue labels: fd_version: blue --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: superapp spec: gateways: - superapp hosts: - superapp http: - match: - uri: prefix: /version route: - destination: port: number: 8080 host: superapp subset: green weight: ${{FD_KN_OLD_WEIGHT}} - destination: port: number: 8080 host: superapp subset: blue weight: ${{FD_KN_NEW_WEIGHT}}
AB Istio Manifest	Istio Manifest file to apply when running the AB deployment strategy. If using a different deployment strategy you can leave this blank.	The AB deployment strategy still involves BLUE and GREEN pods like BlueGreen and Canary. The difference here is that BLUE traffic is only ever open based on a 'Routing Rule' which could be an http header of your choosing. For example, below we can anyone with the 'end-user' header set to a FlexDeploy property configured on the pipeline will get sent to a BLUE pod, and everyone else is routed to GREEN. After the end-user has validated the BLUE pods, we flip them all to GREEN similar to the BlueGreen strategy. istio-ab.yaml Expand source apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: superapp spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: superapp spec: host: superapp subsets: - name: green labels: fd_version: green - name: blue labels: fd_version: blue --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: superapp spec: gateways: - superapp hosts: - superapp http: - match: - headers: end-user: exact: ${{FD_KN_ROUTE_RULE}} route: - destination: port: number: 8080 host: superapp subset: blue - route: - destination: port: number: 8080 host: superapp subset: green
Helm Chart	The Helm chart to apply during deployment.	Can be a chart in the repository configured on the deploying endpoint, a folder with a chart, a chart package or URL.
Helm Release Name	Release Name in Helm to easily track all deployments on the endpoint. Has nothing to do with FlexDeploy Release*	If it is unspecified, Helm will generate a random name.
Parameters Map	Parameters to pass to the Helm Chart

Deployment Strategies

After defining the K8s information and Deployment Strategy Manifest files in the project configuration as laid out above, the majority of the leg work is done by FlexDeploy Pipelines, though you can accomplish the same approach through traditional Projects and Workflows.

Pipeline

Pipelines now consist of a new 'Step' called 'Apply Deployment Strategy', which we can see used below throughout the stages with the K8s icon. On the step you can set the Deployment Strategy you want to use (BlueGreen, Canary, or AB) and what weights or properties you want to apply.

For more specific information on the Apply Deployment Strategy Step see here.

The below pipeline is using the Canary Strategy updating the weights as it progresses through the stages, starting at 10-90 and ultimately finishing with a full cutover at 100 - 0.

Workflows

To use deployment strategies within FlexDeploy you need to use the Kubernetes Deploy Plugin operation within your workflow. If you have your Deployment Strategy information configured in the Pipeline as outlined above, you can defer the setting of those inputs in the workflow.

Helm Configuration

In order to deploy a Helm chart to a K8s cluster, FlexDeploy uses the deploy operation of Helm plugin, which invokes helm upgrade --install command under the hood. So, the deployment workflow should contain a step as in this example:

If Chart Name and Release Name are unspecified, FlexDeploy will take the values from the Helm Configuration tab.

FlexDeploy overrides values of the chart with the values configured in the Chart Values list. These values are specified with Groovy scripts evaluated on-the-fly during the deployment. The scripts may reference any Project or Environment-Instance (available for the project) properties.

There is a smart suggester of available properties. Just start typing something from a property name and hit Ctrl-Space.

Browser not supported