Kubernetes as an API Platform: GitOps Beyond Deployments

Bart Farrell: First things first, who are you? What's your role? And where do you work?

Zach Aller: My name is Zach Aller. I work at Intuit on the Argo CD team and Argo Rollouts team.

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

Zach Aller: One of the Kubernetes tools that I'm keeping an eye on is Intuit is pushing a new project into Argo Proj Labs called GitOps Promoter. And it's a way to do environment promotion in a really GitOps friendly way. I'm pretty excited about that. I would also say kube-burner. It's a project that we're interested in doing. Part of the GitOps promoter project is we're looking to load test some of our Kubernetes resources. That's something that I think will help us in that regard.

Bart Farrell: One of our podcast guests, Mai, believes that ArgoCD's beauty is that it flips the traditional CI-CD model on its head. Instead of the CI system pushing changes to Kubernetes, ArgoCD runs inside your cluster and pulls changes from Git. What's your take on this pull-based GitOps approach?

Zach Aller: The pull-based GitOps approach gives you a central pane of glass. That's what has helped Argo CD accelerate that UI view where you can manage a whole bunch of clusters is really a win for the project. There's some downsides to that with performance and things that we've struggled through. But I think that's the big difference is, do you want the central pane? Do you want the single pane of glass? Or do you want a more distributed architectural setup?

Bart Farrell: Another guest of ours, Andrei, suggested that FluxCD is more approachable to administrators, whereas ArgoCD is more about interacting with developers. Do you agree? And what's your advice when it comes to implementing GitOps?

Zach Aller: In the community, there has been this line drawn that Flux is better for the infra and ArgoCD is better for the developers. I think both can do the job really well. The UI from Argo CD and giving the application developers a concept of what an application is, is why that separation has happened. I don't think there's a right or a wrong. I think both tools can accomplish the job well. It's just what's come out of it recently has been that UI support seems to jive a little bit better with app developers.

Bart Farrell: Looking towards the future, Kubernetes turned 10 years old last year. What can we expect in the next 10 years to come?

Zach Aller: Oh, man. I'm a little bit of a GitOps nerd. I think Kubernetes really helps accelerate GitOps. I would really like the idea of the declarative API to continue to grow. I hope that Kubernetes aggregated API services, which is basically like a CRD that's not stored in etcd. I hope it starts powering a lot more interesting type APIs within the Kubernetes ecosystem. I'd like to see things start growing more as a declarative API where Kubernetes isn't just an autoscaler, but it's really an API platform.

Bart Farrell: And what's next for you, Zach?

Zach Aller: What's next for me? GitOps promoter, GitOps promoter, GitOps promoter. That's pretty much where I see my time being spent for the next handful of years, just trying to get that project going off the ground.

Bart Farrell: How can people get in touch with you?

Zach Aller: The Argo projects on the CNCF Slack, GitHub discussions for the Argo project works well.