目录

1.简介

2.service类型

（1）ClusterIp：

（2）NodePort（节点端口）

（3）LoadBalancer

（4）ExternalName（DNS别名）

3.ClusterIP创建

4.NodePort创建

5.LoadBalancer创建

6.ExternalName创建

1.简介

Kubernetes Service定义了一种抽象：一个 Pod的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。 这一组 Pod 能够被 Service访问到，通常是通过 Label Selector(标签选择器)。

目前一致的service有两个要求：标签匹配，就绪，如果不满足这两个，则无法匹配

2.service类型

（1）ClusterIp：

         默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP

（2）NodePort（节点端口）

         在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 <NodeIP>: NodePort 来访问该服务

（3）LoadBalancer

         在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到<NodeIP>: NodePort

（4）ExternalName（DNS别名）

         把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创 建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持

DNS别名解析流程：
        我们要创建一个ExternalName的service（domain），当创建完domain以后，我们就会得到一个域名，tomcat只要去访问到这个域名，这个域名就会经过coredns解析，解析到一个结果上，这个结果可能是一个域名，也可能是一个IP，这个域名或IP可能指向这个db。
        当外部的db的IP发生变化时，只要修改domain的别名地址就好了，例如db数据库原来是bbs.aaa.com,现在是db.aaa.com，那么只需要将domain的别名地址写成db.aaa.com即可。

3.ClusterIP创建

vim ClusterIP.yaml

apiVersion: v1
kind: Service		#service类型
metadata:
  name: myapp		#当前service的名是myapp
  namespace: default		#放到default名称空间下
spec:		#期望
  type: ClusterIP	#ClusterIP的类型
  selector:			#标签选择器，匹配下面两个标签
    app: myapp	
    release: stabel
  ports:			#端口，
  - name: http		#端口名称为http
    port: 80		#端口是80，集群访问的VIP的端口。
    targetPort: 80	#后端目标80，真实服务器的端口
#IPVS是基于NAT工作模式运行的

kubectl apply -f ClusterIP.yaml
    #基于yaml文件创建ClusterIP类型的svc

kubectl get svc
    #查看已经创建的svc

4.NodePort创建

vim NodePort.yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-nodeport
  namespace: default		#放在default名称空间下
spec:			#期望
  type: NodePort		#当前的工作模式是NodePort方式
  selector:
    app: myapp
    release: stabel
  ports:
  - name: http		#定义的别名为http
    port: 80		#集群的端口80
    targetPort: 80	#后端的端口80

 kubectl apply -f 6.nodeport.yaml

 kubectl get svc
    #这里映射的端口，必须大于三万以上。默认就可以，不用修改，防止冲突
    #在外部访问物理机的31225端口即可映射到容器内部的80端口，达到访问容器的内目的

5.LoadBalancer创建

#与nodeport的区别在于，loadbalancer会自动在外部创建一个调度器将当前的nodeport端口进行流量访问，实现高可用，但是必须得借助云平台创建LB来向节点导流。

loadBalancer 和 nodePort 其实是同一种方式。区别在于 loadBalancer 比 nodePort 多了一步，就是可以调用 cloud provider 去创建 LB 来向节点导流

vim loadbalancer.yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-loadbalancer    #服务的名称，这里是 myapp-loadbalancer。
spec:
  selector:
    app: myapp # 匹配带有相应标签的 Pods。在这个例子中，它匹配所有标签为 app: myapp 的 Pods。
  type: LoadBalancer    #为 LoadBalancer，表明我们想要的服务类型是负载均衡器。
  ports:                #服务的端口配置；
  - protocol: TCP
    port: 80            #服务内部端口，外部请求会到这个端口；
    targetPort: 8080    #Pods 上的端口，服务会将流量从内部端口转发到此端口；
    # 如果云提供商支持，也可以指定一个负载均衡器的外部端口，例如：
    # nodePort: 30000    #（可选）如果指定，这是节点上用来接收外部流量的端口

kubectl apply -f loadbalancer.yaml

kubectl get svc myapp-loadbalancer

6.ExternalName创建

        这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容( 例如：hub.aaa.com )。ExternalName Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和 Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。

kind: Service
apiVersion: v1
metadata:			#元数据
  name: my-service	#当前service名为my-service
  namespace: default	#放在default名称空间下
spec:
  type: ExternalName	#当前的类型为ExternalName类型
  externalName: hub.aaa.com	# ExternalName的值为hub.hongfu.com

# my-service.defalut.svc.cluster.local这是在集群内可以访问到的域名，如果将他的值找dns解析，解析的应该是hub.aaa.com。

例如：

         我有一个pod，我去访问一个web服务，web服务就是hub.hongfu.com，就可以靠这个svc指向这个hub.aaa.com，如果有一天我想指向harbor，那只要dit将这个值指向haobor，他就指过来了，对于pod来说，不需要做任何改变。

        当查询主机 my-service.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local )时，集群的 DNS 服务将返回一个值 my.database.example.com 的 CNAME 记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发