Webinar Recap – GitOps for Multi-Cluster Kubernetes Across Any Cloud

This week we teamed up with our friends at Weaveworks to talk about multi-cluster and multi-cloud Kubernetes in the real world. Multi-cloud is not an empty buzzword, but a reality for many businesses when designing their environments for High Availability (HA) and Disaster Recovery (DR) scenarios, and especially for those that need to operate in multiple geographic regions. And while HA and DR are not new concepts, implementing them with Kubernetes across availability zones, sites and clouds is. 

Kubernetes is the leading application infrastructure orchestration platform and the foundation of cloud-native architecture. However, it provides just one layer of a modern enterprise infrastructure and in fact, it introduces changes in the other infrastructure layers and processes around it.

In order to truly unlock cloud native agility, platform teams require new components and methodologies in order to successfully operationalize the entire stack. In reality many enterprise IT teams are faced daily with production challenges resulting from managing multi-cluster Kubernetes across multiple clouds.

What should you consider when designing and deploying a Kubernetes-centric architecture?

GitOps for declarative infrastructure

GitOps is a way to do Kubernetes cluster management and application delivery.  It works by using Git as a single source of truth for declarative infrastructure and applications. With Git at the center of your delivery pipelines, developers can make pull requests to accelerate and simplify application deployments and operations tasks to Kubernetes.

In this session, we discuss common pitfalls and demonstrate GitOps workflows with the Weave Kubernetes Platform, Gloo, and Service Mesh Hub to configure and operationalize your environment across clouds. We answer questions like:

• What do you need for a production grade Kubernetes infrastructure?
• What pitfalls to avoid when managing multi-cluster and multi-cloud
• How to control application traffic and security from Ingress to Service Mesh
• How to deliver sophisticated cluster lifecycle management of maintenance, upgrades and patches with GitOps

Watch the replay here:

Highlights from the Q&A 

What is an Immutability Firewall in GitOps? 

Paul: When we talk about this conceptually it’s the firewall between DevOps and the CI process and GitOps and the CD process. Now they can be the same. You can use the same git to do this, but typically, you want to separate development from operations. That’s typically why that’s there.

Does flux support multiple git repos? And how to use multiple git upstreams to keep the git host from being a single point of failure in the control plane?

Paul: For the first question, it’s currently one to one, but you can run multiple Fluxes in a cluster. So that’s basically how you build out tenant spaces. The second question “How do you do upstream failover for git?” That’s really on you as Flux uses a git URL and that git URL can be any SSH git URL that you choose. So if you want to use a CNAME and load balance, you can do it that way or if you’re using one of the big services like GitHub, GitLab online, Bitbucket, or something like that, they are doing it for you. So it’s a choice you can make. We don’t say where it has to be. All we say is that the cluster where the agent is running Flux has to be able to reach it.

Can you create multiple virtual meshes with the Service Mesh Hub?

Christian: Yes, so we showed that we are grouping two of those clusters but we specify which clusters we want to be part of that virtual mesh and we do that with the virtual mesh CRD. 

Can you do the meshctl commands from GitOps

Christian: Yes, the meshctl CLI tool is a convenience tool and you can do everything with CRDs and
kubectl if you want. We will also have a web UI for it soon, but everything is driven by CRDs and declarative configuration. You can also use meshctl to output everything into a manifest, a YAML and then capture those objects that are put in GitOps.

What was the web UI for GitOps in the demo, is it open source?

Paul: The web UI is part of our Kubernetes platform product named Weaveworks Kubernetes Platform (WKP) and that part is not open source. However the Scope one that shows the visualization for the cluster is and it’s called Weave Scope. 

When will Service Mesh Hub be open sourced?

Christian: Service Mesh Hub was open sourced a couple of weeks ago (April 8th) and you can check it out in our github repo https://github.com/solo-io/service-mesh-hub, file issues and pull requests.

Download the presentation:

[featured_boxes class=”featured-box”]

Learn More

• About Gloo, Service Mesh Hub, and request a trial
• About Weaveworks Kubernetes Platform
• Download the white paper: Solving the cloud native delivery problem with WKP
• Join the conversation in the Solo.io and Weaveworks Communities

[/featured_boxes]