Pod与Service的联系
- 防止Pod失联
- 定义一组Pod的访问策略
- 支持ClusterIP,NodePort以及LoadBalancer三种类型
- Service的底层实现主要有Iptables和IPVS二种网络模式 如何转发流量和负载均衡
- 问题:
- 1.多个Pod如何负载均衡
- 2.容器崩溃重新拉起,IP发生变化,如何感知
- 3.如何通过域名访问应用
1 | 1. Service 的主要作用: 防止Pod失联 |
Service 定义
1 | [root@k8s-master1 demo]# vim web-service.yaml |
1 | [root@k8s-master demo2]# kubectl apply -f service1.yaml |
1 | # 列出当前service |
1 | # kubernetes这个默认的service是负载 master apiserver的IP |
- 每个service对应1个endpoint控制器
- endpoints关联pod
查看pod的标签
1 | # 查看具有 app=web 的pod |
1 | # 查看svc详细信息 |
启动pod关联service
1 | [root@k8s-master demo2]# vim nginx-1108.yaml |
1 | [root@k8s-master demo2]# kubectl apply -f nginx-1108.yaml |
Service 类型
1 | • ClusterIP:默认,分配一个集群内部可以访问的虚拟IP(VIP) |
ClusterIP
- 集群内部应用中间之间访问
- ClusterIP 用于集群内部负载均衡IP 不对外暴露
- 有两个应用 A应用多个副本 访问 B应用多个副本
- B想访问A应用 不能访问PODIP,需要访问ServiceIP的ClusterIP
- B应用写 ClusterIP
- 应用访问 通过 Iptables/LVS(IPVS) 转发 给serviceIP 再去负载到后面的POD
NodePort
- 外部使用 暴露一个访问入口
- 如何让用户访问到 部署的应用
- 用户访问 -> 暴露的端口 再转发给 -> service -> pods
- NodePort 会在每个 node 上暴露一个端口 这个端口作为用户访问的 入口port
1 | [root@k8s-master demo2]# vim service1.yaml |
1 | [root@k8s-master demo2]# kubectl delete -f service1.yaml |
- NodePort 也分配 CLUSTER-IP = 10.0.0.125
- NodePort 在node上分配端口 80:31376/TCP 31376就是对外访问端口
1 | [root@k8s-node2 ~]# netstat -tnlp | grep 31376 |
查看 ipvsadm 规则
- 安装
1 | [root@k8s-node1 ~]# yum install ipvsadm -y |
域名应该找哪个node
- 还得有一层负载均衡
- 这层负载均衡负责 转发给 node集群+对外端口
- 域名解析 -> 负载均衡器 -> node集群+对外端口 -> pod集群
LoadBalancer
- 这就是前面加一个LB
- LB 转发给 每个nodeIP+port
- 域名解析到LB地址
- 自建LB 需要知道 生成的端口是多少 再添加到LB
- 公有云 LoadBalancer LB 可以自动关联 提供访问 访问流程和NodePort一致
Service类型小结
- NodePort
- 用户 -> 域名 -> 负载均衡(阿里云公网)(后端手动添加) -> NodeIP(内网):Port -> PodIP+Port
- LoadBalancer
- 用户 -> 域名 -> 负载均衡(阿里云公网)(自动添加) -> NodeIP(内网):Port -> PodIP+Port
- LoadBalancer 特定云提供商底层LB接口 例如aws,google,openstack,aliyun不知道
- NodeIP:Port NodeIP不固定 Port可以固定
1 | # cluster IP 范围 |
固定 NodePort 端口
- 端口要提前规划好
- 不要冲突
1 | # 也得注意范围区间 |
1 | [root@k8s-master demo2]# kubectl apply -f service1.yaml |
Service 代理模式
1 | 底层流量转发与负载均衡实现: |
- 工作进程 kube-proxy
- 他完成了 流量转发规则 1.12/13 都是 Iptables
- 创建pod时 kube-proxy 会在node上生成规则
4,如果是iptabes 使用iptables-save | more 查看所有规则 流量转发Dnat
1 | [root@k8s-node1 yum.repos.d]# ps -ef|grep kube-proxy |
1 | [root@k8s-node1 yum.repos.d]# cat /opt/kubernetes/cfg/kube-proxy-config.yml | grep mode |
IPVS
- 如果是iptabes代理 一个service会创建很多的规则 (更新) pod挂了会刷新规则
- iptabes规则都是从上到下逐条匹配(匹配延迟)
- ipvs:LVS基于IPVS内核调度模块实现的负载均衡,LVS基于四层负载均衡,IPVS解决上面的问题
- ipvs 基于内核态规则 性能更好
- iptables 用户态
1 | [root@k8s-node1 yum.repos.d]# ipvsadm -ln |
1 | # 当创建 svc 会在node上创建一个 kube-ipvs0 虚拟网卡 |
Iptables VS IPVS
- 企业中更多使用ipvs
- 在配置文件中 设置调度算法
1 | Iptables: • 灵活,功能强大(可以在数据包不同阶段对包进行操作) |
修改ipvs的调度算法
1 | [root@k8s-node1 yum.repos.d]# vim /opt/kubernetes/cfg/kube-proxy-config.yml |
1 | [root@k8s-node1 yum.repos.d]# systemctl restart kube-proxy |
部署集群内部DNS服务(CoreDNS)
- service 内部之间用clusterIP 进行通信
- clusterIP 并不是固定的 程序也不该写死 项目迁移写死IP很麻烦 访问地址可以通过dns名称 IP有变化也不会影响
- 集群内部的dns来为service做名称的访问
1 | 1. DNS服务监视Kubernetes API,为每一个Service创建DNS记录用于域名解析。 |
- 默认的是 coredns
- 早期版本 kube-dns
- 下载地址:
1 | https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dns/coredns |
1 | spec: |
1 | # cluster.local 域 |
1 | # 镜像地址 |
1 | [root@k8s-master ~]# kubectl get pod -n kube-system |
测试解析dns
1 | # 部署 busybox镜像 指定版本 1.28.4 |
1 | [root@k8s-master1 demo]# kubectl get svc |
跨命名空间解析
1 | # 默认是解析当前pod的命名空间下的service名字 |