Streamlining MLOps, Ambient meshes, and Helm alternatives

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

Chase: Hi, my name is Chase Christensen. I'm a staff solutions engineer, and I work at TileDB.

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

Chase: I'm really keeping an eye on eBPF. I love the idea of an easier kind of service mesh walkthrough or workload. I'm looking at anything that makes an operator easier. I love the operator pattern. Things like Crossplane are really interesting. With the emergence of AI and ML, I'm definitely looking at Kubeflow and how we can take Kubernetes, abstract it away, and help data science teams.

Bart: William Morgan said that eBPF is bad for service meshes, alluding that the technology doesn't work well for this tool. What are your thoughts on using service meshes and what kind of features do you evaluate service meshes for?

Chase: One of the reasons I'm looking into eBPF is because I love the ideas behind a service mesh. When we talk about the ability to... authenticate and authorize our workload, that's really important, especially for serving machine learning models. If you're serving it as an endpoint, you need to authenticate it. If you want to do namespace, multi-tenancy, and isolation, you need to be able to handle that. But I think it's really complicated and there's a lot of overhead. So I'm looking for solutions that can help simplify it. I'm hoping eBPF can provide that for us.

Bart: William explained that Ambient Mesh is a viable alternative to having too many sidecar containers in service meshes, but it comes at the expense of not having the pod as a single independent unit. What are your thoughts on service meshes? Should you use one or not? And when should you use one?

Chase: So that's a really great topic. I think that's something I need to explore more because when it talks to ambient service meshes, I love the idea of being able to decouple it away from the sidecar. I think managing the sidecar and even the vulnerabilities that come with shipping someone else's image and putting it in your environment is something worth exploring. Really, the simplicity and the operationalization is what I'm looking for us to be able to improve. Is it easier to troubleshoot than currently, where I apply maybe an authorization policy, and things break? And then what? Do you need networking tools? Do you need maybe a different stack to be able to troubleshoot it? When really, you just want to be able to push a workload to a centralized operator, and now you're stuck.

Bart: One of our guests, Steven, shared some simple but effective advice on building Kubernetes operators. Keep it simple and use multiple CRDs. Do you have any advice when it comes to operators?

Chase: Advice for operators is based on my current experience. One thing, going back to the Kubeflow project, is they have this thing called the unified... training operator. The idea is if we can unify an operator and simplify the API call, you can switch between machine learning training frameworks. This seems to be a good model to support one operator and call it to spin up what you really want to do, which is use these frameworks. I'm all about that centralization.

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?

Chase: You have all these manifests. We've taken this configuration as data, all these API calls, it's now data. You can store it in a GitOps fashion, but templating it and storing it is hard. These are objects. Kustomize is great, but then you've got this kind of maze within your Git repo that's hard to navigate. I like Helm, but Helm itself is something you need to support. I've seen a lot of motivations to use KPT. I don't think there is a one-size-fits-all answer. I'm going to pull my solutions architect hat out and say it depends. But I've seen a lot of success with Helm, at least getting that upgrade path and the templating into production. It really depends on your customers and the culture within your company.

Bart: Kubernetes is turning 10 years old this year.

Chase: Controversial opinion here. I think our goal for the next 10 years of Kubernetes is to hide as much Kubernetes as possible. I love Kubernetes. I see Kubernetes as this engine that can control innovation. It can do things like scaling. It can do things like simplifying my deployments. But I think we, as an organization, or we as Kubernetes users, are going to take everyone up a level of abstraction, and they're going to use Kubernetes and get the power of it without realizing it. I think that's what the next 10 years of Kubernetes is going to be.

Bart: What's next for you?

Chase: Working with machine teams to use Kubernetes, abstract it away, and get more models into production.

Bart: How can people get in touch with you?

Chase: You can find me at [email protected]. You can find me on LinkedIn, or you can reach me at chase.christianson at tiledb.com.