这是一个创建于 48 天前的主题，其中的信息可能已经有所发展或是发生改变。
我对 k8s 感兴趣，公司也会用这个部署，平时也会接触到一部分 k8s 的东西，于是买了一本《 kubernetes 权威指南》，书挺好就是太厚了，而且考虑到 k8s 整个生态，这书还仅仅是讲基础 k8s 的。
所以我想问下，各位学习 k8s 重点都是放在哪里？
41 条回复 • 2024-03-12 01:01:05 +08:00
 |
1
hkdcl 48 天前 via Android
学个屁。会用 docker 就不错了
|
 |
2
keepRun OP @hkdcl docker 已经会了，基本就是 docker compose 、swarm 一把梭，不过公司里一般还是用 k8s ，特意搞了个 docker desktop 开启 kubernetes 来练练手
|
 |
4
momo24672 48 天前
1 Package docker image and push the image to private registry
2 Understand K8s Deployment, configMap, secrets and service, run the images in k8s (Helm or Kustomize) 3 Try ingress or gateway, expose the service to the public 4 Write the graceful exit, rolling update the service with zero downtime 5 Explore istio service mesh .... |
|
6
keepRun OP 周末玩了下 istio ，顿时感觉这玩意控制流量的能力太强了
|
 |
7
lasuar 48 天前  1
看看 https://github.com/chaseSpace/k8s-tutorial-cn 能否帮助到你，我正在更新的《 Kubernetes 实战指导》的最新章节也是 istio 。
|
 |
8
dcoder 48 天前
docker + k8s 这帮人, 设计这么一大坨复杂玩意, 面相 yaml 编程, 折腾半天, 只能做个 stateless computing cluster. scale 的速度居然还奇慢... 上周公司开会，讨论说往 AWS EKS cluster 加个 EC2 node 要 10 分钟以上, 我都听懵逼了, 我说 EC2 instance 启动瓶颈不是 2 分钟上下吗? DevOps 说是的, 但是 EC2 node 起来后, 往 EKS cluster 里注册非常慢. 我上网搜了下, 确实要加个 EC2 node 要 10 分钟上下... 好烂, 我真的惊了...
所以工作需要的话, 会用常用命令行就行. "研究" 这坨"主流"并"流行"的垃圾, 属于浪费时间. |
 |
11
mahone3297 48 天前
@dcoder 注册时要时间，你要觉得慢，可以用 ECI 虚拟节点，启动很快，秒级还是毫秒级，有点忘了
k8s 的优势是 scale 的一整套功能，包括 scale out ，注册，负载均衡等。。。 如果不用 K8s ，用什么？ docker swarm ？ docker swarm 算是和 k8s 同一种产品，不算。 那么不用 docker swarm ，那你就要自己实现这一整套 scale out 的功能，那就相当于你实现了一个 k8s |
|
13
keepRun OP @mahone3297 docker swarm 功能还是太弱了，除了 k8s ，其它的替代品都比较原始，k8s 主要问题就是有点复杂
|
|
14
lasuar 47 天前
@keepRun #12 学习方法的话，以我个人方式概括起来就是：
- 以相关权威书籍作为核心，最好找到 2 本+，帮助建立这个知识概念的主框架； - 以官网文档作为辅助，补齐一些书中未提到的细节； - 以互联网上有经验之人写的踩坑&总结文章为辅助，吸取他们的实践经验； - 以源码为辅助，获取部分核心术语&逻辑的根本实现，真正达到拨云见雾，见证真章的程度； 以上供参考，确实比较花时间的，需要感到兴趣才能完整实践。 |
 |
15
emSaVya 47 天前
5 年前学 k8s 比较准点。现在再学晚很多了。有点规模的公司 k8s 集群都搭建的七七八八稳定运行了。已经进入基建完善裁人阶段。
|
 |
16
mightybruce 47 天前
这贴充分暴露了 V2EX 上不少程序员的水平
kuberenetes 不是 docker, 没有那么快很上手的。 我建议你先学会操作 kubenetes 基础操作和 kubernetes 的各种资源以及概念 基于 kubernetes 的 部署 调试 和微服务，代码改造。 一步一步学习，一定要动手。 |
|
17
mightybruce 47 天前
另外我强调一点 Kubernetes 不是运维需要学习的， 高级一点的业务开发和基础设施开发都是必须要会。上来不要看源码，
docker 和 kuberneets 是两回事，kubernetes 基本不带 docker 玩耍了 一堆人学不明白，麻烦就不要瞎说了。 先实操完了，在搞 Kubernetes 开发，最后结合开发看源码实现。 |
 |
18
xianzhe 47 天前
kubernetes in action 这本书，由翻译版，不过稍微老了些，但是用来入门 k8s 真的很不错，看前面几张学会 k8s 里面的概念
|
|
19
dcoder 47 天前
注册 5 分钟也够慢的了... 启动个 EC2 VM 都只需要 1~2 分钟. 这个只能是 k8s 的设计问题, 没得救了.
为啥注册个 VM 还需要额外再加个"ECI 虚拟节点"来加速... docker+k8s 我上班天天用，自己做项目是绝对不会用的. 我只简单说下这套东西为啥是复杂的工业垃圾: 1. 各个新老语言的 package/dependency/build 工具进步了, 可以在 dependency hash 层面实现 reproducible build. 根 本不需要用 docker 做那种非常重非常笨非常慢的 binary 级别的 reproducible build. 2. docker 本来应该被淘汰的, k8s 基于 docker 所以会继承 docker 的低效, 但是没想到会这么低效. 如果只是实现 stateless computing cluster 这么简单的东西, 你自己写个 cluster manager 就实现了. 那么对于一个 running cluster, new VM registering 就应该是秒级的速度 -- 我 10 年前就写过这样的东西, 在 AWS 上管理几十个 EC2 VMs. 不要轻易说 "那就相当于你实现了一个 k8s", k8s 的情况属于: 拥有大量宣发资源的人, 忽悠出的"主流"技术栈, 最终点错了科技树的情况. |
 |
20
kennylam777 47 天前 2
@dcoder 你考慮的只是開發的日常, 但是真正有規模的系統, 不是單單講求你個人認為的 building processing 有多快, 重點是你熟識的工具, 還是得讓其他人 reproduce 一次。如果是常用的步驟, Docker 加速的方法多的是, 可能是你家 DevOps 太垃圾。
自己寫 Cluster manager 也笑了, k8s 主要能力是通用度, 不管在哪個 Cloud 都是一樣的作法。而且甚麼自己寫 Cluster manager 的出了 AWS 也是一團廢物, 請問一下的 cluster manager 能處理 BGP 嗎?Layer 2 不通只能用 Layer 3 的網絡上能通嗎? Persistent Volume 當你能調用 EBS 而不是 local storage 好了, 能加上 NFS 嗎? 還有 GPU 需要同時分配 nVidia 及 Intel 的方案也請解決一下, 自己寫 GPU manager 喔? 人家就是有全套的解決方案, 對 scaling 速度有要求的更可以不用 AWS EKS 去玩自建的, 整個 Eco system 就擺著任你用。 不肯合作, 自吹自擂的單打獨鬥派, 任你說得自己的方案多好, 沒人跟你用就是了。 |
 |
21
hancai 47 天前
别卷了，留给运维
|
 |
22
julyclyde 47 天前
非运维应该学习的是面向容器环境进行应用程序开发的技术
|
 |
23
pslucifer 47 天前
k8s 更新的太快了，涉及技术细节的建议看近一两年出版的，你买的那本书可以不看，去看官方文档就行了。
另外我感觉这玩意没有重点，当你能搭建集群、把存储、网络和 ingress 这些搞起来，部署应用，具体就看业务需求了啊 |
 |
24
defunct9 47 天前
知道就可以了。container --> pod --> deploy --> svc --> ingress ，就完事了。
|
|
25
dcoder 47 天前
@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 @_@ |
 |
26
huangzongzhuan 47 天前
@dcoder 说白了就是这些云厂商联合起来搞个所谓的生态，然后割韭菜
|
 |
27
sampeng 47 天前
@dcoder 10 分钟有点扯了。。。我之前千万并发的集群都没啥问题。
可能几个点你们搞错了，1 是 eks 本质还是依靠 ec2 和 vpc 的。可能跨 subnet ，每个 subnet 在不同的可用区。通过内部 nlb 集群通信的时候夸可用区可能有延迟。2 是机器选择上，库存不够，在不停尝试合适的机器起来。开个 support 就能查清楚了。10 分钟肯定是你们运维的锅 |
|
28
sampeng 47 天前
所以楼上说你司的 ops 差不是没道理的。。我们是要承接非洲杯决赛级的瞬间流量。10 分钟，我被开 10 次都够了。
略懂 k8s 的运维都知道，工作节点加入集群就是一个普通的 tcp 操作。除非你是几千个机器的超大集群，这本来其实不应该这么用。虽然官方说支持。但超大节点，etc 和 master 的负担都太大了。纯纯就成了一个单一节点。之前唯品会不就是因为超大节点把 master 搞崩了整个集群都跪了么。 |
|
29
dcoder 47 天前 1
@huangzongzhuan
Google 看着其它云厂商赚钱太眼红了, 就按照自家的 Borg, 做了个劣质简化的版本: Kubernetes 然后投入大量资源宣发 k8s. Amazon 一看, 开源的啊, 快加入我家 AWS 产品线: 结果 ECS, EKS 就出来了. 然后 AWS 用 k8s 继续挣钱，还省去了宣发费用. Google: ... ... |
|
30
dcoder 47 天前
@sampeng 我说的是 EC2 VM 起来之后, register 进入 EKS cluster 的时间. 不是 k8s replica scale 的时间(这个很快). 你决赛的瞬时流量不应该依赖这个, 因为启动 VM(甚至是启动物理机器)的是瓶颈. 你瞬时的 busty 流量要抗住的话，得实现至少把底下 VM(or 动物理机器)预先启动起来. 当然, VM register 进入一个 computing cluster 的时间确实应该很快. 不该是 5 分钟，或者 10 分钟这么慢. 所以我说 EKS k8s 慢.
|
|
31
sampeng 47 天前
@dcoder 我明白你说的意思，我说的也是整个启动时间，不会超过 2 分钟。准确的说，从 ec2 启动到容器启动总共要 3 分钟左右。1.5 分钟 tnnd 是 java 的预启动太慢，只能看着。之前我上 eks 也担心和你一样的问题，结果一看还好。基本只要提前 5 分钟开始伸缩问题就不大。
阿里云同理，基本整个时间不会超过 3 分钟。时间花费反而在容器自己慢。你们运维绝对有锅。。这么慢，是我老早开 support 找 aws/阿里云麻烦去了。 |
|
32
sampeng 47 天前 1
我不是没碰到过启动慢，都是我自己配错了。比如配置的是新机器替换旧机器。比如配置的 autoscalegroup 里面只给了一个机器，这个机器还没什么库存了。再比如 auto scale group 里面也有一个配置，伸缩等待时间，默认 1 分钟还是 5 分钟（忘了，最近运维的是阿里云）才开始启动机器。。。
所以楼上说的没错，这种事得扔给运维去解决。。专业的人干专业的事。 |
|
33
dcoder 47 天前
|
|
34
sampeng 47 天前
@dcoder 还是要看需求。aws 的 fagrate 确实是秒级启动。但还有后续的动作。拉镜像这个事跑不掉，就算内网，最快要几秒。运维是一个系统性的事。快不一定好，不仅仅是 vm 启动，还要涉及安全，日志，监控等等配套设施。需要极致的秒启动，fagrate 是第一解。第二解 aws 也有解决方案，冷服务组。就是一堆 vm 提前加入到集群，但是不工作。然后需要的时候编排过去。这需要有一定的开发工作。
作为 dev 确实会不理解 ops 的事，明明很简单，为什么要搞那么多。很简单：dev 你别给我整微服务就行。。哈哈哈哈哈 |
|
35
dcoder 47 天前
@sampeng 一层层的 pull docker image 的 binary data 应该是最慢的部分, 回到我 19 楼说的基本问题上，这个在 k8s+docker 生态里是难以解决的. 另外, 你说的安全部分也可以搞得特别慢, 如果公司在这方面龟毛的话, 龟毛的安全要+k8s 那就是更加的慢.
|
 |
36
yyttrr 47 天前
从运维的角度来说，希望研发懂一些，比如 pod 的生命周期，有状态无状态 update 时候的不同之类的
但是研发也没必要懂很多，尤其是现在公有云上的 k8s 和其他云产品的配合使用，不同云之间差别还是不小的，研发的经历没必要投入到这方面 |
|
37
mightybruce 47 天前 1
楼上真的是一个典型，dev 不懂 ops ，ops 不懂 dev, 最后都认为是 k8s 的问题。
|
|
38
dcoder 47 天前
从 k8s 开始宣传画的饼, k8s 自己的复杂度, k8s 的运行效率.
作为 dev, 对于其他 dev, 我想说: k8s 真的不行, 研究 k8s 没有性价比, 浪费时间. 省省精力研究点有用的. 多的不说了, 最后说一句: 不浪费智力, 去研究没有性价比的技术, 是 dev 需要的智慧. |
 |
39
isno 47 天前
愣是没看懂你们到底在讨论啥。
|
 |
40
jasei 47 天前
karpenter 不香吗
|
|
41
kennylam777 46 天前
@dcoder 我只想說, 沒必要把 k8s 說到一無是處。我看還是很多團隊在用 k8s 堆 GPU, 因為我也是其中之一。
隨便 Google 一下"gpu cluster management"看到不少方案都是 k8s 的, 這沒有甚麼不好吧。 因為直接在現有 k8s cluster 上堆 GPU node pool, 改動很少但就是可以解決問題, Dev 直接用 CUDA runtime docker image 打包過來就能 Deploy, 也不用花時間自行分配哪台 node 多少 GPU, 需求無論是 1 台 GPU 還是 100 台都是一樣的, 才不會跟你慢慢在查系統驅動配置或對齊 Run-time 的, 直接加一句 "nvidia.com/gpu" , 然後 Failover/Scaling 都依照既有的方法去做, 學過的都會。 k8s 的 CNI 才沒很古老好嗎? SDN 的都有相應 CNI plugin 啊, Multus 用過了嗎? Calico 用過了嗎? SR-IOV 用過了嗎? 哪裡慢了? 哪裡 SDN 不能用了? 就是有 CNI 插件設計才能讓各種專業的網絡方案都套進 k8s 啊。 快速 join cluster 的問題其實要處理的是 VM creation 的時間, 然後是 kubeadm join 前的環境安裝, 如果 kubelet/kubeadm/container engine 等等東西都預先打包準備好, 那不可能要 10 分鐘的, 但是在 Cloud Managed k8s 上能調整的東西不多, 例如有些 Cloud k8s 是在 VM 開機時才用 script 安裝 kubeadm/kubelet/containerd 的, 因為這麼做會比直接用包好的 node images 更乾淨也易於更新。有開機時間追求的話請自建 k8s, 只是大部分公司也沒有那種需要, 也沒能力, 才有 Cloud Managed k8s 產品出現。 DevOps/SRE 弄得好, 其他小問題就可以丟給當值的 Junior ops 處理, 而 Devs 也不必參與突發事件, 最後大家也輕鬆一點才是理想的狀態。 |
Select Language