k8s ingress (二)

k8s ingress ()

Ingress介绍

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

NodePort方式的缺点是会占用很多集群机器的端口,那么当集群服务变多的时候,这个缺点就愈发明显

LB方式的缺点是每个service需要一个LB,浪费、麻烦,并且需要kubernetes之外的设备的支持。

基于这种现状,kubernetes提供了Ingress资源对象,Ingress只需要一个NodePort或者一个LB就可以满足暴露多个Service的需求。工作机制大致如下图表示:

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

ingress:kubernetes中的一个对象,作用就定义请求如何转发到service的规则

ingress controller:具体实现发向代理及负载均衡的程序,对ingress定义的规则进行解析,根据配置的规则来实现请求转发,实现方式有很多,比如Nginx、Contour、Haproxy等等。

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

用户编写Ingress规则,说明哪个域名对应kubernetes集群中欧冠的哪个Service

Ingress控制器动态感知Ingress服务规则的变化,然后生成一段对应的Nginx配置

Ingress控制器会将生成的Nginx配置写入到一个运行着Nginx服务中,并动态更新

到此为止,其实真正在工作的就是Nginx了,内部配置了用户定义的请求转发规则

Ingress 环境准备

在ELB下的监听器中,可以通过监听器协议和端口来判断是4层还是7层的。

如果监听器协议是TCP或UDP,那么该监听器是4层的。这种监听器只能根据目标端口将流量转发到后端实例,不能对流量进行任何处理。

如果监听器协议是HTTP或HTTPS,那么该监听器是7层的。这种监听器可以根据请求的URL、HTTP头部等信息对流量进行处理,并将流量转发到后端实例。

此外,还可以通过监听器端口来判断是4层还是7层的。如果监听器端口是80或443,那么该监听器是7层的;如果监听器端口是其他端口,那么该监听器是4层的

Ingress 的使用

Ingress 环境准备

# 创建文件夹

[root@master ~]# mkdir ingress-controller

[root@master ~]# cd ingress-controller/

# 获取ingress-nginx,本次案例使用的是0.30版本

[root#master ingress-controller]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml

[root#master ingress-controller]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml

# 修改mandatory.yaml文件中的仓库(本人实验不需要修改也可以)

# 修改quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0

# 为quay-mirror.qiniu.com/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0

# 创建ingress-nginx

[root@master ingress-controller]# kubectl apply -f ./

# 查看ingress-nginx

[root@master ingress-controller]# kubectl get pod -n ingress-nginx

NAME                                                                           READY    STATUS         RESTARTS             AGE

pod/nginx-ingress-controller-fbf967dd5-4qpbp    1/1         Running        0                            12h

# 查看service

[root@master ingress-controller]# kubectl get svc -n ingress-nginx

NAME                   TYPE             CLUSTER-IP          EXTERNAL-IP PORT(S)                                     AGE

ingress-nginx NodePort      10.98.75.163  <none>         80:32240/TCP,443:31335/TCP    11h

准备servicepod

为了后面的实验比较方便,创建如下图所示的模型

创建tomcat-nginx.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: nginx-deployment 

  namespace: dev

spec:

  replicas: 3 

  selector:   

    matchLabels:

      app: nginx-pod 

  template:

    metadata:  

      labels:    

        app: nginx-pod

    spec:  

      containers:     

      - name: nginx       

        image: nginx:1.17.1       

        ports:       

        - containerPort: 80

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: tomat-deployment 

  namespace: dev

spec: 

  replicas: 3 

  selector:   

    matchLabels:     

      app: tomcat-pod 

  template:   

    metadata:     

      labels:       

        app: tomcat-pod   

    spec:     

      containers:     

      - name: tomcat       

        image: tomcat:8.5-jre10-slim       

        ports:       

        - containerPort: 8080

---

apiVersion: v1

kind: Service

metadata: 

  name: nginx-service 

  namespace: dev

spec: 

  selector:   

    app: nginx-pod 

  clusterIP: None 

  type: ClusterIP 

  ports: 

  - port: 80   

    targetPort: 80

---

apiVersion: v1

kind: Service

metadata: 

  name: tomcat-service 

  namespace: dev

spec: 

  selector:

    app: tomcat-pod 

  clusterIP: None 

  type: ClusterIP 

  ports: 

  - port: 8080   

targetPort: 8080

# 创建[root@master ~]# kubectl create -f tomcat-nginx.yaml

# 查看

[root@master ~]# kubectl get svc -n dev

NAME                          TYPE                    CLUSTER-IP                 EXTERNAL-IP        PORT(S)         AGE

nginx-service       ClusterIP        None                           <none>                80/TCP          48s

tomcat-service            ClusterIP        None                           <none>                8080/TCP      48s

Http代理

创建ingress-http.yaml

apiVersion: extensions/v1beta1

kind: Ingress

metadata: 

  name: ingress-http 

  namespace: dev

spec: 

  rules: 

  - host: nginx.itheima.com   

    http:     

      paths:     

      - path: /       

        backend:         

          serviceName: nginx-service         

          servicePort: 80 

  - host: tomcat.itheima.com   

    http:     

    paths:     

    - path: /       

      backend:         

      serviceName: tomcat-service         

      servicePort: 8080

# 创建

[root@master ~]# kubectl create -f ingress-http.yaml

ingress.extensions/ingress-http created

# 查看

[root@master ~]# kubectl get ing ingress-http -n dev

NAME                   HOSTS                                                    ADDRESS                     PORTS           AGE

ingress-http  nginx.itheima.com,tomcat.itheima.com                          80                 22s

# 查看详情

[root@master ~]# kubectl describe ing ingress-http -n dev

...

Rules:

Host                     Path backends

----                            ----       --------

nginx.itheima.com /             nginx-service:80(10.244.1.96:80,10.244.1.97:80,10.244.2.112.80)

tomcat.itheima.com     /             tomcat-service:8080(10.244.1.94:8080,10.244.1.95:8080,10.244.2.111.8080)

# 接下来,在本地电脑配置host文件,解析上面的两个域名到192.168.109.100(master)上

# 然后,就可以分别访问tomcat.itheima.com:32240 和nginx.itheima.com:32240 查看效果了

Https代理

创建证书

# 生成证书

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/C=CN/ST=BJ/L=BJ/0=nginx/CN=itheima.com"

# 创建密钥

kubectl create secret tls tls-secret --key tls.key --cert tls.crt

创建ingress-https.yaml 文件

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: ingress-https

  namespace: dev

spec:

  tls:

    - hosts:

      - nginx.itheima.com

      - tomcat.itheima.com

      secretName: tls-secret # 指定秘钥

  rules:

  - host: nginx.itheima.com

    http:

      paths:

      - path: /

        backend:

          serviceName: nginx-service

          servicePort: 80

  - host: tomcat.itheima.com

    http:

      paths:

      - path: /

        backend:

          serviceName: tomcat-service

          servicePort: 8080

# 创建 inress

[root@master ~]# kubectl create -f ingress-https.yaml

ingress.extensions/ingress-https created

# 查看

[root@master ~]# kubectl get ing ingress-https -n dev

NAME                   HOSTS                                                           ADDRESS                     PORTS    AGE

ingress-https nginx.itheima.com,tomcat.itheima.com     10.104.184.38 80, 443       2m42s

# 查看详情

[root@master ~]# kubectl describe ing ingress-https -n dev

...

TLS:

  tls-secret terminates nginx.itheima.com,tomcat.itheima.com

Rules:

Host                     Path backends

----                            ----       --------

nginx.itheima.com /             nginx-service:80(10.244.1.97:80,10.244.1.98:80,10.244.2.119.80)

tomcat.itheima.com     /             tomcat-service:8080(10.244.1.99:8080,10.244.2.117:8080,10.244.2.120.8080)

# 下面可以通过浏览器访问https://nginx.itheima.com:31335 和 https://tomcat.itheima.com:31335来查看了

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

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

相关文章

Postman —— postman实现参数化

什么时候会用到参数化 比如&#xff1a;一个模块要用多组不同数据进行测试 验证业务的正确性 Login模块&#xff1a;正确的用户名&#xff0c;密码 成功&#xff1b;错误的用户名&#xff0c;正确的密码 失败 postman实现参数化 在实际的接口测试中&#xff0c;部分参数每…

Redis通信协议

文章目录 Redis通信协议RESP协议数据类型 模拟Redis客户端 Redis通信协议 RESP协议 Redis是一个CS架构的软件&#xff0c;通信一般分为两步(不包含pipeline和PubSub)&#xff1a; 客户端(client)向服务端(server)发送一条命令。服务器解析并执行命令&#xff0c;返回响应结果…

【DETR】3、Conditional DETR | 拆分 content 和 spatial 来实现对 DETR 的加速

文章目录 一、Conditional DETR 是怎么被提出来的二、Conditional DETR 的具体实现2.1 框架结构2.2 DETR 的 cross-attention 和 Conditional DETR 的 cross-attention 对比 三、效果 论文&#xff1a;Conditional DETR for Fast Training Convergence 代码&#xff1a;https:…

c++ qt--事件过滤(第七部分)

c qt–事件过滤&#xff08;第七部分&#xff09; 一.为什么要用事件过滤 上一篇博客中我们用到了事件来进行一些更加细致的操作&#xff0c;如监控鼠标的按下与抬起&#xff0c;但是我们发现如果有很多的组件那每个组件都要创建一个类&#xff0c;这样就显得很麻烦&#xff…

springboot源码编译问题

问题一 Could not find artifact org.springframework.boot:spring-boot-starter-parent:pom:2.2.5.RELEASE in nexus-aliyun (http://maven.aliyun.com/nexus/content/groups/public/) 意思是无法在阿里云的镜像仓库中找到资源 解决&#xff1a;将配置的镜像删除即可&#…

我的128天创作纪念日-东离与糖宝

文章目录 机缘收获日常成就憧憬 不知不觉我也迎来了自己的128天创作纪念日&#xff0c;一起来看看我有什么想对大家说的吧 机缘 我的写博客之旅始于参加了代码随想录算法训练营。在训练营期间&#xff0c;代码随想录作者卡尔建议我们坚持每天写博客记录刷题学习的进度和心得体…

Vue3.0 新特性以及使用变更总结

Vue3.0 在2020年9月正式发布了&#xff0c;也有许多小伙伴都热情的拥抱Vue3.0。去年年底我们新项目使用Vue3.0来开发&#xff0c;这篇文章就是在使用后的一个总结&#xff0c; 包含Vue3新特性的使用以及一些用法上的变更。 图片.png 为什么要升级Vue3 使用Vue2.x的小伙伴都熟悉…

【Qt学习】02:信号和槽机制

信号和槽机制 OVERVIEW 信号和槽机制一、系统自带信号与槽二、自定义信号与槽1.基本使用student.cppteacher.cppwidget.cppmain.cpp 2.信号与槽重载student.cppteacher.cppwidget.cppmain.cpp 3.信号连接信号4.Lambda表达式5.信号与槽总结 信号槽机制是 Qt 框架引以为豪的机制之…

记录一个诡异的bug

将对接oa跳转到会议转写的项目oa/meetingtranslate项目发布到天宫&#xff0c;结果跳转到successPage后报错 这一看就是successPage接口名没对上啊&#xff0c;查了一下代码&#xff0c;没问题啊。 小心起见&#xff0c;我就把successPage的方法请求方式从Post改为Get和POST都…

司徒理财:8.21黄金空头呈阶梯下移!今日操作策略

黄金走势分析 盘面裸k分析&#xff1a;1小时周期的行情局部于1896附近即下行通道上轨附近录得一系列的K线呈震荡下行并筑圆顶&#xff0c;上轨压制有效&#xff0c;下行通道并未突破&#xff0c;后市建议延续看下行。4小时周期局部录得一系列的纺锤线呈震荡&#xff0c;但行情整…

元矿山下的音视频应用

// 近年来&#xff0c;矿业的技术和管理模式随着元宇宙的火爆和自动驾驶技术的发展逐渐变化、升级&#xff0c;进而衍生出元矿山的概念&#xff0c;音视频技术也在其中成为了关键一环。LiveVideoStackCon 2023 上海站邀请了来自希迪智驾的任思亮&#xff0c;为大家分享希迪智…

STM32 BOOT 启动配置 ISP升级 介绍

启动配置 在STM32F10xxx里&#xff0c;可以通过BOOT[1:0]引脚选择三种不同启动模式。 启动模式选择引脚启动模式说明BOOT1BOOT0X0主闪存存储器主闪存存储器被选为启动区域01系统存储器系统存储器被选为启动区域11内置SRAM内置SRAM被选为启动区域 在系统复位后&#xff0c; S…