Who does what for support, updates and accessibility - Microsoft Azure Red Hat OpenShift

Meet the speakers

Roy de Milde (00:00):
Welcome to this Microsoft Azure Red Hat® OpenShift® video series. I am Roy from Microsoft, and I work for the Global Black Belt Team as an application innovation specialist. And today I'm joined by my dear friend.

Roberto Carratala (00:13):
I'm Roberto Carratala, part of the Managed OpenShift Black Belt team, working for Red Hat®. And today's topic is: who does what for updates and accessibility?

Who provides support for Azure Red Hat OpenShift clusters?

Roy de Milde (00:25):
Okay, cool. So let's assume I'm a customer. I'm running a couple of Azure Red Hat OpenShift clusters, super happy, but something is going on with one of my clusters. What do I do then? What is the process? Could you double-click on that?

Roberto Carratala (00:37):
Yes, absolutely. So, Azure Red Hat OpenShift is jointly engineered, supported, and operated by Red Hat and Microsoft. So I have the perfect item that will explain this. So let's discuss about it.

Roy de Milde (00:52):
Perfect.

Roberto Carratala (00:55):
So imagine that the customer is facing challenges with the different clusters… how can they have help? So the customer can open on both sides, in the Red Hat portal and also in the Microsoft portal, a ticket. So in the background, the frontline engineers–so the support team from both Red Hat and Microsoft–will start working to solve the different challenges. So if it's needed, they will work together and also they cross-collaborate and hand over the different tickets in order to collaborate; from Red Hat support and frontline engineers and also from the Microsoft frontline engineers, having this cross-team collaboration in order to help the customer to solve the different challenges that they are facing. If the frontline engineers need additional expertise, they can escalate to the SRE team from ARO, jointly engineered and supported from Microsoft and Red Hat. So we have the SRE team from Microsoft and Red Hat taking care of solving these different customer challenges. Azure Red Hat OpenShift, it's like another Azure service, so it's following the exact same guidelines as the other Azure service is following as well.

Roy de Milde (02:59):
Thank you. I think that diagram was really insightful. But you talked about an SRE. What is an SRE and what do they do?

What is a site reliability engineer (SRE) team and what do they do?

Roberto Carratala (03:07):
So the SRE, or the site reliability engineer, is a team that is looking proactively to installing, managing, and patching the different Azure Red Hat OpenShift clusters across the globe. So it's a jointly engineer and also a jointly support team around the different Microsoft and Red Hat teams as well.

Roy de Milde (03:32):
That's cool. And what are some of the things that they do for an Azure Red Hat OpenShift cluster, for example?

Roberto Carratala (03:36):
They look and they fix different things around cluster networking. They will also operate the different clusters to be up to date and apply the different security patches, as well. Any hotfix that appears, a security hotfix for example. And also they are responsible for managing and fixing any trouble that, for example, appears in the cluster regarding the control plane or the different workers, and then the customer can focus on the applications with Azure Red Hat OpenShift clusters.

Roy de Milde (04:14):
That's super cool. So basically it’s a team consisting of Red Hat employees and Microsoft employees working together. To make sure that the ARO clusters are up and running and doing their job for their customers. Very cool. Thank you.

Roberto Carratala (04:27):
Red Hat OpenShift ships with a lot of different features, and also there is an Arcadian version and there is also a lifecycle of the different ARO versions. So how can I upgrade my cluster and what are the different versions?

How to upgrade an Azure Red Hat OpenShift cluster

Roy de Milde (04:45):
Sure. So let me first tell you that Azure Red Hat OpenShift works based on a default version. But I actually can hop over to the Lightboard to explain it, maybe a little bit better with the diagram, as well.

Roberto Carratala (04:56):
Absolutely.

Roy de Milde (05:01):
So as I just explained, Azure Red Hat OpenShift works on a default version. So for this example, I'm going to use version 4.11. So if I have my Azure Red Hat OpenShift cluster over here, version 4.11, what I can actually do now when I deploy the Azure Red Hat OpenShift cluster, I can also deploy a 4.10 cluster. But we don't stop there, because what I can do when I deploy the default version, I don't specify that I want to deploy another version, I can actually upgrade to, in this scenario, 4.12. The only thing that we are saying is that you need to be on the stable channel when you are upgrading your cluster yourself. Now, upgrading a cluster could seem a little bit tricky, right? Maybe some risk to that.

(06:00)
But actually what OpenShift did, they made it very easy for you to do an in-place upgrade. You basically log in, you say, “I want to have this version”...this is the upgrade pad, press the button, sit back, and watch the show. So now OpenShift will start updating all the different operators and the nodes, right? And the cool thing is, if something goes wrong, OpenShift comes with building rollback capabilities, so that we still can give you a functioning platform and a functioning cluster, and modify it as you see fit. So this is how it works with upgrading and what we do support and don't support at the end of the day. If you think about it, it's “N minus 2” from a supportability perspective. And feel free to upgrade to the latest, greatest version as long as you stay on that stable channel.

Roberto Carratala (06:51):
Thank you very much, Roy. It was very insightful. So around the access and also the role-based access control that you can have in the different ARO clusters, how is this working?

Access and role-based access control in Azure Red Hat OpenShift clusters

Roy de Milde (07:06):
Sure. So I think there are two parts to this question. And first thing first, we also have an Azure active Directory. And with Azure Active Directory, you can actually connect this to your Azure Red Hat OpenShift cluster. So people can use their active directory credentials to log into the cluster. Now obviously, Azure Active Directory comes with a lot of cool security features and also identity and access management solutions, RBAC, etc. Right? So that's the first part that's hooking in the identity provider to your Azure Red Hat OpenShift cluster. Right? Well, the second part is obviously leveraging the RBAC capability that OpenShift put on the table. So we can do group sync, for example, and we can specify all kinds of role-based access controls inside of the OpenShift cluster, making sure that the developer can access, for example, only the developer portal and a specific project. Maybe the administrator of the cluster can do a little bit more and can trigger an upgrade or do an additional machine set build. Right? All those capabilities are built in, and we can do that with the RBAC capabilities of OpenShift and the combination with Azure Active Directory, as well.

Roberto Carratala (08:15):
Brilliant. And you can control the fine-grained access control, giving the proper permissions and the proper roles to the different developers and their ops teams, as well. 

Roy de Milde (08:25):
Yeah, 100 percent.

Roberto Carratala (08:25):
Brilliant, thanks.

Roy de Milde (08:27):
Sure. So Roberto, we talked about what the SRE team does, and who's responsible, and stuff like that. But, obviously, there are also customers in play, and they do custom things to the cluster based on their workloads. So, how would you explain in your words how that responsibility looks like?

What does the customer do with Azure Red Hat OpenShift clusters?

Roberto Carratala (08:44):
Alright, so ARO ships with a default configuration and also with our default operators that are managing the different pieces within ARO clusters. So the customer is responsible for their own applications, workloads, and also data that are stored on top of ARO clusters. So imagine that one customer is deploying one workload and will be responsible for this specific workload, and also the data that is deployed within the different ARO clusters. And also imagine that this customer wants to deploy also. A third-party will be also responsible for that. So essentially, the SRE team will look after the different operators and the different configuration, and the customer is responsible for their workloads and the different data that are deploying from on top of the different ARO clusters.
 

Roy de Milde (09:46):
Okay, cool. So the way I'm hearing that, everything a customer does specifically based on their needs and requirements, they also carry a responsibility in the lifecycle management, the backup, if they need that. Okay, cool. That's very insightful.

Roberto Carratala (10:03):
Yeah. And sometimes it's a little bit tricky to understand that. So check also the description in order to go to the official supportability metrics and learn more around the different supportability features and the customer responsibilities, as well.

Roy de Milde (10:23):
Awesome. Thank you so much. And if you want to learn more about Azure Red Hat OpenShift, we actually created a couple of really awesome videos. So go check them out. Another thing that you can do is reach out to Microsoft or Red Hat to help you and support you along the way. Thank you.

Roberto Carratala (10:37):
Thanks.