When engineers are thinking about how to make systems and software in a more efficient manner, the first thing that usually comes to mind is “what platform are we deploying this on?”. Although Kubernetes is certainly not the only platform, it is the platform that many engineers are choosing today to run workloads.

In this blog post, you’ll learn about a few methods that you can use Kubernetes and Platform Engineering together to ensure efficient and effective deployments.

Quick Platform Engineering Recap

Before diving into Kubernetes and Platform Engineering, let’s quickly recap what Platform Engineering is.

In short, Platform Engineering is a method of accelerating software delivery, efficiency, and velocity. This can mean a lot of things!

What it ultimately comes down to is giving developers an effective way to work with platforms in an efficient manner without them having to learn and dive into the platform. It’s the job of a Platform engineer to give developers tools that are easy to learn and use to interact with complicated platforms and systems.

Let’s now dive into a few methods of using Kubernetes and Platform Engineering together.

Internal Developer Platforms (IDP)

As mentioned in the previous section, Platform Engineering is about making a developer's life easier.

Not always, but a fair amount of the time you’ll see Platform Engineering associated with Internal Developer Platforms (IDPs). Platform Engineering does not mean it’s all about building IDPs, but as the name suggests, it is an internal tool that developers use to make their lives easier when interacting with complicated systems and platforms.

Because of that, it does make sense to talk about IDPs when talking about Platform Engineering.

An IDP can be a lot of different things, but the short version is it’s a portal that developers use to interact with systems and platforms. For example, maybe there’s a frontend/UI that developers use to add in some information about a Kubernetes cluster that they want. Once they hit the “Finish” button, a Kubernetes cluster is created in the background that has all of the developer's specs that they defined on the IDP.

A good example of an “out of the box” IDP is Morpheus

Crossplane

Crossplane is an interesting project that’s picking up steam in the community. It’s used to make Kubernetes the platform that creates various resources.

For example, with Crossplane, I can use Kubernetes to create an Azure Resource Group, Azure Virtual Network, or just about any other resources across Azure and other clouds like AWS.

It’s almost like using Kubernetes as the Internal Developer Platform (IDP).

At a high level, there are a few steps.

First, you install Crossplane.

helm install crossplane \
crossplane-stable/crossplane \
--namespace crossplane-system \
--create-namespace

Next, you add the provider.

cat <<EOF | kubectl apply -f -
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: upbound-provider-azure
spec:
  package: xpkg.upbound.io/upbound/provider-azure:v0.29.0
EOF

Once the Provider is added for whichever cloud you’re using, you’ll have to authenticate from the Kubernetes cluster to the cloud.

After that, you can use a declarative approach to create a resource. For example, the below Kubernetes Manifest creates an Azure Virtual Network.

apiVersion: [network.azure.upbound.io/v1beta1](http://network.azure.upbound.io/v1beta1)
kind: VirtualNetwork
    metadata:
        name: crossplane-vNet-azure
spec:
    forProvider:
    addressSpace:
        - 10.0.0.0/16
    location: "US East"
    resourceGroupName: devrel-as-a-service

Cluster API

There are many ways to create Kubernetes clusters. You’ll often see it done with an Infrastructure-as-Code tool like Terraform or via the UI.

One amazing method outside of IaC and the UI is creating clusters in a declarative fashion.

Utilizing Cluster API, you can create, update, modify, and delete Kubernetes clusters using a Kubernetes Manifest.

This method of creating Kubernetes clusters can very much fall under the Platform Engineering umbrella and aligns quite nicely with Operators, which you’ll learn about in the next section.

If there’s a Kubernetes Manifest that developers can use to add in a few pieces of information via a spec, it’ll make their lives much easier in terms of creating Kubernetes clusters for workloads. Instead of having to learn Terraform or the options available via the UI (which is usually at least 3-4 pages), developers can simply add in some parameter values, run kubectl apply -f against the Manifest, and have a new Kubernetes cluster up and running.

Operators

A Kubernetes Operator consists of:

• One or more Custom Resource Definitions (CRD).
• One or more Controllers.
• APIs that interact with external or internal resources.

Although an Operator can be used for many purposes, one purpose that’s coming up quite frequently is building an Operator to create resources. For example, you can build an Operator to interact with an Azure API or a VMWare ESXi API or any other on-prem/cloud environment that has an API available.

It’s essentially what Crossplane is doing, but specific to a particular cloud or on-prem environment.

Below are two links. One Operator for Azure and one Operator for Azure.

https://github.com/Azure/azure-service-operator

https://aws.amazon.com/blogs/opensource/aws-service-operator-kubernetes-available/