mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
geekpi
GitHub
commit
082db2fa97
@ -1,76 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (beamrolling)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (You (probably) don't need Kubernetes)
|
||||
[#]: via: (https://arp242.net/weblog/dont-need-k8s.html)
|
||||
[#]: author: (Martin Tournoij https://arp242.net/)
|
||||
|
||||
You (probably) don't need Kubernetes
|
||||
======
|
||||
|
||||
This may perhaps be an unpopular opinion, but the overwhelming majority of companies are probably better off not using k8s.
|
||||
|
||||
You know those old “Hello world according to programmer skill” jokes that start with `printf("hello, world\n")` for a junior programmer and end with some convoluted Java OOP design pattern solution for senior software architect engineer? This is kind of like that.
|
||||
|
||||
* Junior sysops
|
||||
`./binary`
|
||||
* Experienced sysops
|
||||
`./binary` on EC2.
|
||||
* devops
|
||||
Self-deployed CI pipeline to run `./binary` on EC2.
|
||||
* Senior cloud orchestration engineer
|
||||
k8s orchestrated self-deployed CI pipeline to run `./binary` on E2C platform.
|
||||
|
||||
|
||||
|
||||
¯\\_(ツ)_/¯
|
||||
|
||||
That doesn’t mean that Kubernetes or any of these things are bad per se, just as Java or OOP aren’t bad per se, but rather that they’re horribly misapplied in many cases, just as using several Java OOP design patterns are horribly misapplied to a hello world program. For most companies the sysops requirements are fundamentally not very complex, and applying k8s to them makes litle sense.
|
||||
|
||||
Complexity creates work by its very nature, and I’m skeptical that using k8s is a time-saver for most users. It’s like spending a day on a script to automate some 10-minute task that you do once a month. That’s not a good time investment (especially since the chances are you’ll have to invest further time in the future by expanding or debugging that script at some point).
|
||||
|
||||
Your deployments probably should be automated – lest you [end up like Knightmare][1] – but k8s can often be replaced by a simple shell script.
|
||||
|
||||
In our own company the sysops team spent a lot of time setting up k8s. They also had to spend a lot of time on updating to a newer version a while ago (1.6 ➙ 1.8). And the result is something no one really understands without really diving in to k8s, and even then it’s hard (those YAML files, yikes!)
|
||||
|
||||
Before I could debug and fix deploy issues myself. Now that’s a lot harder. I understand the basic concepts, but that’s not all that useful when actually debugging practical issues. I don’t deal with k8s often enough to justify learning this.
|
||||
|
||||
That k8s is really hard is not a novel insight, which is why there are a host of “k8s made easy” solutions out there. The idea of adding another layer on top of k8s to “make it easier” strikes me as, ehh, unwise. It’s not like that complexity disappears; you’ve just hidden it.
|
||||
|
||||
I have said this many times before: when determining if something is “easy” then my prime concern is not how easy something is to write, but how easy something is to debug when things fail. Wrapping k8s will not make things easier to debug, quite the opposite: it will make it even harder.
|
||||
|
||||
There is a famous Blaise Pascal quote:
|
||||
|
||||
> All human evil comes from a single cause, man’s inability to sit still in a room.
|
||||
|
||||
k8s – and to lesser extent, Docker – seem to be an example of that. A lot of people seem lost in the excitement of the moment and are “k8s al the things!”, just as some people were lost in the excitement when Java OOP was new, so everything has to be converted from the “old” way to the “new” ones, even though the “old” ways still worked fine.
|
||||
|
||||
Sometimes the IT industry is pretty silly.
|
||||
|
||||
Or to summarize this post [with a Tweet][2]:
|
||||
|
||||
> 2014 - We must adopt #microservices to solve all problems with monoliths
|
||||
> 2016 - We must adopt #docker to solve all problems with microservices
|
||||
> 2018 - We must adopt #kubernetes to solve all problems with docker
|
||||
|
||||
You can mail me at [martin@arp242.net][3] or [create a GitHub issue][4] for feedback, questions, etc.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://arp242.net/weblog/dont-need-k8s.html
|
||||
|
||||
作者：[Martin Tournoij][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://arp242.net/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/
|
||||
[2]: https://twitter.com/sahrizv/status/1018184792611827712
|
||||
[3]: mailto:martin@arp242.net
|
||||
[4]: https://github.com/Carpetsmoker/arp242.net/issues/new
|
||||
@ -0,0 +1,76 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (beamrolling)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (You (probably) don't need Kubernetes)
|
||||
[#]: via: (https://arp242.net/weblog/dont-need-k8s.html)
|
||||
[#]: author: (Martin Tournoij https://arp242.net/)
|
||||
|
||||
你（大概）不需要 Kubernetes
|
||||
======
|
||||
|
||||
这也许是一个不太受欢迎的观点，但大多数主流公司最好不要再使用 k8s 了。
|
||||
|
||||
你知道那个古老的“根据程序员技能写 Hello world ”笑话吗？它从一个新手程序员的 printf("hello, world\n") 语句开始，最后结束于高级软件架构工程师令人费解的 Java OOP 模式设计。使用 k8s 就有点像这样。
|
||||
|
||||
* 新手 SysOp：
|
||||
`./binary`
|
||||
* 有经验的 SysOp：
|
||||
在 EC2 上的 `./binary`
|
||||
* DevOp：
|
||||
在 EC2 上自部署的 CI 管道运行 `./binary`
|
||||
* 高级云编排工程师：
|
||||
在 EC2 上通过 k8s 编排的自部署 CI 管道运行 `./binary`
|
||||
|
||||
|
||||
|
||||
¯\\_(ツ)_/¯
|
||||
|
||||
这不意味着 Kubernetes 或者任何这样的东西本身都是坏的，就像 Java 或者 OOP 设计本身并不是坏的一样，但是，在很多情况下，它们被严重地误用，就像在一个 hello world 的程序中可怕地误用 Java 面向对象设计模式一样。对大多数公司而言，系统运维从根本上来说并不十分复杂，此时在这上面应用 k8s 起效甚微。
|
||||
|
||||
复杂性本质上来说创造了工作，我十分怀疑使用 k8s 对大多数使用者来说是省时的这一说法。这就好像花一天时间来写一个脚本，用来自动完成一些你一个月一次，每次只花 10 分钟完成的工作。这不是一个好的时间投资（特别是你可能会在未来由于扩展或调试这个脚本来进一步投入更多的时间）。
|
||||
|
||||
你的部署大概应该需要自动化 – 以免你 [最终像 Knightmare][1] 那样 – 但 k8s 通常可以被一个简单的 shell 脚本所替代。
|
||||
|
||||
在我们公司，sysops 团队用了很多时间来设置 k8s 。他们还不得不用了很大一部分时间来更新到新一点的版本（1.6 – 1.8）。结果是如果没有真正深入理解 k8s ，没人会真正明白一些东西，甚至连深入理解 k8s 这一点也很难（那些 YAML 文件，哦呦！）
|
||||
|
||||
在我能自己调试和修复问题之前——现在这更难了，我理解基本概念，但在真正调试实际问题的时候，它们并不是那么有用。我不经常用 k8s 足以证明这点。
|
||||
|
||||
k8s 真的很难这点并不是什么新看法，这也是为什么现在会有这么多“ k8s 简单学”的解决方案。在 k8s 上再添一层来“让它更简单”的方法让我觉得，呃，不明智。复杂性并没有消失，你只是把它藏起来了。
|
||||
|
||||
以前我说过很多次：在确定一样东西是否“简单”时，我最关心的不是写东西的时候有多简单，而是当失败的时候调试起来有多容易。包装 k8s 并不会让调试更加简单，恰恰相反，它让事情更加困难了。
|
||||
|
||||
Blaise Pascal 有一句名言：
|
||||
|
||||
> 几乎所有的痛苦都来自于我们不善于在房间里独处。
|
||||
|
||||
k8s —— 略微拓展一下，Docker ——似乎就是这样的例子。许多人似乎迷失在当下的兴奋中，觉得“ k8s 就是这么回事！”，就像有些人迷失在 Java OOP 刚出来时的兴奋中一样，所以一切都必须从“旧”方法转为“新”方法，即使“旧”方法依然可行。
|
||||
|
||||
有时候 IT 产业挺蠢的。
|
||||
|
||||
或者用 [一条推特][2] 来总结:
|
||||
|
||||
> 2014 - 我们必须采用 #微服务 来解决 monolith 的所有问题
|
||||
> 2016 - 我们必须采用 #docker 来解决微服务的所有问题
|
||||
> 2018 - 我们必须采用 #kubernetes 来解决 docker 的所有问题
|
||||
|
||||
你可以通过 [martin@arp242.net][3] 给我发邮件或者 [创建 GitHub issue][4] 来给我反馈或提出问题等。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://arp242.net/weblog/dont-need-k8s.html
|
||||
|
||||
作者：[Martin Tournoij][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[beamrolling](https://github.com/beamrolling)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://arp242.net/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/
|
||||
[2]: https://twitter.com/sahrizv/status/1018184792611827712
|
||||
[3]: mailto:martin@arp242.net
|
||||
[4]: https://github.com/Carpetsmoker/arp242.net/issues/new
|
||||
Loading…
Reference in New Issue
Block a user