k8s-service 7

由控制器来完成集群的工作负载,service(微服务)是将工作负载的应用暴露出去,从而解决访问问题

k8s-service 7_第1张图片

作用:无论是在集群内还是集群外,都可以访问pod上的应用,其实现对集群内的应用pod自动发现和负载均衡

service默认支持四层负载均衡,七层需要inggress来支持

k8s-service 7_第2张图片

通信必须要有proxy,如果是跨节点网络通信还需要flannel节点,然后再结合每个节点上的iptables,从而实现负载均衡

k8s-service 7_第3张图片k8s-service 7_第4张图片k8s-service 7_第5张图片k8s-service 7_第6张图片k8s-service 7_第7张图片

默认类型为ClusterIP,不指定的话就默认为ClusterIP

k8s-service 7_第8张图片

默认使用iptables,调度iptables算法是随机的,推荐使用lvs

IPVS模式

kube-proxy 通过 iptables 处理 Service 的过程,需要在宿主机上设置相当多的 iptables 规则,如果宿主机有大量的Pod,不断刷新iptables规则,会消耗大量的CPU 资源;

IPVS模式的service,可以使K8s集群支持更多量级的Pod。

lvs内核调度,算法更强大,性能更好,可以减少在刷iptables所带来的cpu消耗

k8s-service 7_第9张图片

修改proxy配置

k8s-service 7_第10张图片k8s-service 7_第11张图片   

重启pod,删除重建

k8s-service 7_第12张图片

在切换成ipvs模式后,kube-proxy会自动在宿主机上添加一个虚拟网卡,并给其分配serviceIP

k8s-service 7_第13张图片


Nodeport

k8s-service 7_第14张图片k8s-service 7_第15张图片

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


Headless(无头服务)

k8s-service 7_第16张图片

headless模式不需要分配VIP

k8s-service 7_第17张图片

该类型也是以一中特殊的clusterIP类型,clusterIP仅限于集群内进行访问

headless通过svc名称访问,由集群内dns提供解析

k8s-service 7_第18张图片

集群内直接使用service名称进行访问

k8s-service 7_第19张图片

该模式访问仅限于在集群内


LoadBalancer(从外部访问的第二种方式)

k8s-service 7_第20张图片

默认无法分配外部访问ip

k8s-service 7_第21张图片

loadBlabcer -> nodeport -> clusterip -> pod

LoadBalancer模式适用于云平台,裸金属环境需要安装metallb提供支持

官网:https://metallb.universe.tf/installation/

k8s-service 7_第22张图片

下载部署文件

k8s-service 7_第23张图片

在harbor仓库中新建一个metallb项目,并将镜像拉取在上面

k8s-service 7_第24张图片

拉取完成后,修改文件中的镜像地址,与刚拉取的harbor仓库保持一致

k8s-service 7_第25张图片k8s-service 7_第26张图片

给镜像打上标签,并且上传到harbor仓库

k8s-service 7_第27张图片k8s-service 7_第28张图片

部署服务

k8s-service 7_第29张图片

配置分配地址段

k8s-service 7_第30张图片k8s-service 7_第31张图片

你可能感兴趣的:(kubernetes,容器,云原生)