一、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算法。
kube-proxy ipvs模式
开启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的工作过程，如下:
deployment-xuq.yaml
创建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-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:
Annotations:
Selector: app=lable-nginx-xuq
Type: ClusterIP
IP: 10.87.87.88
Port: 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:
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
命名空间
nginx pod
tomcat-pod
它俩的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