 Okay, so I will talk about how we run containers in the EGI federation and I will start a bit about introducing the EGI federation. I just realized I have a wrong data here in the slides, but I will fix that. So starting with what is the EGI federation? So this is something that we started back in the day around the 2010 and a bit earlier. There was a lot of movement around the high energy physics collaborations, this compute grid, the WLCG, which is about setting an international infrastructure for supporting these experiments at CERN. The grid technology was kind of created and that evolved gradually into a more multidisciplinary multi-technology infrastructure where not only the WLCG, the high energy physics people were supported, but also any other kind of scientific communities from, let's say, Birgo, which is also physics, Ice Cube is also physics, but WNMR, LSST, it's about the biology, and so it's oceanography, and it's climate change. And there are more than 250 of those communities now being supported. And we started with this grid, but now it's basically an infrastructure with several ways of accessing advanced computing and data analytics for research and innovation. So this is the kind of notorious lights about EGI, our vision and mission. So the vision is that all the researchers have seamless access to services, resources, and expertise to collaborate and conduct work-class research and innovation. And the EGI federation supports a vision with the mission of delivering open solutions for advanced computing and data analytics in research and innovation. EGI is a federation and it has a management body or a coordination body, which is the EGI Foundation, which is the institution I work for. And our mission is mainly to enable this federation to exist and to serve international research and innovation together. We have in the EGI federation, we have 26 participants. These are European countries. So we have an institution in each of the countries belonging to the federation, but we are also now engaging with international research organization that let's say the most well-known is CERN with the High Energy Physics community. But we also have NS, which is about climate, and so which is also anography. And we have also now associated participants which are countries that are getting into the federation, but not yet fully into that. So we have Staki in Hungary. We have BTP in Ukraine and ICAT, which is also a scientific collaboration in the Nordics. And we have the EGI Foundation located in Amsterdam as this coordination body of the whole federation. We are not just restricted to Europe and we try to have international partnerships with the rest of the world. I was thinking that we don't have a specific MOU with Australia, but if I'm not wrong, this is mostly dealt with the, right now with the collaboration with the Academy of Cynical Reccomputing Center in Taiwan that handles a bit the Asia Pacific collaboration. But even if we don't have a specific MOU, we will have a long collaboration with Australian partners and we have talked in the past about several topics. And we are now collaborating with ARDC and for example, in this container and stuff. All of the support that EGI has is done, or I won't say all, but most of the support to the researchers from EGI comes in the form of services and this is the EGI service catalog. So this is official technical services that we deliver to our users. We have a set of categories. The main one would be this computing storage data, which is mostly being able to access baseline compute resources for execution, any kind of applications. Today, mainly I would talk about the cloud compute, cloud container compute, high throughput compute. So this is an infrastructure service, the cloud compute, cloud container compute is running containers on top of that and high throughput compute is what it was used to be called the grid. It's mainly a bit of a batch system distributed all across different providers, more than 200 providers in high throughput compute in particular to deliver large computational power to users. Then we have the world manager that is able to manage those large set of providers in a uniform way. Storage we have on any storage is block storage, object storage, this kind of access to data, archive storage for more cold storage for waking up and data transfer for moving data around. Then we have a bit of higher level services, which will be the applications on demand that are very specific applications for some domains. The notebooks, which is a Jupyter interface for access and compute. We have a single sign-on service, this check-in that allows you to log in into every service with the same identity. And then we have a bit of training. 50 seminar is about IT service management. ISO 200701 is about security information management and then we have a training infrastructure to run tutorials and so on. So that's the AI service catalog. And we are not just alone, we are part of let's say larger initiative, which is the European Open Science Cloud, which I don't know if you have heard about it, but it's something that is going very strong in Europe. And the idea here is in 2016, the European Commission started this initiative of creating a virtual environment which would be free for the researchers and would be as open as possible and would allow to access data, fair data, and analysis facilities for those data, for any researchers and for any European and probably any worldwide country to do research. EOSC, this European Open Science Cloud has been developed in two phases. The first one was a bit about the design and putting things in order. That was until basically last year, 2020. And their EGI was coordinated, the EOS hub project, which was probably the biggest project delivered in EOSC until that year. And there we kind of created the framework for setting up EOSC. So we set up the core elements like the portal, the help desk, the monitoring and accounting, and we deliver all the service management system that needs to be in place to really deliver these two to the users. And EGI also contributed with our service portfolio to the service portfolio of EOSC. And now from 2021, there is an official institution dealing with EOSC, which is the EOS Association, this is an institution sitting in Brussels. And now we have a set of continuing projects. The biggest one will be EOSC feature that gets tries to develop this core concept of EOSC. And then we have others building capacity. And the main one for us is the EIAs project where we deliver the EOSC compute platform, which is a way to say that we deliver the EOSC, sorry, the EGI services, the cloud compute, the HTC, and all the rest to EOSC. And we align them with the EOS architecture. There are other smaller thematic services also around, for example, the series about policy making, EOS interviews is a regular project covering some parts of Europe and what we are participating on that. And EGI members of some of the countries are will be part of the national EOSC nodes. So we somehow are quite involved in this initiative. And EOS has a marketplace where you can order the different services. We have 30 of these services come from this EGIAs project. And looking at the statistics for the orders, you can see here the EGIA system on the 10 most order EOS services since 2018. And in particular, the EOS compute cloud, sorry. The EGI cloud compute is the most order one over the last year it's shown here. It was the most order one. So we have, we are let's say capturing quite a large number of users from EOS in the EGI ecosystem. And in this particular EGIAs project, we are delivering this EOS compute platform and we have allocated for free at the point of use for the user, a number of CPU hours, CPU hours and petabytes of storage for people to just use them. We have an open call for use cases. Maybe this is not so relevant in the student context because it's more for European, but just to tell you that we have this kind of open call where people submit their application and we do an evaluation and basically allocate some resources for them. And we don't do not only deliver the technical services and the resources, we also believe that a key element for making things happen is having user support. And what we do is, well, we have for each of the use cases, we assign an expert, we call the shepherds, that is guiding the use cases and kind of coordinating with the infrastructure to deliver what's needed to support the use cases. We have a training program. We have a webinar program running for two years now in the last year we had 10 of those webinars and we try to keep a regular pace of new webinars coming. Well, we have quite extensive user documentation. This was pre-bumped also last year. It's completely new documentation and we try to keep it up to date. And of course we have the providers involved and we have provider-specific supports for making things really work. And with all of that, we try to deliver one of these kind of different way of the EGI services, but we try to make it possible for the users to really engage in it with our infrastructure. What's coming here to be supported in EIOS, in consequence in EGI, it's we have this kind of classification of the different use cases by type. We have service hosting that would be kind of having web portals or databases typical hosting of applications. Then we have HTC processing, which would be using this HTC facility running jobs at a large scale. Then we have the cloud processing, which is the largest kind of category. In this case, we will be talking about spawning some virtual machines or similar to run any kind of application for doing processing of data. It's kind of generic, but this is more or less a classification we came up. Data spaces is a bit about, it's a bit a merge of service hosting and cloud processing. It's mostly people delivering data, alongside some analytics with a front end and people can just go there and do their very thematic or disciplinary oriented work. And then we have a bit of more or very concrete artificial intelligence applications. And what we have seen over the last years is that there is an increased usage of containers all over the place. So for example, in the HTC processing, people just do not want to run their regular binaries. They want to run containers as jobs in this HTC. For service hosting, we are seeing more and more Kubernetes as the platform to manage those services. And for the cloud processing, we are seeing a lot of containers, let's say plain containers or even Docker compose and also Kubernetes for managing the things. So we are seeing more and more containers as the way to manage the computing resources. We are also seeing an increase of the usage of CPU over the last year. So this is starting from March, 2013 where we set up our EGI cloud until just last month. And we see that there is continually growing of the consumption of CPU resources in the cloud. And since we started this first EOS project, the EOS hub, this has been increasing more and more. Over the last year, there was more than 60% more CPU hours, 43 more millions of CPU hours delivered over the last year. And we see that with the start of the CGIS, this training is continuing. And as I was saying, this is more and more container-based usage of resources. Just to show you a bit what kind of disciplines or scientific domains we are covering. This is from the open calls that we had with this project, the EEAAs. So far we had 20 applications over the four cut-off dates that we had. The next one is in December of this 2015. We are supported already with this virtual access, which means free at the point of views. Others are mainly redirected to the national partners because they were very national in nature. And three are under discussion. And you can see we are covering a quite wide range of disciplines. So agriculture, astroparticle, or cinematography, computer science, biodiversity, clinical medicine, music, so we are quite broad in the scientific domains. Just to show you two examples of what's coming with this EEAAs open call to give you an idea of what we do. The first one is this AIDA Lab. AIDA Lab is a platform where people can perform simulation workflows in a user-friendly way. It's mostly a Jupiter kind of front end that is very customized. So people do not even need to deal with code. They just point and click to create those workflow, install applications, run them, and potentially not just run them in the, in less in the located cloud resources, but also spawn them into HPC systems. And this is all running on top of Kubernetes on Sestent, which is our partner in the transfer public. And yeah, it's all about containers. So what we have done for supporting these people is to deploy Kubernetes and help them to interact with the Kubernetes infrastructure and help them also to allocate resources so computing and storage and to connect that to other parts of the infrastructure. And we have seen this kind of similar setup from then with an interactive way of accessing the compute and then talking to other platforms like HPC. This happens in several other use cases. We have, for example, DNS, which is about time and science, have a very similar setup. So again, kind of Jupiter from then where people just go, have the data, have the computing and can do their thing. This is kind of our recurrent pattern for some applications. Another one that's coming also recently, this is from the Thales institution in the Netherlands that's doing Earth of Innovation. And here they are doing testing of high resolution distributed hydrological models, trying to understand where these models and the data sets work or not. So they do like massive simulations with the model and they are using Kubernetes with the Argo workflow management system for managing the whole thing. So again, what we are doing here is helping them to set up the Kubernetes and helping them to access the computing resources and they are trying to do a substantial amount of simulation covering 50 years of historical data. So the initial request was kind of getting 1,000 CPUs but they are quite happy to access any amount of resources and the more they can get the better because they are just eager to do more and more simulations. And again, what we are doing is enabling these Kubernetes so they can run and just do their work. We do all of this on top of the EGI cloud which is our OpenStack Federation. Well, now it's OpenStack Federation but it used to be a bit more active in this and gradually people have, let's say, converging into OpenStack. So now we are, let's say, things are easier from a management point of view from a technology point of view because everyone is running OpenStack which simplifies a bit that sense. So this is a federated infrastructure where we have a set of providers located all across Europe and the idea is to basically allow international collaborations to perform their analysis with VM-based workloads and this is the main platform that we are using to support containers execution in EGI. Of course, it supports execution of VMs. It uses a federated identity so you can log in with the same identity everywhere. We have a common virtual machine image catalog. We have graphical user interface and command-line base access. We support orchestration and we have central counter monitoring. Some of this may appear a bit trivial. I mean, you can just have a common, let's say, keystone or similar pieces of opens that can make it happen but in our case, the OpenStacks are completely independent and we try to hook them with just components that talk with the public APIs. Try not to modify any of the operation of the different providers. We try to be more of a coordinated model. And we have 25 of these cloud providers, most in Europe but now we started with collaboration with China also. So we have like an international spawn or let's say more worldwide spawn. In 2021, we have three new providers and this is growing with EGI. This project, some more providers will be coming. So how do we support containers in here? I have this scheme of more or less what we do. So it can be a bit of running containers in IBM. So it's kind of you start a VM and you just run Docker there. Another possibility is using the HTC and there we have different technologies and then for more complex applications or users with a clear demand of Kubernetes we just use Kubernetes and we have two possibilities. So I will go into a bit each of the blocks in this image now. So the first one is the running Docker on a virtual machine image. So quite simple, just use EGI cloud compute to spawn up a virtual machine and run the containers. You can run any operating system and any kind of container runtime. So you can do Docker or anything else that you want. And of course you can select how large is the VM. And a bit to facilitate things we also have in our common virtual machine image catalog. We have one image that is meant to support this kind of use case. And we have said you want to, people are quite happy with you want to for doing this stuff with Docker, Docker Compose and Cubatman already pre-installed. So people can just start this one. And it's quite convenient for just running application. It's not like a very trim operating system, very container focused operating system. And it's not a large operating system with full blown installation of things. It's kind of an immediate convenient for most of the people. So that's there. It's been used and it works. But of course it's maybe not for everyone, especially for people that are not interested in managing VMs. Because that comes with some responsibility. You need to make sure that things are kept secure and you need to be on top. So people sometimes prefer to just, okay, I just have this workload. I have jobs. I don't care about it. Just do the thing. And for that, we have the HTC service. But it's not so easy to run containers there because Docker just won't work. It requires root. So we need a container oriented engine looking into HTC. And it's not meant to run services or it has limited lifetime resources. So normally you have like 20 minutes, like seven days maximum spawn of the job. So not for everything. And here we have two main technologies. The first one is Singularity, which I guess you may have heard of. This is a project coming from the U.S. It started in 2015. And now it has a commercial company behind it. It's basically a Docker container runtime focused on supporting HTC, HPC systems. So it runs with our root. It's intended to make it easy to use the hardware. So the GPUs, Infinimum, whatever. And it's trying to place nice with the infrastructure. So we do have Singularity in EGI. It's available at most of the providers. So you just use the Singularity binary and that's it. And we have a nice thing, which is the CDMFS, which is a distributed file system for having software available at the different providers. And this like a hierarchical tree that is distributed across the whole infrastructure. And basically by storing the container images there, you will have them everywhere. And you can just access them because it's part of your system when you enter the job. And we also are able to store and unpack images there. This is nicer for CDMFS that has quite a nice caching and duplication of files. So if you have very similar container images, they will be stored in a very efficient way across the different providers. And this just works. You just use Singularity pointing to the CDMFS image and it will run. And the other technology is Udocher. This is a more European branded way of running containers. Also starting in 2015 as part of one of the ECU funded projects called Indigo Data Cloud. And again, it's about running Docker or containers in general without being root and it is to be as less... So running with the less privilege as possible. So once without using Docker, without requiring privilege, without installing anything, just you need to then load a very single tar file and make it happen. So just to give you an example, this is how it looks. You basically download the thing, make it executable, run this Udocher install, and then just Udocher run whatever image and it will just happen. And this is just done in a very regular user, no privileges at all. Udocher is kind of an iteration tool. So we are trying to make it easy to run any kind of containers in any kind of system. So it's importing images from Docker Hub or from a file system. It turns those images into layers in a Udocher-Locker repository and from there it can just run them. So it creates the different system trees, the operating system trees with the file system layers. And then it will be able to run using different technologies from the most simple that is just a CH root when there is no other support from the underlying environment. It's just a CH root and we'll run the thing, but it has things like Ptrace or even just an actual existing container runtime like run-series singularities. So it tries to accommodate to the most efficient or most convenient way of running containers for the environment you are in any case. And it just runs and it works quite nicely. This is some benchmark. I know if you can see if it's small running Udocher compared to the physical hosting and with Docker, and sometimes Udocher is even faster than Docker. This is because if you have a simple application that can run with a CH root, then it's very easy to get very nice performance. And sometimes it's even faster than the physical host, mainly because if the physical host is using, let's say older libraries, then the more modern operating system that you have in the container may be more efficient and you can get a nice performance. And overall we can say this is performance-wise is very similar to Docker. And one also nice thing is that we can inject libraries from the host to be able to use OpenMPI, for example, for having nice access to the Infinivan or other loan low latency network that may be in the cluster or accessing the GPUs also with local libraries. So we are sure that we get the best performance possible. Yeah, I need to wrap up. Just moving to the other way of running containers, which is running Kubernetes. So we started trying to support Kubernetes in EGI since long, but it was not simple because of the teraginity of the providers. So as I was saying before, we are now all OpenStack, but before we weren't. So it was not easy to use, for example, Magnum everywhere because it was not available. And we needed to find ways around that. And what we done and what we do is we have this tool called EC3, Elastic Cloud Computing Cluster that is able to automate the deployment of, in principle, several technologies, but we use it principally for deploying Kubernetes on the EGI cloud providers. And this is a nice tool that just have a green and a CLI access that is completely integrated with the rest of the ecosystem. So it's using our AI. And also it's able to discover the features of the cloud providers and just use uncivilized to deploy the Kubernetes. And the VA has a set of components, but the main one is this infrastructure manager that is able to talk to different cloud providers in a, let's say, a more continuous way. So you can have OpenStack, but also OpenNebula or even Amazon. And it will kind of deploy the same kind of infrastructure everywhere using the same description. And we have the other component, which is this clues here in the middle of this cloud that is able to understand how the cluster is performing and do a bit of elasticity. So it can scale out or scale in and create new worker nodes for the cluster. If it's Kubernetes, it's just creating a new node and installing QBAT mean there and add it to the cluster. And so that happens whenever there is a lonely list of bots without running, you can say, okay, if this is happening, you just create a new node until this number of nodes and again, if you have nodes which are idle, they will be killed. So you free some resources. And as I said, this is with a graphical user interface, you just click and select where you want to run, the kind of virtual machine, the size of it, and it will just make it happen. And at the end, you will have like an endpoint with an IP where you can connect and you can also have a graphical dashboard for Kubernetes that will allow you to install things with harm and so on. We have a video there with more details and you can also use it via the CLI. So, I mean, just to tell you that this works. We have a bit of EGI specifics because as I said, this is the Kubernetes infrastructure. We can use all of the features that we have from the cloud providers. Specifically, the load balancers, we don't have that. We use Ingresses, which kind of delivers the same functionality and it works. Volumes will lay in NFS for having this kind of flexible share volumes, which just works. Of course, if you want nicer performance, you also can talk to the sender, the open stack volume to make it integrated with that. But that requires a bit of tweaking of the stack and we can also integrate this with the check-in so you can interact with the cloud and its APIs with the EGI entities. And I will just, two more slides and I am finished. This is Tynes and it works, but some of the users are still not really capable of really using this to the standard. So EC3 makes it happen to have the Kubernetes deployed. But today, two operations of the cluster is not for everyone and you need to be on top, Kubernetes. You need to upgrade it because it has a very frequent update release cycle. You need to make sure that things keep running and sometimes you need to tune the setup for making sure you're using the underlying hosting provider as you should and that requires expertise and not everyone is ready for doing that. So what we are doing now or we're trying to do is relying the providers to provision this Kubernetes knowledge service. So the idea is that the providers have expertise on setting up the Kubernetes and tune it to their specific setup and have the people really on top and making sure that things run as expected. And we are engaging with the different providers to, for some of the users, have this Kubernetes and they just have the endpoints and use it. There are still a bit of open issues trying to understand how to better deal with this. The multi-tenancy is still not very clear so we try to do this for a single community, try not to mix people just to avoid potential issues. And we are also trying to see how to integrate this with the rest of the EIA federations, how to better deal with the authentication, the monitoring and accounting, which is something that we do for the other services and we want to also do it for the Kubernetes. So we expect that in the future we will have more of this and more integrated with the EIA. And we're also looking into having a bit of a container catalog, similar to the virtual machine image catalog, we want to have something similar for containers. We mostly rely on Docker Hub right now, but yeah, Docker Hub is not completely free and some users need something that is, let's say European or EIA based for their support. And we are looking into having something like this in what we call the application database, which is our software catalog. And we are looking into how to integrate also containers there. So I expect something will come here in the future. So wrapping up, yeah, we have EIA infrastructure. We support containers in different ways. And we see containers more and more being used in the infrastructure, particularly from the US use cases. We see that Kubernetes is nice, but it's also complex for users. And we are looking into manage offer, involving providers as much as possible. I think the way to go is having them really being supporting the use cases and delivering features. And there's some reference and pointers to EGI. Thank you.