 So, I'd like to introduce Jake Yip, who's from the Nectar team, who's going to give his presentation now. Thank you, Jake. Hello, can anyone hear me? Yep, cool. All right, so thanks everyone for coming. Thanks for sticking around. My name is Jake. I work at ARDC as a DevOps engineer, together with Kieran, who is also going to be talking a bit later. Today, we're going to have a very brief talk and a bit of a demo on Kubernetes. That's provided in the Nectar cloud by Magnum. So yeah, what's Kubernetes? I guess a lot of us have heard of Kubernetes. It's something new and shiny, and everyone loves it and wants to get into it. All right, but unfortunately, using it is fun, but setting up is not really that fun. So, there are many, many different ways of setting up Kubernetes. Some of the ways are like Rancher and Coopspray and COPS. And in the technical field, when there is N solutions, that does not really work well. We come up with N plus one solution. So, the N plus one solution is Magnum. Not really, but yeah, later, further on we'll see why Magnum is, why we adopted Magnum to provide for Kubernetes in the Nectar cloud. So, Magnum. Magnum is a container orchestration engine service. It allows us to, or allows a user to create a Kubernetes service easily from a dashboard without really needing to learn about Kubernetes. It builds on the OpenStack resources. It's a project started in OpenStack LAN, and over the years, contributors have come and gone. And currently, at this point in time, it's permanently worked on by a few research institutions. So, CERN, Catalyst in New Zealand, and Stack HBC in UK, the top three contributors. There are a few other contributors like us who use it and find bugs and fix it. So, we do help out upstream. We introduced this in Nectar in 2018. Um, but as you might have heard from Luca previously, it wasn't, it was quite unpolished then. But since then, there are a lot of improvements. Primarily with the latest released, we've gone. It has a new operating system and a new way of handling upgrades and things like that. So, how it works, it uses OpenStack native resources that we are all familiar, we might be familiar with, like NOVA instances for compute, Octavia load balancer for the ingress. There is advanced networking to tie all together. This is something new-ish, has been around for about two years now. Then volume for storage using backed by sender. So, it uses the same storage pool as your normal volume that you use on the Nectar Research Cloud. This is a brief diagram on how it all looks and work together in the Nectar Cloud. So, at the top of it all, our user will interact with load balancer. Magnum spins up a bunch of instances that can act as a master and workers, they such as NOVA instances. They are all connected using the advanced networking tunnel network and they talk to the volume storage provided by sender. So, just a brief recap again on how it all looks in the Kubernetes LAN and the OpenStack LAN. Kubernetes node is a NOVA instance. Kubernetes persistent volume is a sender volume. A Kubernetes service type of load balancer is an Octavia load balancer. The whole setup configuration provisioning of nodes of a whole Kubernetes cluster is all done using heat. So, now we go to some of the features of Magnum. One of the things that now can do is that you can scale both up and down. So, you start off with a small cluster, maybe one master and one worker. And then when you get, like, you need more resources, you can just say, hey, node count equals to three. And Magnum will go and provision another two more instances for you, set them up, set up the networking, and you will see it all appear in Kubernetes LAN as when you do a kubectl get nodes, you see, oh, now I have three nodes. It can scale down or so. Scaling down simply is an instruction to NOVA to delete a node. So, one of the things that you have to remember is that it's better for you to do a kubectl drain before you scale down. This will allow Kubernetes to handle the ports properly, like move them away and things like that and not schedule any more new jobs to the node. Then, when you destroy the node, it will have less of an impact. There is this newish thing in Magnum called node groups. So, previously, your whole cluster can only have one flavor for a worker. Now, you can have node groups which handles different flavors. So, for example, you can have four small instances doing some type of work, and two large instances doing other type of work. You can label them using Kubernetes and launch your port according to the labels. So, yeah, maybe intensive jobs, compute intensive, you want to launch them on the large instances, for example. That's easily done. Magnum now also supports scaling storage. So, it can scale up, but as you might notice, there is no scale down. Scale down of storage is a hard problem, I think. So, scaling up is a two-step process. You can say, hi, I have a two-gig volume now. I want a four-gig volume. So, it's a two-step process. First of all, Magnum was Signal OpenStack. I want this signal volume to be expanded from two-gig to four-gig, and the raw device would expand. When that finishes, you will need to expand your file system. So, the file system will be expanded. The file system at this point in time is still being used by the port. So, it doesn't expand online, but when you restart the port, as the port is coming up, it will expand the file system. So, very nice. Now, you might be interested in wanting a play. So, just before you jump into it, you would need a quota for a few resources that Magnum would use. So, some of the resources that we are familiar with are like the compute quota and the volume quota, this we all know. But for Magnum, it uses other native resources like advanced networking routers, flowing IP, network load balancers. Typically, you might not have requested for this. So, you will need this before you can even spin up one cluster. So, we have done some work on the allocation system. This is a great work by Stephen Crawley. So, now we have a place where you can say, I want container orchestration service. And I want two numbers of container clusters, and it will check and hint. So, if you want one cluster, you check whether you have one router to floating IPs, one network load balancers, and things like that. And hint to you if you did not specify enough resources for your cluster. So, of course, you can always have more, specify for more. All right, time for demo, the exciting part, exciting for me. Okay, let me stop share of this. So, I'm going to share terminal first. All right, can everybody see this? Is it big enough? You can shout out if it's not big enough. That's fine. Cool, thank you. All right, so, I'm already logged in as a normal user. So, the Kubernetes, sorry, the Magnum service is under the namespace COE. So, opens that COE cluster list, will show you the clusters that you have. So, now I have one cluster here. All right, this is, if you're familiar with command line, you can use opens that COE to do everything. If you're not, I'll jump back into the web now to show you how it looks from the web dashboard. I'm sorry, this one, so, did I lose everyone? Oh, sure, sorry. Okay, sorry. So, this is the dashboard. Under container infrastructure clusters, this is what you see. You can create a cluster here easily. Name of a cluster, let's call it test. And cluster template, I'm just going to make this bigger for everyone. We have come up with some default cluster templates. They generally correspond to availability zones. So, if you have Quota in Melbourne, just speed up in Melbourne. If you have Quota in Tasmania, speed up in Tasmania. So, I'm just going to select Melbourne for now. Size, you can choose how many masters you want and how many workers you want. And you don't have to do that. What you have to do is select keypad because this allows you to access the instances in case anything breaks. And just sum it, and you can see that Magnum has gone and tried to create the cluster called test. So, the dashboard is kind of, I would say, lacking at the moment to do anything else from here. To really do anything, you have to drop to the common line. Sorry, too many windows. All right, so this is back to where we are at the common line. We can see that one is creating in progress. So, what now? So, from here, you will want to be able to control your Kubernetes cluster. The command is cluster config with your cluster name. This will create a file here called config, which is basically defines how to connect to your cluster. Like this is the server and the URL of the API server, your Kubernetes API server. So, you just have to export kube config as to point it to the config file. And you can use kube CTL from now on to do everything. All right, so from now on, these instructions are all in Kubernetes land. We are done with OpenStack Magnum. You can see that there are lots of internal services that Magnum has spun up for Kubernetes. And then we, you can control it from here. So, for example, if I want to run an Nginx server, I can do this, I have cheat code. And this would just run an Nginx container. You can run a load balancer. I'll just apply this first, and then I'll show you how this looks like. So, this is the manifest for the load balancer where you can say, I want a load balancer. And I want it to target the web server that I just spun up on port 80. So, I say, as I talked previously, like all the Kubernetes resources are actually OpenStack resources. So, if you do a kube CTL get all now, you can see that the load balancer is being created in Kubernetes land. Again, if you look at OpenStack, you can see that the OpenStack Octavia load balancer is being created in OpenStack land. All right, so this is underpinning create. It generally takes a while before it is ready because it needs to spin up the M for us. So, when it is ready, the external IP will change and it will show you the IP of the external IP. Ah, there we go. Of the load balancer. So, what it does is it spins up the M for us at the shows of floating IP to it. So, you can get to it from anywhere in the world. So, if you just visit this, you will probably see a default NGINX web page if it all works correctly. All right, this is almost everything. I would like to finish up by showing a dashboard because some people might be more comfortable with getting a dashboard. So, one of the better dashboards that I've seen so far that Kirin recommended me is this dashboard called Octane OC TNT. If you just launch it, it takes in the... So, this is the Octane dashboard. So, from here, you can see your applications. That's the web server I just launched. And many, many other stuff. Like, if you have storage and it will just appear here, your number of nodes, things like that. So, if you are more comfortable with getting a dashboard, this is definitely something you should try out. It's really nice. Okay, that's me. Um, let's go back to the slides. I'm sorry for the number of changes. Thanks, Chey. It's a bit tricky changing screens. Yeah. Sorry. Okay, demo done. All right, so, from now, work in progress. We are at Nectar. We are coming up with Nectar Container Registry. This is primarily to support spinning off the Magnum cluster. As we know, the Docker Hub has now a rate-limited number of pools. So, when we spin our Magnum cluster, the Magnum cluster pulls in a lot of containers from... It needs a lot of containers for all the services. So, Docker Hub rate limits actually might cause an issue. So, we have come up with our container registry to counter this problem. So, we have it working right now to support our Magnum cluster. Things we want to go further and do with it is, we are thinking about is to allow users to share their research containers on this container registry or so. I use it as a way to promote the fair containers. We're also thinking that it could help us in reach-producible research where we can have containers that, once you put it in, we have a CI CD workflow that says, oh, okay, here's a new container. Launch it into Nectar Cloud and make sure it runs properly and has all these results. Then we can be sure that this container is reproducible over time. These are the resources that we have talked about. If you are brand new to Kubernetes, the first resource is really helpful when I was starting out. Nectar, ourselves, has come up with a tutorial. This is mainly to complement the first one where we talked about how Magnum interacts with Nectar and Kubernetes resources. The Octane dashboard is also here. All right, next. Kiran, I'd like to talk a bit about Arcos. Yeah, thanks, Jake. So, I just wanted to give a quick shout-out. So, Arcos is the name of our working group. So, basically, we're building a Kubernetes community of practice. And so far, with input from the community, we've produced a paper just detailing shared challenges and opportunities in the research space. So, if you go to that URL, you can find that paper. We're also looking at implementing some of the recommendations from that paper as well, which are things to do with creating a reference architecture and guides and what things work with building a Kubernetes cluster on Nectar and elsewhere and what things don't, and centralizing and sharing this information rather than groups discovering it individually and running into problems and fixing them. Our next working group meeting is on Friday, so you can, if you look at the arcos.ardc.edu.au site, you'll see some links to join the working group. That'd be great to have your participation and your input as we kind of continue to drive sort of Kubernetes usage and best practice with the community to help. So, yeah, thanks. Okay. Thanks, Kiran. Yeah, I'll put four questions. Any questions for Kiran or Jake? I think there was one in the chat that was... Yep, we... From Dmitri about adding nodes of a particular size or flavor, but you talked about that, I think. Yeah, we've touched a bit about that. You can add in a node group of size one with a new flavor and there will be a new node of a flavor. There's a question about multiple AZs. We haven't tried that yet. I'm very interested in trying it out and do something on the radar. Okay. I'm just putting the... That the paper that Kiran just mentioned is on Zenodo, that address I've just dropped in the chat there for people who want to go straight to it. That's the one, I think, isn't it? Yeah. Yeah, thanks, Rhys. Yeah, I forgot that we'd have a chat here, so we need to really talk about these URLs. No, that's right. And it's on Zenodo. We have recorded today's session, this one, that Jake's been recording this, so I'll need to get that off you, Jake. And we've recorded the first part, but not obviously the breakouts, and so that'll be available to people. Has anyone else got a last, a final question or anything that they'd like to raise for the team can go away and get back to you on? Obviously, we're going to run out of time in a minute, but in that case, I just want to thank Paul, Arvay, James, Luca, and Jake for their presentations and thank Andy, Sam, Kiran, Steve, and Jo in the background, even though she wasn't on the spot, she was doing a lot of work in the background to sort of organize all this, and especially to all of you guys for your comments and your feedback today and your participation, we are expecting that this would be a regular event, how often we're not sure, but we will do more of these. We'll also do more tech talks and things, but we will have a user forum in the future, and you'll hear about it as time goes on. The other thing just to say is we'll send you out in the next couple of days. It'll probably come from Jo, a little feedback form about this forum, just to collect some of your views about what worked and what didn't from the event perspective, because as I said, we're a little shape partly what we do. And while the one final thing we didn't get to, were there were a couple of comments that people made about what they wanted in future sessions, but if you have any other thoughts about that, it'd still be really useful to drop those to Jo, probably just to let her know. We didn't have enough time to talk in detail about what would be useful from you guys. We've got a bit of sense of it, but if there's any particular topic or a particular person or a particular project you'd like to hear from, then we'd be really interested to get that feedback as well. I'll put a question in the feedback form. That's great. For that one. Yeah, thanks, Jo. And Paul, is there any other final things you'd like to say or comments you'd like to make? Or just reiterate, yeah, we are looking to do this in future. So having some more of these maybe every few months. The other thing is we're looking to have some more just very brief sort of technical catch-up sort of regularly scheduled for people to just have sort of a zoom room to drop into maybe once a month or something where you can directly talk to the technical guys and the core services team and ask questions and things like that. So we'll be scheduling those fairly soon and letting people know about those. Yeah, I mean, really, we just want to have more sort of direct engagement with the users and try and help improve the service as much as we can to meet your needs. All right, thanks, Paul. And just as a last thing, I've just put into the chat two links for those who are interested today. We announced the AODC rounds of platforms and data partnerships projects. If anyone wanted to look at those, perhaps the platforms projects will be in just to people to look at what we've actually just funded in the current round, which is sort of, I think, all up around $7 million, $8 million worth of funding. Just if you wanted, I was mentioned at the beginning with Karma, I think mentioned it. Thanks again, guys. We'll close off now and we'll see you again. Thank you. Thanks, Rhys. No worries, bye, guys. Thank you.