Kubernetes学习(七)——Service

落月剑在手

本章节次要引见kubernetes的流量背载组件：Service战Ingress。
1 Service引见

正在kubernetes中，pod是使用程序的载体，我们能够经由过程pod的ip去会见使用程序，可是pod的ip地点没有是牢固的，那也便意味着没有便利间接采纳pod的ip对效劳停止会见。
为理解决那个成绩，kubernetes供给了Service资本，Service会对供给统一个效劳的多个pod停止散开，并且供给一个赞成的进口地点。经由过程会见Service的进口地点就可以会见到前面的pod效劳。

Service正在很多状况下只是一个观点，实正起感化的实际上是kube-proxy效劳历程，每一个Node节面上皆运转着一个kube-proxy效劳历程。当创立Service的时分会经由过程api-server背etcd写进创立的service的疑息，而kube-proxy会基于监听的机造发明这类Service的变动，然后他会将最新的Service的疑息转换成对应的会见划定规矩。

# 10.97.97.97:80 是service供给的会见进口
# 当会见那个进口的时分，能够发明前面有三个pod的效劳正在等候挪用，
# kube-proxy会基于rr(轮询)的战略，将恳求分收到此中一个pod上来
# 那个划定规矩会同时正在散群内乱的一切节面上皆天生，以是正在任何一个节面上会见皆能够.
[root@node ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.97.97.97:80 rr
-> 10.244.1.39:80 Masq 1 0 0
-> 10.244.1.40:80 Masq 1 0 0
-> 10.244.1.33: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中，正在停止转收处置时会增长内乱核战用户空间之间的数据拷贝，固然比力不变，可是服从比力低。

iptables形式
iptables形式下，kube-proxy为service后真个每一个Pod创立对应的iptables划定规矩，间接将收背Cluster IP的恳求重定背到一个Pod IP。
该形式下kube-proxy没有负担四层背载平衡器的脚色，只卖力创立iptables划定规矩。该形式的长处是较userspace形式服从更下，但不克不及体用灵敏的LB战略，当后端Pod不成用时也没法停止重试。

ipvs形式
ipvs形式战iptables相似，kube-proxy监控Pod的变化并创立响应的ipvs划定规矩。ipvs相对iptables转收服从更下。除此以外，ipvs撑持更多的LB算法。

# 此形式必需装置ipvs内乱核模块，不然会升级为iptables
[root@master ~]# yum install ipvsadm -y
# 开启ipvs,正在mode:"ipvs"
[root@master ~]# kubectl edit cm kube-proxy -n kube-system
[root@master ~]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system
[root@master ~]# ipvsadm -Lb
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 10.97.97.97:80 rr -> 10.244.1.39:80 Masq 1 0 0
-> 10.244.1.40:80 Masq 1 0 0
-> 10.244.1.33:80 Masq 1 0 0

复造代码

2 Service范例

Service的资本浑单文件：

kind: Service # 资本范例
apiVersion: v1 # 资本版本
metadata: # 元数据
name: service # 资本称号
namespace: dev # 定名空间
spec: # 详细形貌
selector: # 标签挑选器，用于肯定当前service的代办署理哪些pod
app: nginx
type: # Service范例，指定service的会见方法
clusterIP: # 假造效劳的ip地点
sessionAffinity: # session亲战性，撑持ClienetIP、None两个选项
ports: # 端心疑息
- protocol: TCP
port: 3017 # service端心
targetPort: 5003 # pod端心
nodePort: 31122 # 主机端心

复造代码

ClusterIP：默许值，它是Kubernetes体系主动分派的假造IP，只能正在散群内乱部会见
NodePort：将Service经由过程指定的Node上的端心裸露给内部，经由过程此办法，就能够正在散群内部会见效劳
LoadBalancer：利用中接背载平衡完成到效劳的背载分收，留意此形式需求内部云状况撑持
ExternalName：把散群内部的效劳引进散群内乱部，间接利用

3 Service利用

3.1 尝试状况筹办

正在利用service之前，起首操纵Deployment创立出3个pod,留意要为pod设置app=nginx-pod的标签
创立deploymenet.yaml，内乱容以下：

apiVersion: apps/v1
kind: Deployment
metadata:
name: pc-deployment
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80

复造代码

[root@master ~]# kubectl create -f deployment.yaml
deployment.apps/pc-deployment created
# 检察pod详情
[root@master ~]# kubectl get pods -n dev -o wide --show-labels
NAME READY STATUS IP NODE LABELS
pc-deployment-66cb59b984-8p84h 1/1 Running 10.244.1.40 node1 app=nginx-pod
pc-deployment-66cb59b984-vx8vx 1/1 Running 10.244.2.33 node2 app=nginx-pod
pc-deployment-66cb59b984-wnncx 1/1 Running 10.244.1.39 node1 app=nginx-pod
# 为了便利前面的测试，修正下三台nginx的index.html页里（三台修正的IP地点纷歧致）
# kubectl exec -it pc-deployment-66cb59b984-8p84h -n dev /bin/sh
# echo "10.244.1.40" > /usr/share/nginx/html/index.html
# 修正终了以后，会见测试
[root@master ~]# curl 10.244.1.4010.244.1.40
[root@master ~]# curl 10.244.2.330.244.2.33
[root@master ~]# curl 10.244.1.3910.244.1.39

复造代码

3.2 ClusterIP范例的Service

创立service-clusterip.yaml文件

apiVersion: v1
kind: Service
metadata:
name: service-clusterip
namespace: dev
spec:
selector:
app: nginx-pod
clusterIP: 10.97.97.97 # service的ip地点，假如没有写，默许会天生一个
type: ClusterIP
ports:
- port: 80 # Service端心
targetPort: 80 # pod端心

复造代码

# 创立service[root@master ~]# kubectl create -f service-clusterip.yaml
service/service-clusterip created
# 检察service
[root@master ~]# kubectl get svc -n dev -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service-clusterip ClusterIP 10.97.97.97 <none> 80/TCP 13s
# 检察service的具体疑息
# 正在那里有一个Endpoints列表，内里便是当前service能够背载到的效劳器进口
[root@master ~]# kubectl describe svc service-clusterip -n dev
Name: service-clusterip
Namespace: dev
Labels: <none>
Annotations: <none>
Selector: app=nginx-pod
Type: ClusterIP
IP: 10.97.97.97
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 10.244.1.39:80,10.244.1.40:80,10.244.2.33:80
Session Affinity: None
Events: <none>
# 检察ipvs的映照划定规矩
[root@master ~]# ipvsadm -Ln
TCP 10.97.97.97:80 rr
-> 10.244.1.39:80 Masq 1 0 0
-> 10.244.1.40:80 Masq 1 0 0
-> 10.244.2.33:80 Masq 1 0 0
# 会见10.97.97.97:80察看结果
[root@master ~]# curl 10.97.97.97:8010.244.2.33

复造代码

Endpoirt
Endpoint是kubernetes中的一个资本工具，存储正在etcd中，用去记载一个service对应的一切pod会见地点，它是按照service婚配文件中selector形貌发生的。
一个Service由一组Pod构成，那些Pod经由过程Endpoints裸露出去，Endpoints是完成是效劳的端面会萃。换句话道，service战pod之间的联络是经由过程endpoints完成的。

[root@master ~]# kubectl get endpoints -n dev -o wide
NAME ENDPOINTS AGE
service-clusterip 10.244.1.39:80,10.244.1.40:80,10.244.2.33:80 50m

复造代码

背载分收战略
对Service的会见被分收到了后真个Pod上来，今朝kubernetes供给了两种背载分收战略：

假如没有界说，默许利用kube-proxy测战略，好比随机、轮询
基于客户端地点的会话连结形式，即去自统一个客户端倡议的一切恳求城市转收到一个牢固的Pod上，此形式可使正在spec中增加sessionAffinity: ClientIP选项

# 检察ipvs的映照划定规矩(rr 轮询)[root@master ~]# ipvsadm -Ln
TCP 10.97.97.97:80 rr
-> 10.244.1.39:80 Masq 1 0 0
-> 10.244.1.40:80 Masq 1 0 0
-> 10.244.2.33:80 Masq 1 0 0
# 轮回会见测试
[root@master ~]# while true;do curl 10.97.97.97:80; sleep 5;done;
10.244.1.40
10.244.1.39
10.244.2.33
10.244.1.40
10.244.1.39
10.244.2.33
# 修正分收战略----sessionAffinity:ClientIP
# 正在设置文件service-clusterip.yaml的spec下增加：sessionAffinity:ClientIP
# 检察ipvs划定规矩【persistent 代表耐久】
[root@master ~]# ipvsadm -Ln
TCP 10.97.97.97:80 rr persistent 10800
-> 10.244.1.39:80 Masq 1 0 0
-> 10.244.1.40:80 Masq 1 0 0
-> 10.244.2.33:80 Masq 1 0 0
# 轮回会见测试
[root@master ~]# while true;do curl 10.97.97.97:80; sleep 5;done;
10.244.2.33
10.244.2.33
10.244.2.33
# 删除service
[root@master ~]# kubectl delete -f service-clusterip.yaml
service/service-clusterip deleted

复造代码

3.3 HeadLiness范例的Service

正在某些场景中，开拓职员能够没有念利用Service供给的背载平衡功用，而期望本人去掌握背载平衡战略，针对那其中状况，kubernetes供给了HeadLiness Service，那类Service没有会分派ClusterIP，假如念要会见service，只能经由过程service的域名停止查询。
创立service-headliness.yaml

apiVersion: v1
kind: Service
metadata:
name: service-headliness
namespace: dev
spec:
selector:
app: nginx-pod
clusterIP: None # 将clusterIP设置为None，便可创立headliness Service
type: ClusterIP
ports:
- port: 80
targetPort: 80

复造代码

# 创立service[root@master ~]# kubectl create -f service-headliness.yaml
service/service-headliness created
# 获得service,发明CLUSTER-IP已分派
[root@master ~]# kubectl get svc service-headliness -n dev -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service-headliness ClusterIP None <none> 80/TCP 11s app=nginx-pod
# 检察service详情
[root@master ~]# kubectl describe svc service-headliness -n dev -o -wide
Name: service-headliness
Namespace: dev
Labels: <none>
Annotations: <none>
Selector: app=nginx-pod
Type: ClusterIP
IP: None
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 10.244.1.39:80,10.244.1.40:80,10.244.2.33:80
Session Affinity: None
Events: <none>
# 检察域名的剖析状况
[root@master ~]# kubectl exec -it pc-deployment-66cb59b984-8p84h -n dev /bin/sh/
# cat /etc/resolv.confnameserver
10.96.0.10
search dev.svc.cluster.local svc.cluster.local cluster.local
# 假如本机出有dig，需求装置dig东西
[root@master ~]# yum -y install bind-utils
[root@master ~]# dig @10.96.0.10 service-headlilness.dev.svc.cluster.local
service-headliness.dev.svc.cluster.local. 30 IN A 10.244.1.40
service-headliness.dev.svc.cluster.local. 30 IN A 10.244.1.39
service-headliness.dev.svc.cluster.local. 30 IN A 10.244.2.33

复造代码

3.4 NodePort范例的Service

正在之前的样例中，创立的Service的ip地点只要散群内乱部才能够会见，假如期望将Service裸露给散群内部利用，那末便要利用到别的一中范例Service,称为NodePort范例。NodePort的事情道理实在便是将service的端心映照到Node的一个端心上，然后就能够经由过程NodeIp:NodePort去会见service了。

创立service-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
name: service-nodeport
namespace: dev
spec:
selector:
app: nginx-pod
type: NodePort # Service范例
ports:
- port: 80
nodePort: 30002 # 指定绑定的node的端心（默许与值范畴是：30000-32767），假如没有指定，会默许分派
targetPort: 80

复造代码

# 创立service
[root@master ~]# kubectl create -f service-nodeport.yaml
service/service-nodepoint created
# 检察service
[root@master ~]# kubectl get svc -n dev -o wide
NAME TYPE CLUSTER-IP EXTRNAL-IP PORT(S) SELECTOR
service-nodeport NodePort 10.105.64.191 <none> 80:30002/TCP app=nginx-pod
# 接下去能够通诺电脑主机的阅读器来会见散群中随便一个nodeip的30002端心，便可会见到pod.

复造代码

3.5 LoadBalancer范例的Service

LoadBalancer战NodePort实际上是统一种方法，目标皆是背中裸露一个端心，区分正在于LoadBalancer会正在散群的内部再去做一个背载平衡装备，而那个装备需求内部状况撑持的，内部效劳收收到那个装备上的恳求，会被装备背载以后转收到散群中。

3.6 ExternalName范例的Service

ExternalName范例的Service用于引进散群内部的效劳，它经由过程externalName属性指定内部一个效劳的地点，然后正在散群内乱部会见此service就能够会见到内部效劳了。

创立service-externalname.yaml

apiVersion: v1
kind: Service
metadata:
name: service-externalname
namespace: dev
spec:
type: ExternalName # service范例
externalName: www.百度.com # 改成ip地点就能够

复造代码

# 创立service
[root@master ~]# kubectl create -f service-externalname.yaml
service/service-externalname created
# 域名剖析[root@master ~]# dig @10.96.0.10 service-externalname.dev.svc.cluster.local
service-externalname.dev.svc.cluster.local. 30 IN CNAME www.百度.com.
www.百度.com 30 IN CNAME www.a.shifen.com.
www.a.shifen.com. 30 IN A 39.156.66.18
www.a.shifen.com. 30 IN A 39.156.66.14

复造代码

4 Ingress引见

正在前里课程中曾经提到，Service对散群以外裸露效劳的次要方法有两种：NodePort战LoadBalancer，可是那两种方法，皆有必然的缺陷：

NodePort方法的缺陷是会占用很多散群机械的端心，那末当散群效劳变多的时分，那个缺陷便愈创造隐
LB方法的缺陷是每一个service需求一个LB，华侈、费事，并且需求kubernetes以外的装备的撑持。

基于这类近况，kubernetes供给了Ingress资本工具，Ingress只需求一个NodePort大概一个LB就能够满意裸露多个Service的需供。事情机造大抵以下图暗示：

实践上，Ingress相称于一个7层的背载平衡器，是kubernetes对反背代办署理的一个笼统，它的事情道理相似于Nginx,能够了解成正在Ingress里成立诸多映照划定规矩，Ingress Controller经由过程监听那些设置划定规矩并转化成Nginx的设置，然后对内部供给效劳。正在那里有两个核心观点：

ingress：kubernetes中的一个工具，感化便界说恳求怎样转收到service的划定规矩
ingress controller：具体完成收背代办署理及背载平衡的程序，对ingress界说的划定规矩停止剖析，按照设置的划定规矩去完成恳求转收，完成方法有很多，好比Nginx、Contour、Haproxy等等。

Ingress（以Nginx为例）的事情道理以下：

用户编写Ingress划定规矩，阐明哪一个域名对应kubernetes散群中欧冠的哪一个Service
Ingress掌握器静态感知Ingress效劳划定规矩的变化，然后天生一段对应的Nginx设置
Ingress掌握器会将天生的Nginx设置写进到一个运转着Nginx效劳中，并静态更新
到此为行，实在实正正在事情的便是Nginx了，内乱部设置了用户界说的恳求转收划定规矩

5 Ingress利用

5.1 状况筹办

拆建ingress状况

# 创立文件夹
[root@master ~]# mkdir ingress-controller
[root@master ~]# cd ingress-controller/
# 获得ingress-nginx,本次案例利用的是0.30版本
[root#master ingress-controller]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
[root#master ingress-controller]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
# 修正mandatory.yaml文件中的堆栈(自己尝试没有需求修正也能够)
# 修正quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
# 为quay-mirror.qiniu.com/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
# 创立ingress-nginx
[root@master ingress-controller]# kubectl apply -f ./
# 检察ingress-nginx
[root@master ingress-controller]# kubectl get pod -n ingress-nginx
NAME READY STATUS RESTARTS AGE
pod/nginx-ingress-controller-fbf967dd5-4qpbp 1/1 Running 0 12h
# 检察service
[root@master ingress-controller]# kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx NodePort 10.98.75.163 <none> 80:32240/TCP,443:31335/TCP 11h

复造代码

筹办service战pod
为了前面的尝试比力便利，创立以下图所示的模子

创立tomcat-nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: tomat-deployment
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
app: tomcat-pod
template:
metadata:
labels:
app: tomcat-pod
spec:
containers:
- name: tomcat
image: tomcat:8.5-jre10-slim
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
namespace: dev
spec:
selector:
app: nginx-pod
clusterIP: None
type: ClusterIP
ports:
- port: 80
targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: tomcat-service
namespace: dev
spec:
selector:
app: tomcat-pod
clusterIP: None
type: ClusterIP
ports:
- port: 8080
targetPort: 8080

复造代码

# 创立[root@master ~]# kubectl create -f tomcat-nginx.yaml
# 检察
[root@master ~]# kubectl get svc -n dev
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-service ClusterIP None <none> 80/TCP 48s
tomcat-service ClusterIP None <none> 8080/TCP 48s

复造代码

5.2 Http代办署理

创立ingress-http.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-http
namespace: dev
spec:
rules:
- host: nginx.itheima.com
http:
paths:
- path: /
backend:
serviceName: nginx-service
servicePort: 80
- host: tomcat.itheima.com
http:
paths:
- path: /
backend:
serviceName: tomcat-service
servicePort: 8080

复造代码

# 创立
[root@master ~]# kubectl create -f ingress-http.yaml
ingress.extensions/ingress-http created
# 检察
[root@master ~]# kubectl get ing ingress-http -n dev
NAME HOSTS ADDRESS PORTS AGE
ingress-http nginx.itheima.com,tomcat.itheima.com 80 22s
# 检察详情
[root@master ~]# kubectl describe ing ingress-http -n dev
...
Rules:
Host Path backends
---- ---- --------
nginx.itheima.com / nginx-service:80(10.244.1.96:80,10.244.1.97:80,10.244.2.112.80)
tomcat.itheima.com / tomcat-service:8080(10.244.1.94:8080,10.244.1.95:8080,10.244.2.111.8080)
# 接下去，正在当地电脑设置host文件，剖析上里的两个域名到192.168.109.100(master)上
# 然后，就能够别离会见tomcat.itheima.com:32240 战nginx.itheima.com:32240 检察结果了

复造代码

5.3 Https代办署理

创立证书

# 天生证书
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/C=CN/ST=BJ/L=BJ/0=nginx/CN=itheima.com"
# 创立稀钥
kubectl create secret tls tls-secret --key tls.key --cert tls.crt

复造代码

创立ingress-https.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-https
namespace: dev
spec:
tls:
- hosts:
- nginx.itheima.com
- tomcat.itheima.com
secretName: tls-secret # 指定秘钥
rules:
- host: nginx.itheima.com
http:
paths:
- path: /
backend:
serviceName: nginx-service
servicePort: 80
- host: tomcat.itheima.com
http:
paths:
- path: /
backend:
serviceName: tomcat-service
servicePort: 8080

复造代码

# 创立
[root@master ~]# kubectl create -f ingress-https.yaml
ingress.extensions/ingress-https created
# 检察
[root@master ~]# kubectl get ing ingress-https -n dev
NAME HOSTS ADDRESS PORTS AGE
ingress-https nginx.itheima.com,tomcat.itheima.com 10.104.184.38 80, 443 2m42s
# 检察详情
[root@master ~]# kubectl describe ing ingress-https -n dev
...
TLS:
tls-secret terminates nginx.itheima.com,tomcat.itheima.com
Rules:
Host Path backends
---- ---- --------
nginx.itheima.com / nginx-service:80(10.244.1.97:80,10.244.1.98:80,10.244.2.119.80)
tomcat.itheima.com / tomcat-service:8080(10.244.1.99:8080,10.244.2.117:8080,10.244.2.120.8080)
# 上面能够经由过程阅读器会见https://nginx.itheima.com:31335 战 https://tomcat.itheima.com:31335去检察了

复造代码

免责声明：假如进犯了您的权益，请联络站少，我们会实时删除侵权内乱容，感谢协作！

Kubernetes学习(七)——Service

浏览过的版块