k8sday11服务发现（2/2）
本来打算是直接进行Ingress的学习，但是考虑到昨天Service的学习只是一知半解，很多流程没有很清晰，以及部分概念没有了解的很到位，所以打算在进行Ingress的学习之前进行我的个人理解和补充
Service个人理解+补充
1、加深概念理解
①、为什么需要Service（基本原理）
在k8s集群中，我们可以通过Pod的IP进行服务的访问，但是由于Pod频繁的创建和删除，导致Pod的IP并不固定，容易变化，这就会给要使用我们服务的用户带来不方便，用户无法通过固定的IP进行我们服务的访问。k8s为了解决这个问题才引入的Service资源类型，Service会整合多个Pod，给这些Pod提供一个统一的、固定的IP地址，方便之后对这些Pod上面部署的服务的访问，而这个IP地址在Service的生命周期内是不变的，相当于给这些Pod提供了一个固定入口，用户不再需要访问Pod的IP，而是访问这个固定的入口（Service的IP）。
精简总结：为了给用户提供一个固定IP入口访问Pod内部服务
②、Service 是“虚拟入口”（核心原理）
Service只是一个概念，真正起作用的是kube-proxy进程。当我们创建了Service进程时，APIServer会向etcd存储写入刚刚你创建的Service的信息，而运行在每个Node节点上的kube-proxy，当监控到了Service和Endpoint的信息变化，就会将最新的Service信息转换为对应的访问规则。该生成的规则会在所有节点（主节点+Node副节点）生成。
精简总结：监控到了Service和Endpoint的信息变化，kube-proxy就会将最新的Service信息转换为对应的访问规则
③、Service选择器匹配
表面上看是 Service 选 Pod，实质上是 kube-proxy 根据标签选择器生成的 EndpointSlice，再把它变成内核里的负载均衡规则，最终由内核按规则加上LB算法策略进行选 Pod 转发。
精简总结：Service通过Selector和Pod标签匹配，其实是kube-proxy进行了相应规则生成
2、补充知识
①、何为访问规则（kube-proxy的工作模式）
| 维度 | userspace（已废弃） | iptables（默认） | ipvs（推荐生产） | nftables（未来主流） |
|---|---|---|---|---|
| 内核依赖 | 任意 | 2.4+ 默认 | 需加载 ip_vs* 模块 | ≥5.13，需 nftables |
| kube-proxy 担任的真实身份 | 用户态四层负载均衡器 | 内核 NAT 规则的“安装与维护者” | IPVS 调度器的“配置器 + 兜底 iptables 安装者” | nft set & nft rule 的“安装与维护者” |
| 算法 | 轮询 | 随机 | rr/wrr/lc/wlc/sh/dh… | 随机（可扩展） |
| 复杂度 | O(n) 用户态 | O(n) 规则链 | O(1) hash 表 | O(1) nft set |
| 规模拐点 | <50 服务就卡 | 1000 服务后 CPU↑ | 1 万服务仍平稳 | 同 ipvs 或更好 |
| 延迟/CPU | 高 | 中 | 低 | 低 |
| 热更新 | 慢 | 全链刷新 | 增量更新 | 增量更新 |
| 与 NetworkPolicy 兼容性 | 差 | 好 | 需确认 CNI 支持 | 需确认 CNI 支持 |
| kube-proxy 配置 | 无需 | 默认 | mode: ipvs | mode: nftables |
| 备注 | 仅历史兼容 | 1.30 仍是默认 | 生产>100 节点必开 | 1.33 起 stable |
总结：
userspace：用户发送请求到Cluster IP后经过iptables规则重新定向给kube-proxy，由kube-proxy充当一个负载均衡器，经过LB算法选择一个Pod，与之建立连接将请求发给Pod。（效率低）
iptables：用户发送请求到Cluster IP后经过iptables规则选择一个Pod，与之建立连接将请求发给Pod。kube-proxy只是用来生成iptables规则。（无灵活LB算法，当指向的Pod不可以时不可重试）
ipvs：用户发送请求到Cluster IP后经过iptables规则和LB算法选择一个Pod，与之建立连接将请求发给Pod。kube-proxy只是用来生成ipvs规则。（有灵活LB算法，效率高）
要使用ipvs模式，需安装或加载并单独手动开启ipvs内核模块，否则默认是iptables模式
nftables：用户发送请求到Cluster IP后经过 nftables DNAT 规则（哈希查表）和LB算法选择一个Pod，与之建立连接将请求发给Pod。kube-proxy是用来写 nftables 规则 + set/映射。（无全局锁）
要安装特殊插件，kube-proxy版本 1.33 起默认启用 nftables 模式，通过
--proxy-mode=nftables显式切换，Service 数量破千或节点上百时才有明显优化感觉。
②、加载ipvs内核
IPVS 已经随主流 Linux 内核主线发布，通常不需要重新编译内核，只要加载对应模块即可（99% 的现代发行版默认已编译内核带 IPVS）。如果不确定，可以跟着以下步骤加载内核：（我只提供在WSL2的内核加载哈，如果是其他版本，可以问AI看看其他的检测方法）
Ⅰ、确认当前内核到底有没有 IPVS
# 看内核编译选项（适用于 WSL2）zcat /proc/config.gz | grep -i 'IP_VS'# 输出类似效果即WSL2 内核已经完整编译了 IPVS 支持# CONFIG_IP_VS=m# CONFIG_IP_VS_IPV6=y# CONFIG_IP_VS_DEBUG=y# CONFIG_IP_VS_TAB_BITS=12# CONFIG_IP_VS_PROTO_TCP=y等等Ⅱ、加载内核
# 临时加载sudo modprobe ip_vs ip_vs_rr ip_vs_wrr ip_vs_lc ip_vs_sh nf_conntrack# 确认已加载lsmod | grep ip_vs 将会输出类似结果：
③、测试访问服务
给出我的测试实例，只进行集群内服务的访问
Ⅰ、确保容器有多个（至少两个）
kubectl get po -o wide# 如果发现只有一个容器，可以使用scale来扩容# 注意nginx-deployment1是我的deployment，记得改成自己的kubectl scale deployment nginx-deployment1 --replicas=<你要扩容的数量># 如果扩容之后，过了一会发现容器移动缩容，可以看看是否是设置了HPA# 可选择修改其中最低容器数的配置或临时暂停kubectl get hpaⅡ、进入容器并修改内容
# 在使用kubectl get po -o wide查看了Pod名称后，选择你要进入的容器名kubectl exec -it <你要进入的容器名> /bin/bash# 修改内容# 方法1、使用vi或vim（由于我还没安装故不演示）# 方法2、使用echo直接覆盖# nginx的html内容在/usr/share/nginx/html/index.htmlecho "<h1>this is nginx-text1</h1>" > /usr/share/nginx/html/index.html我的实操页面：
Ⅲ、退出容器并查看内容
# 退出容器exit# 查看内容# 方法1、一条命令直接查看# 注意这里的nginx-deployment1-785fd8f46c-8b5pn是你自己的pod名kubectl exec nginx-deployment1-785fd8f46c-8b5pn -- curl http://localhost# 方法2、在进入容器并修改后直接查看（即第一步退出容器不用执行，而是直接查看内容）curl http://localhost
④、测试服务的问题
刚开始我想通过直接使用curl pod端口：容器暴露端口 直接查看nginx的欢迎页面，但是行不通，一直处于挂起状态，为什么呢？这是因为在 WSL（或任何集群外机器）里没有通往该网段的路由，也缺少 CNI 的 VXLAN/BGP 隧道，所以包发不出去，表现为 curl 一直挂起直到超时。
原因总结：WSL2的网络隔离
以下给出三种解决方案：
Ⅰ、临时测试
# 查看当前已有服务kubectl get hpa# 使用 port-forward# 注意这里的nginx-deployment1是我的服务名，你应该改为你自己的kubectl port-forward svc/nginx-deployment1 8080:80# 注意使用了上面的命令，当前会处于一直挂起的状态，保持这个终端窗口不要关闭。# 这时候你需要另开一台虚拟机，或者再开一个终端，来查看你的服务curl http://localhost:8080# 当然你也可以在你的windows中直接访问http://localhost:8080如图：
Ⅱ、长期访问，暴露端口
# 使用 Kind 的 extraPortMappingskind: ClusterapiVersion: kind.x-k8s.io/v1alpha4nodes:- role: control-plane# 在你的集群配置文件中添加extraPortMappings:- containerPort: 30080 # Kind 容器内部的端口hostPort: 30080 # 映射到 WSL2 和 Windows 主机的端口listenAddress: "0.0.0.0" # 允许外部访问（包括 Windows 主机）protocol: TCP
# 删除原有集群kind delete cluster --name my-cluster# 使用已修改的yaml文件创建新的集群kind create cluster --config kind-config.yaml --name my-cluster注意本方法需要重建集群
# 同时创建 NodePort 类型的 ServiceapiVersion: v1kind: Servicemetadata:name: nginx-nodeportspec:type: NodePortselector:app: nginxports:- port: 80targetPort: 80nodePort: 30080
# 使用已修改的yaml文件创建新的Servicekubectl apply -f nginx-nodeport.yaml# 直接访问服务curl http://localhost:30080Ingress（ing）
简单理解，Service是一个四层负载均衡器，Ingress是一个七层负载均衡器
Ingress 是 Kubernetes 里“把集群内服务一次性、统一地暴露给集群外部用户”的标准方式，比 NodePort / LoadBalancer / port-forward 更灵活、更可扩展
一、为何需要
| 场景 | 是否需要 Ingress |
|---|---|
| 本地调试单个服务 | ❌ port-forward 就够 |
| 多服务共享 80/443 | ✅ Ingress |
| 需要域名、路径路由 | ✅ Ingress |
| 需要 HTTPS、限流、认证 | ✅ Ingress |
| 云厂商 LoadBalancer 成本太高 | ✅ Ingress + NodePort |
相当于是k8s中的nginx的反向代理
二、核心概念
1、Ingress
只是 Kubernetes 里的一条/多条 YAML 记录，就是一个资源对象，自身不会监听端口、也不会转发流量，就是用来定义用户请求转发到具体Pod服务的规则
2、Ingress Controller
是 一个 Deployment/DaemonSet（常见实现：nginx-ingress、traefik、istio-gateway 等），负责监听集群里所有的 Ingress 对象，把Ingree定义的规则翻译成自己的配置文件（nginx.conf、envoy.yaml …），真正监听端口、转发流量给后端的Pod
精简总结：用户发送请求，Ingress根据请求定义规则，Ingress Controller监听规则变化，翻译为自己的配置文件，给外界提供服务
三、环境准备
1、安装Ingress Controller
我提供两种方式安装：
①、一条 YAML 直接安装
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.12.0/deploy/static/provider/cloud/deploy.yaml# 该命令会直接拉取yaml文件并应用在集群，生成Pod# 当然，可能遇到镜像拉取失败，这个方法适用于“网络好”的用户②、我的做法：分步安装（适用“网络一般”）
Ⅰ、手动拉镜像
Ⅱ、加载到集群
Ⅲ、下载官方 YAML 到本地
Ⅳ、修改官方YAML文件
Ⅴ、应用文件创建Pod
以下给出具体代码：
# 拉取镜像（使用的是国内阿里云的镜像源）# 如果你可以直接拉取到国外官方给的，之后步骤内的修改文件就不用改了docker pull registry.aliyuncs.com/google_containers/nginx-ingress-controller:v1.12.0docker pull registry.aliyuncs.com/google_containers/kube-webhook-certgen:v1.5.0# 导入到集群# 注意my-multi-node-cluster1是我的集群名，你要改成自己的kind load docker-image registry.aliyuncs.com/google_containers/nginx-ingress-controller:v1.12.0 --name my-multi-node-cluster1kind load docker-image registry.aliyuncs.com/google_containers/kube-webhook-certgen:v1.5.0 --name my-multi-node-cluster1# 下载官方文件# 用 curlcurl -Lo ingress-nginx.yaml \https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.12.0/deploy/static/provider/cloud/deploy.yaml# 用 wgetwget -O ingress-nginx.yaml \https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.12.0/deploy/static/provider/cloud/deploy.yaml# 如果两个都由于网络问题无法下载成功，提供网址，直接另存为到本地即可# 官方YAML文件网址：https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.12.0/deploy/static/provider/cloud/deploy.yaml# 修改文件# 记得要导到相对应文件的路径下# 同时完成两处替换 + 删除所有 digestsed -i \-e 's|registry\.k8s\.io/ingress-nginx/controller|registry.aliyuncs.com/google_containers/nginx-ingress-controller|g' \-e 's|registry\.k8s\.io/ingress-nginx/kube-webhook-certgen|registry.aliyuncs.com/google_containers/kube-webhook-certgen|g' \-e 's/@sha256:[a-f0-9]*//g' \ingress-nginx.yaml# 如果以上方法不可行，可以使用最笨的方法直接用外部编辑器打开，自己修改【100%成功】# 第445行image: registry.k8s.io/ingress-nginx/controller:v1.12.0@sha256:...改为：image: registry.aliyuncs.com/google_containers/nginx-ingress-controller:v1.12.0# 第547、601行image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.5.0@sha256:.改为：image: registry.aliyuncs.com/google_containers/kube-webhook-certgen:v1.5.0# 保存并退出即可# 不放心是否修改成功，可以cat一下，或者外部编辑器打开，划到文件后面部分，大概4/5处可以看到image# 应用文件，重新部署kubectl apply -f ingress-nginx.yaml成功如图：
【注意：这些pod都是在ingress-nginx这个命名空间内的
官方 YAML 自带 Job 是为了自动生成 webhook 证书，确保 controller 能正常启动，跑一次即结束。】
2、准备Service和Pod
准备两个Service（nginx-service和tomcat-service）和两个Deployment（一个nginx，一个tomcat），每个Deployment对应3个Pod副本。
最终实现：
①、给出我的yaml配置：
# ingress的nginx-deploy1.yamlapiVersion: apps/v1 # Deployment 的API的版本kind: Deployment # 声明资源类型是 Deploymentmetadata: # Deployment 的元信息name: nginx-deploy1 # Deployment 名称（自定义），注意全小写namespace: ingress-nginx # 目标命名空间labels:app: nginx-deploy1 # 给 Deployment 打标签spec:replicas: 3 # 期望的 Pod 副本数selector: # 选择器，告诉 Deployment 它要管理哪些 PodmatchLabels: # 按照标签匹配app: nginx-ingress-deploy # 必须与下方 Pod 模板的 template.metadata.labels 一致template: # Pod 模板，通过这个模板创建副本metadata: # Pod 的元信息labels:app: nginx-ingress-deploy # Pod 标签，和上方matchLabels一致且和下方的nginx-service相匹配spec:containers:- name: nginx # 容器名称image: nginx:1.24.0 # 镜像版本，不加版本号默认最新版imagePullPolicy: IfNotPresent # 镜像拉取策略ports:- containerPort: 80 # Pod 开放的端口# 使用---隔开多个配置文件---# ingress的nginx-service.yamlapiVersion: v1 # Service的API版本（固定为v1）kind: Service # 资源类型为Servicemetadata: # 元数据name: nginx-service # Service的名称（唯一标识）namespace: ingress-nginx # 命名空间labels: # Service的标签（用于筛选）app: nginx-service # 标签（自定义）spec: # 规约（期望状态）type: ClusterIP # Service类型（ClusterIP/NodePort/LoadBalancer/ExternalName）selector: # 关键！用于选择要暴露的Pod（通过标签匹配）app: nginx-ingress-deploy # 匹配label为"app: nginx-ingress-deploy"的Podports: # 端口映射规则（可配置多个）- name: http # 端口名称（可选，用于区分多个端口）protocol: TCP # 协议（TCP/UDP/SCTP，默认TCP）port: 80 # Service暴露的端口（集群内部访问用）targetPort: 80 # Pod中容器的端口（Service转发的目标端口）# 使用---隔开多个配置文件---# ingress的tomcat-deploy1.yamlapiVersion: apps/v1 # Deployment 的API的版本kind: Deployment # 声明资源类型是 Deploymentmetadata: # Deployment 的元信息name: tomcat-deploy1 # Deployment 名称（自定义），注意全小写namespace: ingress-nginx # 目标命名空间labels:app: tomcat-deploy1 # 给 Deployment 打标签spec:replicas: 3 # 期望的 Pod 副本数selector: # 选择器，告诉 Deployment 它要管理哪些 PodmatchLabels: # 按照标签匹配app: tomcat-ingress-deploy # 必须与下方 Pod 模板的 template.metadata.labels 一致template: # Pod 模板，通过这个模板创建副本metadata: # Pod 的元信息labels:app: tomcat-ingress-deploy # Pod 标签，必须与上方的 selector.matchLabels 一致，和下方的tomcat-service相匹配spec:containers:- name: tomcat # 容器名称image: tomcat:9.0-jdk11-temurin # 镜像版本，不加版本号默认最新版imagePullPolicy: IfNotPresent # 镜像拉取策略ports:- containerPort: 8080 # Pod 开放的端口# 使用---隔开多个配置文件---# ingress的tomcat-service.yamlapiVersion: v1 # Service的API版本（固定为v1）kind: Service # 资源类型为Servicemetadata: # 元数据name: tomcat-service # Service的名称（唯一标识）namespace: ingress-nginx # 命名空间labels: # Service的标签（用于筛选）app: tomcat-service # 标签（自定义）spec: # 规约（期望状态）type: ClusterIP # Service类型（ClusterIP/NodePort/LoadBalancer/ExternalName）selector: # 关键！用于选择要暴露的Pod（通过标签匹配）app: tomcat-ingress-deploy # 匹配label为"app: tomcat-ingress-deploy"的Podports: # 端口映射规则（可配置多个）- name: httpprotocol: TCP # 协议（TCP/UDP/SCTP，默认TCP）port: 80 # Service暴露的端口（集群内部访问用）targetPort: 8080 # Pod中容器的端口（Service转发的目标端口）如果镜像拉取失败，还是可以通过手动拉取+导入集群解决哈
②、验证
配置完后应用文件并且验证即可
# 应用文件（记得导到文件对应路径）# 注意nginx-tomcat-ingress1.yaml是我的文件名，你要改成你自己的kubectl create -f nginx-tomcat-ingress1.yaml# 查看pods和servicekubectl get svc -n ingress-nginxkubectl get po -n ingress-nginx# 确认 Service selector 真的能选到 Pod（可选）kubectl get endpoints -n ingress-nginx nginx-servicekubectl get endpoints -n ingress-nginx tomcat-service如图即成功：
四、 案例HTTP+HTTPS代理
1、配置ingress的yaml文件
apiVersion: networking.k8s.io/v1 # Ingress的API版本kind: Ingress # 声明资源类型为 Ingressmetadata: # Ingress的元数据name: ingress1 # Ingress的名称（自定义）namespace: ingress-nginx # 指定目标命名空间spec: # Ingress的规约（期望状态）rules: # 定义路由规则- host: nginx.ingress1.com # 配置域名http:paths:- path: /pathType: Prefix # 必填字段backend:service: # 后端服务配置name: nginx-service # 后端第一个service服务名称port:number: 80 # 后端第一个service服务端口号- host: tomcat.ingress1.com # 配置域名http:paths:- path: /pathType: Prefixbackend:service:name: tomcat-service # 后端第二个service服务名称port:number: 80 # 后端第二个service服务端口号2、应用文件创建Ingress并验证
# 创建Ingresskubectl create -f ingress1.yaml# 验证kubectl describe ing -n ingress-nginx可得到如图类似信息：
用户通过访问Host域名，通过Ingress转发到Service，之后访问Pod
如：访问nginx.ingress1.com，会将请求发给nginx-service:80，之后将请求按规则分发给其管理的Pod
3、HTTP+HTTPS代理测试
# 使用命令查看对应http暴露端口号kubectl get svc -n ingress-nginx
前面的就是http暴露出来的端口号（80：32292）后面的是https暴露的端口号（443：30099）
①、端口转发访问服务
# 开发测试常用kubectl port-forward -n ingress-nginx service/ingress-nginx-controller 8080:80# 之后在浏览器访问服务即可http://nginx.ingress1.com:8080http://tomcat.ingress1.com:8080②、hosts配置域名访问服务
# 将 ingress-nginx-controller 的 80 和 443 同时映射到本机 80 和 443kubectl port-forward -n ingress-nginx svc/ingress-nginx-controller 80:80 443:443# 管理员权限编辑Windows hosts （C:\Windows\System32\drivers\etc\hosts）写：# 其实类似nginx的反向代理，可去我的nginx实操二中看看127.0.0.1 nginx.ingress1.com127.0.0.1 tomcat.ingress1.com# 浏览器访问服务http://nginx.ingress1.com:32292http://tomcat.ingress1.com:30099如果发现tomcat还是没有首页，是因为现代默认把应用放在webapps.dist目录，我需要手动复制到webapps目录才可以访问