kubectl_入门_service详解

Service

我们知道 Pod 的生命周期是有限的。可以用 ReplicaSet 和Deployment 来动态的创建和销毁 Pod,每个 Pod 都有自己的 IP 地址,但是如果 Pod 重建了的话那么他的 IP 很有可能也就变化了。

这就会带来一个问题:比如我们有一些后端的 Pod 集合为集群中的其他应用提供 API 服务,如果我们在前端应用中把所有的这些后端的 Pod 的地址都写死,然后以某种方式去访问其中一个 Pod 的服务,这样看上去是可以工作的,但是如果这个 Pod 挂掉了,然后重新启动起来了,是不是 IP 地址非常有可能就变了,这个时候前端就极大可能访问不到后端的服务了。

为解决这个问题 Kubernetes 就为我们提供Service对象,Service 是一种抽象的对象,它定义了一组 Pod 的逻辑集合和一个用于访问它们的策略,其实这个概念和微服务非常类似。一个 Serivce 下面包含的 Pod 集合是由 Label Selector 来决定的。

在这里插入图片描述

1. kube-proxy

service在很多情况下只是一个概念,真正起作用的其实是kube-proxy服务进程,每个node节点上都运行一个kube-proxy服务进程,当创建service的时候会通过api-server向etcd写入创建的service信息,而kube-proxy会基于监听的机制发现这种service的变动,然后它会将最新的service信息转换成对应的访问规则

在这里插入图片描述

kube-proxy目前支持三种工作模式:

  • userspace模式
  • iptables模式
  • ipvs模式

1.1 userspace模式

userspace模式下,kube-proxy为service后端的每个service创建一个监听端口,发向cluster ip的请求被iptables规则重定向到kube-proxy监听的端口上,kube-proxy根据LB算法选择一个提供服务的pod并和其建立连接,以将请求转发到pod上。

该模式下,kube-proxy充当了一个四层负载均衡器的角色,由于kube-proxy运行在userspace中,在进行转发处理时会增加内核和用户空间之间的数据拷贝,虽然比较稳定,但是效率比较低。

在这里插入图片描述

1.2 iptables模式

iptables模式下,kube-proxy为service后端的每个pod创建对应的iptables规则,直接将发向cluster ip的请求重定向到一个pod ip。

该模式下kube-proxy不承担四层负载均衡器的角色,只负责创建iptables规则。该模式的优点是较userspace模式效率更高,但不能提供灵活的LB策略,当后端pod不可用时也无法进行重试

在这里插入图片描述

1.3 ipvs模式

ipvs模式和iptables类似,kube-proxy监控pod的变化并创建相应的ipvs规则,ipvs相对iptables转发效率更高。除此以外,ipvs支持更多的LB算法。

在这里插入图片描述

此模式必须安装ipvs内核模块,否则会降级为iptables。

  • 安装ipset和ipvsadm

    [root@master ~]# yum install ipset ipvsadm -y
    
  • 写入脚本文件

    [root@master ~]# cat <<EOF> /etc/sysconfig/modules/ipvs.modules
    > #!/bin/bash
    modprobe -- ip_vs
    modprobe -- ip_vs_rr
    modprobe -- ip_vs_wrr
    modprobe -- ip_vs_sh
    modprobe -- nf_conntrack_ipv4
    EOF
    
  • 执行

    [root@master ~]# chmod +x /etc/sysconfig/modules/ipvs.modules 
    #执行脚本文件
    [root@master ~]# /bin/bash /etc/sysconfig/modules/ipvs.modules
    

    查看对应的模块是否加载成功

    [root@master ~]# lsmod |grep -e ip_vs -e nf_conntrack_ipv4
    ip_vs_sh               12688  0 
    ip_vs_wrr              12697  0 
    ip_vs_rr               12600  0 
    ip_vs                 145497  6 ip_vs_rr,ip_vs_sh,ip_vs_wrr
    nf_conntrack_ipv4      15053  15 
    nf_defrag_ipv4         12729  1 nf_conntrack_ipv4
    nf_conntrack          139264  10 ip_vs,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,nf_nat_masquerade_ipv4,nf_nat_masquerade_ipv6,nf_conntrack_netlink,nf_conntrack_ipv4,nf_conntrack_ipv6
    libcrc32c              12644  4 xfs,ip_vs,nf_nat,nf_conntrack

    重启系统。

  • 开启ipvs

    [root@master ~]# kubectl edit cm kube-proxy -n kube-system
    

    将mode改为ipvs

    在这里插入图片描述

    删除kube-proxy的pod并重建

    [root@master ~]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system
    pod "kube-proxy-lwls6" deleted
    pod "kube-proxy-scwzg" deleted
    pod "kube-proxy-sn9kc" deleted
    

    查看ipvs,发现产生了一批规则

    [root@master ~]# ipvsadm -Ln
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    TCP  172.17.0.1:30002 rr-> 10.244.1.95:80               Masq    1      0          0         -> 10.244.1.97:80               Masq    1      0          0         -> 10.244.2.41:80               Masq    1      0          0         
    TCP  172.17.0.1:32000 rr-> 10.244.0.15:8443             Masq    1      0          0         
    TCP  172.18.0.1:30002 rr-> 10.244.1.95:80               Masq    1      0          0         -> 10.244.1.97:80               Masq    1      0          0         -> 10.244.2.41:80               Masq    1      0          0         
    TCP  172.18.0.1:32000 rr-> 10.244.0.15:8443             Masq    1      0          0         
    TCP  172.19.0.1:30002 rr-> 10.244.1.95:80               Masq    1      0          0         -> 10.244.1.97:80               Masq    1      0          0         -> 10.244.2.41:80               Masq    1      0          0         
    TCP  172.19.0.1:32000 rr-> 10.244.0.15:8443             Masq    1      0          0         
    TCP  172.21.0.1:30002 rr-> 10.244.1.95:80               Masq    1      0          0         -> 10.244.1.97:80               Masq    1      0          0         -> 10.244.2.41:80               Masq    1      0          0         
    TCP  172.21.0.1:32000 rr-> 10.244.0.15:8443             Masq    1      0          0         
    TCP  172.22.0.1:30002 rr-> 10.244.1.95:80               Masq    1      0          0         -> 10.244.1.97:80               Masq    1      0          0         -> 10.244.2.41:80               Masq    1      0          0         
    TCP  172.22.0.1:32000 rr-> 10.244.0.15:8443             Masq    1      0          0         
    TCP  172.24.0.1:30002 rr-> 10.244.1.95:80               Masq    1      0          0         -> 10.244.1.97:80               Masq    1      0          0         -> 10.244.2.41:80               Masq    1      0          0         
    TCP  172.24.0.1:32000 rr-> 10.244.0.15:8443             Masq    1      0          0         
    TCP  172.25.0.1:30002 rr-> 10.244.1.95:80               Masq    1      0          0         -> 10.244.1.97:80               Masq    1      0          0         -> 10.244.2.41:80               Masq    1      0          0         
    TCP  172.25.0.1:32000 rr-> 10.244.0.15:8443             Masq    1      0          0         
    TCP  192.168.200.101:30002 rr-> 10.244.1.95:80               Masq    1      0          0         -> 10.244.1.97:80               Masq    1      0          0         -> 10.244.2.41:80               Masq    1      0          0         
    TCP  192.168.200.101:32000 rr-> 10.244.0.15:8443             Masq    1      0          0         
    TCP  10.96.0.1:443 rr-> 192.168.200.101:6443         Masq    1      0          0         
    TCP  10.96.0.10:53 rr-> 10.244.0.14:53               Masq    1      0          0         -> 10.244.0.16:53               Masq    1      0          0         
    TCP  10.96.0.10:9153 rr-> 10.244.0.14:9153             Masq    1      0          0         -> 10.244.0.16:9153             Masq    1      0          0         
    TCP  10.96.34.175:443 rr-> 10.244.0.15:8443             Masq    1      0          0         
    TCP  10.96.106.156:8000 rr-> 10.244.0.13:8000             Masq    1      0          0         
    TCP  10.96.127.29:443 rr-> 10.244.2.40:4443             Masq    1      0          0         
    TCP  10.96.253.220:80 rr-> 10.244.1.95:80               Masq    1      0          0         -> 10.244.1.97:80               Masq    1      0          0         -> 10.244.2.41:80               Masq    1      0          0         
    TCP  10.244.0.0:30002 rr-> 10.244.1.95:80               Masq    1      0          0         -> 10.244.1.97:80               Masq    1      0          0         -> 10.244.2.41:80               Masq    1      0          0         
    TCP  10.244.0.0:32000 rr-> 10.244.0.15:8443             Masq    1      0          0         
    TCP  10.244.0.1:30002 rr-> 10.244.1.95:80               Masq    1      0          0         -> 10.244.1.97:80               Masq    1      0          0         -> 10.244.2.41:80               Masq    1      0          0         
    TCP  10.244.0.1:32000 rr-> 10.244.0.15:8443             Masq    1      0          0         
    UDP  10.96.0.10:53 rr-> 10.244.0.14:53               Masq    1      0          0         -> 10.244.0.16:53               Masq    1      0          0   
    

2. 配置说明(资源文件清单)

kind: Service  #资源类型
apiVersion: v1 #资源版本
metadata: name: servicenamespace: dev
spec:selector:  #标签选择器,用于确定当前service代理哪些podapp: nginxtype: #service类型,指定service的访问方式clusterIp: #虚拟服务的ip地址sessionAffinity: #session亲和性,支持ClientIp,None两个选项ports: #端口信息- protocol: TCPport: 3017  #service端口targetPort: 5003  #pod端口nodePort: 31122   #主机端口

Service类型

  • ClusterIp:默认值,它是K8S系统自动分配的虚拟IP,只能在集群内部访问
  • NodePort:将Service通过指定的Node上的端口暴露给外部,通过此方法,就可以在集群外部访问服务
  • LoadBalancer:使用外接负载均衡器完成到服务的负载分发,注意此模式需要外部云环境支持
  • ExternalName:把集群外部的服务引入到集群内部直接使用

3. 使用

利用deployment创建出3个pod,为pod设置app=nginx-pod的标签

创建deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata: name: pc-deploymentnamespace: dev
spec:replicas: 3selector:matchLabels:app: nginx-podtemplate:metadata: labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports: - containerPort: 80
[root@master service]# kubectl create -f deployment.yaml 
deployment.apps/pc-deployment created
[root@master service]# kubectl get pod -n dev -o wide
NAME                             READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
pc-deployment-6756f95949-rdpc5   1/1     Running   0          65s   10.244.2.45    node2   <none>           <none>
pc-deployment-6756f95949-sd724   1/1     Running   0          65s   10.244.1.120   node1   <none>           <none>
pc-deployment-6756f95949-xbk6d   1/1     Running   0          65s   10.244.1.121   node1   <none>           <none>

通过pod的Ip加上容器端口80访问nginx,验证是否可以访问

在这里插入图片描述

在这里插入图片描述

为了方便后面的测试,修改下面三台nginx的index.html页面(三台修改的Ip地址不一致)

#修改第一个pod
[root@master ~]# kubectl exec -it pc-deployment-6756f95949-sd724 -n dev -- /bin/sh
# echo "10.244.1.62" > /usr/share/nginx/html/index.html
# exit
#修改第二个pod
[root@master ~]# kubectl exec -it pc-deployment-6756f95949-xbk6d -n dev -- /bin/sh
# echo "10.244.2.32" > /usr/share/nginx/html/index.html
# exit
#修改第三个pod
[root@master ~]# kubectl exec -it pc-deployment-6756f95949-rdpc5 -n dev -- /bin/sh
# echo "10.244.1.61" > /usr/share/nginx/html/index.html
# exit

在这里插入图片描述

3.1 ClusterIp类型的Service

创建service-clusterip.yaml文件

apiVersion: v1
kind: Service
metadata:name: service-clusteripnamespace: dev
spec:selector:app: nginx-podtype: ClusterIP #clusterIP: 10.96.96.96  #service的Ip地址,如果不写,会默认生成一个ports:- port: 80  #service端口targetPort: 80  #pod端口
[root@master service]# kubectl create -f service-clusterip.yaml
service/service-clusterip created
[root@master service]# kubectl get svc service-clusterip -n dev
NAME                TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service-clusterip   ClusterIP   10.96.66.152   <none>        80/TCP    8s
[root@master service]# kubectl describe svc service-clusterip -n dev
Name:              service-clusterip
Namespace:         dev
Labels:            <none>
Annotations:       <none>
Selector:          app=nginx-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.96.66.152
IPs:               10.96.66.152
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.1.120:80,10.244.1.121:80,10.244.2.45:80
Session Affinity:  None
Events:            <none>
[root@master service]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags-> RemoteAddress:Port           Forward Weight ActiveConn InActConn      
TCP  10.96.66.152:80 rr-> 10.244.1.120:80              Masq    1      0          0         -> 10.244.1.121:80              Masq    1      0          0         -> 10.244.2.45:80               Masq    1      0          0         

3.2 EndPoint

从上面的信息中我们看到有个字段叫EndpointsEndpoint是Kubernetes中的一个资源对象,存储在etcd中,用来记录一个service对应的所有Pod的访问地址,它是根据service配置文件中的selector描述产生的。

一个service由一组Pod组成,这些Pod通过Endpoints暴露出来,Endpoints是实现实际服务的端点集合。换言之,service和Pod之间的联系是通过Endpoints实现的。

在这里插入图片描述

[root@master service]# kubectl get endpoints -n dev -o wide
NAME                ENDPOINTS                                        AGE
service-clusterip   10.244.1.120:80,10.244.1.121:80,10.244.2.45:80   5m7s

3.3 负载分发策略

对service的访问被分发到了后端的pod上去,目前k8s提供了两种负载分发策略:

  • 如果不定义,默认使用kube-proxy的策略,比如随机,轮询
  • 基于客户端地址的会话保持模式,即来自同一个客户端发起的所有请求都会转发到一个固定的pod上,此模式可以使在spec中添加sessionAffinity:ClientIP选项
#循环访问测试
[root@master service]# while true;do curl 10.96.66.152:80;sleep 5;done;
10.244.2.45
10.244.1.121
10.244.1.120
10.244.2.45
10.244.1.121
10.244.1.120

修改分发策略为sessionAffinity:ClientIP

apiVersion: v1
kind: Service
metadata:name: service-clusteripnamespace: dev
spec:sessionAffinity: ClientIPselector:app: nginx-podclusterIP: 10.96.66.152  #service的Ip地址,如果不写,会默认生成一个type: ClusterIPports:- port: 80  #service端口targetPort: 80  #pod端口
[root@master service]# kubectl delete -f service-clusterip.yaml           
service "service-clusterip" deleted
[root@master service]# vim service-clusterip.yaml 
apiVersion: v1
kind: Service
metadata:name: service-clusteripnamespace: dev
spec:selector:app: nginx-podtype: ClusterIPports:- port: 80  #service端口
apiVersion: v1
kind: Service
metadata:name: service-clusteripnamespace: dev
spec:sessionAffinity: ClientIPselector:app: nginx-podclusterIP: 10.96.66.152  #service的Ip地址,如果不写,会默认生成一个type: ClusterIPports:- port: 80  #service端口targetPort: 80  #pod端口"service-clusterip.yaml" 14L, 320C 已写入                                                                        
[root@master service]# kubectl create -f service-clusterip.yaml
service/service-clusterip created
[root@master service]# kubectl describe svc service-clusterip -n dev
Name:              service-clusterip
Namespace:         dev
Labels:            <none>
Annotations:       <none>
Selector:          app=nginx-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.96.66.152
IPs:               10.96.66.152
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.1.120:80,10.244.1.121:80,10.244.2.45:80
Session Affinity:  ClientIP
Events:            <none>

重新查看ipvs映射规则【persistent代表持久】,发现新增了persistent 10800秒,代表持续180分钟

[root@master service]# ipvsadm -Ln
TCP  10.96.66.152:80 rr persistent 10800-> 10.244.1.120:80              Masq    1      0          1         -> 10.244.1.121:80              Masq    1      0          1         -> 10.244.2.45:80               Masq    1      0          1    

再次进行循环访问测试,发现这次只访问一个pod

[root@master service]# while true;do curl 10.96.66.218:80;sleep 5;done;
10.244.2.45
10.244.2.45
10.244.2.45
10.244.2.45

3.4 HeadLiness类型的Service

在某些场景中,开发人员可能不想使用Service提供的负载均衡功能,而希望自己来控制负载均衡策略,针对这种情况,k8s提供了HeadLiness Service,这类Service不会分配ClusterIP,如果想要访问Service,只能通过service的域名进行查询。

创建service-headliness.yaml

apiVersion: v1
kind: Service
metadata:name: service-headlinessnamespace: dev
spec:selector:app: nginx-podclusterIP: None  #将clusterIP设置为None,即可创建headliness Servicetype: ClusterIPports:- port: 80targetPort: 80
[root@master service]# kubectl create -f service-headliness.yaml
service/service-headliness created
[root@master service]# kubectl get svc service-headliness -n dev
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-headliness   ClusterIP   None         <none>        80/TCP    6s
[root@master service]# kubectl describe svc service-headliness -n dev
Name:              service-headliness
Namespace:         dev
Labels:            <none>
Annotations:       <none>
Selector:          app=nginx-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                None
IPs:               None
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.1.120:80,10.244.1.121:80,10.244.2.45:80
Session Affinity:  None
Events:            <none>

查看域名解析情况

[root@master service]# kubectl exec -it pc-deployment-6756f95949-rdpc5 -n dev -- /bin/sh
# cat /etc/resolv.conf
nameserver 10.96.0.10
search dev.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
# exit
#需要进入pod访问 但是pod内 无curl命令
#通过域名进行查询验证一下即可
[root@master ~]# yum -y install bind-utils
[root@master ~]# dig @10.96.0.10 service-headliness.dev.svc.cluster.local
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.9 <<>> @10.96.0.10 service-headliness.dev.svc.cluster.local
; (1 server found)
;; 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: 3116
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;service-headliness.dev.svc.cluster.local. IN A;; ANSWER SECTION:
service-headliness.dev.svc.cluster.local. 30 IN A 10.244.1.120
service-headliness.dev.svc.cluster.local. 30 IN A 10.244.2.45
service-headliness.dev.svc.cluster.local. 30 IN A 10.244.1.121;; Query time: 9 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: 日 814 13:18:02 CST 2022
;; MSG SIZE  rcvd: 237

3.5 NodePort类型的Service

在前面的应用中,创建的Service的IP地址只有集群内部可以访问,如果希望Service暴露给集群外部使用,那么就要使用到另外一种类型的Service,称为NodePort类型。NodePort的工作原理其实就是将service的端口映射到Node的一个端口上,然后就可以通过NodeIp:NodePort来访问service了。

在这里插入图片描述

创建service-nodeport.yaml

apiVersion: v1
kind: Service
metadata: name: service-nodeportnamespace: dev
spec:selector:app: nginx-podtype: NodePort  #service类型ports:- port: 80nodePort: 30003 #指定绑定的node的端口(默认的取值范围是:30000-32767),如果不指定,会默认分配targetPort: 80
[root@master service]# kubectl create -f service-nodeport.yaml    
service/service-nodeport created
[root@master service]# kubectl get svc service-nodeport -n dev
NAME               TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service-nodeport   NodePort   10.96.114.171   <none>        80:30003/TCP   14s

在这里插入图片描述

3.6 LoadBalancer类型的Service

LoadBalancer和NodePort很相似,目的都是向外部暴露一个端口,区别在于LoadBalancer会在集群的外部再来做一个负载均衡设备,而这个设备需要外部环境支持的,外部服务发送到这个设备上的请求,会被设备负载之后转发到集群中。

在这里插入图片描述

3.7 ExternalName类型的Service

ExternalName类型的Service用于引入集群外部的服务,它通过externalName属性指定外部一个服务的地址,然后在集群内部访问此Service就可以访问到外部的服务了

在这里插入图片描述

创建service-externalname.yaml

apiVersion: v1
kind: Service
metadata:name: service-externalnamenamespace: dev
spec:type: ExternalName  #service类型externalName: www.baidu.com  #改成ip地址也可以
[root@master service]# kubectl create -f service-externalname.yaml 
service/service-externalname created
[root@master service]# kubectl get svc service-externalname -n dev
NAME                   TYPE           CLUSTER-IP   EXTERNAL-IP     PORT(S)   AGE
service-externalname   ExternalName   <none>       www.baidu.com   <none>    5s
[root@master service]# dig @10.96.0.10 service-externalname.dev.svc.cluster.local; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.9 <<>> @10.96.0.10 service-externalname.dev.svc.cluster.local
; (1 server found)
;; 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: 51694
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;service-externalname.dev.svc.cluster.local. IN A;; ANSWER SECTION:
service-externalname.dev.svc.cluster.local. 30 IN CNAME www.baidu.com.
www.baidu.com.          30      IN      CNAME   www.a.shifen.com.
www.a.shifen.com.       30      IN      A       14.215.177.39
www.a.shifen.com.       30      IN      A       14.215.177.38;; Query time: 98 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: 日 814 21:52:44 CST 2022
;; MSG SIZE  rcvd: 247

4. Ingress

4.1 介绍

在前面的学习中已经知道,Service对集群之外暴露服务的主要方式有两种:NodePort和LoadBalancer,但是这两种方式,都有一定的缺点:

  • NodePort方式的缺点是会占用很多集群机器的端口,那么当集群服务变多的时候,这个缺点就愈发明显
  • LB方式的缺点是每个service需要一个LB,浪费、麻烦,并且需要k8s之外设备的支持

基于这种现状,k8s提供了Ingress资源对象。工作机制大致如下图所示:

在这里插入图片描述

实际上,Ingress相当于一个7层的负载均衡器,是k8s对反向代理的一个抽象,它的工作原理类似于Nginx,可以理解成在Ingress里建立诸多映射规则,Ingress Controller通过监听这些配置规则并转化成Nginx的配置,然后对外部提供服务。在这里有两个核心概念:

  • ingress:k8s中的一个对象,作用是定义请求如何转发到service的规则
  • ingress controller:具体实现反向代理及负载均衡的程序,对ingress定义的规则进行解析,根据配置的规则来实现请求转发,实现方式有很多,比如nginx,contour,haproxy等等。

Ingress(以nginx为例)的工作原理如下:

  1. 用户编写ingress规则,说明哪个域名对应k8s集群中的哪个service
  2. ingress控制器动态感知ingress服务规则的变化,然后生成一段对应的nginx配置
  3. ingress控制器会将生成的nginx配置写入到一个运行着的nginx服务中,并动态更新
  4. 到此为止,其实真正在工作的就是一个nginx了,内部配置了用户定义的请求转发规则

在这里插入图片描述

4.2 使用

4.2.1 搭建ingress环境
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.0/deploy/static/provider/cloud/deploy.yaml

由于一些原因,镜像无法下载所以资料中准备好了修改过后的deploy.yaml

[root@master ingress-controller]# kubectl label nodes node1 hasIngress=true
[root@master ingress-controller]# kubectl label nodes node2 hasIngress=true
[root@master ingress-controller]# kubectl apply -f deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
serviceaccount/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
configmap/ingress-nginx-controller created
service/ingress-nginx-controller created
service/ingress-nginx-controller-admission created
daemonset.apps/ingress-nginx-controller created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
ingressclass.networking.k8s.io/nginx created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
[root@master ingress-controller]# kubectl get pod -n ingress-nginx -o wide 
[root@master ingress-controller]# kubectl get pod -n ingress-nginx -o wide 
NAME                                   READY   STATUS      RESTARTS   AGE   IP                NODE    NOMINATED NODE   READINESS GATES
ingress-nginx-admission-create-vlr4h   0/1     Completed   0          24m   10.244.1.125      node1   <none>           <none>
ingress-nginx-admission-patch-vlx7d    0/1     Completed   1          24m   10.244.1.126      node1   <none>           <none>
ingress-nginx-controller-m5jld         1/1     Running     0          24m   192.168.200.102   node1   <none>           <none>
ingress-nginx-controller-t52dn         1/1     Running     0          24m   192.168.200.103   node2   <none>           <none>
[root@master ingress-controller]# kubectl get svc -n ingress-nginx
NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.96.49.11     <pending>     80:31915/TCP,443:30664/TCP   24m
ingress-nginx-controller-admission   ClusterIP      10.96.201.100   <none>        443/TCP                      24m
4.2.2 准备service和pod

创建下图所示的模型

在这里插入图片描述

创建tomcat-nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata: name: nginx-deploymentnamespace: dev
spec:replicas: 3selector:matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports: - containerPort: 80---apiVersion: apps/v1
kind: Deployment
metadata: name: tomcat-deploymentnamespace: dev
spec:replicas: 3selector:matchLabels:app: tomcat-podtemplate:metadata:labels:app: tomcat-podspec:containers:- name: tomcatimage: tomcat:8.5-jre10-slimports: - containerPort: 8080---apiVersion: v1
kind: Service
metadata: name: nginx-servicenamespace: dev
spec:selector:app: nginx-podclusterIP: Nonetype: ClusterIPports:- port: 80targetPort: 80---apiVersion: v1
kind: Service
metadata: name: tomcat-servicenamespace: dev
spec:selector:app: tomcat-podclusterIP: Nonetype: ClusterIPports:- port: 8080targetPort: 8080
[root@master service]# kubectl create -f tomcat-nginx.yaml 
deployment.apps/nginx-deployment created
deployment.apps/tomcat-deployment created
service/nginx-service created
service/tomcat-service created
[root@master service]# kubectl get svc -n dev
NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
nginx-service    ClusterIP   None         <none>        80/TCP     50s
tomcat-service   ClusterIP   None         <none>        8080/TCP   50s
4.2.3 Http代理

创建ingress-http.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: ingress-httpnamespace: dev
spec:ingressClassName: nginxrules:- host: nginx.test.comhttp:paths:- path: /pathType: Prefixbackend:service:name: nginx-serviceport:number: 80- host: tomcat.test.comhttp:paths:- path: /pathType: Prefixbackend:service:name: tomcat-serviceport:number: 8080
[root@master service]# kubectl create -f ingress-http.yaml 
ingress.networking.k8s.io/ingress-http created
[root@master service]# kubectl get ing ingress-http -n dev
NAME           CLASS   HOSTS                            ADDRESS   PORTS   AGE
ingress-http   nginx   nginx.test.com,tomcat.test.com             80      22s
[root@master service]# kubectl describe ing ingress-http -n dev
Name:             ingress-http
Labels:           <none>
Namespace:        dev
Address:          
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:Host             Path  Backends----             ----  --------nginx.test.com   /   nginx-service:80 (10.244.1.120:80,10.244.1.121:80,10.244.1.129:80 + 3 more...)tomcat.test.com  /   tomcat-service:8080 (10.244.1.127:8080,10.244.1.128:8080,10.244.2.49:8080)
Annotations:       <none>
Events:Type    Reason  Age   From                      Message----    ------  ----  ----                      -------Normal  Sync    29s   nginx-ingress-controller  Scheduled for syncNormal  Sync    29s   nginx-ingress-controller  Scheduled for sync

修改本机的hosts文件

node虚拟机的IP地址    nginx.test.com
node虚拟机的IP地址    tomcat.test.com

在这里插入图片描述

查看ingress为service提供的端口号

[root@master service]# kubectl get svc -n ingress-nginx
NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.96.49.11     <pending>     80:31915/TCP,443:30664/TCP   38m
ingress-nginx-controller-admission   ClusterIP      10.96.201.100   <none>        443/TCP                      38m

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/web/6019.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

jupyter notebook切换conda虚拟环境

首先&#xff0c;切换到某个虚拟环境&#xff0c;本人切换到了d2l环境&#xff1a; (d2l) C:\Users\10129>pip install ipykernel然后&#xff0c;如代码所示安装ipykernel包 最后&#xff0c;按下述代码执行&#xff1a; (d2l) C:\Users\10129>python -m ipykernel i…

mac电脑关于ios端的appium真机自动化测试环境搭建

一、app store 下载xcode,需要登录apple id 再开始下载 二、安装homebrew 1、终端输入命令&#xff1a; curl -fsSL <https://gitee.com/cunkai/HomebrewCN/raw/master/Homebrew.sh>如果不能直接安装&#xff0c;而是出现了很多内容&#xff0c;那么这个时候不要着急&…

国产服务器操作系统部署NTP服务 _ 统信UOS _ 麒麟 _ 中科方德

原文链接&#xff1a;国产服务器操作系统部署NTP服务 | 统信UOS | 麒麟 | 中科方德 Hello&#xff0c;大家好啊&#xff01;在保持服务器时间的精确同步方面&#xff0c;时间同步服务器&#xff08;NTP服务器&#xff09;扮演着至关重要的角色&#xff0c;它能确保系统操作的时…

【论文阅读笔记】TS2Vec: Towards Universal Representation of Time Series

【论文阅读笔记】TS2Vec: Towards Universal Representation of Time Series 摘要 这段文字介绍了一个名为TS2Vec的通用框架&#xff0c;用于学习时间序列数据的表示&#xff0c;可以在任意语义层次上进行。与现有方法不同&#xff0c;TS2Vec通过对增强的上下文视图进行层次化…

【热门话题】Stylus 入门与实践详解

&#x1f308;个人主页: 鑫宝Code &#x1f525;热门专栏: 闲话杂谈&#xff5c; 炫酷HTML | JavaScript基础 ​&#x1f4ab;个人格言: "如无必要&#xff0c;勿增实体" 文章目录 Stylus 入门与实践详解引言一、Stylus 简介1.1 什么是 Stylus&#xff1f;1.2 S…

【51单片机LCD1602显示矩阵键盘原始键值】2023-6-1

缘由https://ask.csdn.net/questions/7955623 #include "reg52.h" sbit LCD1602_RS P3^5;//RS端数据命令选择(H/L) sbit LCD1602_RW P3^6;//RW端读写选择(H/L) sbit LCD1602_EN P3^7;//EN端使能信号上升沿25ns void PanDuan1602(/*LCD1602忙判断*/) { LCD1602…

基于Vue Router和element-ui的LayOut

一、展示 二、代码 app.vue <template><div id"app"><el-container style"border: 1px solid #eee; height: 100vh"><el-aside v-bind:width"asideWidth" style"background-color: rgb(48, 65, 86);"><…

前端高频算法

分析算法排序&#xff1a; 时间复杂度: 一个算法执行所耗费的时间。 空间复杂度: 运行完一个程序所需内存的大小。 执行效率、内存消耗、稳定性 三方面入手。 1. 排序 1.1 冒泡排序 冒泡的过程只涉及相邻数据的交换操作&#xff0c;所以它的空间复杂度为 O(1)。 为了保证…

政安晨:【Keras机器学习示例演绎】(二十八)—— 使用 卷积神经网络与循环神经网络 架构进行视频分类

目录 数据收集 设置 定义超参数 数据准备 序列模型 推论 政安晨的个人主页&#xff1a;政安晨 欢迎 &#x1f44d;点赞✍评论⭐收藏 收录专栏: TensorFlow与Keras机器学习实战 希望政安晨的博客能够对您有所裨益&#xff0c;如有不足之处&#xff0c;欢迎在评论区提出指正…

分享自己一篇在亚马逊云科技AWS官网发的Blog技术文章

小李哥在亚马逊AWS官网&#xff0c;作为第一作者发了自己的第一篇AWS Blog文章&#xff0c;也是自己今年在AWS官网的第11篇文章。文章主要内容是描述为出海的金融企业&#xff0c;搭建满足PCI-DSS合规、FIPS 140-2 Level 3安全标准的传输中数据加密云端方案&#xff0c;主要用于…

更深层次理解传输层两协议【UDP | TCP】【UDP 缓冲区 | TCP 8种策略 | 三次握手四次挥手】

博客主页&#xff1a;花果山~程序猿-CSDN博客 文章分栏&#xff1a;Linux_花果山~程序猿的博客-CSDN博客 关注我一起学习&#xff0c;一起进步&#xff0c;一起探索编程的无限可能吧&#xff01;让我们一起努力&#xff0c;一起成长&#xff01; 目录 再谈端口号 端口号的返回…

jsp驾校管理系统Myeclipse开发mysql数据库web结构java编程计算机网页项目

一、源码特点 JSP 驾校管理系统 是一套完善的web设计系统&#xff0c;对理解JSP java编程开发语言有帮助&#xff0c;系统具有完整的源代码和数据库&#xff0c;系统采用serlvetdaobean mvc 模式&#xff0c;系统主要采用B/S模式开发。开发环境为TOMCAT7.0,Myeclipse8.5开发…

解码Starknet Verifier:深入逆向工程之旅

1. 引言 Sandstorm为&#xff1a; 能提交独立proof给StarkWare的Ethereum Verifier&#xff0c;的首个开源的STARK prover。 开源代码见&#xff1a; https://github.com/andrewmilson/sandstorm&#xff08;Rust&#xff09; L2Beat 提供了以太坊上Starknet的合约架构图&…

C语言/数据结构——每日一题(反转链表)

一.前言 大家好&#xff01;今天又是每日一题环节。今天我为大家分享了一道单链表题——反转链表。 废话不多说&#xff0c;让我们直接进入正题吧。 二.正文 1.1题目信息 这是一道leetCode上面的一道题&#xff1a;https://leetcode.cn/problems/reverse-linked-list 1.2解…

2.2 Java全栈开发前端+后端(全栈工程师进阶之路)-前端框架VUE3-基础-Vue基本语法

文本渲染指令 文本渲染指令-v-html与v-text Vue使用了基于HTML的模板语法&#xff0c;允许开发者声明式地将DOM绑定至底层Vue实例的数据。所有Vue的模板都是 合法的HTML&#xff0c;所以能被遵循规范的浏览器和HTML解析器解析。 在前面&#xff0c;我们一直使用的是字符串插…

Java面试八股之强软弱虚引用的概念及区别

Java中强软弱虚引用的概念及区别 在Java中&#xff0c;强引用、软引用、弱引用和虚引用是四种不同类型的引用&#xff0c;它们在对象生命周期管理、垃圾收集&#xff08;Garbage Collection, GC&#xff09;以及内存管理方面有着不同的行为和用途。以下是它们的概念和主要区别…

2.Neo4j的搭建启动

Graph Database 图数据库 版本对应关系 官网都是高版本&#xff0c;推荐使用下载地址可以找到社区老版本&#xff1a; https://we-yun.com/doc/neo4j/ neo4j.bat 启动脚本 cypher-shell.bat 执行CQL语句的。 import文件夹可以放入excel,csv等数据文件&#xff0c;导入到…

多模态大语言模型和 Apple 的 MM1

原文地址&#xff1a;multimodal-large-language-models-apples-mm1 2024 年 4 月 13 日 抽象是计算机科学中最关键的概念之一&#xff0c;具有一些最强大的影响。从简单的角度来看&#xff0c;抽象就是将某一事物应用于多种不同情况的能力。例如&#xff0c;如果你创造了一种…

本地大语言模型LLM的高效运行专家 | Ollama

Ollama简介 Ollama是一个开源的大型语言模型服务工具&#xff0c;它帮助用户快速在本地运行大模型。通过简单的安装指令&#xff0c;用户可以执行一条命令就在本地运行开源大型语言模型&#xff0c;如Llama 2。Ollama极大地简化了在Docker容器内部署和管理LLM的过程&#xff0…

JAVA面试专题-微服务篇

Spring cloud Spring Cloud 5大组件有哪些 注册中心/配置中心&#xff1a;nacos 负载均衡&#xff1a;Ribbon 服务远程调用&#xff1a;Feign 服务保护&#xff1a;sentinel 服务网关&#xff1a;Gateway 微服务注册和发现 nacos和eureka的区别 负载均衡 微服务向Ribbon发送…