CKA备考实验 | 服务发布

原创已于 2023-09-25 15:54:07 修改 · 503 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes

于 2023-07-05 11:13:20 首次发布

本文详细介绍了在Kubernetes中如何使用NodePort和LoadBalancer类型的服务对外发布应用，以及如何通过Metallb部署负载均衡器。此外，还探讨了Ingress作为更高级的发布方式，如何通过配置Ingress规则实现路径转发到不同服务。

书籍来源：《CKA/CKAD应试指南：从Docker到Kubernetes完全攻略》

一边学习一边整理老师的课程内容及实验笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：CKA备考实验 | 汇总_热爱编程的通信人的博客-优快云博客

按前面所述，我们需要为pod创建一个svc，但是svc的IP只有集群内部主机及pod才可以访问，那么如何才能让外界的其他主机也能访问呢？这个时候就利用到服务的发布。

NodePort

当我们创建一个服务的时候，把服务的端口映射到物理机（kubernetes集群中所有节点）的某端口，以后访问服务器该端口的时候，请求就会转发到该svc上，如图12-1所示。

我们把服务的类型设置为NodePort，就可以实现这种映射了。

前面已经把wordpress的pod创建好了。

##########实操验证##########
[root@vms10 svc]# kubectl get pods
NAME        READY   STATUS    RESTARTS   AGE
mysql       1/1     Running   2          38m
wordpress   1/1     Running   0          7m24s
[root@vms10 svc]#

步骤1：为此pod创建类型为NodePort类型的service，名字为blog。

##########实操验证##########
[root@vms10 svc]# kubectl expose pod wordpress --name=blog --port=80 --type=NodePort
service/blog exposed
[root@vms10 svc]#

步骤2：查看服务。

##########实操验证##########
[root@vms10 svc]# kubectl get svc
NAME    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
blog    NodePort    10.111.38.241   <none>        80:31283/TCP   13s
dbsvc   ClusterIP   10.100.82.197   <none>        3306/TCP       38m
[root@vms10 svc]#

上面可以看出来，名字是blog的服务的端口为80，映射到物理机（集群中所有节点）的端口为30588，此时外部主机通过访问集群中任一节点IP的30588端口都可访问到wordpress的服务，如图12-12所示。

自行删除以上几个pod及对应的svc。

LoadBalancer

如果通过loadbalancer的方式来发布服务的话，每个svc都会获取一个IP。所以需要部署一个地址池，用于给svc分配IP。

要部署loadbalancer类型的服务，需要用到第三方工具metallb。

步骤1：创建命名空间metallb-system。

##########实操验证##########
[root@vms10 svc]# kubectl create ns metallb-system
namespace/metallb-system created
[root@vms10 svc]#

步骤2：创建所需要的secret。

##########实操验证##########
[root@vms10 svc]# kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
secret/memberlist created
[root@vms10 svc]#

步骤3：下载部署metallb所需要的yaml文件。

##########实操验证##########
登录百度网盘下载
链接：https://pan.baidu.com/s/1W0tgWBRdMN_rRqE4geC0WQ
提取码：fff6

注意：如果下载不了的话，可以到http://www.rhce.cc/2748.html找到此文件。

查看其所需要的镜像，并把镜像下载策略改由Always改为IfNotPresent：

##########实操验证##########
[root@vms10 svc]# grep image metallb.yaml
        image: metallb/speaker:v0.9.5
        imagePullPolicy: IfNotPresent
        image: metallb/controller:v0.9.5
        imagePullPolicy: IfNotPresent
[root@vms10 svc]#

在所有的节点上提前拉取镜像metallb/speaker:v0.9.5和metallb/controller:v0.9.5。

步骤4：部署metallb。

##########实操验证##########
[root@vms10 svc]# kubectl apply -f metallb.yaml 
Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
podsecuritypolicy.policy/controller created
podsecuritypolicy.policy/speaker created
serviceaccount/controller created
serviceaccount/speaker created
clusterrole.rbac.authorization.k8s.io/metallb-system:controller created
clusterrole.rbac.authorization.k8s.io/metallb-system:speaker created
role.rbac.authorization.k8s.io/config-watcher created
role.rbac.authorization.k8s.io/pod-lister created
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:controller created
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:speaker created
rolebinding.rbac.authorization.k8s.io/config-watcher created
rolebinding.rbac.authorization.k8s.io/pod-lister created
daemonset.apps/speaker created
deployment.apps/controller created
[root@vms10 svc]#

查看metallb是否正常运行了。

##########实操验证##########
[root@vms10 svc]# kubectl get pods -n metallb-system
NAME                         READY   STATUS    RESTARTS   AGE
controller-b4df945f8-pw94r   1/1     Running   0          6m51s
speaker-9zfx8                1/1     Running   0          6m51s
speaker-qmt25                1/1     Running   0          6m51s
speaker-tr4gn                1/1     Running   0          6m51s
[root@vms10 svc]#

所有pod状态为running，说明metallb已经部署完毕。

步骤5：创建地址池所需要的yaml文件，并创建地址池。

##########实操验证##########
[root@vms10 svc]# cat pool1.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: | 
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.211-192.168.1.220
[root@vms10 svc]#

这里192.168.26.111-192.168.26.120是后面将会分配给svc的IP。

创建地址池：

##########实操验证##########
[root@vms10 svc]# kubectl apply -f pool1.yaml 
configmap/config created
[root@vms10 svc]#

步骤6：测试。

创建一个名字为pod1的pod：

##########实操验证##########
[root@vms10 svc]# kubectl run pod1 --image=nginx --image-pull-policy=IfNotPresent
pod/pod1 created
[root@vms10 svc]#

为此pod创建一个名字为svc1，类型为LoadBalancer的服务：

##########实操验证##########
[root@vms10 svc]# kubectl expose --name=svc1 pod pod1 --port=80 --type=LoadBalancer
service/svc1 exposed
[root@vms10 svc]#

查看svc的信息：

##########实操验证##########
[root@vms10 svc]# kubectl get svc
NAME   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)        AGE
svc1   LoadBalancer   10.110.225.174   192.168.1.211   80:30635/TCP   17s
[root@vms10 svc]#

这里可以看到，svc1已经从我们定义的地址池里获取了一个IP地址192.168.26.111。

在物理机的浏览器里输入192.168.26.111，可以直接访问到pod1了。

步骤7：删除这个svc1和pod1。

##########实操验证##########
[root@vms10 svc]# kubectl delete svc svc1
service "svc1" deleted
[root@vms10 svc]# kubectl delete pod pod1
pod "pod1" deleted
[root@vms10 svc]#

ingress

使用NodePort方式把服务发布出去存在一个问题。假设需要发布的服务很多，那么需要在物理机上映射出很多端口，是否可以不用端口映射，就能把服务发布出去呢？答案是可以的，就是利用ingress来实现。

首先我们需要搭建一个ingress-nginx控制器，这个控制器本质上是通过nginx的反向代理来实现的。然后用户在所在命名空间写ingress规则，这些规则会“嵌入”ingress-nginx控制器里，如图12-14所示。

用户在自己的命名空间里定义ingress规则：

访问http://www1.rhce.cc时转发到svc1；

访问http://www2.rhce.cc时转发到svc2；

访问http://www1.rhce.cc/cka时转发到svc3。

我们把http://www1.rhce.cc和http://www2.rhce.cc都解析为ingress-nginx控制器所在主机的IP。以后客户端访问http://www1.rhce.cc的时候访问的就是ingress-nginx控制器，根据规则，控制器会把请求转发到svc1。

部署nginx ingress控制器

这小节讲解如何部署ingress控制器。

步骤1：先下载负载均衡器所需要的镜像，从下面地址找到下载链接。

http://www.rhce.cc/2748.html

下载之后上传到master上。

##########实操验证##########
去百度网盘下载
[root@vms10 svc]# ls nginx-ingress-controller*
nginx-ingress-controller-img.tar  nginx-ingress-controller.yaml
[root@vms10 svc]#

其中nginx-ingress-controller-img.tar是部署nginx ingress controller所需要的镜像，nginx-ingress-controller.yaml是部署控制器所需的yaml文件。

步骤2：在所有节点上把控制器所需镜像提前导入。

##########实操验证##########
[root@vms10 svc]# docker load -i nginx-ingress-controller-img.tar 
fd6fa224ea91: Loading layer [==================================================>]  3.031MB/3.031MB
87c9f1582ca0: Loading layer [==================================================>]  15.44MB/15.44MB
3dc1eb21487c: Loading layer [==================================================>]  27.82MB/27.82MB
Loaded image: jettech/kube-webhook-certgen:v1.5.0
f5600c6330da: Loading layer [==================================================>]  72.52MB/72.52MB
7ccabd267c9f: Loading layer [==================================================>]  64.54MB/64.54MB
850c2400ea4d: Loading layer [==================================================>]  3.072kB/3.072kB
f790aed835ee: Loading layer [==================================================>]  4.096kB/4.096kB
7e914612e366: Loading layer [==================================================>]  3.584kB/3.584kB
Loaded image: nginx:1.19.5
a29a26776f50: Loading layer [==================================================>]    123MB/123MB
50f5f2f7ba0b: Loading layer [==================================================>]  6.144kB/6.144kB
4c08cea741a6: Loading layer [==================================================>]   38.2MB/38.2MB
1043f99d60c5: Loading layer [==================================================>]  18.29MB/18.29MB
491cf361754c: Loading layer [==================================================>]  6.656kB/6.656kB
3689bf681f88: Loading layer [==================================================>]  417.8kB/417.8kB
2653a83258ba: Loading layer [==================================================>]  274.4kB/274.4kB
8c1f006ca9a0: Loading layer [==================================================>]  10.24kB/10.24kB
880ca7b48944: Loading layer [==================================================>]  6.548MB/6.548MB
6a59792a792a: Loading layer [==================================================>]  35.46MB/35.46MB
7131ed606b35: Loading layer [==================================================>]  3.079MB/3.079MB
13602ecdc6a7: Loading layer [==================================================>]  9.216kB/9.216kB
da2fa3ad223e: Loading layer [==================================================>]  51.06MB/51.06MB
fc11fb9b3494: Loading layer [==================================================>]  9.216kB/9.216kB
Loaded image: k8s.gcr.io/ingress-nginx/controller:v0.41.2
[root@vms10 svc]#

步骤3：部署负载均衡器。

##########实操验证##########
[root@vms10 svc]# kubectl apply -f nginx-ingress-controller.yaml 
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
configmap/ingress-nginx-controller created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
service/ingress-nginx-controller-admission created
service/ingress-nginx-controller created
deployment.apps/ingress-nginx-controller created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
serviceaccount/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
[root@vms10 svc]#

步骤4：查看现有命名空间。

##########实操验证##########
[root@vms10 svc]# kubectl get ns
NAME              STATUS   AGE
default           Active   34d
ingress-nginx     Active   22s
kube-node-lease   Active   34d
kube-public       Active   34d
kube-system       Active   34d
metallb-system    Active   21h
nsdeploy          Active   7d21h
nsds              Active   2d23h
nsjob             Active   2d22h
nsprobe           Active   2d23h
nssec             Active   8d
nssvc             Active   23h
nsvolume          Active   9d
[root@vms10 svc]#

步骤5：查看ingress-nginx里的deployment。

##########实操验证##########
[root@vms10 svc]# kubectl get deploy -n ingress-nginx
NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
ingress-nginx-controller   1/1     1            1           45s
[root@vms10 svc]#

步骤6：查看pod所在节点。

##########实操验证##########
[root@vms10 svc]# kubectl get pods -n ingress-nginx -o wide --no-headers
ingress-nginx-admission-create-gnkkb        0/1   Completed   0     72s   10.244.81.92    vms11.rhce.cc   <none>   <none>
ingress-nginx-admission-patch-pjdn2         0/1   Completed   1     72s   10.244.81.93    vms11.rhce.cc   <none>   <none>
ingress-nginx-controller-59b8bf5fdc-hrq8g   1/1   Running     0     73s   192.168.1.111   vms11.rhce.cc   <none>   <none>
[root@vms10 svc]#

步骤7：查看ingress-nginx里的服务。

##########实操验证##########
[root@vms10 svc]# kubectl get svc -n ingress-nginx
NAME                                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort    10.107.146.26   <none>        80:31698/TCP,443:31129/TCP   94s
ingress-nginx-controller-admission   ClusterIP   10.96.15.40     <none>        443/TCP                      94s
[root@vms10 svc]#

因为在练习环境里要通过http://www1.rhce.cc和http://www2.rhce.cc来访问svc，不管通过哪个主机名来访问，都要先访问到ingress-nginx控制器，然后由ingress-nginx控制器转发到不同的svc，所以我们把这两个主机名通过/etc/hosts或者dns解析为192.168.26.11。

修改客户端的/etc/hosts，增加：

##########实操验证##########
[root@vms10 svc]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.110   vms10.rhce.cc          vms10
192.168.1.111   vms11.rhce.cc          vms11
192.168.1.112   vms12.rhce.cc          vms12
192.168.1.111   www1.rhce.cc           www1
192.168.1.111   www2.rhce.cc           www2
[root@vms10 svc]#

如图12-15所示。

环境准备

下面准备我们的实验环境，首先创建3个pod，它们的主页内容各自不同，然后分别为这3个pod创建service，这3个服务直接是clusterIP类型的。当用户把请求发送给ingress-nginx控制器之后，ingress-nginx控制器会把请求转发到后端相应的svc。

步骤1：分别创建3个pod：nginx1，nginx2，nginx3。

##########实操验证##########
[root@vms10 svc]# kubectl run ngin1 --image=nginx --image-pull-policy=IfNotPresent
pod/ngin1 created
[root@vms10 svc]# kubectl run ngin2 --image=nginx --image-pull-policy=IfNotPresent
pod/ngin2 created
[root@vms10 svc]# kubectl run ngin3 --image=nginx --image-pull-policy=IfNotPresent
pod/ngin3 created
[root@vms10 svc]# kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
ngin1   1/1     Running   0          14s
ngin2   1/1     Running   0          9s
ngin3   1/1     Running   0          5s
[root@vms10 svc]#

步骤2：为这3个pod分别创建一个服务svcX，这里X=1,2,3。

##########实操验证##########
[root@vms10 svc]# kubectl expose pod ngin1 --name=svc1 --port=80
service/svc1 exposed
[root@vms10 svc]# kubectl expose pod ngin2 --name=svc2 --port=80
service/svc2 exposed
[root@vms10 svc]# kubectl expose pod ngin3 --name=svc3 --port=80
service/svc3 expos

步骤3：查看这些svc的信息。

##########实操验证##########
[root@vms10 svc]# kubectl get svc
NAME   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
svc1   ClusterIP   10.102.83.198   <none>        80/TCP    33s
svc2   ClusterIP   10.102.63.31    <none>        80/TCP    24s
svc3   ClusterIP   10.97.50.157    <none>        80/TCP    18s
[root@vms10 svc]#

步骤4：分别修改3个pod的内容。

把nginx1的默认主页设置为111。

##########实操验证##########
[root@vms10 svc]# kubectl exec -it ngin1 -- bash
root@ngin1:/# echo 111 > /usr/share/nginx/html/index.html 
root@ngin1:/# exit
exit
[root@vms10 svc]#

把nginx2的默认主页设置为222。

##########实操验证##########
[root@vms10 svc]# kubectl exec -it ngin2 -- bash
root@ngin2:/# echo 222 > /usr/share/nginx/html/index.html 
root@ngin2:/# exit
exit
[root@vms10 svc]#

在nginx3里创建目录/usr/share/nginx/html/cka，将里面index.html的内容设置为333。

##########实操验证##########
[root@vms10 svc]# kubectl exec -it ngin3 -- bash
root@ngin3:/# mkdir /usr/share/nginx/html/cka
root@ngin3:/# echo 333 > /usr/share/nginx/html/cka/index.html
root@ngin3:/# exit
exit
[root@vms10 svc]#

定义ingress规则

步骤1：创建ingress的yaml文件ingress.yaml，内容如下。

##########实操验证##########
[root@vms10 svc]# cat ingress.yaml 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mying
spec:
  rules:
  - host: www1.rhce.cc
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc1
            port:
              number: 80
      - path: /cka
        pathType: Prefix
        backend:
          service:
            name: svc3
            port:
              number: 80
  - host: www2.rhce.cc
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc2
            port:
              number: 80
[root@vms10 svc]#

这个文件就是创建转发规则的，如图12-14所示，当用户访问http://www1.rhce.cc的时候，控制器会把请求转发到svc1里，当用户访问http://www1.rhce.cc/cka的时候，控制器会把请求转发到服务svc3里，当用户访问http://www2.rhce.cc的时候，控制器会把请求转发到服务svc2里。

步骤2：创建ingress。

##########实操验证##########
[root@vms10 svc]# kubectl apply -f ingress.yaml 
ingress.networking.k8s.io/mying created
[root@vms10 svc]#

步骤3：查看ingress。

##########实操验证##########
[root@vms10 svc]# kubectl get ing
NAME    CLASS    HOSTS                       ADDRESS   PORTS   AGE
mying   <none>   www1.rhce.cc,www2.rhce.cc             80      23s
[root@vms10 svc]# 
[root@vms10 svc]# kubectl get ing
NAME    CLASS    HOSTS                       ADDRESS         PORTS   AGE
mying   <none>   www1.rhce.cc,www2.rhce.cc   10.107.146.26   80      57s
[root@vms10 svc]#

注意上面ADDRESS的值需要稍等一会才会出现。

步骤4：访问测试。

在客户端的浏览器里输入http://www1.rhce.cc，如图12-16所示。

可以看到转发到svc1里了，访问了nginx1里的内容。

在客户端的浏览器里输入http://www2.rhce.cc，如图12-17所示。

可以看到转发到svc2里了，访问了nginx2里的内容。

在客户端的浏览器里输入www1.rhce.ccc/cka，如图12-18所示。

可以看到转发到svc3里了，访问了nginx3里的内容。

步骤5：删除以上这些svc和pod及ingress。

##########实操验证##########
[root@vms10 svc]# kubectl delete -f ingress.yaml 
ingress.networking.k8s.io "mying" deleted
[root@vms10 svc]# 
[root@vms10 svc]# kubectl delete svc svc1 svc2 svc3
service "svc1" deleted
service "svc2" deleted
service "svc3" deleted
[root@vms10 svc]# kubectl delete pod ngin1 ngin2 ngin3
pod "ngin1" deleted
pod "ngin2" deleted
pod "ngin3" deleted
[root@vms10 svc]#