 So hello, thanks for coming to this talk. This talk is going to be about the Crano and about our blueprint family that is called Cobernate Native Infrastructure. It is a blueprint family for specialties for the edge. So I am Yolanda Robla, I work for Red Hat. This talk was going to be co-presented by Ricardo Noriega, that is my colleague but he couldn't come so I'm going to be presenting myself. I work for Red Hat at the office of the CTO and I'm a principal software engineer there. And I mostly work in open-shift, co-ordinates and special use cases for the edge. So I'm going to be talking about that. So first of all, let's talk about why the edge and why it's important, why it's computing. So currently there is a lot of demand for real-time processing capabilities because I'm facing a need to place computing at the edge where the user is instead of relying on centralized clusters. So by doing that, we are bringing more processing and storage capabilities closer to where the user is, to the user endpoint. And it's also reducing the cost of ownership. It enables faster processing depending on the needs and it also allows to meet data-specific privacy rules as well depending on the country. So as you can see here on this schema, we have different layers where to put our workloads. So first we will have what we have called the backbone that is going to be like, we are going to have like tens of that. It can be like centralized clouds, public clouds, hybrid. So we don't need really a specific accelerator there. We don't need real-time. The time of response can be lower. And after that we have a different layer that is called network edge. Here we will have like thousands of those. It really needs more like more capability, real-time processing. It is operated by Terco and we have, we need to have like a small time of response there. It's typically accessed by 5G, by LTE, by Wi-Fi. This is operated by the network, by the towers itself. And then finally we have what we were using in the user site. So it's the last mile network. Normally it is going to be at homes, devices at home, at the stadiums, smart cities, whatever, public buildings. So we also need to have a real-time processing there, optimize it and less latency as well, like over 5 milliseconds as much. And typically we are using mobile, virtual reality devices, drones, cars as well. So that's why the need for the edge is raising. So Acreino is an edge stack, it's just a community. We are a community that is called Acreino. And it's an open source software stack that wants to improve the state of the edge, the cloud infrastructure for carrier, for provider and for Internet of Seeing Networks. This community belongs to the Linux Foundation Edge Organization, FH. And currently it's composed by more than 11 blueprint families. And these blueprint families want to support a lot of different use cases, like 5G, machine learning, video processing. And the goals of this community are to drive faster edge innovation, to do it faster, provide an end-to-end ecosystem, like we are focusing on everything, from hardware, configuration, applications that run on top of it. We want to improve the user experience for deploying sites on the edge, also with the goals of providing edge cloud interoperability between different clouds. And important, we rely on open source, we want to use it and we want to improve it. What's going on? Okay, no, no, no. It was like, no, it's okay, it's okay. Okay, so I was explaining before, a typical service provider will have like thousands of edge sites. They can be deployed at a cell tower and an office. So we need to have this end-to-end automation and we need to have zero touch provisioning to minimize the cost of operation and provide more agility, ability to scale. So for resiliency, the deployment is following a hierarchy, okay? So first we will have the central sites, as we mentioned. Then we will have the regional sites, we will have thousands of them. And then we will have the user sites, okay? So three different layers there. Okay, so to just allow the same deployment on each layer, we're using blueprints, okay? A Crayon is a composite of multiple blueprints. As I said, a blueprint is a declarative configuration of an entire stack, like for specific use cases. We can have blueprints for machine learning, for 5G, for video. And it relies on a reference architecture that has been developed by the Crayon community and accepted that. So this declarative configuration is used to define all the components in the architecture. From the hardware, software, applications that will run on top of it, methods of deployment, everything is defined in this blueprint. And currently, our blueprint family that is called KNI, Covernetis Native Infrastructure, this one's to achieve it, all the declaration, we want to achieve it using the best practices of Covernetis and all the ecosystem, okay? So we will define all the stack using just Covernetis tooling. So why we choose Covernetis? Mostly because it is a very popular tool, it has a wide ecosystem, and it has, what is very important for us, it has a very rich orchestration and lifecycle management for deploying applications and components on top of it. So we are relying on Covernetis in our blueprint family, sorry. We are using OpenShift and we want to arrive to use OKD as soon as it's stable enough that is like the vendor oriented, like OpenShift is just for Covernetis and Red Hat and OKD will be just a free version of it. And we also rely, for example, on Rook to have storage, like Chef. As we want to achieve a hybrid deployment, we are focused on just optimizing for Covernetis, like creating CNFs, mostly deploying CNF on top of the cluster, but in the case that we also want to deploy BNS on virtual machines, we want to use Cupid for it and well, more components like that we are using operators, Covernetis operators to achieve the lifecycle management. We're also using Prometheus for like monitoring. So everything that we are using is just Covernetis, so. I wanted to talk a bit about how is this operator pattern of Covernetis. So an operator, a Covernetis operator wants to capture the logic of a human operator. So imagine that you are an operator and you know what your app is and the actions that you need to take to achieve the final goal to deploy the application. So the Covernetis operator will just try to mimic the same. An operator is composed by a controller and a custom resource definition. So you declare that you decided state using the custom resource definition. For example, I can say I want to have machines. I want to have six machines deployed with CoreOS. I will have a custom resource definition that says that I want to upgrade my cluster to this version. I will have it. I want to deploy this application like Cupid or Cupidflow. I will have a resource definition that will tell Covernetis to do it. And under it, there will be a controller that is taking all the actions to arrive from the real state where we have nothing to the final state where the custom resource definition says that we want to arrive. So there will be a process where the controller is taking all the actions and wants to reconcile from the start point to the end point. It will be taking actions, which is mostly what a human operator will do. So we are applying this pattern across the whole stack definition. I will show you later. Currently, we have two blueprints in process. Well, I'm currently the PTL for the two blueprints. Mostly, we are focused on the provider access edge. It is optimized for real time, for networking performance, and we have the goals for deploying VRans and mobile computing workloads on it. For example, in KubeCon, we did a demo about deploying an open interface using these days. So what we have here is that we want to have a higher footprint because we need more masters and workers for the provider access edge. It's more than six. The service will be deployed with CoreOS and with CentOS RT. CoreOS will be mostly for the masters and for the workers that don't need any real time. But for real time, we are currently using CentOS RT. In the future, we also want to advance to CoreOS RT when it's ready. That will be the next version. As container runtime, we are using Cryo for storage we have Seth. Currently, for SDN, we have the OpenShift SDN. We are thinking if we upgrade to Tonsten or not. But for the moment, we don't have it. So as I said, we have Kubernetes for the cluster. Inside of Kubernetes, we have what we call the cluster a machine operator that is taking care of all the cluster upgrades, version management. And for monitoring, we have Prometheus. And this is the basic cluster. And then in top of it, we are deploying applications and workloads. So for the moment, we are deploying Qubit in top of the cluster. And then we are giving you freedom of deploying the CNFs and BNFs that you want to apply on top of it. And in the future, we are also thinking on industrial edge blueprint that has a smaller footprint, like less machines. And it's optimized for low latency IoT and machine learning workloads. So as you can see, the base is the same, but we have less computers there. And currently, the storage and container runtime and SDS is the same. But what it changes is the applications that we are deploying on top of it. So we will be deploying Qubit as well. We will be deploying Qubeflow optionally for machine learning. So you can have Knative for serverless. It will depend a lot on what type of applications that you are planning on it. So what are the components of a blueprint? I will be showing it with more detail later on a demo, but for the moment I will explain a bit. A blueprint is just basically what you can see in red. But we also have an optional installer tool that is helping us. I mean, what we are doing basically is deploying Kubernetes with a set of manifest, a set of YAML files per the file. But we have this installer tool that is a helper that allows to merge all the manifest in a single set of final manifest that are going to be used for deployment. So you can see the link here that is our currently provided access edge blueprint. This is composite by three different layers. So we have base, profiles, and sites. Base is mostly all the core components for the deployment. And it will not change depending on the profile. So for base we will have like the basic manifest to deploy, open shift, Kubernetes, and general workloads. For example, Qubeflow for example is a workload that is in top of base. After that we can have profile that is a specialization for the different types of deployment. So with the same blueprint you can deploy to different platforms. So you can deploy for LeadBear, Amazon. You can deploy for varemental as well, real varemental hardware. That is what I'm going to be showing later. And then we have sites. A site is just more specific set of manifest to customize the specific settings. Like for example, for different sites I want to have change my domain. I want to change my name, network, interfaces. We are having a specific configuration for it. And well, for the profile varemental that I'm going to be showing, we will have like a specific workloads also that for example you cannot deploy SRIOV with LeadBear or PTP. So these are special configuration and special workloads that will be just applied in the case of varemental. For LeadBear and for Amazon you can have different ones as well. But the important is that you can see that everything is declared on the same and it's reusing. It's like there is an inheritance process. A site will inherit from a profile and a profile will inherit from base. So mostly this is how the site will look like. We are going to use a tool that is called Customize. Not sure if you know about it, but it's a way just a tooling used in Kubernetes to just do a work with manifest and allow customization of manifest depending on your sites. It's like using a hierarchy of different YAMAs files to compose a final one. So you can see it's a sample site that is based on LeadBear. So we'll have a first line that we are pointing to the blueprint and we are pointing to the profile that is LeadBear. And then we will have a set of patches that will define like the real settings that we need to have for our site. It's mostly that we are going to define the site name and the domain. So you can see it here. This is the site definition, generic site definition for LeadBear. You can see that we have a generic name, example.com. We have generic network as well. But as we apply the manifest from the site, we can change the domain name. We can change the site name as well. So we will be composing some final sites. And after that I'm going to do a demo so it makes more clear for you. So here we have edgy that was our smart network operator. So the process of deploying a site will be the following. First we need to download all the installer tools that I talked about before that is called Kai and ICTL. After that I'm going to create a site. It's just mostly creating a set of YAMAs files that will inherit from our blueprint. Also now the next step is to face the requirements. So in the profile definition we have a YAMAs file that is going to define all the versions that we are going to be using. So we're going to be installing the OpenShift, OpenShift installer, the OpenShift client, customize with specific versions so all the clusters that you deploy are going to be the same. And after that there is going to be a manifest preparation so all the YAMAs files that I showed for different components are going to be merged together and they are going to be prepared for the installation. There is going to be also in the case of bare metal there is going to be also a specific configuration for networking for dependencies as well. Some tooling also to spin up the bare metal nodes. We're going to start some IPMI dependencies as well. After we have it ready we're going to just go to the deployment of the site. Deployment of the site is going to be done into steps. First we are going to deploy the masters and after they are up we are going to deploy the workers. When we finish that the cluster will be just up and running. It is going to be like a cluster, very vanilla cluster without no much configuration but then we are going to apply the workloads on top of it and when we apply the workloads we are going to do the specific cluster customizations. So we can change the realtime, for example, a node that is not realtime, we can change it to realtime. We can add extra functionalities like SLOB, support, PTP support as well. We are going to install the cube bit or any other workloads that we want to have. And then finally we have our network operator that is happy because he deployed a cluster with everything is automated, everything is on GitHub, so you can just to deploy another site what you will do is that you will create a set of YAML files, you will change the names, the domains and that's all. The basic blueprint will always be the same. So now it's demo time, so I'm going to show it because it's going to be more clear if I can show a video for it. Let's go. So first of all I'm going to show the structure of a blueprint that I was talking before. So here you can see this in GitHub, this is our blueprinter. You can see that we have base. This is the basic configuration and you can see all the components that I was talking before. So install config and cluster mods are going to be running when you are deploying the cluster. You can see that we are using Customize. So Customize is the tooling, not sure if you know how it works but Customize allows you to just define a set of manifest and you can configure specific things over it and you can just inherit it. Okay, what's that? How do I have it? Good, no? Maybe some alert? Very good. Okay. Okay, so you can see here we have the different patches as I was saying. So this is the generic one for bare metal. No, so this is the generic one for base. Totally generic. Okay. Also we have cluster modifications here. So normally it's a vanilla cluster but we have some extras. So, okay, for example, we're having some extras here. So we're, for example, changing the number of replicas of the cluster. Also we have added some extra tooling to auto-approve certificates because we want to automate the enrollment of the worker nodes. And then we have what we call cluster add-ons and services that is deployed after that. So you can see that we are, like, deploying a set of worker nodes like QBeat here and some MacVilla and IPVilla as well. This will allow that when we apply worker nodes, QBeat is just deployed automatically using operators. Then we have profiles. I was saying that we have Amazon bare metal and Libby. I'm going to be talking about bare metal. We have the same structure as on base and we have this extra requirements file that is showing all the binaries that we are going to install. So we can control all the time what we want to deploy. And then the same, we have customization file as Relay and Customize. And we have this specific patch for bare metal. So we are changing now the type, the number of workers and masters just for bare metal. And for cluster mods as well, we have extra configuration for bare metal. We are changing the replicas as well. So you can see that we have modified from the base to bare metal just by applying some extra manifest. And we are also, as we are adding Chef, we are adding some storage there. And also for bare metal, we are adding extra components like real time, for example, or PTP, like we are adding some extra storage for Chef as well. You can see all the files there. This is just done if you are deploying on bare metal. This is for real time. For example, this is how we are real time workers. And then we have sites. I'm going to be showing my site. So this is what I'm deploying. So you can see the structure is the same again. But we have a specific patches to change the sign name, to change the domain. So by doing that, if you just create a site like that, you are going to deploy like thousands of clusters based on the same blueprint. Just changing these files. In the case of bare metal, we are also adding like some network configuration. We are doing the definition of the host, so my masters and workers with IPMI, with credentials as well. Also inside configuration, we are deploying all my network settings that, of course, they are changing on site. This needs to be specific for each one. Same here. We are not doing any modification. And also in cluster add-ons, for my site, I need to change my interface's name because it's different for each installation. So you can see here that we have some patches to do it. So I'm changing my site, my nick for this specific one. So I'm going to prepare the deployment first. I assume that I have the installer already downloaded, that is here. So next thing, I'm going to create a site. I have one site that is already there. You can see what I showed before. And I'm going to face the requirements. This will download all the components that I specified on requirements.yaml. So I'm sure that all the sites that I'm deploying has the same version for everything. Okay, so it's going to take some time. You can see that it's installed like Kubernetes, Customize, Qubectl, the typical tuning for Kubernetes. Okay. After that, I'm going to prepare manifest. That is going to prepare all the YAML files but it is also to add all the dependencies that they are needed on my installer host. This is going to do all the network configuration. It's going to create some pods to have DHCP, to have IPMI control as well. It's going to also it's adding some pods for DNS. You can see all the process here. It's installing more dependencies as well. When we do that, we have the installer. Okay. When we do that, we have the installer host that is up and ready to start the cluster deployment. It's on. After that, I'm installing the cluster itself. It's mostly going to be done into steps. I'm going to deploy the masters. It is using Terraform. So it has a set of Terraform files to just start the power on the nodes by IPMI and then it's going to be relied on this DHCP and DNS pods that are running on my machine. So first of all, it is starting a bootstrap VM. The bootstrap VM is like the core VM that will be expanding the whole Kubernetes cluster. So you can see that it's starting here. After that, you can see that the masters are already up. Okay. It's doing some initial configuration. And well, after someone, you can see that the master is up and running after that. I do the same for the workers. Simple commands. So it will deploy all the workers that I informed on the blueprint. In this case, we have just one worker. It is going to be more or less the same. It starts all the process there. And after somewhere, you can see that the worker is there. It takes some time to join the cluster. The whole process will take over 20, 30 minutes. You can see that it's doing all what I told you about operator reconciliation. This is what you can see here. It takes a lot of actions to just have the worker up and running. And after that, I have my masters and workers ready. So just time to deploy the workloads on top of it. A simple command like apply workloads. I point to my cube config there. And it does the same. It distorts a lot of operators. And it's taking all the actions to just deploy cube build, to deploy the real-time workers, configuration about SROV, PTP. So that's mostly all. After you finish the process, you have a site totally deployed with all the configuration based on YAML. So you can easily reproduce to create a new site. You just copy the site manifest. You change your names, interfaces, and just do it again. So that's mostly all. So you have any questions? So the question is for this demo deployment that you just did, did you do it on bare metal? Yeah. Okay. In terms of hardware, it's not so much. I mean, we are using OpenShift. I mean, it's a Kubernetes typical requirement. So in this case, what we require is two nicks, because we have one for provisioning and one for bare metal. In terms of memory, it will be over 16 gigabytes. If you have real, well, you can have real time on workers as well. And if you want to have SROV, you need to have the nicks for that. Enable. Enable supported like Melanox or these kind of things. But no, it's like the usual Kubernetes requirement, not so much. And we also need to have an extra installer host that is going to be running all the Bustra VM on all the pods for DHCP for bare metal. So for example, if you want to do a minimum deployment, it will be the installer host, one bare metal node, one bare metal node for the master, and one bare metal node for the worker. Okay, cool. So, anyone else? Okay, so thank you. You can do it. You have time, yeah? No, we are using the typical, we have been deploying with different hardware. We require mostly that the more hard requirement is to have two nicks. That's mostly all, but no specific. I mean, it's just a generic one. You can run the deployment, you can run it on whatever you like. I mean, depending on the applications that you want to run on top of it, and the masters are not requiring so much. Depending on the workloads that you want to deploy and how demanding are there, you may choose different hardware for the workers. But not really, we have our footprint, we have been testing that with 16 GB nodes and like all CPUs and not so much, not so much requirement for it. You want to try and also if you want to scale you can just grow as long as you want. Okay, so thank you.