Welcome to our spotlight series on SIG Architecture, where we dive into the inner workings of Kubernetes governance. In this edition, we explore the API Governance subproject, a critical element ensuring that Kubernetes evolves reliably without breaking its ecosystem. We sat down with Jordan Liggitt, the subproject lead, to understand its goals, scope, and how it balances stability with innovation.

Who is Jordan Liggitt and what is his role in API Governance?

Jordan Liggitt is a software engineer at Google who has been deeply involved with Kubernetes since 2014. He describes himself as a Christian, husband, father of four, and an amateur musician. Originally from Texas, he now lives in North Carolina. His journey with Kubernetes began with a bold first pull request—an attempt to add an OAuth server directly into the Kubernetes API server. That PR never got merged (it remained work-in-progress for six months), but it taught him an important lesson about layering APIs. He pivoted to building authentication and authorization capabilities, and his contributions earned him a spot as an API reviewer in 2016, then as an API approver in 2017. Today, he co-leads both the API Governance and code organization subprojects under SIG Architecture, and also serves as a tech lead for SIG Auth.

When did Jordan start leading the API Governance subproject?

Jordan officially joined the API Governance subproject around 2019. By that time, he had already accumulated years of experience shaping core Kubernetes APIs from early beta versions like v1beta3 through to v1. His hands-on work as an API reviewer and approver naturally led him to take on a leadership role in governance, where he now helps steer the evolution of all Kubernetes APIs while keeping them stable and consistent.

What exactly is the API Governance subproject and what are its goals?

API Governance is a subproject within SIG Architecture that oversees the design, consistency, and evolution of all Kubernetes APIs. Its primary goal is to keep Kubernetes stable while still enabling innovation. As Jordan explains, stability alone is easy if nothing ever changes, but that contradicts the need for growth. The subproject works to strike a balance—allowing necessary changes without breaking existing users. This involves setting standards, reviewing new API proposals, and ensuring that every change respects backward compatibility and follows established conventions.

Which API surfaces does API Governance cover? Is it just the REST API?

Many people assume "the API" refers only to the Kubernetes REST API that kubectl and controllers interact with. But Jordan points out that many other surfaces are also APIs: command-line flags, configuration files, binary runtime behavior, communication with back-end components like the container runtime, and data persistence formats. Each of these has a narrower audience but still requires careful governance. The REST API is the largest and most visible, but API Governance ensures that every interface—whether for end-users or system components—follows the same principles of clarity, stability, and consistency.

How does API Governance balance stability with the need for change?

Stability is crucial for production systems, but Kubernetes must continue to evolve to meet new requirements. API Governance approaches this by defining clear policies for deprecation, versioning, and graduation of APIs. Features pass through stages (alpha, beta, stable) with increasing guarantees. The subproject reviews changes to ensure they don't break existing clients, and provides mechanisms like feature gates and API versioning to allow gradual adoption. Jordan emphasizes that the goal is not to freeze the API but to manage change predictably—so that users can plan upgrades and rely on documented contracts.

When does API Governance get involved in the Kubernetes release cycle?

API Governance interacts with the release cycle at multiple points. It helps define guidelines that contributors follow before writing code, reviews Kubernetes Enhancement Proposals (KEPs) during the design phase, and participates in API reviews for actual changes. Throughout the release cycle, subproject members monitor new additions to ensure they align with governance standards. They also work with SIGs to resolve any inconsistencies. This continuous involvement—from early design through final integration—helps catch issues before they become breaking changes.

Can you give an example of how API Governance improves Kubernetes quality?

One concrete example is the handling of field naming and validation. API Governance establishes conventions for how fields are named (e.g., using camelCase), how required vs optional fields are indicated, and how validation rules are implemented. When a new API type is proposed, reviewers from the subproject check that it follows these conventions, preventing a patchwork of inconsistent styles. Another example is ensuring that deprecation of an API follows a clear timeline: marking it as deprecated in one release, keeping it functional for several more, and finally removing it only after clear notice. This disciplined approach has kept Kubernetes a reliable platform for thousands of users, even as it has grown enormously.