Kubernetes

This post is part of the Red Hat Platform series. If you want the full picture of what we’re building toward, start there. Well, these days it’s hard to consider myself a technologist unless there is some AI stuff on my blog. So, in this post we’ll focus on an introduction to OpenShift AI specifically on inferencing. AI has taken the world by storm for better or worse. It’s not just technologists who are buzzing about how AI is going to impact them, the whole world has an opinion on it. While the debates rage on, technologists are trying to find ways to make AI easier to manage. Many people use the SaaS based way to get access to AI models. They use an AI endpoint from Claude (Anthropic), ChatGPT (Microsoft), or Gemini (Google) and pay for each request through the allocation of tokens, and it’s simple to get started. But as your workloads consume more and more tokens, and the SaaS providers charge more and more money for those tokens, this way of leveraging AI gets very expensive very quickly. So you look to buy your own GPUs and servers and plan to host your models yourself. Now we’re met with new problems. How do I lifecycle my models and replace old models when new ones are available? How do I change model types without updating my applications for a new API spec each time? How do I match my finite GPUs to the right models, and how do I keep users from accessing models they don’t need? The challenge is daunting… unless you have OpenShift AI. ...

This post is part of the Red Hat Platform series. If you want the full picture of what we’re building toward, start there. What if we had a situation where our application didn’t run as a container for some reason. What if the Brix Pizzaria ran virtual machines instead? Will our OpenShift platform be capable of managing these as well as our containerized workloads? The short answer is yes. In this post we’ll focus on OpenShift Virtualization and how we can leverage this solution to run our VMs on our existing OpenShift cluster. ...

This post is part of the Red Hat Platform series. If you want the full picture of what we’re building toward, start there. In this post we’ll focus on OpenShift Dev Spaces. Dev Spaces I’d love to tell you that Dev Spaces is a fun new store where you try out the latest ergonomic gadgets. Standing desks with built-in treadmills, kneeling chairs, and expensive vertical mice that look like a clay sculpture would be just some of the things in these pop-up stores. Those of us tied to a desk for way too many hours a day could check out the latest in geek comfort. I hope a place like this exists somewhere, but that’s not what we’re talking about today. ...

This post is part of the Red Hat Platform series. If you want the full picture of what we’re building toward, start there. Here we’re focused on continuous deployment using OpenShift GitOps, which is Red Hat’s supported distribution of ArgoCD. GitOps This post is really about continuous deployments of our sample Brix Pizza application. In a previous post we build a CI/CD pipeline that built our container image automatically after we made changes to the source code and committed it to git. In this case we want to get our application deployed to our Kubernetes cluster. ...

This post is part of a series on OpenShift as a platform. We’re looking at the container foundation here, specifically what OpenShift adds on top of upstream Kubernetes and how Operators turn that into an extensible platform for everything else we’ll cover. Kubernetes is the Engine Kubernetes is the most widely adopted container orchestration system in the world, and OpenShift is built on top of it. But “built on top of” understates what Red Hat has done. Kubernetes is a powerful set of primitives such as a control plane, an API, a scheduler. This is the engine for managing containers on a distributed cluster. But just like your car, the engine while being maybe the most important component, won’t get you to the grocery store alone. You still need tires, a steering wheel, brakes, and a series of other things for your car to be a useful tool. Well, organizations need more than the basic Kubernetes components to run their workloads. This includes things like authentication, observability, security controls, and a console for it to be used for production. ...

This is part of an ongoing series on OpenShift as a platform for containers, VMs, AI workloads, and developer tooling. In this post we’ll set up a CI pipeline using OpenShift Pipelines to automatically build and push a container image for the Brix Pizza demo app whenever code is pushed to GitHub. If the application is going to run on OpenShift, it makes sense to build and test it there too. Your CI environment and your production environment become the same platform, which means fewer surprises at deployment time. ...

Hey! Who deployed this container in our shared Kubernetes cluster without putting resource limits on it? Why don’t we have any labels on these containers so we can report for charge back purposes? Who allowed this image to be used in our production cluster? If any of the questions above sound familiar, its probably time to learn about Validating Admission Controllers. Validating Admission Controllers - The Theory Admission Controllers are used as a roadblocks before objects are deployed to a Kubernetes cluster. The examples from the section above are common rules that companies might want to enforce before objects get pushed into a production Kubernetes cluster. These admission controllers can be from custom code that you’ve written yourself, or a third party admission controller. A common open-source project that manages admission control rules is Open Policy Agent (OPA). ...

Just because a container is in a running state, does not mean that the process running within that container is functional. We can use Kubernetes Readiness and Liveness probes to determine whether an application is ready to receive traffic or not. Liveness and Readiness Probes - The Theory On each node of a Kubernetes cluster there is a Kubelet running which manages the pods on that particular node. Its responsible for getting images pulled down to the node, reporting the node’s health, and restarting failed containers. But how does the Kubelet know if there is a failed container? ...

You’ve built your Kubernetes cluster(s). You’ve built your apps in containers. You’ve architected your services so that losing a single instance doesn’t cause an outage. And you’re ready for cloud scale. You deploy your application and are waiting to sit back and “profit.” When your application spins up and starts taking on load, you are able to change the number of replicas to handle the additional load, but what about the promises of cloud and scaling? Wouldn’t it be better to deploy the application and let the platform scale the application automatically? ...

Containerizing applications and running them on Kubernetes doesn’t mean we can forget all about resource utilization. Our thought process may have changed because we can much more easily scale-out our application as demand increases, but many times we need to consider how our containers might fight with each other for resources. Resource Requests and Limits can be used to help stop the “noisy neighbor” problem in a Kubernetes Cluster. Resource Requests and Limits - The Theory Kubernetes uses the concept of a “Resource Request” and a “Resource Limit” when defining how many resources a container within a pod should receive. Lets look at each of these topics on their own, starting with resource requests. ...