Citrix ADC for Kubernetes: Smarter canary deployment with Spinnaker

Raghav SN

5 years ago

“No one can whistle a symphony. It takes a whole orchestra to play it.” — H.E. Luccock

Application deployment stacks today are a combination of multiple open source and vendor sourced products. And modern microservices are polyglot applications often developed by different teams, using diverse design methodologies and programming language stacks. These microservices communicate with each other through APIs that have SLO (service level objectives) to meet the desired scale of end-user traffic.

Citrix ADC seamlessly fits into the cloud-native stack of any enterprise. In this blog, we’ll detail the value Citrix ADC can add to the DevOps pipeline. We’ll use Spinnaker and Kayenta as canary deployment tools to show how we can enrich the decision making using L3-L7 metrics (HTTP errors, latencies, etc).

DevOps and Continuous Deployment

Canary deployment is a popular way to roll out new features to a limited set of users to confirm they work as expected in production. It’s inspired by the practice of sending a canary into a new mine before sending any human miners. The canary’s health upon return would indicate if mine had any poisonous gas that would adversely impact health of miners.

Spinnaker is becoming the preferred platform for continuous deployment. Kayenta is a platform for automated canary analysis that Spinnaker uses as a canary judge, enabling automated canary deployment. The ADC is a critical enabler of canary deployment because it can send a portion of production traffic to the canary instances. As more application teams use the canary pattern more frequently, the ADC configuration has to be automated and well-integrated with the continuous deployment platforms such as Spinnaker.

Using Citrix ADC with Spinnaker and Kayenta

The Citrix ADC cloud-native solution enables enterprise Kubernetes platform teams and DevOps to improve canary deployments through a set of building blocks.

Containerized ADC with in-built ingress controller (CPX)
Ingress controller container to automate hardware and software Citrix ADCs outside the cluster (Citrix ingress controller)
Containers that export metrics and transaction data to cloud native monitoring tools
Continuous deployment (CD) controller, which integrates Citrix ADC with open source continuous deployment platform Spinnaker and canary judge Kayenta

The diagram below illustrates about the life cycle of an application version in continuous deployment:

Why Citrix ADC?

In canary deployments, application owners define rules to segregate production traffic across canary and production service instances so that only a small subset of users are exposed to the new version of the application. Citrix ADC provides extensive support for implementing canary deployments for both stateful and stateless applications.

Monitoring the canary version is a crucial task. It requires the application owners to look into network, system, and application metrics. Citrix ADC exports rich network and application metrics that can be used for the canary judge (Kayenta).

As the production or canary set of instances scale down, Citrix ADC provides a graceful way to drain the existing connections to those instances and prevents the client from reconnecting or reauthenticating. The characteristics of canary deployment for your application can be defined using a DevOps-friendly custom resource definition (CRD). Here is a sample CRD for an application:

apiVersion: “citrix.com/v1”
kind: “continuousDeploymentCustomConfig”
metadata:
   name: customcd
spec:
   serviceName:
   – frontend-app
   deployment: Kayenta
   config:
     stage:
       # canary distribution percentage
       percentage: 20
       # duration before a canary judgement is made
       period: 30m
     newImageTag:
       # canary image regular expression
       version: “canary”
     productionImageTag:
       # production image regular expression
       version: “prod”

# rule to segregate the traffic based on URL parameters
matchExpression: HTTP.REQ.URL.CONTAINS(“utm_campaign=roadshow”)

# stickiness/persistence type (SourceIP, Cookie, SSLID)
stickiness: cookie

     # graceful option for bleeding the existing client transactions
     connectionDrain: graceful
     KayentaConfig:
       Spinnaker:
         domain: 10.1.2.3
         port: 443
         pipelineName: Canary Deploy
         applicationName: frontend-app

Visit our GitHub page for more information about the CRD above.

Learn More

Please watch this Citrix Networking Master Class video for a live demo of integration with Spinnaker/Kayenta.

https://www.youtube.com/watch?v=Wp2oyF3kZV0

And for more information on individual components, please read the following blog posts:

Citrix Tech Bytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.

Click here for more Tech Bytes and subscribe.

Want specific Tech Bytes? Let us know! tech-content-feedback@citrix.com.