 Hi everyone. Thank you for joining today's session. Today we're going to speak about OpenShift multi-cluster management with Red Hat Advanced Cluster Management for Kubernetes. My name is Andrés Valero. I work at Red Hat as an OpenShift Specialist Solutions Architect, and today with me is Mario Vázquez. Hello everyone. My name is Mario, as Andrés said, and I work at Red Hat as a Senior Solutions Engineer. So for today we have a short but intense agenda. So first of all, we will introduce the main challenges we find when we try to manage multi-cluster environments in a hybrid cloud landscape. We will introduce Red Hat Advanced Cluster Management for Kubernetes, or ACM for now on. Then we will explain you how ACM and GitOps work together. And last but not least, we will deliver a demo where we will see the main features of the product. So as I was telling you, managing clusters, Kubernetes clusters in a hybrid cloud environment or multi-cloud environment is something hard. So these kinds of landscapes are ever too prone. Definitely the configuration and security management for these clusters is something that can be really overwhelming. Deploying applications, manage the updates in these different clusters across different clouds, different platforms is a really challenging task. And also, finding a managed resource in such environments is time consuming and sometimes can be really, really complicated to debug when something is going wrong in one of our clusters. So for help us in all these challenges and all these problems and more, we have Red Hat Advanced Cluster Management for Kubernetes. For ACM, we have four big areas or what, as we say, four big pillars that we work to help you or to help customers with the multi-cluster management. First of all, that is the multi-cluster lifecycle management. So to be able to manage the lifecycle of different clusters from ACM, we can manage not only OpenShift but other public Kubernetes services like AKJS, AKJS, GKE, et cetera. But just for OpenShift, we can have a full lifecycle. So we can create and destroy OpenShift clusters also. We can also help you to enforce the configuration management in the different clusters and to make them secure using policies. It can also help you with the application management. So we are able to deploy applications. We are able to manage the updates to make sure that the right application lands in the right cluster. And also we can help you with the high availability of applications and you'll see that later on in the demonstration. But in these two areas, in policy and application management, GitOps is something really important and is something that later on Mario will introduce to you. And last, multi-cluster observability for health and optimization, but not only for this. With all the tools that ACM provides you, you can not only have information, but you can also debug. You can manage resources, Kubernetes resources across all your clusters. In ACM, we have this main, this is the main dashboard where we can just really quick see and have a general idea of what's happening in our clusters. We can see which platforms, which clusters, kind of Kubernetes, state of the pods, if our clusters are not compliant, etc. So we can quickly know what is happening in our federated domain. Then with the policies, we have a powerful tool that will help us to centrally manage and enforce security and configuration to different clusters. We are compliant with CIS and other security standards, and we have also now integration with OpenPolicyAgent. In the application lifecycle management, we can, as I already introduced you, we can deploy application from different and multiple sources. We can deploy at scale, manage the upgrades, manage where is happening what, where are deployed, being deployed applications. And now we have also integration with Ansible when we are deploying applications. So for instance, we can have a pre-task and a post-task. So if we are deploying an application, we can do something like, for instance, opening a ticket in ServiceNow, then deploying an application, and last, configure a load balancer to access to our application. That's something that now we can do in a single step on ACM. And now I will hand it over to Mario. Thank you, Andres. So we are going to see how GitOps comes to play with ACM. So let's do it. So what's GitOps? A brief introduction. So GitOps is a way of deploying applications or configurations to your Kubernetes clusters using Git as your main source of truth. That means that every object that you want to get created, modified or deleted on your clusters will be stored in a Git repository. And that way you will have a record of who, what, and when a change was done in your environments and also it will allow you to, it will allow your teams to do code reviews before doing a change or have different levels of approvals. Mainly take full control of all the changes that are done on your data centers. And then of course, we can use the Git commit history to restore the environment to our previous state. Okay, but how GitOps work in ACM? So we have three main objects, the channel object, the subscription object, and the placement rule. So what is what? The first one is the channel object. The channel object defines a source of information. In this case, if you look at the left side of the screen, you will see a Git repository, which is of type GitHub, meaning that it's connected to a Git repository in GitHub, which has the, in this case, the files required to deploy our application, a deployment, a service, whatever we need. Then we have the placement rule. The placement rule, it's where, where we want to deploy those objects. So in this case, in the right side of the screen, we have a placement rule, which has three main configurations. Let's start by the cluster conditions. So the cluster conditions is a way that you can use for only getting the clusters that are currently available, which means that are up and running, and there are no issues on those clusters. Then we have the cluster selector, which as you can see, have a label matcher. In this case, it says environment equals depth. And last, we have the cluster replicas, which in this case equals to one. What this means is that from all the clusters that are available in our infrastructure, we are going to get only those which has the environment depth label. And then from that list, we only want to get one cluster. That means that if we have five clusters in the dev environment, we will get one of them for deploying our application. And then we have the subscription, which is like the glue between the channel and the placement rule. So in this case, we are saying, okay, we want to deploy this channel and we can use then annotations to filter which objects do we want to deploy on the cluster. In this case, if we look at the annotations, we can see that we have a git path, which says up, lifecycle, ether path, and then a git branch, which says main. So this way we can actually filter what objects within the repository we are going to deploy. So for those of you who are already doing GitOps, you know that you can have your repositories organized in different branches or maybe using different folders. So with these two annotations, you can play with that. And then in the specification, we have the channel, which says we want to deploy the ether path up latest channel, which is the one pointing to the GitHub repo. And we want to deploy this channel on the placement rule called ether path PR, which is the one that matches the depth cluster. So we will see how it works in detail in the demo. And we have been talking about a Git type channel, but we support also Helm repositories and object storage, meaning that you can deploy your Helm charts or even if you have all your deployment files in an S3-like storage, you can use that as well. And of course we support almost any Git server out there, GitHub, GitLab, Gox, et cetera. Okay, and now we are ready to start with the demo. I will hand it over to Andres, who is going to introduce us to the ACM web UI. Hi again. Now let's go in to see the product. Let's go in to see what ACM can do. So this is the home screen of the product. And as you can see, there are four big areas. So the four pillars I've poked to you a few minutes ago. We have the cluster lifecycle, visibility, application lifecycle, and the governance risk and compliance. So let's move on to the cluster lifecycle. So in here, we have a list of all the managed clusters. And as you can see here, we have a cluster here in Amazon, another one that is running on bare metal. And we have the local cluster that is also running on Amazon. Okay. So we are managing also the cluster where ACM is running. From here, if we are managing OpenShift clusters, we can upgrade the clusters. Okay. And we can also create and import existing clusters. So between the clusters we created and the cluster we import, there are few differences. For instance, if we go inside this Amazon cluster, we created this one using ACM. So we can here see that we have the credentials accessible. We can download from here the key config and the install config files. And also from here, we see all the options or all the options we have to manage this cluster. So edit labels, connect to the cluster, upgrade the cluster, search Kubernetes objects inside the cluster, detach the cluster that means stop managing the cluster. And we have an option this destroy the clusters. So as we created this cluster using ACM, we can also destroy this cluster using ACM. However, if we go to the bare metal cluster, we can detach the cluster, but we cannot destroy the cluster since we didn't create this one. We just imported it. When we want to import the cluster, we go here, we provide a name like, I don't know, Andres. We apply a label that usually is the cloud or we can just leave ACM do it. And then we click on generate command and it will generate a general file in coding base 64 that we have to run in a command, a QCTL command against the cluster we want to manage. And that will create all the resources we need to be able to manage that cluster. But we can also create a new cluster. So for instance, we can say, OK, Google Cloud 1. And we can select the Google platform and just providing some few information here in this, in this formulary, we can deploy a cluster using Hive and the IP installer. And we can also click here, enable the YAML. And we can see here all the YAMLs that is going to consume Hive and the IP installer to do the installation. And as you can see here, we can deploy clusters in Amazon, in Google, in Azure, in Beesphere, and in bare metal. So we got a lot of options from ACM to deploy OpenShift clusters. There's something I forgot to show you is inside the clusters we can get some extra information like the nodes, but this is an important thing. These are the add-ons, so the agents we deploy in the managed clusters to perform all the operations. So in here, we can see in the different clusters the state of those agents. So if sometime there's something that is not working as expected, we may have a problem here. So in here, we can check. Now let's move on to the main dashboard. And as I already told you, we have here the main dashboard we can see in a very easy way. The platforms or the clouds we're using, the amount of clusters, what's happening in those clusters, bots running, et cetera. We can see also if the clusters are compliant or not. And we can also filter this dashboard in here using these labels or using the labels that we assigned to those clusters. And we can filter and let's say see only the depth clusters or we can see just the bare metal clusters, whatever we need to see here. So this is pretty useful. We have here this little Grafana icon. So if we click here, obviously we go to a Grafana dashboard. And in here, we get metrics and information of the managed clusters. For getting this information, we get a Thanos instance with an S3 storage and we can configure the persistent we need for this data. And we are using PromQL to get all this information and you can build your own PromQL queries in order to extract different information if you need it. So not only few information, also metrics from the clusters and last but not least we have here this search engine. This is very, very, very powerful. And here you can see there are some pre-booked filters and these are filters that I created myself. So for instance, this is a filter that looks for deployments created in the last hour. No deployments created in the last hour but there are some stuff created in the last hour. That's perfect. Now let's going to repeat a search. I'm going to search for deployments in the cluster Amazon manage one. And immediately we get here all the deployments in this cluster and we can click on one of those. We see the channel definition and we can edit whatever object from here. And this is equivalent and OC edit common. But we can also, for instance, click and delete or by clicking here and pasting some jammer code and selecting which cluster we want to create something we can create new objects in our manage clusters. And in here you are seeing a lot of small squares here. These are the objects that are all the objects related with all these deployments. So when we use the search engine, we don't just get what we are looking for but all the related objects. This is important because this can make our life easier when we are debugging something. But we don't only have these tools, we have also the visual web terminal. This is like a CLI on asteroids. This is something I like a lot. From here we can, for instance, say, OC get pods in the open cluster management name space and we, obviously, we're going to get the pods in there but we get this improved output when we can see different pods, the state. We have some information but we can also interact with them. For instance, we can click this bot and we will get here summary with some information, basic information about the pod. We can see the events in the last hour, if any. We can see the logs of the pod. We can connect to the terminal in the pod and this is pretty cool and we can also see the Jamel definition. And this by itself is pretty powerful and this is working not just with OC but with OC, with QCTL, with Helm and Istio CTL. But from here we can also use the search engine like we did a few minutes ago. So we can again look for deployment in one of our clusters, let's say in the bare metal one. We can click here and we get all the deployments again or even we can click and see the resources but in a different way, but just from a single place. So from here we can perform commands, we can connect to the clusters, we can get information, we can search for resources. So this is pretty powerful. And now I will hand it over to Mario that will show you some cool stuff about the application. So Mario, it's all yours. Okay, thank you Andres. So we are here in the ACM applications. So what we are going to do is we are going to create a new application and in order to that we can use the web UI. So let's give it a name. In this case, it's the etherpad application. Then let's use this name space here, etherpad. And now we are using Git to get our application deployed. We already have this repository configured, so we are using it. Then we have a special branch which is called DefConf. And what we are going to do now is we are going to configure the path for this application. So in this case inside the repository we are using the branch DefConf and inside that branch we are using the folder AppLifeCycle, etherpad AWS to deploy our application. So as Andres said before, we could set up pre and post deployment tasks with Ansible and then we can choose which clusters we want to deploy the application to. So in this case, we want to target any cluster which has a label cloud equal to Amazon. We can add multiple labels or we can deploy to all online clusters on the local cluster or we can just deploy to a local cluster. Local cluster meaning where ACM is running. Then we have deployment windows where we can choose when this application can be deployed. For example, we can block specific intervals or allow specific intervals. For this time, we are using an always active which means that the application will be created right away. And then we have the YAML file here on the right side. So we can use the web UI to create our applications and then of course we could take this YAML file here and upload it to our Git repository. Although that's not the way GitOps work but for this demo we are showing it this way. Okay, so we created the application and now we will see how the different objects start coming up. Okay, so here we have the application deployed. As you can see in the placement we said that we want any cluster with the cloud Amazon label and we can see here that the application has been deployed to two clusters to the one AWS managed one and to the local cluster. Okay, so we have our application deployed on both clusters. We can see that the deployment is still not ready so let's wait a bit and now it becomes ready. So what we are going to do now is we are going to access our application. We can click in the route. By the way, these are all the objects that are being created by our application and now you can navigate the different objects and you can get different information for the objects. You can view the YAML definition and so on and so forth but we don't have much time so let's go to the application. So I can open this application here in my browser and you can see that it's working and the same goes for this one. Okay, but now let's say that I have a bare metal cluster and I want this application to be deployed to that cluster as well. So I need to edit this application. So let's do that. I'm going to edit this application and I'm going to add a new repository. In this case, it will be the same repository that we are already using, same branch but my bare metal cluster uses different files. So in this case, the files are under bare metal folder. And then I already have a placement rule for this cluster, which is this one that will target any cluster with its cloud label is equal to bare metal. So this is the things that we are doing and now the application should be updated so if I go back, I should see that now the application is deployed on two clusters, right? We have, well, on three clusters. We have the other two clusters that were deployed before and now I have a new one, which is called PMManage1 and here I can see that the different objects are being created as well. So I have the route, the service, everything's the same. We just need to wait a bit for the deployment and now the deployment is ready. So let's access this application. Okay, so we have the application ready, right? So that goes for the multi-cluster. Well, you can see how you can deploy your applications to multiple clusters and now we are going to show a very simple disaster recovery scenario. So in order to do that, what I'm going to do is I'm going to delete this application first. Okay, remove everything related to the application. So I don't want to keep that, right? So now we can start from scratch. All right, so let's click on create application and let's give it a name. In this case, the name will be Etherpad PR, right? And now, sorry, DR. And now we are using the same name space as we did before. We are using it again, same repository. In this case, the branch is the same and the path will be DR, right? So now what we want to do is we want to use an existing placement rule. In this case, it's the one which is called DR and we will see how that placement rule looks right after this gets created. So now we created the application. The application will be deployed and let's check the placement rule. So in this case, the placement rule is different. If we look at the YAML, we are using the managed condition true available. So the managed cluster condition available true, which means that the cluster is up and running and everything is running well. And then we have the cluster selector, which has two expressions. In this case, we want any cluster which its cloud label is set to Amazon or bare metal. And then we don't want to get any cluster that its name is local hyphen cluster. And from that list, we only want one cluster replica. That means that we will get one cluster on Amazon or one cluster on bare metal. Let's see what we got. So if we go back to the application view here, we are running on AWS, right? So let's refresh to get led to state. Now everything is ready. So now we can access our application on AWS. Okay. Now in order to simulate that the AWS cluster goes down, what we are going to do is we are going to edit the placement rule and we are going to remove the Amazon selector. That will make that the cluster, the Amazon cluster will not be reported but back by the placement rule, which means that the, that ACM needs to relocate that application somewhere else. In this case, it will be the bare metal cluster. So let's click edit. And now I can click save. And as soon as I do that, if I go back to the subscription, sorry, to the application view, and I hit refresh, I will see how now the application has been moved from AWS to the bare metal cluster. And at this very moment, it's been deployed there. So let's wait a couple of seconds until the application is deployed and we will try to access the application. So let's wait for the deployment to become ready. Okay, the deployment is ready now. So let's access the application. And you can see that the application is working. So this is for the demo. I just want to clarify that when you are running on a real environment, all the changes to the application should be done in Git. And in this case, ACM reacts to changes on the Git repository, meaning that if we now edit the deployment object on the Git repository, ACM will detect that and deploy the required changes to the required clusters. And with that being said, I'm going to hand it over back to Andres, who is going to show us how to work with policies. As I explained you before, from ACM we can use policies. But not only policies from here, from the UI or the policies with the tool, we can also use policies, fully customized policies from a Git repo using GitOps. But for now, for this demo, we are going to use one of the policies inside the cloud. So we create here in create policy. And we are going to create a limit range using a policy. So we need an AMI space. You remember anything we manage and everything we control from ACM, it's a Kubernetes object, has a general definition, so we need an AMI space. And in here we can select a limit range. This is basically doing or creating just a simple limit range for pods. Now we can select the cluster binding. So we are going to deploy as Mario already introduced to you. That is here a placement rule that we created based on what we select here. In here we can see the standards, security standards compliant, and the categories in control that the policy will be compliant with. So we have also this little check here that says Enforced Supported. So if we click here, there is a field inside the spec that is called remediation action that moves or changes to Enforce. We are going to unselect. We are going to create the policy in informed mode and in a few seconds you will see which is the difference. So now we're going to create this policy. And we click here, we see our policy just have been created. Now it is updating. We don't have yet the status. It is now recollecting the information. Now we can see that two or four clusters are not compliant. So the limit range, mem limit range, does not exist in this concrete cluster, neither in this other one, but it is in this cluster. So in here in the status, we can get the detailed information about what's happening. And also we can track here the history and the changes of the different steps or components of a policy. So let's move back to the policies list. And now we are changing the policy. As we can see here, the policies in informed mode, that's okay. We will change it to Enforce. In the meanwhile, I'm going to show you the main dashboard and we'll see that in here it's a start telling us that we have two clusters non-compliant and one that is compliant. So let's move back to the govern area. And now we will see some changes. There are already a cluster that has changed. In the managed clusters, we deploy controllers, Kubernetes controllers. And these Kubernetes controllers work in the expected way. So I have a definition, something that I define as the desired state. And they control also the actual state. And if the states don't match, the controller will make it match. So now our controller, what has done is to create this limit range in the clusters that it didn't exist. And now, if we go again to the main dashboard, we'll see that our clusters are now compliant.