The grievances between Docker and k8s (4)-the end of the cloud-native era

Please indicate the source for reprinting: Grape City official website, Grape City provides developers with professional development tools, solutions and services, and empowers developers.

In the previous articles of this series, we introduced the iterative process of the development of PaaS platforms from Cloud Foundry to Docker. Today we continue to introduce to you the reasons for Docker's desolation and the opening of the era of great navigation.

Commercialization of Docker

In the previous article, we talked about the Docker project using its own innovative Docker Image to instantly become popular, so many businesses have also discovered business opportunities from it, launched their own container products, and wanted to get a share of the market.
CoreOS launched the Rocket (rkt) container, and Google has also open sourced its own container project lmctfy (Let Me Container That For You), etc. However, in the face of the strength of the Docker project, even a bigwig like Google has nothing to resist. Therefore, Google intends to cooperate with Docker, shut down its own container project, and maintain open-source container operations with Docker, but Docker strongly rejected this cooperation that would obviously weaken its position.

At this time, Docker also realized that it is only the hero behind the cloud computing technology stack, and can only be used as the carrier for the final deployment of applications on the platform. However, if you want to become the core of this field, you should have your own PaaS ecosystem. After Docker exploded and had sufficient funds, Docker started a frantic buy-buy-buy to expand its strength, the most famous of which was signed Fig. Fig is the predecessor of the famous Docker Compose project. Through these mergers and acquisitions and its own R&D iterations, Docker finally launched a three-piece PaaS with itself as the core: Docker Compose, Docker Swarm and Docker Machine.
Here is a brief introduction to the content of the Docker three-piece suit:

1. Docker Compose: The predecessor of Compose is Fig, an open source project of Docker container orchestration maintained by only two people. Its function is: If the user now needs to deploy an application A and a database B and load balance C, then Fig will allow users Define the three containers ABC in a configuration file and specify their relationship. Finally, only one command fig up can be used directly.

At the time of the Docker fire, the Fig project on Github was as hot as Docker, so in 2015 Docker acquired it and renamed it Docker Compose as an orchestration tool for Docker containers, and it has been used today.

2. Docker Swarm: Swarm is a Docker cluster management project. Its main logic is similar to the Cloud Foundry mentioned in the previous section. You can use docker run -H my Swarm cluster in a command line similar to docker run my image. API address My image runs Docker into a cluster and manages it. The emergence of Swarm upgrades the Docker project from an ordinary container to a PaaS platform.
3. Docker Machine: Machine should be the least well-known of the Docker three-piece suit. Its function is to run virtual machines into containers and manage virtual machines in the same way as Docker containers.

OCI's "inaction" appeared to CNCF

On the road of development, Docker has always maintained absolute authority and voice in the development of Docker open source projects, and has challenged the interests of other players with practical actions on multiple occasions; on the other hand, Docker’s commercialization path is serious. It violated the vital interests of the former partner company RedHat; in addition, Docker's high-speed iteration list in 2015 showed various unstable breaking changes and began to make the community complain.

There are many popular people, not to mention that Docker also grabbed everyone's cake. As a result, several other players in the container field began to discuss the right to "cut" the Docker project. In the end, Docker was under pressure. On June 22, 2015, it led CoreOS, Google, RedHat and other companies to jointly establish a neutral foundation and donated its own container runtime LibContainer and renamed it RunC. Based on RunC, the Foundation jointly formulated a set of standards and specifications for containers and mirrors-OCI (Open Container Initiative).

The establishment of OCI means that the implementation of container runtime and mirroring is completely separated from the Docker project, making it possible for other players to implement their own Docker runtime without relying on Docker.

However, because the establishment of the foundation was only a compromise between Docker and these large companies, and it did maintain a large enough community at the time, Docker was confident about the establishment of the foundation and did not care about the formulation of standards. Because in the general environment at that time, Docker's own implementation was already the industry's unified standard.

Due to the slow development of the OCI Foundation, the leading players in the infrastructure fields such as Google and RedHat played the trump card in their hands and jointly led a foundation called CNCF (Cloud Native Computing Foundation) (this is also the concept of cloud native Appeared in the public eye for the first time). The ideological basis of the CNCF Foundation is to build a platform-level community led by open source infrastructure vendors based on the Kubernetes project and operated in the manner of an independent foundation to fight against the container business ecosystem with Docker as the core. It is also the establishment of this foundation that our protagonist Kubernetes in the second quarter has also begun to emerge.

The emergence and development of Kubernetes

Kubernetes is an open source container infrastructure orchestration framework released by Google as early as 2014. Unlike other technologies that have come up with brains, the technology of Kubernetes has a theoretical basis, namely: Borg. Borg is a part of Google's entire infrastructure system, and Borg is a part of Google's entire infrastructure system. Google has also published a number of papers on Borg as its theoretical support. It carries many industry-leading technologies such as MapReduce and BigTable. Therefore, the Borg system has always been hailed as the most powerful "secret weapon" within Google, and it is also the most unlikely open source project for Google. Kubernetes was developed on this theoretical basis. The figure below is the public infrastructure stack of Google described in the Google Omega paper.

Open source vs closed source

Facing the emergence of k8s, a container battle between Docker and k8s started.

At the beginning of this confrontation, because the Kubernetes development inspiration and design ideas originated from Borg, the Kubernetes project was called Qu Gao and Qi when it was first released. Too advanced thinking makes developers unable to understand. At the same time, because the Kubernetes project has been maintained by Google engineers, it did not receive much attention and growth at the beginning of the release.

However, the establishment of CNCF changed all of this. RedHat's strength is that it has a mature community management system and enough engineering capabilities. This has enabled the Kubernetes project to develop rapidly after being handed over to the community for maintenance, and gradually began to fight against Docker. And different from the closed business model of Docker, Kubernetes is the opposite of opening the source and democratizing. Every important function provides users with a customizable interface, and ordinary users can also pull and modify the Kubernetes code without permission. , The community has dedicated reviewer and approver. As long as the code you write passes the PR and passes the code review and approval, it will become the backbone of Kubernetes, which greatly increases the vitality of Kubernetes. Moreover, relying on open interfaces, Kubernetes-based open source projects and plug-ins abound, and relying on excellent architecture design, emerging technology concepts such as microservices are also quickly implemented, and finally a stable and huge ecology with a hundred flowers blooming is formed.

And Docker can only be modified by its own engineers, which is far behind Kubernetes at this point.

To sum it up:

Facing the rise and growth of the Kubernetes community, Docker had to admit that its gamble ended in failure. Starting in 2017, Docker donated the container runtime part of the Docker project to the CNCF community and announced in October of that year that it would The built-in Kubernetes project in its own Docker Enterprise Edition also marks the end of the container orchestration battle that has lasted for nearly two years. In January 2018, RedHat announced the acquisition of CoreOS for US$250 million. In March 2018, Solomon Hykes, CTO of Docker, the initiator of all these disputes, announced his resignation. So far, the turbulent container technology circle has settled and the world has become one.

Summarize

This article introduces how Docker became the focus of the PaaS platform and how it was replaced by Kubernetes step by step. In the next section, we will continue to introduce to you how Kubernetes has reduced the dimensionality of its container orchestration technology in addition to the community, so stay tuned.