Okay. Okay. I am Marco Mancini. I am a social architect in Open Nebula System. Open Nebula
System is, okay. Open Nebula System is the company behind Open Nebula, the open source
software. So today, I will talk about how you can easily deploy Kubernetes clusters
on hybrid and multi-cloud environments by using our open source solution. So let me
introduce Open Nebula. Open Nebula was born around 14 years ago as a solution for private
cloud computing, you know, for on-premises. And evolved during the last years, and now
we provide a solution that allows you to manage different types of workloads. So going from
virtual machines to application containers to Kubernetes clusters along what we call
today, you know, the data-sender cloud edge continuum. So you can have resources on on-premises,
you can have resources on public or on far edge and so on. So what we would like to do
with this open source solution, no? Open Nebula is to provide you with a simple way in order
to manage different type of workloads along the, let's say, this cloud edge continuum.
And so you can minimize the complexity, you know, to manage these workloads. You reduce
no consumption of resources because you can manage different types across different kind
of resources and so on. So mainly what we, at the core of Open Nebula, we use different
virtualization technologies. So we go from supporting using VMware, KVM for virtual machine
workloads, to LXC for system containers, to Firecracker, where you can manage micro-VMs
and deploy container-based applications. And we manage these technologies by using clearly
advanced features, no? You can have multi-tenancy, self-service, no? You can provide resources
on these different virtualization technologies and so on. We have a graphical user interface
where you can manage all your resources across the, as I said, this continuum and also we
have integrated different third-party tools, no? Going from Terraform to Ansible to Kubernetes
and so on. So our vision about the multi-cloud is that we can, no, we would like to provide
an easy way for automatic provisioning of resources, no? Across multiple cloud providers.
That's the moment. So what we have built is a tool that is called the One Provision.
So you can see in the bottom, so we have also a graphical user interface, but it's also
a command line interface. So you can create resources on different providers. At the moment,
we support providers that has bare-metal servers like AWS and Equinix. But, yeah, we can support
other providers. We just need to write some drivers, no? That allow us to provide resources
also across different providers. Behind the One Provision tool, we use open-source tools
like Terraform and Ansible. So with this tool, with this One Provision tool, we can build
so different what we call edge clusters. So an edge cluster for Openable is an abstraction
where you have computing, you have storage and networking. So once you provide this edge
cluster, every cluster, whenever it's provisioning, can be managed by our uniform, just from one
managing place that is our Sunstone graphical user interface or with our command line interface.
And so from one just panel, you can manage all your clusters across different, for example,
providers or your premise resources. And then at the end, what we have is the concept
of marketplace. So whether you can have appliances or you can have, we have also integrated Docker
app. So you can have also Docker images that you can deploy. So you can deploy virtual
machine, multi-virtual machine, containers, and Kubernetes clusters across these different
resources that we have provisioned. So this is how we manage, let's say, multi-cloud
environment. So by using this One Provision tool and then our graphical user interface
and the marketplace. So let me introduce also how we have built Kubernetes, how Kubernetes
is integrated in Open Nebula. So for us, Kubernetes is just a service. So we have built an appliance.
I will talk soon about how we have built this appliance. So as I said, you can manage Kubernetes
by using our tool for managing any application, right? And then you can deploy on different
edge clusters, right? So you can exploit all the features that we have. So since we have
a multi-tenants environment, you can deploy Kubernetes clusters for all your tenant within
Open Nebula. So you want to deploy Kubernetes clusters on the same physical resources that
are shared. They will be deployed in a secure way because you can deploy by using our visualization
technologies and so on. And also you are not looking to any vendor because you can just
deploy your Kubernetes clusters on any, let's say, cloud edge or premise or far edge provider
that you would like to integrate within your infrastructure and the price infrastructure.
So how we have built Kubernetes, integrated Kubernetes in Open Nebula is we have defined
an appliance. It's called one key. This is just a complete Kubernetes deployment. So
it's based on RQ2 and we use the version 1.24 of Kubernetes. So we provide all the features.
So when you deploy this appliance, you have all the features included. So you don't have
to deal with managing deployment of a storage solution or ingress controllers or load balancing.
At the moment, we have used these technologies on our roadmap. There are some features that
we would like to include, especially a better integration with some of the features that
has Open Nebula. But at the moment, yeah, we have this kind of solution that is based
on, as I said, on RQ2. The one key appliance, these are the components. It's based on one
flow. One flow is a component in Open Nebula that allow you to define multi VMs applications.
So in a one flow service, you can have different roles. And each role, for example, in this
case, for the Kubernetes appliance, we have defined different roles. For example, we use
the VNF role. This is the load balancer for the control plane. But it also does NAT and
routing because we have two networks within our appliance. One is the public network
and another is the private network between the different components. So this VNF also
allows for the different VMs within the private network to communicate outside to the public.
Then we have the master role. His role is to manage the control plane, the ATC database,
the API, and so on. Then we have the worker nodes that you can use for any workloads that
you want to deploy on your Kubernetes cluster. And then finally, we have the storage nodes.
These are dedicated so they will not be used for when you have to deploy some workloads,
but they are used just for your storage needs. And we use Longcore for persistent volumes
within other Kubernetes, within the one case service. As I said, the VNF, this virtual
network function service provides a load balancer. So you can have multiple VNF, so in an availability
mode. Taking into account that OpenNebula offers you the abstraction of virtual machine groups.
So usually for having an availability solution, if you have a virtual machine, you would like
to deploy your virtual machine on different hosts in order to have an available solution.
So you can use OpenNebula VM groups and then using some affinity rules, your VMs will be
deployed for example on different hosts so you can have an available solution. And this
is valid for any role that you have seen before. So for any role, you can use these VM groups
in order to have also available solution. So one key by default, just create one VM for
each role, but you can modify and scale the solution. So having multiple VMs for each
role. So this is the VM. As I said, for the persistent volumes, we have this storage nodes
where we deploy a Longcore, we use Longcore. So you can have replicas of your volumes on
different VMs related to the storage nodes. Then we have, in order to access your services,
we need that you deploy within your Kubernetes clusters. You can have the ingress controller
you can use. We deploy an ingress controller based on traffic. So this can be used for
HTTP and HTTPS protocol. And then you can access the service by just defining an ingress
controller for your service. And then we have integrated also Metal LB, instead for the
load balancer service. So in this case, you can use this for other kind of protocols
that are not HTTP or HTTP based. Yeah, I would like to go because, yeah, it's almost,
I have five minutes now, more or less. I will prepare just a demo to show you how you can
use Open Nebula. So I will show you how to use one provision in order to provide resources
on AWS and Equinix. And then we can deploy a Kubernetes cluster on both edge clusters
that on this two public cloud provider. And then we just, you can just access one of the
Kubernetes clusters and just deploy an application. Let's me go on the demo. Okay, so this is
the Sunstone Graphica user interface that you can see here. If we go to clusters, we
have just the default cluster. But there are no host, no data, there are only data store,
there are no host. So in this moment, we have just our front end without any resources.
Now what's it go is to go to the one provision. We have defined already two providers, one
for Equinix and one for AWS. And once you define these providers, you can create clusters
on the two providers. So we are going to create a cluster, for example, in AWS. In this case,
we have defined a provider for AWS in London, the zone. And this will now create an edge
cluster on AWS. As I said, we use Terraform and Ansible to create resources and to compute
in such a way that you create an edge cluster for OpenEbula. And then here I'm going to
create another cluster instead of on Equinix. Clearly, you have some parameters. You can
define the number of hosts, you can define the number of public IP that you would like
to access, and so on. Okay? By the way, you can define two type of clusters with one provision.
One is an edge cluster, it's a base, or you can also create a safe cluster, an hyperconverged
cluster. As you can see here, once you use one provision in a Sunstone, graphical user
interface, you will see the hosts that are going to be proficient. And while it will
take around five, ten minutes, this depends on the cloud provider how much time it needs
to create resources. But once you have created the resources, you can see here the two clusters.
What you have to do is to instantiate a couple of, to use Kubernetes appliance, we have to
define a couple of private networks, one for Equinix and one for the other AWS clusters.
And in order to do this, it's simplified because we create a template, then you just instantiate
the template, and then you can create also the private networks, both for AWS and Equinix.
Because we need the private for the internal VMs, the roles like node, master, storage,
and the worker nodes, and then we need the public network instead for the VNF, that is
our main endpoint where to access the Kubernetes clusters. Now what we are going to do is to
import the one key appliance for our marketplace within our open Nebula. You can do this just
once. So we are going to import the appliance. And once you import the appliance, what will
be imported are templates for the VMs that are for each role, and the template for the
service. This service is based on one floor, and also the images that are related to the
different roles. So in order to create a new Kubernetes cluster, what we have to do is
to just instantiate a service by selecting the appropriate networks, for example. So
in this case, you can see now I'm creating a cluster on AWS. So I select for the public
network, the AWS cluster public for the private, the AWS private, and then I just have to put
a couple of IPs internal. These are for the internal networks, for the virtual IP, for
the VNF, and for the gateway. And we can do the same for Equinix. So by just selecting
the public networks of Equinix and then the private networks that we have defined. Also
in this case, I've used the same network for both clusters. And here you see that now we
are deploying the two Kubernetes clusters on the two different edge clusters that are
on AWS London and Equinix. As you see, the first role that is deployed is VNF. Once the
VNF is ready running, in one floor, you can define dependencies. And once the VNF is
ready, one floor is going to deploy the other roles, master, the worker, and the storage
node. In order to access the Kubernetes clusters, you have to use the public IP of the VNF.
And you can use SSH agent forwarding by using, you know, first connecting to the VNF and
then connecting to the master by using the private IP. Okay. Here we can see the nodes.
So we can have, as I said, by default, you have one node for each master clear. This
is not for production environment. If you want to have for production environment, you
need to scale each node, for example. So here, I just create an image and I prepared also
a YAML file, a manifest file for exposing the service through the ingress controller.
And then you can use the public IP of the VNF to access the service. Okay. Clearly OpenEBOLA
is not, doesn't have any tools for managing the deployment of application on Kubernetes.
So we manage the infrastructure and the deployment of Kubernetes cluster. Then you can use kubectl,
you can use Ranger, you can use other open source tooling, you know, that maybe in the
future we can add also. As you can see here, by using the public IP of the VNF, I have
access to the engine mix. Another thing, you can scale the roles once you deploy, for example.
In this case, I can scale, for example, the worker. You just put the number here. We use
the one flow, one flow allows us to scale the cluster for each role. Okay. And now you
can see another worker is going to be deployed. Yeah, this was the demo and I think that's
the conclusion. Okay. Thank you. Thank you all. Okay.