Director of Operations angrily scolded development: Do you really need K8s?

Recently, the editor saw such a question on Zhihu:

Director of Operations angrily scolded development: Do you really need K8s?

Kubernetes continues to attract new users for its automated management and scalability, but it has also been criticized for its complex configuration and high resource consumption, and developers may have asked themselves: Do we really need Kubernetes?

Adhering to the learning attitude of peaceful exchanges, the editor has selected the wonderful answers of several highly praised Zhihu netizens to share with you to learn and exchange (don't rise, don't lead to war):

No. 1 Zhihu netizen: Lin Ying

To put it mildly, many projects, springcloud+k8s, have more than 10 backends and a bunch of servers;

There are not tens of thousands of daily active users, and there are tens of thousands of daily incremental data, that amount, just a few springboot to figure it out, server costs, development costs, how good it is to use it for the market, don't talk to me about decoupling, you just do this concurrency, write a for loop, and you can write select statements in it without jumping.

No. 2 Zhihu netizen: Tai Ku

In the companies I have worked in in the last few years, as soon as I join the company, I basically lead or push for full containerization and K8s, regardless of the size of the business (of course, microservices are a must).

For me, who has been using K8s for 4 years, even if you only have three servers, I will deploy K8s for you.

If you only have one physical machine, I'd love to virtualize three machines and install a K8s (just long).

If you say it's not necessary, my subconscious feeling is that you're definitely not familiar with K8s yet.

Here's a quick explanation of why I'm already inseparable from K8s.

In terms of online costs, various clouds already have clusters that host masters for sale, and you can just buy node, and the cost of a node and an ECS is not much different (the same configuration).

In terms of offline costs, whether you use k8s or not, a server is a must, and this is inevitable anyway.

In terms of server maintenance, compared with traditional corporate servers, virtualization technologies such as ESXi generally use virtualization technologies to allocate physical machines into several virtual machines, but after you use k8s, you can directly use the physical machine as a node of the cluster, eliminating the time and maintenance costs of virtualization, and the newly purchased machine can directly join the resource pool as a node.

In terms of maintenance difficulty, as long as you are proficient in using kubectl, most of your operation and maintenance work can be exempted from SSH.

I want to run an app:

kubectl create deploy xx --image=xxx

I want to make the service externally accessible:

kubectl expose deploy xx --type xx --target-port xx --port xx

My application needs to scale the replica and do the following load balancing:

kubectl scale deploy xx --replicas xx

I want to assign a domain name, forwarding, blacklist and whitelist:

kubectl edit ing ...

For CI/CD, service release updates:

kubectl set image xxx app image=xxx 或 helm upgrade ...

Think back to years ago when you wrote a 300-line shell just to smoothly update a version of an application, K8s still just needs you to kubectl it.

To go a little further, if you have a little development skills, connect with the K8s api, and make the above operations into the UI for development point by bit, you will find that if your company originally has 10 O&M, it may be enough to do two (leave one to eat with the other).

Well, when I wrote this, I re-read the next question, and it was about development...... Then all I can say is that K8s is really awesome......

No. 3 Zhihu netizen: Anonymous friend

We don't have an O&M department, the technical director asked us to only use Docker to deploy it, and after we wrote the Dockerfile, we let the production machine run the image, and SLB went to the reverse proxy. But the container went down for 2 days, and everyone didn't know, or another colleague had nothing to do and looked at the log only to find out that something was wrong. What should I do if I suddenly want to expand in the middle of the night? Pick a machine to deploy a container and manually change it to Nginx/SLB?

Many "directors" don't realize what the cloud is all about, because they don't even know what a CRI container runtime interface like Docker is (not everyone).

In addition to containers and microservices, the core infrastructure of cloud native is container orchestration! Google's 15 years of accumulation, you say you don't need it, you don't need it?

For modern operations departments, back-end architecture departments, mastering Kubernetes is a must-have, because it solves the problem of deploying microservices, and it is already the de facto standard for container orchestration. Don't tell me about Docker Swarm, Docker has given up on itself.

No. 4 Zhihu netizen: Be dead w

I don't know if I should use it, so I shouldn't use it.

After several companies have been working on K8s microservices, the unified experience is that the architecture design is sparse, the microservices are not small, and various infrastructures are missing or no one maintains. Some use K8s as docker-compose, and some are ambitious, which also requires that, but the development and maintenance personnel are counted on one hand.

If you want to get on K8s, it's best to ask yourself, what problem do you want to solve on K8s? Is K8s the best solution? Are you ready to get along with K8s for a long time, and how to migrate the CI/CD automated testing QA release process? And if you want to go microservices, do you have enough people to maintain the infrastructure and migrate the architecture? Have there been leaders who have stepped on the pit and led the team to dismantle services, draw boundaries, and arrange gradual restructuring for you?

On the project from scratch, K8s not only does not need to refactor in the X-Hill code, but also dismantles services, demarcates boundaries, writes documents, and maintains infrastructure.

Unless K8s is still the old way to shuttle, nothing more than replacing docker run with deployment, then K8s is as practical as useless. For example, another respondent said that the service had been down for a few months and no one knew about it. Switching to K8s, no one knows when the pod has been evicted for a few months, no one knows when the node has been hanging for a few months, no one will notice if a node is inexplicably hooked up to taint, or the memory quota is not enough to serve OOM restart, the code is wrong, deadlocked, is anyone paying attention?

Obviously, the problem is not with docker or K8s, and the problem with K8s will only be more, more frequent, and more insidious than when using docker run.

Don't use the K8s as a silver bullet, get back to rationality and think about why you use it and how to use it well.

5 号知乎网友: runzhliu

The focus of Kubernetes is on service orchestration, which is the reason why Kubernetes is really popular, and of course, the idea of doing some architectural innovation based on Kubernetes has never stopped, and there will be more ways to play in the future.

Back to the question, developers who want to use Kubernetes are often brainwashed by the propaganda of the powerful Kubernetes community...... This phenomenon is similar to the popularity of big data frameworks such as Hadoop/Spark ten years ago.

Because many of the published articles publicize these new technologies very highly, and rarely mention the burden of technical management and operation and maintenance brought by these new technologies.

Although it is said that everyone is crossing the river by feeling the stones from 0, but after all, it depends on the reserve of talent ability, which must be achieved through the stock of employees or recruited employees to achieve team building.

Suppose the operation and maintenance director of your company finds a so-called leader who has engaged in K8S (in fact, he only does the work of K8S machine operation and maintenance), and it must be difficult for such a leader to lead the company's containerization work, because in fact, he is only engaged in the process of machine delivery, and is not familiar enough with the internal operation machines, containers, and kernels of K8S. It's hard to expect him to be able to build a container team that's big enough for a large business.

Therefore, in addition to considering the form of the company's business, we must also consider the talent and team reserves, rather than reading a bunch of press releases or sharing and then starting containerization with great interest.

6号知乎网友：RLLvmd

The logic of the development code is problematic and it is easy to terminate the service. The K8s self-healing function automatically restarts the container, restarting it more than 3,000 times in an hour, and the user does not notice the service interruption.

No. 7 Zhihu netizen: Uncle Internet addiction

Last month, in order to optimize costs, all more than 200 nodes were rotated, except for the database nodes and some stateful service nodes, no one else was bothered, a total of 2 days.

This kind of operation is estimated to have to work overtime for several weeks when there is no K8s, and a little carelessness is a P0 failure.

8号知乎网友：Chen Moore

With a total of 3 or 5 EC instances, let alone K8s, I was too troublesome to use the last SpringCloud.

Throwing Nginx in front of the whole SpringBoot is all about the need to use Java for front-end separation.

Really start from 0, this scale

我选择 react / vue + next.js 一把梭。

"Do you really need K8s?" Welcome to communicate in the message area and leave your views~

Organize the dbaplus community

Source丨 zhihu.com/question/430952886/

*It is only for reference and learning exchange, and does not represent the position of the DBAPLUS community! The DBAPLUS community welcomes contributions from technical personnel at [email protected]