一 什么是k8s中的微服务(service)

用控制器来完成集群的工作负载,那么应用如何暴漏出去?需要通过微服务暴漏出去后才能被访问

  • Service是一组提供相同服务的Pod对外开放的接口,固定访问入口
  • Pod 是临时的(可能因扩缩容、故障重启等原因销毁重建),IP 会动态变化。Service 为一组关联 Pod 分配固定的虚拟 IP(ClusterIP),其他服务通过这个固定 IP 访问,无需关心 Pod 具体 IP。
  • 借助Service,应用可以实现服务发现和负载均衡。
  • service默认只支持4层负载均衡能力,通过kube-proxy组成完成(默认轮询策略),没有7层功能。(可以通过Ingress实现)
  • 服务发现,通过 K8s 内置的 DNS 服务(如 CoreDNS),Service 名称会被解析为对应的 ClusterIP,其他服务可直接通过 服务名:端口 访问(无需记 IP)。

工作原理

  • 标签选择器(Label Selector):Service 通过标签关联后端 Pod。例如,为所有 user-service 的 Pod 打标签 app: user-service,Service 就会通过 selector: {app: user-service} 自动关联这些 Pod。
  • Endpoint:K8s 会自动维护一个 Endpoint 资源,记录 Service 关联的所有 Pod 的 IP 和端口,当 Pod 变化时(新增 / 删除),Endpoint 会自动更新。
  • 流量转发:当请求发送到 Service 的 ClusterIP 时,K8s 内部的 kube-proxy 组件会将流量转发到 Endpoint 中的某个 Pod。

image-20251013000030274

二 微服务的类型

微服务类型 作用描述
ClusterIP 默认值,k8s系统给service自动分配的虚拟IP,只能在集群内部访问
NodePort 将Service通过指定的Node上的端口暴露给外部,访问任意一个NodeIP:nodePort都将路由到ClusterIP
LoadBalancer 在NodePort的基础上,借助cloud provider创建一个外部的负载均衡器,并将请求转发到 NodeIP:NodePort,此模式只能在云服务器上使用
ExternalName 将服务通过 DNS CNAME 记录方式转发到指定的域名(通过 spec.externlName 设定

除了ExternalName是集群内部访问外部,其余都是外部访问集群内部

示例:

#生成控制器文件并建立控制器
[root@k8s-master ~]# kubectl create deployment fjwyyy --image myapp:v1  --replicas 2 --dry-run=client -o yaml > fjwyyy.yaml

#生成微服务yaml追加到已有yaml中
[root@k8s-master ~]# kubectl expose deployment fjwyyy --port 80 --target-port 80 --dry-run=client -o yaml >> fjwyyy.yaml

[root@k8s-master ~]# vim fjwyyy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: fjwyyy
  name: fjwyyy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: fjwyyy
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: fjwyyy
    spec:
      containers:
      - image: myapp:v1
        name: myapp
---										#不同资源间用---隔开

apiVersion: v1
kind: Service
metadata:
  labels:
    app: fjwyyy
  name: fjwyyy
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: fjwyyy

[root@k8s-master ~]# kubectl apply  -f fjwyyy.yaml
deployment.apps/fjwyyy created
service/fjwyyy created

[root@k8s-master ~]# kubectl get services
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   19h
fjwyyy    ClusterIP   10.99.127.134   <none>        80/TCP    16s

微服务默认使用iptables调度

[root@master ~]# iptables -t nat -nL
#可以在火墙中查看到策略信息

image-20251013002348699

三 ipvs模式

3.1 为什么要使用ipvs模式

  • Service 是由 kube-proxy 组件,加上 iptables 来共同实现的
  • kube-proxy 通过 iptables 处理 Service 的过程,需要在宿主机上设置相当多的 iptables 规则,如果宿主机有大量的Pod,不断刷新iptables规则,会消耗大量的CPU资源
  • IPVS模式的service,可以使K8s集群支持更多量级的Pod

3.2 ipvs模式配置方式

1.所有节点安装ipvsadm

[root@node2 ~]# dnf install ipvsadm -y
#命令行脚本
[root@master ~]# for i in 100 10 20
> do ssh -l root 172.25.254.$i dnf install ipvsadm -y
> done

2.修改master节点的代理配置

[root@master ~]# kubectl -n kube-system edit cm kube-proxy
......
mode: "ipvs"
......

#更改完配置文件后重启,删了对应pod让其自愈

image-20251013154311185

[root@master ~]# kubectl delete -n kube-system pods/kube-proxy-28hpl
pod "kube-proxy-28hpl" deleted
[root@master ~]# kubectl delete -n kube-system pods/kube-proxy-2rbqq
pod "kube-proxy-2rbqq" deleted
[root@master ~]# kubectl delete -n kube-system pods/kube-proxy-zpzlg
pod "kube-proxy-zpzlg" deleted

image-20251013154625690

四 微服务类型

4.1 clusterip

#创建控制器管理pod
[root@master svc]# kubectl create deployment myappv1 --image myapp:v1 --replicas 2 --dry-run=client -o yaml > clusterip.yml
[root@master svc]# cat clusterip.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myappv1
  name: myappv1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myappv1
  template:
    metadata:
      labels:
        app: myappv1
    spec:
      containers:
      - image: myapp:v1
        name: myapp
[root@master svc]# kubectl apply -f clusterip.yml

#暴露端口,生成微服务
[root@master svc]# kubectl expose deployment myappv1 --port=80 --target-port=80 --type=ClusterIP --dry-run=client -o yaml >> clusterip.yml
#暴露端口时不写type参数默认是ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: myappv1
  name: myappv1
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: myappv1
  type: ClusterIP
[root@master svc]# kubectl apply -f clusterip.yml

[root@master svc]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   37h
myappv1      ClusterIP   10.110.12.255   <none>        80/TCP    50s

#service创建后集群DNS提供服务解析
[root@master svc]# dig myappv1.default.svc.cluster.local. @10.96.0.10
; <<>> DiG 9.16.23-RH <<>> myappv1.default.svc.cluster.local. @10.96.0.10
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36832
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 9b63b5d828c7c4d3 (echoed)
;; QUESTION SECTION:
;myappv1.default.svc.cluster.local. IN  A

;; ANSWER SECTION:
myappv1.default.svc.cluster.local. 30 IN A      10.110.12.255	#可以解析到服务对应的集群IP

;; Query time: 1 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Tue Oct 14 00:37:04 CST 2025
;; MSG SIZE  rcvd: 123

可以指定externalIPs 给集群内部用的 “外部 IP 标识”,而非给外部网络用的访问入口。

[root@master svc]# kubectl expose deployment myappv1 --port=80 --target-port=80 --type=ClusterIP --external-ip=172.25.254.66 --dry-run=client -o yaml >> clusterip.yml
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: myappv1
  name: myappv1
spec:
  externalIPs:
  - 172.25.254.66
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: myappv1
  type: ClusterIP
  
  [root@master svc]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP     PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1       <none>          443/TCP   37h
myappv1      ClusterIP   10.110.12.255   172.25.254.66   80/TCP    12m

  • externalIPs 是给集群内 Pod 访问服务时用的 IP,而非给集群外客户端用的
  • 该 IP 必须能被集群节点识别(通常是节点本身已配置的 IP)
  • 不提供外部访问能力,仅用于内部通信的 IP 标识兼容

externalIPs使用场景

服务迁移过渡场景

当你将原本运行在集群外的服务(如物理机、虚拟机上的旧服务)迁移到 Kubernetes 集群内时,集群内其他应用可能仍依赖旧服务的外部 IP 地址(例如 172.25.254.66)进行通信。

此时可以:

  • 在集群内部署新服务的 Deployment
  • 创建 ClusterIP Service 并指定 externalIPs: [172.25.254.66]

这样,集群内的应用无需修改配置(仍使用旧 IP 访问),流量会自动路由到集群内的新服务,实现平滑迁移。

4.2 cluster中的headless

headless(无头服务)

对于无头 Services 并不会分配 Cluster IP,kube-proxy不会处理它们, 而且平台也不会为它们进行负载均衡和路由,集群访问通过dns解析直接指向到业务pod上的IP,所有的调度由dns单独完成

#使用模板生成yaml模板
[root@master svc]# kubectl expose deployment myappv1 --cluster-ip=None --port=80 --target-port=80 --dry-run=client -o yaml
[root@master svc]# vim headless.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myappv1
  name: myappv1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myappv1
  template:
    metadata:
      labels:
        app: myappv1
    spec:
      containers:
      - image: myapp:v1
        name: myapp
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: myappv1
  name: myappv1
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: myappv1
  type: ClusterIP
  clusterIP: None		#开启clusterip无头服务的参数
~

[root@master svc]# kubectl get svc

image-20251014005716515

[root@master svc]# dig myappv1.default.svc.cluster.local. @10.96.0.10

image-20251014005907121

#开个pod来测试,访问无头服务
[root@master svc]# kubectl run test --image=busybox -it
If you don't see a command prompt, try pressing enter.
/ #
/ #
/ # nslookup myappv1		#查询名为 myappv1 的服务的 DNS 记录
Server:         10.96.0.10
Address:        10.96.0.10:53

** server can't find myappv1.cluster.local: NXDOMAIN

Name:   myappv1.default.svc.cluster.local
Address: 10.244.1.4
Name:   myappv1.default.svc.cluster.local
Address: 10.244.2.4

4.3 nodeport

通过ipvs暴漏端口从而使外部主机通过master节点的对外ip:来访问pod业务

其访问过程为:

image-20251014155330399

示例:

#可以通过命令来生成yaml模板
kubectl expose deployment my-microservice --type=NodePort --name=my-microservice-nodeport --port=80 --target-port=80 --port=80 --node-port=30080 
[root@master svc]# vim nodeport.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myappv1
  name: myappv1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myappv1
  template:
    metadata:
      labels:
        app: myappv1
    spec:
      containers:
      - image: myapp:v1
        name: myapp
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: myappv1
  name: myappv1
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
    #nodePort: 33333
  selector:
    app: myappv1
  type: NodePort
  			#也可以添加此参数来指定端口
[root@master svc]# kubectl apply -f nodeport.yml

image-20251014155600420

[!NOTE]

nodeport默认端口范围

nodeport默认端口是30000-32767,超出会报错

可以通过更改api配置文件来突破端口范围限制

[root@k8s-master ~]# vim /etc/kubernetes/manifests/kube-apiserver.yaml

- --service-node-port-range=30000-40000

[!NOTE]

添加“–service-node-port-range=“ 参数,端口范围可以自定义

修改后api-server会自动重启,等apiserver正常启动后才能操作集群

集群重启自动完成在修改完参数后全程不需要人为干预

4. 4 loadbalancer

什么是loadbalance?

image-20250814013402257

在云环境下,Kubernetes 会自动调用云提供商的负载均衡服务(如 AWS ELB、GCP LB ),自动分配一个外部 IP 地址,将流量分发到服务后端的 Pod。该方式受限于云平台,且通常使用云平台的 ELB 等需要额外费用 。

通过云平台分配vip并实现访问,如果是裸金属主机那么需要metallb来实现ip的分配

什么是metallb?

MetalLB 是一个用于在裸机 Kubernetes 集群中提供负载均衡功能的开源项目。在云环境中,Kubernetes 可以借助云提供商(如 AWS、GCP 等)的负载均衡服务(如 ELB、GCE LB ),但在没有云服务的裸机环境中,没有现成的负载均衡解决方案,MetalLB 就填补了这一空白。

工作原理:

ARP 模式:MetalLB 通过响应客户端的 ARP 请求,将分配给 Service 的虚拟 IP 地址映射到一个实际节点的 MAC 地址,从而使客户端将流量发送到正确的节点,然后由节点上的 kube-proxy 进一步将流量转发到后端 Pod。这种模式适用于较小的网络环境,网络中的设备需要支持 ARP 协议。

image-20250814013346129

4.1设置类型为LoadBalancer

[root@master svc]# vim fy.yml
---

apiVersion: v1
kind: Service
metadata:
  labels:
    app: fy
  name: fy
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: fy
  type: LoadBalancer		#设置为LB

[root@master svc]# kubectl apply -f fy.yml
[root@master svc]# kubectl get svc
#因为LoadBalancer模式适用云平台,裸金属环境需要安装metallb提供支持

image-20250813172341246

4.2更改kube-proxy模式

1.#设置ipvs模式,并且开启arp
[root@master mnt]# kubectl -n kube-system edit cm kube-proxy
......
mode: "ipvs"
......
strictARP: true		#开启ARP功能,提供给mentalLB使用
......

2.修改配置文件后,要重启这里的kube-proxy删了会自动开启
[root@master svc]# kubectl -n kube-system delete pods kube-proxy-5xw7s
pod "kube-proxy-5xw7s" deleted
[root@master svc]# kubectl -n kube-system delete pods kube-proxy-gzd6g
pod "kube-proxy-gzd6g" deleted
[root@master svc]# kubectl -n kube-system delete pods kube-proxy-rt9jl
pod "kube-proxy-rt9jl" deleted

4.3部署metalLB

1.下载或导入部署文件
[root@master ~]# wget https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml

[root@master mnt]# docker load -i metalLB.tag.gz

2.上传镜像到harbor
[root@master ~]# docker tag quay.io/metallb/controller:v0.14.8 reg.fy.org/metallb/controller:v0.14.8
[root@master ~]# docker push reg.fy.org/metallb/controller:v0.14.8
[root@master ~]# docker tag quay.io/metallb/speaker:v0.14.8 reg.fy.org/metallb/speaker:v0.14.8
[root@master ~]# docker push reg.fy.org/metallb/speaker:v0.14.8

3.修改部署文件与地址池文件
#部署文件
[root@master ~]# vim metallb-native.yaml
...
image: metallb/controller:v0.14.8
image: metallb/speaker:v0.14.8

#地址池文件
[root@master ~]# vim configmap.yml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool						#地址池名称
  namespace: metallb-system
spec:
  addresses:
  - 172.25.254.50-172.25.254.99			#修改为自己本地地址段

---										#两个不同的kind中间必须加分割
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: example
  namespace: metallb-system
spec:
  ipAddressPools:
  - first-pool							#使用地址池 
   
4.部署
[root@master svc]# kubectl apply -f metallb-native.yaml
[root@master svc]# kubectl apply -f configmap.yml后就能查看分配到的IP
#部署configmap.yml后就能查看分配到的IP

image-20250814012521927

测试

image-20250814012834512

4.5 externalname

  • 开启services后,不会被分配IP,而是用dns解析CNAME固定域名来解决ip变化问题
  • 一般应用于外部业务和pod沟通或外部业务迁移到pod内时
  • 在应用向集群迁移过程中,externalname在过度阶段就可以起作用了。
  • 集群外的资源迁移到集群时,在迁移的过程中ip可能会变化,但是域名+dns解析能完美解决此问题

示例:

#生模板导入
[root@master svc]# kubectl create service externalname ext-service --external-name www.baidu.com --dry-run=client -o yaml > exsvc.yml

[root@master svc]# vim exsvc.yml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: ext-service
  name: ext-service
spec:
  externalName: www.baidu.com
  selector:
    app: ext-service
  type: ExternalName

#部署
[root@master svc]# kubectl apply -f exsvc.yml
[root@master svc]# kubectl get svc
NAME          TYPE           CLUSTER-IP   EXTERNAL-IP     PORT(S)   AGE
ext-service   ExternalName   <none>       www.baidu.com   <none>    10m

#测试
[root@master svc]# kubectl run test --image busyboxplus -it
/ # ping ext-service.default.svc.cluster.local

image-20250814101228658

五 Ingress-nginx

官网:

https://kubernetes.github.io/ingress-nginx/deploy/#bare-metal-clusters

5.1 ingress-nginx功能

image-20251015164650590

  • 一种全局的、为了代理不同后端 Service 而设置的负载均衡服务,支持7层
  • Ingress由两部分组成:Ingress controller和Ingress服务
  • Ingress Controller 会根据你定义的 Ingress 对象,提供对应的代理能力。
  • 业界常用的各种反向代理项目,比如 Nginx、HAProxy、Envoy、Traefik 等,都已经为Kubernetes 专门维护了对应的 Ingress Controller。

5.2 部署ingress

1.下载或导入部署文件

#通过github下载
[root@k8s-master ~]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.11.2/deploy/static/provider/baremetal/deploy.yaml

#导入镜像包
[root@master ingress]# docker load -i ingress-nginx-1.13.1.tar
Loaded image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.6.1
Loaded image: registry.k8s.io/ingress-nginx/controller:v1.13.1

#打标签上传到harbor
[root@master ingress]# docker tag registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.6.1 reg.fy.org/ingress-nginx/kube-webhook-certgen:v1.6.1
[root@master ingress]# docker push reg.fy.org/ingress-nginx/kube-webhook-certgen:v1.6.1

[root@master ingress]# docker tag registry.k8s.io/ingress-nginx/controller:v1.13.1 reg.fy.org/ingress-nginx/controller:v1.13.1
[root@master ingress]# docker push reg.fy.org/ingress-nginx/controller:v1.13.1

2.部署ingress

#编辑部署文件
[root@master ingress]# vim deploy.yaml
445         image: ingress-nginx/controller:v1.11.2		#指定仓库镜像
546         image: ingress-nginx/kube-webhook-certgen:v1.4.3
599         image: ingress-nginx/kube-webhook-certgen:v1.4.3

#开始部署
[root@master ingress]# kubectl apply -f deploy.yaml

#查看部署情况
[root@master ingress]# kubectl -n ingress-nginx get all
NAME                                            READY   STATUS    RESTARTS       AGE
pod/ingress-nginx-controller-7bf698f798-z8twz   1/1     Running   3 (143m ago)   13h

NAME                                         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/ingress-nginx-controller             ClusterIP   10.104.10.221    <none> 	      80/TCP,443/TCP   13h
service/ingress-nginx-controller-admission   ClusterIP   10.104.245.250   <none>        443/TCP          13h

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/ingress-nginx-controller   1/1     1            1           13h

NAME                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/ingress-nginx-controller-7bf698f798   1         1         1       13h

#修改微服务为loadbalancer,对外开放供给外部访问
[root@master ingress]# kubectl -n ingress-nginx edit svc ingress-nginx-controller
49   type: LoadBalancer


[root@master ingress]# kubectl -n ingress-nginx get all
......
NAME                                         TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
service/ingress-nginx-controller             LoadBalancer   10.104.10.221    172.25.254.50   80:32205/TCP,443:31873/TCP   13h
......
#微服务类型为loadbalancer后可以获取到VIP供外部访问

5.3 测试ingress示例

#生成一个单pod的负载均衡ingress

1.建立用于测试的控制器lb的模板yaml

#生成控制器模板
[root@master ingress]# kubectl create deployment lb --image myapp:v1 --replicas=2 --dry-run=client -o yaml > lb.yml

[root@master ingress]# vim lb.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: lb
  name: lb
spec:
  replicas: 2
  selector:
    matchLabels:
      app: lb
  template:
    metadata:
      labels:
        app: lb
    spec:
      containers:
      - image: myapp:v1
        name: lbmyapp
        
[root@master ingress]# kubectl apply -f lb.yml
[root@master ingress]# kubectl get deployments.apps lb
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
lb     2/2     2            2           10m

        
#生成service模板,暴露端口,对外访问
[root@master ingress]# kubectl create service clusterip lb --tcp 80:80 --dry-run=client -o yam >> lb.yml

[root@master ingress]# vim lb.yml
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: lb
  name: lb
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: lb
	type: ClusterIP
	
[root@master ingress]# kubectl apply -f lb.yml
[root@master ingress]# kubectl get svc lb
NAME   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
lb     ClusterIP   10.103.141.28   <none>        80/TCP    8m40s

2.建立ingress的模板yaml

#生成模板
[root@master ingress]# kubectl create ingress lb --class nginx --rule '*/=lb:80' --dry-run=client -o yaml > lb-ingress.yml

[root@master ingress]# vim lb-ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: lb
spec:
  ingressClassName: nginx	#使用nginx这个class
  rules:
  - http:
      paths:
      - backend:
          service:
            name: lb
            port:
              number: 80
        path: /
        pathType: Prefix
#Exact(精确匹配),ImplementationSpecific(特定实现),Prefix(前缀匹配),Regular expression(正则表达式匹配)

[root@master ingress]# kubectl apply -f lb-ingress.yml
[root@master ingress]# kubectl get ingress
NAME   CLASS   HOSTS   ADDRESS         PORTS   AGE
lb     nginx   *       172.25.254.10   80      111s

3.测试

[root@master ingress]# for i in {1..10}; do curl 172.25.254.50/hostname.html; done
lb-95c6d466c-fzx5q
lb-95c6d466c-xsxxw
lb-95c6d466c-fzx5q
lb-95c6d466c-xsxxw
lb-95c6d466c-fzx5q
lb-95c6d466c-xsxxw
lb-95c6d466c-fzx5q
lb-95c6d466c-xsxxw
lb-95c6d466c-fzx5q
lb-95c6d466c-xsxxw

5.4ingress的高级用法

5.4.1 基于路径的访问

1.建立用于测试的控制器myapp,与开启微服务

#建立控制器
[root@master ingress]# kubectl create deployment myappv1 --image myapp:v1 --dry-run=client -o yaml > myappv1.yaml

[root@master ingress]# vim myappv1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myappv1
  name: myappv1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myappv1
  template:
    metadata:
      labels:
        app: myappv1
    spec:
      containers:
      - image: myapp:v1
        name: myappv1

[root@master ingress]# kubectl create deployment myappv2 --image myapp:v2 --dry-run=client -o yaml > myappv2.yaml

[root@master ingress]# vim myappv2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myappv2
  name: myappv2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myappv2
  template:
    metadata:
      labels:
        app: myappv2
    spec:
      containers:
      - image: myapp:v2
        name: myappv2
        
[root@master ingress]# kubectl get pods -o wide
NAME                       READY   STATUS    RESTARTS        AGE   IP           NODE   
myappv1-5c47495d84-68gg2   1/1     Running   3 (5h39m ago)   26h   10.244.1.2   node1   <none>           <none>
myappv2-67cc8c4845-ql9vv   1/1     Running   2 (5h39m ago)   26h   10.244.2.2   node2   <none>           <none>


#开启微服务,暴露端口对外访问
[root@master ingress]# kubectl create service clusterip myappv1 --tcp 80:80 --dry-run=client -o yaml >> myappv1.yaml

[root@master ingress]# vim myappv1.yaml
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: myappv1
  name: myappv1
spec:
  ports:
  - name: myappv1
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: myappv1
  type: ClusterIP

[root@master ingress]# kubectl create service clusterip myappv2 --tcp 80:80 --dry-run=client -o yaml >> myappv2.yaml

[root@master ingress]# vim myappv2.yaml
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: myappv2
  name: myappv2
spec:
  ports:
  - name: myappv2
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: myappv2
  type: ClusterIP
  
[root@master ingress]# kubectl get svc lb
NAME   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
lb     ClusterIP   10.103.141.28   <none>        80/TCP    17h
  

2.建立基于路径访问的ingress

[root@master ingress]# vim path-ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /	
  name: path-ingress
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: myappv1
            port:
              number: 80
        path: /
        pathType: Prefix

      - backend:
          service:
            name: myappv1
            port:
              number: 80
        path: /v1
        pathType: Prefix

      - backend:
          service:
            name: myappv2
            port:
              number: 80
        path: /v2
        pathType: Prefix

[root@master ingress]# kubectl apply -f path-ingress.yml

#查看详细信息
[root@master ingress]# kubectl describe ingress path-ingress
Name:             path-ingress
Labels:           <none>
Namespace:        default
Address:          172.25.254.10
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /     myappv1:80 (10.244.1.2:80)
              /v1   myappv1:80 (10.244.1.2:80)
              /v2   myappv2:80 (10.244.2.2:80)
Annotations:  nginx.ingress.kubernetes.io/rewrite-target: /
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    31s (x2 over 81s)  nginx-ingress-controller  Scheduled for sync

image-20250815221357984

3.测试

[root@master ingress]# curl 172.25.254.50
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
[root@master ingress]# curl 172.25.254.50/v1
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
[root@master ingress]# curl 172.25.254.50/v2
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

5.4.2 基于域名的访问

[root@master ingress]# vim host-ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: host-ingress
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: myappv1
            port:
              number: 80
        path: /
        pathType: Prefix
    host: myappv1.fy.org

  - http:
      paths:
      - backend:
          service:
            name: myappv2
            port:
              number: 80
        path: /
        pathType: Prefix
    host: myappv2.fy.org

[root@master ingress]# kubectl apply -f host-ingress.yml
[root@master ingress]# kubectl describe ingress host-ingress
Name:             host-ingress
Labels:           <none>
Namespace:        default
Address:          172.25.254.10
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host            Path  Backends
  ----            ----  --------
  myappv1.fy.org
                  /   myappv1:80 (10.244.1.2:80)
  myappv2.fy.org
                  /   myappv2:80 (10.244.2.2:80)
Annotations:      <none>
Events:
  Type    Reason  Age                 From                      Message
  ----    ------  ----                ----                      -------
  Normal  Sync    4s (x3 over 3m21s)  nginx-ingress-controller  Scheduled for sync

image-20250815221333677

#添加本地域名解析

[root@master ingress]# vim /etc/hosts
172.25.254.50 myappv1.fy.org myappv2.fy.org

测试

[root@master ingress]# curl myappv1.fy.org
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
[root@master ingress]# curl myappv2.fy.org
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

5.4.3 建立tls加密

1.建立证书

#建立证书
[root@master ingress]# openssl req -newkey rsa:2048 -nodes -keyout tls.key -x509 -days 365 -subj "/CN=nginxsvc/O=nginxsvc" -out tls.crt
#通过非交互来完成证书信息填入
-subj "/CN=nginxsvc/O=nginxsvc"

2.建立加密资源类型

#建立加密资源类型secret,用于存放tls加密的证书与key
[root@master ingress]# kubectl create secret tls  web-tls-secret --key tls.key --cert tls.crt

[root@master ingress]# kubectl describe secrets web-tls-secret
Name:         web-tls-secret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  kubernetes.io/tls

Data
====
tls.crt:  1164 bytes
tls.key:  1704 bytes

3.编辑yaml文件进行部署

[root@master ingress]# vim tls-ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-test
spec:
  tls:								#指定tls加密信息
  - hosts:							#要加密的主机域名
    - myappv1.fy.org				
    secretName: web-tls-secret		#指定secret
  ingressClassName: nginx
  rules:
  - host: myappv1.fy.org
    http:
      paths:
      - backend:
          service:
            name: myappv1
            port:
              number: 80
        path: /
        pathType: Prefix
        

[root@master ingress]# kubectl apply -f tls-ingress.yml

[root@master ingress]# kubectl describe ingress tls-ingress
Name:             tls-ingress
Labels:           <none>
Namespace:        default
Address:          172.25.254.10
Ingress Class:    nginx
Default backend:  <default>
TLS:
  web-tls-secret terminates myappv1.fy.org
Rules:
  Host            Path  Backends
  ----            ----  --------
  myappv1.fy.org
                  /   myappv1:80 (10.244.1.2:80)
Annotations:      <none>
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    12s (x2 over 19s)  nginx-ingress-controller  Scheduled for sync

image-20250815223902502

4.测试

image-20250815224030105

5.4.4 建立auth认证

1.建立认证文件

#下载认证工具
[root@master ingress]# dnf install httpd-tools -y
#创建认证用户
[root@master ingress]#  htpasswd -cm auth fjw
New password:
Re-type new password:
Adding password for user lee

[root@master ingress]# cat auth		#创建的认证文件名称必须要为auth,默认从auth获取信息
fjw:$apr1$od60beNV$5e2/KtGljoS2FOmX5GZLu1

2.建立加密资源类型

[root@master ingress]# kubectl create secret generic auth-web --from-file=auth
[root@master ingress]# kubectl describe secrets auth-web
Name:         auth-web
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
auth:  42 bytes

3.编辑yaml文件进行部署

[root@master ingress]# cp tls-ingress.yml auth-ingress.yml
[root@master ingress]# vim auth-ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: auth-web
    nginx.ingress.kubernetes.io/auth-realm: "Please input username and password"
  name: tls-ingress
spec:
  tls:
  - hosts:
    - myappv1.fy.org
    secretName: web-tls-secret
  ingressClassName: nginx
  rules:
  - host: myappv1.fy.org
    http:
      paths:
      - backend:
          service:
            name: myappv1
            port:
              number: 80
        path: /
        pathType: Prefix
        
[root@master ingress]# kubectl apply -f auth-ingress.yml

[root@master ingress]# kubectl describe ingress tls-ingress
Name:             tls-ingress
Labels:           <none>
Namespace:        default
Address:          172.25.254.10
Ingress Class:    nginx
Default backend:  <default>
TLS:
  web-tls-secret terminates myappv1.fy.org
Rules:
  Host            Path  Backends
  ----            ----  --------
  myappv1.fy.org
                  /   myappv1:80 (10.244.1.2:80)
Annotations:      nginx.ingress.kubernetes.io/auth-realm: Please input username and password
                  nginx.ingress.kubernetes.io/auth-secret: auth-web
                  nginx.ingress.kubernetes.io/auth-type: basic
Events:
  Type    Reason  Age               From                      Message
  ----    ------  ----              ----                      -------
  Normal  Sync    3s (x3 over 30m)  nginx-ingress-controller  Scheduled for sync

image-20250815231148502

4.测试

image-20250815231016348

5.4.5 rewrite重定向

基本重定向

[root@master ingress]# cat re-ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rw-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /	#访问路径后加任何内容都被定向到/
spec:
  ingressClassName: nginx
  rules:
  - host: myappv1.fy.org
    http:
      paths:
      - backend:
          service:
            name: myappv1
            port:
              number: 80
        path: /test
        pathType: Prefix

[root@master ingress]# kubectl apply -f re-ingress.yml

#测试
[root@master ingress]# curl myappv1.fy.org/test
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

#重定向指定文件

[root@master ingress]# cat re-ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rw-ingress
  annotations:
    nginx.ingress.kubernetes.io/app-root: /hostname.html	#使用app-root
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: myappv1.fy.org
    http:
      paths:
      - backend:
          service:
            name: myappv1
            port:
              number: 80
        path: /
        pathType: Prefix

[root@master ingress]# kubectl apply -f re-ingress.yml
[root@master ingress]# kubectl describe ingress rw-ingress
Name:             rw-ingress
Labels:           <none>
Namespace:        default
Address:          172.25.254.10
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host            Path  Backends
  ----            ----  --------
  myappv1.fy.org
                  /   myappv1:80 (10.244.1.2:80)
Annotations:      nginx.ingress.kubernetes.io/app-root: /hostname.html
                  nginx.ingress.kubernetes.io/use-regex: true
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    63s (x4 over 25m)  nginx-ingress-controller  Scheduled for sync

#测试
[root@master ingress]# curl -L myappv1.fy.org
myappv1-5c47495d84-68gg2
#重定向路径问题
[root@master ingress]# curl -L myappv1.fy.org/fjw/hostname.html
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.12.2</center>
</body>
</html>

#解决重定向路径问题

[root@master ingress]# cat re-ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rw-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2		#使用rewrite-target
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: myappv1.fy.org
    http:
      paths:
      - backend:
          service:
            name: myappv1
            port:
              number: 80
        path: /(.*)/(.*)
        pathType: ImplementationSpecific


[root@master ingress]# kubectl apply  -f re-ingress.yml
[root@master ingress]# kubectl describe ingress rw-ingress
Name:             rw-ingress
Labels:           <none>
Namespace:        default
Address:          172.25.254.10
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host            Path  Backends
  ----            ----  --------
  myappv1.fy.org
                  /(.*)/(.*)   myappv1:80 (10.244.1.2:80)
Annotations:      nginx.ingress.kubernetes.io/rewrite-target: /$2
                  nginx.ingress.kubernetes.io/use-regex: true
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    18m (x2 over 19m)  nginx-ingress-controller  Scheduled for sync


#测试
[root@master ingress]# curl myappv1.fy.org/fjw/
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
[root@master ingress]# curl myappv1.fy.org/fjw/hostname.html
myappv1-5c47495d84-68gg2

六 Canary金丝雀发布

6.1 什么是金丝雀发布?

image-20251015170705373

金丝雀发布(Canary Release)也称为灰度发布,是一种软件发布策略。

主要目的是在将新版本的软件全面推广到生产环境之前,先在一小部分用户或服务器上进行测试和验证,以降低因新版本引入重大问题而对整个系统造成的影响。

是一种Pod的发布方式。金丝雀发布采取先添加、再删除的方式,保证Pod的总量不低于期望值。并且在更新部分Pod后,暂停更新,当确认新Pod版本运行正常后再进行其他版本的Pod的更新。

6.2 Canary发布方式

image-20251015171432563

其中header和weiht中的最多

6.2.1 基于header(http包头)的灰度发布

image-20251015171447413

#示例

#建立版本1的ingress
[root@master ingress]# cat v1-ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: v1-ingress
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: myappv1
            port:
              number: 80
        path: /
        pathType: Prefix

#建立版本2的ingress
[root@master ingress]# cat v2-ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapv2-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"					
    nginx.ingress.kubernetes.io/canary-by-header: "version"
    nginx.ingress.kubernetes.io/canary-by-header-value: "2"
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: myappv2
            port:
              number: 80
        path: /
        pathType: Prefix

#部署
[root@master ingress]# kubectl apply -f v1-ingress.yml
ingress.networking.k8s.io/v1-ingress created
[root@master ingress]# kubectl apply -f v2-ingress.yml
ingress.networking.k8s.io/myapv2-ingress created

#测试
[root@master ingress]# curl 172.25.254.50
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
[root@master ingress]# curl -H "version: 2" 172.25.254.50
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

6.2.2 基于权重的发布

image-20251015171505151

#示例

#添加基于权重的注释参数
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: v2-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"			
    nginx.ingress.kubernetes.io/canary-weight: "10"			#权重值
    nginx.ingress.kubernetes.io/canary-weight-total: "100"	#100次
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: myappv2
            port:
              number: 80
        path: /
        pathType: Prefix

[root@master ingress]# kubectl apply -f v2-ingress.yml
ingress.networking.k8s.io/myapv2-ingress created

[root@master ingress]# cat check_ingress.sh		#使用测试脚本
#!/bin/bash
v1=0
v2=0

for (( i=0; i<100; i++))
do
    response=`curl -s 172.25.254.50 |grep -c v1`

    v1=`expr $v1 + $response`
    v2=`expr $v2 + 1 - $response`

done
echo "v1:$v1, v2:$v2"

[root@master ingress]# sh check_ingress.sh
v1:90, v2:10
#更改完毕权重后继续测试可观察变化
Logo

码道开发者社区,聚焦华为云码道 CodeArts 代码智能体,沉淀 Agent、Skill、鸿蒙开发实战内容,供开发者查阅资料、交流技术、分享工程实践

更多推荐