一般pod 都是根据 service 资源来进行集群内的暴露,因为 k8s 在 pod 启动前就已经给调度节点上的 pod 分配好 ip 地址了,因此我们并不能提前知道提供服务的 pod 的 ip 地址。那么 service 服务提供的功能就是,使用者根本无需关心后端提供服务 pod 的数量,以及各自对应的 ip 地址。 服务资源会被 k8s 分配一个...
对于不需要ClusterIP的服务,可以创建一个所谓的Headless服务。这种服务没有ClusterIP,直接利用DNS解析到后端Pods的IP地址。 2)多端口服务 ClusterIP服务还可以定义多个端口,允许同一个服务上的不同端口处理不同的流量,为复杂的应用场景提供支持。 总而言之,ClusterIP服务是Kubernetes集群内部通信的基石,它的通信限制是出...
1.ClusterIp:默认类型,自动分配一个仅 Cluster 内部可以访问的虚拟 IP。 2.NodePort:在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口,这样就可以通过 : <NodeIp>:NodePort 来访问该服务 。 3.LoadBalancer:在 NodePort 的基础上,借助 cloud provider 创建一个外部负载均衡器,并将请求转发到: <NodeIp...
排错背景:在一次生产环境的部署过程中,配置文件中配置的访问地址为集群的Service,配置好后发现服务不能正常访问,遂启动了一个busybox进行测试,测试发现在busybox中,能通过coredns正常的解析到IP,然后去ping了一下service,发现不能ping通,ping clusterIP也不能ping通。 排错经历:首先排查了kube-proxy是否正常,发现启动...
1.ClusterIP(集群内部使用)默认方式,分配一个稳定的IP地址,即VIP,只能在集群内部访问 2.NodePort(...
1.服务之间使用服务名称访问不通: example: 使用serviceA.serviceA-ns.svc.cluster.local:8080 实现互通发生超时; 2.使用cluster IP 也不通: 由于使用svc name 通信的核心机制是使用kube-dns解析成为clusterIP,再由kube-proxy 将clusterIP 形成iptables的chain,则配置服务之间使用cluster IP 通信尝试,依然不通; ...
k8s cluster ping 10.96.0.1 no route ping不通svc地址,但是地址可以解析,ping 10.96.0.1果然也不通,ping其他pod地址是正常通的,可能是路由规则的问题也就是iptables规则或ipvs规则的问题 检查后发现没有指定ipvs模块,默认是iptables规则,但是kube-proxy执行iptables失败导致的解决如下 ...
这个文件中,配置的 DNS Server,一般就是 K8S 中,kubedns 的 Service 的 ClusterIP,这个IP是虚拟IP,无法ping,但可以访问。 root@other-8-67:~# kubectl get svc -n kube-system |grep dns kube-dns ClusterIP 10.68.0.2 <none> 53/UDP,53/TCP,9153/TCP 106d ...
service的cluster-ip是k8s系统中的虚拟ip地址 只能在内部访问。 如果需要在外部访问的话 可以通过NodePort...