Oxide Integrations: Empowering Platform Teams and Developers with Oxide Computer

Hey everyone. Uh, Matthew Snar here from Oxide. I lead the solutions software engineering team here and we are focused on taking that GTM and customer feedback and taking them and making them engineering projects and building integrations.

Uh, I myself have a decade of cloud and on-prem experience in site reliability, engineering roles and software engineering roles. And today I wanna talk to you about integrations. So I wanna start with platform integrations.

So what exactly are these platform integrations that we're building at Oxide? Well, these are these integrations that enable platform teams to develop on top of oxide. As Brian and Steve already noted, oxide is API driven, it's API first, we have our own ui, our web console where users can interact with oxide and create resources.

But your engineering teams, they're not gonna use the, the, the UI to do this sort of scale integrations that they're meant to do for your business. So these integrations are familiar across cloud providers. And I wanna cover the following.

We have a go SDKA Terraform provider and a Packer plugin. And I'll do that with a demo. So in the UI here, you can see that I, I have oxide open here and I have some instances running.

I'm just going to show you a quick demo of the go SCK. So here I have a main do go file, which is building our, our, you know, it's connecting to our oxide rack and we have this published publicly. And what this is doing is it's allowing people to integrate with oxides rack via a programmatic way.

So how does this all work? Well, if you click the docs in our website, in our, in our instance, you can see that it takes you to our oxide docs. We publish an API all the documentation for it.

And more importantly, we publish an API schema. So we generate our API with an open API schema and you can use that to generate any number of SDKs. And that's what we do internally.

We have a Russ, SDKA, TypeScript, SDK, and a go, SDK. So this is me using this go SDK. So if I actually run this, so if I do go run and I'll give it the project and the SH key, this will reach out to oxide.

And this will go ahead. If I go back over to my, to my um, UI here, this is gonna go ahead and create this cloud field day go instance using the go SDK. And that's great.

But what happens when you wanna manage a state about this, if I'm an engineering team integrating, I need to manage, I need to write extra code to manage the lifecycle of this, of this machine, right? If I rerun this go program, it's just gonna create another instance and another instance, there's no management of the state and that's where something like the Terraform provider comes in. So I'll go ahead and go to the Terraform and I'll do Terraform reply.

So now we're using this go SDK to create our Terraform provider. So under the hood, Terraform is calling our go SDK, which is in turn calling our oxide API. And now not only can I get an instance created, but the state of this is gonna be managed.

So this is creating the disc first and then creating the instance to boot from that disc. But now operators have control over the state of their machines. So I can go ahead and destroy that and I'll leave that running in the, in the background.

But also there's more integrations. For example, let's say you are running an engineering team and they Need to build images for oxide, specifically images that bake in application or business specific logic. Well, we have a Packer plugin to do just that.

So Packer is a way to build images for different cloud platforms. We created an oxide cloud plugin for this. So if I run Packer build, this is going to reach out to oxide, it's gonna say, Hey, I would like to create an instance from a base image.

And then that instance will be, you'll see that coming up right here and it's going to, once that image is started, it's gonna connect to that image over SSH and it's gonna provision that instance. And this is where you would put your application specific logic in such as app, you know, application, system D, unit files, whatever you need for your business to, to have in the image. And then once that image is created, and I will grab a pre-created image name real quick 'cause I don't wanna wait the minute 45 for Packer to, to finish running.

But once that image is created, and I'll go back into the Packer folder, you can use that image with something like Terraform and you can say, Hey, what image do you want to use? So now I'm creating a new instance from the image I've built with Packer that has my business logic within. And you might be saying, Matt, what business logic is inside of this?

And in this example, the business logic is really just a engine X web server that I run that says hello from Packer. Um, s once instance, once this instance is started up, you would see a, like if I go to its external ip, you will see a hello from Packer. And I'll leave that in the background 'cause I'm just waiting for the instance to start up.

So between these go SCK, the Terraform provider and the, and the Packer plugin, these are the integrations that operators and your engineering teams are expecting. They wanna be able to build images with business logic built in. They wanna be able to manage resources at scale using something like Terraform.

And for those things where maybe Terraform or Packer isn't the right fit, you have the go SDK under the hood so that you can write your custom integrations from there. And I will let that open up real quick and you can see like, hello from Packer, this is me with that I use Packer to load a business specific logic, random an instance, and my business logic is in there. Cool.

So that's on, that's it for the platform integrations. I then wanna cover other integrations and I'll repeat, hello, I am Matthew Berry again, still, uh, still leading the solution software engineering team from the last five minutes. And uh, our focus is on creating integrations for oxide that customers are asking for, but not super specific to customers.

We wanna address the commonalities in the industry. And I want to shift focus here to something that Brian actually teed up for me, which is Kubernetes integrations. So Kubernetes integrations this, they're kind of a beast, right?

We have, you have your platform engineering teams, your operation teams, they are writing their own code to work with underlying infrastructure providers, but some of those teams are standardizing on a platform and generally they're picking Kubernetes. And we've seen that in the last decade. So we also have integrations at Oxide to deploy and manage Kubernetes running on Oxide.

And these integrations should sound familiar if you're in the Kubernetes ecosystem. So we've created a cloud controller manager, we've created a rancher node driver, and we've created an omni infrastructure provider. And we know that people are bringing their own Kubernetes to oxide, but they're also probably already using a Kubernetes distribution such as suse Rancher or Lins or OpenShift.

So we wanna integrate with those as well. So let's demo a little bit of that. So I wanted to first demo the cloud controller manager.

Now the cloud controller manager and I will just, I already pre-created the infrastructure for this previously and I just have to run this bootstrap command. So this one is pretty interesting. The a cloud controller manager for Kubernetes is how all of those public cloud providers are providing you with a managed Kubernetes offering.

They're using this cloud controller manager integration, which is a Kubernetes native way of integrating. And what it does is it runs all of these controllers that are meant to interact with your underlying cloud provider's, API. And what does it do?

It manages things like node health load balancing routes and other controllers that you may want to do. So in this case, I have run, I created a Kubernetes cluster running on these three nodes and I've bootstrapped it. And now if I get its cube config file real quick, override, override, now I have a Kubernetes cluster.

And in a, in a minute after these nodes are are running, if I do like get all, you'll see that this is, this Kubernetes cluster is starting up 10 seconds ago. And this is kind of what I wanted to show you. So I'm glad I caught it pretty early.

So if I watch this for a second and I do QCTL get nodes, and I just look at the nodes that are coming in my cluster, and this will take about 30 ish seconds, but I wanna catch it here because I wanna show you the, the, the point here. So I'll give this a, a few more moments. Yep.

As you see, this is still 33 seconds old and I can go sorry for that two, one of these instances and show you the serial console. This is applying all of the Kubernetes components to turn these three otherwise seemingly virtual machines into a Kubernetes cluster. Lemme go back here and give this a second.

Cool. So now you see here these notes are not ready and I wanna catch them before they become ready. So I'm gonna jump in really quickly and get to a point where I can show you them, ah, they already turned ready.

But when a Kubernetes cluster comes up, the nodes are marked as not ready because it has to form, it has to do its consensus and form a cluster and say, Hey, are you my, my toe node? Oh, yes I am. Let's talk to each other.

So that doesn't happen magically under the hood. That actually happens, and I'll show you this via what's called a cloud controller manager. One of the controllers that it runs is called the node controller.

And this node controller is responsible for reaching out to the underlying cloud platform oxide in this case and saying, Hey, this node, does an actual instance exist in the cloud provider because I'm ready to market as a node in Kubernetes, but I don't wanna do that if the cloud provider Says that instance doesn't exist. So what this cloud provider, what this cloud controller manager does, is it reached out to oxide, verifies this instance is healthy and up and active, and then says, Hey, yes, this instance does exist. Here's its identifier.

So this will match the instance ID and oxide, and then further controllers can now look at this and use that ID for other resources. And we'll cover that a little bit later. The interesting part about this is when a, let's say you have a network partition in your Kubernetes cluster where you have three control plane nodes that are talking to each other, but there's a network partition for one of them.

That's a pathological case in Kubernetes, because now if Kubernetes can't say a control plane node exists, it might want to kill it and remove it from the Kubernetes cluster. But if you have a cloud controller manager reaching out to oxide as a source of truth oxide can then say, yes, I know you can't see the Kubernetes nodes, but I can, and it's existing and it's running. Please don't remove it from the, from the cluster and cause some cascading failure.

Cool, let me get outta this. If you are running a specific distribution of Kubernetes, maybe SUSE Rancher, we have integrations with that. So I'll open up my rancher dashboard here.

So I have rancher running, and if I load this up, you will see that we have what's called a oxide rancher, no driver. Now, when you create clusters in rancher, what happens is you can choose from a number of Kubernetes providers that you can run infrastructure on. One of them is oxide.

So if I click saying, Hey, I wanna create a Kubernetes cluster on oxide, I get this nice UI saying, please provide me with the boot image, you want to use the size and so on and so forth. Now I will do that via the API real quick. So I'll do QCTL, uh, get notes to verify that I'm indeed talking to rancher.

And I'll do QCTL apply dash f oxide manifest. And this manifests, I'll just cat it out real quick. This creates the configuration to boot on oxide and the cluster config to say, Hey, what version of edes you want to run, what machines you wanna use, so on and so forth.

So I'm booting a one node Kubernetes cluster. So now if I go back to rancher, you'll see that this cluster is being created. And if I go to oxide, you'll also see in a moment that this node is being created or this instance is gonna start being created right here.

So now this is rancher using an oxide plugin that we've built to create nodes on oxide to make Kubernetes clusters. And I won't show you the full, I won't wait for that to be ready. I'll just move on to the next thing.

So outside of that though, let's say you're not running rancher. Let's say you, you are using a new system out there. We have partnered with the folks over at, um, side Ciera Labs.

They run, they create a, a immutable Linux operating system called Talos Linux that is perfectly suited for being a Kubernetes node. And they have their own project called the Omni, which is a way to manage these otherwise, you know, disparate Talos Linux machines and create Kubernetes clusters from them. They have an integration too, which I will Show you.

So I'll open up Omni and you'll see here that I have this oxide infrastructure provider hooked up to side arrow's Omni. And if I wanted to create a Kubernetes cluster, it's as simple as going into clusters, hitting crate cluster, choosing the version of Taos, and now I'm specifically choosing version 1 11 3 because there was a patch in do three that I worked with Tala team on to get in there and I need that. And then from here I can say, Hey, for my control plane, I really want you to spin up three of them and I want you to use this oxide infrastructure provider to reach out to oxide to actually create the resources for it.

So if I do this and I won't make any work, nodes doesn't matter. So now I've created that. Now you can see here my, my actual infrastructure provider is filled with locks because it's doing things.

How Omni has reached out to my provider and say, Hey, I need to create three nodes on oxide stat. And the provider's saying, great, I will go do that for you. So if I go back into oxide and I refresh this, you will see these machines are starting up now and everything's live and running.

So these sorts of integrations, the control, the cloud controller manager, the rancher node driver, and the omni infrastructure provider give us a lot of flexibility for running Kubernetes on oxide. And in the future as we add more things to oxide, like a load balancer, like other controllers, we can, we have ways now to integrate them with Kubernetes on day zero essentially.