Special Interest Groups (SIGs)

Covers all aspects of API server, API registration and discovery, generic API CRUD semantics, admission control, encoding/decoding, conversion, defaulting, persistence layer (etcd), OpenAPI, CustomResourceDefinition, garbage collection, and client libraries.

Covers deploying and operating applications in Kubernetes. We focus on the developer and devops experience of running applications in Kubernetes. We discuss how to define and run apps in Kubernetes, demo relevant tools and projects, and discuss areas of friction that can lead to suggesting improvements or feature requests.

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.

Covers development and maintenance of components for automated scaling in Kubernetes. This includes automated vertical and horizontal pod autoscaling, initial resource estimation, cluster-proportional system component autoscaling, and autoscaling of Kubernetes clusters themselves.

Covers kubectl and related tools. We focus on the development and standardization of the CLI framework and its dependencies, the establishment of conventions for writing CLI commands, POSIX compliance, and improving the command line tools from a developer and devops user experience and usability perspective.

Ensures that the Kubernetes ecosystem is evolving in a way that is neutral to all (public and private) cloud providers. It will be responsible for establishing standards and requirements that must be met by all providers to ensure optimal integration with Kubernetes.

The Cluster Lifecycle SIG examines how we should change Kubernetes to make it easier to manage and operate with a focus on cluster deployment and upgrades. Add our calendar to track when we have community meetings.

Developing and sustaining a healthy community of contributors is critical to scaling the project and growing the ecosystem. We need to ensure our contributors are happy and productive, and that there are not bottlenecks hindering the project in, for example: feature velocity, community scaling, pull request latency, and absolute numbers of open pull requests and open issues.

Covers documentation, doc processes, and doc publishing for Kubernetes.

etcd is a production-ready store for building cloud-native distributed systems and managing cloud-native infrastructure via orchestrators like Kubernetes. Etcd should provide distributed system primitives** (such as distributed locking and leader election) that allow users to **create scalable, highly available and fault-tolerant systems. Etcd is the place to store the infrastructure configuration, not only as part of Kubernetes, but also as a standalone solution.

Covers best practices for cluster observability through metrics, logging, events, and traces across all Kubernetes components and development of relevant components such as klog and kube-state-metrics. Coordinates metric requirements of different SIGs for other components through finding common APIs.

SIG K8s Infra is interested in the successful migration of ownership and management of all Kubernetes project infrastructure from the google.com GCP Organization (or elsewhere) to the CNCF, such that the Kubernetes project is able to sustainably operate itself without direct assistance from external vendors or entities. In other words, we seek to eradicate usage of the phrase “oh that’s something that only an employee of Vendor X can do, we’re blocked until they respond.”

A Special Interest Group focused on solving common challenges related to the management of multiple Kubernetes clusters, and applications that exist therein. The SIG will be responsible for designing, discussing, implementing and maintaining API’s, tools and documentation related to multi-cluster administration and application management. This includes not only active automated approaches such as Cluster Federation, but also those that employ batch workflow-style continuous deployment systems like Spinnaker and others. Standalone building blocks for these and other similar systems (for example a cluster registry), and proposed changes to kubernetes core where appropriate will also be in scope.

Covers networking in Kubernetes.

SIG Node is responsible for the components that support the controlled interactions between pods and host resources.

Ensure quality Kubernetes releases

SIG Scalability is responsible for defining and driving scalability goals for Kubernetes. We also coordinate and contribute to general system-wide scalability and performance improvements (not falling into the charter of other individual SIGs) by driving large architectural changes and finding bottlenecks, as well as provide guidance and consultations about any scalability and performance related aspects of Kubernetes.
We are actively working on finding and removing various scalability bottlenecks which should lead us towards pushing system’s scalability higher. This may include going beyond 5k nodes in the future - although that’s not our priority as of now, this is very deeply in our area of interest and we are happy to guide and collaborate on any efforts towards that goal as long as they are not sacrificing on overall Kubernetes architecture (by making it non-maintainable, non-understandable, etc.).

SIG Scheduling is responsible for the components that make Pod placement decisions.

SIG Security takes a community-building approach to improving security for end users, project maintainers, and the Kubernetes project itself. We work collaboratively across SIGs to advance security-related features, write and update documentation, and maintain security processes and tools for the benefit of all.

SIG Storage is responsible for ensuring that different types of file and block storage (whether ephemeral or persistent, local or remote) are available wherever a container is scheduled (including provisioning/creating, attaching, mounting, unmounting, detaching, and deleting of volumes), storage capacity management (container ephemeral storage usage, volume resizing, etc.), influencing scheduling of containers based on storage (data gravity, availability, etc.), and generic operations on storage (snapshoting, etc.).

Interested in how we can most effectively test Kubernetes. We’re interested specifically in making it easier for the community to run tests and contribute test results, to ensure Kubernetes is stable across a variety of cluster configurations and cloud providers.

Covers all things UI related. Efforts are centered around Kubernetes Dashboard: a general purpose, web-based UI for Kubernetes clusters. It allows users to manage applications running in the cluster and troubleshoot them, as well as manage the cluster itself.

Focuses on supporting Windows Node and scheduling Windows containers on Kubernetes.