Cloud Native Computing Foundation (“CNCF”) Charter
The Linux Foundation
Effective Nov 6 2015 / Updated May 15 2018
1. Mission of the Cloud Native Computing Foundation.
The Foundation’s mission is to create and drive the adoption of a new computing paradigm that is optimized for modern distributed systems environments capable of scaling to tens of thousands of self healing multi-tenant nodes.
Cloud native systems will have the following properties:
(a) Container packaged. Running applications and processes in software containers as an isolated unit of application deployment, and as a mechanism to achieve high levels of resource isolation. Improves overall developer experience, fosters code and component reuse and simplify operations for cloud native applications.
(b) Dynamically managed. Actively scheduled and actively managed by a central orchestrating process. Radically improve machine efficiency and resource utilization while reducing the cost associated with maintenance and operations.
(c) Micro-services oriented. Loosely coupled with dependencies explicitly described (e.g. through service endpoints). Significantly increase the overall agility and maintainability of applications. The foundation will shape the evolution of the technology to advance the state of the art for application management, and to make the technology ubiquitous and easily available through reliable interfaces.
2. Role of the CNCF.
The CNCF will serve a role in the open source community responsible for:
(a) Stewardship of the projects
i. Ensuring that the technologies are available to the community and free of partisan influence
ii. Ensure that the technologies’ brand (trademark and logo) is being cared for and used appropriately by members of the community, with a specific emphasis on uniform user experience and high levels of application compatibility
(b) Fostering the growth and evolution of the ecosystem
i. Evaluating which additional technologies should be added to meet the vision of cloud native applications, and working to encourage the community to deliver them, and integrate them if and only if they advance the general agenda
ii. Providing a way to foster common technical standards across the various pieces
(c) Promotion of the underlying technologies, and approach to application definition and management, including: events and conferences, marketing (SEM, direct marketing), training courses and developer certification
(d) Serve the community by making the technology accessible and reliable.
i. The foundation seeks to offer up a fully integrated and qualified build of each of the constituent pieces, on a well-defined cadence across the reference architecture.
The CNCF will strive to adhere to the following principles:
(a) Fast is better than slow. The foundation enables projects to progress at high velocity to support aggressive adoption by users.
(b) Open. The foundation is open and accessible, and operates independently of specific partisan interests. The foundation accepts all contributors based on the merit of their contributions, and the foundation’s technology must be available to all according to open source values. The technical community and its decisions shall be transparent.
(c) Fair. The foundation will avoid undue influence, bad behavior or “pay-to-play” decision-making.
(d) Strong technical identity. The foundation will achieve and maintain a high degree of its own technical identify that is shared across the projects.
(e) Clear boundaries. The foundation shall establish clear goals, and in some cases, what the non-goals of the foundation are to allow projects to effectively co-exist, and to help the ecosystem understand where to focus for new innovation.
(f) Scalable. Ability to support all scales of deployment, from small developer centric environments to the scale of enterprises and service providers. This implies that in some deployments some optional components may not be deployed, but the overall design and architecture should still be applicable.
(g) Platform agnostic. The specifications developed will not be platform specific such that they can be implemented on a variety of architectures and operating systems.
The CNCF shall be composed of Platinum, Gold, Silver, End-User and Academic and Non-Profit member participants. All member applications will be reviewed by the Linux Foundation, who will decide whether that applicant is to be classified as an end-user, academic/non-profit, or
vendor for purposes of CNCF membership.
(a) Platinum members shall be entitled to:
i. Appoint one (1) representative to the CNCF Governing Board.
ii. Appoint one (1) representative as a voting member in any subcommittees or activities of the Governing Board.
iii. Enjoy most prominent placement in displays of membership including on the website.
iv. If the member is also an approved End User, all of the privileges of End User Members in (d).
(b) Gold members shall be entitled to:
i. Appoint one (1) representative to the CNCF Governing Board per every five (5) Gold members, up to three (3) maximum Gold representatives.
ii. If the member is also an approved End User, all of the privileges of End User Members in (d).
(c) Silver members shall be entitled to:
i. Appoint one (1) representative to the CNCF Governing Board per every ten (10) Silver members, up to three (3) maximum Silver representatives.
ii. If the member is also an End User, all of the privileges of End User Members in (d).
(d) End User members shall be entitled to:
i. Participate in the End User Advisory Community as described below;
ii. Nominate one (1) representative to the End User Technical Advisory Board.
(e) Academic and Non-Profit members: The Academic and Non-Profit category of participation is limited to academic and non-profit institutions respectively and requires approval by the Governing Board. Academic and Non-Profit members shall be entitled to identify their organization as members supporting the mission of CNCF and any other rights or benefits as determined by the Governing Board.
5. Governing Board
(a) The CNCF Governing Board will be responsible for marketing and other business oversight and budget decisions for the CNCF. The Governing Board does not make technical decisions for the CNCF, other than working with the TOC to set the overall scope for the CNCF, initially established in Schedule A, and updated from time to time on the CNCF website.
(b) The Governing Board will address business matters including:
i. adopting the overall scope for the CNCF in consultation with the TOC;
ii. defining and enforcing policy regarding the use of the trademarks and copyrights of the foundation;
iii. directing marketing, including evangelism, events and ecosystem engagement;
iv. creating and executing a brand compliance program, if desired;
v. overseeing operations and qualification efforts; and
vi. fundraising and financial governance overall;
(c) Composition – the Governing Board voting members shall consist of Member Representatives and Technical Community Representatives:
i. Member Representatives consist of:
a. one representative appointed from each Platinum member; and
b. the Gold and Silver member elected representatives (if any)
ii. Technical Community Representatives consist of:
a. the TOC Chair, and
b. two Committers elected from the CNCF Projects under a process approved by the then-serving Governing Board.
iii. The Governing Board may extend a Platinum membership at the Silver Membership Scale rates on a year-by-year basis for up to 5 years to startup companies with revenues less than $50 million that are deemed strategic technology contributors by the Governing Board.
iv. Only one person from a group of Related Companies may serve as a Member Representative. Only one person from a group of Related Companies may serve as a Technical Community Representative.
i. approve a budget directing the use of funds raised from all sources of revenue to be used for technical, marketing or community investments that advance the mission of the CNCF;
ii. elect a Chair of the Governing Board to preside over meetings, authorize expenditures approved by the budget and manage any day-to-day operations;
iii. vote on decisions or matters before the Governing Board;
iv. define and enforce policy regarding intellectual property (copyright, patent or trademark) of the foundation;
v. direct marketing and evangelism efforts through events, press and analyst outreach, web, social and other marketing efforts;
vi. oversee operations and qualification efforts;
vii. establish and oversee any committees created to drive the mission of CNCF;
viii. establish and execute a brand compliance program, if any, based on the CNCF requirements, which may include a certification test, to use the brand marks established by the TOC;
ix. adopt guidelines or a policy for use of the trademark; and
x. and provide financial governance overall.
(e) The revenues collected by the project shall be used for the following purposes:
i. The marketing, promotion and expansion of deployment and use of the “Included in CNCF” projects.
ii. The staffing of key resources to build, run and manage project productivity infrastructure.
iii. The promotion of container-based computing principles as outlined and implementation thereof via the CNCF’s projects.
6. Technical Oversight Committee (“TOC”)
(a) Mandate. The TOC is expected to facilitate driving neutral consensus for:
i. defining and maintaining the technical vision for the Cloud Native Computing Foundation,
ii. approving new projects within the scope for CNCF set by the Governing Board, and create a conceptual architecture for the projects,
iii. aligning projects, removing or archiving projects,
iv. accepting feedback from end user committee and map to projects,
v. aligning interfaces to components under management (code reference implementations before standardizing), and
vi. defining common practices to be implemented across CNCF projects, if any.
i. The TOC shall be composed of at most nine (9) members.
ii. TOC members elected are expected to cover key technical domains: container technologies, operating systems, technical operations, distributed systems, user level application design, etc.
iii. The Governing Board shall elect six (6) TOC members, the End User TAB shall elect one (1) TOC member and the initial seven TOC members shall elect an additional two (2) TOC members.
iv. If more than two TOC members would be from the same group of Related Companies, either at the time of election or from a later job change, they will jointly decide who should step down, or if there is no agreement, random lots shall be drawn.
(c) Operating Model
i. The TOC shall select a Chair of the TOC to set agendas and call meetings of the TOC.
ii. The TOC is expected to meet quarterly face-to-face to discuss key topical issues.
iii. The TOC may meet virtually as needed to discuss emerging issues. Issues may be raised for TOC review by:
a. any TOC member,
b. any Governing Board member,
c. a maintainer or top level project leader in a CNCF project established under Section 8(h),
d. the CNCF Executive Director, or
e. a majority vote of the End User Technical Advisory Board.
iv. Transparency. TOC meetings, mailing list, minutes, etc should be open.
v. Simple TOC issues may be resolved by short discussion and simple majority vote. TOC discussions may be over email or at a meeting of the TOC.
vi. After a review of the opinions and optional virtual discussion/debate options are identified, seeking consensus and taken to vote if necessary.
vii. The intent is for the TOC to find a path to consensus within the TOC and community. TOC decisions at meetings meeting quorum requirements shall pass with a vote greater than 50% of TOC members present.
viii. TOC meetings shall require a quorum of two-thirds of the TOC total members to take a vote or make any decision. If a TOC meeting fails to meet the quorum requirement, discussions may proceed, however there shall be no voting or decisions.
ix. TOC decisions may be made electronically without a meeting, but to pass a vote shall require as many votes as would be needed to achieve quorum in a meeting. During an electronic vote, if any two (2) TOC members request a meeting to discuss the decision, the electronic vote in process shall end without effect, and a new vote may be initiated after the meeting to discuss the decision has completed.
(d) Criteria for Nomination. Nominees for the TOC shall:
i. commit that they have the available bandwidth to make the time to invest in the CNCF TOC, including a considerable early investment as the CNCF is formed and then ongoing investment of time to prepare and review in advance of quarterly TOC meetings,
ii. demonstrate advanced level of professional experience as engineers in the scope of CNCF,
iii. demonstrate seniority sufficient to access additional staff or community members to assist in their TOC preparations, and
iv. operate neutrally in discussions and put the goals and success of CNCF
in balance with corporate objectives or any particular project in CNCF.
(e) Process for TOC Member Nominations and Election
i. The TOC shall be composed of nine (9) TOC members: six (6) elected by the Governing Board, one (1) selected by the End User TAB and two (2) elected by the initial seven TOC members.
ii. Nominations: Each individual (entity or member) eligible to nominate a TOC member may nominate up to two (2) technical representatives, (from vendors, end users or any other fields), at most one of which may be from their respective company. The nominee(s) must agree to participate prior to being added to the nomination list.
a. The initial seven (7) TOC members (the six elected by the Governing Board plus one (1) elected by the End User TAB) shall then nominate and elect two (2) additional TOC members using the Nomination Process.
b. A nomination requires a maximum one (1) page nomination pitch which should include the nominees name, contact information and supporting statement identifying the nominees experience in CNCF domains.
c. The Governing Board, End User TAB and TOC shall determine the timeline and dates for nominations, voting, and any other details regarding the nomination and election process for their TOC elections.
d. A minimum of 14 calendar days shall be reserved for an Evaluation Period whereby TOC nominees may be contacted and/or evaluate the electors.
iii. Elections: After the Evaluation Period, the Governing Board, End User TAB and later, initial seven TOC members, shall vote on each nominee individually. A valid vote shall require as many votes as would be required to meet quorum for a meeting. Each nominee shall require support of over 50% majority of those voting to validate the nominee meets the qualification criteria. Nominees passing with a majority vote shall be Qualified Nominees.
iv. If the number of Qualified Nominees are equal to or less than the number of TOC seats available to be elected, the Qualified Nominees shall be approved after the nomination period has closed. If there are more Qualified Nominees than open TOC seats available for election by either the the Governing Board, End User TAB or TOC, then that group shall elect the TOC members via a Condorcet vote. A Condorcet vote shall be run using the Condorcet-IRV method through the Cornell online service (http://civs.cs.cornell.edu/).
v. If there are fewer Qualified Nominees than open TOC seats available for election by either the Governing Board, End User TAB or TOC, the group shall initiate another round of nominations with each member or individual eligible to nominate submitting at most one (1) nominee.
i. TOC Members shall serve two-year, staggered terms. The initial six elected TOC members from the Governing Board election shall serve an initial term of three (3) years. The TOC members initially elected by the End User TAB and TOC shall serve an initial term of two (2) years.
ii. TOC members may be removed by a two-thirds vote of the other TOC members, with the impacted individual ineligible to participate in the vote.
iii. Any TOC member that misses three (3) consecutive meetings shall be automatically suspended from eligibility to vote until having attended two meetings consecutively. For avoidance of doubt, the suspended TOC member shall be eligible to vote in the second consecutive meeting.
iv. The TOC charter, model, approach, composition, etc may be modified by a two-thirds vote of the entire Governing Board.
v. The TOC agenda will be set by the TOC. However, it is expected that initial TOC discussions and decisions will cover:
a. assessing technologies to include in CNCF
b. defining acceptance criteria for new technologies to include in CNCF
c. defining process to ratify a contributed technology as a standard API
d. identifying immediate gaps that require further investigation
7. End User Community
(a) End User Members in CNCF shall be entitled to coordinate and drive activities important to users of CNCF as consumers for which CNCF was designed. Any member or non-member who is an End User, each an “End User Participant”, shall be invited to participate. The End User Participants are expected to help provide input to the Technical Advisory Board and CNCF community on topics relevant to users.
(b) The End User Community Members shall elect an End User Technical Advisory Board.
(c) End User Community Members will be approved by the CNCF Executive Director, or if none exists, The Linux Foundation Executive Director.
8. End User Technical Advisory Board (“End User TAB”).
(a) Composition: The End User TAB shall be composed of seven (7) representatives from End User Participants plus one member of the TOC to facilitate input from the End User TAB to the TOC.
(b) Selection: To encourage participation of End Users in CNCF, the first seven (7) End User Members may appoint one (1) representative to the initial End User TAB with any remaining seats allocated by the CNCF Director to any End User Participant. After the initial year, all End User Participants may nominate one (1) representative
and the End User Community shall vote to select the End User TAB members using a process approved by the then current End User TAB.
(c) The End User TAB may alter the size of the End User by two-thirds vote, provided there are a minimum of seven (7) possible representatives.
(d) End User representatives should be nominated on operational and technical acumen. Nominees should have significant practical experience with building and operating infrastructure and applications which embody the principles of the CNCF.
(e) The End User TAB will discuss and progress topics with a focus on identifying gaps and proposing priorities for the TOC and the CNCF developer community.
(f) The End User TAB may also focus on proactively advancing topics of concern to End Users, promoting market adoption of CNCF, hosting meetings for End Users, or advising the Governing Board.
(g) If the End User TAB desires, it may approve subcommittee Special Interest Groups
(“SIGs”) to address industry or specialized topics.
(h) The End User TAB input to the TOC shall be taken together with other input and feedback for the TOC to make decisions and plans. The recommendations are advisory only and at no point shall the recommendations of the End User TAB be used to order or direct any TOC or project participant toward any action or outcome.
(i) To facilitate bilateral interaction with the TOC, the End User Technical Advisory Board shall elect one (1) representative to the TOC. The End User TAB may invite anyone to participate in End User meetings, SIGs or other discussions.
9. CNCF Projects
(a) It is expected that member companies, and open source community members will bring project assets to the TOC for discussion and inclusion into the CNCF. All such contributions should meet a set criteria created by the TOC and ratified by the Governing Board. The goal is to have an increasing bazaar of projects related to and that integrate with projects already accepted into the CNCF.
(b) Projects can be associated with the CNCF in the following 3 ways:
i. Included in CNCF, under a neutral home for collaboration
a. All aspects of the project are governed by the CNCF
b. The project is marketed by the CNCF as a CNCF project
c. The project should be a core functional component of the CNCF solution. (e.g. such as Kubernetes, Mesos, etcd, etc.)
ii. Associated with the CNCF via an API or specification
a. Includes components where the CNCF may offer or enable multiple options
b. The project is referred to as a component that the CNCF integrates with, not as a project hosted by the CNCF
c. Integration and compliance are defined by an API or specification
d. Active development on the project or component is ideally done in the upstream community
iii. Used by the CNCF
a. A project or component that is completely licensed under an OSIapproved open source license and is well managed and used as a component in the CNCF
b. Project is not actively marketed by the CNCF,
c. Active development on the project or component is ideally done in the upstream community
(c) Existing open source projects should continue to run through their existing technical governance structure to maintain cohesion and velocity. Projects approved by the TOC for inclusion in the CNCF will be ‘lightly’ subject to the Technical Oversight
(d) A standard protocol to achieve committer status shall be established across projects based on an individual’s level and duration of contribution. Maintainer status is achieved through contribution to a given project over time and validation by peer
(e) New open source projects initiated in CNCF shall complete a project proposal template adopted by the TOC and be approved by the TOC for inclusion in CNCF. The TOC members shall be afforded sufficient time to discuss and review new project proposals. New project proposals shall include details of the roles in the project, the governance proposed for the project and identify alignment with CNCF’s role and values.
10. Marketing Committee
(a) Composition: the Marketing Committee will be open to all members to participate. A Chair of the Marketing Committee shall be elected to develop meeting agendas, moderate discussions and help the committee progress against its goals. The Marketing Committee shall seek consensus where possible. Any issues that cannot reach a Rough Consensus in the Marketing Committee shall be referred to the Governing Board.
(b) Responsibilities: The Marketing Committee shall be responsible for designing, developing and executing marketing efforts on behalf of the Governing Board.
(c) If the Marketing Committee becomes too large to operate effectively, the Marketing Committee may choose to elect Marketing Board and delegate decision authority to the Marketing Board.
11. IP Policy
(a) Any project that is added to the CNCF must have ownership of its trademark and logo assets transferred to the Linux Foundation.
(b) Each project shall determine whether it will require use of an approved CNCF CLA. For projects that select to use a CLA, all code contributors will undertake the obligations set forth in the Apache contributor license agreement(s), altered only as necessary to identify CNCF as the recipient of the contributions, and which shall be approved by the Governance Board. See CNCF Contributor License Agreements available at https://github.com/cncf/cla. The process for managing contributions in accordance with this policy shall be subject to
Governance Board approval.
(c) All new inbound code contributions to the CNCF shall be (i) accompanied by a Developer Certificate of Origin sign-off (http://developercertificate.org) and (ii) made under the Apache License, Version 2.0 (available at http://www.apache.org/licenses/LICENSE-2.0), such license to be in addition to, and shall not supersede, obligations undertaken under the contribution license agreement(s) provided for in (b) above.
(d) All outbound code will be made available under the Apache License, Version 2.0.
(e) All projects evaluated for inclusion in the CNCF shall be completely licensed under an OSI-approved open source license. If the license for a project included in CNCF is not Apache License, Version 2.0, approval of the Governing Board shall be required.
(f) All documentation will be received and made available by the CNCF under the Creative Commons Attribution 4.0 International License.
(g) If an alternative inbound or outbound license is required for compliance with the license for a leveraged open source project or is otherwise required to achieve the CNCF’s mission, the Governing Board may approve the use of an alternative license
for inbound or outbound contributions on an exception basis.
12. Antitrust Guidelines
(a) All members shall abide by the requirements for The Linux Foundation set forth in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy.
(b) All members shall encourage open participation from any organization able to meet the membership requirements, regardless of competitive interests. Put another way, the Governing Board shall not seek to exclude members based on any criteria, requirements or reasons other than those used for all members.
13. Code of Conduct
(a) All participants agree to abide by The Linux Foundation Code of Conduct available at http://events.linuxfoundation.org/code-of-conduct. The TSC may vote to adopt its own code of conduct for the CNCF community.
14. Related Companies
i. “Subsidiaries” shall mean any entity in which a Member owns, directly or indirectly, more than fifty percent of the voting securities or membership interests of the entity in question;
ii. “Related Company” shall mean any entity which controls or is controlled by a Member or which, together with a Member, is under the common control of a third party, in each case where such control results from ownership, either directly or indirectly, of more than fifty percent of the voting securities or membership interests of the entity in question; and
iii. “Related Companies” are entities that are each a Related Company of a Member.
(b) Only the legal entity which has executed a Participation Agreement and its Subsidiaries shall be entitled to enjoy the rights and privileges of such Membership; provided, however, that such Member and its Subsidiaries shall be treated together as a single Member.
(c) Only one Member which is part of a group of Related Companies shall be entitled to appoint, or nominate for a membership class election, a representative on the Governing Board at one time.
(d) If a Member is itself a foundation, consortium, open source project, membership organization, user group or other entity that has members or sponsors, then the rights and privileges granted to such Member shall extend only to the employee-representatives of such Member, and not to its members or sponsors, unless otherwise approved by the Governing Board in a specific case from time to time.
(e) Memberships shall be non-transferable, non-salable and non-assignable, except that any Member may transfer its current Membership benefits and obligations to a successor to substantially all of its business and/or assets, whether by merger, sale or otherwise; provided that the transferee agrees to be bound by this Charter and the Bylaws and policies required by Linux Foundation membership.
(a) The Governing Board shall approve an annual budget and never commit to spend in excess of funds raised. The budget shall be consistent with the nonprofit mission of The Linux Foundation.
(b) The Linux Foundation shall provide regular reports of spend levels against the budget.
16. General & Administrative Expenses
(a) The Linux Foundation shall have custody of any fees, funds and other cash receipts.
(b) A General & Administrative (G&A) fee will be applied to funds raised to cover Finance, Accounting and operations. The G&A fee shall equal 9% of CNCF’s first $1,000,000 of gross receipts and 6% of CNCF’s gross receipts over $1,000,000.
17. General Rules and Operations.
The participants in CNCF shall:
a. demonstrate plans and the means to coordinate with the open source project’s developer community, including on topics such as branding, logos, and other collateral that will represent the community;
b. engage in a professional manner consistent with maintaining a cohesive community, while also maintaining the goodwill and esteem of The Linux Foundation in the open source software community;
c. respect the rights of all trademark owners, including any branding and usage guidelines;
d. engage The Linux Foundation for all press and analyst relations activities;
e. upon request, provide information regarding project participation, including information regarding attendance at project-sponsored events, to The Linux Foundation;
f. engage The Linux Foundation for any websites directly for the foundation; and
g. operate under such rules and procedures as may from time to time be approved by the Governing Board, provided that such rules and procedures shall not be inconsistent with the purpose and policies of the Linux Foundation and shall not be detrimental to the Linux Foundation.
This charter may be amended by a two-thirds vote (excluding abstentions) of all Governing Board members, provided that any such amendments shall not be inconsistent with the purpose or policies of the Linux Foundation and shall not be detrimental to the Linux Foundation.
Schedule A: Initial CNCF Scope Vision
The overarching intent behind the cloud native computing foundation is to support and accelerate the adoption of ‘cloud native computing’. What follows below is an initial scope intended to articulate core concepts of ‘cloud native computing’ that the CNCF will strive to implement. This initial scope shall become a living document posted to the CNCF website.
CNCF’s community believe there are three core attributes to cloud native computing:
- Container packaged and distributed.
- Dynamically scheduled.
- Micro-services oriented.
A cloud native computing system enables computing that builds on these core attributes, and embraces the ideals of:
- Openness and extensibility.
- Well-defined APIs at borders of standardized subsystems.
- Minimal barriers to application lifecycle management.
When successful, the cloud native computing foundation will establish:
- Standardized interfaces between subsystems.
- A standard systems architecture describing the relationship between parts
- At least one standard reference implementation of each sub-system.
- Thinking about adding extensible architecture that end users can extend, replace or change behavior in every layer of the stack for their purposes.
The suggested set of areas/sub-systems:
- Application definition and orchestration
- standard service definition
- define a standard distributed system service that can be deployed
- composite application definition
- a standard model for packaging and shipping an app of many parts
- a standard framework to deploy and manage an app of many parts
- providing workload/job specific orchestration and control
- standard service definition
- Resource scheduling
- map containers to nodes (in either a cluster, or single node environment)
- manage the life-cycle, scaling and health of containers and container groups
- handle active scaling of containers
- interface with infrastructure provisioning to request more resources as needed (either bare metal, private cloud, or public cloud)
- interface with SDN and SDS to map to storage/network
- Distributed systems services
- a standard set of services that are not bound to a single node
- supporting application use cases
- state management/sharding
- a minimum atom of consumption for software (i.e. the model to find and consume something)
- within the cluster
- between clusters
- from outside the cluster
- A local agent that integrates CNCF into a local computing environment
- maintains the lifecycle of containers on a node
- monitors the health of container on a node
- Compute node definition
- a standard definition for what the minimum set of services on a compute node are (the actual node distribution is out of scope)
- Infrastructure provisioning and integration
- provide a standard interface and plugin model to request additional infrastructure
- software defined datacenter integration
- provide a standard interface and plugin model for network (SDN) and storage (SDS) integration with clusters
- services (common capabilities made optionally available to all CNCF sub-systems)
- Distributed state and scheduling management. Provide mechanisms to robustly handle cluster state.
- Distributed control plane technology. Support robust command and control of systems across failure domain boundaries.
- API server. Create a common mechanism to support REST based access to core services.
- Tools and Visualization
- A single ‘pane of glass’ to view and control distributed systems
- Monitoring and operations capabilities
- a standard set of services that are not bound to a single node
External systems. These systems are not considered part of the project, but should interface cleanly with the CNCF subsystems, and CNCF should work with the the appropriate communities to support standardization.
- Compute Node OS. The node (host OS for container applications) is considered out of scope of this effort. We should however work closely with OS providers to ensure that the minimal node specification (i.e. what local services a cloud native application requires) are well defined and standardized across the emerging lightweight container nodes.
- Container runtime and specification. This is critical, but should be driven through the OCI. This community must interface with the OCI group to ensure that requirements for cloud native operation are met, including where applicable, signing, verification and distribution.
- Identity management systems. CNCF should integrate with identity management systems, but subject to TOC guidance, not define a new model.
For further discussion
The following are considered out of scope for now, but might need to be included later.
- Application environment. Crafting a well formed, minimal userland environment for cloud native applications.
- OCI topics (container format and runtime). The goal is to integrate with the OCI group.
Any given sub-system should exist behind an open REST based API. Vendors should be able to provide alternate implementations of any given subsystem to optimize if for a given workload, or to add value through commercial technology. The models, and APIs, defined by the CNCF should be extensible such that vendors can add additional capabilities. However, interoperability across implementations is critical and therefore extensions should be optional.
CNCF imagines a qualification model through API standardization, and rich integration testing. The community will produce a trademarkeable brand and reserve use of the mark for systems that meet integration requirements.
Three qualification levels will likely exist:
- Trademark Implementation. All relevant technologies are built from code housed in CNCF repositories.
- Trademark Compatible. Passing all integration test to and demonstrating deep semantic compatibility with ‘Trademark Implementation systems.
- Trademark version X API compliant. Compliant with the version X API.