Introduction

Kubernetes Resource Modeling is the technique of building declarative APIs in the style of the APIs provided by the core Kubernetes Platform. There are expectations and conventions that are assumed throughout the Kubernetes API that allow tooling and automation to be built around it because it is consistent.

The declarative aspect of the API comes with the assumption that the user’s request will be continually monitored and fulfilled as other factors in the environment change. This is one reason why Kubernetes has gained as much traction as it has over the last several years: less stable code can provide a much higher level of reliability than it would otherwise be able to. The Kuberetes platform actively monitors and reacts to application failures, scale changes, and config updates.

This is relevant today because companies are now starting to enable their developer and operation teams to start attempting to build their own platforms for their own applications and finding a catered source of information for this topic is impossible. There are good resources but they are scattered across many media types and don’t tend to be in-depth enough to help when the work gets hard.

© 2024 Scott Nichols. All rights reserved.

What is a Kubernetes Resource Model?

© 2024 Scott Nichols. All rights reserved.

KRM in Practice

© 2024 Scott Nichols. All rights reserved.

Engineering Principles

© 2024 Scott Nichols. All rights reserved.

Encapsulation and Separation of Concerns

© 2024 Scott Nichols. All rights reserved.

Control Plane vs Data Plane

© 2024 Scott Nichols. All rights reserved.

Declarative APIs

© 2024 Scott Nichols. All rights reserved.

Kubernetes APIs

© 2024 Scott Nichols. All rights reserved.

Implementation Tools

© 2024 Scott Nichols. All rights reserved.

Custom Resource Definitions

© 2024 Scott Nichols. All rights reserved.

Kubernetes Concepts

© 2024 Scott Nichols. All rights reserved.

Resource Contracts

© 2024 Scott Nichols. All rights reserved.

Clientsets

© 2024 Scott Nichols. All rights reserved.

Listers, Informers, and Clients

© 2024 Scott Nichols. All rights reserved.

Work Queues

© 2024 Scott Nichols. All rights reserved.

Reconciliation Frameworks

© 2024 Scott Nichols. All rights reserved.

Modeling

© 2024 Scott Nichols. All rights reserved.

Providing Spec and Status

© 2024 Scott Nichols. All rights reserved.

Information Passing

© 2024 Scott Nichols. All rights reserved.

Layered Models

© 2024 Scott Nichols. All rights reserved.

Isolation and Role Separation

© 2024 Scott Nichols. All rights reserved.

Extendability and Providers

© 2024 Scott Nichols. All rights reserved.

Integration

© 2024 Scott Nichols. All rights reserved.

Testing

© 2024 Scott Nichols. All rights reserved.

Avoiding Tight Coupling

© 2024 Scott Nichols. All rights reserved.

Delegation

© 2024 Scott Nichols. All rights reserved.

Dependencies and Injection

© 2024 Scott Nichols. All rights reserved.

Duck Typing

© 2024 Scott Nichols. All rights reserved.

Common Model Shapes

© 2024 Scott Nichols. All rights reserved.

Reading

© 2024 Scott Nichols. All rights reserved.

Mutating

© 2024 Scott Nichols. All rights reserved.

Implementation Providers

© 2024 Scott Nichols. All rights reserved.

Abstract References

© 2024 Scott Nichols. All rights reserved.

Current Compromises

© 2024 Scott Nichols. All rights reserved.

Platform Building

© 2024 Scott Nichols. All rights reserved.

Iaas, PaaS, SaaS

© 2024 Scott Nichols. All rights reserved.

Building the Application around the Model

© 2024 Scott Nichols. All rights reserved.

Beyond Kuberenetes

© 2024 Scott Nichols. All rights reserved.