非运维学习 kubernetes 的重点是什么？

[keepRun]

我对 k8s 感兴趣，公司也会用这个部署，平时也会接触到一部分 k8s 的东西，于是买了一本《 kubernetes 权威指南》，书挺好就是太厚了，而且考虑到 k8s 整个生态，这书还仅仅是讲基础 k8s 的。

所以我想问下，各位学习 k8s 重点都是放在哪里？

[hancai]

别卷了，留给运维

[julyclyde]

非运维应该学习的是面向容器环境进行应用程序开发的技术

[pslucifer]

k8s 更新的太快了，涉及技术细节的建议看近一两年出版的，你买的那本书可以不看，去看官方文档就行了。
另外我感觉这玩意没有重点，当你能搭建集群、把存储、网络和 ingress 这些搞起来，部署应用，具体就看业务需求了啊

[defunct9]

知道就可以了。container --> pod --> deploy --> svc --> ingress ，就完事了。

[dcoder]

@kennylam777 你到底看懂我的回帖没...
什么叫我只考虑开发的日常, 我说的是 k8s EKS 的 scale 竟这么慢, 竟然影响到了实际业务 -- 竟然需要额外优化!? 我在硅谷这边工作, 不只一个 DevOps 组跟我说过这个问题, 也许是我认识的 DevOps 都很烂. 就你司 DevOps 厉害...

然后, 我说的根本问题 1 2, 你是不是一个没看懂.
"甚麼自己寫 Cluster manager 的出了 AWS 也是一團廢物" -- 做个最简单的 cluster manager 跟 AWS 实现屁关系没有, 只要能通过 VM image 构建 VM 就行. 用不用 AWS/Azure 都没关系. 只能用现成的"主流"工具的人, 是不是完全理解不了...
最简单 stateless computing cluster managing 是 k8s 最常用使用场景, 这个都做不好(竟然需要额外优化!?), 更复杂场景还需要看吗? 地基就是歪的. 你可以在上面加一堆更复杂更全面的功能，但是不能掩盖楼是歪的. 还"处理 BGP", 简单场景都这么费劲... k8s networking 部分几年前我看过一下, shit show 的复杂程度. 费老大劲糊上一堆 legacy 的 protocols... 我怀疑他们设计这块的人没有认真理解最近这些年 SDN(Software Defined Network)的主要成果. 至于你 EBS, NFS 我是看不懂你想说啥. 堆 GPU 搞 LLM 的话, 有些团队/组当然不是用 k8s 的!

对于那种只能用 k8s 的团队/组，我是会用 k8s 的跟他们干活的，但是破玩意儿真的不用浪费时间研究.
对于不用 k8s 的团队/组, 我也很乐意使用/改进他们自己的 infra.
在工作中, 上面两种情况都常见. 不要以为全世界都只会用 k8s @_@

[o562dsRcFqYl375i]

@dcoder 说白了就是这些云厂商联合起来搞个所谓的生态，然后割韭菜

[sampeng]

@dcoder 10 分钟有点扯了。。。我之前千万并发的集群都没啥问题。
可能几个点你们搞错了，1 是 eks 本质还是依靠 ec2 和 vpc 的。可能跨 subnet ，每个 subnet 在不同的可用区。通过内部 nlb 集群通信的时候夸可用区可能有延迟。2 是机器选择上，库存不够，在不停尝试合适的机器起来。开个 support 就能查清楚了。10 分钟肯定是你们运维的锅

[sampeng]

所以楼上说你司的 ops 差不是没道理的。。我们是要承接非洲杯决赛级的瞬间流量。10 分钟，我被开 10 次都够了。

略懂 k8s 的运维都知道，工作节点加入集群就是一个普通的 tcp 操作。除非你是几千个机器的超大集群，这本来其实不应该这么用。虽然官方说支持。但超大节点，etc 和 master 的负担都太大了。纯纯就成了一个单一节点。之前唯品会不就是因为超大节点把 master 搞崩了整个集群都跪了么。

[dcoder]

@huangzongzhuan
Google 看着其它云厂商赚钱太眼红了, 就按照自家的 Borg, 做了个劣质简化的版本: Kubernetes
然后投入大量资源宣发 k8s. Amazon 一看, 开源的啊, 快加入我家 AWS 产品线: 结果 ECS, EKS 就出来了.
然后 AWS 用 k8s 继续挣钱，还省去了宣发费用. Google: ... ...

[dcoder]

@sampeng 我说的是 EC2 VM 起来之后, register 进入 EKS cluster 的时间. 不是 k8s replica scale 的时间(这个很快). 你决赛的瞬时流量不应该依赖这个, 因为启动 VM(甚至是启动物理机器)的是瓶颈. 你瞬时的 busty 流量要抗住的话，得实现至少把底下 VM(or 动物理机器)预先启动起来. 当然, VM register 进入一个 computing cluster 的时间确实应该很快. 不该是 5 分钟，或者 10 分钟这么慢. 所以我说 EKS k8s 慢.

[sampeng]

@dcoder 我明白你说的意思，我说的也是整个启动时间，不会超过 2 分钟。准确的说，从 ec2 启动到容器启动总共要 3 分钟左右。1.5 分钟 tnnd 是 java 的预启动太慢，只能看着。之前我上 eks 也担心和你一样的问题，结果一看还好。基本只要提前 5 分钟开始伸缩问题就不大。

阿里云同理，基本整个时间不会超过 3 分钟。时间花费反而在容器自己慢。你们运维绝对有锅。。这么慢，是我老早开 support 找 aws/阿里云麻烦去了。

[sampeng]

我不是没碰到过启动慢，都是我自己配错了。比如配置的是新机器替换旧机器。比如配置的 autoscalegroup 里面只给了一个机器，这个机器还没什么库存了。再比如 auto scale group 里面也有一个配置，伸缩等待时间，默认 1 分钟还是 5 分钟（忘了，最近运维的是阿里云）才开始启动机器。。。

所以楼上说的没错，这种事得扔给运维去解决。。专业的人干专业的事。

[dcoder]

@sampeng
刚刚问了负责的 DevOps, 说优化到 6 分钟了, 他们还在搞. 我作为 dev 不想搞 ops 事情, 只是用起来偶尔非常闹心...
按照你提前 3~5 分钟的说法, 所以最后能优化到 3 分钟上下. 但是我还是觉得好慢. 因为我们始终是在讨论分钟级别的延迟, 实际上, 广义上看, 如果底层实现够优化的话, 应该是秒级别的事情. 不知道底层在干啥, 需要达到分钟级别... @_@

[sampeng]

@dcoder 还是要看需求。aws 的 fagrate 确实是秒级启动。但还有后续的动作。拉镜像这个事跑不掉，就算内网，最快要几秒。运维是一个系统性的事。快不一定好，不仅仅是 vm 启动，还要涉及安全，日志，监控等等配套设施。需要极致的秒启动，fagrate 是第一解。第二解 aws 也有解决方案，冷服务组。就是一堆 vm 提前加入到集群，但是不工作。然后需要的时候编排过去。这需要有一定的开发工作。

作为 dev 确实会不理解 ops 的事，明明很简单，为什么要搞那么多。很简单：dev 你别给我整微服务就行。。哈哈哈哈哈

[dcoder]

@sampeng 一层层的 pull docker image 的 binary data 应该是最慢的部分, 回到我 19 楼说的基本问题上，这个在 k8s+docker 生态里是难以解决的. 另外, 你说的安全部分也可以搞得特别慢, 如果公司在这方面龟毛的话, 龟毛的安全要+k8s 那就是更加的慢.

[yyttrr]

从运维的角度来说，希望研发懂一些，比如 pod 的生命周期，有状态无状态 update 时候的不同之类的

但是研发也没必要懂很多，尤其是现在公有云上的 k8s 和其他云产品的配合使用，不同云之间差别还是不小的，研发的经历没必要投入到这方面

[mightybruce]

楼上真的是一个典型，dev 不懂 ops ，ops 不懂 dev, 最后都认为是 k8s 的问题。

[dcoder]

从 k8s 开始宣传画的饼, k8s 自己的复杂度, k8s 的运行效率.
作为 dev, 对于其他 dev, 我想说: k8s 真的不行, 研究 k8s 没有性价比, 浪费时间. 省省精力研究点有用的.
多的不说了, 最后说一句: 不浪费智力, 去研究没有性价比的技术, 是 dev 需要的智慧.

[isno]

愣是没看懂你们到底在讨论啥。

[jasei]

karpenter 不香吗