Service资源

没有service资源,想要访问服务,需要在防火墙做端口转发

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
1、起一个pod资源
[root@master01 kubernetes]# vim nginx.yml
apiVersion: v1
kind: Pod
metadata:
name: nginx-test
namespace: default
spec:
containers:
- name: nginx-container-v2
image: nginx:alpine
imagePullPolicy: IfNotPresent
#端口映射
ports:
- name: http-port
#容器的80端口映射到宿主机的8081端口
containerPort: 80
hostPort: 8081

2、运行
[root@master01 kubernetes]# kubectl apply -f nginx.yml
[root@master01 kubernetes]# kubectl get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-test 1/1 Running 0 46s 10.2.3.96 node03

3、pod起来了,并且运行在node03节点上,查看node03的端口,看不到8081端口,可以浏览器直接访问,能够访问到nginx主页面
10.0.0.203:8081

4、因为防火墙在底层做了端口转发,是看不到的,只要访问到node03的8081端口,会自动转发转发到容器里的80端口

#如果如上端口转发一般不使用,映射的端口看不到


## 使用控制器启动POD时,无法多个POD绑定同一个端口,而且每次pod起来,ip会发生变化
[root@master01 kubernetes]# cat nginx-dp.yaml
apiVersion: "apps/v1"
kind: "Deployment"
metadata:
name: nginx-dp
namespace: default
spec:
replicas: 10
selector:
matchLabels:
run: nginx-dp
template:
metadata:
name: nginx-pod
namespace: default
labels:
run: nginx-dp
spec:
containers:
- name: nginx-container
image: nginx:alpine
imagePullPolicy: IfNotPresent
ports:
- name: http-port
containerPort: 80
hostPort: 8081

#报错端口被占用
[root@master01 kubernetes]# kubectl describe pod nginx-dp-69c9d4dbc5-9xp64
Warning FailedScheduling 44s default-scheduler 0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 3 node(s) didn't have free ports for the requested pod ports.
Warning FailedScheduling 44s default-scheduler 0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 3 node(s) didn't have free ports for the requested pod ports.

1、Service资源介绍

1
2
3
4
   通过前面的实验我们已经掌握了使用Pod控制器来管理Pod,我们也会发现,Pod的生命周期非常短暂,每次镜像升级都会销毁以及创建,而我们知道每个Pod都拥有自己的IP地址,并且随着Pod删除和创建,这个IP是会变化的。
当我们的Pod数量非常多的时候前端的入口服务该怎么知道后面都有哪些Pod呢?
为了解决这个问题k8s提供了一个对象Service和三种IP,创建的Service资源通过标签可以动态的知道后端的Pod的IP地址,在PodIP之上设计一个固定的IP,也就是ClusterIP,然后使用NodePort来对外暴露端口提供访问。
接下来我们先认识一下K8s里的三种IP及其作用。

K8s使用的三种IP

1
2
3
4
5
6
7
8
1、nodes IP:宿主机的IP
2、Pod IP:容器的IP地址
3、Cluster IP:容器的负载均衡IP


#Service资源涉及到的IP和网络
ClusterIP:IP地址
NodePort:端口

image-20240924175240230

2、ClusterIP的资源

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
#如果要起一个service资源,就必须先起一个Pod,再给POD打上Cluster IP

1、需要先起一个Deployment控制器资源
[root@master01 service]# vim nginx-dp.yaml
apiVersion: "apps/v1"
kind: "Deployment"
metadata:
name: nginx-deploy
namespace: default
spec:
replicas: 3
selector:
matchLabels:
run: nginx-deploy
template:
metadata:
name: nginx-pod
namespace: default
labels:
run: nginx-deploy
spec:
containers:
- name: nginx-container
image: nginx:alpine
imagePullPolicy: IfNotPresent

[root@master01 service]# kubectl apply -f nginx-dp.yaml
[root@master01 kubernetes]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-deploy-545f948568-66bjf 1/1 Running 0 5s
nginx-deploy-545f948568-f5mhc 1/1 Running 0 5s
nginx-deploy-545f948568-vmkpz 1/1 Running 0 5s
#现在访问,就相当于访问web01、web02、web03,但是前面没有加lb01,接下来就写Cluster资源清单,就相当于lb01



2、写Cluster资源清单,这个资源清单要给上面的3个pod打一个负载均衡的Cluster IP
[root@master01 service]# vim nginx-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
namespace: default
spec:
#你的service起的cluster IP要给哪个pod绑定,就相当于标签选择器,这里的标签要和pod的标签一样
selector:
run: nginx-deploy
ports:
- name: http-nginx
#宿主机里映射的端口
port: 80
protocol: TCP
#容器的的端口
targetPort: 80
type: ClusterIP


[root@master01 service]# kubectl apply -f nginx-svc.yaml

3、查看svc详细信息
[root@master01 kubernetes]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.1.0.1 <none> 443/TCP 11d #这个是k8s创建的svc
nginx-svc ClusterIP 10.1.168.150 <none> 80/TCP 8h
[root@master01 kubernetes]# curl 10.1.168.150
curl 一下,如果通了,这个负载均衡就做好了

#注意,如果curl不通,不要着急,先curl一下POd的ip是否能通,通过可以通,那就是svc的请求无法到达pod,可能是iptables防火墙阻止了,可以在前面加ingress,如果在浏览器里面可以访问,那么ingress能正常对外提供服务,就没问题

[root@master01 kubernetes]# kubectl describe svc nginx-svc
Name: nginx-svc
Namespace: default
Labels: <none>
Annotations: <none>
Selector: run=nginx-deploy
Type: ClusterIP
IP: 10.1.168.150 #serivice资源的ip
Port: http-nginx 80/TCP
TargetPort: 80/TCP
Endpoints: 10.2.1.52:80,10.2.2.46:80,10.2.3.111:80
Session Affinity: None
Events: <none>

image-20240925231650457

同一个名称空间通信的方法:通过ping server资源名 进行通信

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
4、随便起一个有ping命令的pod,并进入pod
[root@master01 kubernetes]# vim c7.yml
apiVersion: "v1"
kind: "Pod"
metadata:
name: c7-nginx
namespace: default
spec:
containers:
- name: c7-container
image: centos:7
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","tail -f /etc/hosts"]

[root@master01 kubernetes]# kubectl apply -f c7.yml

5、连接进入容器,ping serivice资源的ip和serivice资源的名字
[root@master01 service]# kubectl exec -it c7-nginx -c c7-container -- /bin/bash
[root@c7-nginx /]# ping 10.1.189.201
[root@c7-nginx /]# ping nginx-svc
可以ping

image-20240924195940632

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
[root@master01 prometheus]# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-6d56c8448f-85k2r 1/1 Running 2 13d
coredns-6d56c8448f-h697m 1/1 Running 2 8d
......

#流程梳理:
1、因为我们有2个coredns服务器,他会帮我们做一个域名解析
2、啥时候做域名解析呢?
当你apply起一个svc时,当svc起来了后,他会把10.1.189.201 nginx-svc(serivice资源的ip和serivice资源的名字)绑定到那2个dns服务器里面,做一个域名解析

起了一个pod,pod里面有dns的配置,里面有一个ip,是service的ip,这个起在kube-system名称空间里面的

[root@master01 prometheus]# kubectl get svc -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.1.0.10 <none> 53/UDP,53/TCP,9153/TCP 13d
metrics-server ClusterIP 10.1.11.158 <none> 443/TCP 2d13h
[root@master01 kubernetes]# kubectl describe svc -n kube-system kube-dns
Name: kube-dns
Namespace: kube-system
Labels: k8s-app=kube-dns
kubernetes.io/cluster-service=true
kubernetes.io/name=KubeDNS
Annotations: prometheus.io/port: 9153
prometheus.io/scrape: true
Selector: k8s-app=kube-dns
Type: ClusterIP
IP: 10.1.0.10
Port: dns 53/UDP
TargetPort: 53/UDP
Endpoints: 10.2.1.5:53,10.2.2.7:53
Port: dns-tcp 53/TCP
TargetPort: 53/TCP
Endpoints: 10.2.1.5:53,10.2.2.7:53
Port: metrics 9153/TCP
TargetPort: 9153/TCP
Endpoints: 10.2.1.5:9153,10.2.2.7:9153
Session Affinity: None
Events: <none>

image-20240926232750951

image-20240926233119633

不名称空间通信的方法:ping service的名字.service的名称空间.svc.cluster.local

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1、随便起一个有ping命令的pod,并进入pod
[root@master01 kubernetes]# vim c7.yml
apiVersion: "v1"
kind: "Pod"
metadata:
name: c7-test
#这里指定一个名称空间
namespace: kube-system
spec:
containers:
- name: c7-container
image: centos:7
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","tail -f /etc/hosts"]

[root@master01 kubernetes]# kubectl apply -f c7.yml

5、连接进入容器,ping serivice资源的ip和serivice资源的名字
[root@master01 kubernetes]# kubectl exec -it c7-test -n kube-system -- /bin/bash
[root@c7-test /]# ping nginx-svc
ping: nginx-svc: Name or service not known
#ping资源名,无法通,说明不在同一个名称空间是做网络隔离的,不在同一个pod不能用service通信

[root@c7-nginx /]# ping 10.1.189.201
ip可以通,但是ip通没啥用,ip会发生变化


#如果有时候,就是想要不同名称空间的通信,就像阿里云买机器,把网络打通内网的需求,打通内外这种事,k8s也能做
ping service的名字.service的名称空间.svc.cluster.local

[root@c7-test /]# ping nginx-svc.default.svc.cluster.local
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#原理:
1、首先起了一个c7-test的pod,里面有dns服务器的配置
[root@c7-test /]# cat /etc/resolv.conf
nameserver 10.1.0.10
search kube-system.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

2、10.1.0.10这个ip是一个svc的ip,不过这个svc起在kube-system这个名称空间里
[root@master01 prometheus]# kubectl get svc -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.1.0.10 <none> 53/UDP,53/TCP,9153/TCP 13d


[root@master01 kubernetes]# kubectl describe svc -n kube-system kube-dns
Name: kube-dns
Namespace: kube-system
Labels: k8s-app=kube-dns
kubernetes.io/cluster-service=true
kubernetes.io/name=KubeDNS
Annotations: prometheus.io/port: 9153
prometheus.io/scrape: true
Selector: k8s-app=kube-dns
Type: ClusterIP
IP: 10.1.0.10
Port: dns 53/UDP
TargetPort: 53/UDP
Endpoints: 10.2.1.5:53,10.2.2.7:53
Port: dns-tcp 53/TCP
TargetPort: 53/TCP
Endpoints: 10.2.1.5:53,10.2.2.7:53
Port: metrics 9153/TCP
TargetPort: 9153/TCP
Endpoints: 10.2.1.5:9153,10.2.2.7:9153
Session Affinity: None
Events: <none>

以后pod与pod的通信流程图

image-20240927194820715

1
但是现在光用Cluster ip是没啥用的,会发现Cluster ip的ip在浏览器无法访问,因为他是一个内网ip,想要这个ip能够访问,还需要在宿主机上做一个NodePort 端口映射,映射到clusterip

3、NodePort资源 做端口映射

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
#如果要起一个service资源,就必须先起一个Pod,再给POD打上NodePort

1、需要先起一个Deployment控制器资源
[root@master01 service]# vim nginx-dp.yaml
apiVersion: "apps/v1"
kind: "Deployment"
metadata:
name: nginx-deploy
namespace: default
spec:
replicas: 3
selector:
matchLabels:
run: nginx-deploy
template:
metadata:
name: nginx-pod
namespace: default
labels:
run: nginx-deploy
spec:
containers:
- name: nginx-container
image: nginx:alpine
imagePullPolicy: IfNotPresent

[root@master01 kubernetes]# kubectl apply -f nginx-dp.yml

2、编写nodeport资源清单 写发和clusterip一样,就把后面的type换一下
[root@master01 service]# vim nginx-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
namespace: default
spec:
selector:
run: nginx-deploy
ports:
- name: http-nginx
port: 80
protocol: TCP
targetPort: 80
#映射到宿主机30000的端口
nodePort: 30000
type: NodePort

3、删除上一个实验的nginx-svc资源,运行本次编写的资源清单
[root@master01 service]# kubectl delete service nginx-svc
service "nginx-svc" deleted


[root@master01 service]# kubectl apply -f nginx-svc.yml
[root@master01 service]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.1.0.1 <none> 443/TCP 11d
nginx-svc NodePort 10.1.171.27 <none> 80:30000/TCP 63s
#把cluster ip的80端口,映射到宿主机的30000
他起NodePort也帮你起一个cluster ip,也就是说NodePort也包含cluster ip,所以以后起的时候就不需要单独起cluster ip的资源了

3、连接进入容器,ping serivice资源的名字,可以ping通
[root@master01 service]# kubectl exec -it c7-nginx -c c7-container -- /bin/bash
[root@c7-nginx /]# ping nginx-svc


#将拥有同一个标签的pod分为一组 对外映射端口(30000-65535) 进行负载
宿主机 30000 --- > serIP:80 -----> podip:80

## NodePort端口范围:30000-32767
The Service "nginx-svc" is invalid: spec.ports[0].nodePort: Invalid value: 80:provided port is not in the valid range. The range of valid ports is 30000-32767

现在使用浏览器访问,可以访问到nginx主页面
10.0.0.200:30000
10.0.0.201:30000
10.0.0.202:30000
10.0.0.203:30000

#这个和k8s的组件kube-proxy有关,只要有kube-proxy的机器都会做端口映射出来,底层做一个转发,kube-proxy在启动的时候使用的是DaemonSet,每个机器都会起
kube-proxy提供的30000端口
[root@master01 kubernetes]# netstat -lntup|grep 30000
tcp 0 0 0.0.0.0:30000 0.0.0.0:* LISTEN 96411/kube-proxy


#注意:
端口范围是30000~32767,不太好用,所以以后不行NodePort,写cluster ip就可以,不要NodePort,就可以不用kube-proxy,我们会用ingress取代

4、Ingress资源介绍

NodePort的缺点

1
2
3
4
5
6
7
8
9
1.没有ingress之前,pod对外提供服务只能通过NodeIP:NodePort的形式,但是这种形式有缺点,一个节点上的Port不能重复利用。比如某个服务占用了80端口,那么其他服务就不能在用这个端口了。

2.NodePort是4层代理,不能解析7层的http,不能通过域名区分流量

3.为了解决这个问题,我们需要用到资源控制器叫Ingress,作用就是提供一个统一的访问入口。工作在7层

4.虽然我们可以使用nginx/haproxy来实现类似的效果,但是传统部署不能动态的发现我们新创建的资源,必须手动修改配置文件并重启。

5.适用于k8s的ingress控制器主流的有nginx-ingress、traefik、haproxy-ingress

Ingress控制器
1)[AKS 应用网关Ingres控制器] 使用 Azure应用程序网关启用AKS集群ingress。
2)mbassador API网关,一个基于Envoy的Ingress控制器,有着来自社区的支持和来自Datawire的商业支持。
3)AppsCode Inc 为最广泛使用的基于HAproxy的Ingress控制器Voyager提供自持和维护。
4)AWS ALB Ingress控制器,通过AWS应用Load Balancer启用Ingress。
5)Contour是一个基于Envoy的Ingress控制器,它由VMware提供和支持。
6)Citrix为其硬件(MPX),虚拟化(VPX)和免费容器化(CPX)ADC提供了一个Ingress控制器,用于裸金属和云部署。
7)F5 Networks为用于Kubernetes的F5 BIG-IP控制器提供支持和维护。
8)Gloo是一个开源的基于Envoy的Ingress控制器,它提供了API网关功能,有着来自solo.io的企业级支持。
9)HAproxy Ingress是HAproxy高度可定制的、由社区驱动的Ingress控制器。
10)HAproxy Technologies为用于Kubernetes的HAproxy Ingress控制器提供支持和维护,具体信息请参考官方文档。
11)基于Istio的ingress控制器,控制Ingress流量。
12)Kong为用于Kubernetes的Kong Ingress控制器提供社区或商业支持和维护。
14)Nginx 为用于Kubernetes的Nginx Ingress控制器提供支持和维护
15)Traefik(小蜜蜂)是一个全功能的Ingress控制器。(Let’s Encrypt,secrets,http2,websocket)并且它也有Traefik Labs的商业支持

image-20240924121232376

1、部署nginx-ingress

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
https://github.com/kubeguide
权威指南的资源清单网址:https://github.com/kubeguide/K8sDefinitiveGuide-V5-Sourcecode/blob/main/Chapter04/4.6.1%20nginx-ingress-controller.yaml

1、下载权威指南的资源清单 ingress资源清单
[root@master01 service]# vim nginx-ingress.yaml
把复制的资源清单粘贴
135行: kind: Deployment 改为 kind: DaemonSet
130行: 删除 data:
140行: 删除 replicas: 1

#这2行是给node打标签的,只有打了标签才装在node上面,要么注释这两行,要么给node打标签 节点标签选择器
147行: nodeSelector:
148行: role: ingress-nginx-controller

#建议复制之后粘贴在VScode里面,格式不会出错

image-20240924213753073

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2、给node节点打上标签
[root@master01 kubernetes]# kubectl label node node01 role=ingress-nginx-controller
node/node01 labeled
[root@master01 kubernetes]# kubectl label node node02 role=ingress-nginx-controller
node/node02 labeled
[root@master01 kubernetes]# kubectl label node node03 role=ingress-nginx-controller
node/node03 labeled

3、运行资源清单
[root@master01 kubernetes]# kubectl apply -f nginx-ingress.yaml
[root@master01 kubernetes]# kubectl get pod -n nginx-ingress -owide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-ingress-hrn5v 1/1 Running 0 2m16s 10.2.3.98 node03
nginx-ingress-hsvgc 1/1 Running 0 2m16s 10.2.1.45 node01
nginx-ingress-tzsht 1/1 Running 0 2m16s 10.2.2.40 node02

2、使用ingress启动自己的站点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
1、为避免数据库有脏数据,先删除节点上之前映射的数据库目录
[root@node01 ~]# rm -rf /data/
[root@node02 ~]# rm -rf /data/
[root@node03 ~]# rm -rf /data/


2、# wordpress pod 起Deployment资源
[root@master01 kubernetes]# kubectl apply -f wp-dp-v1.yml
apiVersion: "apps/v1"
kind: "Deployment"
metadata:
name: wp-dp
namespace: default
spec:
#起2个,数据也是2个,除非把数据分开
replicas: 1
selector:
matchLabels:
#这里的标签一定要和svc的标签一样,不然会连接不到
app: wp
template:
metadata:
name: wp-pod
namespace: default
labels:
app: wp
spec:
volumes:
- name: mysql-data
hostPath:
path: /data/mysql
- name: wp-data
hostPath:
path: /data/wp

containers:
- name: wp-container
image: wordpress
imagePullPolicy: IfNotPresent
#livenessProbe:
# tcpSocket:
# port: 80
# initialDelaySeconds: 10
# periodSeconds: 3
# timeoutSeconds: 3
# failureThreshold: 3
readinessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 3
timeoutSeconds: 1
periodSeconds: 2
successThreshold: 3
failureThreshold: 3
env:
- name: WORDPRESS_DB_HOST
value: '127.0.0.1'
- name: WORDPRESS_DB_USER
value: 'wp_user'
- name: WORDPRESS_DB_PASSWORD
value: '123'
- name: WORDPRESS_DB_NAME
value: 'wp_db'

volumeMounts:
- name: wp-data
mountPath: /var/www/html/

- name: mysql-container
image: mysql:5.7
imagePullPolicy: IfNotPresent
args:
- --character-set-server=utf8
- --collation-server=utf8_general_ci
livenessProbe:
exec:
command: ["/bin/sh","-c","mysqladmin -uroot -p123 ping"]
initialDelaySeconds: 10
periodSeconds: 3
timeoutSeconds: 3
failureThreshold: 3
env:
- name: MYSQL_ROOT_PASSWORD
value: '123'
- name: MYSQL_DATABASE
value: 'wp_db'
- name: MYSQL_USER
value: 'wp_user'
- name: MYSQL_PASSWORD
value: '123'
volumeMounts:
- name: mysql-data
mountPath: /var/lib/mysql


2、# wordpress service
[root@master01 kubernetes]# vim wp-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: wordpress-svc
namespace: default
spec:
selector:
#这里的标签一定要和pod-dp的标签一样,不然会连接不到
app: wp
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
type: ClusterIP

3、# 对外提供服务的wordpress ingress
[root@master01 kubernetes]# vim wp-ingress.yaml
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: wordpress-ingress
spec:
rules:
#站点的域名
- host: blog.wp.com
http:
paths:
- path: /
pathType: ImplementationSpecific
#backend之前的都是网站相关配置
##从backend之后的都是ingress关联ClusterIP
backend:
service:
#这里必须要写svc网站的名字
name: wordpress-svc
port:
number: 80

4、运行
[root@master01 kubernetes]# kubectl apply -f wp-ingress.yml
ingress.networking.k8s.io/wordpress-ingress created
[root@master01 kubernetes]# kubectl apply -f wp-dp-v1.yml
pod/wp-pod created
[root@master01 kubernetes]# kubectl apply -f wp-svc.yml
service/wordpress-svc created

5、查看
[root@master01 kubernetes]# kubectl get ingress
Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
wordpress-ingress <none> blog.wp.com 80 13s

[root@master01 kubernetes]# kubectl get svc
wordpress-svc ClusterIP 10.1.42.145 <none> 80/TCP 25s
[root@master01 kubernetes]# kubectl describe svc wordpress-svc
Name: wordpress-svc
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=wp
Type: ClusterIP
IP: 10.1.84.160
Port: http 80/TCP
TargetPort: 80/TCP
Endpoints: 10.2.3.118:80 #显示找到了pod ip
Session Affinity: None
Events: <none>
[root@master01 kubernetes]# kubectl get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE
wp-dp-9d48b944b-z6snw 2/2 Running 0 22m 10.2.3.118 node03

3、测试

1
2
3
4
5
6
7
1、本地机器做域名解析,ingress起在node节点上的,node节点的ip做谁的域名解析都可以
10.0.0.201 blog.wp.com

2、使用域名在浏览器访问成功,这就是ingress的相关,而且还是80端口,以后不管起多少个网站,都走80端口,但是node节点上看不到80端口的,只是在底层的防火墙做的转发
blog.wp.com

'3、iptables -F这个命令千万不要执行,他会清空iptables所有的转发配置'

image-20240927230958071

image-20240927231602977

将域名解析改到其他node,也可以使用域名访问成功

image-20240927231929202

1
2
3
他到node节点的机器,转发到cluster ip上,cluster ip去访问pod,但我们的pod就一个pod,所以暂时没有日志显示是哪台机器转发的

解析到哪,取决于哪些机器安装了ingress

3、ingress资源解析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
spec:                                          #转发规则
rules: #转发规则
#站点的域名
- host: blog.wp.com #匹配的域名
http: #基于http协议解析
paths: #基于路径进行匹配
- path: / #匹配/路径
pathType: ImplementationSpecific #路径类型
backend: #匹配后跳转的后端服务
service: #设置后端跳转到Service的配置
name: wordpress-svc #跳转到名为wordpress-svc的ClusterIP
port: #跳转到的端口
number: 80 #Service端口号


# pathType路径类型支持的类型:
ImplementationSpecific 系统默认,由IngressClass控制器提供
Exact 精确匹配URL路径,区分大小写 相当于nginx配置文件的 location = / ~ * 这种
Prefix 匹配URL路径的前缀,区分大小写

5、Service服务发现

1
2
3
4
5
在k8s中,一个service对应的“后端”由Pod的IP和容器端口号组成,即一个完整的"IP:Port"访问地址,这在k8s里叫做Endpoint。通过查看Service的详细信息可以看到后端Endpoint的列表。
[root©node1 ~]# kubectl describe svc my-nginx
Endpoints: 10.2.1.24:80,10.2.1.26:80,10.2.1.27:89 more...

把一个pod删掉后,自动起来的就会自动加到cluster ip里

我们也可以使用DNS域名的形式访问Service,如果在同一个命名空间里甚至可以直接使用service名来访问服务。

1
2
3
servicename.namespace.svc.cluster.local
servicename.namespace
servicename

image-20240927183355537