service-凯发k8国际娱乐官网入口

直接访问pod的问题

负载创建完成后，如何访问负载呢？访问负载实际上就是访问pod，但是直接访问pod会有如下几个问题：

• pod会随时被deployment这样的控制器删除重建，那访问pod的结果就会变得不可预知。
• pod的ip地址是在pod启动后才被分配，在启动前并不知道pod的ip地址。
• 应用往往都是由多个运行相同镜像的一组pod组成，一个个pod的访问也变得不现实。

举个例子，假设有这样一个应用程序，使用deployment创建了前台和后台，前台会调用后台做一些计算处理，如图1所示。后台运行了3个pod，这些pod是相互独立且可被替换的，当pod出现状况被重建时，新建的pod的ip地址是新ip，前台的pod无法直接感知。

图1 负载间访问

service是如何工作的

kubernetes中的service对象就是用来解决上述pod访问问题的。service有一个固定ip地址，service将访问他的流量转发给pod，具体转发给哪些pod通过label来选择，而且service可以给这些pod做负载均衡。

那么对于上面的例子，通过为前后台添加两个service，通过service来访问pod，这样前台pod就无需感知后台pod的变化，如图2所示。

图2 通过service访问pod

创建service

下面示例创建一个名为“nginx”的service，通过selector选择到标签“app:nginx”的pod，目标pod的端口为80，service对外暴露的端口为8080。

访问服务只需要通过“服务名称:对外暴露的端口”接口，对应本例即“nginx:8080”。这样，在其他负载中，只需要通过“nginx:8080”就可以访问到“nginx”关联的pod。

apiversion: v1
kind: service
metadata:
  name: nginx        # service的名称
spec:
  selector:          # label selector，选择包含app=nginx标签的pod
    app: nginx
  ports:
  - name: service0
    targetport: 80   # pod的端口
    port: 8080       # service对外暴露的端口
    protocol: tcp    # 转发协议类型，支持tcp和udp
  type: clusterip    # service的类型

在原生kubernetes中，service还有nodeport类型，当前云容器实例不支持使用nodeport类型service。

将上面service的定义保存到nginx-svc.yaml文件中，使用kubectl创建这个service。

# kubectl create -f nginx-svc.yaml -n $namespace_name
service/nginx created
# kubectl get svc -n $namespace_name
name       type        cluster-ip       external-ip   port(s)         age
kube-dns   clusterip   10.247.9.190             53/udp,53/tcp   7m
nginx      clusterip   10.247.148.137           8080/tcp        1h

您可以看到service有个cluster ip，这个ip是固定不变的，除非service被删除，所以您也可以使用clusterip在内部访问service。

kube-dns是预留给域名解析使用的service，云容器实例会自动创建，域名解析的详细内容请参见使用servicename访问service。

使用servicename访问service

云容器实例中您可以使用插件给service做域名解析，然后使用“servicename:port”访问service，这也是kubernetes中最常用的一种使用方式，coredns的安装请参见。

coredns安装成功后会成为dns服务器，当创建service后，coredns会将service的名称与ip记录起来，这样pod就可以通过向coredns查询service的名称获得service的ip地址。

访问时通过nginx..svc.cluster.local访问，其中nginx为service的名称，为命名空间名称，svc.cluster.local为域名后缀，在实际使用中，可以省略.svc.cluster.local，直接使用service的名称即可。

例如上面创建的名为nginx的service，直接通过“nginx:8080”就可以访问到service，进而访问后台pod。

使用servicename的方式有个主要的优点就是可以在开发应用程序时可以将servicename写在程序中，这样无需感知具体service的ip地址。

coredns插件占用计算资源，共2个pod，每个pod占用0.5核1g的资源，您需要为此付费。

loadbalancer类型的service

现在您知道可以创建clusterip类型的service，通过service的ip可以访问到service后端的pod。

云容器实例同时还支持创建loadbalancer类型的service，将增强型elb实例与service绑定，这样访问elb实例的流量就会访问到service。

elb实例根据ip地址不同可以分为私网elb实例和公网elb实例，区别在于公网elb实例绑定了一个公网ip，您可以根据需要选择。您可以调用创建elb实例，更方便的方法是通过创建增强型elb实例。

• elb实例必须与service在同一个vpc内，否则无法绑定。
• 跨namespace不支持service或elb域名访问，只能通过elb内网ip:端口访问。

图3 loadbalancer service

apiversion: v1
kind: service
metadata:
  name: nginx
  annotations:
    kubernetes.io/elb.id: 77e6246c-a091-xxxx-xxxx-789baa571280  # elb的id
spec:
  selector:
    app: nginx
  ports:
  - name: service0
    targetport: 80
    port: 8080         # elb访问端口
    protocol: tcp
  type: loadbalancer   # service的类型