Kube.NETes 以其自动化管理与可扩展性等优点不断吸引着新用户，然而，它的配置复杂与资源消耗高等特点也一直被诟病，开发人员或许都曾扪心自问：我们真的需要 Kubernetes 吗？
秉持着和平交流的学习态度，小编精选了几位高赞知乎网友的精彩回答，分享给大家学习交流（勿上升、勿引战）：
1号知乎网友：林英
说句难听点的，很多项目，springcloud+k8s，整了10几个后端，一堆服务器；
日活都没上万，日增数据就万条，那点量，整几个springboot 弄弄就行，服务器费用，开发费用一砍，拿来做市场多好，别和我谈解耦，你就这点并发，写个 for 循环，里面可劲写 select 语句都不会蹦。
2号知乎网友：泰酷啦
我最近几年待过的公司，我只要一进公司，基本上都是主导或力推全面容器化、K8s 化，不论业务体量（当然，微服务是必须的）。
对于连续用了4年 K8s 的我来说，哪怕你只有三台服务器，我也要给你部署 K8s。
如果你只有一台物理机，我恨不得给你虚拟化三台机器出来再装个 K8s（只是恨不得而已）。
如果你说没必要，我下意识的感觉就是你肯定还不熟悉K8s。
下面简单说一下我已经离不开 K8s 的理由。
从线上费用来讲，各种云已经有托管 master 的集群在售，你直接买 node 就行，一个 node 和 一个 ecs 的费用相差也不大（同等配置）。
从线下费用来讲，不管你用不用 k8s，服务器是必须的吧，这个无论如何免不了。
从服务器维护来讲，相对传统的公司服务器一般会用 esxi 等虚拟化技术将物理机分配成若干个虚拟机，而你用了 k8s 之后，你直接可以将物理机作为集群的一个 node，免去虚拟化的时间和维护成本，新购机器直接作为 node 加入资源池。
从维护难度来讲，你只要能熟练使用 kubectl，你的大部分运维工作都可以免去 ssh 这个操作了。
我要运行一个应用：
kubectl create deploy xx --image=xxx
我要让服务可以外部访问：
kubectl expose deploy xx --type xx --target-port xx --port xx
我的应用要扩展一下副本，做下负载均衡：
kubectl scale deploy xx --replicas xx
我要配下域名、转发、黑白名单：
kubectl edit ing ...
对于CI/CD、服务发布更新：
kubectl set image xxx App image=xxx 或 helm upgrade ...
回想一下多年以前你写了一个 300 行的 Shell 只为所谓的平滑更新一个应用的版本，K8s 依然只要你 kubectl 一下。
再进阶一点，你如果稍具开发技能，对接一下 K8s 的 api，把上面的这些操作做到 UI 让开发点点点，你会发现，如果你公司本来有 10 个运维，这么一搞可能两个就够了（留一个陪另一个吃饭）。
额，写到这里的时候重新看了下题，是对开发来讲的哈……那我只能说，K8s 真的牛……
3号知乎网友：匿名好友
我司都没有运维部门，技术总监让我们只用 Docker 来部署一下，我们写好 Dockerfile 之后让生产机器让跑镜像，SLB 去反向代理。但容器 down 了 2 天大家都不知道，还是另一个同事闲的没事做看看日志才发现不对劲。半夜突然要扩容了怎么做？随手挑一台机器去部署容器然后手动改 Nginx/SLB ？
很多「总监」意识不到上云到底上的啥，毕竟它们连 Docker 这种 CRI 容器运行时接口是什么都没有搞清楚（不是所有人）。
云原生除了容器、微服务之外，核心的基础设施就是容器编排！google 15 年的积累你说不需要就不需要？
现代运维部门、后端的架构部门，掌握 Kubernetes 已经是必备的了，因为它解决了微服务的部署问题，而且已然是容器编排的事实标准。别和我说 Docker Swarm，Docker 公司自己都放弃了。
4号知乎网友：作死w
不知道该不该用，那就不该用。
前后干了几家公司上 K8s 微服务了，统一的体验就是架构设计稀烂，微服务不微，各种基础设施缺失或者没人维护。有的是把 K8s 当 docker-compose 用，有的是野心很大，这也要那也要，但开发维护的人手一只手数的过来。
想上 K8s 最好问问自己，上 K8s 想解决啥问题？K8s是不是最佳解决方案？做好长期和 K8s 相处的准备了吗，CI/CD 自动测试 QA 发布流程怎么迁移？以及想上微服务的，有足够的人手维护基础设施和迁移架构吗？有踩过坑带过队的领导，给你们拆服务、划边界、安排渐进重构吗？
从零开始的项目上 K8s 除了不用在x山代码里重构之外，拆服务划边界写文档还有基础设施维护等等细碎而且让人头大的工作，都是要跟老板要人力的。
除非上 K8s 还是老办法一把梭，无非把 docker run 换成 deployment，那这 K8s 其实用了就跟没用一样。像是另一位答主说服务 down了几个月没人知道。换到K8s上，Pod 不知道啥时候 evicted 了几个月也一样没人知道，节点啥时候挂了几个月也没人知道，某台节点莫名其妙挂上了 tAInt 也不会有人注意，又或者内存配额不够服务OOM重启了，代码报错了，死锁了，难道就有人注意了吗。
问题显然不是出在用 docker 还是 K8s，换 K8s 出的问题只会比用 docker run 直接跑的时候更多、更频繁、更隐蔽。
别把 K8s 当银弹，回归理性，好好想想为什么去用它，怎么用好它。
5号知乎网友：runzhliu
Kubernetes 的重点在于服务编排，这个才是 Kubernetes 真正流行的原因，当然基于 Kubernetes 上做一些架构的创新的想法一直都没停止过，未来会有更多的玩法。
回到问题，开发同学想用 Kubernetes 经常都是被 Kubernetes 强大的社区的宣传所洗脑……这个现象跟十年前 Hadoop/Spark 为代表的大数据框架开始流行很像。
因为很多宣发的文章都把这些新技术宣传的非常高大上，而比较少会提到这些新技术带来的技术管理和运维上的负担。
虽然说大家都是从0开始摸着石头过河的，但是能过河终究要看人才能力上的储备，这就要通过存量的员工或者招聘来的员工来实现团队的建设了。
假设你公司的运维总监找来一个所谓搞过 K8S 的 Leader（实际只是做 K8S 机器运维的工作），要让这样的 Leader 带领公司的容器化工作，肯定是吃苦头的，因为实际他只是搞了机器交付的环节，对 K8S 内部的运作机器、容器、内核都不够熟悉，那么在招聘人才的时候，也经常会走漏眼，毕竟他自己都不懂，很难指望他能够建立一个足以应付大型业务的容器团队。
所以关于到底用不用，除了要考虑公司业务的形态，还得考虑人才和团队储备，而不是看了一堆通稿或者分享之后就兴致勃勃开始容器化。
6号知乎网友：RLLvmd
开发代码逻辑有问题，容易服务终止。K8s 自愈功能自动重启容器，一小时重启三千多次，硬生生扛下了所有，用户没发现服务中断。
7号知乎网友：网瘾大爷
上个月为了成本优化，把全部200多个节点都轮转了一遍，除了数据库节点和一些有状态服务节点，没麻烦其他人，总计2天。
这种操作在没有 K8s 的时候估计得加班搞几周，稍微不小心就是个P0故障。
8号知乎网友：Chen Moore
一共3、5台EC实例的规模你别说K8s了，上个SpringCloud 我都嫌麻烦。
整个 SpringBoot 前面扔个 Nginx 完事，这还是建立在必须得前后端分离用 JAVA 的基础上。
真要从0开始，这点规模
我选择 react / vue + next.js 一把梭。
"你真的需要 K8s 吗？"欢迎在留言区交流，留下你的观点~
整理丨dbaplus社群
来源丨zhihu.com/question/430952886/
