SIGnals from KubeCon

The basic organizational construct within the Kubernetes project is a set of Special Interest Groups (SIGs), each of which represents a different area of responsibility within the project. Introductions to what the various SIGs do, as well as more detailed sessions, were a core part of KubeCon + CloudNativeCon Europe 2019, as the different groups explained what they're doing now and their plans for the future. Two sessions, in particular, covered the work of the Release and Architecture SIGs, both of which have a key role in driving the project forward.

SIG Release

Among the core Kubernetes SIGs is SIG Release, which is responsible for the release-engineering aspects of the project. Tim Pepper, open-source engineer at VMware's Open Source Technology Center and Stephen Augustus, senior cloud-native architect at VMware, ran a session that outlined some of the current issues and challenges for release engineering in Kubernetes. Pepper and Augustus currently serve as co-chairs for SIG Release, alongside Caleb Miles from Google.

Among the SIG's primary goals is to generate releases on a reliable schedule, which involves partnership with the other Kubernetes SIGs to make sure the work is all integrated properly. From a release-engineering perspective, SIG Release is also tasked with providing guidance and tooling to facilitate the generation of automated releases. Pepper admitted that full automation is still a distant goal, though the direction is to automate more human tasks and processes within the release workflow. "In many ways we don't do a lot of the work that people maybe presume that we do, they think that the release team for example does a lot of work, but it's much more partnering with the SIGs and empowering them to identify what they can get done on the timeline that's associated with the release and integrate their work," Pepper said.

One of the key areas of intersection is with SIG PM (Project Management), which handles some of the tracking for large features, referred to as "enhancements", within the Kubernetes development cycle. Enhancement issues are not simple bug fixes, rather they involve changes that typically take multiple release cycles to complete and mature. Augustus explained that, within the SIG Release team, there are different roles for members, one of them is about tracking and working with SIG PM on enhancements. Enhancement leads are responsible for collating lists of open features within Kubernetes and deciding which ones will land in a given release.

SIG Release handles continuous-integration (CI) signals on the Kubernetes master branch, making sure that the test infrastructure is stable and working. These signals include various test results that could indicate a potential stability issue within a release. The group is also responsible for managing operations around branching and moving content in preparation for a release. When it comes to the actual release, SIG Release helps to put together the release notes and associated documentation.

The move to have all release engineering done transparently via SIG Release (and the open-source Kubernetes project in general) is part of the continuing evolution of Kubernetes away from being just a Google project. Kubernetes is celebrating its fifth birthday in 2019, and the project became the founding effort of the Linux Foundation's Cloud Native Computing Foundation (CNCF) in 2015. Though Kubernetes has been an open project for five years, it was only in August 2018 that Google announced that it was moving Kubernetes development infrastructure over to the CNCF. "One of the cool things that we've done over the last year, is turn this (release engineering process) from sort of anecdote and lore especially held within the minds of a a set of Googlers, into something that's really being run by the community," Pepper said.

Licensing and long-term support

One of the newer subprojects within SIG Release has to do with licensing. Pepper said that licensing shouldn't really be a challenge, since Kubernetes itself is licensed under the Apache 2.0 license. Apparently, however, there are some non-Apache licenses in the Kubernetes code as well. Pepper said that there isn't a clear uniformity of Apache-2.0 licensed files in the code base. "This is open source, we have to do things right and we need to make sure that we're in compliance with whatever all these other licenses are," Pepper said.

Given the scale of the Kubernetes project, there is a clear need for automated tooling to help identify the various licenses and make sure there are no license conflicts. The Linux Foundation is helping out with its FOSSology tool, which outputs a list of all licenses used in a code base into a spreadsheet. Augustus said that the Kubernetes project will be making use of a tool called FOSSA to help identify licenses in an automated manner when code is submitted to Kubernetes.

Another issue addressed in this session was long-term support for Kubernetes, which is released on a quarterly cadence; each release receives nine months of support from the open-source project for bug and security fixes. Pepper said that there has been a question in the community about whether there is a need for a longer support term for releases, as some users require more time for upgrades.

The question of how Kubernetes might handle a long term support release is being talked about in a working group within the project dubbed WG-LTS. "In Kubernetes, working groups don't own code, they're trying to figure out and propose a solution to a problem," Pepper said. "So this working group is trying to drive conversations around what are the actual end-user needs and then, with those cataloged, what are our options to match them."

SIG Architecture

While SIG Release deals with release engineering, SIG Architecture is about understanding, defining, and evolving the architecture of Kubernetes. Timothy St. Clair, senior staff engineer at VMware and Kubernetes Steering Committee member, ran a session where he outlined the current state of Kubernetes architecture. The scope of SIG Architecture is to maintain and evolve the design principles of Kubernetes as well as providing a consistent body of expertise that is necessary to ensure architectural consistency over time.

SIG Architecture handles tasks like the API review process as well as conformance-test review and management. "API reviews affect everybody, so if you have a bad API, that's a contract that you're going to have to support for several iterations if you make a mistake, so the API review process affects everybody," St. Clair said.

SIG Architecture also provides input into the ongoing evolution of Kubernetes features via the Kubernetes Enhancement Proposals (KEPs) process. A KEP is a document that defines the goals and capabilities of a new or updated feature within Kubernetes. St. Clair explained that SIG Architecture provides a stopgap review for KEPs that cut across different boundary lines in an effort to help retain the integrity and stability of Kubernetes' architecture overall. "The promise of Kubernetes, the whole purpose at a fundamental level is to be the abstraction layer that you can write across different providers and different clouds," St. Clair said. "If that abstraction layer doesn't hold true and we develop balkanization, the promise of Kubernetes is lost."

Overall, the direction that St. Clair hopes that Kubernetes will take from a core architecture perspective is to be less iterative on foundational elements. He'd instead like to see API extension mechanisms and extension policies that retain core stability while enabling extensibility by developers. Currently, stability is a work in progress across different aspects of the Kubernetes project and in particular for dot-zero releases (i.e. 1.14.0). St. Clair asked the audience how many people use a dot-zero Kubernetes release in production and a single hand went up. "If you use a dot-zero in production, you are far braver than 90% of the people I know," St. Clair said.

According to St. Clair, a Kubernetes dot-zero release is a good development release, but isn't really suited for production usage. He said that after each dot-zero release there can be hundreds of pull requests that come in. "All of a sudden it gets in the wild, then we find all the things that we're missing," St. Clair said.

Across both the SIG Release and SIG Architecture sessions, a unifying theme was that of community engagement and a call for more participation as the way forward to build a better, more inclusive Kubernetes project for everyone.

YouTube video of the SIG Release and SIG Architecture sessions are available.