kubernetes资源对象--Service

最新推荐文章于 2024-10-17 10:36:05 发布

lykops

最新推荐文章于 2024-10-17 10:36:05 发布

阅读量1k

点赞数 2

CC 4.0 BY-SA版权

分类专栏： docker kubernetes 文章标签： kubernetes K8S服务发现 kubernetes服务发现 kubernetes资源对象 K8S资源对象

本文链接：https://blog.youkuaiyun.com/liyingke112/article/details/76576657

docker 同时被 2 个专栏收录

52 篇文章

订阅专栏

kubernetes

43 篇文章

订阅专栏

本文深入探讨K8S中的Service机制，包括Service的概念、如何为Pod提供稳定的访问入口、不同类型的端口（如ClusterIP、NodePort和TargetPort）的作用及区别，以及外部访问Service的四种方式。此外，还介绍了Service如何代理外部服务和支持服务发现。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

为了适应快速的业务需求，微服务架构已经逐渐成为主流，微服务架构的应用需要有非常好的服务编排支持。K8S中的核心要素Service便提供了一套简化的服务代理和发现机制，天然适应微服务架构。

概念

Service是一种抽象概念，定义了一个Pod逻辑集合以及访问它们的策略。目标是提供一个代理服务器，作为Pod的访问入口，它会为访问者提供一个固定访问地址，用于在访问时重定向到相应的后端pod。K8S默认分配给Service的一个固定IP，称为Cluster IP。

在K8S中，Pod IP会随着pod的变化（重建等）而变化的，这对于Pod的访问者来说是不可接受的，而Service会及时更新。对于访问者来说，通过Service进行访问，无需直接感知Pod。

默认的负载均衡策略是轮训或者随机（有kube-proxy的模式决定）。同时，Service上通过yaml文件设置sessionAffinity=ClientIP，来实现基于源IP地址的会话保持。

需要注意，默认情况下。Cluster IP是一个虚拟IP，并不是一个真实的IP，在外部是无法寻址的。如果需要外部访问service 的Cluster IP，这需要额外配置。

service的端口

port

service暴露在cluster ip上的端口，cluster ip:port 是提供给集群内部客户访问service的入口。

nodePort

nodePort是K8S提供给集群外部客户访问service入口的一种方式，node IP:nodePort 是提供给集群外部客户访问service的入口。

targetPort

targetPort是pod上的端口，从port和nodePort上到来的数据最终经过kube-proxy流入到后端pod的targetPort上进入容器。

port、nodePort总结

总的来说，port和nodePort都是service的端口，前者暴露给集群内客户访问服务，后者暴露给集群外客户访问服务。从这两个端口到来的数据都需要经过反向代理kube-proxy流入后端pod的targetPod，从而到达pod上的容器内。

外部访问service的四种方法

但有些服务又需要被外部访问到，例如web前段。这时候就需要加一层网络转发，即外网到内网的转发。K8S提供了四种方案让外部访问service：

ClusterIP：提供一个集群内部的虚拟IP以供Pod访问，如果外部访问的话，需要配置kube-proxy为userspace模式。

NodePort：在每个Node上打开一个端口以供外部访问。

LoadBalancer：通过外部的负载均衡器来访问，该模式需要底层云平台（例如GCE）支持。。

Ingress：具体请见http://blog.youkuaiyun.com/liyingke112/article/details/76022267

代理外部服务

Service不仅可以代理Pod，还可以代理任意其他后端，比如运行在K8S外部MySQL、Oracle等。这是通过定义两个同名的service和endPoints来实现的。

具体请见http://blog.youkuaiyun.com/liyingke112/article/details/76204038

服务发现

K8S主要支持两种服务发现机制：环境变量和DNS。

环境变量方式

K8S创建Pod时会自动添加所有可用的service环境变量到该Pod中。需要注意的是，环境变量的注入只发送在Pod创建时，且不会被自动更新。这个特点暗含了service和访问该service的Pod的创建时间的先后顺序，即任何想要访问service的pod都需要在service已经存在后创建，否则与service相关的环境变量就无法注入该Pod的容器中，这样先创建的容器就无法发现后创建的service。