Preface # Every organization I’ve worked for since 2017 has used Kubernetes. Granted, back in 2017, it was still a very new technology that didn’t benefit from the open-source ecosystem that it now does, and things were more challenging to do with it in general.
My professional experience with Kubernetes began with reading documentation and trying things locally or in AWS EKS. Local environments like Kind and k3s were new but suffered from severe resource limitations. Despite the improvement in laptop specs over the years, trying to do meaningful local development work, testing, or learning remains a significant challenge due to the complexity of said environments and the cost of managed options like EKS, GKE, and AKS.
The Github repo containing files discussed or shown in this post can be found here.
Assumptions and Requirements # Before beginning, I’ll go over some requirements and I’m also going to make some assumptions about you, the reader, and the environment you’re working from.
Assumptions # I’m going to first assume that you’ve got a base level of knowledge and experience with GKE, Istio, and Kubernetes in general.
This is Part 1 of a two part series.
As part of the SRE team at Harness, the goal is to help increase stability and reliability for our org while keeping in mind the need to scale as we grow. Here I’ll explain where we were with our platform, how we changed some things, for the better, in our move from AWS to GCP, and how we think we can help improve things here at Harness.