The software industry has undergone significant changes in how applications are deployed and supported, particularly with the rise of containerization and Kubernetes. Traditionally, application vendors certified their software for specific operating system versions. Kubernetes introduced a new paradigm that potentially changes this support model. In this post, I want to examine whether it is time to shift from traditional support models to supporting Kubernetes (API) versions.

Traditional OS-Specific Support Model

How the Traditional Model Works

In the traditional model, software vendors test and certify their applications against specific operating system versions and patch level. This approach creates a tightly controlled environment where the vendor can ensure compatibility and performance. For enterprise applications vendors like SAP, Oracle or Microsoft this model has been the standard for decades – with detailed compatibility matrices specifying app versions are supported on which OS versions and what patchlevel.

Benefits of the Traditional Model

1. Predictability and Stability: By limiting supported environments, vendors can thoroughly test their applications in controlled conditions, reducing the risk of unexpected behavior
2. Clear Support Boundaries: When issues arise, there’s a clear delineation of responsibility between the application vendor, OS vendor, and customer
3. Simplified Testing: Vendors only need to test against a finite number of OS versions rather than an infinite combination of configurations
4. Established Processes: Enterprise customers are familiar with this model and have built their IT operations around it

The Kubernetes Paradigm Shift

How Kubernetes Changes Application Deployment

More than 10 years ago, first Docker and then Kubernetes started to introduce an abstraction layer between applications and the underlying infrastructure, using containers to package applications with their dependencies. This creates a more consistent runtime environment regardless of the underlying infrastructure. Kubernetes provides standardized APIs for deploying, scaling, and managing containerized applications across different environments – including fundamental infrastructure abstractions like storage (volumes) or networking capabilities.

The Kubernetes Conformance Testing Process

Kubernetes is governed by the Cloud-Native Computing Foundation (CNCF). And the CNCF has established a process to ensure “Kubernetes actually is Kubernetes”. This is called conformance testing. Kubernetes conformance is verified through Sonobuoy, a diagnostic tool that runs the official conformance test suite. The conformance test suite checks whether Kubernetes distributions meet the project’s specifications, ensuring compatibility across different implementations by covering APIs, networking, storage, scheduling, and security. Only API endpoints that are generally available and non-optional features are eligible for conformance testing.

The CNCF has made significant progress in conformance coverage – from approximately 11% of endpoints covered by tests in 2018 to less than 6% of endpoints not covered by conformance tests as of Kubernetes 1.25. This comprehensive coverage means that any CNCF-certified Kubernetes distribution must support the same core APIs, regardless of the underlying infrastructure or vendor-specific additions.

The Case for Kubernetes API-Based Support

At the same time, many application vendors are still applying the traditional OS-specific support model to Kubernetes by certifying their applications for specific commercial Kubernetes distributions. This approach treats each Kubernetes distribution as if it were a different operating system, requiring separate certification and support processes.

Benefits of Supporting Kubernetes API Versions

1. Simplified Support Model: By focusing on Kubernetes API compatibility, support becomes more straightforward, with clearer boundaries between application issues and infrastructure issues
2. Improved Portability: By supporting Kubernetes API versions rather than specific distributions, applications become more portable across different environments
3. Vendor Lock-in Concerns: Some customers worry about vendor lock-in with specific Kubernetes distributions and want assurance their applications will work in other environments
4. Reduced Certification Burden: Application vendors can focus on testing against standard Kubernetes APIs rather than multiple distributions, reducing the testing matrix significantly
5. Faster Innovation: Application vendors can release updates more quickly without waiting for certification across multiple Kubernetes distributions
6. Alignment with Cloud-Native Principles: This approach better aligns with the cloud-native philosophy of platform independence and portability
7. Kubernetes API Stability Guarantees: Kubernetes provides strong API stability guarantees, especially for GA (Generally Available) APIs, making them reliable targets for support
8. Support Ecosystem: Established support channels and partnerships exist between application vendors and Kubernetes distribution providers

Challenges with the Kubernetes API-Based Approach

While there are many advantages to this approach, of course there are some potential challenges.

1. Distribution-Specific Features: Different Kubernetes distributions offer unique features and extensions that applications might leverage
2. Enterprise Customer Expectations: Many enterprise customers still expect vendor certification for their specific Kubernetes platform
3. Varying Implementation Details: Despite standardized APIs, implementations can vary across distributions, potentially causing subtle compatibility issues
4. Security and Compliance Requirements: Enterprise customers often have specific security and compliance requirements that are tied to particular distributions

Practical Considerations for Application Vendors

So what can be done about the situation? And how could the cloud-native community move forward towards a new model? As always in life, a balanced approach might be the best option to get started – and evolve from there.

Implementing a Balanced Approach

1. Define Core Requirements: Specify minimum Kubernetes version and required capabilities (like RWO volumes or load balancing) rather than specific distributions.
2. Tiered Support Model: Offer different levels of support – full support for tested distributions and best-effort support for any Kubernetes cluster meeting API requirements.
3. Leverage Kubernetes Certification: The CNCF Kubernetes Certification Program ensures distributions meet API compatibility requirements, providing a baseline for support.
4. Container-Focused Testing: Test applications in containers across different environments to ensure consistent behavior regardless of the underlying distribution.
5. Documentation and Guidance: Provide clear documentation on required Kubernetes features and configuration, enabling customers to self-validate their environments.

Conclusion & Comment

The transition from OS-specific support models to Kubernetes API-based support represents a significant evolution in application deployment and management. And a huge shift towards choice for customers and end-users. But while there are compelling reasons to adopt a more platform-agnostic approach based on Kubernetes API versions, many application vendors still rely on distribution-specific support.

As a user, I’d challenge application vendors that say “my app is only supported on X”. So is it a super cool cloud-native, container-based workload? A modern app that promises business benefits, a better operational experience or better resiliency?

Because if the container-based app can’t run on any conformant Kubernetes, it might actually be better suited for a traditional OS deployment model inside a VM. The operational burden of using and maintaining specific distributions or specific versions of distributions is just adding complexity – where Kubernetes and cloud-native apps actually promised a “next-gen” experience.