Pod内访问不自己svc地址？ pod无法访问外部ip？

k8s核心概念之SVC(易混淆难理解知识点总结)

SVC工作原理**：kube-proxy组件运行于每个node节点上，实现服务功能，包括客户端Pod访问service，或集群外主机通过NodePort等方式访问service。早期版本中，kube-proxy使用iptables模式，但随着service数量增加，引入了性能更优的IPVS模式。

服务与pod的关系：Kubernetes Service抽象一组POD，作为一组Pod的负载均衡（LB），将请求分发至对应Pod。集群IP对应svc，kube-proxy实现LB功能，通过系统调用建立ipvs映射。

在K8s中，服务（Service）提供了一种网络抽象，允许内部Pod间通过Service名进行通信。例如，一个名为frontend的Service可以通过frontend或frontend..svc.cluster.local的dns名称访问同一命名空间内的服务。

pod内部访问svc失败分析

始终是1/2的成功率，但是完全没有新的contrack记录。 pod访问svc 应该没走kube-proxy。解决方式： 移除eth1的网卡上的ip，该情况完全消失。 pod 内部访问100%成功，node访问会产生新的contrack 如果自定义 svc 只有一个pod，pod 访问 svc 始终都是成功的 可以看到eth1网卡发起的arp广播。

开始时，一个正常运行的Pod突然无法创建新的连接，业务通过Pod A访问svc B时出现此问题。查阅资料后，发现错误可能源于linux内核的随机端口数量阈值已满，导致无法分配新的端口用于连接。内核参数`net.ipVip_local_port_range`默认为32768~60999，若业务需要大量长连接，可能需要调整这个范围。

原因：镜像问题导致容器重启失败。解决方法：更换镜像。Pod创建失败：原因：镜像问题导致容器无法启动。解决方法：更换镜像。Pod的ready状态未进入：原因：Pod的执行命令失败，无法获取资源。解决方法：进入容器内部，创建yaml定义的资源。Pod创建失败：原因：yml文件内容出错，如使用了中文字符。

可能导致健康检查失败、业务访问异常等问题。大量创建 svc 的时候减少创建监听的步骤只是提交 ipvs/iptables 规则，这样可以优化连接性能。另一个就解决某些场景下出现大量的 CLOSE_wait 占用 TCP 连接等问题。在 22 版本之后就去掉了 PortOpener 逻辑。

kubernetes——Service(SVC)服务

这种模式，kube-proxy 会监视 Kubernetes Service对象和Endpoints，调用netlink接口以相应地创建ipvs 规则并定期与 Kubernetes Service对象和Endpoints对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。

流量链路介绍：当通过本地域名调用服务，流量在Kubernetes集群内部的转发路径包括本地域名解析、Kubernetes Service、kube-proxy、ipvs，直至实际后端服务。服务治理通过本地域名映射到特定svc，svc提供集群IP，kube-proxy则通过ipvs建立svc与pod之间的映射关系。

解析地址，域名组成为servicename.namespace.svc.cluster.local：集群内访问：0x04 ExternalName 将外部流量引入集群内部 ExternalName类型的Service通过CNAME和它的值，可以将服务映射到externalName字段的内容引入外部服务到内部流量，即使用DNS CNAME机制把自己CNAME到你指定的另外一个域名上。

问题2： 如何提供外部访问和负载均衡的能力 Kubernetes Service 具备服务发现和负载均衡的功能，即 一方面提供了统一的访问入口，另一方面负载均衡到后端 Pod 。下图是 Service 的简约架构图，左侧表示 Service 提供了外部访问和 Pod 网络访问 ，右侧表示对接了一组 Pod，同时把请求负载均衡到这组 Pod。

在Kubernetes（K8s）环境中，服务间的调用和通信是微服务架构的核心。本文将深入探讨K8s中服务调用的方法和原理，帮助你全面理解服务间交互的机制。在K8s中，服务（Service）提供了一种网络抽象，允许内部Pod间通过Service名进行通信。

问题1：Kubernetes集群服务访问失败？原因分析：证书不能被识别，可能是因为自定义证书或证书已过期。解决方法：更新证书。问题2：Kubernetes集群服务访问失败？原因分析：端口映射错误，服务虽然正常运行，但不能提供服务。解决方法：删除服务（SVC），重新映射端口。

请问下k8siptables下的实现的svc是哪一种负载均衡模式呢?

LoadBalancer 类型的 SVC 访问时，从 PREROUTING 链跳转到 KUBE-SERVICES 链，再到 KUBE-EXT-XR6NUEPTVOUAGEC3 链，最后到 KUBE-SVC-XR6NUEPTVOUAGEC3 链，执行负载均衡操作后 DNAT 到目标 Pod 节点。

**负载均衡**：SVC通过绑定微服务中一组pod，对外请求时，SVC将请求均衡分发到这组pod中的某个实例。运维人员通过yaml文件或kubectl命令指定规则创建SVC，实现负载均衡与服务发现功能。

Kubernetes Service定义了这样一种抽象：一个Pod的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。

K8S Service实战与原理初探的答案如下：Kubernetes Service的基本概念 Kubernetes Service是一种抽象的网络暴露方式，提供了一种负载均衡的解决方案，用于管理一组Pod的网络访问。

kube-proxy负责service的实现，即实现了k8s内部从pod到service和外部从node port到service的访问。kube-proxy作为一个控制器，作为k8s和Linux kernel Netfilter交互的一个枢纽。

服务与Pod的关系：Kubernetes Service抽象一组Pod，作为一组Pod的负载均衡（LB），将请求分发至对应Pod。集群IP对应svc，kube-proxy实现LB功能，通过系统调用建立ipvs映射。