Kubernetes之Service

　　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功能