一、Service 介绍

k8s中，pod是应用程序的载体，我们可以通过pod的ip地址来访问应用程序，但是pod的IP地址是不固定的，这就意味着不方便直接采用pod的IP对服务进行访问。

为了解决这个问题，k8s提供了Service资源，service会对提供同一个服务的多个pod进行汇聚，并且提供一个统一的入口地址，通过访问service的入口地址就能访问到后面的pod服务。

Service在很多情况下只是一个概念，真正起作用的是kube-proxy服务进程，每个node节点上都运行了一个kube-proxy的服务进程，当创建service的时候会通过apiserver向etcd写入创建的service信息，而kube-proxy会基于监听的机制发现这种service的变化，然后会将新的service信息转换为对应的访问规则。

例如 10.87.87.88:80 是svc提供的访问入口，当访问这个入口时，可以发现后面有三个pod服务在等待调用，kube-proxy会基于轮询算法，将请求分发到其中一个pod上。这个规则会同时在集群内的所有节点上生成，所以在任何一个节点上访问都可以。

[root@k8s-n1 ~]# ipvsadm -Ln

IP Virtual Server version 1.2.1(size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

TCP 10.87.87.88:80 rr

->10.244.1.31.80 Masq 1 0 0

->10.244.1.33.80 Masq 1 0 0

->10.244.1.36.80 Masq 1 0 0

二、kube-proxy支持的三种工作模式

userspace模式:

userspace模式下，kube-proxy会为每个service创建一个监听端口，发向cluster ip的请求被iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个提供服务的pod并和其建立连接，以便将请求转发到pod上。

该模式下，kube-proxy充当了一个四层负载均衡器的角色，由于kube-proxy运行在userspace中，在进行转发处理的时候会增加内核和用户空间之间的数据拷贝，虽然比较稳定，但是效率非常低。

ipvs模式:

ipvs模式和iptables类似，kube-proxy监控pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率会更高，除此之外，ipvs支持更多的LB算法。

开启ipvs模式

1、安装ipvs内核模块

要使用ipvs必须安装它的内核模块，不然会降级为iptables模式

2、设置mode=ipvs

kubectl edit cm kube-proxy -n kube-system

3、删除

kubectl delete pod -l k8s-app=kube-proxy -n kube-system

4、测试ipvs模块是否开启成功

三、service有哪些类型

ClusteIP: 默认值，它是k8s系统自动分配的虚拟ip，只能在集群内部访问。

NodePort: 将service通过指定的node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务。

LoadBalancer: 使用外接负载均衡器完成到服务的负载分发，注意此模式需要外部云环境支持。

ExternalName: 把集群外部的服务引入集群内部，直接使用。

3.1、我们先通过deployment创建出3个pod，来了解svc的工作过程，如下:

创建pod

kubectl create -f deployment-xuq.yaml

查看pod信息,--show-labels表示显示标签

kubectl get pod -n ns-test-xuq -o wide --show-labels

进入pod里的容器里

kubectl exec -it deployment-xuq-3678f2fc9f-0wqk3(pod名) -c gq-nginx-xuq(容器名) -n ns-test-xuq /bin/sh

在进入pod里的容器后，向nginx首页文件添加内容

echo 'hello 10.244.2.66' >/usr/share/nginx/html/index.html

然后退出 容器

exit

3.2、ClusterIP类型的service

svc-clusterip.yml

创建svc

kubectl create -f svc-clusterip.yml

查看svc信息

kubectl get svc -n ns-test-xuq -o wide

查看svc更详细信息

kubectl describe svc svc-clusterip-xuq -n ns-test-xuq

[root@k8s-m1 ~]# kubectl describe svc svc-clusterip -n ns-test-xuq
Name: svc-clusterip-xuq
Namespace: ns-test-xuq
Labels: <none>
Annotations: <none>
Selector: app=lable-nginx-xuq
Type: ClusterIP
IP: 10.87.87.88
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 10.244.1.6:80,10.244.1.7:80,10.244.1.8:80
Session Affinity: None
Events: <none>

Endpoint是k8s中的一个资源对象，存储在etcd中，用来记录一个svc对应的所有pod的访问地址，它是根据svc配置文件中的selector描述产生的

一个svc由一组pod组成，这些pod通过endpoint暴露出来，endpoint是实现实际服务的端点集合，也就是说svc和pod之间的联系是通过endpoint实现的。

查看ipvs的映射规则

ipvsadm -Ln

删除svc

kubectl delete -f svc-clusterip.yml

3.3、ClusterIP类型的SVC之HeadLiness

在一些场景下，开发人员可能不想使用service提供的负载均衡功能，而希望自己来控制负载均衡策略，针对这种情况，

k8s提供了headliness service,这类service不会分配clusterIP，如果想要访问svc，只能通过它的域名进行查询。

svc-headliness.yml

kubectl create -f svc-headliness.yml

kubectl get svc service-headliness -n test -o wide

kubectl describe svc service-headliness -n test

kubectl exec -it deployment-xuq-3678f2fc9f-0wqk3 -n dev /bin/sh

cat /etc/resolv.conf

dig @10.96.0.12 service-headliness.dev.svc.cluster.local

3.4、NodePort类型的service

在之前的案例中，创建的svc的IP地址只能在集群内部才可以访问，如果希望svc暴露给集群外部使用，那么久需要使用到另外一种类型的svc，称为NodePort类型的svc。nodeport的工作原理就是将svc的端口映射到node的一个端口上，然后就可以通过nodeIP: NodePort来访问svc了。

svc-nodeport.yaml

kubectl create -f svc-nodeport.yaml

kubectl get svc svc-nodeport -n ns-test-xuq -o wide

通过浏览器访问: http://192.168.128.100:30002 访问对应的pod

3.5、LoadBalancer类型的svc

LoadBalancer和NodePort很相似，目的都是向外部暴露一个端口，区别在于LoadBalancer会在集群的外部再来做一个负载均衡设备，而这个设备需要外部环境的支持，外部服务发送到这个设备上的请求，会被设备负载之后转发到集群中。

3.6、ExternalName类型的Service

ExternalName类型的service用于引入集群外部的服务，它通过externalName属性指定一个服务的地址，然后在集群内部访问此service就可以访问到外部服务了。

创建svc-externalname.yaml文件

# 使用时 要调整缩进
apiVersion: v1
kind: Service
metadata:
name: svc-externalname
namespace: test
spec:
type: ExternalName # svc类型为ExternalName
externalName: www.aa.com # 使用ip也行

kubectl create -f svc-externalname.yaml

dig @10.96.0.12 svc-externalname.test.svc.cluster.local

四、Ingress

Ingress 概述

通过前面的学习，我们知道，service对外暴露服务的方式有两种:NodePort和LoadBalancer，但是这两种方式，都有一定的缺点。

首先NodePort方式的缺点是会占用很多集群的端口，那么当集群服务变多的时候，这个缺点就愈发明显。

其次LoadBalancer的缺点是每个svc都需要一个LB，浪费，麻烦，并且需要k8s之外的设备支出

基于它俩的情况，k8s提供了Ingress资源对象，Ingress只需要一个NodePort或者一个LB就可以满足暴露多个svc的需求，工作机制大致如下:

实际上，ingress相当于一个七层的负载均衡器，是k8s对反向代理的一个抽象，它的工作原理类似于nginx，可以理解为ingress里面建立了诸多规则，ingress controller通过监听这些配置规则并转化为nginx的反向代理配置，然后对外提供服务。

ingress: k8s中的一个对象，作用是定义请求如何转发svc的规则

ingress Controller: 具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析,根据配置的规则来实现请求转发，实现的方式有很多，如nginx、contour、haproxy等。

ingress的工作过程如下:

1、用户编写ingress规则，说明哪个域名对应k8s中的哪个svc，

2、ingress控制器动态感知ingress服务规则的变化，然后生成一段对应的nginx反向代理配置

3、ingress控制器会将生成的nginx配置写入到一个运行的nginx服务中，并动态更新。

4、到此为止，其实真正在工作的就是一个nginx，内部配置了用户定义的请求规则。

4.2、ingress的使用

创建 ingress-controller目录并下载控制器

mkdir -pv opt/ingress-controller && cd /opt/ingress-controller

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml

kubectl apply -f ./

kubectl get pod -n ingress-nginx

kubectl get svc -n ingress-nginx

然后准备测试的pod，以nginx和tomcat为例及相应的svc

它俩的svc

创建http代理，如下:

ingress-http.yaml

kubectl create -f ingress-http.yaml

kubectl get ingress ingress-http -n test

kubectl describe ingress ingress-http -n test

192.168.1.112 nginx.service

192.168.1.112 tomcat.service

kubectl get svc -n ingress-nginx # 获取端口

浏览器访问 http://tomcat.service:31765

----

https代理

生成证书

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/C=CN/ST=BJ/L=BJ/O=nginx/CN=haxuq.com"

创建密钥:

kubectl create secret tls tls-secret --key tls.key --cert tls.crt

创建ingress-https.yaml

kubectl create -f ingress-https.yaml

kubectl get ingress ingress-https -n test

kubectl describe ingress ingress-https -n test

浏览器访问: https://tomcat.haxuq.com:31235