Kubernetes（五）：Ingress

已于 2025-10-27 09:16:03 修改
阅读量561 收藏 25
点赞数 16
CC 4.0 BY-SA版权
分类专栏： K8s_Kubernetes 文章标签： kubernetes 容器 云原生 k8s
于 2025-09-17 18:17:20 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zyplanke/article/details/151795838

目录

一、介绍

二、安装Ingress控制器Controller

  2.1 下载清单文件

  2.2 外部负载均衡器

  2.3 部署Ingress NGINX Controller

三、完整示例

  3.1 准备后端应用

  3.2 定义Ingress规则（单Host多Path）

  3.3 定义Ingress规则（多Host）

  3.4 探究访问路径

  3.5 探究Ingress规则如何生效

一、介绍

   在Kubernetes中Service是工作在第四层（既网络模型中的第四层，既TCP/UDP层）。而HTTP和HTTPS是在网络模型中第七层，Ingress就是工作在第七层的路由机制。

Open Systems Interconnection Model (OSI  Model)：
  • 第四层L4 refer to layer 4 (Transport Layer; TCP, UDP)
  • 第七层L7 refer to layer 7 (Application Layer; HTTP) 

  在Kubernetes中已经有了Service，为什么还需要Ingress呢？

  • 由于Ingress工作在第七层，所以不再局限于在IP和端口层面控制。而是可以基于HTTP/HTTPS进行分发。比如根据URL中包含特定的字符进行分发，比如根据HTTP请求头的内容进行分发，比如基于Cookie的回话亲和性等规则。
  • 为多个不同Service提供统一代理和分发。例如：对于type=LoadBalancer类型的Service，在云厂商托管情况会自动创建云负载均衡器。所以每个Service都会有一个负载均衡器，这种做法既浪费资源，也难以管理，更合理的做法是Kubernetes提供相对统一的负载均衡器。因此这种统一的、为不同Service提供代理和分发就是Ingress。例如对外由Ingress统一暴露某个域名http://www.zyp.com，其中访问http://www.zyp.com/coffee域名分发至后端的Coffee服务，访问http://www.zyp.com/tea域名分发至后端的Tea服务。

  所以Ingress本身就是Service及Pod等各类资源，可以说Ingress是“Service”的“Service”。

  Ingress示意图如下：：

在Ingress中分为：

二、安装Ingress控制器Controller

  下面选择比较常用的Ingress NGINX Controller进行演示。安装部署Ingress NGINX Controller可以有多种方式，下面通过yaml清单文件方式部署。

官网网站：https://kubernetes.github.io/ingress-nginx/     

Github地址：https://github.com/kubernetes/ingress-nginx   有与Kubernetes版本对应关系表。

  2.1 下载清单文件

安装部署Ingress NGINX Controller可以有多种方式，比如Helm方式，比如yaml清单文件方式。下面通过yaml清单文件方式部署。该清单文件创建如下类型的资源：

  • 1个Namespace，名为“ingress-nginx”的。 （以下资源在该Namespace下创建）
  • 2个ServiceAccount，名为“ingress-nginx”、“ingress-nginx-admission”
  • 2个Role，名为“ingress-nginx”、“ingress-nginx-admission”
  • 2个ClusterRole，名为“ingress-nginx”、“ingress-nginx-admission”
  • 2个RoleBinding
  • 2个ClusterRoleBinding
  • 1个ConfigMap，名为“ingress-nginx-controller”
  • 2个Service，type=LoadBalancer名为“ingress-nginx-controller”、type=ClusterIP名为“ingress-nginx-controller-admission”。 type=LoadBalancer的Service用途是把“Ingress NGINX Controller”作为统一入口对外暴露（端口80与443），由其接收流量后，再根据分发规则Rules分发至后端各Service。
  • 1个Deployment，使用镜像“registry.k8s.io/ingress-nginx/controller”
  • 2个Job，名为“ingress-nginx-admission-create”、“ingress-nginx-admission-patch”
  • 1个IngressClass，名为“nginx”，并且controller指定关联到具体实现的Deployment中Pod。
  • 1个ValidatingWebhookConfiguration

在Kubernetes的Control控制平面上：

# 下载yaml清单文件并重命名
curl -o ingress-nginx-controller.yaml https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.13.3/deploy/static/provider/cloud/deploy.yaml

# 查看该yaml文件中有哪些资源类型
grep "^kind" ingress-nginx-controller.yaml

#若国内无法直接访问registry.k8s.io，则替换为国内源
sed -i 's#registry.k8s.io#k8s.nju.edu.cn#' ingress-nginx-controller.yaml

  2.2 外部负载均衡器

在该yaml清单文件中，type=LoadBalancer名为“ingress-nginx-controller”的Service用途是作为统一入口对外暴露，由其接收流量。如果是云厂商托管的Kubernetes（如Amazon的EKS、阿里云的ACK）会自动检测到type=LoadBalancer的Service，并通过云控制器管理器调用云厂商的 API（如 AWS EC2 API、阿里云 SLB API）自动创建一个云负载均衡器，并将云负载均衡器IP自动注入到“ingress-nginx-controller”的Service中。

但本文演示环境不属于云上托管，是本地自行搭建的私有环境，因此没有云会自动创建负载均衡器，也不能将IP自动注入Service。此处为了简易起见，通过手工配置一个IP来模拟外部负载均衡器。模块方式具体为：

  1. 在Kubernetes集群找其中任意一台节点机器，对该节点增加配置一个IP地址作为外部负载均衡器IP。要求该IP地址能被集群外部直接访问。在本文中增加配置IP为192.168.43.50
  2. 在yaml清单文件里，“ingress-nginx-controller”的Service配置下手工增加externelIPs，模拟云厂商托管场景下自动注入外部负载均衡器IP。

注：type=LoadBalancer的Service相关知识可参见：https://blog.csdn.net/zyplanke/article/details/151224929

针对模拟方式第1步，在一台Kubernetes节点机器上，以root用户执行以下命令增加IP：

#在已有的网卡设备(以下为ens33为例)上增加配置一个IP，并设定别名为“ens33:2”
#以下命令仅当前临时有效。若希望Linux重启后仍有效，则还应配置在网卡配置文件中
sudo ip addr add 192.168.43.50 dev ens33 label ens33:2

#以上命令执行成功后，则可以ping通该IP。可对该IP再进一步配置域名（本文略）

针对模拟方式第2步，在yaml清单文件中对“ingress-nginx-controller”的Service配置下，新增externalIPs、调整externalTrafficPolicy配置：

  2.3 部署Ingress NGINX Controller

    Kubernetes的Control控制平面上：

    # 根据修改后的清单文件部署
kubectl apply -f ingress-nginx-controller.yaml

# 查看该命名空间下的资源
kubectl get all -n ingress-nginx

    根据该namespace查看已创建的资源如下（注意输出展示Service的EXTERNAL-IP、PORT）：

    查看Pod并访问该Pod，可以看到Nginx的应答。由于此时还为配置Ingress的分发规则，因此HTTP返回的是Nginx自身，而不是后端服务（更准确说Pod中容器）返回的应答。

      自此，Ingress Controller已安装部署完毕，但还没有配置分发规则。下一步以示例来展示。

    三、完整示例

      3.1 准备后端应用

     分别准备两个后端应用如下：

    • coffee服务：1个的Service（端口11110）、两个Pod副本（端口1111）
    • tea服务：1个的Service（端口22220）、两个Pod副本（端口2222）

      为便于演示，Pod中容器使用alpine镜像并通过nc命令启动简易HTTP服务端。

      1、创建coffee服务。准备demo-coffee.yaml文件如下：

    apiVersion: v1
kind: Service
metadata:
  name: svc-coffee
spec:
  selector:                # 标签选择器，选择满足条件的后端Pod
    app: http-coffee
  type: ClusterIP
  ports:
  - port: 11110              # Service在clusterIP上的监听端口
    targetPort: 1111         # 转发至后端Pod上的端口，若未指定则等于port
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: p-alpine-coffee
spec:
  replicas: 2                   # 期望的副本数，默认为1
  selector:                     # 标签选择器。若多个matchLabels则为AND关系；还可以用matchExpressions来表达复杂选择关系
    matchLabels:
       app: http-coffee         # 需与.spec.template.metadata.labels一致
  template:                     # Pod模版定义
    metadata:
      labels:
        app: http-coffee
    spec:
      containers:
      - name: c-alpine          #容器名（需符合RFC 1123，不能有下划线）
        image: alpine           #镜像名
        command:                #容器启动时执行命令，通过nc命令启动简易HTTP服务端
        - sh
        - -c
        - |
            while : ;
            do
               (echo "HTTP/1.1 200 OK";
                echo "";
                echo "Demo HTTP Server by nc! "
                echo "HTTP serverHostname=`hostname`  serverIP=`hostname -i`  serverTime=`date`";
               ) | nc -v -l -p 1111;
            done
        ports:
        - containerPort: 1111   #展示性申明容器对外暴露的端口，可多个

      2、创建后，可以看到直接通过其Service访问，其应答分别是由不同的Pod（容器）返回的：

     3、创建tea服务。准备demo-tea.yaml文件如下：

    apiVersion: v1
kind: Service
metadata:
  name: svc-tea
spec:
  selector:                # 标签选择器，选择满足条件的后端Pod
    app: http-tea
  type: ClusterIP
  ports:
  - port: 22220              # Service在clusterIP上的监听端口
    targetPort: 2222         # 转发至后端Pod上的端口，若未指定则等于port
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: p-alpine-tea
spec:
  replicas: 2                   # 期望的副本数，默认为1
  selector:                     # 标签选择器。若多个matchLabels则为AND关系；还可以用matchExpressions来表达复杂选择关系
    matchLabels:
       app: http-tea            # 需与.spec.template.metadata.labels一致
  template:                     # Pod模版定义
    metadata:
      labels:
        app: http-tea
    spec:
      containers:
      - name: c-alpine          #容器名（需符合RFC 1123，不能有下划线）
        image: alpine           #镜像名
        command:                #容器启动时执行命令，通过nc命令启动简易HTTP服务端
        - sh
        - -c
        - |
            while : ;
            do
               (echo "HTTP/1.1 200 OK";
                echo "";
                echo "Demo HTTP Server by nc! "
                echo "HTTP serverHostname=`hostname`  serverIP=`hostname -i`  serverTime=`date`";
               ) | nc -v -l -p 2222;
            done
        ports:
        - containerPort: 2222   #展示性申明容器对外暴露的端口，可多个

      4、创建后，可以看到直接通过其Service访问，应答分别是由不同的Pod（容器）返回的：

      3.2 定义Ingress规则（单Host多Path）

          这里对外提供一个域名，每个域名后分别两个子Path分别对应后端coffee与tea两个应用服务。对此将Ingress Resource（既规则）写成yaml清单文件one-host-ingress.yaml，内容如下：

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: one-host-ingress
spec:
  ingressClassName: nginx         #指定本规则由哪种Ingress Controller实现
  rules:
  - host: "*.zyp.com"             #与HTTP请求头中Host对应（可带通配符）。不能为IP格式
    http:
      paths:
      - path: /coffee             #HTTP请求中URL，必须以“/” 开头
        pathType: Prefix          #path匹配类型：Exact完全精准匹配；按“/”拆分URL路径前缀匹配
        backend:
          service:                #后端服务需与本Ingress同属一个namespace
            name: svc-coffee      #流量分发至后端服务名
            port:                 #流量分发至后端服务中哪个端口（可以为name端口名 或 number数字端口号）
              number: 11110
      - path: /tea                #HTTP请求中URL，必须以“/” 开头
        pathType: Prefix          #path匹配类型：Exact完全精准匹配；按“/”拆分URL路径前缀匹配
        backend:
          service:                #后端服务需与本Ingress同属一个namespace
            name: svc-tea         #流量分发至后端服务名
            port:                 #流量分发至后端服务中哪个端口（可以为name端口名 或 number数字端口号）
              number: 22220

    Kubernetes的Control控制平面上：

    # 部署Ingress清单文件部署
kubectl apply -f one-host-ingress.yaml

# 查看Ingress资源（注意输出展示的Address刚开始可能无值，需等几十秒后才自动有值）
kubectl describe ingress/one-host-ingress

    注意输出展示的Rules中，Ingress通过服务已直接获得后端Pod的IP与端口，因此通过Ingress分发时可直接一步到位分发至Pod。

    然后再Kubernetes集群之外，找台机器通过访问外部负载均衡器：

    # 设置HTTP请求头
curl -H "Host: www.zyp.com" http://192.168.43.50/coffee
curl -H "Host: www.zyp.com" http://192.168.43.50/tea

    注1：Ingress规则中Host是与HTTP请求头中Host匹配，不是与URL。

    注2：curl或者浏览器默认会根据请求URL中内容自动设置Host请求头。但由于本环境中没有对外部负载均衡器配置DNS域名，因此在URL中只能写IP，对此需要手工设置HTTP请求头以便通过Host与Ingress规则匹配。

    至此，通过同个Host不同子Path均成功访问。

      3.3 定义Ingress规则（多Host）

       有时需要在同一入口（比如一个入口公网IP）上同时对外提供多个域名（既Host）。虽然是同一入口，但通过不同的域名访问，返回的内容是不同的。 

         对此，在Ingress中配置多个Host，并将不同Host分发到不同的后端服务上。写成yaml清单文件multi-host-ingress.yaml，内容如下：

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-host-ingress
spec:
  ingressClassName: nginx         #指定本规则由哪种Ingress Controller实现
  rules:
  - host: "*.coffee.ltd"          #与HTTP请求头中Host对应（可带通配符）。不能为IP格式
    http:
      paths:
      - path: /coffee             #HTTP请求中URL，必须以“/” 开头
        pathType: Prefix          #path匹配类型：Exact完全精准匹配；按“/”拆分URL路径前缀匹配
        backend:
          service:                #后端服务需与本Ingress同属一个namespace
            name: svc-coffee      #流量分发至后端服务名
            port:                 #流量分发至后端服务中哪个端口（可以为name端口名 或 number数字端口号）
              number: 11110
  - host: "*.tea.ltd"             #与HTTP请求头中Host对应（可带通配符）。不能为IP格式
    http:
      paths:
      - path: /tea                #HTTP请求中URL，必须以“/” 开头
        pathType: Prefix          #path匹配类型：Exact完全精准匹配；按“/”拆分URL路径前缀匹配
        backend:
          service:                #后端服务需与本Ingress同属一个namespace
            name: svc-tea         #流量分发至后端服务名
            port:                 #流量分发至后端服务中哪个端口（可以为name端口名 或 number数字端口号）
              number: 22220

    Kubernetes的Control控制平面上：

    # 部署Ingress清单文件部署
kubectl apply -f multi-host-ingress.yaml

# 查看Ingress资源（注意输出展示的Address刚开始可能无值，需等几十秒后才自动有值）
kubectl describe ingress/multi-host-ingress

    注意输出展示的Rules中，Ingress通过服务已直接获得后端Pod的IP与端口，因此通过Ingress分发时可直接一步到位分发至Pod。

    然后再Kubernetes集群之外，找台机器通过访问外部负载均衡器：

    # 设置HTTP请求头
curl -H "Host: a.coffee.ltd" http://192.168.43.50/coffee
curl -H "Host: b.tea.ltd" http://192.168.43.50/tea

    注1：Ingress规则中Host是与HTTP请求头中Host匹配，不是与URL。

    注2：curl或者浏览器默认会根据请求URL中内容自动设置Host请求头。但由于本环境中没有对外部负载均衡器配置DNS域名，因此在URL中只能写IP，对此需要手工设置HTTP请求头以便通过Host与Ingress规则匹配。

    至此，通过不同Host均成功访问。

      3.4 探究访问路径

        客户端通过Ingress访问后端应用的路径理论上为：

    客户端(curl等)→外部负载均衡器→Ingress(对应Controller实现)→Service→Pod中容器应用

        但实际访问路径为：

    客户端(curl等)→外部负载均衡器→Ingress(对应Controller实现)→Pod中容器应用

    注意1：不同的外部负载均衡器实现方式可能不同，在本例中从“外部负载均衡器”至“Ingress(对应Controller实现)”通过NAT转发完成（通过IPVS或者iptables转发），所以无法看到外部负载均衡器IP上监听LISTEN端口。

    注意2：上文实际访问路径中，在Pod前没有Service。因为Ingress通过服务已直接获得后端Pod的IP与端口，因此在Ingress(对应Controller实现)分发时可一步到位直接分发至Pod。

      3.5 探究Ingress规则如何生效

        Ingress Resource只是规则定义，最终如何生效还是靠Ingress Controller的具体实现，不同的Controller类型有不同的具体实现方式。对于本文选择的“Ingress NGINX Controller”这款，它是对Ingress定义规则是如何具体实现的呢？

        在以上Ingress规则定义后，可以进入到NGINX Controller容器内

    #先进入容器内
kubectl exec -it pod/ingress-nginx-controller-dcfb8c47-l8msj -n ingress-nginx -- /bin/bash

#再进入容器内部后，查看最新的nginx.conf
vi /etc/nginx/nginx.conf

    可以看到根据Ingress中定义的规则，已自动写入到nginx.conf文件中。这就是“Ingress NGINX Controller”这款对Ingress定义规则的具体实现方式。

    Kubernetes 基础：Ingress的高可用部署
    在技术的广袤天地里，本博客如精准罗盘。剖析前沿科技，深掘代码奥秘，以精炼笔触，带您穿越复杂技术迷宫，速达知识彼岸。
    09-10 1214
    我们很少**直接使用**这些方式来对外暴露服务，因为它们都有一个比较严重的问题，那就是需要占用节点端口。 `Ingress` 就是为了解决这些问题而设计的，它允许你将 Service 映射到集群对外提供的某个端点上（由域名和端口组成的地址）， 这样我们就可以在 Ingress 中将多个 Service 配置到同一个域名的不同路径下对外提供服务，避免了对节点端口的过多占用。 `Ingress` 还支持路由规则和域名配置等高级功能，就像 Nginx 那样能够承担业务系统最边缘的反向代理+网关的角色。
    Kubernetes核心组件Ingress详解
    weixin_72583321的博客
    05-27 1984
    在Kubernetes集群中，Ingress作为集群内服务对外暴露的访问接入点，几乎承载着集群内服务访问的所有流量。Ingress是Kubernetes中的一个资源对象，用来管理集群外部访问集群内部服务的方式。您可以通过Ingress资源来配置不同的转发规则，从而实现根据不同的规则设置访问集群内不同的Service所对应的后端Pod。 Ingress资源仅支持配置HTTP流量的规则，无法配置一些高级特性，例如负载均衡的算法、Sessions Affinity等，这些高级特性都需要在Ingress Cont
    Kubernetes(22):Ingress详解
    不积跬步，无以至千里
    10-18 1618
    NodePort方式的缺点是占用很多集群机器的端口，那么当集群服务变多的时候，这个缺点就会愈发明显LB方式的缺点是每个service需要一个LB，浪费、麻烦，并且需要kubernetes之外设备的支持。基于这种现状，kubernetes提供了Ingress资源对象，Ingress只需要一个NodePort或者一个LB就可以满足暴露多个service的需求。
    Kubernetes生产实战(三十六)：Ingress 实战指南
    sre救赎之路
    05-22 794
    Ingress 是 Kubernetes 中管理外部访问集群内服务的 API 对象，通过配置规则将 HTTP/HTTPS 流量路由到不同的 Service。以下是完整的实战指南，涵盖部署、配置、TLS 和高级特性： Ingress Controller：具体实现流量转发的组件（如 Nginx、Traefik），监听 API Server 并根据 Ingress 规则动态配置负载均衡器。 2. 工作流程 Ingress Controller 通过 Watcher 机制监听 Ingres
    Kubernetes - 实战：Ingress
    qq_33240556的博客
    04-19 701
    在 Kubernetes 中，Ingress 是一种资源对象，它提供了集群内部服务对外暴露 HTTP(S) 端点的功能，同时具备 URL 路由、SSL/TLS 终止、重写规则等多种功能。
    kubernetes的ingress：Ingress controller，traefik
    阿白，
    05-05 2173
    文章目录Ingress介绍nginx ingress controlleringressURL RewriteBasic Auth灰度发布等各种发布方式HTTPSCertManager 自动 HTTPS安装配置自动化 HTTPSHTTP-01 校验DNS-01 校验Traefik核心概念traefik安装ACME中间件Traefik Pilot灰度发布流量复制TCPTCP服务实例带 TLS 证书的 TCPUDP Ingress介绍 对外暴露集群服务 前面我们学习了在 Kubernetes 集群内部使用 ku
    Kubernetes - 实战：ingress-nginx
    qq_33240556的博客
    04-19 467
    并且确保 DNS 解析正确，使得域名指向 Ingress Controller 的负载均衡器 IP（如果是 LoadBalancer 类型）。最后，通过浏览器或 curl 等工具访问你的域名，验证路由规则是否生效。确保 Ingress 控制器正常运行，并且 Ingress 规则已被正确应用。创建一个 Ingress 资源 YAML 文件，例如。
    Kubernetes 实战：用 Ingress-Nginx 管理流量与自动续期 HTTPS 证书
    qq_43394776的博客
    04-24 1009
    k8s中的ingress-nginx以及作用场景和k8s中如何为所有服务自动续期 Let's Encrypt 证书
    Kubernetes安装ingress-nginx
    南宫乘风-Linux运维-虚拟化容器-Python编程 ownit.top
    12-04 2158
    网上的资料一般是基于v0.30.0来安装，但是对于kubernetes@1.22来说要安装ingress-nginx@v1.0.0以上版本（目前最新版本是v1.0.4，本文采用v1.0.0），原因是 kubectl@v1.22版本不再支持v1beta1如果安装ingress-nginx@v0.30.0版本后启动pod有如下问题有一个版本的支持情况（ingress官方网站ingress仓库地址ingress-nginx v1.0 最新版本 v1.0。
    Kubernetes Dashboard + Ingress 及其 yaml 文件分析
    m0_59267075的博客
    05-25 1175
    记录部署Dashboard + Ingress的具体过程及其 yaml 文件分析。
    kubernetes学习-Ingress（八）
    wj617906617的博客
    01-19 822
    访问对应的IP地址，如下图：我这里在配置window的hosts文件时，最开始不能通过k8s.wolfcode.cn域名来访问，后面才知道，由于我的电脑开了代理，需要关闭代理，才可以进行访问。这时候去获取pod发现并没有获取到，k8s-master节点的确打上了ingress=ture标签，这是由于k8s-master上的污点导致的，k8s默认不建议将应用装到master节点上。搜索ingress-nginx/kube-webhook-certgen。或者参考上述文档的评论区。使用上面文档的解决方法。
    Kubernetes 安装配置ingress controller
    qianghong000的博客
    11-21 1422
    Kubernetes 安装配置ingress controller
    Kubernetes 网关流量管理：Ingress 与 Gateway API
    凌虚Blog
    08-31 1799
    Ingress是否会被替代？不会，Ingress自 1.19 版本 GA 后并没有计划弃用。Ingress与都是声明性资源（可以简单理解为配置文件），两者都需要由具体的网关支持工作。Ingress提供了较为简单的流量管理，适用于小规模和简单的流量需求，其实现依赖于具体的控制器，因此存在一定的供应商绑定问题。的标准化设计提供了跨平台的兼容性和一致性，并且支持多协议、多团队协作和更复杂的流量管理需求。
    K8s中，deployment 是如何从 yaml 文件最终部署成功 pod 的
    shafsyjwqt的博客
    10-23 389
    整个过程Kubernetes的“声明式 API”和“控制循环”设计理念，用户只需定义期望状态，Kubernetes会自动协调实现该状态。检测到新的Deployment对象后，根据配置创建ReplicaSet。目标节点上的Kubelet定期从API Server 同步Pod信息。如果Pod异常终止，ReplicaSet会自动创建新的Pod替换。Scheduler 负责为未调度的Pod选择合适的节点。验证YAML配置的合法性(语法、字段约束等)发现分配给自己的新Pod后，通过容器运行时创建容器。
    Prometheus（二）—— 在K8s集群中部署Prometheus+Grafana+AlertManager实现全方位监控
    荣光波比的博客
    10-23 1116
    本文介绍了在Kubernetes集群中部署完整监控系统的方案，主要包括以下组件：node-exporter（节点监控）、Prometheus（核心监控）、Grafana（可视化）和AlertManager（告警）。首先进行环境准备，包括节点检查、依赖验证和防火墙配置。随后详细部署node-exporter作为数据采集器，通过DaemonSet确保每个节点运行实例。接着部署Prometheus Server作为监控核心，配置RBAC授权和ConfigMap存储监控规则。整个方案实现了从数据采集、存储到可视化展
    用n8n工作流+DeepSeek大模型基于k8s做一个运维智能体
    最新发布
    https://ophome.blog.csdn.net,在IT行业有多年的工作经验，尤其是在Python、Linux、负载均衡、Nginx和服务器运维等领域。
    10-27 422
    用n8n工作流+DeepSeek大模型基于k8s做一个运维智能体
    K8s高可用：四大核心机制解析
    m0_75050314的博客
    10-24 342
    K8s 高可用（HA）的核心是通过和。
    K8s 集群环境搭建 - yaml 版本（一）
    weixin_45278293的博客
    10-23 613
    不同地域的云服务器内网不互通，而 k8s 集群中，master 连接 woker 默认采用的内网连接，比如连接 master 连接 woker 的 10250 端口，通过此端口获取节点状态，下发容器操作指令等。在 Kubernetes 中，CSI 提供了一种标准的方式，用于与第三方存储供应商（如 NFS、AWS EFS、Ceph、GlusterFS、Minio 等）对接，实现存储卷的创建、挂载、卸载等操作。我这里是直接在 Master 节点安装的，所以直接用的 Master 节点的内网IP。
    k8s高频面试题汇总
    daxiang的专栏
    10-26 314
    本文介绍了 50道k8s高频面试题，涵盖： 基础概念、架构组成、核心组件、网络服务等内容
    评论
    添加红包

    请填写红包祝福语或标题

    个

    红包个数最小为10个

    元

    红包金额最低5元

    当前余额3.43元 前往充值 >
    需支付：10.00元
    成就一亿技术人!
    领取后你会自动成为博主和红包主的粉丝 规则
    hope_wisdom
    发出的红包
    实付元
    使用余额支付
    点击重新获取
    扫码支付
    钱包余额 0

    抵扣说明：

    1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
    2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

    余额充值