Recently, Systems Engineer Stephane Montri and Edward Ionel from our open source growth team walked webinar viewers through the process of creating a production-grade Kubernetes cluster — and sharing access to the cluster within a team. Today, we’re presenting an excerpt to help you get started doing the same.
If you’d like to watch the full webinar, you can check it out here.
Creating a Production-Grade Cluster
Stephane Montri: Mirantis Container Cloud is our solution at Mirantis in order to create and manage the lifecycle of clusters we created with our Kubernetes distribution. The idea with Container Cloud is to provide a cloud-like experience for our customers. So what you see on the screen is a list of clusters already deployed into my project.
And then I will go through the creation of a cluster. So basically, Container Cloud will be able to work with any type of infrastructure whether it is bare metal, on-prem, VMware, OpenStack, or any cloud providers like AWS or Azure or Google Cloud. What you can see in this environment…I have some credentials that have been configured in that environment which enables me to create clusters on AWS, on Mirantis OpenStack or on Equinix as we have started a partnership with Equinix Metal and they are able to deploy our distribution. And, with Container Cloud, I will also be able to define or configure the releases we want to use, which means the Kubernetes release we want to deploy, which is basically linked to a community distribution. For example, the 7.0 version will deploy 3.4 MKE cluster, which is a Kubernetes 1.20 API. And you see that all the providers that are available, OpenStack, AWS, Equinix, Azure, VMware, where we can specifically deploy data down-the-line.
So going back to clusters, you see that I have created a cluster, and I could also attach an already existing MKE cluster — that’s MKE for Mirantis Kubernetes Engine. So basically, starting from creating or adjusting some existing cluster in order to put that one in the management. And I click “create a new cluster” and first, we’ll give it a name, and then select the provider I want to use. For this one, I will work with AWS, I already have an Equinix cluster deployed which I’ll share with Edward afterwards. So basically, it will use the credentials that have been defined, the newest versions. So if you see the information on the release, you’ll see that it’s a 3.4 MKE cluster, which is a Kubernetes 1.20 version…
So basically what I just created is an envelope where I defined the way the cluster will be configured. And after that, I have to create the machine. So exactly what you would do on a cloud provider interface. So should we take AWS, and when you want to create an EKS cluster, you create the cluster and then you define the worker core and the machine you want to use inside the cluster. So I create my machine for the master—the control plane—I will have a minimum of three nodes to define. I will be able to select, also, the instance type, which means what flavor of machine I want to use for the control plane, and the AMA ID that is configured with the AWS credential I’m using to deploy the environment. Then, the same for the worker nodes, I’ll just take two. Same for the instance type, the AMA ID, I can also put some levels for StackLight, as I’m deploying StackLight on them. And then create.
Once I do this, it will automatically provision the infrastructure on AWS, and deploy all the MKE components in order to install the cluster that will be then ready to use and ready to send to Lens, and then share to your teams. What we’ll see is, of course, the status we go through all the stages. It’s pending and provisioning and preparing and then ready. And you’ll see also on the queues, so, for example, I’m going back to that one, you’ll see that the release and the status ready for all the components that have deployed through Container Cloud. So you have the Kubelet, the Kubernetes, the components, the provider instance, also because we will rely on the cloud provider to deploy load balance or create storage, et cetera.
And as it is fully automated, we, at the end, create OIDC, the security groups, all the configuration we need for the Kubernetes cluster, the Bastion post, in order to correct into the OIDC. So all this is automatically curated, so we just want to select how many machines, the flavor of the machine, and then you have a cluster which is ready that you can use and share with your team.
Edward Ionel: That’s quite excellent, Stephane, and I just want to reiterate what you mentioned. Mirantis Container Cloud works with all cloud providers, correct? Whether it’s VMware, Google Cloud, AWS, as you mentioned, and so forth.
Stephane Montri: Yeah. For example, if I want to create a cluster on OpenStack, because it’s an additional OpenStack from Mirantis, but let’s call it “os-demo”, we have the same option and when I go to provider, then you have specific options regarding the provider. But the idea is really to bring a consistent experience, whatever provider is behind it. And it is ready for customers that are running some work on-prem or in the cloud to also bring a hybrid experience to Container Cloud.
Edward Ionel: Understood, thank you for that.
Sephane Montri: Okay so now, we created a cluster and the cluster is being created. We’ll see it at the end because it will take approximately 20-25 minutes to be created. So, of course, we won’t wait in front of the screen for it to be created. You can also see from the cluster events that things are being created. So for now, the PPC has been created, the subnet has been created, the gateway has been created, et cetera. So all the things will come and also if you would collect into the AWS account we would see all the machines creating the security rules, being configured, et cetera, by this deployment.
Importing a Cluster to Lens
So what we want to do now, as my cluster has been created, is show you how to easily move that cluster into Lens and also, possibly, share that cluster with people on my team.
Edward Ionel: Excellent.
Stephane Montri: I will take this cluster, which is called Lens Webinar, you see that this one, sorry, has been deployed on Equinix. So this is bare metal on the cloud, and in the option for my cluster, I also have an option to add the cluster to Lens. So basically what this does, is that in Lens, when you work with a cluster you basically configure the kubeconfig file in Lens to add it automatically. With Container Cloud, we also create an extension for Lens that will automatically bring that cluster into the Lens configuration. So I’m just ticking that option, and basically what’s happening is that we’ll open it in Lens, and you see that my cluster has simply been added in Lens. And it’s just up.
Stephane Montri: And as for that cluster I also deployed all the StackLight components – which are monitoring, logging, et cetera – and you see, by default, all the metrics for this cluster. So I see the uses of memory for the worker node, for the master nodes. So the whole thing is gathered automatically by Lens. And, of course, I can see all the workers that are running in my cluster so here I’m just selecting all the Lens Spaces so that I see all the workloads that have been deployed. So we have StackLight, we have all the basic deployments that we’re running in a Kubernetes cluster. As this cluster is quite new, I don’t have any specific application on it. So you just basically see what is deployed by default in this cluster.
Edward Ionel: That’s excellent, and just so everybody understands, Lens is a free, open source desktop application that anybody can leverage. It’s 100 percent free and open source, and it works with any certified Kubernetes cluster that’s certified by CNCF. And really the value that Lens provides is giving full situational awareness of everything that’s happening within your cluster from your resources to your objects, your deployments, and so on. And as Stephane mentioned, you have the pre-built in Prometheus here that Lens has leveraging. And you can easily view your CPU to your memory to get a very good understanding of, again, how your cluster is performing in the last hour. So, awesome.
Stephane Montri: Yeah, and just to complement what you are saying here, in terms of a different Kubernetes, we see that now I’m looking at a Kubernetes cluster which I’ve just added to Lens. So if I go to the catalog view, I see that this “lens webinar” is right here. That’s the one that I opened, and also, of course, bring that to the Hotbar on the left of the screen in order to quickly access that one. But I also have another one which is another MKE cluster deployed on AWS, so another provider.
Edward Ionel: Yes.
Stephane Montri: So when opening a k0s cluster which is waiting on a single VM loading on my laptop in case you are using another distribution from Mirantis. Also, open source, free to use that you can set up really easily. I can also connect to another one, which is OpenStack as well. So basically, with Lens, you get access to any Kubernetes distribution and which is really enticing is that you are directly in the context of the cluster.
Edward Ionel: Yes.
Stehpane Montri: So I am opening my terminal and just connected it with my “lens webinar” cluster with my credentials because that is the way it is configured to send the API to the extension.
Edward Ionel: Excellent, yes, and as Stephan just demoed, he is jumping from cluster to cluster. And he mentioned this, it’s always matching to the correct cluster context and the end-point there. So when you switch from a k0s cluster to an MKE cluster, you always know that you will be automatically synced and connected to that correct cluster API, which is so important. So we’re switching from cluster to cluster, while always maintaining the correct context of the cluster itself. So again, working with many different clusters at once, Lens works with any CNCF certified Kubernetes cluster. So this is very awesome to see if you’re working with multiple Kubernetes clusters, whether it’s a production-grade cluster, a development cluster, proof of concept cluster, and so forth. You can work with all of these clusters directly in Lens.
Stephane Montri: And also, a small detail about this, is that you can also set up Lens in order to get the complete upstream binary of kubectl, the version of your cluster. Which is also quite important because when you need to access an API you also need to have the same version of a CLI versus the API which is running in the cluster. So now, what did we do? I created the cluster through Container Cloud. I added a cluster already existing in my Container Cloud environment to Lens, which you just saw with my “lens webinar” cluster, which is here. The good thing is that I see all the metrics. I also have an event management in Lens, this is just showing me that there’s no issue on my cluster which is also –
Edward Ionel: This is good.
Sharing Access with Your Team
Stephane Montri: Yeah, this is good. And now, probably Edward, you want to also have access to the cluster?
Edward Ionel: Absolutely, that would be fantastic. So here, Stephan is going to be demoing how he shared access to this cluster with myself. So this is quite, quite interesting whenever you want to get a team member access to your particular cluster. You can do so through Lens and Lens spaces. So, yes, take it away, let’s take a look.
Stephane Montri: Yeah, so this is done through Lens Spaces. So with Spaces, basically, you get a SaaS component, to which you will have a login and, of course, can define some “spaces” and some “teams” to work together. So I’ve created a “demo Space” where we have some people in there. You can also see the building and the plans so, for example, I can add up to three connected clusters with the free version of Lens Spaces, and up to three teams as well. I can see the members, and then can invite some new members into my Space. And I think, Edward, I already invited you.
Edward Ionel: Yes.
Stephane Montri: So maybe you have to accept that invitation in order to see those clusters.
Edward Ionel: Absolutely, so what I’ll do from here is – if you’re okay with that, Stephan – I can take the ball real quick and showcase me accepting the invitation to your space. How does that sound?
Stephane Montri: Yeah, the first thing I need to do is to share my cluster.
Edward Ionel: Perfect, let’s start with that.
Stephane Montri: If I look at my cluster – you can see it on the top right of my screen – I have a small button called “share cluster”. And basically what will happen, is that it will deploy some components in the cluster in order to make the connectivity to Lens Spaces. It’s basically a BoarC component that will hop on the channel in order to have the connectivity. So I just click on “install cluster connect and share”, so basically it will create a Lens Space with all the components. So you see now in green that my cluster has been shared with my space “demo”. And so, Edward, you should be able to see that cluster.
Edward Ionel: Perfect, let me take the ball from you here. I will share my screen of myself accepting the invitation to your space and then taking a look at the cluster. Can you see my screen, Stephan?
Stephane Montri: Yeah.
Edward Ionel: Excellent, so here you guys can see I have Lens open. I’m currently looking at a minikube cluster, so once again, any CNCF certified Kubernetes distro works here. And from here, what I’ll do is I’ll navigate to my profile, and within my profile itself, I’ll actually be able to take a look at any invitations that I have received from a team member to join a Space. Joining that Space will give me – will share access to that Kubernetes cluster. So everybody understands, Lens Spaces is a centralized, cloud-based offering on top of Lens the desktop application which allows you to create these spaces where you can add different cloud-native resources. For right now, it’s for Kubernetes clusters, so you can add your Kubernetes cluster to that space, as Stephan mentioned. And here, I’ll actually accept the invitation as you guys can see on the bottom of the screen. I’ll click accept.
And I’ve now accepted the invitation. And within the Spaces, I can actually see the demo space here. From here, if I close this out and actually go back to my catalog, I can see all of the different cloud-native resources that I have access to. So this is the unified catalog, within the catalog you can have several different things. For example, you can have Kubernetes clusters, you can have Spaces, you can have documentation, which would be like web links, so being able to access the internet or different documentations, maybe you have a cheat sheet for kubectl commands that you wanted to utilize here. You can take a look at all of these different things within your catalog. I will say the catalog is very similar to a directory where you have various different resources in one place.
So from here, I’ll navigate to Spaces, and again, I can see that demo space that was shared with me, but to actually access the cluster, I’ll go to clusters here and here I can see the cluster itself. So there’s several different clusters here, we have the demo cluster, and then the MKE-AWS cluster. I’ll open this cluster, click it here, and immediately this cluster has been added to my Lens desktop application, again, via Lens Spaces. So I can only see this cluster if I’m actually logged into Spaces. And voila, we can see how this cluster is performing in the last hour. So real quick, Stephane created a space, added me to the space, shared the cluster to that space, and now I can view that cluster.
I do want to mention that everything’s very much based off of your role-based access control from your kubeconfig file as well as role-binding. So you can set different permissions for different teams within Lens as well. So if Stephane wanted to, he could create a team within that space specifically for developers and then give specific access only to, again, I’ll use the same words, specific namespaces, right. So maybe I only want my developer team to take a look at the namespace monitoring or something along these lines, or default namespaces or the kube system namespaces, and so forth. So you do have that ability to give your team members much more granular access control when sharing that Kubernetes cluster. And here we can take a look at how it’s performing, the pods, the workloads, and so forth.
And, of course, I can click into these things and get a much more granular view of how this particular pod is performing, in the last hour, through the Prometheus, the CPU, the memory, the network, the file systems, and so forth. So this is an awesome technology that was brought to Lens via Lens 5, which was released in late June. Again, it’s a cloud-based offering, it’s a centralized offering where you will need to create an account. It is free to use as of right now. There are some limitations depending on the resources that you’re spending and using. But it is free to use and all you have to do is register for an account and you can begin creating spaces and sharing clusters to that space, which would then give a team member access to that cluster. Excellent, I’ll stop my sharing.
Perfect, well, I think we took a look at everything we wanted to see today. Stephane, can you reiterate for the audience what we took a look at?
Stephane Montri: Yeah, sure. So basically, we did three main things, again, so we created a Kubernetes cluster, an MKE cluster through Container Cloud. So, we showed it is a cloud-like experience so really to bring a cluster to the experience in a way we want to create and govern the lifecycle of your clusters for work on a cloud, whatever the provider is behind. Then, we showed that we are able now to automatically add the cluster from Container Cloud to Lens and configure the cluster in Lens.
And at the end, we saw how easy it is just to share a cluster with my colleagues and say, okay, for example, my personal use case for this is I’m with a development team. I have an issue with my cluster and just want to ask for some help, have someone else look at it. Let me share the cluster with you.
Want to see the full video and follow along? The complete webinar is available here.