Introducing 'kit' for Multi-Cluster Kubernetes Deployments

--- title: " Deploying to Multiple Kubernetes Clusters with kit " date: 2016-09-06 slug: deploying-to-multiple-kubernetes-with-kit url: /blog/2016/09/Deploying-To-Multiple-Kubernetes-With-Kit author: > Chesley Brown (InVision) --- Our Docker journey at InVision may sound familiar. We started with Docker in our development environments, trying to get consistency there first. We wrangled our legacy monolith application into Docker images and streamlined our Dockerfiles to minimize size and amp the efficiency. Things were looking good. Did we learn a lot along the way? For sure. But at the end of it all, we had our entire engineering team working with Docker locally for their development environments. Mission accomplished! Well, not quite. Development was one thing, but moving to production was a whole other ballgame. **Along Came Kubernetes** Kubernetes came into our lives during our evaluation of orchestrators and schedulers last December. AWS ECS was still fresh and Docker had just released 1.9 (networking overlay release). We spent the month evaluating our choices, narrowing it down to native Docker tooling (Machine, Swarm, Compose), ECS and Kubernetes. Well, needless to say, Kubernetes was our clear winner and we started the new year moving headlong to leverage Kubernetes to get us to production. But it wasn't long when we ran into a tiny complication... **Automated Deployments With A Catch** Here at [InVision](https://www.invisionapp.com/), we have a unique challenge. We just don’t have a single production environment running Kubernetes, but several, all needing automated updates via our CI/CD process. And although the code running on these environments was similar, the configurations were not. Things needed to work smoothly, automatically, as we couldn't afford to add friction to the deploy process or encumber our engineering teams. Having several near duplicate clusters could easily turn into a Kubernetes manifest nightmare. Anti-patterns galore, as we copy and paste 95% of the manifests to get a new cluster. Scalable? No. Headache? Yes. Keeping those manifests up-to-date and accurate would be a herculean (and error-prone) task. We needed something easier, something that allows reuse, keeping the maintenance low, and that we could incorporate into our CI/CD system. So after looking for a project or tooling that could fit our needs, we came up empty. At InVision, we love to create tools to help us solve problems, and figuring we may not be the only team in this situation we decided to roll up our sleeves and created something of our own. The result is our open-source tool, kit! (short for Kubernetes + git) **Hello kit!** [

InVision adopted Docker for development and then Kubernetes for production. They needed a solution for deploying to multiple Kubernetes clusters with similar code but different configurations. Finding no existing tool that fit their needs, they created 'kit,' an open-source tool to manage and automate deployments across multiple Kubernetes clusters by leveraging git.