SVC服务的发布
服务的发布
发布的方式
之前说过了服务的发现，这个是服务的发布，服务的发布其实就是让你的应用可以被外部访问到，因为如果你的服务外部不可以访问的话那你起这个服务有什么作用呢？没有什么太大的作用是吧
默认情况下，外界是无法访问到集群内的ClusterIP的
1.NodePort
nodePort就是将svc的某个端口与集群的某个端口做了一个映射
通过nodePort映射出去有2种方法
方法一：创建的时候直接指定类型
这种方式比较简单
# 先创建一个nginx的pod
[root@master ~]# kubectl run web01 --image nginx --image-pull-policy IfNotPresent
pod/web01 created
[root@master ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
web01 1/1 Running 0 6s 10.244.104.13 node2 <none> <none>
我们可以看到他的IP地址是10.244.104.14，我们使用windows的cmd来ping一下这个地址看看能不能通
我们可以看到这个地址是不通的，既然不通那浏览器也肯动访问不到
我们现在通过nodePort将他映射出去
[root@master ~]# kubectl expose pod web01 --type NodePort --port 80 --target-port 80
service/web01 exposed
[root@master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 38d
pod01 ClusterIP 10.100.218.31 <none> 80/TCP 4d4h
web01 NodePort 10.102.81.211 <none> 80:31545/TCP 4s
我们可以看到有一个NodePort类型的svc 他也有一个集群内部的IP地址，但是我们要访问的不是这个IP，我们只用看他的端口
他映射的端口是31545，那么这个端口如何使用呢？
这个端口可以跟在集群内的任意一台节点的IP地址后面
比如，这个pod是跑在node02上的，我们可以通过node02的IP地址:31545就可以访问到，或者通过node01的IP地址:31545，当然使用master:31545也是可以的
是不是这样的呢？我们来看看
- 我们首先通过master的IP地址来访问
可以看到是通的 - 我们再通过node01的IP地址来访问
使用node01的也是可以的 - 使用node02的IP地址来访问
也是没有任何的问题
现在集群内部的nginx就可以被外部访问到了
方法二：在线修改(将其他类型改为NodePort)
我们先将刚刚创建的svc删除，pod保留
[root@master ~]# kubectl expose pod web01 --port 80 --target-port 80
service/web01 exposed
[root@master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 38d
web01 ClusterIP 10.104.17.66 <none> 80/TCP 5s
只要不指定类型，那么默认就是ClusterIP，现在我们通过在线修改的方式去改变他
[root@master ~]# kubectl edit svc/web01
我们只需要改动这几处地方，其他的地方不用变
ports:
# 这里加上一个nodePort，也就是你开放的端口，不写这里的话他就是随机开放一个端口
- nodePort: 30888
port: 80
protocol: TCP
targetPort: 80
#type这个地方将clusterIP改为NodePort
sessionAffinity: None
type: NodePort
# 改完这些之后保存退出就可以了
[root@master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 38d
web01 NodePort 10.104.17.66 <none> 80:30888/TCP 114s
可见，他的类型从ClusterIP变成了NodePort
这个时候你可能会问，他后面还是得跟上端口啊，而且端口还是5位数，不太好记，也是一样的很麻烦啊，其实我们的服务并不会直接通过这种方式去暴露在互联网上，我们会通过负载均衡器或者防火墙来开放80/443端口，然后流量到80/443之后负载均衡器会把流量转发到对应的端口，这样的话用户就不用知道具体的端口，他只用输入域名或者IP就可以访问到我们的服务了
2.LoadBalance
要使用这个方式需要先安装第三方插件，因为LoadBalance翻译过来是负载均衡器，但是实际上不是的，他是一个地址池
集群起来之后每个节点都分配一个公网IP会有点浪费资源
我们通过实验来理解
前置条件：需要安装一个三方插件
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.3/config/manifests/metallb-native.yaml
如果因为网络原因创建失败的话可以使用一些特殊手段来尝试一下
安装完成之后执行这个命令
[root@master metallb]# kubectl get pods -n metallb-system
NAME READY STATUS RESTARTS AGE
controller-7d678cf54-w8r9x 1/1 Running 0 62s
speaker-2crsx 1/1 Running 0 61s
speaker-s668p 1/1 Running 0 61s
speaker-wcb7s 1/1 Running 0 61s
会有一个新的命名空间
注意：我们是模拟公网IP地址池，你把地址池里的地址当作是公网的IP地址就行了
安装完成之后再创建2个yaml文件，一个是创建地址池，一个是配置2层工作模式
# 创建地址池
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: first
namespace: metallb-system
spec:
addresses:
# 写上地址段
- 192.168.200.240-192.168.200.250
这就是第一个yaml文件
然后再来第二个yaml文件
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: example
namespace: metallb-system
spec:
ipAddressPools:
- first
然后应用这2个yaml文件
[root@master ~]# kubectl apply -f ippools.yaml
[root@master ~]# kubectl apply -f l2.yaml
# 查询一下地址池
[root@master ~]# kubectl get ipaddresspools.metallb.io -n metallb-system
NAME AUTO ASSIGN AVOID BUGGY IPS ADDRESSES
first true false ["192.168.200.240-192.168.200.250"]
然后我们现在创建一个nginx的pod，使用Load Balance方式将他发布出去
[root@master ~]# kubectl run nginx01 --image nginx --image-pull-policy IfNotPresent
pod/nginx01 created
[root@master ~]# kubectl expose pods/nginx01 --type LoadBalancer --port 80 --target-port 80
service/nginx01 exposed
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx01 1/1 Running 0 21s
[root@master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 38d
nginx01 LoadBalancer 10.99.228.13 192.168.200.240 80:32042/TCP 8s
到这里我们可以看到，external-ip这里是有一个ip地址的，我们来尝试访问一下这个IP地址
没有问题，我们同时也看到在port那里有一个32042的端口，这个端口是干嘛的呢？这个端口其实就是nodePort的端口
我们使用某个节点的IP:32042
没有任何的问题
我们之前就说了这个是模拟的公网IP，如果你是在公有云上部署这个并且你有一些公网IP，那么就可以直接通过公网IP来发布你的服务了
3.Ingress(推荐/重点)
ingress会根据用户的不同需求将流量转发到对应的服务上
使用ingress的话有3个步骤
- 配置反向代理
- 创建pod
- 创建svc
操作开始
我们现在开始配置反向代理，配置反向代理不要用nginx去手动配置，虽然行得通，但是很麻烦，我们直接使用ingress-nginx这个镜像
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml
如果网络不好的话这样操作
# 在node1和node2上操作
[root@node1 ~]# crictl pull registry.cn-hangzhou.aliyuncs.com/cloudcs/kube-webhook-certgen:v20220916-gd32f8c343
[root@node1 ~]# crictl pull registry.cn-hangzhou.aliyuncs.com/cloudcs/controller:v1.6.4
然后将文件内容复制下来写到一个yaml文件里，需要改3个地方
[root@master ingress]# grep image deploy.yaml
# 这3个镜像的地方需要改，第2个和第3个使用的是同一个镜像
image: registry.cn-hangzhou.aliyuncs.com/cloudcs/controller:v1.6.4
imagePullPolicy: IfNotPresent
image: registry.cn-hangzhou.aliyuncs.com/cloudcs/kube-webhook-certgen:v20220916-gd32f8c343
imagePullPolicy: IfNotPresent
image: registry.cn-hangzhou.aliyuncs.com/cloudcs/kube-webhook-certgen:v20220916-gd32f8c343
imagePullPolicy: IfNotPresent
然后apply
如果想要他使用宿主机的IP地址的话在500行的地方，也就是nginx-controller这个容器的spec内加上hostNetwork: true
加上这个之后这个pod就会使用宿主机的IP地址，后续的hosts文件也可以直接写宿主机的IP地址
[root@master ingress]# kubectl get pods -n ingress-nginx
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-z27v4 0/1 Completed 0 5m44s
ingress-nginx-admission-patch-fnx6b 0/1 Completed 0 5m44s
ingress-nginx-controller-7ffff4c7dd-jps9m 1/1 Running 0 5m44s
他最后应该变成这样，2个完成，1个运行中
再查看一下svc
[root@master ~]# kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller LoadBalancer 10.106.120.188 192.168.200.241 80:32558/TCP,443:32206/TCP 11h
ingress-nginx-controller-admission ClusterIP 10.96.125.66 <none> 443/TCP 11h
这些东西都是为了反向代理做支撑的
然后我们还需要定义一个规则
# 这个规则就是用户访问www.web1.com 的时候流量会走到pod01上，访问www.web2.com流量会到pod02上，www.web3.com则会到pod03
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-wildcard-host
spec:
rules:
- host: "www.web1.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: pod01
port:
number: 80
- host: "www.web2.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: pod02
port:
number: 80
- host: "www.web3.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: pod03
port:
number: 80
这个文件先别急着apply，还有一个操作
# 修改ingress的默认class
[root@master ~]# kubectl edit ingressclasses.networking.k8s.io
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
annotations:
# 加上这一行，让他有一个默认类
ingressclass.kubernetes.io/is-default-class: "true"
kubectl.kubernetes.io/last-applied-configuration: |
然后我们开始创建pod
# 创建3个pod，在ingress-nginx命名空间下，在哪都无所谓，我这里是在这个命名空间下的，只需要保证你的pod,svc和ingress在同一命名空间就行
[root@master ~]# kubectl run pod01 --image nginx --image-pull-policy IfNotPresent --namespace ingress-nginx
pod/pod01 created
[root@master ~]# kubectl run pod02 --image nginx --image-pull-policy IfNotPresent --namespace ingress-nginx
pod/pod02 created
[root@master ~]# kubectl run pod03 --image nginx --image-pull-policy IfNotPresent --namespace ingress-nginx
pod/pod03 created
[root@master ~]# kubectl get pods -n ingress-nginx
NAME READY STATUS RESTARTS AGE
pod01 1/1 Running 0 21s
pod02 1/1 Running 0 15s
pod03 1/1 Running 0 11s
# 然后进去pod修改index文件
[root@master ~]# kubectl exec -it pods/pod01 -- bash
root@pod01:/# echo 111 > /usr/share/nginx/html/index.html
[root@master ~]# kubectl exec -it pods/pod02 -- bash
root@pod01:/# echo 222 > /usr/share/nginx/html/index.html
[root@master ~]# kubectl exec -it pods/pod03 -- bash
root@pod01:/# echo 333 > /usr/share/nginx/html/index.html
然后我们去创建svc
[root@master ~]# kubectl expose pods/pod01 --port 80 --target-port 80
service/pod01 exposed
[root@master ~]# kubectl expose pods/pod02 --port 80 --target-port 80
service/pod02 exposed
[root@master ~]# kubectl expose pods/pod03 --port 80 --target-port 80
service/pod03 exposed
当在ingress-nginx命名空间下创建完pod和svc之后我们再去apply那个规则文件
[root@master ~]# kubectl apply -f ingress.yaml
# 然后我们来查看一下
[root@master ingress]# kubectl describe ingress
……省略一些信息
Rules:
Host Path Backends
---- ---- --------
www.web1.com
/ pod01:80 (10.244.104.40:80)
www.web2.com
/ pod02:80 (10.244.104.19:80)
www.web3.com
/ pod03:80 (10.244.166.145:80)
Annotations: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Sync 26m (x2 over 27m) nginx-ingress-controller Scheduled for sync
这里我么可以看到 www.web1.com 他会转发到pod01上，那么没有问题
下面是验证环节，为了方便，我们直接在master节点上修改hosts文件
# 先查询一下ingress的ip
[root@master ingress]# kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress-wildcard-host nginx www.web1.com,www.web2.com,www.web3.com 192.168.200.241 80 5m28s
# 这里他的IP是192.168.200.241
[root@master ~]# vim /etc/hosts
192.168.200.200 master
192.168.200.210 node1
192.168.200.220 node2
192.168.200.241 www.web1.com
192.168.200.241 www.web2.com
192.168.200.241 www.web3.com
好，我们来访问一下
如果在之前是使用的宿主机的IP地址的话这里直接写宿主机的IP，就不是写192.168.200.241
[root@master ingress]# curl www.web1.com
111
[root@master ingress]# curl www.web2.com
222
[root@master ingress]# curl www.web3.com
333
好的，我们的规则生效了，这个就是ingress发布，操作有点麻烦，但是可以对应不同的需求
这些就是服务的发布了，没有讲到ClusterIP，因为这个只能集群内部访问，上一节有提到过这个
刚刚我们的访问都是基于不同的域名，如果现在我们只有一个域名，但是需要根据不同的后缀来转发流量。怎么做呢？
我们只用到pod01和pod02
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-wildcard-host
# 注意，这一个注释很关键，如果没有这个注释的话你问的时候会报错404
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: "www.test.com"
http:
paths:
- pathType: Prefix
path: "/web01"
backend:
service:
name: web01
port:
number: 80
- host: "www.test.com"
http:
paths:
- pathType: Prefix
path: "/web02"
backend:
service:
name: web02
port:
number: 80
关于在上面写的注释，意思就是使用 NGINX Ingress 的 rewrite-target 注解，将请求路径重写为根路径 /
如果没有这个注释的话，你去访问www.test.com/web01的时候，他会访问pod的/web01这个文件，而不是访问index.html，所以我们需要将这个注释加上
创建ingress规则
kubectl apply -f ingress2.yaml
访问测试
C:\Users\33308>curl www.test.com/web01
web01
C:\Users\33308>curl www.test.com/web02
web02
现在就已经做到根据不同的后缀来转发到不同的svc了
本文来自博客园，作者：FuShudi，转载请注明原文链接：https://www.cnblogs.com/fsdstudy/p/18015433
