当前位置：首页 > java >正文

k8s中的微服务

java 2025/8/16 1:46:46

什么事微服务

微服务可以通过标签来找到能发布的服务

现在还不知道能让谁来做负载均衡，需要做端口暴漏

当我们访问111时，它会带我们访问后端的四个IP

当我们改变了标签，并覆盖后，原先这个这个标签的主机就被开出去了

重新返回，把标签还原

查看策略，当我们访问这个IP时，他的策略把他带去访问后端的IP地址

这个策略本身是不太好的，IP地址总是会变，而且是防火墙里的策略，数据一多，每次扫描都会造成浪费

即便测试器删了，微服务也不会被删除

要再次删除微服务

微服务的类型

微服务类型	作用描述
ClusterIP	默认值，k8s系统给service自动分配的虚拟IP，只能在集群内部访问
NodePort	将Service通过指定的Node上的端口暴露给外部，访问任意一个NodeIP:nodePort都将路由到ClusterIP
LoadBalancer	在NodePort的基础上,借助cloud provider创建一个外部的负载均衡器，并将请求转发到 NodeIP:NodePort，此模式只能在云服务器上使用
ExternalName	将服务通过 DNS CNAME 记录方式转发到指定的域名（通过 spec.externlName 设定

LoadBalancer：集群内访问集群外

ExternalName：集群外访问集群内

ipvs模式

之前说过，iptables防火墙里的策略不好，所以这里我们可以换成ipvs模式

查看集群的配置

更改集群的配置

更改集群资源的命令

如果什么都没有，说明是默认的使用iptables，这里我们加上ipvs

修改配置后，要重启，这里可以删掉之前的网络配置pod，重新刷新新的pod出来，此时就是新策略的pod

微服务类型详解

clusterip

clusterip模式只能在集群内访问，并对集群内的pod提供健康检测和自动发现功能

追加内容，此时微服务和控制器就在一个配置文件里了

只有集群内部的IP，集群外部的不暴露

查看clusterIP是否成功

这个虚拟 IP（10.99.60.157）在集群内部是可访问的（从 master 节点能成功 curl 通，说明 ClusterIP 有效）
Service 已正确关联后端 Pod（返回 Hello MyApp | Version: v1 证明请求被转发到了 myapp:v1 镜像的 Pod 并处理）

ClusterIP 服务的内部通信机制
集群内部的客户端（如其他 Pod、节点上的进程）想要访问 myappv1 服务时，会使用 Service 的 ClusterIP：10.99.60.157:80。
请求到达任意节点的内核时，IPVS 规则会匹配 10.99.60.157:80，并按轮询策略将流量转发到后端的两个 Pod（10.244.1.15:80 或 10.244.2.15:80）。
Pod 处理请求后，通过反向 NAT 将响应返回给客户端，客户端全程只感知 ClusterIP，无需知道具体 Pod 的 IP（即使 Pod 重建、IP 变化，Service 也会自动更新转发规则）。

想要访问发布，可以手动加入

172.25.254.111：Service 的 ExternalIP（手动配置的外部可访问 IP）
10.244.1.15、10.244.2.15：Deployment myappv1 管理的两个 Pod 的实际 IP（容器运行的真实 IP）
ClusterIP 类型的 Service 核心作用是：提供一个固定的虚拟 IP（ClusterIP），通过标签关联动态变化的 Pod，并通过 IPVS 实现负载均衡。数据传输的核心路径是：
客户端 Pod → ClusterIP（10.99.60.157）→ IPVS 负载均衡 → 后端 Pod（10.244.1.15/2.15）

如果不写，对外的IP就没了