Three Ways Kubernetes Landed

Three ways Kubernetes landed

Three ways Kubernetes landed.Author | Wang Guoliang, a member of the Kubernetes community and project maintainer .com/p/82666719 Since its open source in June 2014, the Kubernetes project, which was born in a wealthy family and endorsed by a big manufacturer, has risen rapidly with the joint efforts of many manufacturers and open source enthusiasts, and has grown into a de facto standard in the field of container management today.

Three ways Kubernetes landed.Author | Wang Guoliang Kubernetes community member and project maintainer Original title "The Way of Kubernetes Application: The "Three Axes" for Kubernetes to Land", first published in Zhihu column: Attack on Cloud Computing Original address: https://zhuanlan.zhihu.com /p/82666719

Three ways Kubernetes landed.Since its open source in June 2014, the Kubernetes project, which was born in a wealthy family and endorsed by a large factory, has risen rapidly with the joint efforts of many manufacturers and open source enthusiasts, and has grown into a de facto standard in the field of container management today. With its advanced design concept, open participation threshold, and strong support from domestic and foreign manufacturers and developers, its success is self-evident.

Three ways Kubernetes landed.The popularity of Kubernetes at home and abroad, including major cloud manufacturers, Ant Financial , JD.com, Meituan, Didi and other major companies have made Kubernetes the center of their infrastructure. "In the eyes of 10,000 people, there are 10,000 A Hamlet", although Kubernetes is the de facto standard in the field of container management, in fact, in enterprises with different backgrounds, there are differences in the way Kubernetes is implemented. It can be roughly divided into three categories:
•Three ways Kubernetes landed.One is completely on top of Kubernetes (Above), which is deployed and applied in its native way. Most of these users are start-ups without too much technology stack burden, and mainly focus on using public cloud Kubernetes solutions and services. ;
•One is a container management platform based on Kubernetes (On), which reuses some concepts of Kubernetes but does not hand over application management to Kubernetes, and maintains the old service governance method. This type of enterprise has developed for a long time. The technical burden is relatively heavy, and it is impossible to immediately switch to the cloud-native service governance method, and it is impossible to abandon years of technical accumulation. Such users are mainly concentrated in some medium or large-scale private cloud Kubernetes usage scenarios;

•The other is based on the design concept of Kubernetes (In) to solve and adapt to the localized application management needs by customizing the application load, and integrate the localized load and management into the native Kubernetes architecture, which is also one of the current application management. Trend, not only can eat the dividends of cloud native and community Kubernetes, but also better integrate years of technology accumulation, development and evolution into it. This is an excellent way to embrace cloud native.
Basic "axe": Above Kubernetes

Three ways Kubernetes landed.If you are asked to choose a container management platform now, I believe that no one will miss Kubernetes, especially for users without any technical burden, choosing Kubernetes is undoubtedly the most sensible choice.
Above Kubernetes, this way of landing is well understood, that is, you bring the native, standard, community version of Kubernetes without any contact and intrusion changes, deploy and run it directly, and build your own applications completely on top of Kubernetes , to access the cluster through the standard Kubernetes API. You can completely follow the community upgrade and evolve your Kubernetes, keep pace with the community, and maintain your Kubernetes entirely with the help of the community.
This way of landing is undoubtedly the most ideal. You don't have to consider breaking away from the mainstream of the community and the industry, and it also reduces the cost of management and operation and maintenance.

Three ways Kubernetes landed.As shown in the figure above, you can install a standard and mainstream cloud native system to implement Kubernetes, and you can embrace a complete set of architectural solutions from the community, which is sufficient to meet your needs.
Advanced "Axe": On Kubernetes

Three ways Kubernetes landed.Being able to use a native Kubernetes cluster is great, but some scenarios don't necessarily work. We all know that the concept and design of Kubernetes is actually very advanced. Although Google's software development and application deployment concepts are good, most companies in the industry still have outdated technical concepts and more complex scenarios. For users, it is indeed a bit overwhelming to abandon the current application management and deployment method and change it to the native Kubernetes application deployment and management method. For these users, they definitely can't watch other people eat meat and nibble on their own.

Three ways Kubernetes landed.The landing form of On Kubernetes is actually a compromise and an intermediate process. On the one hand, it is difficult to abandon the existing infrastructure, such as service governance, monitoring, network topology, etc., and can only do some localization on the basis of native Kubernetes The transformation enables Kubernetes to meet the current application management methods, such as abandoning kube -proxy and using a flat intranet environment, packaging some monitoring and proxy components through rich containers, and so on.

On the one hand, this way of landing can enjoy this wave of technological dividends with less changes. On the other hand, you can explore your own cloud-native path, and the internal technology stack can also evolve in the direction of cloud-native. The trend is too far behind, and you can do customized Kubernetes development according to your own scenarios, even go further than the community's Kubernetes or solve some problems that the community has not solved.

There are both gains and losses. Although the design concept and management capabilities of Kubernetes can be used, at the same time, since the localized transformation cannot be fully compatible with the community version of Kubernetes, the upgrade will be more troublesome. There will be the dilemma of maintaining multiple Kubernetes versions at the same time, which will undoubtedly bring a lot of trouble to development and operation and maintenance , so this is not a path that ordinary small companies can take, and requires certain R&D and technical capabilities. Typical ones are Alibaba's Sigma, Meituan -Dianping's HULK 2.0 and JD.com's JDOS 2.0.

Three ways Kubernetes landed.Meituan Dianping HULK2.0


In this high-level gameplay, there is no standard routine, only the one that conforms to your own. For example, Meituan Dianping has built a HULK 2.0 system on Kubernetes based on its existing facilities, and has made localized transformations in terms of storage, network, load life cycle management, and application monitoring, but still maintains full compatibility with the Kubernetes API. You can integrate a series of components according to your own infrastructure, such as storage, monitoring, link tracking, service release, and network, and even deeply customize Kubernetes according to business scenarios and your own needs, such as NetEase Cloud 's Kubernetes-based Deep customization practice.
Lore "Axe": In Kubernetes

The term cloud native has been widely circulated in the technical circle, and even some students do not understand what cloud native is, but they all know that it is necessary to develop and evolve towards cloud native. In any case, it is necessary for users to change the way virtual machines are deployed and managed in the past and the governance strategy of services. It has to be said that All in Kubernetes is a trend. CRD has been produced from Kubernetes version 1.7 to the GA of version 1.16 released last week, which means that we have the ability to extend Kubernetes in the production environment.

If you have a deep understanding of Kubernetes, you will find that Kubernetes itself is a platform. In addition to providing many functions, Kubernetes can simplify the workflow of applications and speed up development; users can use Label to organize and manage resources in their own way; Use Annotation to customize the description of resources, such as providing status checks for management tools. In addition, Kubernetes controllers are also built on the same API used by developers and users. Users can also write their own controllers and schedulers, and can also extend the functionality of the system through various plug-in mechanisms.

That is to say, we can complete any form and type of application load and management method in Kubernetes by extending the API and load type, even if you have a complex technology stack that cannot be escaped or a complex workflow, no problem, you can Inject any external dependencies and logic in the resource and application lifecycle according to your needs.

This way of landing is actually based on the extension mechanism provided by Kubernetes, which completely transforms the localized and complex logic into the design and management concept of Kubernetes, not only using Kubernetes, but integrating and weakening native Kubernetes, and ultimately every user Each has its own unique set of Kubernetes. You have me I have you. Additionally, it is still fully compatible with native Kubernetes, gracefully upgrading and merging community patches and more. A more representative one is the Openkruise project, which is open sourced by Alibaba. https://github.com/openkruise/kruise

The core of users' use of Kubernetes is workload management. In fact, a big reason for choosing On Kubernetes is that the user's current workload management method does not well match the existing workload types of Kubernetes. CRDs and Operators solve this problem well, allowing users to customize their own workloads. A prime example of this is the OpenKruise project, a set of controllers that extends and complements the workload management of the Kubernetes core controller. For example it offers three workload controllers:
•Advanced StatefulSet : An enhanced version of the default StatefulSet with extra features such as inplace- update , pause , and MaxUnavailable .

•BroadcastJob : A job that runs a Pod on all nodes in the cluster to complete.

•SidecarSet : A controller that injects sidecar containers into the Pod specification based on selectors and is able to upgrade sidecar containers .

Ideally, any load can do All in Kubernetes, even Kubernetes itself load management, that is, kube - on-kube , and management of stateful services, such as Mysql cluster operator, etc. You can find some on operatorhub Very classic example.

Three ways Kubernetes landed Summarize

Although different landing methods are different from each other, they are actually the best choices in different contexts. They can all be fully compatible with the Kubernetes API. Without the problem itself, it is impossible to say which method is the best.
•Above Kubernetes: If you are a startup and just want to use Kubernetes to meet normal container management or service deployment, there is no burden, and there is not enough manpower to maintain Kubernetes by yourself;
•On Kubernetes: If you are a medium or even large company with a large amount of technical accumulation and facilities, and the ability and manpower to transform and develop Kubernetes or native Kubernetes cannot meet your needs;
•In Kubernetes: You are not satisfied with simply using Kubernetes or the native Kubernetes cannot meet your needs, you can change from Above Kubernetes; of course, if you think about it, or want to completely transform the current infrastructure and application management methods, think Moving closer to the cloud-native path or wanting to upgrade outdated machine deployment and delivery models, you can move from On Kubernetes to All in Kubernetes.

Related Articles

Explore More Special Offers

  1. Short Message Service(SMS) & Mail Service

    50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00