Kubernetes 1.27 Goes Galactic with OpenAPI

Exploring the integration of OpenAPI with Kubernetes 1.27 along with code examples.

Welcome to the brave new world where APIs have not just learned to dance but are performing ballet in zero gravity. In our today’s tech venture, we’ll be exploring the grandeur of Kubernetes 1.27 API, where the OpenAPI spec has landed and is revving up the engines for a stellar journey.

As we unpack the wonders of this remarkable integration, we’ll waltz through what the OpenAPI specification has to offer, how it works with the Kubernetes API, and the incredible benefits it brings to our development ecosystem. Not only will we be sharing two coding examples to illustrate the process, but we’ll also make it fun (because who says technology and fun can’t coexist?).

What is OpenAPI, and Why Should We Care?

OpenAPI is a language-agnostic specification for defining RESTful APIs. It helps us create, discover, and understand the capabilities of services without requiring access to source code or extra documentation. With the advent of Kubernetes 1.27, OpenAPI v3.0 has been made generally available, further enhancing the API functionality of Kubernetes.

In essence, OpenAPI simplifies the lives of developers in an understated yet profound way. It serves as a map, illuminating the pathway for us to create, discover, and understand the capabilities of various services, all without necessitating the arduous task of digging into the source code or sifting through tons of documentation. It’s like having a backstage pass that lets you explore the nooks and crannies of your favourite band’s concert venue.

But wait, there’s more. The versatility of OpenAPI is such that it transcends the boundaries of programming languages, making it a unifying force in the often fragmented landscape of technology. Its language-agnostic nature ensures that you can define APIs irrespective of the language employed in writing the application. So, whether your application is dancing to the tunes of Python, or grooving with Go, or even humming along with JavaScript, OpenAPI fits in harmoniously.

Enter Kubernetes 1.27

Since Kubernetes 1.27 announcement into general release, the integration of OpenAPI into Kubernetes 1.27 has opened new doors of possibilities for developers. It provides improved documentation, clear validation rules, and enhanced extensibility. This, in turn, allows for an improved user experience and robust service design.

OpenAPI v3.0 brings in a bouquet of features and enhancements to the Kubernetes API. From offering a more detailed and robust schema for defining APIs, to improvements in describing request bodies, responses, and multipart form data, it truly ups the ante. And if you’re passionate about security, you’d be thrilled to know that OpenAPI v3.0 introduces enhanced security definitions, which allow for better and more granular security schemes.

Here’s what the arrival of OpenAPI in Kubernetes 1.27 means for us in the Kubernetes-verse:

1. Validation: OpenAPI offers in-depth validation rules, enhancing the integrity of our data and cutting down on errors.
2. Documentation: Now, the API can be self-documented! With OpenAPI, Kubernetes API can provide more detailed and accurate documentation.
3. User Experience: Detailed error messages make it easier to troubleshoot and resolve issues, leading to an overall better developer experience.
4. Extensibility: OpenAPI paves the way for future enhancements, keeping Kubernetes on the leading edge of technology.

Let’s get into the code part of proceedings

For our first example, we’ll take a look at a Custom Resource Definition (CRD) with OpenAPI v3 field validation. This will allow us to ensure our custom resources follow the rules we set:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: myresources.stable.example.com
spec:
  group: stable.example.com
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              cronSpec:
                type: string
                pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
              replicas:
                type: integer
                minimum: 1
                maximum: 10
  scope: Namespaced
  names:
    plural: myresources
    singular: myresource
    kind: MyResource
    shortNames:
    - mr
status:
  acceptedNames:
    kind: ""
    plural: ""
  conditions: []
  storedVersions: []

Here we have a CRD named myresources.stable.example.com. It validates that cronSpec follows a specific regex pattern and replicas are between 1 and 10. If you want to explore CRD’s some more, check out this article on Implementing Custom Resource Definitions.

Next, let’s see how Kubernetes’ response changes when we try to apply a resource that doesn’t comply with our new rules:

apiVersion: "stable.example.com/v1"
kind: MyResource
metadata:
  name: my-resource
spec:
  cronSpec: "* * * *"
  replicas: 15

Trying to apply this resource with kubectl apply -f my-resource.yaml, you’ll see an error message like:

The MyResource "my-resource" is invalid: spec.replicas: Invalid value: 15: must be between 1 and 10, inclusive

Here, Kubernetes rejects the custom resource because replicas is outside the specified range.

On the other side of the spectrum, we should be able to apply a resource that complies with our new rules without a hitch. Let’s try to create a resource that fits within the guidelines we established:

apiVersion: "stable.example.com/v1"
kind: MyResource
metadata:
  name: my-resource
spec:
  cronSpec: "*/5 * * * *"
  replicas: 5

If we apply this resource with kubectl apply -f my-valid-resource.yaml, it will be accepted because it meets our validation criteria. cronSpec follows the specific regex pattern and replicas are within the range we specified.

You can check the status of your new resource with kubectl get myresources.stable.example.com my-resource.

Schema-less Validation

Remember that it’s also possible to create Custom Resource Definitions without specifying a schema for field validation. In such cases, you won’t have the same validation constraints.

Here’s an example:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: schemaless.stable.example.com
spec:
  group: stable.example.com
  versions:
  - name: v1
    served: true
    storage: true
  scope: Namespaced
  names:
    plural: schemaless
    singular: schemalessresource
    kind: SchemalessResource
    shortNames:
    - slr
status:
  acceptedNames:
    kind: ""
    plural: ""
  conditions: []
  storedVersions: []

In this example, we’re creating a CRD named schemaless.stable.example.com, but we're not specifying an openAPIV3Schema field. We're now free to create resources of kind SchemalessResource with any properties under spec.

apiVersion: "stable.example.com/v1"
kind: SchemalessResource
metadata:
  name: my-schemaless-resource
spec:
  anyProperty: "I can have any property here"
  replicas: 100

Running kubectl apply -f my-schemaless-resource.yaml would successfully create this resource, even though replicas is outside the range we specified for myresources.stable.example.com. But remember, with great power comes great responsibility. While schema-less validation provides flexibility, it can also lead to inconsistencies if not managed properly.

A Tech Tale Told Under the Kubernetes Sky

As the curtain falls on our starry journey through the Kubernetes 1.27 API and OpenAPI, we find ourselves standing on the precipice of endless possibilities. With better validation, improved documentation, superior user experience, and enhanced extensibility, we are geared up to unlock new frontiers of efficient and effective application development. So, embrace this new era and let your creativity take flight!

By harnessing the power of Kubernetes 1.27 and OpenAPI, we have now unlocked a toolkit that is more than just lines of code. It’s a gateway that ushers us into a world where our applications become smarter, our work becomes smoother, and we become the maestros orchestrating an ever-evolving symphony of seamless automation and robust functionalities.

The voyage doesn’t end here, there are galaxies to explore within the Kubernetes cosmos. Fuel our next expedition with your engagement. Clap if this piece resonated, or subscribe to join on future ventures into the tech world’s frontier.

Further Reading:

Kubernetes Monitoring with OpenTelemetry

API monitoring vs. observability in microservices

OpenTelemetry: A full guide

Serverless observability, monitoring, and debugging explained