CNCF Graduation Application Tracking

[RainbowMango]

Background & Purpose

The Karmada community is preparing to submit a ​CNCF Graduation Application. This issue serves to:

• ​Publicly review the graduation checklist and application materials.
• ​Track all action items and progress.
• Ensure transparent community participation in the review process.

Graduation Application Form

The application form is listed below.

How to Contribute?

Community members can participate by:

1. ​Review & Discuss: Comment on checklist items or proposal drafts.
2. ​Claim Tasks: Self-assign unowned items in the action table below.

Action Items Tracking

• Check and confirm that the maintainer's information(affiliation, email) on Maintainer List is up-to-date. (@lfbear, Update MAINTAINERS.md #120)
• Check and confirm that the maintainer's information is synced with CNCF maintainer list. (@lfbear, Update Karmada maintainers company cncf/foundation#978)
• Add maintainer's focus and duty on Maintainer List (@RainbowMango)
• Archive security report of OSTIF. (@RainbowMango, Archive security audit report #121)
• Archive security self-assessment. (@zhzhuang-zju, add karmada self assessment #122)
• Document Security Self-Assessment on application form. (@RainbowMango)
• Engage with CNCF TAG-Runtime through a presentation or completing a General Technical Review.
• Get the insights or recommendation from CNCF TAG-Runtime.
• Nominate more maintainers on to the Maintainer List and update the application form.
• Improving Governance Doc with More Explicit Vendor Neutrality and Maintainer Seat Limits (@RainbowMango, Improving governance doc with vendor neutrality and vote sceanrios #140)
• Clarify the administrator role

[RainbowMango]

Review Project Moving Level Evaluation

• I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.

Karmada Graduation Application

v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria.

Project Repo(s): https://github.com/karmada-io/karmada
Project Site: https://karmada.io/
Sub-Projects: https://github.com/karmada-io/dashboard
Communication: https://cloud-native.slack.com/archives/C02MUF8QXUN

Project points of contacts: Hongcai Ren, qdurenhongcai@gmail.com

• (Post Graduation only) Book a meeting with CNCF staff to understand project benefits and event resources.

Graduation Criteria Summary for Karmada

Application Level Assertion

• This project is currently Incubating, accepted on 2023-12-12, and applying to Graduate.

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

Currently there are over 30 public adopters(in production) of the project, the full list can be found at https://karmada.io/adopters. Some notable adopters include:

• Xiaohongshu: https://www.xiaohongshu.com/
• Trip.com: https://www.trip.com/
• Bilibili: https://www.bilibili.com/
• MoMo: https://www.hellogroup.com/
• Bloomberg: https://www.bloomberg.com/
• Huawei: https://www.huaweicloud.com/
• JDCloud: https://www.jdcloud.com/
• DaoCloud: https://www.daocloud.io/

Application Process Principles

Suggested

N/A

Required

• Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.
  • This was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.

• TAG provides insight/recommendation of the project in the context of the landscape

• All project metadata and resources are vendor-neutral.

• Neutral resources - Karmada has its channels (community branded and managed), including:

  • Homepage: https://karmada.io/
  • Mailing list: https://groups.google.com/forum/#!forum/karmada
  • Slack: https://cloud-native.slack.com/archives/C02MUF8QXUN
  • Twitter: https://x.com/karmada_io
  • Community Meeting:
    • Meeting Notes: https://docs.google.com/document/d/1y6YLVC-v7cmVAdbjedoyR5WL0-q45DBRXTvz5_I7bkA/edit
    • Meeting Link: https://zoom.com/my/karmada

• Clearly state on the official website that the project is open and neutral.

• Governance - Karmada operates under clear vendor-neutral governance in GOVERNANCE.md#values, and all project communication, messaging, and collaboration are also vendor-neutral.

• The structure of the Maintainers Section says: No single vendor can exceed 50% of the total number of maintainers.

• Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.

  • Met during Project's application on DD-MMM-YYYY.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

• Karmada Installation Documentation: covers several ways of deployment.

• Karmada Introduction documentation: introduces the Karmada architecture and main features.

• Karmada Tutorials: provides step-by-step guides for users to quickly learn its usage via hands-on practice.

• Contributor documentation: details on submitting patches and the contribution workflow.

• Contributor Guide: explains how to make contributions.

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

Karmada has been continuously updating community governance doc to reflect project growth, some examples are:

• Karmada initial governance: Propsing project governance #45
• Provide a dependencies policy that describes how dependencies are consumed and updated: add Dependencies policy #77
• Proposing Karmada Adopter Group to enhance communication and collaboration among users, and gather valuable feedback to guide the future development of the project: Proposing Karmada Adopter Group #95
• Update maintainer list according to activity: Put Xiao Zhang to the maintainer list karmada#4392
• Documents the rule of accepting the subprojects as well as list the current subprojects: Add subprojects documentation #118
• Add maintainership change rule: Add maintainership change rule #112
• Add roadmap change process: Add Roadmap change process documentation #117

Required

• Clear and discoverable project governance documentation.

Karmada governance documentation: https://github.com/karmada-io/community/blob/main/GOVERNANCE.md

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

Examples showing that Karmada community governance is up to date:

• Update maintainers affiliation: Update maintainers affiliation karmada#3776

• Add new maintainer: Put Xiao Zhang to the maintainer list karmada#4392

• Update community meeting time: Update community meeting time #99

• Governance clearly documents vendor-neutrality of project direction.

Karmada has clear vendor-neutrality description in the governance doc, including matters related to decision-making and transparent communication. Moreover, every participant is required to engage in the project as an individual.
Quote from the project GOVERMANCE.md#values

• Openness: Communication and decision-making happens in the open and is discoverable for future
  reference. As much as possible, all discussions and work take place in public
  forums and open repositories.

• Fairness: All stakeholders have the opportunity to provide feedback and submit
  contributions, which will be considered on their merits.

• Community over Product or Company: Sustaining and growing our community takes
  priority over shipping code or sponsors' organizational goals. Each
  contributor participates in the project as an individual.

• Inclusivity: We innovate through different perspectives and skill sets, which
  can only be accomplished in a welcoming and respectful environment.

• Participation: Responsibilities within the project are earned through
  participation, and there is a clear path up the contributor ladder into leadership
  positions.

• Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

• Decision-making on leadership roles:

  • community-membership.md: outlines the various responsibilities of contributor roles in Karmada.
  • GOVERNANCE.md#voting

• Contribution acceptance: CONTRIBUTING.md

• Requests to the CNCF: https://github.com/karmada-io/community/blob/main/GOVERNANCE.md#cncf-resources

• Changes to governance: https://github.com/karmada-io/community/blob/main/GOVERNANCE.md#modifying-this-charter

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

Karmada Project has the following basic roles, and the updating process is described in the community-membership.md

• Becoming a member: community-membership.md#member
• Becoming a reviewer: community-membership.md#reviewer
• Becoming an approver: community-membership.md#approver
• Becoming a maintainer: community-membership.md#maintainer
• Retiring inactive members: community-membership.md#inactive-members
• Recruiting and retiring maintainers: community-membership.md#changes-in-maintainership

Karmada Project has one specific team, i.e. the Security Team. Responsibilities and joining, stepping down process are described at: security-release-process.md#the-security-team-membership

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

Karmada documents maintainers list at: https://github.com/karmada-io/community/blob/main/MAINTAINERS.md

• A number of active maintainers which is appropriate to the size and scope of the project.

Karmada currently has 8 maintainers from 6 companies, the activities of the maintainers can be found at https://karmada.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1.

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

Karmada has a clear maintainer lifecycle process documented in their community-membership doc:

• Maintainer roles: https://github.com/karmada-io/community/blob/main/community-membership.md#maintainer

• Becoming a maintainer: https://github.com/karmada-io/community/blob/main/community-membership.md#maintainer-recruiting

• Maintainer Retirement: https://github.com/karmada-io/community/blob/main/community-membership.md#maintainer-retirement

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

Demonstrations regarding the maintainer lifecycle of the Karmada project:

• Karmada-io/karmada#4392: Xiao Zhang was added as a new maintainer

• Project maintainers from at least 2 organizations that demonstrates survivability.

According to the Maintainers list, Karmada currently has 8 maintainers from multiple organizations, including Huawei, ByteDance, Moore Threads, DaoCloud, ICBC, VIPKID.

Definition of Maintainers can be found in the community-membership.md. Maintainers require diverse membership: [No single vendor can exceed 50% of the total number of maintainers](https://github.com/karmada-io/community/blob/main/community-membership.md#the-structure-of-the-maintainers).

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

OWNERS files are used to designate responsibility over different parts of the Karmada codebase. Today, we use them to assign the reviewer and approver roles (defined in our community membership doc) that are used in our two-phase code review process. Ref:

• https://github.com/karmada-io/karmada/blob/master/charts/OWNERS

• https://github.com/karmada-io/karmada/blob/master/pkg/apis/OWNERS

• https://github.com/karmada-io/website/blob/main/docs/OWNERS

• Document adoption of the CNCF Code of Conduct

Karmada follows the CNCF Code of Conduct: https://github.com/karmada-io/community/blob/main/CODE_OF_CONDUCT.md

• CNCF Code of Conduct is cross-linked from other governance documents.

CNCF Code of Conduct is cross-linked in the karmada-io/community repo: https://github.com/karmada-io/community/blob/main/CODE_OF_CONDUCT.md.
All other Karmada repositories maintain a reference to the Code of Conduct in the community repo, e.g.

• karmada-io/karmada: https://github.com/karmada-io/karmada/blob/master/CODE_OF_CONDUCT.md

• karmada-io/dashboard: https://github.com/karmada-io/dashboard/blob/main/CODE_OF_CONDUCT.md

• All subprojects, if any, are listed.

The following projects are associated with Karmada and maintained as sub-projects.

• dashboard: Karmada Dashboard is a general-purpose, web-based control panel for Karmada.

In addition to the above-mentioned sub-projects, other repositories are not sub-projects under the Karmada repositories:

• api: the canonical location of the Karmada API definition.

• website: contains all the docs for Karmada.

• community: the starting point for becoming a contributor - improving code, improving docs, giving talks, etc.

• multicluster-cloud-provider: Defines the shared interfaces which Karmada cloud providers implement.

• multi-cluster-ingress-nginx: a demo used as an example of multi-cluster ingress.

• karmada-operator: this repository has been archived by the owner on Jul 6, 2023. It is now read-only.

• playground: provide an interactive online environment to help users to try and learn Karmada.

• kubernetes: the fleet-apiserver of Karmada.

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

According to Governance.md#Subprojects, sub-projects can have their own repositories but follow the same governance mechanism as the main project.
add/remove process: https://github.com/karmada-io/community/blob/main/GOVERNANCE.md#subprojects

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Contributor ladder with multiple roles for contributors.

Karmada has the following roles for contributors that are related to code and non-code contributions:

• Maintainer: https://github.com/karmada-io/community/blob/main/community-membership.md#maintainer
• Approver: https://github.com/karmada-io/community/blob/main/community-membership.md#approver
• Reviewer: https://github.com/karmada-io/community/blob/main/community-membership.md#reviewer
• Member: https://github.com/karmada-io/community/blob/main/community-membership.md#member

Required

• Clearly defined and discoverable process to submit issues or changes.

The process is defined in the contributing guide, which is cross-linked in the Karmada main repo and website.

• Contributing guide: https://github.com/karmada-io/karmada/blob/master/CONTRIBUTING.md

• Also clearly defined in the karmada website: https://karmada.io/docs/contributor/contribute-docs/

• Project must have, and document, at least one public communications channel for users and/or contributors.

Karmada has the following public communications channel for users and contributors documented in the Project README

• mailing list
• slack | Join
• twitter

• List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

• The communication channels for Karmada documented at https://github.com/karmada-io/karmada/blob/master/README.md#contact

• Karmada has a private mailing list cncf-karmada-security@lists.cncf.io for users reporting security vulnerabilities. Ref: https://github.com/karmada-io/community/blob/main/security-team/SECURITY.md#security-policy

• cncf-karmada-distributors-announce@lists.cncf.io, is for in advance private information and vulnerability disclosure. Ref: https://github.com/karmada-io/community/blob/main/security-team/SECURITY.md#security-policy

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

Karmada currently holds weekly community meetings, with Chinese and English language options every two weeks. Ref: https://github.com/karmada-io/karmada#meeting
Resources:

Meeting Notes and Agenda
Meeting Calendar | Subscribe
Meeting Link

• Documentation of how to contribute, with increasing detail as the project matures.

• Karmada contribution workflow documented at: https://github.com/karmada-io/community/blob/main/CONTRIBUTING.md#contributor-workflow

• Karmada website: https://karmada.io/docs/contributor/github-workflow

• Docs of how to correct information for better contribution: Add doc to explain how to correct information for better contribution website#235

• Demonstrate contributor activity and recruitment.

• Contributor activities measured by devstats: karmada.devstats.cncf.io

• Contributor activity measured by GitHub contributor dashboard: The contributions of contributors

• Examples of recruiting new members/reviewers/approvers/maintainers according to contributor's contributions:

  • Add mohamedawnallah to members: REQUEST: New membership for @mohamedawnallah #87
  • Nominate Xiao Zhang as Maintainers: Nominate Xiao Zhang(@wawa0210) as Maintainers #55

Engineering Principles

• Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This requirement may also be satisfied by completing a General Technical Review.

Project goal from project README.md

Karmada (Kubernetes Armada) is a Kubernetes management system that enables you to run your cloud-native applications across multiple Kubernetes clusters and clouds, with no changes to your applications. By speaking Kubernetes-native APIs and providing advanced scheduling capabilities, Karmada enables truly open, multi-cloud Kubernetes.

Karmada aims to provide turnkey automation for multi-cluster application management in multi-cloud and hybrid cloud scenarios,
with key features such as centralized multi-cloud management, high availability, failure recovery, and traffic scheduling.

Why Karmada:

• K8s Native API Compatible
• Out of the Box
• Avoid Vendor Lock-in
• Centralized Management
• Fruitful Multi-Cluster Scheduling Policies
• Open and Neutral

• Document what the project does, and why it does it - including viable cloud native use cases. This requirement may also be satisfied by completing a General Technical Review.

Karmada introduction: https://karmada.io/docs/
According to Karmada doc, typical use cases are:

Cross-cloud Multi-cluster Management
Multi-cluster Scheduling
Multi-cluster Failover
Multi-cluster Service Governance
Global Uniform Resource View

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

Karmada has a public roadmap doc at : https://github.com/karmada-io/community/blob/main/ROADMAP.md

• Roadmap change process is documented.

Karmada documents its roadmap rules and changing process in https://github.com/karmada-io/community/blob/main/GOVERNANCE.md#roadmap

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.

• Karmada architecture overview: https://github.com/karmada-io/karmada/blob/master/README.md#architecture

• Design details are documented under the proposals directory, an example is: Support Priority Class Configuration for Karmada Control Plane Components

• Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:

  • Release expectations (scheduled or based on feature implementation)
    • Ref to Karmada release cycle, each karmada release cycle takes about 3 months.
  • Tagging as stable, unstable, and security related releases
    • Ref to Karmada release timeline, in each minor release cycle of Karmada, the tags include alpha.1, alpha.2, beta.0, and rc.0. These tags represent important milestones as the release matures. Each phase indicates different levels of stability and feature completeness, ranging from the initial alpha test versions to the near-final release candidate (rc).
  • Information on branch and tag strategies
    • Information on branch strategies: https://karmada.io/docs/next/releases#branches-and-prs
      Information on tag strategies: https://karmada.io/docs/next/releases#the-release-cycle
  • Branch and platform support and length of support
    • According to the release platform support, currently darwin-arm64, darwin-amd64, linux-arm64 and linux-amd64 binaries are maintained by the community.

Length of support is clearly documented in release support versions, karmada maintains the three most recent minor releases, meaning that each minor release receives approximately nine months of patch maintenance following its release.

• Artifacts included in the release.
• Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.

Each release note specifies the artifacts included in the release. Example: Karmada v1.13.0-rc.0 release notes
https://karmada.io/docs/next/releases#release-artifacts

• History of regular, quality releases.

History of Karmada releases and changelogs: https://github.com/karmada-io/karmada/releases

Security

Note: this section may be augmented by a joint-assessment performed by TAG Security.

Suggested

• Achieving OpenSSF Best Practices silver or gold badge.

Required

• Clearly defined and discoverable process to report security issues.

Karmada has a clear security vulnerability report guide at: security-team/report-a-vulnerability.md

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

• One of the requirements for members of the community is to enable two-factor authentication on their GitHub accounts.

• DCO sign-off and review&approval by maintainers are required for all the incoming pull-request. Example: https://github.com/karmada-io/karmada/pull/6161/checks?check_run_id=37834871445

• Karmada also enabled the following static and dynamic scanning, security scanning to help ensure the code quality:

  • Image scanning
  • Golangci-lint
  • E2e test

• Document assignment of security response roles and how reports are handled.

The Karmada Security Release Process documents response roles and the process of handling reports.

• Document Security Self-Assessment.

The Security Self-Assessment can be found at https://github.com/karmada-io/community/blob/main/security-team/assessments/self-assessment.md.

• Third Party Security Review.

  • Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs.

Karmada has passed the Third Party Security Review, and the audit completion date is January 9, 2025. Ref: Karmada-Security-Audit-2025-report. A total of six security issues were discovered during this security audit: one high-level issue, one medium-level issue, two low-level issues, and two informational issues. By now, all found issues have been fixed.

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

Karmada has achieved OpenSSF Best Practices passing badge: https://www.bestpractices.dev/en/projects/5301

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

The Karmada Adopters documents adopters with usage scenarios and case studies, all item listed are production grade adopters.

Organisations below all are using Karmada in production.

• Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)

The project provided the TOC with a list of production adopters for verification of use of the project at the graduation level.

For a full list of public production grade adopters, see Karmada Adopters on karmada website.

• TOC verification of adopters.

To be done by the TOC reviewer: Karmada Maintainers will provide the TOC sponsor with a list of xx users who agreed to be interviewed for the Graduation Due Diligence process.

Refer to the Adoption portion of this document.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

• argo-cd: refer to working with argo-cd

• Flux: refer to working with flux

• pipeCD: refer to working with PipeCD

• Istio: refer to working with Istio

• Filebeat: refer to working with Filebeat

• Submariner: refer to working with Submariner

• Velero: refer to working with Velero

• Prometheus: refer to working with Prometheus

• ANP: refer to working with anp

• Gatekeeper(OPA): refer to working with Gatekeeper(OPA)

• Kyverno: refer to working with Kyverno

• ErieCanal: refer to working with ErieCanal to Empower Cross-Cluster Service Governance

Adoption

Adopter 1 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR

Adopter 2 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR

Adopter 3 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR

[kevin-wangzefeng]

Thanks @RainbowMango for initiating this, good to know most of my offline review comments have been addressed, will take a look and provide feedback.

[kevin-wangzefeng]

Finished review. All the checkboxes that meet the requirements shall be checked. I've updated the checklist accordingly.

[RainbowMango]

I've synced the changes to the official application form in cncf/toc reop: cncf/toc#1572.