Simplifying the tooling you need to manage infrastructure at scale

Hello everyone, this is my first talk in English. So, my name is Alejandro. I am a Go developer in the research team at Civo. Today, I'll discuss how to simplify the tooling that you need to manage infrastructure at scale.

So, how do we manage infrastructure today? Everyone is using the same tool, but we're using the Terraform, Crossplane, CLI, and provided libraries created in Go, Python, or another library. First? No, yes, I like it.

It's a pleasure for me to introduce you to the Open Control Plane. We made a presentation on the main stage, so a demo this time will go more deeply into the Open Control Plane. So basically, we built a new API, and we call it Open Control Panel, OpenCP. We added to that API new objects compatible with Kubernetes kubectl. We created a single interface. The idea of the Open Control Plane is to create a single interface for all clouds.

But, if you do not need to write a file in Terraform for one provider and if then you decide to move into another provider, you need to rewrite that file again. We think you only need one tool to manage everything, kubectl. And I am 100% sure everyone has that tool in their machine. And you don't need any additional tool. That's the beauty behind the Open Control Plane.

I will show you a small demo and how we're doing, and then we can go more into the architecture and things.

So, we have two files: cluster and namespace, I will call 'namespace'.

We have a definition, a namespace, normally the user to create a namespace in Kubernetes, nothing different. What we do is we tie the namespace to a Civo Network.

You can compare the same with PVC and AWS or Digital Ocean. It will be the same. We keep the namespace to make it compatible with kubectl. In that way, you can pass -n or -N, uppercase or capital letter, and you can list all your namespaces like 'kubectl get namespace'.

This is my namespace on my network inside Civo, returning in the same way that you do it during the cluster. Let's say you want to create a new apply namespace.

I created a new namespace, called OpenCP. If I list it again, it should be there. Hopefully, you can see it's already there. It's simple, I don't need to worry what happened behind and if it's compatible with Civo or not. It's a single YAML file. Suppose that you have the same interface for Digital Ocean, Linode, AWS, GCP. It will be the same file and you only need to change context. I need it in GCP, apply, it will work. I need it in AWS, apply, and work.

Let's go further, let's say I want all the Kubernetes clusters I have in my account. I have a single cluster in the kubectl namespace, with two pools, with public IPs, state active, and was created that day. I can remember the thing. Let's do it and apply a new cluster. Create a new cluster in the new namespace. Say, 'cluster'. This is a demo file with a simple definition. API version of NCP V1, also one, of course, is alpha time, Kubernetes cluster, the metadata, you pass cluster name, namespace, you will equal the network of VPC. This spec, you declare the pools. The pool contains the size that I did for the pool and the count. They are optional params that you can use for other clouds, like autoscaler, true, minimum size and maximum size. But in our case, we don't use it. So that part will be optional and depending on the provider, user or not. The version of Kubernetes we wanted and the Cli plugin. It's a simple YAML file. Let's apply. 'Kubectl, Apply, cluster.yaml'.

The idea behind OpenCP, I don't want to say we want to replace Terraform or Crossplane or Pulumi, but yes, basically, you don't need to rewrite your configuration file to move from one provider to another.

You don't need to say, for example, in the case of Civo, you use a Civo Kubernetes cluster as a resource. If you want to say the same with AWS, you need to say resource AWS cluster bla. See, you need to rewrite the whole files again.

With this, you don't need to do that because the same yaml file will work with every provider. So, maybe we call version 122.11, maybe in AWS it's AWS 1.20.1. You only need to check the version, because it has to be compatible with the provider, but that's it, you keep the same structure.

Let's list again, let's say kubectl, I would list all my clusters in the kubectl namespace. Oh, I put it right. But that's not the namespace that we used in the demo file. So, we want to see every cluster that we have. We pass -A, so it's using kubectl like you do it regularly in your daily work.

So now, we have two clusters: one in the OpenCP namespace and the other one in kubectl namespace. One is upgrading and the other one is active. It's upgrading because I deployed an old version and our platform automatically will re upgrade to the latest version. But we can go to the Civo webpage. We can refresh. We can see the OpenCP network here. We can go to Kubernetes. And we can have both clusters. It would be the same with using YAML file and kubectl of course.

Another feature: You can say, for example, get secrets. This is cool, basically we store the kubeconfig inside the secret. That secret, for now, I can do that. Right, okay. I don't know that secret for now, no, the card is still being set up. You can see how we do it. Basically that secret now is built on the fly. So when you request a secret, we get the kubeconfig and we build the secret object compatible with kubectl and we return it. So that secret, we don't store that secret in any way or any place. So it's safe.

Let's say I wanna, give me the secret for that cluster. Oh sorry, I put it in secure, it's the local development. Give me the secret for that cluster in that namespace. Oh yeah. I'm not sure. No, it's the same for some reason. So, basically, it gave me the secret and the type is Opaque. The data, it only contains one data inside the secret and was created 21 days ago, the creation date from the cluster. So, if the cluster is 100 days old, it will be 100 days old. You can say Kubectl returns that secret, the YAML file of the secret. It's the way we use it to get the data from the secret.

Basically, we're returning a valid version of the YAML, the data in YAML format, with the data and the kubeconfig. You can decode it and you have your cluster configuration. You put it, and you only need to change the contexts to manage infrastructure, to manage the cluster. That's it.

We go back to the presentation again. Hope this works well. The Open Control Plane architecture is structured this way. Open Control Plane depends on three projects right now: OpenCPs API, which contains the API declaration and the Proto Buffer files to create a client and server. The OpenCP shim uses the Proto Buffer files to create a client and the provider implementation. In our case, it's Civo. Civo Open Control Plane uses the same aspect to create the server. So kubectl talks with the shim. The shim, using REST, talks with the implementation using gRPC, and the provider implementation talks with the cloud using REST, and returns it in the same path. REST, gRPC, gRPC. And we convert it back into the format for kubectl.

The benefit for the end user is that you only need one tool to rule them all. The Lord of The Rings, think about that. A well-known interface, everyone knows YAML, and if you don't know, you can learn it. It's easy. Everyone knows kubectl get cluster, describe, watch. I want to say, the OpenCP shim is 50% compatible right now with kubectl. We want to keep it growing, and take it to 100% compatible with kubectl. So you can watch resources, you can do the same that you do with Kubernetes, do it with Open Control Plane. Also, you can filter by namespace or BPC or the name that you used in your provider, list in ultimate space or a specific namespace.

The benefit for the cloud provider will be they don't need to maintain multiple tools or libraries, and they can put features quickly to the end user. And the end user doesn't need to update any tool to the last version. I have an example. These are... I didn't sleep about that yesterday in the night. Then, it occurred to me, okay, we need a way to get the secrets from the kubeconfig using kubectl.

After three to four hours, we see the kubectl is not thinking of returning to return a kubeconfig. So we decide, okay, we're going with the secret. It took me like one hour to implement the secret, push it to production, and you see it. So, I don't have today any tool. I don't have to, they release a new version of the CLI, because it's already there.

And it's easy to adopt by the cloud native. It's simple. You don't need to worry about the compatibility between clouds.

How to get involved? Use it, create an issue, return feedback. Pull requests are welcome on GitHub. There is a repo for the spec, repo for the shim. We have an example of the Civo Open Control Plane, you can use it as a base to create more providers. And there is a repo for documentation. You can contribute in any way, any suggestions or anything.

How to use it with Civo now? This is already live in the three regions that Civo has, not the Phoenix one, okay, not yet, tonight. We will launch it tonight in Phoenix region. In the documentation repo, you have an example of the queue config that you need and you can play, return the feedback, that would be awesome.

This is an example of the kubeconfig. It's basically the same that you use every day to talk with the cluster: the cluster server name, a context, the user and your token for Civo. Even the token will be the same for Civo, for AWS, DigitalOcean, Linode, whatever. You only need to change the name and the context, that's it. Questions in that way? Yeah, I have problems with English and things but then… Okay, I will try to respond to the question if I can. Forward. Yeah, sure.

Q&A Session:

Question: Okay, thanks for the presentation. Short question. So, every region has an Open CP endpoint, and I can use it with my kubeconfig to communicate. So the CRTs will be used to authenticate against this?

Answer: Yes, okay, that's the thing. Every region has deployed the Open CP shim with the provider implementation in the same container. So it's a pod with two containers. When you send traffic to the region, you send it to that pod. That pod gets the token and sends it to the API. The API endpoint is the same for every region, so your token will be valid in every region.

Then, you have three queue configs in your kubeconfig folder, you only need to change contexts. Like this, for example, I will show you, I have a… I use this tool, this awesome Kubeb. If you don't use it, use it, it's fine. You see I have OpenCP Frankfurt, and OpenCP London. So I have two contexts and you can change between contexts. It will be the same. Go to the Civo webpage and go to the border and say, 'Region from region London, region New Jersey.'

Okay, the endpoint is from Civo. That's... it's not something I need to deploy in my own, noting a cluster, it's a public endpoint and it just gets authenticated.

The idea is okay, get involved, all the cloud providers, in that way you don't need to do anything. So we have right now opencp.london1.civo.com. Suppose that you have opencp.sanfrancisco1.digitalocean.com. That's it.

The idea that we're doing behind this is that every cluster would be an availability zone. So if you're going between Amazon availability zones, that would be its own cluster endpoint. So that you can switch between contexts. Then users would be, for example, if you had a staging and a production user with different RBAC privileges, you'd be able to set up your kubeconfig to be talking, saying to London with staging and then you change context to talk to Frankfurt with production and you'd get different credentials. And the tokens that you're providing, at the moment it's only token-based, kind of bearer tokens, but we'd be looking to contributions to do all of the other authentication methods. So there are like the JSONs or the OAuth plugins. So that's already supported inside kubectl, and we'd just be looking for support for the shim to support that and pass through to the cloud provider.

Question: Do you think that you will get any pushback from adoption by other cloud providers because of this shimming above an API but kind of pretending it's a cluster?

Answer: Good question. I don't know. I don't know. That depends. But, forward. It's something that we've got to do to get adoption across other vendors, right? So, all of these tools that are out there definitely have this initial struggle to get out there. But, it's something that we believe in, that it's going to benefit the community and the end user. So, we're going to push it from a Civo point of view. Because, internally, Alejandro's pointed out some of the benefits that this has to us. I see it replacing our CLI entirely and that we just get rid of it. I'd love for this to have wider adoption and not just be our project. End goal, if I can get this given to the CNCF so that the specs, maintained by a committee across all cloud providers. Everyone's got their own interests and they have their own things. I've been talking to people today who have been saying that Ingress was meant to do this, but then there are annotations left, right and center for all of the variations that every cloud provider has. I would love to us to be in a place where we can agree that, wait, no, this is the spec for a load balancer. And there are optionals that are provided and that you can move across through. But if we can define and this is for us as a cloud industry to solve, to make your lives as an end user better. So, it's something that we will be pushing forwards, almost on your behalf and taking that fight on.

Yeah, I think this is a powerful tool. We have a joke in the research channel, with David and the other guy in the research, and say, 'Okay, we can create our coffee machine and put it implementation, talk with the team, and we can send to create, make a coffee, using a YAML file. It's simple because the implementation will be talking with the coffee machine and you only need to say, 'kubectl apply, make a coffee'. That's it.'

I think, Matt, on your other point as well, about a pushback from providers about the shim. The shim is there to provide a common interface for kubectl, and we're hoping that providers themselves would take on the responsibility for the interface between the shim and the endpoint. I would be pushing that people replace the API endpoint with something that is shim compatible. So then rather than you having a shim that goes through this proxy, and then to an API endpoint. If cloud providers are willing to just make their cloud endpoints gRPC compatible, the shim would talk directly to that. Or even better, if they make their current REST API endpoints compatible with this, then the shim and the translator effectively are no longer required. But that is, that's a huge amount of work, that's not something that anyone's going to take on lightly. But, you know, utopia, change the world, future thinking, that would be, that would be awesome. Any other question?

Question: Is OpenCP currently open source?

Answer: Yes, it's open source, Open Control Plane, and is under Apache 2 license. So, you can use it.

Question: Do we have any clients using this now?

Answer: Not today. It's been launched out to the public today. This is the first time it is being seen. You are welcome to use it and be one of the first clients. You need your API token and that's it. But it should, it shouldn't be any different than hitting our REST API because it is just going via the REST API. Let me know how you get on.

Question: So, are you planning to reduce, for example, the maintenance of your Terraform provider, for example? Is something to say, okay, first our shim get the latest new features, and then, yeah, we will push this also to the Terraform provider. This is still equal. Every possibility to interact with you?

Answer: We will try to maintain both projects at the same time. So, right now I only one who code for shim and made all the reviews for Terraform provider. But, I would try to find the time to do... I say, I don't sleep, but I will find the time to keep every feature at the same time in both. Yes. So, we don't plan to launch something in shim and say, okay, we have this, but you need to wait two months to get it in the Terraform provider. So, the idea is launch, service, and have it in both, service on in every service that we have. Which currently is CLI, API, Terraform, Crossplane, Pulumi, and now we'll just add one more as well. It's basically a lot of service. That is why we think this will be nice because we only need to put a feature to the shim and you already have the tool. So, you don't need to worry if you are in the right version of the CLI, if you have the right version of the provider. You have kubectl, the machine for the first time, the first to do it is okay. Thank you.