What are the advantages of running TiDB on a K8S cluster?

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: K8S集群上跑TiDB有什么优势?

| username: 江湖故人

Is anyone using K8S to run TiDB in a production environment?
TiDB clusters already have disaster recovery and online scaling capabilities, so why use K8S?

| username: zhanggame1 | Original post link

No advantage, not recommended.

| username: Kongdom | Original post link

Teacher Xiaolei believes that the advantages of database containerization are twofold. First, cost reduction and efficiency improvement. Currently, the resource utilization rate of some of our clusters may not be very sufficient, leading to wasted CPU or memory. By using a K8s cluster to collect these resources into a resource pool and deploying TiDB through TiDB Operator, we can allocate the corresponding resources, achieving more reasonable resource allocation and centralized management, thereby saving resource costs. Second, resource isolation. K8s provides an excellent model for resource isolation. If we can use K8s’s cluster management model to achieve resource isolation, it would also be a very good usage condition.

You can check out these columns for more details :yum:

| username: 小龙虾爱大龙虾 | Original post link

In production, there are instances running on k8s, mainly to reduce costs and increase efficiency. It is suitable for less important systems and systems with low traffic.

| username: forever | Original post link

I remember there was an introduction from Meituan, which runs on k8s.

| username: yiduoyunQ | Original post link

TiDB Cloud runs on AWS EKS and Google GKE.

| username: Jellybean | Original post link

Containerized management allows for full utilization of machine resources, enabling different businesses to use hardware facilities at different times, squeezing out the last bit of remaining value.

However, unless you have a professional operations team specializing in K8S, it is not recommended to deploy a TiDB cluster on it. Additionally, compared to bare-metal deployment, performance may degrade by approximately 10%-30% (the exact value can only be determined through specific business testing).

| username: TIDB-Learner | Original post link

One cannot simply discuss good or bad; every product and tool has its advantages and optimizations. Improving upon what is already good. K8S, a product from major companies.

| username: 像风一样的男子 | Original post link

From my personal perspective, it has no advantages and greatly reduces database performance. Too few people use it, requiring a specialized k8s operations team, which may result in higher actual costs. If the system encounters problems, it is difficult to find someone to help resolve them.

| username: wfxxh | Original post link

Testing is okay, but not very practical for production.

| username: buddyyuan | Original post link

Some unimportant systems can be moved up to save resources. When a component crashes, the startup speed is particularly fast, and it will pull up another pod in about 1 second.

| username: dba远航 | Original post link

It depends on your usage, it’s equivalent to hardware fault tolerance plus software fault tolerance.

| username: andone | Original post link

It is recommended not to run in production on k8s.

| username: 数据小黑 | Original post link

I have seen deployments on k8s for easier management. Some enterprises create many small TiDB clusters (although this approach is also debatable) and deploy them on k8s for easier management. k8s also provides elasticity, allowing TiDB servers to automatically recover to their original state in the event of a single node failure, without intrusion or manual intervention, as long as there are remaining resources. This has a significant advantage in a pay-as-you-go scenario on public clouds.

| username: kelvin | Original post link

It’s better to run on physical machines in an actual production environment.

| username: ShawnYan | Original post link

You can run it in the development environment. If you have a bunch of development environments to manage and often need to rebuild and destroy them.

| username: tidb菜鸟一只 | Original post link

If you are proficient in k8s, you can give it a try. It facilitates resource expansion and elastic scaling.

| username: forever | Original post link

Time to master a new technology again :grin:

| username: Miracle | Original post link

As a deep user, I can briefly explain:
Advantages: Better hardware resource management, ability to control individual CPU and memory, easy scaling, self-healing, automatic restart on exceptions, etc.
Disadvantages: Higher maintenance costs, strong dependency on K8S, instability in K8S means instability in TiDB. Performance issues. Node de-scaling issues.

| username: 江湖故人 | Original post link

There are always imperfections with software isolation, right? In the financial industry, many operations require mandatory physical isolation. :thinking: