k8s中的微服务-EW帮帮网

什么事微服务

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

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

当我们访问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就没了

默认情况下，只对集群内部的访问生效

前面是微服务的名称加上命名空间，对微服务进行域名解析，能解析到她的IP

ClusterIP中的特殊模式headless

之前有了无头服务，要删掉，不然影响实验

没有了IP以后，后端就没有调度了

此时我们可以用dns来写，把要访问的server直接指定到后端的服务器中去

#开启一个busyboxplus的pod测试

nodeport

之前的服务设置了无头服务，这里要删除之前环境，重新运行

多了一个端口

这个端口用来直接对外暴露

nodeport在集群节点上绑定端口，一个端口对应一个服务

直接负载到下面两个

用clusterip来访问后端的

访问模式

对应的端口是不固定的，但是我们可以直接指定，但是有范围限制最大30000

但是想要超过限制也可以，修改配置文件就行。但是集群会挂掉，要等待自愈

加上这句话- --service-node-port-range=30000-40000

刚刚还不能超过的限制，现在就可以了

loadbalancer

没有云平台的情况

有云平台的情况，把服务搭建到云平台上，云平台会给一个自动分配对外ip的业务

状态正在获取，默认无法分配外部访问IP

可以访问，但是对外访问时，并不好做

如果主机没有IP，可以用dhcp来分配，但是此时集群中没有，所以我们要做一个类似的

metaILB

部署安装

必须要把集群做成ipvs的模式

并且重启网络方面的pod

这个文档里的路径已经修改好了，如果是未修改的，记得把路径换成自己的软件仓库

这个生效了之后，才能改配置

之前这里还是正在生效，现在已经有了IP

#通过分配地址从集群外访问服务

已经自动分配对外IP

externalname

开启services后，不会被分配IP，而是用dns解析CNAME固定域名来解决ip变化问题
一般应用于外部业务和pod沟通或外部业务迁移到pod内时
在应用向集群迁移过程中，externalname在过度阶段就可以起作用了。
集群外的资源迁移到集群时，在迁移的过程中ip可能会变化，但是域名+dns解析能完美解决此问题

集群内部的IP在访问时，做的是域名解析

把真实的微服务转化成其他主机上

没有IP时如何被访问的，通过dns的域名解析

验证 DNS 解析

这行命令测试 Kubernetes 集群内部 DNS（10.96.0.10是集群 DNS 服务的 IP）是否能正确解析ext-service对应的域名：

结果显示ext-service.default.svc.cluster.local（集群内部服务域名）被解析为www.baidu.com

最终解析到百度的实际 IP 地址（103.235.46.115和103.235.46.102）

得到了集群内部的主机

微服务把集群外部的资源映射到集群内部，让集群内部可以使用

Ingress-nginx

在service前面在加一个nginx

在集群暴露时，再加一个反向代理

一种全局的、为了代理不同后端 Service 而设置的负载均衡服务,支持7层
Ingress由两部分组成：Ingress controller和Ingress服务
Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。
业界常用的各种反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为Kubernetes 专门维护了对应的 Ingress Controller。

首先先下载镜像源