kubernetes基础知识之service模式中的ClusterIP

kubernetes service的ipvs有三种运行模式：

①：NAT网络地址转换模式

好处：后端端口和集群端口可以不一致

缺点：当前流量必须经过ipvs调度器本身，不管是入站还是出站方向。

②：DR直接路由模式

好处：回程流量不需要经过负载接收器，本身压力会更小。

缺点：它可能需要对ARP的响应和连通性做设定，而且后端的端口和负载均衡集群的端口必须一致。

③：TUN隧道模式

缺点：它的性能会比较低。因为需要跨越多个公网物理环境，而且还需要做数据报文的二次封装。

优点：可以跨公网网络进行集聚化的组建。

还有fullnat模式，也是ipvs的转发模式。

当前的kubernetes集群采用的是ipvs的NAT模式。当前kubernetes集群的kube-proxy，也就是kubernetes集群创建的service采用NAT模式，因为它创建的集群端口和后端服务器的端口可以不一致。

每一个服务器上的ipvs规则只会被当前服务器的客户端所使用，另外一个节点的客户端并不会访问我这个节点的ipvs规则，会访问它自己机器的ipvs规则，这就导致了每个node 节点的压力都不会太大。既然这样的话，那还不如选择node的方式，可以保证我们的端口不一致，这就是灵活性的体现。

下面是一个clusterIP类型服务的资源清单：

touch clusterip_service.yaml

apiVersion: v1

kind: Service

metadata:

name: myapp-clusterip

namespace: default

spec:

type: ClusterIP

selector:

app: myapp

release: stabel

svc: clusterip

ports:

- name: http

port: 80

targetPort: 80

通过create创建的服务，它有一个默认值的关系。就是它会通过匹配app等于当前service的名字作为匹配条件。

创建服务：

kubectl create service clusterip myapp --tcp=80:80

--tcp代表一个tcp类型的负载均衡集群，第一个80代表集群端口，第二个80代表当前真实服务器的端口。

kubectl create service clusterip myapp --tcp=80:80 --dry-run -o yaml

这样可以导出资源清单，--dry-run表示试运行，不真正执行命名，用来测试命令是否正确，并不会真正创建出来资源，去掉这个--dry-run参数后，即可真正执行命令。

这样执行了命令：

kubectl create service clusterip myapp --tcp=80:80

这时selector选择器里面有一个默认值，它的标签app等于myapp。

如果是自己编辑的资源清单文件，那么想写几个就写几个。

clusterip类型服务使用deployment控制器创建pod的资源清单文件：

vim deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name:myapp-clusterip-deploy

namespace: default

spec:

replicas: 3

selector:

matchLabels:

app: myapp

release: stabel

svc: clusterip

template:

metadata:

labels:

app: myapp

release: stabel

env: test

svc: clusterip

spec:

containers:

- name: myapp-container

image: xxx/nginx:v1

imagePullPolicy: Always

ports:

- name: http

containerPort: 80

readinessProbe:

httpGet:

port: 80

path: /index.html

initialDelaySeconds: 1

periodSeconds: 3

控制器的selector是标签选择器的标签，template也就是怎么创建pod。pod的标签在template的labels里面定义，deployment这个pod控制器的标签应该是pod标签的子集。

基于资源文件创建pod:

kubectl apply -f deployment.yaml

查看pod创建情况：

kunectl get pod -n $namespace_name

service标签如果要匹配pod的话，需要满足两个条件：

①：pod处于就绪状态

②：pod标签是svc标签的集合（同一个命名空间下）。

创建service服务的资源清单文件：

touch myapp-service.yaml:

apiVersion: v1

kind: Service

metadata:

name:myapp-clusterip

namespace: default

spec:

type: ClusterIP

selector:

app: myapp

release: stable

svc: clusterip

ports:

- name: http

port: 80

targetPort: 80

如果不指定服务的类型type的话，默认值就是:ClusterIP。

端口ports里面的port代表是负载均衡集群的端口。

端口ports里面的targetPort代表当前的后端真实服务器的端口。

可以基于资源清单创建服务，也可以使用kubectl create service clusterip 的方式创建服务，在指定这个命令的时候，它的背后也会转变成资源清单，不是yaml格式，而是json格式。

当我们提交yaml格式的资源文件给kubectl命令时，向kube-apiserver发送命令的时候，已经变成了json格式。因为kubectl和kubernetes集群没有明显的关联性，不是说必须把kubectl部署在kubernetes集群的节点上，也完全可以把kubectl部署在非kubernetes集群中。也就是意味着从yaml到Jason的转换不再消耗kubernetes集群资源。

基于资源清单创建service:

kubectl apply -f myapp-service.yaml

查询服务信息：

kubectl get svc -n $namespace_name

clusterip类型的clusterip实际上就是ipvs的VIP，ports是集群端口。

查看pod的详细信息：

kubectl get pod -n $namespace_name

查看ipvs集群信息：

ipvsadm -Ln

查询pod的标签信息：

kubectl get pod -n $namespace_name --show-labels

进入pod容器的命令：

kubectl exec -it $pod_name -n $namespace_name -- /bin/sh

查看pod信息：

kubectl get pod -n $namespace_name

查看负载均衡情况：

ipvsadm -Ln

clusterIP类型的服务是集群内部的访问方式。如果想访问这个这个服务service，需要先执行：

kubectl get svc -n $namespace_name

查看到当前服务service的负载均衡的VIP，再执行:

curl $VIP

还有另外一种方法是借助DNS插件，每一个service服务创建完成之后，都会有一个DNS的域名。在我们的DNS插件被解析，解析的地址就是当前的CLUSTER-IP。

先安装工具包：

yum install bind-utils -y

bind是伯克利大学的一个域名解析服务，utils是工具包。使用这个DNS测试工具执行：

dig -t -A
myapp-clusterip.default.svc.cluster.local. @DNS解析服务器的负载均衡VIP地址。

-t代表tcp解析,-A代表A记录。解析的域名是service的格式，每个service创建完成以后，都会在DNS中形成一个域名。域名的格式是： 当前service名字.当前命名空间名字.svc.当前域名。.svc是固定字符，当前域名叫cluster.local。如果在初始化kubernetes集群的时候，没有指定域名，默认就是cluster.local。clusterip类型的服务是在集群内部使用的，改不改默认域名影响不大。

查询service服务名：

kubectl get svc -n $namespace_name

查看DNS解析服务器的负载均衡VIP地址：

kunectl get pod -n kube-system -o wide | grep dns

查看dns的负载均衡VIP地址：

ipvsadm -Ln

查询dns的负载均衡集群的VIP地址。

对于DNS来说，一般tcp的53号端口用来同步数据，UDP的53号端口用来做地址解析。如果UDP多次不解析的话，也会允许到tcp解析。

现在很多厂商基于http协议封装DNS解析过程。

我们要想访问DNS服务的话，必须要找到dns解析pod所对应的dns负载均衡的VIP地址。

然后使用dig -t -A
myapp-clusterip.default.svc.cluster.local. @DNS解析服务器的负载均衡VIP地址，就可以成功解析服务对应的IP地址了。

查看服务service信息：

kubectl get svc -n $namespace_name

物理机的DNS是自己指定的，但是kubernetes及其内部的pod它的默认DNS都是指向两个DNS的插件上。不需要配置，就可以解析通过。

进入pod的命令：

kubectl exec -it $pod_name -- /bin/sh

wget http://$service_name.$namespace_name.svc.cluster.local./hostname.html && cat hostname.html && rm -rf hostname.html

在kubernetes集群内部的pod，它默认就把DNS指向到了DNS插件上了，所以域名是可以直接调用的。

两种访问service的方式：

①：通过service的IP。

②：通过service的域名。

service_ip的好处就是直接看，缺点在于当service没有创建出来的话，不知道IP地址是多少。但是通过域名访问就可以知道，只要知道service名、所在的命名空间、集群的域名，就知道创建之后它的访问IP是什么，或者它的访问域名是什么。哪怕service还没开始创建呢，就可以开始编写一个pod访问这个service的域名了。

通过IP访问clusterip类型的服务，更简单一点。通过域名访问service，可以更前置化一些。

service 通过DNS访问的域名格式：

svcName.nsName.svc.domainName.

服务名.命名空间名.svc关键字.集群域名.

可以加一个点，表示根域。

鼓励的话语：男子汉要有血性、有豪情，要宁折不弯！