【K8s】Service发现
目录
1. Kubernetes 如何在集群的Pod之间提供网络服务？
2. 解释iptables和IPVS代理模式Service的区别。
6. 说明MetalLB所实现的LoadBalancer Service的原理。
1. Kubernetes 如何在集群的Pod之间提供网络服务？
Kubernetes 通过 Service 资源为一组动态变化的Pod提供稳定的网络访问入口。
具体机制如下：
（1）标签选择器：Service通过标签选择器筛选出属于同一逻辑组的Pod（例如后端应用）。
（2）稳定入口：Service拥有固定的虚拟IP（ClusterIP）和DNS名称，Pod重启或IP变化不影响访问。
（3）负载均衡：流量到达Service后，由kube-proxy基于iptables规则或IPVS规则将其平均分发到后端的多个Pod。
（4）服务发现：Kubernetes内置DNS将Service名称解析为ClusterIP，支持环境变量注入。
Pod之间可以直接通过Pod IP通信，但Pod IP不固定；因此通常通过Service进行访问，实现解耦和高可用。
2. 解释iptables和IPVS代理模式Service的区别。
iptables 和 IPVS是K8s中kube-proxy支持的两种主要的流量转发模式。
iptables 模式 基于 Linux 内核的 netfilter 规则链实现。它为每个 Service 生成一组线性匹配的规则，流量经过时按顺序匹配。这种模式在小规模集群（Service 数量少于 1000）中工作良好，规则清晰易于排查。但随着 Service 数量增加，规则链变长，匹配效率线性下降；每次规则更新需要刷新整个 iptables 表，可能造成连接中断。负载均衡算法仅支持随机转发（通过概率规则模拟）。
IPVS 模式 基于 Linux 内核的 IPVS（IP Virtual Server）模块，专门用于高性能负载均衡。它使用哈希表存储规则，查找复杂度为 O(1)，因此即使 Service 数量达到数千，性能依然稳定。IPVS 原生支持多种负载均衡算法，如轮询（rr）、最少连接（lc）、目标哈希（dh）、源哈希（sh）等。规则更新采用增量方式，不影响现有连接。缺点是排查问题需要熟悉 ipvsadm 工具，规则不如 iptables 直观。
对于大规模集群（节点数多、Service 数量大），优先选择 IPVS 模式以获取更好的性能和算法灵活性；小规模开发测试环境两种模式均可。
3. 举例说明ClusterIP类型Service的用法。
ClusterIP类型的服务发现通过集群内部的IP暴露服务，只能在集群内部访问，是默认的ServiceType。
想象这样一个场景：一个电商系统由前端Web应用和后端订单处理API组成，两者都部署在同一个K8s集群中。
前端Pod需要调用后端API获取订单数据。由于后端Pod可能会因版本更新、节点故障或扩缩容而动态变化，他的IP地址是不固定的。此时，可以为后端API创建一个ClusterIP类型的Service。这个Service获得一个集群内部唯一的虚拟IP（例如 10.96.100.1），并通过标签选择器始终指向当前所有健康的后端API Pod。
前端Pod只需通过该Service的名称或对应的内部域名发起请求，集群内部的DNS会自动解析为Service的虚拟IP。这样，前端完全不需要关心后端Pod的具体IP变化，实现了服务发现和负载均衡，而且这个服务不会被集群外部访问，保证了内部API的安全性。
4. 举例说明NodePort类型Service的用法。
NodePort是一种Service类型，它会在集群的每个节点上分配一个固定的静态端口（NodePort）。用户只需通过任意节点的IP地址加上这个端口号（即<节点IP>:<节点端口>），就可以从集群外部访问该服务。当请求到达节点端口后，NodePort服务会自动将其转发给后台自动创建的ClusterIP服务，再由ClusterIP完成对后端Pod的负载均衡和最终请求传递。
想象这样一个场景：一家创业公司开发了一个内部使用的数据分析工具，该工具以Web界面形式运行在K8s集群中。公司的开发人员需要在自己的笔记本电脑上直接访问这个Web界面，但公司没有配置专用的负载均衡器，也没有云服务提供商的LoadBalancer支持。
此时，运维人员将该Web应用对应的Service类型设置为NodePort。当Service创建后，K8s会在集群中每一个节点的网络接口上开放一个特定范围的端口（范围再30000-32767）。开发人员只需要知道任意一个节点的公网或内网IP地址（例如 192.168.1.10），就可以在浏览器中输入 http://192.168.1.10:30080 访问该数据分析工具的Web界面。
即使某台节点宕机，只要开发人员切换到另一个正常节点的IP地址和相同的NodePort，仍然可以正常访问应用，因为Service会将发往该节点端口的请求路由到后端正常的Pod上。
5. 举例说明Headless类型Service的用法。
Headless类型的Service 不分配虚拟 IP，而是直接在 DNS 中返回后端 Pod 的 IP 列表。这让客户端可以直连每个 Pod，适用于需要稳定网络标识和独立访问的有状态应用（例如 Kafka、ZooKeeper、etcd）。
想象这样一个场景：一个大型互联网公司需要部署一套Kafka消息队列集群，这个集群由多个Broker节点（即多个Pod）组成。Kafka的客户端（生产者或消费者）需要直接连接到每一个Broker，而不是通过一个负载均衡器，因为Kafka内部需要维护与每个Broker的独立连接状态，用于主题分区读写和副本同步。
如果使用普通ClusterIP Service，客户端只会连接到一个虚拟IP，然后被随机或轮询转发到某个Broker，这无法满足Kafka对每个Broker直接连接的要求。因此，运维人员为Kafka集群创建一个Headless Service。
创建后，该Service不为Broker Pod提供统一的虚拟IP，而是在集群DNS中为每个Pod直接生成独立的DNSA记录。Kafka客户端可以先通过该Headless Service获取所有可用Broker Pod的IP列表，然后直接与每一个Broker Pod的IP建立网络连接。这种方式保留了每个Pod的有状态身份，完美适配Kafka、ZooKeeper、etcd等需要稳定网络标识和直连Pod的分布式有状态应用。
6. 说明MetalLB所实现的LoadBalancer Service的原理。
MetalLB 是裸机K8s集群的LoadBalancer类型Service实现。当云厂商不提供LB时，MetalLB接管LoadBalancer请求。
它的原理是：MetaILB监听集群中类型为LoadBalancer的Service资源，从预先配置的IP地址池中分配一个外部IP；然后通过两种工作模式之一对外宣告该IP。在Layer 2模式下，它利用ARP/NDP响应使Service的IP成为某台节点（Leader）的MAC地址，所有流量先汇聚到这个节点再经kube-proxy分发，存在单点瓶颈但无需BGP支持；在BGP模式下，它与路由器建立BGP会话并将Service的IP路由通告出去，从而实现真正的负载均衡和多路径转发。最后，MetalLB自动更新Service的status.loadBalancer.ingress字段，将分配到的外部IP写入其中，完成服务暴露，适用于没有云LB的物理机或虚拟机集群。
7. 详细说明Ingress的实现原理和它所实现的功能。
Ingress不是一种Service类型，而是一组API资源和控制器的组合。
Ingress的工作原理是：用户首先定义Ingress规则，在YAML中指定域名、路径与后端Service的映射关系；随后，Ingress Controller持续监听API Server中Ingress资源的变化，一旦发现新规则或规则变更，Controller会根据这些规则动态生成对应反向代理的配置；接着，Controller通过重载或动态更新方式使代理应用加载并生效新配置；最终，当外部请求到达Controller Pod（该Pod通常通过NodePort或LoadBalancer方式对外暴露）时，Controller根据请求的Host/Path信息将其精准转发到正确的后端Service和Pod，完成整个流量路由过程。
Ingress实现了以下功能：
（1）基于域名的路由：根据不同域名将请求分发到不同后端服务，例如将api.example.com指向Service A，web.example.com指向Service B。
（2）基于路径的路由：根据URL路径将请求分发到不同服务，例如将example.com/api指向Service A，example.com/web指向Service B。
（3）SSL/TLS终结：集中管理HTTPS证书，在Ingress层解密HTTPS请求后以HTTP形式转发给后端服务，减轻后端压力。
（4）负载均衡：支持轮询、最少连接数等多种算法，将请求平均分发到后端Pod。
（5）黑白名单：基于客户端IP地址进行访问控制，允许或拒绝特定IP段的请求。
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
12
0- 0
已为社区贡献10条内容
所有评论(0)