{"id":516934,"date":"2020-09-01T15:11:49","date_gmt":"2020-09-01T13:11:49","guid":{"rendered":"https:\/\/www.devoteam.com\/expert-view\/using-spinnaker-for-multi-cluster-kubernetes-workloads-in-gke\/"},"modified":"2020-09-01T15:11:49","modified_gmt":"2020-09-01T13:11:49","slug":"using-spinnaker-for-multi-cluster-kubernetes-workloads-in-gke","status":"publish","type":"expert-view","link":"https:\/\/devoteam.info\/cz\/expert-view\/using-spinnaker-for-multi-cluster-kubernetes-workloads-in-gke\/","title":{"rendered":"Using Spinnaker for multi-cluster Kubernetes workloads in GKE"},"content":{"rendered":"

In\u00a0part 1\u00a0of\u00a0<\/a> this article series<\/a><\/span> about deploying multi-tenant Kubernetes deployments in a VPC-native cluster with Spinnaker on Google Kubernetes Engine (GKE), we set up a basic CI\/CD solution using Spinnaker and a Single GKE cluster. The solution as-is from part 1 is not suited for production because any change made by a developer would be automatically publish into production without proper validation. In this second article, we are going to build on top of the infrastructure we set up in part 1 and learn how we can add new environments to develop and validate our application without impacting the production environment.<\/strong><\/span><\/p>\n

<\/p>\n

\"GKE<\/strong><\/p>\n

A production-grade environment requires quality and stability for the delivered applications.<\/strong> This requires development and validation processes within the application life cycle, from daily updates from the development team to the proper testing of the application by the quality assurance team before releasing the application.<\/p>\n

By the end of this article, we will have a Development, Staging, and Production environment which will be used by Spinnaker to deploy the application in.<\/strong><\/p>\n

Adding Environments<\/h2>\n

Making sure we deliver a stable and high quality application requires proper testing and validation before being made available to the users.<\/strong> Failing to do so is likely to result in long delays between releases, incomplete (or lack of) new functionalities, or even unexpected breaking changes in the application – making it partially unusable by the users.<\/p>\n

This can lead to financial loss for the customer relying on the solution, make the customers unhappy and impact the reputation of the company.<\/strong> In part 1 of this article series, we\u2019ve only set up one environment for the users, which has the problems we just described.<\/p>\n

Production environment<\/h3>\n

The version of application currently accessible by the users is running in the Production<\/em> environment.<\/strong> It is possible to have multiple versions of an application running in Production<\/em>, for example if there is a stable and beta version. As both are available to the users, they are both running in what we call a Production<\/em> environment.<\/p>\n

The application needs to evolve to offer new functionalities and having the development team directly working on this environment has a high chance of impacting the quality and reliability of the application.<\/strong> Indeed, developers can easily introduce changes that can negatively impact the user experience. In addition, some components of the infrastructure might change. This could potentially include breaking changes.<\/p>\n

For example, the Kubernetes version running on the cluster can be upgraded by the Cloud Provider and add incompatibilities with some Kubernetes resources, breaking the application even if it was not modified.<\/p>\n

Staging environment<\/h3>\n

To prevent this, we decide to set up a non-production environment, called Staging<\/em>,<\/strong> which is not available to the users and usually runs the current or next production version of the application. This environment can safely be used to intensively test and validate the application without impacting the existing Production<\/em> environment. This doesn\u2019t guarantee the application will run without issues once deployed into Production<\/em>, but it greatly minimises the risk of issues the users might encounter.<\/p>\n

That\u2019s why it\u2019s important that the Staging<\/em> environment reflects as close as possible the Production<\/em> environment.<\/strong> If issues are discovered in this environment, it is important that they are fixed before releasing the application into Production<\/em>.<\/p>\n

Automation testing is a great way to test for regressions in the application.<\/strong> It can greatly reduce the human time needed by the team to validate the application. If the entire validation process is automated, one can imagine releasing the application very often.<\/p>\n

Otherwise, the validation process takes more time and requires the application not to change during that time.<\/strong> The development team is likely to publish new changes on a day-to-day basis, which can impact the validation process if the environment is shared.<\/p>\n

If acceptance tests<\/a> are performed, it is possible that one functionality<\/strong> might be working when tested and be broken after an update by the developers, which could then be wrongly labeled as validated.<\/p>\n

Development environment<\/h3>\n

To prevent any conflicts, we are adding an additional environment called Development<\/em>.<\/strong> In this environment, developers can safely push their changes on a day-to-day basis without impacting the Staging<\/em> and Production<\/em> environments.<\/p>\n

Breaking changes in the Development<\/em> environment are accepted as normal and get resolved during the developments of the application.<\/strong> During each release cycle, the content of the Development<\/em> environment is frozen and properly tested in the Staging<\/em> environment.<\/p>\n

The new infrastructure<\/h2>\n
\"Spinnaker<\/div>\n

We are adding 3 environments to our current infrastructure : Development<\/em> (DEV), Staging<\/em>, and Production<\/em> (PROD). On the diagram, we are only showing one additional environment (PROD)<\/strong>, but all 3 environments can be represented with the same components within the blue rectangle.<\/p>\n

Dedicated GKE clusters<\/h3>\n

Each environment has its own dedicated GKE cluster,<\/strong> running a specific version of the application:<\/p>\n