Kubernetes网络服务全解析

 1.  Kubernetes如何在集群的Pod之间提供网络服务？

答：每个 Pod 分配独立 IP，由 Calico 插件配置，确保 Pod 跨节点可直接通信。用Service 为一组 Pod 提供固定访问点，通过标签选择器关联 Pod，自动负载均衡请求。kube-proxy 在节点上维护转发规则（iptables/IPVS），将 Service IP 的请求转发到后端 Pod。

 2. 解释iptables和IPVS代理模式Service的区别。

答：iptables：基于防火墙规则转发，规则多了性能下降，仅支持轮询和会话亲和，适合小规模集群。

IPVS：基于内核负载均衡模块，哈希表存储规则，性能稳定，支持轮询、最小连接等多种算法，适合大规模集群。

iptables 代理模式的 Service：

kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。对每个Service，它会配置 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，进而将请求重 定向到 Service 的一组后端中的某个 Pod 上面。对于每个 Endpoints 对象，它也会配置 iptables 规则， 这个规则会选择一个后端组合。

使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理，因此无需在用户空间 和内核空间之间进行切换。

IPVS 代理模式的 Service：

在 IPVS (IP Virtual Server)模式下，kube-proxy 监视 Kubernetes 服务和端点，调用 netlink 接口相应地 创建 IPVS 规则，并定期将 IPVS 规则与 Kubernetes 服务和端点同步。该控制循环可确保 IPVS 状态与 所需状态匹配。访问服务时，IPVS 将流量定向到后端 Pod 之一。

IPVS 代理模式基于类似于 iptables 模式的 netfilter 挂钩函数，但是使用哈希表作为基础数据结构，并 且在内核空间中工作， 这意味着，与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。

3.举例说明ClusterIP类型Service的用法。

 答：ClusterIP 是默认的 Service 类型，通过集群内部的虚拟 IP暴露服务，仅集群内 Pod 可访问，适用于内部服务通信。Pod IP访问。

4. 举例说明NodePort类型Service的用法。

答：NodePort 类型 Service 通过在每个节点上开放静态端口（NodePort）暴露服务，外部可通过节点IP:NodePort访问，适用于需要外部临时访问集群服务的场景。

5.举例说明Headless类型Service的用法。

答：Headless Service是不分配 ClusterIP 的 Service，DNS 解析时直接返回所有关联 Pod 的 IP，适用于客户端需要知道所有 Pod 实例的场景，获取的地址每一个都可以进行后端访问。

6. 详细说明Ingress的实现原理和它所实现的功能。

答：Ingress 是 Kubernetes 中用于管理 HTTP/HTTPS 流量路由的 API 对象，通过 Ingress Controller 将外部流量转发到集群内的 Service,用户定义的路由规则（YAML），包含域名、路径、后端 Service 等配置。外部流量（如用户请求）首先到达集群边缘的 Ingress Controller。Ingress Controller 根据 Ingress 资源规则，将流量按域名（或路径转发到对应的后端 Service。Service 再将流量转发到关联的 Pod，完成请求处理。

实现的功能：

HTTP/HTTPS 路由；HTTPS 终止；负载均衡；

7.简述LoadBalancer类型的service。