K8s and FlexDeploy

With the release of FlexDeploy 5.2, we now have the ability to automate K8s Deployment Strategies as well as more native support for K8s. Because of this, we unfortunately have to say goodbye to the Helm Tab to make room for K8!

FlexDeploy 5.2

FlexDeploy 5.1

This blog will require you to have a working knowledge of K8s and Deployment Strategies. Therefore, if you need a brush up you can check out this post or just Google around. (It’s your life!)

The Goal

Our objective is to deploy a new version of our ‘SpringBoot’ app into production. Furthermore, we want to do this in a way that doesn’t significantly hinder the user experience. In order to accomplish this, we are going to have the following:

The Project

The role of the Project is to export the manifest files from source and deploy the application to K8s. Along the way, any manifest files we specify for Deployment Strategies will also be applied. Below are some of the resources if you wish to create this yourself.

K8s Configuration

K8s Configuration

Making use of the new K8s tab, we are specifying the Deployment Name (1) as a Groovy script using the Project Version. In addition, the Manifest Files for deployment (2) and Canary Deployment Strategy (3) are also specified.

Upon opening the Istio-canary.yaml file, we can see one thing out of the ordinary. Notably, the ‘weight’ fields are using FlexDeploy Property Replacement.

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}}

Keep this in mind as it will come into play later on.

The Pipeline

Now that the project is all setup, it’s time to showcase how exactly we are going to update our weights as we feel more confident with our new application version. To set the stage, this SpringBoot project is part of a Release using a Pipeline configured for Canary Deployments.

Canary Pipeline

Pipelines now come with a new Step called ‘Apply Deployment Strategy’, which has anywhere from 2-4 fields depending on your strategy. For instance, Canary is the selected strategy here and we can see it then prompts for ‘Old Weight‘ and ‘New Weight‘. These weights correlate to the FD_KN_OLD_WEIGHT and FD_KN_NEW_WEIGHT we saw in the Yaml configuration. Consequently, as we deploy to higher environments, we are directing more of the traffic to the Blue (new version) Pods. Finally, the Pipeline finishes with a Deployment to Production where 100 percent is routed to Blue and then Blue is cut-over to Green, thus completing our deployment.

Finishing Deployment

The Results

You may have noticed in the Pipeline that automated testing was done as well to validate the traffic. 10 requests were sent to the service with the output differing depending on whether the Blue or Green Pod was hit.

Environment Weights Test Results
Development 10-Blue, 90-Green 2-Blue, 8-Green
Test 30-Blue, 70-Green 3-Blue, 7-Green
QA 50-Blue, 50-Green 6-Blue, 4-Green
Production 100-Blue, 0-Green 10-Blue, 0-Green

The Conclusion

So why wait any longer? Deployment strategies can reduce your time-to-market, help you discover and solve any issues, and increase IT team (and customer) morale.

Join us for a webinar on deployment strategies for microservices and containers!

Save Your Seat

Joel Wenzel

I have been working on integration and API architecture and development for the past 6 years, including with products such as Oracle SOA Suite, MuleSoft Anypoint Platform, Oracle Integration Cloud and API Platform, and Google Apigee. At Flexagon, I am part of the FlexDeploy engineering team which is enabling on prem and cloud use cases related to integration, API management, containers, and other tools and technologies.

More posts by Joel Wenzel
    

Leave a Reply

Your email address will not be published. Required fields are marked *