svcpod的简单介绍

Pod内部访问svc失败分析

始终是1/2的成功率，但是完全没有新的contrack记录。 POD访问svc 应该没走kube-proxy。解决方式： 移除eth1的网卡上的ip，该情况完全消失。

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

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

若pod1需访问pod2，通常通过Service2的域名进行访问，直接访问pod较为罕见，因pod IP易变，而服务IP相对稳定。当pod1使用servicenamespacesvc.cluster.local发起域名解析请求时，nodeLocaldns若缓存中未找到解析结果，则将请求转发至全局CoreDNS。全局CoreDNS解析后将IP返回给pod1，完成访问过程。

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

首先，创建DNS诊断工具pod用于检测DNS服务状态。接着，检查本地DNS配置文件，确保search域名设置正确。进一步，验证DNS服务pod状态是否正常，以及服务的Endpoints是否关联正确。通过描述DNS服务，确认服务与pod之间的关联性。

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

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

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

3、Service 是为一组具有相同功能的Pod提供一个统一的入口地址，并将请求进行负载均衡地分发到各个Pod上。ClusterIP类型的Service是kubernetes集群默认的Service， 它只能用于集群内部通信。不能用于外部通信。K8s会为每个Service分配一个虚拟IP，即ClusterIP。这个虚拟IP只能在集群内部访问。

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

5、在K8S大规模场景下，Service性能的优化主要可以通过以下方式进行： 使用IPVS代替Iptables**： KuberneTES中的Service默认使用Iptables进行负载均衡，但随着Service数量的增加，Iptables的规则链会线性增长，导致性能下降。

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

k8s如何修改svc

获取deployment名称，一般pod使用名称与之一致，创建mynginx所对应的svc，pod所对应的端口是8080，所以目标端口是8080。需要修改svc的网络模式，编辑新创建的svc，type的类型由ClusterIP改成NodePort，保存退出即可。以上是k8s修改svc的方法。

方式1：修改LB调度策略（适用于公有云环境）：将clusterip模式暴露的服务改成LB方式。使用注解service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler：wlc修改LB的调度策略为最少请求调度策略（默认是轮询）。注意事项：增加LB会增加网络节点，可能增加耗时。

**服务发现**：在微服务项目部署于K8S上时，每个项目由多个服务组成，每个服务由多个pod构成。当请求访问服务时，SVC提供统一的入口，无论服务分散于集群不同位置或分配不同IP，请求都能被转发到一组服务的某个pod处理。创建SVC时，根据标签选择器查找并创建与SVC同名的endpoint对象。

流量转发与NAT：流量从Pod通过内核PREROUTING链到达，IPVS监听后进行DNAT修改目标IP，POSTROUTING链选择路由至真实服务器，服务器响应后IPVS修改源IP，最终返回客户端。排查过程：通过压测和控制变量法定位问题，发现与后端服务关系不大。问题可能源自socket管理机制，特别是nodejs的HTTP客户端。

{SVCNAME}_SERVICE_PORT 变量。 这里 Service 的名称需大写，横线被转换成下划线。