当前位置：首页 > 每日看点 > 正文内容

在 Kubernetes 中，Service 的实现原理是什么，它是如何实现服务发现的？

卡卷网10个月前 (11-20)每日看点161

行，问的这个问题挺有意思，Kubernetes 里 Service 是怎么实现的，服务发现是怎么回事，咱就直说了。这事儿看起来挺玄乎，但掰开揉碎了讲，也就那么回事。你得把这事儿想得简单点，别一上来就被啥术语吓住了——其实全是些搬砖的套路。

咱先从个大方向捋，Kubernetes 这东西，说白了就是个工头，它管理着一堆工人，也就是咱们那些服务（Pods）。你想在工地上指挥一堆工人干活儿，总得有个方式让他们互相认识吧？这就是服务发现的基本需求。然后，Kubernetes 的 Service 就是起了个“指路标”的作用——给工地的工人们找对门儿。

最近无意间获得一份阿里大佬写的刷题笔记，一下子打通了我的任督二脉，进大厂原来没那么难。这是大佬写的，7701页的BAT大佬写的刷题笔记，让我offer拿到手软

1. Service 是干啥的？

Kubernetes 的 Service 本质上就是个“中间商”，负责把请求从外部引导到具体的 Pod 上。为什么要 Service？很简单，因为你直接跟 Pod 打交道不靠谱。Pod 是会“挂”的，跟你的临时工一样，干一阵子走人了，来了新的 Pod，这时候外部流量还是傻乎乎地跑去找原来的 Pod，找不到了，这不就完犊子了么？

所以，Service 出来了，搞了个虚拟 IP，背后帮你去找 Pod。你就别管 Pod 换来换去了，反正都能接着用这个虚拟 IP 跟服务通信。

Kubernetes 里的 Service 有几种类型，最常见的就是 ClusterIP。你可以理解成，你站在工地门口，只能通过工地发号施令，但你不能直接进工地里面挑工人干活儿。Service 就是站在门口收任务，然后再悄悄把活儿分给工人。

2. 服务发现怎么玩的？

这个服务发现咋实现的呢？你要知道，工人（Pod）是动态的，今天来俩，明天走一个，工地还得照常干活儿。这就得靠 Kubernetes 自己给工人打卡登记了。

Service 有个牛逼的地方，叫做“标签选择器”（Label Selector）。简单来说，Kubernetes 会给每个 Pod 发一个小牌子（Label），比如“我是干前端的”或者“我是干数据库的”，然后 Service 就盯着这些牌子，按照需求把流量引过去。就像在工地上，你只要告诉 Service 你需要哪种工人，Service 就能从一堆 Pod 里挑出合适的给你用。

有的哥们可能会问，那服务一多，我怎么知道哪个服务对应哪个 Pod 呢？这就得提 DNS（域名解析）了。在 Kubernetes 里，集群内部有个自带的 DNS 服务，Service 一旦创建成功，Kubernetes 就会自动给它分配一个域名。你只需要通过这个域名就能找到 Service，就像在公司里发邮件一样，用名字就能找到同事，不用管背后换了多少电脑。

3. LoadBalancer 和 NodePort 这两货啥时候用？

ClusterIP 那一套咱们已经说了，它只在集群内部起作用。那问题来了，如果我想把服务暴露出去给外部的客户用呢？这时候你就得用 LoadBalancer 或者 NodePort。

LoadBalancer 其实就是给你配了个“公司前台”，外部请求来了，前台接单，再把活儿转到内部工人那儿去。这玩意儿更智能，自动帮你搞定所有负载均衡的事情，客户从外面看着还挺牛，但其实后面就是一堆工人不停地干活。

NodePort 是啥？这个比较原始，简直跟老工厂里守大门的保安一样。NodePort 是给每个工人直接开了个大门，客户一来，不管啥时候，总有人在门口守着，接到请求就送到工人那儿。你说这玩意儿听着多靠谱，其实毛病不少——你得自己维护这扇门，还不如前面那个自动接活儿的 LoadBalancer 省心。

4. 真实场景：怎么实现 Service 更新？

咱说点实际的，比如你想更新一个服务，但又不能影响客户使用，那 Service 是怎么做到的呢？其实很简单，叫做滚动更新。当你升级服务时，Kubernetes 会自动在后台干活儿，把老的 Pod 换成新的，而外部请求还是通过那个虚拟 IP 进入，这样不管你怎么换工人，客户都看不出来。这种操作简直就是职场里换人不换岗，你明明换了个菜鸟，但客户还是觉得你服务一如既往地好。