The Architecture SIG maintains and evolves the design principles of Kubernetes, and provides a consistent body of expertise necessary to ensure architectural consistency over time.
The charter defines the scope and governance of the Architecture Special Interest Group.
- Enhancements Subproject Meeting: Thursdays at 10:00 PT (Pacific Time) (biweekly). Convert to your timezone.
- Production Readiness Office Hours: Wednesdays at 12:00 PT (Pacific Time) (biweekly). Convert to your timezone.
- Regular SIG Meeting: Thursdays at 11:00 PT (Pacific Time) (biweekly). Convert to your timezone.
- code organization Office Hours: Thursdays at 14:00 PT (Pacific Time) (biweekly). Convert to your timezone.
- conformance office Hours: Tuesdays at 19:00 UTC (biweekly). Convert to your timezone.
The Chairs of the SIG run operations and processes governing the SIG.
- Derek Carr (@derekwaynecarr), Red Hat
- Davanum Srinivas (@dims), VMware
- John Belamaric (@johnbelamaric), Google
- Slack: #sig-architecture
- Mailing list
- Open Community Issues/PRs
- GitHub Teams:
- @kubernetes/sig-architecture-api-reviews - API Changes and Reviews
- @kubernetes/sig-architecture-bugs - Bug Triage and Troubleshooting
- @kubernetes/sig-architecture-feature-requests - Feature Requests
- @kubernetes/sig-architecture-misc-use-only-as-a-last-resort - General Discussion
- @kubernetes/sig-architecture-pr-reviews - PR Reviews
- @kubernetes/sig-architecture-proposals - Design Proposals
- @kubernetes/sig-architecture-test-failures - Test Failures and Triage
- Steering Committee Liaison: Jordan Liggitt (@liggitt)
The following subprojects are owned by sig-architecture:
- Owners:
- Owners:
- Contact:
- Slack: #k8s-code-organization
- Owners:
- Contact:
- Slack: #k8s-conformance
- GitHub Teams:
- Owners:
- Contact:
- Slack: #enhancements
- Owners:
- Contact:
- Slack: #prod-readiness
Establishing and documenting design principles, documenting and evolving the system architecture, reviewing, curating, and documenting new extension patterns
Establishing and documenting conventions for system and user-facing APIs, define and operate the APl review process, final API implementation consistency validation, co-own top-level API directories with API machinery; maintaining, evolving, and enforcing the deprecation policy
- Kubernetes Design and Architecture
- Design principles
- API conventions
- API Review process
- Deprecation policy
Please see the API Reviews tracking board to follow the work of this sub-project. Please reach out to folks in the OWNERS file if you are interested in joining this effort.
Kubernetes Enhancement proposals (KEPs) are used to propose and communicate changes to sub-projects of SIG-Architecture. Following the KEP process is mandatory for all enhancements since Kubernetes 1.14 release.
- Answers to our FAQs can be found here FAQs
- Full details of the KEP process can be found in KEP-1
- Please follow the KEP template available at KEP Template for the enhancement proposal.
- Progress of KEPs can be tracked on our github project board at Kubernetes Enhancements
- Please review OWNERS to connect with enhancement chairs, approvers, and reviewers
Reviewing, approving, and driving changes to the conformance test suite; reviewing, guiding, and creating new conformance profiles
Please see the Conformance Test Review tracking board to follow the work for this sub-project. Please reach out to folks in the OWNERS file if you are interested in joining this effort. There is a lot of overlap with the Kubernetes Software Conformance Working Group with this sub project as well. The github group cncf-conformance-wg enumerates the folks on this working group. Look for the area/conformance label in the kubernetes repositories to mark issues and PRs
Overall code organization, including github repositories and branching methodology, top-level and pkg OWNERS of kubernetes/kubernetes, vendoring
Please see the Code Organization tracking board to follow the work of this sub-project. Please reach out to folks in the OWNERS file if you are interested in joining this effort. Look for the area/code-organization label in the kubernetes repositories to mark issues and PRs. We also use area/dependency label as well issues and PRs.
Defining and documenting the processes for ensuring production readiness of new and promoted features, as well as producing tooling to enforce those processes.