 Welcome, everyone. This is the Magnum 101 introduction to Magnum. My name is Adrian Otto, and I am the project team lead for the Magnum project. So Magnum is an OpenStack service that allows you to create container clusters. It lets you use the same credentials you would use to interact with your OpenStack cloud in order to create those clusters and to manage them. It gives you a choice of what kind of cluster types to create. It has a full multi-tenancy solution that works all the way from the control plane all the way down into the data plane. And it allows you to create those clusters quickly and easily using advanced features such as multi-master. So if any of you have ever created a container orchestration cluster on your own, maybe you set up Kubernetes, getting all of the security configuration right, getting the multi-master configuration right, can be very difficult. And so using a tool like Magnum to simplify that can make your life a lot easier. Now before I get too far into it, I need to define a couple of terms that I'm going to use during this talk. The first is COE. A COE is a container orchestration engine. Magnum supports a variety of these today, including Docker Swarm, Kubernetes, Apache MISOS, and DCOS. The next thing I'm going to talk about is a Magnum cluster. So a cluster is an API resource represented in Magnum that represents a grouping of NOVA instances and other cloud services that are used in order to deploy the COE. So you can think of this as this is the cloud assembly that runs your COE. So the basis of this is a NOVA instance. There are a lot of other resources that are not pictured here. But the COE would be like your Kubernetes cluster. The Magnum cluster would be all of the resources that are necessary in order to run that. The cluster itself can be scaled. It can be created and destroyed. But container clusters or Magnum clusters don't actually run containers. The thing that runs containers is the COE. You with me so far? All right. Next piece of terminology is cluster template. So within Magnum, there's another cloud resource called a cluster template. And you can think of this like a rubber stamp for creating Magnum clusters. And this has all of the settings in it that you need in order to create that cluster. Like it's DNS settings, what network it's gonna be connected to, what key pairs it should use, everything that you would set up at runtime would be either specified at the time that you create the cluster or built into the cluster template itself. So cluster templates are just a way for operators to make it really easy for end users to make Magnum clusters. And then the last piece of terminology is native client. Now when I say native client, what I mean is the tool that is native to the COE. So when I say native client, I'm not talking about an open stack tool. I'm talking about whatever the upstream open source container management tool is. So if you are creating Magnum clusters that are Kubernetes clusters, then your native client is kubectl or kubectl. If you are deploying Docker swarm clusters, then your native client is Docker. So you get the idea. Magnum is designed so that end users interact with the native client rather than with open stack tools. So you can have open stack users, Magnum consumers that are open stack users, and you can also have another set of users who knew nothing about your open stack cloud at all and just interact directly with the container orchestration environment. Now when I talk about Magnum and I get questions, people ask what is the difference between running open stack with Magnum with Kubernetes on top or open stack with Magnum and swarm on top or any of these other COEs versus me just setting up a bunch of instances and putting the tool on myself. And there are a number of differences. So I'm gonna go into four of them right now. The first is multi-tenant, which is what I mentioned earlier. Multi-tenancy means you run workloads that belong to potentially hostile neighbors. So customer one, customer two are not related in any way. They're sharing some resource. You wanna be sure that there's a security isolation barrier between these things, okay? With a properly designed multi-tenant system, there are high degrees of isolation between them. If you just took a bunch of cloud resources and put a container orchestration system on top and started running containers in it, you would end up with hostile workloads neighboring with nothing between them besides the definition of the container namespaces. Unless you are using a lot of additional security features, that can be risky. So what Magnum does is it groups these clusters using NOVA resources such that each cluster is only for one tenant at a time. So it's a way to achieve multi-tenancy with clusters that are really fast and easy to create in a way that does not share the same host kernel between neighboring tenants, which makes it fundamentally more secure than trying to do a massively multi-tenant single installation of a COE. The next is Magnum is giving you the choice of what COE to run. So when we conceived of running Magnum, the first driver that we built, the first implementation was Docker. And at the time it seemed that Docker was ruling the world and that there would never be any other choice, but times changed. And now Kubernetes is the new hotness. Now, wouldn't it be nice if you didn't have to retool your entire cloud environment every single time you made a change in terms of what was your favorite in-style COE? So if Kubernetes is the winner from now on, great, nothing lost. But if it changes, and down the road there's another one, and you'd like to have a driver for that, this system gives you a place to plug that in. You might also choose a different COE depending on what kind of workload you're running. So if you're running a cloud native workload, it would make sense to run that in Kubernetes. If you're running maybe a workload that's just forklifting a legacy application, it might make sense to run it in Kubernetes, but you might not be getting a lot of additional value. And maybe you just want a simpler system, right? So maybe it makes more sense to run that in a Docker environment than it does to run it in a Kubernetes environment. And if that's what you believe, then great. You have the choice. You can run Docker clusters and Kubernetes clusters side by side on the same infrastructure, all managed with the same tools. The third differentiator is you can choose what kind of servers Nova gives you by changing your vert driver. And Magnum doesn't care. It will let you deploy clusters that are composed of bare metal servers or clusters that are composed of virtual machines or if your cloud is configured for this, clusters made of containers. So containers within containers. Magnum is fundamentally designed to support this. Now I will say that it supports the VMs first because that's the default that most people are running a KVM vert driver in their open stack clouds and it works well with that. It may not work as well with the other server types but it's designed to accommodate it. And then the fourth differentiator is that it's integrated with open stack. So if you've already got an open stack cloud and you've got users that have keystone credentials that they're using to interact with that cloud, they use those same exact credentials in order to create Magnum clusters. They don't need something new. So why Magnum at all? So the first is it gives you the choice. You can decide what container orchestration tool works best for you. Second, it allows you to create those clusters with a degree of speed and simplicity that is unmatched. And third, it will allow your developers to iterate on your software, the things that add value to your business more quickly and more easily than trying to do this by hand. When learning about Magnum for the first time, a lot of people think, what's really the difference between just running Kubernetes on top of the cloud and running Magnum? And I want to make the point that your container orchestration environment is about managing your application cluster and Magnum is about managing your infrastructure cluster which are two distinctly different things. You need an infrastructure in order to run your application cluster. You want to be able to manage it. It's lifecycle, it's scale, right? You want to be able to create new ones that are of newer versions of it. You want to be able to do that easily. There is a small overlap if you saw the previous session or two sessions describing the interaction between, for example, Kubernetes through its cloud provider interface to OpenStack. Okay, so there is some interaction that occurs between those systems. But that overlap is relatively narrow. Kubernetes is focusing mainly on the application, deploying it and managing it, and Magnum is focusing entirely on the infrastructure and managing that. So it's an enabler. So next I'm going to give you an idea of what the different kinds of consumers experience when they use Magnum. So the first is for a cloud operator, for those of you that are owners of clouds, you're going to be able to create something called a cluster template which I mentioned before. And this is what a create command would look like for a cluster template. This one says it's based on the Fedora Atomic image. It specifies a key pair, what network to use, what the DNS settings are, how big the servers should be based on their flavor, how much storage should be attached to them, what networking driver they should use, which container orchestration engine is running inside of it, and what volume driver to use. And this one also has a public flag which means after I create this template, it won't only be visible to me, it will be available to everyone. So my users will all see this when they list templates. So if I switch over to using Magnum from the users perspective, the cloud end users perspective, they use this command called cluster create. So cluster create takes an argument of a name, this one's named K8S. It uses the template called Kubernetes. It's gonna make an eight node cluster with three masters. So a total of 11 nodes. Once I create that cluster, I can run a command to automatically take the TLS configuration that was created at the time the Magnum cluster was created and copy that into the local environment so that I can use the native client without fooling around. So I don't do any security configuration. I don't share any security credentials from one cluster to the next, right? Every single one is unique. Everyone's got its own CA and certificates are signed against that CA. So I don't need to worry about a user of one cluster having access to another. And then once I have that environment set up, I can use the native tool directly. So in the case of Kubernetes, I would use kubectl and begin interacting with it. This is gonna create a pod. And alternatively, I'll give you the same experience, but if you were creating a swarm cluster, for example, again, you provide a name, you indicate what template to use, and the size of how many nodes and how many masters. The same thing again with using cluster config to pull in the TLS certificates and necessary to interact with the cluster, and then you can use the native client directly against it. So this is gonna run a Docker container within the swarm. New in the last release. So in the last release, we added encryption to the XCD cluster. So now by default, all interaction between the XCD clusters and the COE are encrypted using these credentials that I'm talking about. There's also a new parameter in the cluster create that lets you specify what key pair to use. We also built in OS profile or support so you can do request tracing. There's a new endpoint for quotas. Before, so when you create, when you use Magnum to interact with your cloud, right? It's going to respect all of the existing quotas for things like neutron networks and volumes and Nova instances. Go down the list. All of those quotas still apply. The ones that are in the context of your current operating tenant. But there wasn't an instrument to say, look, I wanna limit the number of Magnum clusters that you can create or how big they can be or these sort of things, okay? So now there's an API endpoint for defining quotas that are unique to Magnum. So above and beyond all of the quotas that apply to all of your constituent cloud resources, we now have the ability to do quotas based on the Magnum resources as well. There's also a new stats endpoint that gives you statistics about the usage of your Magnum service. We now support rotation of the certificate authority. And this is important because if you have a cluster that's in production and you've shared these TLS credentials, right? With an actor and that actor for whatever reason is no longer employed with you. You wanna have the ability to make sure that those credentials that may still be in his or her possession are no longer valid to interact with the cluster, okay? So if we rotate the CA, it invalidates any existing certificates and then they just run cluster config. Any surviving users would do cluster config again to refresh their environment and continue accessing the system. And then we also updated the version of Swarm and Swarm Driver. In addition, in the last release, we also added, or the community I should say, added two new cluster drivers. One is a Kubernetes driver that runs on Susie Linux and the other is a DCOS driver. And both of these are newly contributed so they'll exist in our contrib directory. And if we see a lot of adoption of these, drivers will pull them into the main tree as well. So if you care about these, we wanna hear about it. Next, we're gonna be focusing on extensions to the Magnum API that allow it to do more complicated clusters. So we have this concept of a node group. Today, when you create a Magnum cluster, it's all just one, it's actually two groups. It's a group of masters and a group of slaves or nodes. With node groups, you can create an arbitrary number of these. So you can do things like have a group that's in one region and a group that's in another. Or a group that's in one availability zone and a group that's in another availability zone. So as you create clusters, they can be more diverse geographically and more highly available. It also allows you to do things like defining different groups for different types of hardware. So say you've got an application that requires a GPU resource. You might wanna have that defined as a separate node group. So you can treat it differently in the way that you tag it in your COE. We're also working on additional security features that make it safer to do things like having your COE interact directly with your infrastructure. I'll give you an example of this. So today, there's a Kubernetes extension, or what do we call these, Tom? Module, plugin. Okay, Kubernetes plugin that allows you to create volumes in Cinder. Which requires that there's a credential, an open stack trust, a Keystone trust that exists on the cluster node in order to be able to create those volumes. Now that credential might be abused and used for other things besides creating and destroying clusters through Kubernetes. Maybe it's used to destroy volumes that had nothing to do with Kubernetes. That would be an escalation of privileges that would be undesirable. But it is possible to configure an arrangement of services where this is controlled through a policy where this would not be allowed. So this is an area that we're working on today to try to make that even more secure. And if you'd like to get involved with the development of the project, we are in the open stack containers channel in FreeNode and we meet on Tuesdays, I think alternating Tuesdays at 1600 UTC in the open stack meeting channel. So if you have questions, the microphones are here in the aisles. I'll take them now. You mentioned security. And I was wondering since security is involved in pretty much defining what you want the system to do, who you want to let in and what you want it to never do. How do you validate that you've properly configured your security with your frameworks here? I don't think we have features that are designed to do that yet. So we would be open to hearing your ideas on how best to do it. Oh, thank you. A question on how Magnum keeps up with underlying changes to the COEs. So when, you know, new versions of Kubernetes and Swarm and things like that, they change something. Do you guys have to constantly keep up with those changes? If it's something that changes the driver, the way that the driver interacts with the COE, then yes, we would need to make a change in order to support that. If it's something that does not change the interaction between the driver and the COE, then all you need to do is build a new image. So I mentioned the concept of cluster templates. One of the things that is in the cluster template is an indication of what glance ID to use to build the cluster nodes. So you can update that glance image with a new version of the COE without changing Magnum at all. So most changes wouldn't require changing Magnum. The ones that do would require a bump of the driver. And like I said before, the driver is not only is it versioned, but it's pluggable and it's Python code. So it's relatively easy to change. About the network connectivity issue, when we provide the virtual machine and the container that's just like K-Bytes to Magnum, so how could we make the network connectivity between virtual machine and the container for maintenance? So let me see if I understand the question properly. You're asking about how do we support having your containers interact with existing machines that are VMs that are on the same cloud? Okay, so the idea for how this should be supported, and I don't think we actually allow this today except going through the public interface, but the way this is supposed to work by design is that you specify the ID of the neutron network at the time of cluster creation. So if you have cloud resources that are already on a neutron network and you create a Magnum cluster, you can specify that ID and it will then create all of the Magnum resources on that same network, and that would allow for the communication that you're talking about. If we do on K-Bytes on top of Open State without Magnum, then we could not make the virtual machine and the container for which we are, right? It's hard to do that securely, I'll say that. Yeah. Does Magnum do life cycle management of the cluster that it creates? So suppose a node fails in that cluster that I created. What does Magnum do? That depends. What we would like to do is to have the monitoring solution automatically detect that it's a failed node and replace it. Today what it requires is that the operator can do a delete of that one node and then grow the cluster by one. So you can do that. In terms of life cycle management, though, there's a feature that's in development right now for doing an in-place upgrade of the COE. So let's say you're running, say Kubernetes 1.4, you wanna go to Kubernetes 1.5, you don't wanna deploy a new cluster and redeploy your workload, you want the workload in place to be upgraded. We're working on that right now, so that would do a rolling up grade of the COE in place. So in terms of handling node failures, your COE has some capability already to, like in your, for example, Kubernetes has this cluster rebalancing capability that it can already do. Magnum doesn't need to be involved in that. It's only if you wanted to take the failed node out of the Magnum cluster and rebuild it. There's a command to do that. Magnum will add the new node back to the, I mean it will also configure the Kubernetes to add that node to the cluster. Yeah, I didn't show an example of scaling, but for example, that would be the same thing as scaling a cluster. So you would say, okay, I'm gonna take this eight node and I'm gonna make it a 10 node. Magnum would automatically grow that heat stack by two additional nodes and it would configure them in the same way that it did the original set. So yes, you can adjust the size of the cluster up or down for both masters and slaves. Is there any additional features to do multi-tenancy other than your spawning your COE in your own open stack tenant? Do you guys do anything in Magnum to give extra kind of isolation? Great question. No, we don't, that's out of scope. But when we talk about isolation and multi-tenancy, that's how we're doing it because of the open stack kind of project or tenant architecture. Yeah, when you create a Magnum cluster, in turn it creates a heat stack. And that heat stack is a grouping of cloud resources that are owned by your same tenant. So for an individual tenant, although you can put a lot of applications into the same cluster, when another actor creates a cluster of his own, it's not gonna share any hosts with yours. That's the guarantee you're getting. All right, looks like no more questions. Thank you everyone for attending.