Shulou(Shulou.com)05/31 Report--

In this article Xiaobian introduces in detail "what is the difference between the kubernetes community and other open source projects", with detailed content, clear steps and proper handling of details. I hope that this article "what is the difference between the kubernetes community and other open source projects" can help you solve your doubts.

We know that the Kubernetes project is hosted under the CNCF Foundation. However, when I explained the history of container and Kubernetes at the beginning of the column, I already mentioned that the relationship between CNCF and Kubernetes is not the traditional relationship between foundation and managed project. CNCF actually plays the role of Marketing of Kubernetes project.

For example, the Kubernetes project should have been maintained, operated and promoted by Google alone. But in order to show neutrality and attract more contributors, the Kubernetes project chose to be hosted by the foundation from the very beginning. And the key here is that the foundation itself, created by the "bosses" behind Kubernetes, then operates and Marketing the Kubernetes project in a neutral way.

In this way, the Kubernetes project avoids being criticized by competitors for Google's "bad style" and non-neutral role in the open source community, and can unite all container-related forces in the community on the commanding heights of the open source foundation. And then the rapid development and growth of the CNCF Foundation also confirmed that this idea is actually very correct and prescient. However, after the graduation of Kubernetes and Prometheus, the first and second projects of CNCF, the more function of the CNCF community now is to play the role of a traditional open source foundation, recruit members, and help the project incubate and run.

However, due to the great success of the Kubernetes project, CNCF has achieved a high reputation and recognition in the field of cloud computing, which has filled the gap of the previous Linux Foundation in this field. So, you can think that the current CNCF is the Apache in the field of cloud computing, and its role is the same as that of the Apache Foundation in big data's field.

It should be noted, however, that third-party foundations have never been a necessary condition for open source projects and the operation of the open source community. In fact, most of the world's successful open source projects and communities come from a smart idea or a bunch of brilliant hackers. In the development of these projects, the role of an independent, 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 the relationship between open source projects and foundations.

In addition, it should be pointed out that the CNCF Foundation is only responsible for the Marketing of member projects, and does not and does not have the ability to directly affect the development 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.

So, of course, it is the Kubernetes community itself that can really influence the development of Kubernetes projects. You may wonder how the Kubernetes community itself works.

Usually, a project hosted by a foundation needs to follow the foundation's own management mechanism, such as a unified CI system, Code Review process, management method, and so on.

However, in the actual situation in our community, there is Kubernetes before CNCF, and the CNCF Foundation is still "brought up" by Kubernetes. Therefore, in the matter of project governance, the Kubernetes project has long been a system of its own, and has developed very well. While other projects in the foundation are generally separate, CNCF will not put forward too many requirements on the governance methods of the project itself.

When it comes to the governance of the Kubernetes project, in fact, it is relatively close to the Google style, that is, attach importance to the code and the democracy of the community.

First of all, the Kubernetes project is a project without "Maintainer". This is very interesting, the role of Maintainer existed for a short time in the Kubernetes project, but it was quickly abandoned. Instead, it is the approver+reviewer mechanism. The specific principle here is that in every directory of Kubernetes, you can add an OWNERS file and write a field like this in the file:

Approvers:- caesarxuchaoreviewers:- lavalamplabels:- sig/api-machinery- area/apiserver

For example, in the above example, the GitHub ID of approver is caesarxuchao (Xu Chao) and reviewer is lavalamp. This means that anyone who submits a Pull Request (PR, code modification request), as long as he modifies the files in this directory, must go through lavalamp's Code Review, and then through caesarxuchao's Approve before it can be merged. Of course, in this file, caesarxuchao has the greatest power. It can be both Code Review and final Approve. However, lavalamp cannot carry out Approve.

Of course, whether through Code Review or Approve, these maintainers only need to Comment / lgtm and / approve,Kubernetes project k8s-ci-robot under PR to automatically tag the PR with lgtm and approve, then enter the merge queue of the Kubernetes project CI system, and finally be merged. In addition, if you want to tag the project or Assign it to someone else, you can do it through Comment.

As you can see, in the whole process above, the code maintainer does not need to have write access to the Kubernetes project to complete all the processes such as code review, merge, and so on. This is, of course, thanks to the perfect robotic mechanism of the Kubernetes community, which is one of the most attractive features of GitHub.

By the way, a lot of people ask me, how 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, it is very likely that you will not be Approve if you submit a PR directly. The process here must be carried out in accordance with my following explanation:

Create an Issue in the main Kubernetes library to describe in detail the problems, solutions, and development plans you want to solve. And if relevant Issue already exists in the community, then you have to quote them here. If the same Issue already exists in the community, you need to confirm whether it should be transferred directly to the original issue for discussion.

Tag the Issue with the SIG associated with it. For example, you can directly Comment / sig node, then the Issue will be labeled sig-node, so that members of the SIG-Node will pay special attention to the Issue.

Collect community information about this Issue, reply to Comment, and agree with SIG members. When necessary, you also need to attend SIG's weekly meetings to better present your ideas and plans.

After agreeing with most members of SIG, you can begin to work on the detailed design.

If the design is complex, you also need to submit a PR in Kubernetes's design proposals directory (in the Kubernetes Community library) to add your design documents. At this time, all members of the community who are concerned about the design will come to discuss your design. In the end, however, only a small number of 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

Reviewers:-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 "bosses" in the community. But I would like to remind you here that "boss" does not necessarily mean a high level, so you still have to keep your eyes open. In addition, the founding members of the Kubernetes project, known as Elders, are jbeda, bgrant0607, brendandburns, dchen1107 and thockin.

After the above Design Proposal has been merged, you can start writing code according to the contents of the design document. This is the normal well-known process of writing code, submitting PR, passing CI testing, doing Code Review, and then waiting for a merge.

If your feature needs to be released online in Kubernetes's official Release, then you also need to submit a KEP (that is, Kubernetes Enhancement Proposal) in the Kubernetes Enhancements library. The main content of this KEP is to describe in detail your coding plan, test plan, release plan, and backward compatibility plan and other software engineering-related information for the whole community to supervise and guide.

After reading this, the article "what is the difference between the kubernetes community and other open source projects" has been introduced. If you want to grasp the knowledge of this article, you still need to practice and use it to understand it. If you want to know more about the article, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.