k8s服务service
service是一个抽象概念，定义了一个服务的多个pod逻辑合集和访问pod的策略，一般把service称为微服务
举个例子一个a服务运行3个pod，b服务怎么访问a服务的pod，pod的ip都不是持久化的重启之后就会有变化。
这时候b服务可以访问跟a服务绑定的service，service信息是固定的提前告诉b就行了，service通过Label Selector跟a服务的pod绑定,无论a的pod如何变化对b来说都是透明的
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376port 端口是service对外暴露的端口，任何人访问80端口都会被service代理到后端pod的9376端口
service的类型有四种:
1. ExternalName: 用于将集群外部的服务引入到集群内部，在集群内部可直接访问来获取服务。
它的值必须是 FQDN, 此FQDN为集群内部的FQDN, 即: ServiceName.Namespace.Domain.LTD.
然后CoreDNS接受到该FQDN后，能解析出一个CNAME记录, 该别名记录为真正互联网上的域名.
如: www.test.com, 接着CoreDNS在向互联网上的根域DNS解析该域名，获得其真实互联网IP.
2. ClusterIP： 默认模式，只能在集群内部访问,用于为集群内Pod访问时,提供的固定访问地址,默认是自动分配地址,可使用 ClusterIP关键字指定固定IP.
3. NodePort: 用于为集群外部访问Service后面Pod提供访问接入端口.
这种类型的service工作流程为:
Client----->NodeIP:NodePort----->ClusterIP:ServicePort----->PodIP:ContainerPort
4. LoadBalancer: 用于当K8s运行在一个云环境内时,若该云环境支持LBaaS,则此类型可自动触发创建
一个软件负载均衡器用于对Service做负载均衡调度.
因为外部所有Client都访问一个NodeIP,该节点的压力将会很大, 而LoadBalancer则可解决这个问题。
而且它还直接动态监测后端Node是否被移除或新增了，然后动态更新调度的节点数
一个NodePort的例子
创建一个nodePort类型的service，让节点外主机可以访问到服务.
vim myapp-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: default
spec:
selector:
app: myapp
release: canary
clusterIP: 10.99.99.99 #此地址设定为固定很容易冲突, 建议最好不写,让其自动分配.
type: NodePort
ports:
- port: 80 #设置Service对外提供服务的端口
targetPort: 80 # 设置Pod对外提供服务的端口.
nodePort: 30080 #此宿主机端口也可不指定,系统将自动从3万~65535分配,若必须设为80,也可以,
#但必须保证所以宿主机上的80端口没有被占用,若有被占用,则该节点上的服务将无法被访问.headless service(无头service)：
所谓headless service指: 没有ClusterIP的service, 它仅有一个service name.这个服务名解析得到的不是
service的集群IP，而是Pod的IP,当其它人访问该service时，将直接获得Pod的IP,进行直接访问。
示例:
vim myapp-svc-headless.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp-headless
namespace: default
spec:
selector:
app: myapp
release: canary
clusterIP: None
ports:
- port: 80
targetPort: 80Ingress... 待续