Red Hat OpenShift is the enterprise Kubernetes platform, and with the latest version, the platform has undergone significant improvements to developer experience, automation, and platform management.
In this video, I’m going to walk you through the changes in this new version, explain how each of these new features work, and demonstrate how these updates are improving the OpenShift 4 console. I hope you enjoy!
What’s new in OpenShift 4.3?
Red Hat OpenShift is the enterprise Kubernetes platform, and with the latest version—OpenShift 4—the platform has undergone significant improvements to developer experience, automation, and the management of the platform itself.
But what exactly changed and what do you need to know about OpenShift 4? Let’s get started.
So, OpenShift is Kubernetes at the core, and with OpenShift 4, the platform is now driven by Operators. Yes, this includes the services that support OpenShift, as well as app services that are deployed by users like you. This is significant. So, we’ll start with covering Operators.
Next, we’ll jump into one of the first things users will notice in OpenShift 4—that is an improved developer experience. And this comes with significant updates to the console.
And then, finally, we’ll dive into some of the community-driven projects that OpenShift has adopted into supported solutions. Things like OpenShift Service Mesh and OpenShift Pipelines. There’s actually more but we’ll touch on these two today.
Starting with Operators—essentially, they allow you to automate the lifecycle of containers. Let’s say I’m deploying a simple frontend and backend application. Once I deploy all of them into my cluster, I’ve got to manage all the automation or the config of individual applications.
But, with an Operator, I can take a different approach. By installing an Operator into a cluster with OLM (or Operator Lifecycle Manager), I can enable new CRDs (or Custom Resource Definitions).
These CRDs allow me to manage my application using custom config files tailored from my application. In addition, any automation that I need can be built into the operator itself. Essentially, I’ve extended the Kubernetes API to create new custom resources that are tailored to the resources that you regularly work with.
In OpenShift 4, the services that makeup OpenShift itself are actually managed by Operators. This means we get to take advantage of that same framework to easily do installation and upgrades of OpenShift itself.
Check out the Operator SDK to create your own Operators, or use the embedded Operator Hub in OpenShift to start quickly and with existing solutions.
Improved console experience
Next, let’s talk about one of the first things you’ll notice in the platform, and that is an improved developer experience starting from the console.
The main thing you’ll notice is a different view for administrators and developers. There’s new dashboard capabilities for streamlined deployment of applications, whether you start with a git repo, container image, or deployment YAML.
In addition, you’ll get better observability into the platform. For example, there’s an events view which tracks everything happening in your cluster.
There’s improved administration of the cluster itself, with a new user-manage section as well.
Cloud native development
OpenShift Pipelines with Tekton
Lastly, let’s close with some of the community-driven projects that OpenShift is supporting. One of them is going to be OpenShift Pipelines with Tekton.
Tekon is a cloud native way to declare CI/CD pipelines, and it’s based entirely on Kubernetes. It starts with defining the tasks that make up a CI/CD flow, which actually run as pods in your cluster. These make up a pipeline, and that’s able to deploy applications into your cluster.
In OpenShift, there’s actually UI integration between Tekton and OpenShift. So, OpenShift Pipelines lets you manage your CI/CD, all in the dashboard.
OpenShift Service Mesh
The other community-driven project I want to talk about is OpenShift Service Mesh. This is based on Istio.
Imagine you have a number of services that are dependent on one another. A number of concerns arise in the interaction between these services. How do you actually manage these interdependent complexities?
Well, instead of managing them in the app itself, you can take advantage of the Istio control plane, which uses “sidecars” to basically help you control how these microservices connect with each other, how they enforce policies, and then even observe how they behave.
That way, the capabilities rest on the control plane rather than the apps themselves.