Kubernetes系列之理解K8s Service的几种模式

今天给你们介绍下k8s的service的几种访问模式。

概述

---

咱们知道pod的ip不是固定的，是根据所在宿主机的docker0网卡生成的，每次重启，更新，调度等状况IP都会变，那pod与pod之间须要互相调用，确定不能用ip的，由于地址不是固定的， 如何能保障pod以前访问的可靠性，由此就衍生出Service的概念。

在实际生产环境中，通常有两种访问 对集群内部的访问， 集群外部的访问。service如今分为如下类型

ClusterIP        

集群内部容器访问地址，会生成一个虚拟IP 与pod不在一个网段。

NodePort         

会在宿主机上映射一个端口，供外部应用访问模式。

Headless CluserIP   

无头模式，无serviceip，即把spec.clusterip设置为None 。

LoadBalancer   

使用外部负载均衡。

Port类型

---

咱们先理解Service Port的几种类型。

NodePort

指定暴露到宿主机的端口，不指定的话会随机分配个，分配的IP在apiserver的配置文件中指定了--service-node-port-range=30000-50000，表示只容许分配30000-50000之间的端口。

好比一个nginx应用须要能被外部访问，就须要配置类型为type=NodePort,而且须要配置下nodePort: 30002(指定固定端口)，这样的话外部使用http://ip:30002就能够访问这个应用了。

也有一些内部服务是须要外部访问的，那就不须要到使用NodePort模式了。

apiVersion: v1

Port

集群内部服务之间访问的端口。

好比一个nginx容器暴露了80端口，可是其余容器须要经过nginx:80访问，就须要配置port:80 ,外部是无法访问这个端口的，由于没有对外开放端口。

apiVersion: v1

targetPort

容器自己暴露的端口，和dockerfile中的expose意思同样

例子说明

---

接下来咱们经过几个例子来理解说明

建立NodePort类型Service

若是选择了“NodePort”，那么 Kubernetes master 会分配一个区域范围内，（默认是30000-32767），而且，每个node，都会代理（proxy）这个端口到你的服务中，咱们能够在spec.ports[*].nodePort 找到具体的值

若是咱们指定一个端口，咱们能够直接写在nodePort上，系统就会给你指派指定端口，可是这个值必须是指定范围内的。

Cluster service 的 IP 地址是虚拟的，所以，只能从node节点上使用该IP 地址访问应用。为了从集群外访问应用，K8S 提供了使用 node 节点的IP 地址访问应用的方式。

基本上，NodePort 服务与普通的 “ClusterIP” 服务 YAML 定义有两点区别。 首先，type 是 “NodePort”。还有一个称为 nodePort 的附加端口，指定在节点上打开哪一个端口。 若是你不指定这个端口，它会选择一个随机端口。

 该端口号的范围是 kube-apiserver 的启动参数 –service-node-port-range指定的，在当前测试环境中其值是 30000-50000。表示只容许分配30000-50000之间的端口。

ps：通常使用NodePort 都会在外部搭建负载均衡来代理多个node节点。

建立一个Deployment

[root@master-01 ~]# cat nginx-deploy.yaml 

建立service 

[root@master-01 ~]# cat ng-svc.yaml 

查看详情

[root@master-01 ~]# kubectl  describe  svc  nginx

查看状态

[root@master-01 ~]# kubectl  get po,ep,svc

访问测试

# 经过endpoint 访问

在pod中也能够经过service的名称访问（通常都这样使用）

建立ClusterIP类型Service

会生成一个集群内部的虚拟IP（网段和pod不一样）只是给集群内部和pod之间访问的，外部没法访问，网段经过配置文件指定。

ClusterIP也是Kubernetes service的默认类型。

原理

用户经过kubectl命令向apiserver发送建立service的命令，apiserver接收到请求之后将数据存储到etcd中。

每一个节点中都有一个叫作kube-proxy的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables中。

iptables 使用NAT等技术将virtualIP的流量转至endpoint中。

建立pod

[root@master-01 ~]# cat nginx-deployment.yaml

建立Service

[root@master-01 ~]# cat ng-svc-clusterip.yaml 

建立HeadlessClusterIP类型Service

有时候咱们可能不须要一个固定的IP和分发，这个时候咱们只须要将spec.clusterIP的值设置为none就能够了，经过设置标签绑定到pod的方式完成，对于这样的服务来讲，集群IP没有分配，这个时候当你查询服务的名称的时候，DNS会返回多个A记录，这些记录都是指向后端Pod的。Kube-proxy代理不会处理这个服务，在服务的前端也没有负载均衡器。可是endpoints controller仍是会建立Endpoints,在访问服务的时候返回后端的所有的Pod IP地址。

建立pod

[root@master-01 ~]# cat busybox-deploy.yaml 

建立service

[root@master-01 ~]# cat busybox-svc-headless.yaml 

查看状态

能够看到CLUSTER-IP  为None了，

[root@master-01 ~]# kubectl  get svc,ep,po

以上能够看出后端的pod列表已经加到该svc。

咱们进容器中经过service名字是否可以解析访问到pod

查看dns域

root@busybox-deploy-b47575595-khxsp:/# cat /etc/resolv.conf 

能够看到以上的A记录，解析出的是pod的ip地址

1.普通 Service：解析成 ClusterIP

2.Headless Service：解析为指定 Pod的IP列表，Serivce域名也起到了经过dns作负载的能力。

往期文章一览

一、Kubernetes集群搭建之系统初始化配置篇

二、Kubernetes集群搭建之企业级环境中基于Harbor搭建本身的私有仓库

三、Kubernetes集群搭建之Etcd集群配置篇

四、Kubernetes集群搭建之CNI-Flanneld部署篇**

五、Kubernetes集群搭建之Master配置篇

六、Kubernetes系列之Coredns and Dashboard介绍篇

7、Kubernetes系列之监控Metres-server实战篇

若是您以为不错，请别忘了转发、分享、点赞让更多的人去学习， 您的举手之劳，就是对小编最好的支持，很是感谢！