Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Graduation] Karmada Graduation Application #1572

Open
43 of 56 tasks
RainbowMango opened this issue Mar 26, 2025 · 0 comments
Open
43 of 56 tasks

[Graduation] Karmada Graduation Application #1572

RainbowMango opened this issue Mar 26, 2025 · 0 comments
Labels
graduation

Comments

@RainbowMango
Copy link

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

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:

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

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

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:

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:

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.

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

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:

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:

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.

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:

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.

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

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

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

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:

  • 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.

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.

  • 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)

See Karmada Adopters on karmada website for a complete list。

The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

  • TOC verification of adopters.

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.

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
graduation
Projects
CNCF TOC Board
Status: New
Milestone
No milestone
Development

No branches or pull requests
1 participant
@RainbowMango