Managing Kubernetes infrastructure: from bare metal to production

Bart: Who are you? What's your role, and where do you work?

Michael: My name is Michael Wells. I'm with Dell Technologies. I'm an engineering technologist on the product team for the Dell Apex Cloud Platform for Red Hat OpenShift, and I work remotely living in upstate New York, which is based on OpenShift.

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

Michael: There is a lot of interest in virtualization, such as KubeVirt, these days. We are always keeping an eye on tools for things like observability, such as those that can improve high availability and disaster recovery features.

Bart: One of our podcast guests, Mathias, discussed the subject of bare metal, stating 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 his advice. What is your experience with bare metal clusters, and how does that differ from using Kubernetes in the cloud, perhaps using a solution like KubeVirt? What would you have liked to know before starting Kubernetes on bare metal?

Michael: It can be challenging to bring in bare metal compared to traditional hyperscaler infrastructures, as a lot of the underlying complexity is abstracted away. However, when you're on-premises, you still have to think about those things, which is one of the reasons why we created this product specifically for running OpenShift on bare metal on-premises. We've elevated the infrastructure management directly into the OpenShift web console and provide full stack lifecycle management. This means managing the OpenShift version also includes managing all of the ACP manager software, as well as the firmware updates for the hardware itself, similar to what is offered by Dell Apex Cloud Platform for Red Hat OpenShift. We greatly simplify the process of day two operations, such as expansion of the cluster, adding and removing nodes, and provide health visibility directly in the OpenShift web console.

Bart: On the subject of high availability, Pod Topology Spread, and Pod Topology Spread Constraints, our podcast guest Martin suggested avoiding Pod Topology Spread Constraints, as this is a Kubernetes feature that is simple to understand but has problematic consequences if not understood correctly. Do you have similar examples of something in Kubernetes that looked easy but was an absolute nightmare?

Michael: There are a number of things that Pod Disruption Budgets can affect, such as the ability to bring down nodes or make configuration changes. Making sure that the technologies are understood and implemented properly is crucial. There are a lot of features that are really beneficial, and you want to make sure you're using them correctly and not shooting yourself in the foot.

Bart: Databases on Kubernetes. Our guest shared that you can and should run a database on Kubernetes. The tooling and practices have matured since Kubernetes began, and you should run stateful applications there. What's your experience and advice with running stateful applications in Kubernetes?

Michael: Absolutely, I agree with that statement. Initially, when containers first became popular, it was not a good place for running stateful applications. However, as Kubernetes has matured over time, we have constructs around persistent volumes, and there is no reason why you shouldn't run database platforms on top of Kubernetes. You can get significant benefits, both in reducing the overhead of those platforms and in the speed of expansion, such as cloud-based database topologies where you can expand quickly by scaling up. This allows you to take advantage of these benefits. Like any change, you need to adapt how you deal with databases and how you architect them, but there are significant benefits to doing it this way.

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

Michael: In the next 10 years, continued enhancements and new feature sets will be developed. The innovation has not slowed; it has sped up. As we see greater adoption of [containerization](no link provided for containerization, consider adding a link to a Kubernetes or cloud native technology resource), you will continue to see new features and capabilities inside [Kubernetes](no link provided for Kubernetes, consider adding a link to the official Kubernetes website). One of the things I love about KubeCon is that their approach is to make changes in Kubernetes if it benefits the platform, not in KubeCon. You have additional projects driving further innovation in the Kubernetes platform, adding new capabilities not just for those running containers. You will continue to see this over time, and I am really excited about the next stage.

Bart: What's next for you?

Michael: It's a world that's constantly changing. There's so much to know and understand. I'm looking forward to the recordings of this event so that I can get to all those sessions that I wasn't able to attend in person.

Bart: How can people get in touch with you?

Michael: To get in touch with me, Michael Wells, at Dell.com, or if you have any questions about the Dell Apex Cloud Platform for Red Hat OpenShift, please reach out to your local Dell representative or visit Dell.com.