Page Comparison

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 following 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. File paths can be absolute or relative to the temp directory.

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.

Code Block

language	text
theme	Midnight
firstline	1
title	deployment.yaml
linenumbers	true
collapse	true

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

Code Block

language	text
theme	Midnight
firstline	1
title	service.yaml
linenumbers	true
collapse	true

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.

Code Block

language	text
theme	Midnight
firstline	1
title	istio-bg.yaml
linenumbers	true
collapse	true

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):

Code Block

language	text
theme	Midnight
firstline	1
title	istio-canary.yaml
linenumbers	true
collapse	true

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.

Code Block

language	text
theme	Midnight
firstline	1
title	istio-ab.yaml
linenumbers	true
collapse	true

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

...

Versions Compared

Old Version 20

New Version Current

Key

Field Summary