Kubernetes Ingress暴露应用的工作流程

🕗 发布于 2024-01-29 23:37 kubernetes 容器云原生

文章目录

一、Igress是什么
二、安装Igress Controller
三、Service NodePort模式暴露Ingress Controller
四、创建ingress 进行访问
- 查看ingress controller生成的规则(两种类型通用)
五、HostNetwork模式暴露Ingress Controller
总结：

一、Igress是什么

一般负载均衡器分为：
四层（传输层）：基于ip和端口进行转发，例如lvs、nginx、haproxy
七层（应用层）：基于应用层协议进行转发的，例如http，可以根据域名、url等转发，例如nginx、haproxy

Service NodePort存在的不足：

一个端口只能由一个服务使用，端口需要提前规划
只支持4层负载均衡(ip:port)

ingress可以实现集群中全局的负载均衡（只需一个到两个端口来实现分别为 80，443）为集群提供一个统一的访问入口，也可以基于url、域名实现七层的负载均衡技术来进行给应用分流进而转发到不同的services上；

ingress：k8s中的一个抽象资源，给管理员提供一个暴露应用的入口定义方法
ingress Controller：根据Ingress生成具体的路由规则，并对pod进行负载均衡

Ps：Ingress Controller是基于域名进行分流的
在这里插入图片描述

二、安装Igress Controller

Ingress controller默认在k8s中是没有部署的；
Ingress controller有很多实现，我们这里采用官方维护的基于Nginx实现的控制器

项目地址：https://github.com/kubernetes/ingress-nginx
文档：https://kubernetes.github.io/ingress-nginx/deploy/
其他控制器（里面有k8s所支持的控制器的集合）：https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/

项目地址里会有各个ingress版本所支持的k8s版本及nginx的版本
在部署ingress的时候需要看下与自己k8s版本的兼容情况，以避免部署不起来
在这里插入图片描述
然后在项目地址里点击"Getting Started "或者直接点击上面的文档地址来进行选择部署ingress controller，这里我们选择自建k8s集群的方式来部署

1.下载ingress的yml文件

[root@k8s-master ~]# wget -c https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.0/deploy/static/provider/baremetal/deploy.yaml
#下载其它版本的话直接修改中间的版本号就行
[root@k8s-master1 ~]# mv deploy.yaml ingress-controller.yaml

2.修改ingress配置
（1）需要将镜像地址（registry.k8s.io）修改为国内的（lank8s.cn）否则会下不了镜像

[root@k8s-master ~]# grep -r "image:" deploy.yaml 
        image: registry.k8s.io/ingress-nginx/controller:v1.3.0@sha256:d1707ca76d3b044ab8a28277a2466a02100ee9f58a86af1535a3edf9323ea1b5
        image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660
        image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660
[root@k8s-master ~]# mv deploy.yaml ingress-controller.yaml
[root@k8s-master ~]# grep -r "image:" ingress-controller.yaml 
        image: registry.k8s.io/ingress-nginx/controller:v1.3.0@sha256:d1707ca76d3b044ab8a28277a2466a02100ee9f58a86af1535a3edf9323ea1b5
        image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660
        image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660
[root@k8s-master ~]# sed -i 's/registry.k8s.io/lank8s.cn/g' ingress-controller.yaml 
[root@k8s-master ~]# grep -r "image:" ingress-controller.yaml 
        image: lank8s.cn/ingress-nginx/controller:v1.3.0@sha256:d1707ca76d3b044ab8a28277a2466a02100ee9f58a86af1535a3edf9323ea1b5
        image: lank8s.cn/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660
        image: lank8s.cn/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660

修改完镜像地址后，需要选择下面一种暴露ingress controller方式来进行部署(正常情况下HostNetwork模式居多)；

三、Service NodePort模式暴露Ingress Controller

Service NodePort暴露Ingress Controller
ingress controller是以k8s pod的方式进行部署的，我们可以使用service nodeport的方式来随机生成或指定暴露端口来将请求转发到ingress controller上，ingress controller就会根据我们创建的ingress规则来转发至相应的pod上；

当我们下载好ingress的配置文件后，它默认使用的就是NodePort类型来暴露自己pod的80和443端口，也就是一个service暴露多个端口
在这里插入图片描述

ingress controller使用的是Depolyment进行部署的，默认的副本数为1
在这里插入图片描述

其实使用NodePort方式进行部署ingress是不需要对配置文件进行改动的，直接下载下来apply部署一下就可以

[root@k8s-master ~]# kubectl apply -f ingress-controller.yaml 
#默认会将ingress controller给我部署到"ingress-nginx"这个命名空间下
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
deployment.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@k8s-master ~]# kubectl get pod -n ingress-nginx 
NAME                                       READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-9qfbs       0/1     Completed   0          2d18h
ingress-nginx-admission-patch-w2252        0/1     Completed   2          2d18h
ingress-nginx-controller-dc9c4bf8f-9nl2t   1/1     Running     0          2d18h

当ingress启动之后，我们可以查看下它暴露的端口

[root@k8s-master ~]# kubectl get pod,svc  -n ingress-nginx 
NAME                                           READY   STATUS      RESTARTS   AGE
pod/ingress-nginx-admission-create-9qfbs       0/1     Completed   0          2d18h
pod/ingress-nginx-admission-patch-w2252        0/1     Completed   2          2d18h
pod/ingress-nginx-controller-dc9c4bf8f-9nl2t   1/1     Running     0          2d18h

NAME                                         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
service/ingress-nginx-controller             NodePort    10.96.212.26     <none>        80:32337/TCP,443:31950/TCP   2d18h
service/ingress-nginx-controller-admission   ClusterIP   10.110.231.235   <none>        443/TCP                      2d18h

可以看到ingress暴露的端口为32337和31950，分别对应着它容器内部的80和443端口；当请求到ingress-controller上时会把请求转发到相应的pod上

四、创建ingress 进行访问

官方创建ingress配置示例：https://kubernetes.io/docs/concepts/services-networking/ingress/
在这里插入图片描述

或者通过命令来进行创建示例
例：

[root@k8s-master ~]# kubectl create ingress --help 
Usage:
  kubectl create ingress NAME --rule=host/path=service:port[,tls[=secret]]
[options]
[root@k8s-master ~]# kubectl create ingress web1 --rule=host/path=web:80 --dry-run=client -o yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  creationTimestamp: null
  name: web1
spec:
  rules:
  - host: host
    http:
      paths:
      - backend:
          service:
            name: web
            port:
              number: 80
        path: /path
        pathType: Exact
status:
  loadBalancer: {}

1.这里使用官方示例来进行创建ingress

[root@k8s-master ~]# vim web-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
spec:
  #指定ingress控制器类型为nginx，不同的控制器表示不一样，可以查看官方文档进行查阅
  ingressClassName: nginx
  rules:
  #指定请求的域名
  - host: web.study.com
    http:
      paths:
      #指定请求的路径
      - path: /
        pathType: Prefix
        backend:
          #指定要暴露的应用(Pod)的service,所以使用ingress之前是一定要先创建service的,它是基于service来发现这一组要被请求的pod的
          service:
            name: web
            #指定要暴露的service的内部port端口
            port:
              number: 80
              
[root@k8s-master ~]# kubectl apply -f web-ingress.yaml 
ingress.networking.k8s.io/web created

2.使用apply来创建ingress并进行访问
创建ingress后，ingress controller会基于nginx来自动生成ingress转发规则

[root@k8s-master ~]# kubectl get ingress
NAME   CLASS   HOSTS                 ADDRESS   PORTS   AGE
web   nginx   web.study.com             80      13s

测试访问:
因为我们使用的是NodePort的方式部署的ingress controller，使用当我们要去访问ingress的时候，也需要使用Service NodeProt的方式去访问
ingress controller暴露的端口为80:32337/TCP,443:31950/TCP

又因为我们上面创建ingress 的时候绑定了域名，应该使用域名:nodeport(80:32337/TCP,443:31950/TCP)进行去访问
例如：
web.study.com:32337
在这里插入图片描述
注：如果这里配置的域名可以直接解析到（公网IP）的话，直接访问就行了，如果是个人学习环境解析不到的话，就需要在本地电脑绑定hosts记录对应着ingress里面配置的域名
例： < NodeIP > web.study.com

查看ingress controller生成的规则(两种类型通用)

因为这里使用的是nginx类型的ingress控制器（ingress-nginx），所以我们可以进入到这个ingress控制器里查看生成的nginx配置(ingress规则)

[root@k8s-master ~]# kubectl get pod -n ingress-nginx 
NAME                                       READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-9qfbs       0/1     Completed   0          3d17h
ingress-nginx-admission-patch-w2252        0/1     Completed   2          3d17h
ingress-nginx-controller-dc9c4bf8f-9nl2t   1/1     Running     0          3d17h

[root@k8s-master ~]# kubectl exec -it pod/ingress-nginx-controller-dc9c4bf8f-9nl2t -n ingress-nginx /bin/bash 
bash-5.1$ vi /etc/nginx/nginx.conf

可以看到如下ingress controller会帮我们自动生成一个nginx的虚拟主机server的配置，也就是在这里会基于这个域名来进行分流

        ## start server web.study.com                                        
        server {                                                             
                server_name web.study.com ;

                listen 80  ;
                ...
        ## end server web.study.com

五、HostNetwork模式暴露Ingress Controller

Service NodePort 模式暴露Ingress的痛点：
由于NodePort模式进行访问时需要域名加端口(web.study.com:32337)来进行访问，先是经过Service NodePort转发到ingress controller上，再由ingress controller转发到pod上；而且一个请求流的过程太过繁琐，使用共享宿主机网络模式整体流程会更加清晰

共享宿主机网络（hostNetwork:True）
指定ingress controller这个pod保持跟宿主机的网络保持一致，用同一个网络命名空间，这样我们访问node节点就是相当于请求到了ingress controller里，再根据我们设置的ingress规则，来转发至相应的pod上；

1.共享宿主机模式部署ingress controller

apiVersion: apps/v1
kind: Deployment
...
    spec:      
      #共享宿主机的网络协议栈(不给ingress controller分配独立的网路命名空间，与宿主机网络命名空间共享)
      hostNetwork: True
      #将Pod调度到指定的Node上，不经过调度器
      #nodeName: k8s-master
      #根据标签控制pod在哪个node节点上，受scheduler调度器控制（例如有污点便不能调度）
      #例如将pod调度到含有[test-label-ingress-controller: "true"]标签的节点上
      #nodeSelector: 
      #  test-label-ingress-controller: "true" 
      containers:
      - args:
        - /nginx-ingress-controller
        ...

在这里插入图片描述

修改完后apply重新应用ingress controller控制器

[root@k8s-master ~]# kubectl apply -f ingress-controller.yaml 
[root@k8s-master ~]# kubectl get pod -n ingress-nginx -o wide 
NAME                                        READY   STATUS      RESTARTS   AGE     IP               NODE         NOMINATED NODE   READINESS GATES
ingress-nginx-admission-create-9qfbs        0/1     Completed   0          7d17h   10.244.36.65     k8s-node1    <none>           <none>
ingress-nginx-admission-patch-w2252         0/1     Completed   2          7d17h   10.244.107.193   k8s-node3    <none>           <none>
ingress-nginx-controller-55b4c7fdcf-68stc   1/1     Running     0          7m24s   192.168.1.1      k8s-master   <none>           <none>
#此时已经不会再给ingress controller这个Pod分配IP了，而是直接使用了k8s-master这个宿主机的IP进行监听，也就是除了网络没有和宿主机进行隔离，其他都是隔离的;

可以看到ingress controller被分配到了master上（也可以根据调度指定节点），然后我们将hosts解析改成分配到的pod，再直接使用域名访问
在这里插入图片描述
注：如果这里配置的域名可以直接解析到（公网IP）的话，直接访问就行了，如果是个人学习环境解析不到的话，就需要在本地电脑绑定hosts记录对应着ingress里面配置的域名

需要注意的是，我们只能访问将域名解析改为ingress controller所在的节点上，因为在使用host方式的时候，ingress controller只会监听它所在的节点的端口，其他节点没有ingress controller，就不会监听

#查看k8s-master节点上ingress controller监听的80端口
[root@k8s-master ~]# ss -unptl | grep 80 
tcp    LISTEN     0      128       *:80                    *:*                   users:(("nginx",pid=41316,fd=10),("nginx",pid=41311,fd=10))
tcp    LISTEN     0      128    192.168.1.1:2380                  *:*                   users:(("etcd",pid=2912,fd=3))
tcp    LISTEN     0      128    [::]:80                 [::]:*                   users:(("nginx",pid=41316,fd=11),("nginx",pid=41311,fd=11))

#查看k8s-node1节点是否有监听
[root@k8s-node1 ~]# ss -unptl | grep 80

拓展：只要我们访问的节点上有ingress controller这个pod，就可以访问我们后端的pod，所以，我们可以指定ingress controller的副本以及根据相应的调度策略来实现多个指定的节点上跑ingress controller的pod来实现host方式的 ingress controller 高可用；

总结：

Service NodePort访问的ingress controller流程：

域名 web.study.com:32337 --> service nodeprot(80:32337/TCP,443:31950/TCP)(iptables/ipvs) --> ingress  controller(nginx 基于域名来进行分流) --> 分布在各个节点的pod

#当用户根据域名:端口请求时，先是Service NodePort(主要作用是将ingress controller暴露出去)会将请求转发至ingress controller，然后ingress controller 会基于域名来帮我们转发到后端service(在这里service提供的只是服务发现的机制，并不提供转发的路径)关联的pod上；
前者(Service NodePort)根据iptables/ipset来实现转发，后者(ingress controller)基于nginx来实现；

hostNetwork方式的ingress-nginx整体的工作流程是：

域名 web.study.com:80 --> 宿主机80端口 是ingress controller监听的 --> ingress controller(nginx 基于域名来进行分流) --> 分布在各个节点的pod

#当用户直接请求域名时，此时的请求也就是"域名:80"，只要域名解析正确(可以解析到ingress controller所在的宿主机)，这个请求就会直接到ingress controller上，然后ingress controller会基于域名来帮我们转发到后端service关联的pod上；

原文地址：https://blog.csdn.net/qq_44930876/article/details/134991339

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！

上一篇：安装Anaconda所遇到的一些问题
下一篇：Typora 最新版安装使用教程

【C++】list 类深度解析：探索双向链表的奇妙世界
本文深度解析了 C++ 标准库中的 list 类。首先阐述学习 list 类的原因，其具有高效插入删除操作优势，如双向链表结构使插入删除只需调指针，时间复杂度常数级；内存管理灵活，节点分散存储避免内存
阅读更多2024-11-16
常用List工具类（取交集、并集等等）
【代码】常用List工具类（取交集、并集等等）
阅读更多2024-11-16
宝塔面板从 Nginx 切换到 Caddy：详细教程
宝塔面板从 Nginx 切换到 Caddy
阅读更多2024-11-16
计算机网络中的数据包传输机制详解
数据包是网络通信的基本单位，它包含了控制信息（如源地址、目的地址等）和用户数据（即有效载荷）。根据不同的网络协议，数据包的结构会有所不同。数据包的传输机制是计算机网络的核心内容之一，它涉及到数据的封装
阅读更多2024-11-16
LinkedList 源码分析
仅仅在头尾插入或者删除元素的时候时间复杂度近似 O(1)，其他情况增删元素的平均时间复杂度都是 O(n)。底层数据结构是链表，内存地址不连续，只能通过指针来定位，不支持随机快速访问，所以不能实现。是一
阅读更多2024-11-16
【泛型 Plus】Kotlin 的加强版类型推断：@BuilderInference
视频先行下面是视频内容的脚本文案原稿分享。小剧场面试官：「既然协程和泛型你都熟悉，flow() 函数是怎么实现类型推断的有了解过吗？」求职者：「嗯……」求职者：「嗯……在Kotlin协程中，flow
阅读更多2024-11-16
20.UE5UI预构造，开始菜单
如果我们直接再画布上设计我们的按钮，我们需要为每一个按钮进行编辑，复用性太差，能不能在其他的UI蓝图中编辑好，随后就好像其他元素（文本，button）一样，直接放入到我们的画布中？为了在复用时，可以自
阅读更多2024-11-16
支持向量机SVM——基于分类问题的监督学习算法
支持向量机SVM是一种常用于分类问题的监督学习算法。文章主要从基础公式角度讲解它的基本原理，涉及线性和非线性情况。
阅读更多2024-11-16
鸿蒙生态下的安全隐私保护：打造用户信任的应用体验
作为开发者，在享受鸿蒙生态系统带来的广阔市场机遇的同时，也面临着保障用户数据安全和隐私保护的重要责任。同时，开发者需要向用户提供清晰的信息收集和使用的说明，让用户了解自己的数据如何被使用。总的来说，在
阅读更多2024-11-16
基本数据类型：Kotlin、Dart (Flutter)、Java 和 C++ 的比较
本文比较了 Kotlin、Dart (Flutter)、Java 和 C++ 中的基本数据类型，并探讨了有符号和无符号整数的区别。文章还详细解释了二进制补码的计算方式和其在计算机系统中的应用。理解这些
阅读更多2024-11-16