Revolutionizing deployments with Kubernetes and GitOps

Bart: Who are you? What's your role? And who do you work for?

Nicholas: Hi, I'm Nicholas Morey. I'm a senior developer advocate with Akuity, the company created by the founders of the Argo project.

Bart: What are three emerging Kubernetes tools that you are keeping an eye on?

Nicholas: The one I've heard a lot about this time at KubeCon is CUE as a potential replacement for Kustomize and Helm. We'll see which adoption has the biggest impact. The second is Kargo, an open-source project by Akuity to handle environment promotion for GitOps. Basically, the entire lifecycle of the application can be managed declaratively with a nice UI, so you're no longer maintaining bespoke CI scripts to handle your promotion from one environment to the next. And then finally, something dear and close to my heart is Talos, the bare metal Linux operating system for Kubernetes, something I can't wait to replace MicroK8s with.

Bart: One of our guests, Jacco, expressed dissatisfaction with Helm's templating approach, comparing it unfavorably to PHP's templating HTML. What's your experience and preferred approach to templating and deploying Kubernetes resources to several environments?

Nicholas: My preferred approach is to use Kustomize and Helm in my GitOps repo, which gives me the flexibility to take basically any chart I want and also any resources I want and package them together into one declarative unit and deploy them into my cluster. Now, that actual deployment, I tend to prefer to do in a pre-rendered fashion. I gave a talk about this at ArgoCon. The idea is that instead of letting Argo CD or whatever your GitOps tooling is render the manifest for you when it goes to apply it to the cluster, you actually pre-render those manifests so that you get the true desired state stored in Git as an artifact, and then it's only managing raw Kubernetes manifests.

Bart: Another guest of ours, Mac, acknowledges the usefulness of tools like Vault. He cautions against misconfigurations and suggests evaluating the return on investment regarding security. He mentioned how the auto-unseal mechanism is usually a double-edged sword. What's your take on Kubernetes security, Vault, and other tools such as Sealed Secrets for managing Kubernetes secrets?

Nicholas: Don't manage your own secrets manager. That's my take. I've been in that position. I've been the person responsible for a Vault instance that somebody else set up before I joined the organization. Misconfigurations are terrifying, outages are impossible to troubleshoot, and I'd rather pay for a service that has a team of engineers responsible for keeping that secrets manager safe, secure, and reliable. Then use something like External Secrets Operator to actually pull those secrets and generate the Kubernetes secrets in the cluster for you.

Bart: Our guest, Mathias, believes that on-premise deployments require proper education and attention, especially regarding managing on-prem architecture versus cloud architecture. After spending a few months building an on-prem Kubernetes cluster, he shared this advice. What's your experience with bare metal clusters? And how does that differ from using Kubernetes in the cloud? What would you have liked to know before starting to use Kubernetes on bare metal?

Nicholas: You have to think about a lot more when you're doing bare metal. The cloud is this beautiful abstraction that basically makes everything a lot easier for you. When you go to bare metal, you have to start thinking about things like redundant power, redundant networking connectivity, and even redundant storage on the physical hosts. So I recommend anybody that's trying to do bare metal to have a solid understanding of how to manage physical infrastructure before worrying about the Kubernetes part, because you can slap Kubernetes on basically any bare metal system. But the cluster is not going to be reliable if the hardware that it's running on is also not reliable. Also, Talos. I wish I had known about Talos before I started with bare metal.

Bart: Kubernetes is turning 10 years old this year. What should we expect in the next 10 years to come?

Nicholas: I expect that given the breadth of the CNCF landscape, we're going to start seeing a lot more opinionated stacks about how to combine cloud-native tooling on a Kubernetes cluster to produce a full solution. So things like the BACK Stack or CNEUs, the cloud-native operational excellency group, are telling you based on their enterprise experience, these are the toolings that you should be using to accomplish this end result. And if I was to take another take, it would be that we need to have a focus on education because I don't know if you remember the first time you looked at a Kubernetes manifest, it's daunting. You don't know what matters in that Kubernetes manifest. Do I care about the API version? Do I care about this? Do I care about the status field, these managed fields? So if we want to continue to grow the ecosystem and grow the adoption, we need to make sure that people are properly educated and that we make it accessible to people that are new to Kubernetes and new to the industry.

Bart: What's next for you?

Nicholas: This year, we will focus on in-person events where we can get on the ground and start getting feedback better than we can from the remote world we've been living in for the past few years. You'll be seeing me at KCD New York, in Salt Lake City, and at other events around the world. We'll spend a lot of time talking about Kargo environment promotion for GitOps and how to scale GitOps for enterprise companies.

Bart: How can people get in touch with you?

Nicholas: You won't find me on Twitter or X, but you can find me on LinkedIn. You can find me on the CNCF Slack, and you can also find me in person in Ottawa, Canada. Please reach out to me if you're local.