今天我们学习kubernetes内容Ingress资源对象

一、概述

server服务:分为

NotePort和LoadBalancer

  • NodePort方式的缺点是端口范围窄,只有2768个pod,不满足可扩展性

  • LB方式的缺点是每个service需要一个LB,成本高,浪费

基于这种现状,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服务中的pod,并动态更新

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

二、 Ingress应用案例

环境准备

搭建ingress环境

创建文件夹

bash 复制代码
[root@k8s-master01 ~]# mkdir ingress-controller
[root@k8s-master01 ~]# cd ingress-controller/

获取ingress-nginx

bash 复制代码
[root@k8s-master01 ingress-controller]# wget https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.12.0/ingress-nginx-controller-v1.12.0.zip
[root@k8s-master01 ingress-controller]# unzip ingress-nginx-controller-v1.12.0.zip
[root@k8s-master01 ingress-controller]# cd ingress-nginx-controller-v1.12.0/deploy/static/provider/cloud
[root@k8s-master01 cloud]# ls
deploy.yaml  kustomization.yaml

查看并修改镜像源

bash 复制代码
[root@k8s-master01 cloud]# cat deploy.yaml | grep -n image
445:        image: registry.k8s.io/ingress-nginx/controller:v1.12.0
547:        image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.5.0
601:        image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.5.0

部署

bash 复制代码
[root@k8s-master01 cloud]# 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
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-master01 cloud]# kubectl -n ingress-nginx get pod
NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-sgksd        0/1     Completed   0          77s
ingress-nginx-admission-patch-f4rdc         0/1     Completed   1          77s
ingress-nginx-controller-565cc5ddd9-2qwnm   1/1     Running     0          77s

[root@k8s-master01 cloud]# kubectl -n ingress-nginx get svc
NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.10.103.132   <pending>     80:31502/TCP,443:31020/TCP   96s
ingress-nginx-controller-admission   ClusterIP      10.10.227.21    <none>        443/TCP                      96s

查看集群已经存在的nginx类型

bash 复制代码
[root@k8s-master01 cloud]# kubectl get ingressclass
NAME    CONTROLLER             PARAMETERS   AGE
nginx   k8s.io/ingress-nginx   <none>       2m53s

验证-NodePort模式

准备service和pod

创建nginx.yaml

bash 复制代码
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-deploy
  name: nginx-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-deploy
  type: ClusterIP
bash 复制代码
创建
[root@k8s-master01 ingress-controller]# kubectl apply  -f nginx.yaml 
deployment.apps/nginx-deploy created
service/nginx-svc created


# 查看
[root@k8s-master01 ingress-controller]# kubectl get pod
NAME                            READY   STATUS    RESTARTS   AGE
nginx-deploy-7c7b68644b-26jtl   1/1     Running   0          20s
nginx-deploy-7c7b68644b-5jsmb   1/1     Running   0          20s
nginx-deploy-7c7b68644b-rjc4r   1/1     Running   0          20s

[root@k8s-master01 ingress-controller]# kubectl get svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.10.0.1      <none>        443/TCP   13d
nginx-svc    ClusterIP   10.10.199.33   <none>        80/TCP    36s

ingress service配置解析

工作原理

  1. 当外部请求到达某个节点的 NodePort 时:

    • 如果该节点上有服务对应的 Pod 在运行,请求会被转发到本地的 Pod

    • 如果该节点上没有服务对应的 Pod,请求会被丢弃(返回 TCP RST)

  2. 特点:

    • 保留原始客户端 IP(不会做 SNAT)

    • 可能导致流量分布不均(只有有 Pod 的节点才会接收流量)

    • 适合需要保留客户端源 IP 的场景

验证-LoadBalancer模式

修改ARP模式,启用严格ARP模式

bash 复制代码
执行修改操作
kubectl get configmap kube-proxy -n kube-system -o yaml | \
sed -e "s/strictARP: false/strictARP: true/" | \
kubectl apply  -f - -n kube-system
 
 
#或者
kubectl get configmap kube-proxy -n kube-system -o yaml | sed -e "s/strictARP: false/strictARP: true/" | kubectl apply  -f - -n kube-system
#查看修改结果
kubectl edit configmap -n kube-system kube-proxy

为什么要修改严格模式?

  • 避免 ARP 冲突

    • 在默认情况下,容器网络可能会出现一些非预期的 ARP 行为。在 Load Balancer 模式下,流量需要准确地被分发到后端的 Pod。如果不启用严格 ARP 模式,可能会出现多个 Pod 响应同一个 ARP 请求的情况。

    • 例如,假设在一个集群中有多个 Pod 提供相同的服务,并且它们在同一个子网中。如果没有严格的 ARP 控制,负载均衡器可能会收到来自多个 Pod 的 ARP 响应,导致流量分发混乱,影响服务的正常运行。

  • 确保流量正确分发

    • 严格 ARP 模式可以确保只有正确的后端 Pod 响应 ARP 请求。这样,负载均衡器能够准确地将流量发送到预期的 Pod。

    • 以一个 Web 应用程序为例,当外部用户通过负载均衡器访问该应用时,负载均衡器需要将请求发送到正确的 Web 服务器 Pod。通过启用严格 ARP 模式,就像是给每个 Pod 一个 "专属标签",只有拥有该标签(正确 MAC 地址)的 Pod 才会响应 ARP 请求,从而保证请求能够准确无误地到达提供服务的 Pod。

  • 增强网络安全性和稳定性

    • 限制 ARP 响应可以防止恶意的 Pod 或者受到攻击的 Pod 干扰网络通信。如果一个被入侵的 Pod 随意响应 ARP 请求,可能会导致中间人攻击或者流量劫持等安全问题。

    • 严格 ARP 模式可以防止这种情况的发生,使得网络通信更加安全和稳定。例如,在一个多租户的 Kubernetes 集群环境中,不同租户的 Pod 之间通过严格的 ARP 模式来隔离网络通信,避免租户之间的相互干扰和安全威胁。

搭建metallb支持LoadBalancer

Metallb 在 Kubernetes 中的作用主要是为没有运行在如 AWS、GCP 等具有完善网络服务的云平台上的集群,提供网络负载均衡器的实现。

  • 实现 LoadBalancer 服务类型:在 Kubernetes 中,Service 有多种类型,其中 LoadBalancer 类型通常需要外部的负载均衡器支持。Metallb 可以在缺乏原生云平台负载均衡支持的环境下,模拟实现 LoadBalancer 类型的 Service。它能够为应用提供可从集群外部访问的固定 IP 地址。

  • IP 地址分配与管理:负责在指定的 IP 地址范围(IP address pool)内,为 LoadBalancer 类型的 Service 分配 IP 地址,并确保这些 IP 地址的正确映射和管理,使外部流量能够准确地路由到相应的 Kubernetes 服务后端 Pod。

  • 提供高可用的网络连接:通过实现 BGP(Border Gateway Protocol)或 Layer2 模式的负载均衡机制,确保即使在节点故障或网络波动的情况下,也能维持应用的外部网络连接的稳定性和可靠性。

相关推荐
lichenyang4533 天前
Docker 学习笔记(四):Dockerfile,把项目打成自己的镜像
docker·容器
lichenyang4533 天前
Docker 学习笔记(三):Docker 网络、bridge、子网和容器互通
docker·容器
lichenyang4533 天前
Docker 学习笔记(二):docker run 的参数到底在控制什么?
docker·容器
运维开发故事6 天前
基于 Arthas 的多集群在线诊断系统设计与实现
kubernetes
Patrick_Wilson8 天前
从「改个端口」到 502:Next.js on k8s 的容器端口、Service 映射与 env 覆盖
docker·kubernetes·next.js
探索云原生8 天前
K8s 1.36 这个 GA 特性,把 initContainer 拉模型的 hack 干掉了
ai·云原生·kubernetes
云恒要逆袭8 天前
运行你的第一个Docker容器
后端·docker·容器
Java之美9 天前
一次k8s升级引发的DevicePlugin注册失败
云原生·kubernetes
程序员老赵10 天前
10 分钟部署 OpenCode:Docker 一键安装,浏览器打开就能用 AI 写代码(附完整命令与排错)
docker·容器·ai编程