[k8s series 4] differences between kubernetes (k8s) community and other open source projects


This article is reproduced from:Talk about kubernetes open source community and its future trend
We know that the kubernetes project is hosted under the CNCF foundation. However, when I explained the development history of containers and kubernetes at the front of the column, I mentioned that the relationship between CNCF and kubernetes is not the relationship between foundations and managed projects in the traditional sense. CNCF actually plays the role of marketing of kubernetes projects.
For example, the kubernetes project should have been maintained, operated and promoted by Google. However, in order to show neutrality and attract more contributors, the kubernetes project chose the model hosted by the foundation from the beginning. The key here is that the foundation itself is behind kubernetes
It was created by the “bosses” of, and then operated and marketed the kubernetes project in a neutral way
In this way, the kubernetes project can not only avoid being denounced by competitors for Google’s “bad style” and non neutral role in the open source community, but also unite all container related forces in the community from the commanding height of the open source foundation. The subsequent rapid development and growth of CNCF foundation also confirmed that this idea is actually very correct and foresight.
However, after the graduation of kubernetes and Prometheus, the first and second projects of CNCF, the more functions of CNCF community are to play the role of a traditional open source foundation, attract members and help incubate and operate the projects
However, due to the great success of the kubernetes project, CNCF has achieved a high reputation and recognition in the field of cloud computing, and also filled the gap of the previous Linux foundation in this field. Therefore, you can think that the current CNCF is Apache in the field of cloud computing, and its role is the same as that of the Apache foundation in the field of big data.
However, it should be noted that third-party foundations have never been a necessary condition for the operation of open source projects and open source communities. In fact, most successful open source projects and communities in the world come from a smart idea or a group of outstanding hackers. In the development of these projects, the role of an independent and third-party foundation is more part of the active commercial operation after the project has developed to a certain extent. I hope you don’t put the cart before the horse in this layer of relationship between open source projects and foundations
In addition, it should be noted that CNCF foundation is only responsible for the marketing of member projects, and will never and has no ability to directly affect the development process of specific projects. Neither any member company nor CNCF’s TOC (technical oversight committee) has the right to “dictate” the kubernetes project, unless the TOC is a key figure in the kubernetes project.
Therefore, it is the kubernetes community itself that can really affect the development of kubernetes project. You may wonder, how does the kubernetes community itself operate?
Generally, the projects managed under a foundation need to follow the management mechanism of the foundation itself, such as unified CI system, code review process, management method, etc.
However, in the actual situation of our community, there are kubernetes first, and then CNCF, and the CNCF foundation is “brought up by kubernetes”. Therefore, in terms of project governance, the kubernetes project has long been self-contained and developed very well. Other projects in the foundation are generally in their own arrays, and CNCF will not put forward too many requirements for the governance methods of the project itself
When it comes to the governance mode of kubernetes project, it is actually close to Google style, that is, pay attention to code and community democracy.
First, the kubernetes project is a project without a “maintainer”. This is very interesting. The role of maintainer once existed in the kubernetes project for a short time, but it was soon abandoned. Instead, it is the approver + reviewer mechanism. The specific principle here is that you can add an owners file in each directory of kubernetes, and then write such fields in the file:

- caesarxuchao
- lavalamp
- sig/api-machinery
- area/apiserver

For example, in the above example, the GitHub ID of the approver is caesarxuchao (Xu Chao), and the reviewer is lavaamp. This means that any pull request (PR, code modification request) submitted by anyone who modifies the files in this directory must go through the code review of Lavalamp and then the approval of caesarxuchao before it can be merged. Of course, in this file, caesarxuchao has the greatest power. It can do both code review and final approval. However, Lavalamp cannot approve.
Of course, whether the code review is approved or approved, these maintainers only need to comment / lgtm and / approve under the PR, and the k8s CI robot of kubernetes project will automatically label the PR with lgtm and approve, then enter the merge queue of kubernetes project CI system, and finally be merged. In addition, if you want to tag this project or assign it to others, you can also use comment.
It can be seen that in the whole process, code maintainers can complete all processes such as code review and consolidation without having write permission on kubernetes project. Of course, this is due to the perfect robot mechanism of kubernetes community, which is also one of the most attractive features of GitHub.
By the way, many people ask me, where is GitHub better than gitlab or other code hosting platforms? In fact, GitHub’s huge API and plug-in ecology is the most attractive part of this product.
Of course, when you want to submit your ideas to the kubernetes project in the form of code, unless your changes are bugfix or very simple changes, you will probably not be approved if you directly submit a pr. The process here must be carried out according to my following explanation:

  1. Create an issue in the kubernetes main database to describe in detail the problems, solutions, and development plans you want to solve. If relevant issues already exist in the community, you must quote them here. If the same issue already exists in the community, you need to confirm whether it should be directly transferred to the original issue for discussion.
  2. Label issue with sig related to it. For example, you can directly comment / sig node, and the issue will be labeled with sig node, so that members of SIG node will pay special attention to the issue.
  3. Collect community information on this issue, reply to comment and reach an agreement with sig members. If necessary, you also need to attend the weekly meeting of SIG to better explain your ideas and plans
  4. After reaching agreement with most members of SIG, you can start the detailed design
  5. If the design is complex, you also need to submit a PR under the kubernetes design proposal directory (in the kubernetes Community Library) to add your design documents. At this time, all community members who care about the design will come to discuss your design. Finally, however, only a few members of the entire kubernetes community have permission to review and approve your design documents. Of course, they are also defined in the owners file under this directory, as shown below
 - brendandburns - dchen1107 - jbeda - lavalamp - smarterclayton - thockin - wojtek-t - bgrant0607approvers:
 - brendandburns - dchen1107 - jbeda - lavalamp - smarterclayton - thockin - wojtek-t - bgrant0607labels:
 - kind/design

These members can be called “big men” in the community. But what I want to remind you here is that “big guy” does not necessarily mean high level, so you still have to polish your eyes. In addition, several founding members of the kubernetes project, called elders, are jbeda, bgrant0607, brendandburns, dchen1107 and thockin.

  1. After the above design proposal is merged, you can start writing code according to the content of the design document. This process is the well-known process of writing code, submitting PR, passing CI test, conducting code review, and then waiting for consolidation.
  2. If your feature needs to be released online in the official release of kubernetes, you also need to submit a kep (kubernetes enhancement proposal) in the library of kubernetes enhancements. The main content of this kep is to describe your coding plan, test plan, release plan, backward compatibility plan and other software engineering related information in detail for the supervision and guidance of the whole community.

The above is the main way of kubernetes community operation.