Service存在的意义
- 防止Pod失联
- 定义一组Pod访问策略
- 支持ClusterIp，NodePort以及LoadBalancer三种类型
Pod与Service的关系
- 通过label-selector相关联
- 通过Service实现Pod的负载均衡（TCP/UDP 4层）
示例
svc.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app: java-demo
name: java-demo
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8080
selector:
app: java-demo
type: NodePort
selector根据标签关联一组资源
service类型
ClusterIP在集群内部访问，相当于一个VIP虚拟IP，访问VIP转发到后端不同的Pod
NopePort在每个Node上面创建一个端口，访问端口转发到后端不同的Pod，端口是随机的默认是从30000开始，用户访问Node ip加随机端口
LoadBalancer主要应用于公有云，工作原理类似于NopePort，访问Lb转发到Node通过Node再转发到后端Pod
查看当前命名空间下的service
kubectl get svc
任何类型都会产生内部的cluster ip
Service NopePort对外暴露应用
需要访问以下三个Pod
创建Service 改pod使用deploy.yaml创建
kubectl expose deployment java-demo --port=80 --target-port=8080 --type=NodePort
指定类型为deployment
指定名称为java-demo 如果不知道名字可以通过kubectl get deploy查看
--port=80集群内部访问的端口是80
--target-port=8080内部应用实际端口，因为是tomcat所以是8080端口
可以使用参数--name指定名称 不指定名称和deploy是一样的
--type指定类型
Service已经存在，之前已经创建过了
加参数不执行创建yaml文件
kubectl expose deployment java-demo --port=80 --target-port=8080 --type=NodePort --dry-run -o yaml
导出至svc2.yaml
kubectl expose deployment java-demo --port=80 --target-port=8080 --type=NodePort --dry-run -o yaml>>svc2.yaml
应用
kubectl apply -f svc2.yaml
访问任何Node加随机端口即可访问该项目
怎么创建cluster ip把yaml文件里面的type类型改成ClusterIP即可
修改svc2.yaml
不指定type的话默认就是ClusterIP及只能在集群内部访问
删除刚刚应用的svc2
kubectl delete -f svc2.yaml
再创建一次
kubectl apply -f svc2.yaml
查看
kubectl get svc
在任何一个节点使用ClusterIP访问
curl 10.1.187.157:80
要使用LoadBanlancer也是定义的
最常用的是ClusterIP和NodePort
CLusterIP只能在集群内部访问，只能在节点访问
NopePort分配一个集群IP会在每个Node启用一个端口，可以在集群外部访问
LoabBanlancer 分配一个内部集群IP地址，并在每个节点上启用一个端口来暴露服务
Service可以实现负载均衡，是怎么实现多个Pod负载均衡的呢
通过Iptables创建的规则转发到Pod
使用kube-proxy实现实现service功能