Yesterday Boss Feng posted an article discussingwhy putting the database into K8S is not a wise choice.
If someone questioned containerized databases four years ago, I think it would be okay to have a battle. It’s already 2023 and there are still people who can’t recognize this trend, so it’s necessary for me to talk about my views.
I have been doing this since K8s version 0.9. It was a little early at that time, and CSI was not yet mature. It was only a little more stable in 1.0. At that time, I was working at iFlytek, and the project I was responsible for was building and maintaining a complete system. The system ultimately supports the company's internal PaaS services.
We built a cluster of 30 physical machines. Although this cluster is small, it is very technical. There are nearly 3,000 applications running in it, and they are of various types, including but not limited to microservices. , database, message queue, cache, etc. This cluster is used by hundreds of developers within the company at the same time, but the operation and maintenance of the entire cluster can be completed with less than half a manpower. Without K8s, all this would be absolutely impossible.
We also upgraded the Linux kernel imperceptibly without affecting upper-layer applications. This kind of imperceptible upgrade is unimaginable without the support of K8s. Just communicating with various business lines may take half a year.
I have seen another cluster that only ran 400 databases, 400 servers, and an operation and maintenance team of 40 people. The overall utilization rate of the cluster was less than 10%. No one dares to touch the entire cluster, so it can only be filled with people and operated and maintained by humans. While this situation can be attributed to unprofessionalism on the part of the organization, in reality many teams face similar challenges and are unable to effectively manage and optimize their infrastructure.
Later I went to Alibaba, and all delivery scenario databases ran on K8s. So far, we have been running databases in containers for more than five years, with zero failures.
Database on K8s: popularization of professional capabilities
Most companies doing business usually have two problems with database processing: either the database management level is average and cannot fully utilize the potential of the database; or they need to spend a lot of money on database management every year. Database on K8s can standardize all this. With standards, people can collaborate, and productivity changes production relations, thus greatly improving efficiency. Allowing the vast majority of teams that do not have professional capabilities to enjoy professional capabilities essentially makes the division of labor clearer, just like the separation of agriculture and animal husbandry, each focusing on its own field, thus improving overall efficiency and output.
Taking the KubeBlocks team as an example, I believe that most companies do not have as much accumulation and professional capabilities at the database level as they do. And they transformed these practical experiences into code and wrote controllers to empower other companies in an extremely simple way. K8s makes this possible.
You may ask: Why not use Ansible? Operations and maintenance personnel may admire Ansible because it matches the tools they have on hand and is easy to use. The core idea of Ansible is to help users deploy and perform operation and maintenance operations, while the K8s controller is based on another idea:What machines can do should not be done by humans a> 24 hours a day without interruption. This is difficult to achieve with Ansible. How can you use Ansible to achieve it? Want to write a scheduled task? . Through Operator, you can synchronize the desired state and actual state
It's like before the advent of operating systems, programmers had to manually punch holes in paper tape to run programs. Some people may say that if you can run programs on paper tape, or even burn programs on a CD to run, why do you need an operating system?
It's the same thing: Ansible is a great tool for operations people, but the goal of K8s is to eliminate low-end operations work (i.e., the work of writing and executing Ansible scripts). Through K8s, we can achieve more efficient and automated database management, so that teams that do not have professional database management capabilities can also enjoy professional-level services.
Advantages of database on K8s
Most people's concerns about running databases on K8s focus on these issues:
Not sure about the stability?
There's a problem that I can't troubleshoot?
Is the performance not good enough?
the complexity
When running a database on K8s, the complexity is mainly divided into two aspects:
- The complexity of building this system
- complexity of use
First: the complexity of building this system
If you build a database system directly based on native K8s (bare K8s), the cost will be relatively high, and for novices, such an operation is not friendly. You need to build multiple components such as K8s storage driver and database controller yourself. It cannot be done without deep professional knowledge and practical experience.
At this time, the advantages of distributions are reflected. Similar to Linux systems, most people prefer to use distributions such as CentOS and Ubuntu instead of directly operating the kernel. We can also think of K8s as a "cloud kernel". If you just use the kernel directly without proper customization and optimization, you may not find it useful enough. Because the kernel itself only provides a framework, many functions and optimizations need to be implemented by users themselves. The K8s distribution helps users solve this problem. For example, Sealos can help you build a complete system including high availability clusters, storage plug-ins and databases with one click . All this requires only two simple commands:
$ sealos run labring/kubernetes:v1.27.7 labring/helm:v3.9.4 labring/cilium:v1.13.4 \
--masters 192.168.64.2,192.168.64.22,192.168.64.20 \
--nodes 192.168.64.21,192.168.64.19 -p [your-ssh-passwd]
$ sealos run labring/openebs:v3.9.0 labring/mysql:8.0
Then there was no more, a system including a high-availability cluster, storage plug-in and database was born. Although Ansible can help you solve installation problems, itcannot handle runtime self-healing, multi-tenancy and other issues, while on K8s can make the database as a Service.
Second: complexity of use
Through cloud operating system distribution and controller, users can implement productized database services instead of relying on scripts to solve problems.
I believe no one will use this page, right? Even a novice like me has the ability to build a PostgreSQL cluster with 3 replicas and include backup, recovery and monitoring functions. This ability can not only be given to all developers in the enterprise, but also demonstrate the fundamental difference between "cloud computing thinking" and "script thinking". Cloud computing allows everyone to provide services (as a Service), while the traditional script method is just a convenient tool for operation and maintenance personnel.
stability
Our team is not even professional in the database field, but we have been able to establish a fairly stable database system, let alone top experts who specialize in this field. Users don’t need to worry about this, just leave it to professionals.
For example,Sealos Public Cloud currently runs thousands of applications, and the databases of these applications are fully containerized, powered by Support is provided by the KubeBlocks team. Once there is any problem with the database, we just throw it to them. From a cost perspective, the cost of recruiting a DBA is much higher than what we pay for the commercial version of KubeBlocks, and Sealos is also the builder of the platform, not to mention the end users who use the database. Judging from the current operation situation, our stability has far exceeded the operation and maintenance level of many non-professional teams.
And basically there are only so many things in database life cycle management. Stability issues will be converged over time. These problems are constantly being solved at the code level, and end users will care less and less. . This is similar to the stability of the Linux system. As the technology continues to mature and be optimized, its stability has reached a very high level. A good software architecture will continuously improve and converge its robustness, and gradually reduce its dependence on people. For example, people who use Oracle will have more tea time than people who use open source MySQL. many.
So whether from the perspective of reality or theoretical analysis, stability should not be an obstacle for users to run databases on K8s. Running the database on k8s is actually leveraging the experience of dozens of top database experts. They integrate their knowledge and skills into the code and serve users in a standardized way. It would be difficult to convey these experiences so thoroughly and efficiently using scripts alone. . It would be difficult to convey these experiences so thoroughly and efficiently using scripts alone.
performance
It is said that if the performance of the database running container is not good, there is a high probability that it will not be used. The KubeBlocks team has done in-depth testing and tuning, and written a very detailed analysis article. Many people think it is really complicated, but in fact This complicated thing does not require users to do it. These complexities are built into the controller's code, making the process uncomplicated for the end user. Moreover, the impact of containers on database performance is almost negligible. What really matters are factors such as disk IO and network bandwidth latency.
The solution of OpenEBS bare disk + database controller can effectively solve the performance problem. With a database controller, there is no need to rely on distributed storage. The controller can ensure high performance and high availability of multiple copies of the database. Whether it is a stateful service or a stateless service, users will not feel the difference. If an instance fails, the controller automatically adjusts. This is the ultimate database usage experience.
Sealos This solution has been adopted to ensure high availability without sacrificing performance. It can directly connect to bare disks for automatic expansion, backup and recovery. If a node fails, the controller automatically starts a new node, synchronizes data and joins it to the cluster. These advanced functions can only be implemented in the cloud operating system, and traditional scripting methods can only be far behind, and the latter usually requires manual intervention. For example, if it hangs up in the middle of the night, it can only be called on.
SoNot only does running the database on K8s have no performance problems, its stability even exceeds the capabilities of most operation and maintenance personnel. Moreover, this method is easy to use and self-service. Do you want to use it?
Do not deviate from the actual scene to deny and affirm
When discussing whether a database should be containerized, we must consider different practical use cases.
Some companies' databases are already running very stably in a non-containerized manner, and they don't have enough money to maintain a group of database experts. In such a situation, of course there is no incentive to move the database to K8s. Who will take the blame if problems arise? For example, banks often use specialized Oracle appliances that require a subscription fee, making it difficult to incentivize migration.
However, for many business development teams and organizations, they are now faced with a new choice: Acquire highly specialized database capabilities at a very low cost, thereby transforming the core The team's energy is entirely focused on business development.
To achieve this effect, they can choose to directly use a database cloud service such as RDS (Relational Database Service), or adopt a K8s-based database solution. This approach requires a long-running management process to replace human roles to empower teams that don't understand databases. This is a big trend. Fixed costs (such as the cost of developing a controller) have increased, but marginal costs (the cost of each team using the database) will be significantly reduced.
There are currently many solutions to do this, such as virtual machine-based or Ansible-based, but there is no doubt that K8s-based controllers are currently the optimal solution. Even if you provide services with capabilities similar to RDS, using the k8s technology stack at the bottom is the optimal solution. In comparison, virtual machines are not very powerful, they are heavy, the cost is naturally high, and they consume more performance. And tools like Ansible are even more whimsical when it comes to achieving self-service and multi-tenant support.
Summarize
The importance of K8s
K8s is a big killer. For example, you can exert 10% of Wuyazi's skills. If K8s does not run the database, you can only exert 1% of the power. Proper use of K8s can greatly enhance the efficiency of database operation and maintenance.
Changes in division of labor brought about by technological progress
With the continuous advancement of technology, database managers and users will gradually separate, and traditional manual operations are gradually being replaced by automated procedures. In this process, standardization becomes the cornerstone of effective collaboration. At present, there is no de facto standard that is stronger than container technology and K8s. Therefore, running the database on K8s is the general trend.
Practical cases and benefits
Currently, many teams have successfully implemented K8s in multiple dimensions such as cost, ease of use, stability, and performance, achieved remarkable results, and have tasted the benefits of doing so. It is difficult to go from luxury to frugality. Once an enterprise experiences the benefits brought by K8s, it is difficult to go back to the traditional operation and maintenance method. Take Sealos as an example. From v2 using ansible, to v3 completely switching to golang,it has now developed to v4 and v5. The evolution of this technology is based on The thinking of "cloud computing" and "cloud operating system" rather than the traditional "operation and maintenance script" thinking. Scripts can’t even implement an API. How can you and I talk about advanced productivity? The priority in designing a system is not necessarily for people to use it, but for it to be called by other systems, so that the entire automation can take off. This is why API > CLI > GUI.
The changing role of operations and maintenance
At present, there are still many DBA operation and maintenance personnel in the existing market who want to keep their jobs and are pessimistic about this direction. However, wise decision-makers will sooner or later discover that adopting K8s can significantly reduce labor costs and improve efficiency and system stability. Good birds choose trees to roost in. I hope that many operation and maintenance students will realize that it is a fact that you are gradually being replaced. When we were doing iFlytek, we had an operation and maintenance team of nearly 40 people. After that, even the operation and maintenance group was gone. When we were at Alibaba Cloud, our team also had zero operation and maintenance personnel.
The rapid maturity and ecological development of K8s
K8s is becoming more mature at an extremely fast speed, and the ecosystem is booming, creating short-term chaos and making implementation confusing. But don't worry, excellent distributions will definitely appear. Distributions are doing "entropy reduction" to simplify the user experience, just like the evolution from the Linux kernel to Linux distributions. Sealos is one of them based on K8s. Cloud operating system distribution. I recently visited nearly 200 paid users of Sealos, and none of them reported that the above database cannot be used, and some reported that it was unstable due to several reasons, such as the disk being full, problems caused by upgrades, etc. These problems All were converged, and finally approached 0, which can at least be said to be several 9's more stable than the one built by the user.
Business choice
Whether an enterprise chooses such a solution depends on its actual situation, but smart enterprises will bring great benefits after trying database on K8s. For example, choosing the combination of Sealos + KubeBlocks is equivalent to having:
- A professional K8s team with more than 8 years of experience.
- A P10 leads a top professional database team of P8-9.
- An extremely user-friendly product experience, extremely robust, and extremely high-performance database system.
It doesn’t even cost less to recruit an expert. Of course, there must be resistance to this choice. Most of the resistance comes from those within the company who don't really need it if they want to keep their jobs.
I could have counterattacked Boss Feng's arguments one by one, but I'm still too tired to read and write at the same time. I'm reading these in pieces, hoping to see how many people can have a more advanced understanding, and hope to hear more support. OR Oppose our voices and explore the truth together~