K8S Archives - 原立方 https://www.atomic-cube.cn/category/k8s/ 技术栈的流动-从零到∞ Tue, 23 Jun 2026 07:22:48 +0000 zh-CN hourly 1 https://wordpress.org/?v=7.0.2 Kubectl 命令参考手册 https://www.atomic-cube.cn/kubectl-%e5%91%bd%e4%bb%a4%e5%8f%82%e8%80%83%e6%89%8b%e5%86%8c/ https://www.atomic-cube.cn/kubectl-%e5%91%bd%e4%bb%a4%e5%8f%82%e8%80%83%e6%89%8b%e5%86%8c/#respond Tue, 16 Jun 2026 00:00:22 +0000 https://www.atomic-cube.cn/?p=2016 Kubectl 命令参考手册

The post Kubectl 命令参考手册 appeared first on 原立方.

]]> K8S 命令老是忘记，索性整理了常用的 kubectl 命令，方便日常 Kubernetes 集群管理使用。

一：基础命令

1.1 查看集群信息

# 查看集群信息
kubectl cluster-info

# 查看 Kubernetes 版本
kubectl version

# 查看 API 资源列表
kubectl api-resources

# 查看 API 版本
kubectl api-versions

1.2 查看节点信息

# 查看所有节点
kubectl get nodes

# 查看节点详细信息
kubectl get nodes -o wide

# 查看节点详细信息（JSON/YAML）
kubectl get nodes -o json
kubectl get nodes -o yaml

# 查看特定节点
kubectl get node <node-name>

# 描述节点
kubectl describe node <node-name>

二：资源查看

2.1 Pod 相关：

# 查看所有命名空间的 Podkubectl get pods --all-namespaces
kubectl get pods -A

# 查看指定命名空间的 Podkubectl get pods -n <namespace>

# 查看 Pod 详细信息
kubectl get pods -o wide

# 查看 Pod 详细信息（JSON/YAML）
kubectl get pods -o json
kubectl get pods -o yaml

# 查看特定 Podkubectl get pod <pod-name> -n <namespace>

# 查看 Pod 标签
kubectl get pods --show-labels

2.2 Deployment 相关：

# 查看所有 Deploymentkubectl get deployments
kubectl get deploy

# 查看 Deployment 详细信息
kubectl get deployments -o wide

# 查看特定 Deploymentkubectl get deployment <deployment-name> -n <namespace>

2.3 Service 相关：

# 查看所有 Servicekubectl get services
kubectl get svc

# 查看 Service 详细信息
kubectl get services -o wide

# 查看特定 Servicekubectl get service <service-name> -n <namespace>

2.4 其他资源：

# 查看所有资源类型
kubectl get all

# 查看 ConfigMapkubectl get configmaps
kubectl get cm

# 查看 Secretkubectl get secrets

# 查看 PersistentVolumekubectl get pv

# 查看 PersistentVolumeClaimkubectl get pvc

# 查看 Ingresskubectl get ingress
kubectl get ing

# 查看 Jobkubectl get jobs

# 查看 CronJobkubectl get cronjobs

# 查看 DaemonSetkubectl get daemonsets
kubectl get ds

# 查看 StatefulSetkubectl get statefulsets
kubectl get sts

三：资源操作

3.1 创建资源

# 从文件创建资源
kubectl create -f <file.yaml>

# 从 URL 创建资源
kubectl create -f <url>

# 从目录创建所有资源
kubectl create -f <directory>/

# 创建命名空间
kubectl create namespace <namespace-name>

3.2 应用资源

# 应用配置文件（推荐）
kubectl apply -f <file.yaml>

# 应用目录下所有文件
kubectl apply -f <directory>/

# 应用并记录配置
kubectl apply -f <file.yaml> --record

# 强制替换资源
kubectl apply -f <file.yaml> --force

3.3 删除资源

# 删除资源
kubectl delete -f <file.yaml>

# 删除特定资源
kubectl delete pod <pod-name> -n <namespace>
kubectl delete deployment <deployment-name> -n <namespace>
kubectl delete service <service-name> -n <namespace>

# 删除所有资源
kubectl delete all --all -n <namespace>

# 删除命名空间（会删除命名空间下所有资源）
kubectl delete namespace <namespace-name>

# 强制删除 Podkubectl delete pod <pod-name> --force --grace-period=0

3.4 编辑资源

# 编辑资源（使用默认编辑器）
kubectl edit pod <pod-name> -n <namespace>
kubectl edit deployment <deployment-name> -n <namespace>

# 编辑并应用
kubectl edit -f <file.yaml>

3.5 替换资源

# 替换资源
kubectl replace -f <file.yaml>

# 强制替换
kubectl replace -f <file.yaml> --force

四：调试和日志

4.1查看日志

# 查看 Pod 日志
kubectl logs <pod-name> -n <namespace>

# 查看前 N 行日志
kubectl logs <pod-name> -n <namespace> --tail=100

# 实时跟踪日志
kubectl logs <pod-name> -n <namespace> -f

# 查看之前容器的日志
kubectl logs <pod-name> -n <namespace> --previous

# 查看多容器 Pod 中特定容器的日志
kubectl logs <pod-name> -c <container-name> -n <namespace>

# 查看指定时间范围的日志
kubectl logs <pod-name> -n <namespace> --since=1h
kubectl logs <pod-name> -n <namespace> --since-time="2024-01-01T00:00:00Z"

4.2 进入容器

# 进入 Pod 容器（交互式）
kubectl exec -it <pod-name> -n <namespace> -- /bin/bash
kubectl exec -it <pod-name> -n <namespace> -- /bin/sh

# 在容器中执行命令
kubectl exec <pod-name> -n <namespace> -- <command>

# 在特定容器中执行命令
kubectl exec <pod-name> -c <container-name> -n <namespace> -- <command>

4.3 调试工具

# 查看 Pod 详细信息
kubectl describe pod <pod-name> -n <namespace>

# 查看事件
kubectl get events -n <namespace> --sort-by='.lastTimestamp'

# 查看资源使用情况
kubectl top nodes
kubectl top pods -n <namespace>

# 查看资源使用情况（所有命名空间）
kubectl top pods --all-namespaces

五: 配置管理

5.1 ConfigMap 操作

# 查看 ConfigMapkubectl get configmap <configmap-name> -n <namespace>

# 查看 ConfigMap 内容
kubectl get configmap <configmap-name> -n <namespace> -o yaml

# 从文件创建 ConfigMapkubectl create configmap <configmap-name> --from-file=<file-path>

# 从目录创建 ConfigMapkubectl create configmap <configmap-name> --from-file=<directory>/

# 从字面量创建 ConfigMapkubectl create configmap <configmap-name> --from-literal=key1=value1 --from-literal=key2=value2

# 编辑 ConfigMapkubectl edit configmap <configmap-name> -n <namespace>

# 删除 ConfigMapkubectl delete configmap <configmap-name> -n <namespace>

5.2 Secret 操作

# 查看 Secretkubectl get secret <secret-name> -n <namespace>

# 查看 Secret 内容（Base64 编码）
kubectl get secret <secret-name> -n <namespace> -o yaml

# 解码 Secretkubectl get secret <secret-name> -n <namespace> -o jsonpath='{.data.<key>}' | base64 -d

# 从文件创建 Secretkubectl create secret generic <secret-name> --from-file=<file-path>

# 从字面量创建 Secretkubectl create secret generic <secret-name> --from-literal=username=admin --from-literal=password=secret

# 从 Docker 注册表创建 Secretkubectl create secret docker-registry <secret-name> --docker-server=<server> --docker-username=<username> --docker-password=<password>

# 编辑 Secretkubectl edit secret <secret-name> -n <namespace>

# 删除 Secretkubectl delete secret <secret-name> -n <namespace>

5.3 端口转发

# 转发 Pod 端口到本地
kubectl port-forward <pod-name> <local-port>:<pod-port> -n <namespace>

# 转发 Service 端口到本地
kubectl port-forward service/<service-name> <local-port>:<service-port> -n <namespace>

# 转发 Deployment 端口到本地
kubectl port-forward deployment/<deployment-name> <local-port>:<container-port> -n <namespace>

# 示例：转发 MySQL 服务
kubectl port-forward service/mysql 3306:3306 -n default

5.4 执行命令

# 在 Pod 中执行命令
kubectl exec <pod-name> -n <namespace> -- <command>

# 在 Pod 中执行交互式命令
kubectl exec -it <pod-name> -n <namespace> -- <command>

# 在特定容器中执行命令
kubectl exec <pod-name> -c <container-name> -n <namespace> -- <command>

# 示例
kubectl exec my-pod -- ls /tmp
kubectl exec -it my-pod -- /bin/bash

5.5 标签和选择器

# 查看资源标签
kubectl get pods --show-labels

# 给资源添加标签
kubectl label pod <pod-name> app=myapp -n <namespace>

# 更新标签
kubectl label pod <pod-name> app=newapp --overwrite -n <namespace>

# 删除标签
kubectl label pod <pod-name> app- -n <namespace>

# 使用标签选择器查询
kubectl get pods -l app=myapp -n <namespace>
kubectl get pods -l 'app in (myapp,yourapp)' -n <namespace>
kubectl get pods -l 'app=myapp,version=v1' -n <namespace>

5.6 滚动更新

# 查看滚动更新状态
kubectl rollout status deployment/<deployment-name> -n <namespace>

# 查看滚动更新历史
kubectl rollout history deployment/<deployment-name> -n <namespace>

# 回滚到上一个版本
kubectl rollout undo deployment/<deployment-name> -n <namespace>

# 回滚到指定版本
kubectl rollout undo deployment/<deployment-name> --to-revision=<revision-number> -n <namespace>

# 暂停滚动更新
kubectl rollout pause deployment/<deployment-name> -n <namespace>

# 恢复滚动更新
kubectl rollout resume deployment/<deployment-name> -n <namespace>

# 扩展 Deploymentkubectl scale deployment/<deployment-name> --replicas=<number> -n <namespace>

5.7 资源描述

# 描述 Podkubectl describe pod <pod-name> -n <namespace>

# 描述 Deploymentkubectl describe deployment <deployment-name> -n <namespace>

# 描述 Servicekubectl describe service <service-name> -n <namespace>

# 描述 Nodekubectl describe node <node-name>

# 描述命名空间
kubectl describe namespace <namespace-name>

5.8 事件查看

# 查看所有事件
kubectl get events -n <namespace>

# 查看所有命名空间的事件
kubectl get events --all-namespaces

# 按时间排序查看事件
kubectl get events -n <namespace> --sort-by='.lastTimestamp'

# 查看特定资源的事件
kubectl get events --field-selector involvedObject.name=<pod-name> -n <namespace>

# 实时监控事件
kubectl get events -n <namespace> --watch

5.9 命名空间管理

# 查看所有命名空间
kubectl get namespaces
kubectl get ns

# 查看命名空间详细信息
kubectl get namespace <namespace-name> -o yaml

# 创建命名空间
kubectl create namespace <namespace-name>

# 删除命名空间
kubectl delete namespace <namespace-name>

# 切换到命名空间（使用 kubectx/kubens 工具）
# 或者使用上下文
kubectl config set-context --current --namespace=<namespace-name>

5.10 上下文和配置

# 查看当前上下文
kubectl config current-context

# 查看所有上下文
kubectl config get-contexts

# 切换上下文
kubectl config use-context <context-name>

# 查看配置
kubectl config view

# 查看特定上下文的配置
kubectl config view --context=<context-name>

# 设置默认命名空间
kubectl config set-context --current --namespace=<namespace-name>

# 查看集群信息
kubectl config view --minify

# 重命名上下文
kubectl config rename-context <old-name> <new-name>

六: 实用技巧

6.1 输出格式

# JSON 格式
kubectl get pods -o json

# YAML 格式
kubectl get pods -o yaml

# 自定义列
kubectl get pods -o custom-columns=NAME:.metadata.name,STATUS:.status.phase

# JSONPath
kubectl get pods -o jsonpath='{.items[*].metadata.name}'

# 表格格式（默认）
kubectl get pods

6.2 过滤和搜索

# 按标签过滤
kubectl get pods -l app=myapp

# 按字段选择器过滤
kubectl get pods --field-selector status.phase=Running

# 搜索资源
kubectl get all | grep <keyword>

6.3 批量操作

# 删除所有命名空间下的所有 Podkubectl delete pods --all --all-namespaces

# 删除所有命名空间下的所有 Deploymentkubectl delete deployments --all --all-namespaces

# 删除命名空间下的所有资源
kubectl delete all --all -n <namespace>

6.4 导出资源

<em># 导出资源为 YAMLkubectl get pod <pod-name> -n <namespace> -o yaml > pod.yaml</em>

<em># 导出资源为 JSONkubectl get pod <pod-name> -n <namespace> -o json > pod.json</em>

<em># 导出并移除集群特定信息</em>
kubectl get pod <pod-name> -n <namespace> -o yaml --export > pod.yaml

6.5 补丁操作

<em># 使用 JSON 补丁</em>
kubectl patch pod <pod-name> -p '{"spec":{"containers":[{"name":"mycontainer","image":"newimage"}]}}'

<em># 使用策略性合并补丁</em>
kubectl patch deployment <deployment-name> -p '{"spec":{"replicas":3}}'

<em># 使用 JSON 补丁文件</em>
kubectl patch pod <pod-name> --patch-file=patch.json

七: 常用组合命令

<em># 查看 Pod 并显示标签</em>
kubectl get pods --show-labels -n <namespace>

<em># 查看所有命名空间的资源</em>
kubectl get all --all-namespaces

<em># 查看资源并持续监控</em>
kubectl get pods -w -n <namespace>

<em># 查看资源并排序</em>
kubectl get pods --sort-by=.metadata.creationTimestamp -n <namespace>

<em># 查看资源使用情况</em>
kubectl top pods --sort-by=memory -n <namespace>

<em># 查看资源并过滤</em>
kubectl get pods -n <namespace> | grep <keyword>

<em># 查看资源并导出</em>
kubectl get deployment <deployment-name> -n <namespace> -o yaml > deployment.yaml

八: 故障排查命令

<em># 查看 Pod 状态和事件</em>
kubectl describe pod <pod-name> -n <namespace>

<em># 查看 Pod 日志</em>
kubectl logs <pod-name> -n <namespace> --previous

<em># 查看所有命名空间的错误 Podkubectl get pods --all-namespaces --field-selector status.phase!=Running</em>

<em># 查看节点资源使用</em>
kubectl top nodes

<em># 查看集群事件</em>
kubectl get events --all-namespaces --sort-by='.lastTimestamp'

<em># 检查 API 服务器连接</em>
kubectl cluster-info dump

<em># 查看资源配额</em>
kubectl describe quota -n <namespace>

注意事项

1. 命名空间：大多数命令需要指定 -n <namespace> 或 --namespace=<namespace>，如果不指定则使用默认命名空间（通常是 default）

2. 资源名称：可以使用完整名称或简写形式，例如：

  • pods 或 po
  • services 或 svc
  • deployments 或 deploy
  • namespaces 或 ns

3. 输出格式：使用 -o 参数指定输出格式，常用格式包括：

  • yaml
  • json
  • wide
  • custom-columns

4. 强制删除：删除资源时，如果 Pod 处于 Terminating 状态，可以使用：

kubectl delete pod <pod-name> --force --grace-period=0 -n <namespace>

5. 权限：某些命令可能需要相应的 RBAC 权限，确保当前用户有足够的权限执行操作

参考资源

The post Kubectl 命令参考手册 appeared first on 原立方.

]]> https://www.atomic-cube.cn/kubectl-%e5%91%bd%e4%bb%a4%e5%8f%82%e8%80%83%e6%89%8b%e5%86%8c/feed/ 0 本地安装Minikube部署Kubernetes环境 https://www.atomic-cube.cn/apple-chip%e5%ae%89%e8%a3%85minikube/ https://www.atomic-cube.cn/apple-chip%e5%ae%89%e8%a3%85minikube/#respond Thu, 11 Jun 2026 23:20:00 +0000 https://www.atomic-cube.cn/?p=1685 Minikube 是一个工具，它为本地环境提供了一种轻量化的 Kubernetes 集群实现。通过 Minikube，用户可以在本地机器上快速启动并运行一个 Kubernetes 环境，用来学习、测试和开发。Minikube支持Kubernetes的所有主要功能，包括Dashboard、DNS、容器运行时（如Docker、containerd、CRI-O）等。这种本地化的 Kubernetes 环境主要为开发者提供了便捷，不再需要花费额外的精力去搭建和维护一个庞大的远程集群。 1.安装 Docker Desktop 作为官方推荐的容器化平台，安装Docker Desktop能让你顺利使用Docker驱动。 2. 安装 Minikube 和 kubectl 使用 Homebrew 可以一键安装这两个核心工具。 使用 Homebrew 安装：在终端中执行以下命令： 验证安装：运行以下命令，确认版本信息能正常输出： 3. 启动你的 Kubernetes 集群 启动命令是最关键的一步。对于国内的网络环境，强烈建议配置阿里云的镜像加速，这能显著提升启动速度和成功率。 推荐方案：使用 Docker 驱动 + 阿里云镜像/dl.k8s.io加速：使用以下命令启动 Minikube： 4.验证并开始使用 如果看到节点状态为 Ready，就说明你的单节点 Kubernetes 集群已经成功运行了。 5. (可选) 启用 Minikube 插件 Minikube 提供了许多插件来扩展功能，最常用的是仪表盘（Dashboard）。 启用仪表盘 (Dashboard)：执行以下命令，浏览器将自动打开 Kubernetes 的 Web UI 界面，方便你直观地管理集群。 更多插件：执行 minikube addons list 可以查看所有可用插件，例如 ingress 用于管理入站网络流量。 […]

The post 本地安装Minikube部署Kubernetes环境 appeared first on 原立方.

]]> Minikube 是一个工具，它为本地环境提供了一种轻量化的 Kubernetes 集群实现。通过 Minikube，用户可以在本地机器上快速启动并运行一个 Kubernetes 环境，用来学习、测试和开发。Minikube支持Kubernetes的所有主要功能，包括Dashboard、DNS、容器运行时（如Docker、containerd、CRI-O）等。这种本地化的 Kubernetes 环境主要为开发者提供了便捷，不再需要花费额外的精力去搭建和维护一个庞大的远程集群。

1.安装 Docker Desktop

作为官方推荐的容器化平台，安装Docker Desktop能让你顺利使用Docker驱动。

  • 下载与安装：访问 Docker 官网，我使用的是Mac M2，需要下载适用于 Apple Chip 的安装包并进行安装。
  • 启动与验证：安装完成后，启动 Docker Desktop，并确保它在后台正常运行，状态显示为 Running。

2. 安装 Minikube 和 kubectl

使用 Homebrew 可以一键安装这两个核心工具。

使用 Homebrew 安装：在终端中执行以下命令：

brew install kubectl
brew install minikube


验证安装：运行以下命令，确认版本信息能正常输出：

kubectl version --client
minikube version

3. 启动你的 Kubernetes 集群

启动命令是最关键的一步。对于国内的网络环境，强烈建议配置阿里云的镜像加速，这能显著提升启动速度和成功率。

推荐方案：使用 Docker 驱动 + 阿里云镜像/dl.k8s.io加速：使用以下命令启动 Minikube：

docker配置使用国内镜像源后，可直接运行：
minikube start --driver=docker

可以手动指定其他源，可尝试多次下载：
minikube start --driver=docker --kubernetes-version='v1.35.1' --binary-mirror='https://dl.k8s.io'

如出现下载失败或者下载超时，可采用以下方式彻底清除现有集群和缓存，然后重新执行上面的命令进行下载：
minikube delete --all --purge
rm -rf ~/.minikube   # 可选，彻底清理残留配置

4.验证并开始使用

minikube status
kubectl get nodes

如果看到节点状态为 Ready，就说明你的单节点 Kubernetes 集群已经成功运行了。

5. (可选) 启用 Minikube 插件

Minikube 提供了许多插件来扩展功能，最常用的是仪表盘（Dashboard）。

启用仪表盘 (Dashboard)：执行以下命令，浏览器将自动打开 Kubernetes 的 Web UI 界面，方便你直观地管理集群。

minikube addons enable dashboard
启用可能会失败：
# 拉取 dashboard 镜像
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/dashboard:v2.7.0

# 拉取 metrics-scraper 镜像
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-scraper:v1.0.8

将拉取下来的国内镜像，标记为 Kubernetes 期望的官方镜像名：
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/dashboard:v2.7.0 kubernetes/dashboard:v2.7.0

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-scraper:v1.0.8 kubernetes/metrics-scraper:v1.0.8

删除失败的 Pod，让它们重新创建
kubectl delete pod -n kubernetes-dashboard --all

kubectl get pods -n kubernetes-dashboard

minikube dashboard


更多插件：执行 minikube addons list 可以查看所有可用插件，例如 ingress 用于管理入站网络流量。

🧪 测试集群：部署一个 Nginx 应用

为了验证集群功能，可以尝试部署一个简单的 Nginx 应用。

  1. 创建 Nginx Deployment：
kubectl create deployment nginx --image=nginx:alpine

2.创建一个 Service 来暴露应用：

kubectl expose deployment nginx --type=NodePort --port=80

3.获取访问地址：运行以下命令获取服务的访问 URL，然后在浏览器中打开它，就能看到 Nginx 的欢迎页面了。

minikube service nginx --url

4.清理测试资源：测试完成后，可以删除 Deployment 和 Service 来释放资源。

kubectl delete service nginx
kubectl delete deployment nginx

常用 Minikube 命令
停止集群: minikube stop (保留数据，释放 CPU/内存)
暂停集群: minikube pause (快速暂停)
删除集群: minikube delete (彻底删除数据)
查看 Dashboard: minikube dashboard (打开 Web 界面)
查看插件列表: minikube addons list

The post 本地安装Minikube部署Kubernetes环境 appeared first on 原立方.

]]> https://www.atomic-cube.cn/apple-chip%e5%ae%89%e8%a3%85minikube/feed/ 0 Kubernetes Ingress 架构设计与最佳实践指南 https://www.atomic-cube.cn/kubernetes-ingress-%e6%9e%b6%e6%9e%84%e8%ae%be%e8%ae%a1%e4%b8%8e%e6%9c%80%e4%bd%b3%e5%ae%9e%e8%b7%b5%e6%8c%87%e5%8d%97/ https://www.atomic-cube.cn/kubernetes-ingress-%e6%9e%b6%e6%9e%84%e8%ae%be%e8%ae%a1%e4%b8%8e%e6%9c%80%e4%bd%b3%e5%ae%9e%e8%b7%b5%e6%8c%87%e5%8d%97/#respond Tue, 06 Jan 2026 00:00:54 +0000 https://www.atomic-cube.cn/?p=2020 Ingress 是 Kubernetes 中用于管理外部访问集群内服务的 API 对象。它提供了 HTTP 和 HTTPS 路由、负载均衡、SSL/TLS 终止等功能。

The post Kubernetes Ingress 架构设计与最佳实践指南 appeared first on 原立方.

]]> 概述

什么是 Ingress？

Ingress 是 Kubernetes 中用于管理外部访问集群内服务的 API 对象。它提供了 HTTP 和 HTTPS 路由、负载均衡、SSL/TLS 终止等功能。

核心概念

  • Ingress Controller：实际处理流量的组件，负责实现 Ingress 规范
  • Ingress 资源：定义路由规则的 Kubernetes 资源对象
  • IngressClass：用于指定使用哪个 Ingress Controller

为什么需要 Ingress？

  • 统一入口管理：避免为每个 Service 使用 NodePort 或 LoadBalancer
  • 成本优化：一个 LoadBalancer 可以服务多个应用
  • 灵活路由：基于域名、路径的路由规则
  • SSL/TLS 管理：集中管理证书

架构设计原则

1. 集中式 Controller + 分布式 Ingress 资源

核心思想：

  • 集群级部署一个或多个 Ingress Controller（高可用）
  • 各业务命名空间独立管理自己的 Ingress 资源
  • Controller 统一处理所有命名空间的 Ingress

2. IngressClass 作用域

集群作用域（Cluster-scoped）

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
spec:
  controller: k8s.io/ingress-nginx

特点：

  • 集群内所有命名空间可用
  • 适合共享的 Ingress Controller
  • 生产环境推荐使用

命名空间作用域（Namespace-scoped）

特点：

  • 仅在该命名空间内可用
  • 适合多租户或特殊隔离场景
  • 一般不建议使用

Ingress Controller 选型

主流 Controller 对比

Controller维护者特点适用场景
Ingress-NGINXKubernetes 社区最流行，基于 Nginx，功能丰富通用场景，推荐
TraefikTraefik Labs配置简单，自动证书微服务架构
Istio GatewayIstio 社区服务网格集成服务网格环境
KongKong Inc.API 网关功能API 管理场景

推荐：Ingress-NGINX

优势：

  • Kubernetes 官方维护，社区活跃
  • 功能完善，文档齐全
  • 性能优秀，生产验证
  • 支持丰富的注解（annotations）

企业级架构方案

标准架构图

┌─────────────────────────────────────────────────────────┐
│                   外部流量入口                            │
│              (LoadBalancer / NodePort)                   │
└──────────────────────┬──────────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────────┐
│         Ingress Controller (集群级)                      │
│  ┌──────────────────────────────────────────────────┐  │
│  │  Namespace: ingress-nginx                        │  │
│  │  - Deployment: ingress-nginx-controller (3副本)   │  │
│  │  - Service: LoadBalancer                         │  │
│  │  - IngressClass: nginx (集群作用域)              │  │
│  └──────────────────────────────────────────────────┘  │
└──────────────────────┬──────────────────────────────────┘
                       │ 监听所有命名空间
        ┌──────────────┼──────────────┐
        │              │              │
┌───────▼──────┐ ┌─────▼──────┐ ┌─────▼──────┐
│  a-api       │ │  b-api     │ │  c-api     │
│  namespace   │ │  namespace │ │  namespace │
│              │ │            │ │            │
│  Ingress     │ │  Ingress   │ │  Ingress   │
│  Service     │ │  Service   │ │  Service   │
│  Deployment  │ │  Deployment│ │  Deployment│
└──────────────┘ └────────────┘ └────────────┘

高可用部署

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  replicas: 3  <em># 多副本高可用</em>
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app.kubernetes.io/name
                  operator: In
                  values:
                  - ingress-nginx
              topologyKey: kubernetes.io/hostname

多 Controller 场景（可选）

如果需要内外网隔离：

- ingress-nginx-internal (内网，IngressClass: nginx-internal)
- ingress-nginx-external (外网，IngressClass: nginx-external)

Ingress-NGINX 工作原理

1. 核心架构组件

┌─────────────────────────────────────────┐
│  Ingress Controller Pod                  │
│  ┌───────────────────────────────────┐  │
│  │  Ingress Controller (Go程序)       │  │
│  │  - 监听 Kubernetes API Server      │  │
│  │  - 生成 Nginx 配置                 │  │
│  │  - 管理 Nginx 进程                 │  │
│  └───────────────────────────────────┘  │
│  ┌───────────────────────────────────┐  │
│  │  Nginx (C程序)                     │  │
│  │  - 实际处理 HTTP/HTTPS 流量        │  │
│  │  - 读取生成的配置文件              │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

2. 工作流程

阶段 1：Controller 启动和初始化

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  template:
    spec:
      containers:
      - name: controller
        args:
        - /nginx-ingress-controller
        - --watch-ingress-without-class=true  <em># 监听所有 Ingress</em>
        - --ingress-class=nginx               <em># 只处理指定 class 的 Ingress</em>
        - --configmap=ingress-nginx-controller  <em># 全局配置</em>

启动步骤：

  1. 连接 Kubernetes API Server
  2. 创建必要的 RBAC 权限（ClusterRole/ClusterRoleBinding）
  3. 初始化 Informer 监听机制

阶段 2：监听机制（Informer Pattern）

Controller 使用 Kubernetes 的 Informer 机制实现事件驱动监听：

关键特性：

  • 集群级权限：通过 ClusterRole 读取所有命名空间的资源
  • 事件驱动：资源变化时立即触发，无需轮询
  • 本地缓存：减少 API Server 压力

监听资源类型：

  • Ingress 资源（所有命名空间）
  • Service 资源（相关命名空间）
  • Endpoints 资源（相关命名空间）
  • Secret 资源（TLS 证书）

阶段 3：Ingress 资源发现和过滤

当在任何命名空间创建 Ingress 时：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: a-api-ingress
  namespace: a-api
spec:
  ingressClassName: nginx  <em># 关键：指定使用 nginx IngressClass</em>
  rules:
  - host: a-api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: a-api-service
            port:
              number: 80

Controller 处理逻辑：

  1. IngressClass 匹配检查
    • 检查 spec.ingressClassName 是否匹配
    • 如果不匹配，忽略该 Ingress
  2. 资源验证
    • 验证 Ingress 规则的有效性
    • 检查引用的 Service 是否存在
  3. 规则解析
    • 解析 host、path 规则
    • 获取后端 Service 信息
  4. 缓存更新
    • 更新内部 Ingress 缓存
    • 触发配置重新生成

阶段 4：Nginx 配置生成

Controller 将 Ingress 规则转换为 Nginx 配置：

生成的配置示例：

<em># /etc/nginx/nginx.conf</em>

<em># 从 a-api 命名空间</em>
upstream upstream_balancer_a {
    least_conn;
    server 10.244.1.5:8080 max_fails=0 fail_timeout=0;
    server 10.244.1.6:8080 max_fails=0 fail_timeout=0;
}

server {
    listen 80;
    server_name a-api.example.com;
    
    location / {
        proxy_pass http://upstream_balancer_a;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

<em># 从 b-api 命名空间</em>
upstream upstream_balancer_b {
    least_conn;
    server 10.244.2.3:8080 max_fails=0 fail_timeout=0;
}

server {
    listen 80;
    server_name b-api.example.com;
    
    location / {
        proxy_pass http://upstream_balancer_b;
    }
}

配置生成过程：

  1. 遍历所有匹配的 Ingress 资源
  2. 解析每个 Ingress 的规则（host、path）
  3. 获取对应的 Service 和 Endpoints
  4. 生成 upstream 配置（负载均衡）
  5. 生成 server 块（路由规则）
  6. 写入配置文件
  7. 验证配置语法
  8. 重载 Nginx（nginx -s reload）

阶段 5：Service 和 Endpoints 发现

Controller 同时监听 Service 和 Endpoints 变化：

Endpoints 更新流程：

  1. Pod 启动/停止 → Endpoints 变化
  2. Controller 监听到变化
  3. 更新对应的 upstream 配置
  4. 重载 Nginx

关键点：

  • Endpoints 变化时自动更新负载均衡配置
  • 无需手动干预，实现自动服务发现

3. 跨命名空间访问原理

RBAC 配置

<em># ClusterRole - 集群级权限</em>
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ingress-nginx
rules:
- apiGroups: [""]
  resources: ["services", "endpoints", "secrets", "nodes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["networking.k8s.io"]
  resources: ["ingresses"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["networking.k8s.io"]
  resources: ["ingresses/status"]
  verbs: ["update"]
- apiGroups: ["networking.k8s.io"]
  resources: ["ingressclasses"]
  verbs: ["get", "list", "watch"]
---
<em># ClusterRoleBinding - 绑定到所有命名空间</em>
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ingress-nginx
subjects:
- kind: ServiceAccount
  name: ingress-nginx
  namespace: ingress-nginx

权限说明：

  • ClusterRole 提供集群级权限，可访问所有命名空间
  • ClusterRoleBinding 将权限绑定到 Controller 的 ServiceAccount
  • Controller 因此可以读取所有命名空间的 Ingress、Service、Endpoints

4. IngressClass 匹配机制

IngressClass 定义

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
spec:
  controller: k8s.io/ingress-nginx

匹配逻辑

Controller 启动时指定要处理的 IngressClass：

--ingress-class=nginx

匹配规则：

  1. Ingress 明确指定 ingressClassName: nginx → 匹配
  2. Ingress 未指定，但 nginx 是默认 IngressClass → 匹配
  3. 其他情况 → 不匹配，忽略

5. 完整数据流

用户创建 Ingress (a-api 命名空间)
         ↓
Kubernetes API Server
         ↓
Ingress Controller Informer 监听到事件
         ↓
Controller 验证 IngressClass 匹配
         ↓
Controller 读取对应的 Service (a-api 命名空间)
         ↓
Controller 读取 Service 的 Endpoints
         ↓
Controller 生成 Nginx 配置（包含 upstream）
         ↓
Controller 写入 /etc/nginx/nginx.conf
         ↓
Controller 执行 nginx -s reload
         ↓
Nginx 开始处理流量
         ↓
流量 → Nginx → Service → Pod

实施步骤

步骤 1：部署 Ingress Controller

使用 Helm 部署（推荐）

<em># 添加 Helm 仓库</em>
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

<em># 安装 Ingress Controller</em>
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.replicaCount=3 \
  --set controller.service.type=LoadBalancer

使用官方 YAML 部署

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/cloud/deploy.yaml

验证部署

<em># 检查 Controller 状态</em>
kubectl get pods -n ingress-nginx

<em># 检查 IngressClass</em>
kubectl get ingressclass

<em># 检查 Service</em>
kubectl get svc -n ingress-nginx

步骤 2：创建 IngressClass（如未自动创建）

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
spec:
  controller: k8s.io/ingress-nginx

步骤 3：在各命名空间创建 Ingress 资源

a-api 命名空间示例

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: a-api-ingress
  namespace: a-api
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - a-api.example.com
    secretName: a-api-tls
  rules:
  - host: a-api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: a-api-service
            port:
              number: 80

b-api 命名空间示例

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: b-api-ingress
  namespace: b-api
spec:
  ingressClassName: nginx
  rules:
  - host: b-api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: b-api-service
            port:
              number: 80

步骤 4：配置 TLS 证书（可选）

<em># 创建 TLS Secret</em>
apiVersion: v1
kind: Secret
metadata:
  name: a-api-tls
  namespace: a-api
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-cert>
  tls.key: <base64-encoded-key>

步骤 5：验证配置

<em># 检查 Ingress 状态</em>
kubectl get ingress -A

<em># 查看 Ingress 详情</em>
kubectl describe ingress a-api-ingress -n a-api

<em># 测试访问</em>
curl -H "Host: a-api.example.com" http://<ingress-ip>/

最佳实践

✅ 推荐做法

1. 单一 Ingress Controller

  • 一个集群部署一个 Ingress Controller（多副本高可用）
  • 所有命名空间共享同一个 Controller
  • 节省资源，便于管理

2. IngressClass 集群作用域

  • 使用集群作用域的 IngressClass
  • 所有命名空间可以引用
  • 统一管理，避免混乱

3. 命名空间隔离

  • 每个业务命名空间管理自己的 Ingress 资源
  • 通过 RBAC 限制权限
  • 实现职责分离

4. 域名规划

方案 A：子域名

a-api.example.com
b-api.example.com
c-api.example.com

方案 B：路径路由

example.com/a-api
example.com/b-api
example.com/c-api

5. RBAC 控制

<em># 限制命名空间只能管理自己的 Ingress</em>
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ingress-manager
  namespace: a-api
rules:
- apiGroups: ["networking.k8s.io"]
  resources: ["ingresses"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ingress-manager
  namespace: a-api
subjects:
- kind: ServiceAccount
  name: app-deployer
  namespace: a-api
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ingress-manager

6. 监控告警

  • 监控 Ingress Controller 的 Pod 状态
  • 监控 Nginx 错误日志
  • 监控 Ingress 资源状态
  • 设置告警规则

7. 资源限制

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-nginx-controller
spec:
  template:
    spec:
      containers:
      - name: controller
        resources:
          requests:
            cpu: 100m
            memory: 90Mi
          limits:
            cpu: 1000m
            memory: 512Mi

8. 配置优化

<em># ConfigMap 配置</em>
apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  <em># 工作进程数</em>
  worker-processes: "4"
  <em># 最大连接数</em>
  max-worker-connections: "16384"
  <em># 启用 gzip</em>
  enable-gzip: "true"
  <em># 日志格式</em>
  log-format-upstream: |
    $remote_addr - $remote_user [$time_local] "$request" 
    $status $body_bytes_sent "$http_referer" 
    "$http_user_agent" $request_length $request_time 
    [$proxy_upstream_name] [$proxy_alternative_upstream_name] 
    $upstream_addr $upstream_response_length 
    $upstream_response_time $upstream_status 
    $req_id

❌ 不推荐做法

  1. 每个命名空间部署独立的 Controller
    • 资源浪费
    • 管理复杂
    • 成本增加
  2. 使用命名空间作用域的 IngressClass
    • 除非有特殊隔离需求
    • 一般场景不推荐
  3. 在 Ingress 中硬编码 IP
    • 使用 Service 名称
    • 利用服务发现
  4. 忽略 TLS 配置
    • 生产环境必须启用 HTTPS
    • 使用 Let’s Encrypt 自动证书

常见问题与解决方案

Q1: Controller 无法发现其他命名空间的 Ingress？

原因：

  • RBAC 权限不足
  • IngressClass 不匹配

解决方案：

<em># 检查 RBAC</em>
kubectl get clusterrole ingress-nginx -o yaml
kubectl get clusterrolebinding ingress-nginx -o yaml

<em># 检查 IngressClass</em>
kubectl get ingressclass
kubectl describe ingress <ingress-name> -n <namespace>

Q2: 如何实现蓝绿部署？

使用 Ingress 注解：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"  <em># 10% 流量</em>
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-service-v2  <em># 新版本</em>
            port:
              number: 80

Q3: 如何配置限流？

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/limit-rps: "100"
    nginx.ingress.kubernetes.io/limit-connections: "10"
spec:
  ingressClassName: nginx
  <em># ...</em>

Q4: 如何实现跨命名空间服务访问？

Ingress 可以引用其他命名空间的 Service（需要特殊配置）：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cross-ns-ingress
  namespace: a-api
  annotations:
    nginx.ingress.kubernetes.io/upstream-vhost: "b-api-service.b-api.svc.cluster.local"
spec:
  ingressClassName: nginx
  rules:
  - host: a-api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: b-api-service
            namespace: b-api  <em># 跨命名空间</em>
            port:
              number: 80

注意：需要 Controller 有跨命名空间访问权限。

Q5: 如何查看 Nginx 配置？

<em># 进入 Controller Pod</em>
kubectl exec -it -n ingress-nginx <controller-pod> -- /bin/sh

<em># 查看生成的配置</em>
cat /etc/nginx/nginx.conf

<em># 查看特定 upstream</em>
grep -A 10 "upstream_balancer" /etc/nginx/nginx.conf

GitOps 集成

目录结构

ic2-deploy-config/
├── ingress-controller/          # Ingress Controller 配置
│   ├── base/
│   │   ├── ingressclass.yaml
│   │   ├── deployment.yaml
│   │   └── kustomization.yaml
│   └── overlays/
│       ├── production/
│       └── staging/
├── apps/
│   ├── backend/
│   │   ├── a-api/
│   │   │   ├── base/
│   │   │   │   └── ingress.yaml  # 业务 Ingress
│   │   │   └── overlays/
│   │   └── b-api/
│   └── ...
└── argocd-bootstrap/
    └── ingress-controller/
        └── application.yaml

ArgoCD Application 示例

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ingress-controller
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/ic2-deploy-config
    targetRevision: main
    path: ingress-controller/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: ingress-nginx
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

业务 Ingress 管理

每个业务应用在自己的目录下管理 Ingress：

<em># apps/backend/a-api/base/ingress.yaml</em>
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: a-api-ingress
  namespace: a-api
spec:
  ingressClassName: nginx
  rules:
  - host: a-api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: a-api-service
            port:
              number: 80

环境差异化配置

<em># apps/backend/a-api/overlays/production/ingress-patch.yaml</em>
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: a-api-ingress
  namespace: a-api
spec:
  rules:
  - host: a-api.prod.example.com  <em># 生产环境域名</em>
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: a-api-service
            port:
              number: 80

总结

核心要点

  1. 一个集群级 Ingress Controller 处理所有命名空间的 Ingress
    • 通过 ClusterRole 获得集群级权限
    • 使用 Informer 监听所有命名空间
    • IngressClass 过滤匹配的 Ingress
  2. IngressClass 使用集群作用域
    • 所有命名空间共享
    • 统一管理，避免混乱
  3. 各命名空间独立管理 Ingress 资源
    • 职责分离
    • 通过 RBAC 控制权限
  4. GitOps 实践
    • Controller 配置放在基础设施仓库
    • 业务 Ingress 随应用代码管理
    • 使用 ArgoCD/Flux 自动化部署

架构优势

  • ✅ 资源高效：一个 Controller 服务所有应用
  • ✅ 管理简单：统一入口，集中管理
  • ✅ 成本优化：减少 LoadBalancer 数量
  • ✅ 灵活扩展：支持多 Controller 场景
  • ✅ 生产就绪：高可用、监控、告警

参考资源

The post Kubernetes Ingress 架构设计与最佳实践指南 appeared first on 原立方.

]]> https://www.atomic-cube.cn/kubernetes-ingress-%e6%9e%b6%e6%9e%84%e8%ae%be%e8%ae%a1%e4%b8%8e%e6%9c%80%e4%bd%b3%e5%ae%9e%e8%b7%b5%e6%8c%87%e5%8d%97/feed/ 0 Kubernetes Ingress 架构验证实践文档 https://www.atomic-cube.cn/kubernetes-ingress-%e6%9e%b6%e6%9e%84%e9%aa%8c%e8%af%81%e5%ae%9e%e8%b7%b5%e6%96%87%e6%a1%a3/ https://www.atomic-cube.cn/kubernetes-ingress-%e6%9e%b6%e6%9e%84%e9%aa%8c%e8%af%81%e5%ae%9e%e8%b7%b5%e6%96%87%e6%a1%a3/#respond Fri, 02 Jan 2026 00:00:15 +0000 https://www.atomic-cube.cn/?p=2022 概述 本文档记录了在低配置 Kubernetes 集群环境中，对 Ingress 架构设计进行完整技术验证（PoC）的详细过程。验证过程包括部署、配置、测试和流量追踪等全链路环节。 验证环境 准备工作：资源适配策略 副本数调整 将 Controller 副本数从 3 降为 1（Worker 节点内存紧张，跑 1 个足矣）。 Service 类型选择 如果你的 K8s 是自建的（裸金属/虚拟机）且没有配置 MetalLB，LoadBalancer 类型的 Service 会一直处于 Pending 状态。为了验证，我们将 Controller 的 Service 临时改为 NodePort，这样你可以直接通过 节点IP:端口 访问。 步骤 1：部署 Ingress Controller (轻量化) 我们使用 Helm 部署，但通过命令行参数覆盖默认配置，以适应微型集群。 1.1 添加 Helm 仓库 1.2 安装 Controller (适配参数) 请直接执行以下命令： 参数解释 1.3 验证 Controller […]

The post Kubernetes Ingress 架构验证实践文档 appeared first on 原立方.

]]> 概述

本文档记录了在低配置 Kubernetes 集群环境中，对 Ingress 架构设计进行完整技术验证（PoC）的详细过程。验证过程包括部署、配置、测试和流量追踪等全链路环节。

验证环境

  • Kubernetes 版本: v1.29.15
  • 集群节点:
    • k8s-master: 10.4.4.15 (Control Plane)
    • k8s-node1: 10.4.0.17 (Worker Node)
  • 资源限制: Worker 节点内存紧张，需要轻量化部署

准备工作：资源适配策略

副本数调整

将 Controller 副本数从 3 降为 1（Worker 节点内存紧张，跑 1 个足矣）。

Service 类型选择

如果你的 K8s 是自建的（裸金属/虚拟机）且没有配置 MetalLB，LoadBalancer 类型的 Service 会一直处于 Pending 状态。为了验证，我们将 Controller 的 Service 临时改为 NodePort，这样你可以直接通过 节点IP:端口 访问。

步骤 1：部署 Ingress Controller (轻量化)

我们使用 Helm 部署，但通过命令行参数覆盖默认配置，以适应微型集群。

1.1 添加 Helm 仓库

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

1.2 安装 Controller (适配参数)

请直接执行以下命令：

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.replicaCount=1 \
  --set controller.service.type=NodePort \
  --set controller.service.nodePorts.http=30080 \
  --set controller.resources.requests.cpu=100m \
  --set controller.resources.requests.memory=90Mi \
  --set controller.admissionWebhooks.enabled=false \
  --set controller.allowSnippetAnnotations=true

参数解释

  • replicaCount=1: 节省资源
  • type=NodePort: 确保在没有云负载均衡器的情况下也能访问
  • nodePorts.http=30080: 固定端口，方便测试
  • admissionWebhooks.enabled=false: 关闭准入校验 Webhook，避免在小集群因网络波动导致从 API Server 无法连接 Controller 而造成部署失败
  • allowSnippetAnnotations=true: 允许使用 snippet 注解（如需要）

1.3 验证 Controller 启动

kubectl get pods -n ingress-nginx
<em># 等待状态变为 Running (1/1)</em>

验证结果：

NAME                                        READY   STATUS    RESTARTS   AGE
ingress-nginx-controller-744f64bf78-x8tl6   1/1     Running   0          27s

步骤 2：模拟业务服务 (Backend)

为了验证流程，我们在 a-api 命名空间部署一个简单的 Nginx 服务作为后端。

2.1 创建命名空间

kubectl create ns a-api

2.2 部署业务应用 (Deployment)

kubectl create deployment a-api-demo --image=nginx:alpine --replicas=1 -n a-api

2.3 暴露服务 (Service)

kubectl expose deployment a-api-demo --name=a-api-service --port=80 --target-port=80 -n a-api

2.4 验证业务运行

kubectl get pod,svc -n a-api

验证结果：

NAME                            READY   STATUS    RESTARTS   AGE
pod/a-api-demo-575dc6578b-dkprf   1/1     Running   0          45m

NAME                    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/a-api-service   ClusterIP   10.104.181.16   <none>        80/TCP    45m

步骤 3：应用 Ingress 规则

这里我们直接应用设计文档中的逻辑，创建一个指向 a-api 的 Ingress 资源。

3.1 创建 Ingress YAML 文件

创建文件 ingress-v129.yaml：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: a-api-ingress
  namespace: a-api
spec:
  ingressClassName: nginx  <em># 对应我们安装的 ingress-nginx</em>
  rules:
  - host: a-api.test.com   <em># 测试域名</em>
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: a-api-service
            port:
              number: 80

3.2 应用配置

kubectl apply -f ingress-v129.yaml

3.3 检查 Ingress 状态

kubectl get ingress -n a-api
<em># ADDRESS 列如果出现 IP (通常是 NodeIP) 说明 Controller 已经成功识别并注入了状态</em>

验证结果：

NAME            CLASS   HOSTS             ADDRESS   PORTS   AGE
a-api-ingress   nginx   a-api.test.com              80      7s

步骤 4：全链路技术验证

现在通过”外部”请求来验证整个链路：流量路径：curl -> NodePort(30080) -> Ingress Controller -> a-api-service -> Pod

由于我们没有配置真实的 DNS 解析，我们需要通过 curl 的 -H 参数伪造 Host 头。

请在你的 Master 节点或任何能 ping 通集群节点的机器上执行：

<em># 假设你的 Worker 节点 IP 是 192.168.1.x (请替换为真实IP)</em>
<em># 如果不知道 IP，用 kubectl get nodes -o wide 查看 INTERNAL-IP</em>
<em># 发送测试请求</em>
curl -v -H "Host: a-api.test.com" http://<你的Worker节点IP>:30080/

实际执行：

kubectl get nodes -o wide

输出：

NAME         STATUS   ROLES           AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE         KERNEL-VERSION     CONTAINER-RUNTIME
k8s-master   Ready    control-plane   2d19h  v1.29.15  10.4.4.15     <none>        Ubuntu 24.04 LTS 6.8.0-71-generic   containerd://2.2.1
k8s-node1    Ready    <none>          2d18h  v1.29.15  10.4.0.17     <none>        Ubuntu 24.04 LTS 6.8.0-71-generic   containerd://2.2.1

curl -v -H "Host: a-api.test.com" http://10.4.0.17:30080/

预期结果：

你应该能看到 Nginx 的默认欢迎页 HTML 代码：

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

实际验证结果：

*   Trying 10.4.0.17:30080...
* Connected to 10.4.0.17 (10.4.0.17) port 30080
> GET / HTTP/1.1
> Host: a-api.test.com
> User-Agent: curl/8.5.0
> Accept: */*

< HTTP/1.1 200 OK
< Date: Tue, 23 Dec 2025 03:27:48 GMT
< Content-Type: text/html
< Content-Length: 615
< Connection: keep-alive
< Last-Modified: Tue, 09 Dec 2025 19:41:33 GMT
< ETag: "69387b6d-267"
< Accept-Ranges: bytes

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

结论：如果看到了这个页面，恭喜你！你的 Ingress 设计流程已经跑通了。

步骤 5：验证”路由隔离” (可选)

为了证明 Ingress 是根据域名路由的，你可以试着访问一个不存在的域名：

curl -v -H "Host: b-api.test.com" http://<你的Worker节点IP>:30080/

预期结果：

你应该看到 404 Not Found，且是由 nginx 返回的。这证明请求到了 Ingress Controller，但 Controller 发现没有匹配 b-api.test.com 的规则，所以拦截了。

验证进阶：多命名空间 + 多服务 + 差异化响应

既然你想要”多验证几个不一样的”，我们来做两个更有趣的实验，模拟真实的微服务场景：

  • 场景 A (基于域名的路由): 不同的域名 (b-api.test.com) 分发到另一个命名空间的不同服务
  • 场景 B (基于路径的路由): 同一个域名，通过 /a 和 /b 分发给不同的业务

为了让你直观地看到区别，我们第二个服务不使用 Nginx，而是使用 Apache (httpd)。这样，服务 A 会返回 “Welcome to nginx”，服务 B 会返回 “It works!”，一眼就能看出区别。

实验 1：部署 b-api (使用 Apache)

我们模拟第二个业务团队 b-api。

1.1 创建命名空间和服务

<em># 创建命名空间</em>
kubectl create ns b-api

<em># 部署 httpd (Apache)，它的默认首页是 "It works!"，和 Nginx 很容易区分</em>
<em># 使用 alpine 版本以节省你宝贵的内存</em>
kubectl create deployment b-api-demo --image=httpd:alpine --replicas=1 -n b-api

<em># 暴露服务</em>
kubectl expose deployment b-api-demo --name=b-api-service --port=80 --target-port=80 -n b-api

1.2 创建 b-api 的 Ingress 规则

我们创建一个新的 Ingress 资源，这次绑定域名 b-api.test.com。

cat <<EOF > ingress-b-api.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: b-api-ingress
  namespace: b-api
spec:
  ingressClassName: nginx
  rules:
  - host: b-api.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: b-api-service
            port:
              number: 80
EOF

<em># 应用配置</em>
kubectl apply -f ingress-b-api.yaml

1.3 验证差异化路由

现在我们有了两个域名指向同一个 IP (你的 Worker 节点 10.4.0.17)。

测试 A (旧服务)：

curl -H "Host: a-api.test.com" http://10.4.0.17:30080/ | grep "h1"

预期输出：<h1>Welcome to nginx!</h1>

测试 B (新服务 – 跨命名空间)：

curl -H "Host: b-api.test.com" http://10.4.0.17:30080/ | grep "h1"

预期输出：<html><body><h1>It works!</h1></body></html> (或者类似的 It works 字样)

实际验证结果：

curl -v -H "Host: b-api.test.com" http://10.4.0.17:30080/

输出：

*   Trying 10.4.0.17:30080...
* Connected to 10.4.0.17 (10.4.0.17) port 30080
> GET / HTTP/1.1
> Host: b-api.test.com
> User-Agent: curl/8.5.0
> Accept: */*

< HTTP/1.1 200 OK
< Date: Tue, 23 Dec 2025 04:11:17 GMT
< Content-Type: text/html
< Content-Length: 191
< Connection: keep-alive
< Last-Modified: Fri, 07 Nov 2025 08:23:08 GMT
< ETag: "bf-642fce432f300"
< Accept-Ranges: bytes

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>It works! Apache httpd</title>
</head>
<body>
<p>It works!</p>
</body>
</html>

原理说明：Ingress Controller 根据 HTTP 请求头中的 Host 字段，自动将流量切换到了不同的 Namespace (a-api vs b-api) 和不同的 Backend Pod。

实验 2：路径路由 (Fanout) – 一个域名，多个后端

这是企业中最常用的场景：example.com/api/v1 去一个服务，example.com/api/v2 去另一个。

我们创建一个统一的入口文件 ingress-fanout.yaml，放在 a-api 命名空间下（假设由统一网关组管理，或者使用 ExternalName Service 引用跨 NS 服务，这里为了简单，我们让它管理指向 a-api 的路径，同时演示路径匹配）。

这里我们演示：

  • 访问 all.test.com/a -> 去 a-api
  • 访问 all.test.com/ -> 默认去 a-api (兜底)

(注：跨命名空间引用 Service 在标准 Ingress 中通常需要 Service 位于同 Namespace，或者使用 ExternalName。为了不把流程搞复杂，我们这里仅演示在 a-api 里的路径路由)

2.1 创建路径路由 Ingress

cat <<EOF > ingress-fanout.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: fanout-ingress
  namespace: a-api
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: all.test.com
    http:
      paths:
      # 访问 /foo 转给 a-api-service
      - path: /foo
        pathType: Prefix
        backend:
          service:
            name: a-api-service
            port:
              number: 80
      # 访问 /bar 也转给 a-api-service (实际场景通常是不同的service)
      - path: /bar
        pathType: Prefix
        backend:
          service:
            name: a-api-service
            port:
              number: 80
EOF

kubectl apply -f ingress-fanout.yaml

2.2 验证 Rewrite 和路径

<em># 访问 /foo</em>
curl -I -H "Host: all.test.com" http://10.4.0.17:30080/foo

预期：HTTP/1.1 200 OK

这里最关键的是 nginx.ingress.kubernetes.io/rewrite-target: / 这个注解。

如果不加它，请求发给 Nginx Pod 的路径会是 /foo，但 Nginx 容器内部只有 / (index.html)，没有 /foo 目录，就会报 404。加了这个注解，Ingress 会把 /foo 剥离掉，只把 / 发给后端。

实验 3：验证 HTTPS (自签名证书)

你的设计文档里提到了 SSL/TLS。虽然我们没有真证书，但可以生成一个自签名的来验证流程。

3.1 生成自签名证书

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout tls.key -out tls.crt -subj "/CN=secure.test.com"

<em># 创建 Secret</em>
kubectl create secret tls secure-tls --key tls.key --cert tls.crt -n a-api

3.2 创建 HTTPS Ingress

cat <<EOF > ingress-tls.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
  namespace: a-api
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - secure.test.com
    secretName: secure-tls
  rules:
  - host: secure.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: a-api-service
            port:
              number: 80
EOF

kubectl apply -f ingress-tls.yaml

3.3 验证 HTTPS

你需要获取 HTTPS 的 NodePort 端口（不是 30080 了，是随机的，除非我们之前固定了）。

让我们查一下 HTTPS 的端口：

kubectl get svc -n ingress-nginx ingress-nginx-controller

看 443: 后面映射的端口是多少（比如 32443）。

然后测试（加上 -k 忽略证书警告，因为是自签名的）：

<em># 假设端口是 3xxxx</em>
export HTTPS_PORT=$(kubectl get svc -n ingress-nginx ingress-nginx-controller -o jsonpath='{.spec.ports[1].nodePort}')

curl -v -k -H "Host: secure.test.com" https://10.4.0.17:$HTTPS_PORT/

如果看到 SSL connection using ... 和 Welcome to nginx!，说明 TLS 终止（Offloading）成功了！

实际验证结果：

curl -v -k -H "Host: secure.test.com" https://10.4.0.17:$HTTPS_PORT/

输出显示：

*   Trying 10.4.0.17:32443...
* Connected to 10.4.0.17 (10.4.0.17) port 32443
...
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
...
< HTTP/2 200
...
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

流量流转验证：三种方法

要证明流量确实是 Client -> Ingress Controller -> Service -> Pod 这样流转的，而不是直接撞上了 Pod 或者 Service，我们有三种”铁证”可以验证。

方法一：查看 Ingress Controller 的实时访问日志（最直接的证据）

Ingress Controller 本质上是一个反向代理（Nginx），它会记录每一条经过它的请求。如果日志里有记录，说明流量确实经过了它。

1.1 打开一个终端窗口，实时监听 Controller 的日志

<em># -f 表示 follow (实时输出)，-n 指定命名空间</em>
kubectl logs -f -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx

1.2 在另一个窗口发送请求

curl -H "Host: a-api.test.com" http://10.4.0.17:30080/

1.3 回到日志窗口观察

你应该能看到类似下面的一行日志立即滚动出来：

10.4.0.17 - - [23/Dec/2025:04:00:00 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.68.0" 86 0.002 [a-api-a-api-service-80] [] 10.1.2.3:80 615 0.002 200 ...

关键点分析：

  • Host: 如果你开启详细日志，会看到 a-api.test.com
  • Upstream ([a-api-a-api-service-80]): 这证明 Controller 识别出了这是要去 a-api 命名空间的 a-api-service 服务
  • Upstream IP (10.1.2.3:80): 这里的 IP 必须是你后端业务 Pod 的 IP（见方法二）

实际验证结果：

W1223 03:51:25.338445       7 controller.go:1469] Unexpected error validating SSL certificate "a-api/secure-tls" for server "secure.test.com": x509: certificate relies on legacy Common Name field, use SANs instead
W1223 03:51:25.338476       7 controller.go:1470] Validating certificate against DNS names. This will be deprecated in a future version
I1223 03:51:25.340746       7 controller.go:214] "Configuration changes detected, backend reload required"
I1223 03:51:25.390835       7 controller.go:228] "Backend successfully reloaded"
I1223 03:51:25.391624       7 event.go:377] Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-nginx", Name:"ingress-nginx-controller-744f64bf78-x8tl6", UID:"3b1af039-c49b-4f5d-8880-5a10b5f5d7e6", APIVersion:"v1", ResourceVersion:"460791", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload triggered due to a change in configuration
I1223 03:52:02.957678       7 status.go:311] "updating Ingress status" namespace="a-api" ingress="secure-ingress" currentValue=null newValue=[{"ip":"10.104.181.16"}]
I1223 03:52:02.962960       7 event.go:377] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"a-api", Name:"secure-ingress", UID:"3d83cbd8-361b-4265-9090-eab01250dbb1", APIVersion:"networking.k8s.io/v1", ResourceVersion:"464318", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync
W1223 03:52:02.963441       7 controller.go:1469] Unexpected error validating SSL certificate "a-api/secure-tls" for server "secure.test.com": x509: certificate relies on legacy Common Name field, use SANs instead
W1223 03:52:02.963526       7 controller.go:1470] Validating certificate against DNS names. This will be deprecated in a future version
10.4.0.17 - - [23/Dec/2025:03:52:28 +0000] "GET / HTTP/2.0" 200 615 "-" "curl/8.5.0" 30 0.001 [a-api-a-api-service-80] [] 192.168.36.78:80 615 0.001 200 8cf46d801eed33a14953870e4cc826db
10.4.0.17 - - [23/Dec/2025:04:07:13 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/8.5.0" 77 0.001 [a-api-a-api-service-80] [] 192.168.36.78:80 615 0.001 200 01ca7520fdb1071cf38873d9223db8fe
10.4.0.17 - - [23/Dec/2025:04:08:18 +0000] "GET / HTTP/2.0" 200 615 "-" "curl/8.5.0" 30 0.001 [a-api-a-api-service-80] [] 192.168.36.78:80 615 0.001 200 a698f1311f1ffd12b7bf30dbba93d21a
10.4.0.17 - - [23/Dec/2025:04:08:47 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/8.5.0" 77 0.001 [a-api-a-api-service-80] [] 192.168.36.78:80 615 0.001 200 62b640eeb06e1da08812e54dc41c4cc5
10.4.0.17 - - [23/Dec/2025:04:08:56 +0000] "GET / HTTP/1.1" 200 191 "-" "curl/8.5.0" 77 0.001 [b-api-b-api-service-80] [] 192.168.36.79:80 191 0.000 200 11c6853707a5932ce643078b26718a37

关键日志分析：

  • [a-api-a-api-service-80] [] 192.168.36.78:80: Controller 识别出这是要去 a-api 命名空间的 a-api-service 服务，目标 Pod IP 是 192.168.36.78
  • [b-api-b-api-service-80] [] 192.168.36.79:80: Controller 识别出这是要去 b-api 命名空间的 b-api-service 服务，目标 Pod IP 是 192.168.36.79

方法二：验证 IP 对应关系（数据链路证据）

在你的 Dashboard 详情页中，有一个非常关键的信息：

Endpoints: 10.104.181.16

这个 IP 地址是 Ingress Controller 经过计算后，认为”流量应该发往的目标地址”。我们需要确认这个 IP 到底是谁。

请执行以下命令：

kubectl get pods -n a-api -o wide

预期结果：

你应该会发现 a-api-demo-xxxxx 这个 Pod 的 IP 正是 192.168.36.78（或类似的 Pod IP）。

实际验证结果：

NAME                            READY   STATUS    RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
a-api-demo-575dc6578b-dkprf   1/1     Running   0          45m   192.168.36.78   k8s-node1   <none>           <none>

结论：

  • Ingress 既然显示了 Endpoint 是 192.168.36.78，说明它已经通过 Service 找到了具体的 Pod
  • 如果流量不经过 Ingress，Ingress Controller 根本不需要知道这个 Endpoint 是多少

方法三：Header 响应头和 Pod 日志”露马脚”（针对 b-api）

这个方法利用了你刚才部署的 Apache (b-api) 和 Nginx (Ingress Controller) 的特性差异。

  • 你的后端 b-api 是 Apache (httpd)
  • 你的网关 ingress-nginx 是 Nginx

如果你直接访问 Apache，响应头里的 Server 应该是 Apache/2.4.x。

但如果经过了 Ingress，Nginx 通常会把 Server 头改写或者保留。

让我们测试一下：

curl -v -H "Host: b-api.test.com" http://10.4.0.17:30080/

观察输出中的 < Server: 字段：

  • 如果看到 Server: nginx/1.x.x，这不仅证明了请求成功，还证明了是 Nginx（Ingress Controller）在回复你，它作为代理人把 Apache 的内容拿回来给了你
  • 有些配置下可能会显示 Server: Apache，但在 Header 里通常会多出一个 X-Real-IP 或者 X-Forwarded-For，这是反向代理注入的特征

你可以进到 b-api 的 Pod 里看 Apache 的访问日志，会发现来源 IP 不是你发送 curl 的机器 IP，而是 Ingress Controller Pod 的 IP。

验证命令：

<em># 1. 获取 Ingress Controller Pod IP</em>
kubectl get pods -n ingress-nginx -o wide

输出：

NAME                                        READY   STATUS    RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
ingress-nginx-controller-744f64bf78-x8tl6   1/1     Running   0          50m   192.168.36.77   k8s-node1   <none>           <none>

<em># 2. 查看 b-api 的日志</em>
kubectl logs -n b-api -l app=b-api-demo

实际验证结果：

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.36.79. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.36.79. Set the 'ServerName' directive globally to suppress this message
[Tue Dec 23 03:46:08.238030 2025] [mpm_event:notice] [pid 1:tid 1] AH00489: Apache/2.4.66 (Unix) configured -- resuming normal operations
[Tue Dec 23 03:46:08.238109 2025] [core:notice] [pid 1:tid 1] AH00094: Command line: 'httpd -D FOREGROUND'
192.168.36.77 - - [23/Dec/2025:03:47:23 +0000] "GET / HTTP/1.1" 200 191
192.168.36.77 - - [23/Dec/2025:03:47:45 +0000] "GET / HTTP/1.1" 200 191
192.168.36.77 - - [23/Dec/2025:04:08:56 +0000] "GET / HTTP/1.1" 200 191
192.168.36.77 - - [23/Dec/2025:04:11:17 +0000] "GET / HTTP/1.1" 200 191

关键发现：

  • Apache 日志中显示的来源 IP 是 192.168.36.77，这正是 Ingress Controller Pod 的 IP（192.168.36.77）
  • 这证明了流量不是从外面直接”偷渡”进来的，而是经过了 Controller 的代理

证据链闭环分析

我们提取出日志中的关键 IP 地址和角色：

IP 地址映射表

IP 地址角色来源
192.168.36.77Ingress Controller Podkubectl get pods -n ingress-nginx -o wide
192.168.36.78a-api 业务 Podkubectl get pods -n a-api -o wide
192.168.36.79b-api 业务 Pod从 Controller 日志推断出

线索 1：Controller 找到了正确的人 (向下看)

在验证 1 的 Controller 日志中，有这样一行：

[a-api-a-api-service-80] [] 192.168.36.78:80

解读：Controller 说：”我收到了去 a-api 的请求，我查了 Service 发现目标是 192.168.36.78，我已经把货发过去了。”

佐证：这就和验证 2 中 a-api Pod 的真实 IP (192.168.36.78) 完美吻合！

线索 2：业务 Pod 看到了正确的人 (向上看)

在验证 3 的 b-api (Apache) 日志中，有这样一行：

192.168.36.77 - - [23/Dec/2025:04:11:17 +0000] "GET / HTTP/1.1" 200 191

解读：Apache 说：”有个 IP 是 192.168.36.77 的家伙刚才访问了我。”

佐证：这个 IP 正是验证 3 中 Ingress Controller 自己的 Pod IP (192.168.36.77)！这证明了流量不是从外面直接”偷渡”进来的，而是经过了 Controller 的代理。

完整流量路径验证

客户端 (10.4.0.17 或外部)
    ↓
NodePort Service (30080)
    ↓
Ingress Controller Pod (192.168.36.77)
    ↓ (根据 Host 头路由)
Service (a-api-service / b-api-service)
    ↓
业务 Pod (192.168.36.78 / 192.168.36.79)

关于日志中的警告信息

你可能注意到了验证 1 开头的警告：

W1223 ... Unexpected error validating SSL certificate ... x509: certificate relies on legacy Common Name field, use SANs instead

不用担心，这是正常的。

原因

我们用简单的 openssl 命令生成的自签名证书只使用了旧版的 CN (Common Name) 字段。现代的安全标准（如 Go 1.15+ 和 Chrome）要求使用 SANs (Subject Alternative Names)。

影响

仅仅是 Controller 发出的警告，不会阻断流量。在生产环境中，你会使用 Cert-Manager 或云厂商签发的正式证书，这个问题自然就没有了。

解决方案（生产环境）

在生产环境中，建议使用 Cert-Manager 自动管理证书：

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: a-api-tls
  namespace: a-api
spec:
  secretName: a-api-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - a-api.example.com

总结与下一步

验证成果

你已经成功在低配环境验证了设计文档中的核心逻辑：

  1. ✅ Controller 集中管理：Ingress-nginx 成功运行
  2. ✅ Ingress 资源分布：在 a-api 和 b-api 命名空间定义的规则生效了
  3. ✅ 流量转发：成功将外部流量导入了内部 Service
  4. ✅ 多命名空间路由：不同域名正确路由到不同命名空间的服务
  5. ✅ TLS 终止：HTTPS 流量成功处理
  6. ✅ 流量追踪：完整验证了流量路径

环境清理（可选）

验证完成后，你可以执行以下命令清理环境，释放那宝贵的 1G 内存：

kubectl delete ns a-api
kubectl delete ns b-api
helm uninstall ingress-nginx -n ingress-nginx
kubectl delete ns ingress-nginx

下一步建议

既然你已经掌握了部署、路由、TLS(HTTPS) 和排错(日志分析)，这个 PoC 环境的历史使命已经完成了。

如果你想继续深入，可以做以下两件事之一：

  1. 清理环境：释放那宝贵的 1G 内存
  2. 尝试 GitOps 流程：把你设计文档里的 ArgoCD 部分跑通，但这可能需要更多的内存资源

目前来看，你的 Ingress 架构设计在真实集群上是完全可行且逻辑通顺的！

深入理解：核心机制解析

在完成实践验证后，你可能会有一些更深层次的问题。本节将解答三个关键问题，帮助你深入理解 Ingress 的工作原理。

问题一：Ingress Controller 是怎么知道各个命名空间的路由规则的？

核心机制：Kubernetes 的”监听（Watch）”机制 + RBAC 权限

Ingress Controller (IC) 本质上是一个运行在 Pod 里的守护进程（Go 语言编写的程序），它并不是”轮询”去问 API Server，而是通过 Event（事件）驱动 的方式工作的。

1. 它是如何”跨命名空间”看到的？

还记得我们在部署 Controller 时，Helm 帮你创建了 ClusterRole 和 ClusterRoleBinding 吗？

  • ClusterRole: 赋予了它在集群级别（Cluster-wide）读取 Ingresses、Services、Endpoints、Secrets 的权限
  • 结果: 尽管 Controller 运行在 ingress-nginx 命名空间下，但它拥有”上帝视角”，能看到 a-api、b-api 等所有命名空间里的资源

2. 它是如何”实时感知”变化的？

这是 K8s 控制器的标准工作模式（Informer Pattern）：

  1. 订阅（Watch）: Controller 启动时，会向 K8s API Server 注册一个”监听器”，订阅所有 Ingress 资源的变更事件（增、删、改）
  2. 事件触发: 当你在 a-api 下执行 kubectl apply -f ingress.yaml 时：
    • API Server 将数据存入 etcd
    • API Server 立刻推送一个 ADD 事件给 Controller
  3. 配置翻译: Controller 收到事件，读取你的 YAML 内容（Host, Path, ServiceName），将其翻译成 Nginx 原生的配置文件格式（nginx.conf）
  4. 重载 (Reload): Controller 修改 Pod 内部的 /etc/nginx/nginx.conf 文件，并执行 nginx -s reload
  5. 生效: 新的路由规则毫秒级生效

验证方法：

你可以通过以下命令观察 Controller 的实时日志，看到配置重载的过程：

kubectl logs -f -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx | grep -i reload

当你创建或修改 Ingress 时，会看到类似这样的日志：

I1223 03:51:25.340746       7 controller.go:214] "Configuration changes detected, backend reload required"
I1223 03:51:25.390835       7 controller.go:228] "Backend successfully reloaded"

问题二：我写的 ingress.yaml 本身占用资源（CPU/内存）吗？

简短回答：几乎不占用计算资源，只占用极微小的存储资源。

我们需要区分 “静态配置（Config）” 和 “运行实例（Process）”：

Ingress Controller (Pod)

  • 是活的。它是一个运行中的进程
  • 占用资源: 它需要 CPU 来处理网络请求、SSL 加密解密、计算路由；需要内存来缓存连接、加载 Lua 脚本等。所以我们需要给它限制 CPU/Mem

Ingress.yaml (资源对象)

  • 是死的。它只是一段文本数据（配置记录）
  • 存储: 当你 apply 后，它只是在 K8s 的数据库（etcd）里存了一条几 KB 的文本记录
  • 计算: 它不消耗 Worker 节点的 CPU 和内存。它不会启动任何 Pod 或容器
  • 唯一消耗: 它会导致 Ingress Controller 加载的 nginx.conf 变大一点点（几行文本），对 Controller 的内存影响微乎其微（除非你有几万条规则）

结论: 你可以在集群里创建成百上千个 ingress.yaml，只要没有流量进来，它们对集群的负载压力几乎为零。

验证方法：

<em># 查看 Ingress 资源占用的存储空间（实际上只是 etcd 中的一条记录）</em>
kubectl get ingress -A --no-headers | wc -l  <em># 统计 Ingress 数量</em>

<em># 查看 Controller 的内存使用（这才是真正消耗资源的地方）</em>
kubectl top pod -n ingress-nginx

问题三：外部流量可能绕过 Ingress Controller，直接走到业务 Pod 吗？

这是一个非常关键的安全和架构问题。

答案取决于你的 Service 类型和网络策略。

情况 A：绝对无法绕过（标准生产架构）✅

在我们的 PoC 验证中，你的业务 Service (a-api-service) 配置如下：

  • Type: ClusterIP (默认)
  • IP: 类似于 10.104.181.16

分析:

  • ClusterIP 是一个虚拟 IP，它只存在于 Kubernetes 集群内部网络中
  • 外部世界（你的笔记本、公网用户）根本就没有路由能通达这个 IP
  • 唯一入口: 外部流量只能通过你暴露的 NodePort:30080 (即 Ingress Controller) 进入

结论: 流量被迫经过 Ingress Controller -> Service -> Pod。无法绕过。

情况 B：可以绕过（配置不当/特殊需求）⚠️

如果你的业务 Service (a-api-service) 被你配置成了：

  1. Type: NodePort: 此时 K8s 会在所有节点上开一个端口（比如 31000）。外部用户如果知道这个端口，就可以直接 curl NodeIP:31000 访问你的 Pod，完全绕过 Ingress 的路由规则、限流和鉴权
  2. Type: LoadBalancer: 云厂商会直接给这个 Service 分配一个公网 IP。外部流量直接打进来，绕过 Ingress
  3. HostNetwork: true: Pod 直接占用宿主机网络，也能被绕过

验证方法：

<em># 检查你的 Service 类型（应该是 ClusterIP）</em>
kubectl get svc -n a-api

<em># 尝试直接访问 ClusterIP（应该失败，因为外部无法路由）</em>
curl http://10.104.181.16/  <em># 这个 IP 只在集群内部可达</em>

总结: 只要你的业务 Service 类型保持为 ClusterIP（这是默认值，也是最佳实践），外部流量就物理上无法绕过 Ingress Controller。Ingress 变成了集群唯一的”守门人”。

最佳实践建议

  1. 业务 Service 使用 ClusterIP（默认值，无需修改）
  2. 仅 Ingress Controller 使用 NodePort 或 LoadBalancer 作为外部入口
  3. 使用 NetworkPolicy 进一步限制 Pod 间的网络访问（可选，但推荐）
  4. 定期审计 Service 类型，确保没有业务服务被误配置为 NodePort 或 LoadBalancer

实践验证：外部流量绕过 Ingress 实验

为了更直观地理解 Service 类型对安全性的影响，我们可以通过两个阶段来验证：

  • 阶段一（现状验证）：证明当前状态下，外部流量无法绕过 Ingress
  • 阶段二（模拟漏洞）：人为修改配置，让外部流量成功绕过 Ingress（演示如果不小心配置错了会发生什么）

阶段一：验证”无法绕过” (安全基线)

目前你的 a-api-service 应该是默认的 ClusterIP 类型。这意味着它只有集群内部 IP，没有对外的端口。

1. 确认 Service 类型
kubectl get svc -n a-api

预期输出：

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
a-api-service   ClusterIP   10.97.242.22    <none>        80/TCP    ...

关键点：TYPE 是 ClusterIP。

实际验证结果：

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
a-api-service   ClusterIP   10.97.242.22    <none>        80/TCP    3h9m
2. 尝试直接”攻击”后端

我们知道 a-api 的 Pod 运行在 Worker 节点 (10.4.0.17) 上，且服务端口是 80。我们试着直接访问 Worker 节点的 80 端口，看看能不能摸到业务 Pod。

<em># 尝试直接连接 Worker IP 的 80 端口</em>
curl -v --connect-timeout 5 http://10.4.0.17:80/

预期结果：

失败 (Connection refused 或 Timed out)。

原因：Worker 节点的宿主机上，并没有任何进程监听 80 端口。Pod 的 80 端口是在 CNI (容器网络) 的虚拟网络里的，外部物理网络直接连不通。

实际验证结果：

*   Trying 10.4.0.17:80...
* Connected to 10.4.0.17 (10.4.0.17) port 80
> GET / HTTP/1.1
> Host: 10.4.0.17
...
< HTTP/1.1 200 OK
< Server: nginx/1.29.4
...
<title>InkSpace - 个人网站</title>

⚠️ 特殊情况说明：

在实际验证中，访问 Worker 节点的 80 端口成功了，但返回的是”InkSpace – 个人网站”的内容，而不是 Kubernetes Pod 的内容。这是因为：

  • 宿主机上部署了博客系统，占用了 80 端口
  • 这个响应来自宿主机的应用，不是 Kubernetes Pod
  • 这证明了：即使宿主机有服务监听 80 端口，Kubernetes Pod 的 80 端口仍然是隔离的，外部无法直接访问

结论：在当前配置下，外部流量必须经过 NodePort 30080 (Ingress Controller) 才能访问到 Kubernetes 集群内的业务 Pod，无法绕过。

阶段二：模拟”绕过 Ingress” (制造漏洞)

现在我们修改 Service 配置，把它变成 NodePort 类型。这相当于在防火墙上打了一个洞，允许外部直接访问业务 Service。

1. 修改 Service 类型为 NodePort

执行以下命令，将 a-api-service 的类型”热更新”为 NodePort：

kubectl patch svc a-api-service -n a-api -p '{"spec": {"type": "NodePort"}}'

实际执行结果：

service/a-api-service patched
2. 查看暴露的端口

再次查看 Service，找到 K8s 随机分配的那个端口：

kubectl get svc -n a-api

实际输出：

NAME            TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
a-api-service   NodePort   10.97.242.22     <none>        80:30925/TCP   3h14m

关键信息：分配的端口是 30925（请以你实际看到的为准）。

3. 执行绕过攻击

现在，我们不走 Ingress (端口 30080)，而是直接走这个后门端口 (30925)。

<em># 替换 30925 为你上面查到的端口</em>
export BYPASS_PORT=$(kubectl get svc -n a-api a-api-service -o jsonpath='{.spec.ports[0].nodePort}')

curl -v http://10.4.0.17:$BYPASS_PORT/

预期结果：

✅ 成功返回 <title>Welcome to nginx!</title>。

实际验证结果：

*   Trying 10.4.0.17:30925...
* Connected to 10.4.0.17 (10.4.0.17) port 30925
> GET / HTTP/1.1
> Host: 10.4.0.17:30925
...
< HTTP/1.1 200 OK
< Server: nginx/1.29.4
...
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
<h1>Welcome to nginx!</h1>
...

😱 后果：你成功绕过了 Ingress Controller！

阶段三：铁证如山 (日志对比)

为了证明这是”绕过”，我们需要看 Ingress Controller 的日志。

1. 打开日志监听
kubectl logs -f -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx
2. 再次发送”绕过请求”

在另一个窗口执行刚才的 curl 命令（访问 30925 端口）。

curl -v http://10.4.0.17:30925/
3. 观察日志

结果：Ingress Controller 的日志里静悄悄的，完全没有这条访问记录。

结论：因为流量根本没经过它！就像你偷偷从后门进了大楼，前门的保安（Ingress）根本不知道你来了。

这就带来了严重的问题：

  • ❌ Ingress 上配置的 HTTPS 加密失效了（你是明文访问的）
  • ❌ Ingress 上配置的限流、鉴权、WAF 防火墙全部失效
  • ❌ 无法通过 Ingress 日志追踪和审计访问记录

阶段四：恢复环境 (堵上漏洞)

验证完成后，我们必须把这个漏洞堵上，恢复架构的安全性。

1. 恢复 Service 为 ClusterIP
kubectl patch svc a-api-service -n a-api -p '{"spec": {"type": "ClusterIP"}}'

<em># 注意：patch 可能会报错说端口冲突或字段不可变</em>
<em># 如果报错，最简单的办法是删了重建 Service (不删 Deployment 不影响业务)</em>
kubectl delete svc a-api-service -n a-api
kubectl expose deployment a-api-demo --name=a-api-service --port=80 --target-port=80 -n a-api

实际执行结果：

<em># 第一步：尝试 patch（可能失败）</em>
kubectl patch svc a-api-service -n a-api -p '{"spec": {"type": "ClusterIP"}}'
<em># service/a-api-service patched</em>

<em># 第二步：删除并重建（更稳妥）</em>
kubectl delete svc a-api-service -n a-api
<em># service "a-api-service" deleted</em>

kubectl expose deployment a-api-demo --name=a-api-service --port=80 --target-port=80 -n a-api
<em># service/a-api-service exposed</em>
2. 再次验证
kubectl get svc -n a-api

实际验证结果：

NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
a-api-service   ClusterIP   10.100.197.170   <none>        80/TCP    8s

✅ 确认变回了 ClusterIP。

3. 验证绕过端口已失效
<em># 尝试访问之前的 NodePort</em>
curl -v http://10.4.0.17:30925/

实际验证结果：

*   Trying 10.4.0.17:30925...
* connect to 10.4.0.17 port 30925 from 10.4.4.15 port 53912 failed: Connection refused
* Failed to connect to 10.4.0.17 port 30925 after 1 ms: Couldn't connect to server

✅ 确认 NodePort 端口已关闭，无法绕过。

实验总结

通过这个实验，我们验证了：

  1. ✅ ClusterIP 是安全的防线：只要 Service 是 ClusterIP，外部流量就”物理上”无法直接触达业务 Pod（除非宿主机本身有服务占用端口，但那是宿主机层面的，不是 Kubernetes 层面的）
  2. ⚠️ NodePort 是潜在的漏洞：如果开发人员随意把业务 Service 改成 NodePort，就会导致 Ingress 被架空，所有安全策略失效
  3. 🔒 防御建议：这就是为什么在生产环境中，我们通常会配合 NetworkPolicy（网络策略） 来进一步加固：”只允许 Ingress Controller 的 Pod 访问后端业务 Pod，禁止其他任何来源访问。”

进一步加固：NetworkPolicy 示例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-only
  namespace: a-api
spec:
  podSelector:
    matchLabels:
      app: a-api-demo
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx
    - podSelector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx
    ports:
    - protocol: TCP
      port: 80

这个策略确保：只有来自 ingress-nginx 命名空间的 Pod 才能访问 a-api 的 Pod，即使 Service 被误配置为 NodePort，外部流量也无法直接到达 Pod。

附录：完整命令清单

部署阶段

<em># 1. 安装 Helm（如未安装）</em>
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

<em># 2. 添加 Helm 仓库</em>
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

<em># 3. 部署 Ingress Controller</em>
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.replicaCount=1 \
  --set controller.service.type=NodePort \
  --set controller.service.nodePorts.http=30080 \
  --set controller.resources.requests.cpu=100m \
  --set controller.resources.requests.memory=90Mi \
  --set controller.admissionWebhooks.enabled=false \
  --set controller.allowSnippetAnnotations=true

<em># 4. 验证 Controller</em>
kubectl get pods -n ingress-nginx

业务服务部署

<em># 创建命名空间</em>
kubectl create ns a-api
kubectl create ns b-api

<em># 部署 a-api (Nginx)</em>
kubectl create deployment a-api-demo --image=nginx:alpine --replicas=1 -n a-api
kubectl expose deployment a-api-demo --name=a-api-service --port=80 --target-port=80 -n a-api

<em># 部署 b-api (Apache)</em>
kubectl create deployment b-api-demo --image=httpd:alpine --replicas=1 -n b-api
kubectl expose deployment b-api-demo --name=b-api-service --port=80 --target-port=80 -n b-api

Ingress 配置

<em># a-api Ingress</em>
cat <<EOF > ingress-v129.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: a-api-ingress
  namespace: a-api
spec:
  ingressClassName: nginx
  rules:
  - host: a-api.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: a-api-service
            port:
              number: 80
EOF

<em># b-api Ingress</em>
cat <<EOF > ingress-b-api.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: b-api-ingress
  namespace: b-api
spec:
  ingressClassName: nginx
  rules:
  - host: b-api.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: b-api-service
            port:
              number: 80
EOF

<em># 应用配置</em>
kubectl apply -f ingress-v129.yaml
kubectl apply -f ingress-b-api.yaml

验证命令

<em># 获取节点 IP</em>
kubectl get nodes -o wide

<em># 测试 HTTP</em>
curl -v -H "Host: a-api.test.com" http://10.4.0.17:30080/
curl -v -H "Host: b-api.test.com" http://10.4.0.17:30080/

<em># 查看日志</em>
kubectl logs -f -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx
kubectl logs -n a-api -l app=a-api-demo
kubectl logs -n b-api -l app=b-api-demo

<em># 查看 Pod IP</em>
kubectl get pods -n ingress-nginx -o wide
kubectl get pods -n a-api -o wide
kubectl get pods -n b-api -o wide

The post Kubernetes Ingress 架构验证实践文档 appeared first on 原立方.

]]> https://www.atomic-cube.cn/kubernetes-ingress-%e6%9e%b6%e6%9e%84%e9%aa%8c%e8%af%81%e5%ae%9e%e8%b7%b5%e6%96%87%e6%a1%a3/feed/ 0 Kubernetes集群搭建并部署Web应用 https://www.atomic-cube.cn/k8s%e9%9b%86%e7%be%a4%e6%90%ad%e5%bb%ba%e5%b9%b6%e9%83%a8%e7%bd%b2web%e5%ba%94%e7%94%a8/ https://www.atomic-cube.cn/k8s%e9%9b%86%e7%be%a4%e6%90%ad%e5%bb%ba%e5%b9%b6%e9%83%a8%e7%bd%b2web%e5%ba%94%e7%94%a8/#respond Mon, 01 Dec 2025 00:00:11 +0000 https://www.atomic-cube.cn/?p=2032 写在前面 本文记录了从零开始使用 Kind 搭建单节点 Kubernetes 集群，并成功部署 Go Web 应用的完整过程。包括集群搭建、镜像构建、应用部署等各个环节，以及遇到的各种问题和解决方案。 环境准备 系统环境 Docker 安装 参考菜鸟教程：https://www.runoob.com/docker/ubuntu-docker-install.html Go 安装参考：https://www.runoob.com/go/go-environment.html Kind 安装 Kind 安装方式非常多，我们这里使用 Go 安装，使用以下命令： 更多关于 Kind 的内容可以参考官方文档：https://kind.sigs.k8s.io/ kubectl 安装 网络环境 Kind 集群搭建 1.1 初始集群状态检查 首先检查现有的 kind 集群： 执行结果：我这里之前测试创建了两个集群，刚安装 kind 肯定是没有的 发现有两个集群：dev 和 kind 1.2 集群问题诊断 检查 kind 集群状态时发现 Calico 网络插件存在问题： 执行结果： 问题现象： 根本原因分析： 详细错误信息： 错误输出： 1.3 重新创建集群 删除有问题的集群，重新创建： 执行结果： […]

The post Kubernetes集群搭建并部署Web应用 appeared first on 原立方.

]]> 写在前面

本文记录了从零开始使用 Kind 搭建单节点 Kubernetes 集群，并成功部署 Go Web 应用的完整过程。包括集群搭建、镜像构建、应用部署等各个环节，以及遇到的各种问题和解决方案。

环境准备

系统环境

  • 操作系统: Ubuntu 22.04.5 LTS
  • CPU: 4 核
  • 内存: 8GB
  • Docker 版本: 28.3.3
  • Kind 版本: v0.29.0

Docker 安装

参考菜鸟教程：https://www.runoob.com/docker/ubuntu-docker-install.html

Go 安装参考：https://www.runoob.com/go/go-environment.html

Kind 安装

Kind 安装方式非常多，我们这里使用 Go 安装，使用以下命令：

go install sigs.k8s.io/kind@v0.29.0

更多关于 Kind 的内容可以参考官方文档：https://kind.sigs.k8s.io/

kubectl 安装

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin

网络环境

  • 服务器位于国内，配置了多个 Docker 镜像源
  • 包含阿里云、清华、中科大等国内镜像源
  • 使用代理环境进行网络访问

Kind 集群搭建

1.1 初始集群状态检查

首先检查现有的 kind 集群：

kind get clusters

执行结果：
我这里之前测试创建了两个集群，刚安装 kind 肯定是没有的

dev
kind

发现有两个集群：dev 和 kind

1.2 集群问题诊断

检查 kind 集群状态时发现 Calico 网络插件存在问题：

kubectl get pods -n kube-system

执行结果：

NAME                                         READY   STATUS                  RESTARTS      AGE
calico-kube-controllers-7498b9bb4c-dfjfp     0/1     ImagePullBackOff        0             10h
calico-node-bp4df                            0/1     Init:ImagePullBackOff   0             10h
coredns-674b8bbfcf-j28hf                     1/1     Running                 0             10h
coredns-674b8bbfcf-z9wkq                     1/1     Running                 0             10h
etcd-kind-control-plane                      1/1     Running                 1 (11h ago)   10h
kindnet-hvxwh                                1/1     Running                 0             10h
kube-apiserver-kind-control-plane            1/1     Running                 1 (11h ago)   10h
kube-controller-manager-kind-control-plane   1/1     Running                 1 (11h ago)   10h
kube-proxy-9qvpq                             1/1     Running                 0             10h
kube-scheduler-kind-control-plane            1/1     Running                 1 (11h ago)   10h

问题现象：

  • calico-kube-controllers 和 calico-node 出现 ImagePullBackOff 错误
  • 错误信息显示代理连接失败：dial tcp 127.0.0.1:7890: connection refused

根本原因分析：

  • 代理设置与镜像源配置冲突
  • 网络环境复杂导致镜像拉取失败

详细错误信息：

kubectl describe pod calico-kube-controllers-7498b9bb4c-dfjfp -n kube-system

错误输出：

Events:
 Type     Reason   Age                   From     Message ----     ------   ----                  ----     ------- Normal   Pulling  15m (x130 over 10h)   kubelet  Pulling image "docker.io/calico/kube-controllers:v3.25.0" Warning  Failed   15m (x130 over 10h)   kubelet  Failed to pull image "docker.io/calico/kube-controllers:v3.25.0": failed to pull and unpack image "docker.io/calico/kube-controllers:v3.25.0": failed to resolve reference "docker.io/calico/kube-controllers:v3.25.0": failed to do request: Head "https://registry-1.docker.io/v2/calico/kube-controllers/manifests/v3.25.0": proxyconnect tcp: dial tcp 127.0.0.1:7890: connect: connection refused Normal   BackOff  20s (x2897 over 10h)  kubelet  Back-off pulling image "docker.io/calico/kube-controllers:v3.25.0" Warning  Failed   20s (x2897 over 10h)  kubelet  Error: ImagePullBackOff

1.3 重新创建集群

删除有问题的集群，重新创建：

<em># 删除现有集群</em>
kind delete cluster --name dev
kind delete cluster --name kind

<em># 重新创建集群，使用稳定版本</em>
kind create cluster --name dev --image kindest/node:v1.23.6

执行结果：

Creating cluster "dev" ...
 ✓ Ensuring node image (kindest/node:v1.23.6) 🖼
 ✓ Preparing nodes 📦  
✓ Writing configuration 📜 
⠎⠁ Starting control-plane 🕹️ 
✓ Starting control-plane 🕹️ 
✓ Installing CNI 🔌 
✓ Installing StorageClass 💾 
Set kubectl context to "kind-dev"
You can now use your cluster with:

kubectl cluster-info --context kind-dev

Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂

成功指标：

  • 使用稳定的 v1.23.6 版本
  • 自动安装默认的 kindnet 网络插件
  • 避免 Calico 的镜像拉取问题

1.4 集群验证

<em># 检查集群状态</em>
kubectl cluster-info --context kind-dev
kubectl get nodes
kubectl get pods -n kube-system

执行结果：

<em># 集群信息</em>
Kubernetes control plane is running at https://127.0.0.1:33427
CoreDNS is running at https://127.0.0.1:33427/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

<em># 节点状态</em>
NAME                STATUS   ROLES                  AGE     VERSION
dev-control-plane   Ready    control-plane,master   4m39s   v1.23.6

<em># 系统Pods状态</em>
NAME                                        READY   STATUS    RESTARTS   AGE
coredns-64897985d-gg4ng                     1/1     Running   0          4m26s
coredns-64897985d-smmdx                     1/1     Running   0          4m26s
etcd-dev-control-plane                      1/1     Running   0          4m42s
kindnet-6x6jx                               1/1     Running   0          4m26s
kube-apiserver-dev-control-plane            1/1     Running   0          4m41s
kube-controller-manager-dev-control-plane   1/1     Running   0          4m41s
kube-proxy-9xrkn                            1/1     Running   0          4m26s
kube-scheduler-dev-control-plane            1/1     Running   0          4m40s

验证结果：

  • 控制平面正常运行
  • 所有核心 Pods 状态正常
  • 使用 kindnet 网络插件，运行稳定

Go Web 应用开发

2.1 应用代码

你可以使用:

go mod init ${project_name}
例如：
go mod init github/xxxxxx/go-web

使用 vim main.go 写入以下内容后，并且执行 go mod tidy 对依赖进行加载

package main

import (
 "net/http" "github.com/gin-gonic/gin")

func Pong(c *gin.Context) {
 c.JSON(http.StatusOK, gin.H{ "name":   "xxxxxx", "age":    18, "school": "家里蹲大学",
 })}

func main() {
 r := gin.Default() r.GET("/ping", Pong) r.Run("0.0.0.0:8080")}

2.2 Dockerfile 构建

项目根目录下创建一个 Dockerfile

<em># 构建阶段</em>
FROM golang:1.21-alpine AS builder

<em># 设置工作目录</em>
WORKDIR /app

<em># 设置国内Go代理（解决网络问题）</em>
RUN go env -w GOPROXY=https://goproxy.cn,direct

<em># 预下载依赖 (利用Docker缓存层)</em>
COPY go.mod go.sum ./
RUN go mod download

<em># 拷贝源代码</em>
COPY . .

<em># 编译静态二进制文件</em>
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags='-w -s' -o go-web-app

<em># 运行阶段 (使用极简镜像)</em>
FROM alpine:3.18

<em># 安装CA证书</em>
RUN apk add --no-cache ca-certificates

<em># 创建非root用户</em>
RUN adduser -D -u 10001 appuser
USER appuser

<em># 从构建阶段复制二进制文件</em>
COPY --from=builder --chown=appuser /app/go-web-app /app/go-web-app

<em># 设置环境变量</em>
ENV GIN_MODE=release
 PORT=8080
<em># 暴露端口</em>
EXPOSE 8080

<em># 启动应用</em>
ENTRYPOINT ["/app/go-web-app"]
  • 使用多阶段构建减小镜像大小
  • 设置国内 Go 代理解决依赖下载问题
  • 使用非 root 用户提高安全性
  • 添加编译优化参数减小二进制大小

2.3 镜像构建

docker build -t go-web:latest .

构建过程输出：

[+] Building 337.3s (17/17) FINISHED                                                                                                                           
 => [internal] load build definition from Dockerfile                                                                                      0.0s 
 => => transferring dockerfile: 854B                                                                                                                                      0.0s 
 => [internal] load metadata for docker.io/library/alpine:3.18                                                                                                     3.5s 
 => [internal] load metadata for docker.io/library/golang:1.21-alpine                                                                                                     4.3s 
 => [internal] load .dockerignore                                                                                                                                         0.0s 
 => => transferring context: 2B                                                                                                                                      0.0s 
 => [builder 1/7] FROM docker.io/library/golang:1.21-alpine@sha256:2414035b086e3c42b99654c8b26e6f5b1b1598080d65fd03c7f499552ff4dc94                                      47.5s 
 => => resolve docker.io/library/golang:1.21-alpine@sha256:2414035b086e3c42b99654c8b26e6f5b1b1598080d65fd03c7f499552ff4dc94                                               0.0s 
 => => extracting sha256:c6a83fedfae6ed8a4f5f7cbb6a7b6f1c1ec3d86fea8cb9e5ba2e5e6673fde9f6                                                                                 0.1s 
 => => extracting sha256:41db7493d1c6f3f26428d119962e3862c14a9e20bb0b8fefc36e7282d015d099                                                                                 0.0s 
 => => extracting sha256:54bf7053e2d96c2c7f4637ad7580bd64345b3c9fabb163e1fdb8894aea8a9af0                                                                                 3.5s 
 => => extracting sha256:4579008f8500d429ec007d092329191009711942d9380d060c8d9bd24c0c352c                                                                                 0.0s 
 => => extracting sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1                                                                                 0.0s 
 => [stage-1 1/4] FROM docker.io/library/alpine:3.18@sha256:de0eb0b3f2a47ba1eb89389859a9bd88b28e82f5826b6969ad604979713c2d4f                                              9.6s 
 => => resolve docker.io/library/alpine:3.18@sha256:de0eb0b3f2a47ba1eb89389859a9bd88b28e82f5826b6969ad604979713c2d4f                                                      0.1s 
 => => extracting sha256:44cf07d57ee4424189f012074a59110ee2065adfdde9c7d9826bebdffce0a885                                                                                 3.4MB                                                                                 9.4s
 => => extracting sha256:44cf07d57ee4424189f012074a59110ee2065adfdde9c7d9826bebdffce0a885                                                                                 0.1s => [stage-1 2/4] RUN apk add --no-cache ca-certificates                                                                                                                322.7s => [builder 2/7] WORKDIR /app                                                                                                                                            1.9s => [builder 3/7] RUN go env -w GOPROXY=https://goproxy.cn,direct                                                                                                         0.3s => [builder 4/7] COPY go.mod go.sum ./                                                                                                                                   0.2s => [builder 5/7] RUN go mod download                                                                                                                                    35.1s => [builder 6/7] COPY . .                                                                                                                                                0.1s => [builder 7/7] RUN CGO_ENABLED=0 GOOS=linux go build -ldflags='-w -s' -o go-web-app                                                                                   15.4s => [stage-1 3/4] RUN adduser -D -u 10001 appuser                                                                                                                         0.3s => [stage-1 4/4] COPY --from=builder --chown=appuser /app/go-web-app /app/go-web-app                                                                                     0.1s => => exporting to image                                                                                                                                                 0.1s => => exporting layers                                                                                                                                                   0.1s => => writing image sha256:40a377fbf28772e04665a7ce2cb8ceebbcc6f4da3a6102eeb294627cef56047b                                                                              0.0s => => naming to docker.io/library/go-web:latest                                                                                                                          0.0s

构建结果：

  • 镜像大小：15MB（非常轻量）
  • 构建时间：约 5 分钟
  • 构建成功，无错误

2.4 本地测试

<em># 测试运行容器</em>
docker run -d --name go-web-test -p 8080:8080 go-web:latest

<em># 检查容器状态</em>
docker ps

<em># 测试API接口</em>
curl http://localhost:8080/ping

执行结果：

# 容器启动
2cbdbdf8a448b64c43f9c005dda4ab79c08e7722ea0d2b558543d6e80cb0814a

# 容器状态
CONTAINER ID   IMAGE                  COMMAND                  CREATED          STATUS          PORTS                                         NAMES
2cbdbdf8a448   go-web:latest          "/app/go-web-app"        6 seconds ago    Up 6 seconds    0.0.0.0:8080->8080/tcp, [::]:8080->8080/tcp   go-web-test

# API测试结果
{"age":18,"name":"xxxxxx","school":"家里蹲大学"}

测试结果：

  • 容器启动成功
  • API 返回正确的 JSON 响应
  • 应用功能正常

Kubernetes 部署

3.1 创建 K8s 配置文件

deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-web-deployment
  labels:
    app: go-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: go-web
  template:
    metadata:
      labels:
        app: go-web
    spec:
      containers:
      - name: go-web
        image: go-web:latest
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "100m"
        livenessProbe:
          httpGet:
            path: /ping
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ping
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: go-web-service
spec:
  selector:
    app: go-web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

3.2 部署应用

<em># 部署应用</em>
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

执行结果：

deployment.apps/go-web-deployment createdservice/go-web-service created

3.3 遇到的第一个坑：镜像拉取失败

问题现象：

kubectl get podsNAME READY   STATUS             RESTARTS   
AGEgo-web-deployment-cfc7cccbd-ckgrp 0/1     ImagePullBackOff   0          24sgo-web-deployment-cfc7cccbd-xfdhq 0/1     ImagePullBackOff   0          24s

检查部署状态：

kubectl get deploymentsNAME READY   UP-TO-DATE   AVAILABLE   AGEgo-web-deployment 0/2     2            0           13s

错误信息：

Failed to pull image "go-web:latest": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/library/go-web:latest"

问题分析：

  • K8s 试图从 Docker Hub 拉取镜像
  • 但我们的镜像是本地构建的
  • Kind 集群无法直接访问宿主机的 Docker 镜像

解决方案：

<em># 将本地镜像加载到kind集群</em>
kind load docker-image go-web:latest --name dev

<em># 验证镜像加载</em>
docker exec dev-control-plane crictl images | grep go-web

执行结果：

<em># 镜像加载</em>
Image: "go-web:latest" with ID "sha256:40a377fbf28772e04665a7ce2cb8ceebbcc6f4da3a6102eeb294627cef56047b" found to be already present on all nodes.

<em># 验证镜像</em>
docker.io/library/go-web                   latest               40a377fbf2877       15.5MB

3.4 遇到的第二个坑：镜像拉取策略

问题现象：
即使镜像已加载到集群，Pods 仍然出现 ImagePullBackOff 错误。

根本原因：

kubectl get deployment go-web-deployment -o yaml | grep imagePullPolicyimagePullPolicy: Always

imagePullPolicy: Always 导致 K8s 总是尝试从远程仓库拉取镜像。

解决方案：

<em># 修改镜像拉取策略为Never</em>
kubectl patch deployment go-web-deployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"go-web","imagePullPolicy":"Never"}]}}}}'

<em># 重启部署</em>
kubectl rollout restart deployment/go-web-deployment

执行结果：

<em># 修改策略</em>
deployment.apps/go-web-deployment patched

<em># 重启部署</em>
deployment.apps/go-web-deployment restarted

<em># 检查Pods状态</em>
NAME                                 READY   STATUS    RESTARTS   AGE
go-web-deployment-7b85d85d64-nd5zp   1/1     Running   0          29s
go-web-deployment-7b85d85d64-vbqjt   1/1     Running   0          19s

3.5 部署成功验证

Pods 状态：

kubectl get podsNAME READY   STATUS    RESTARTS   AGEgo-web-deployment-7b85d85d64-nd5zp 1/1     Running   0          29sgo-web-deployment-7b85d85d64-vbqjt 1/1     Running   0          19s

服务测试：

<em># 端口转发</em>
kubectl port-forward service/go-web-service 8080:80

端口转发输出：

Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
Handling connection for 8080

<em># API测试</em>
curl http://localhost:8080/ping

测试结果：

{"age":18,"name":"xxxxxx","school":"家里蹲大学"}

关键经验总结

1. 网络环境配置

  • 国内环境需要配置合适的镜像源
  • 避免过多镜像源配置导致冲突
  • 使用稳定的网络插件（kindnet vs Calico）

2. 镜像管理

  • 本地镜像需要显式加载到 Kind 集群
  • 正确设置 imagePullPolicy 避免不必要的远程拉取
  • 使用多阶段构建优化镜像大小

3. 部署最佳实践

  • 设置资源限制和健康检查
  • 使用非 root 用户运行容器
  • 配置合适的副本数保证高可用

4. 问题排查方法

  • 使用 kubectl describe pod 查看详细错误信息
  • 检查镜像拉取策略和网络配置
  • 验证集群和镜像状态

配置 Ingress 实现外部访问

下面我们在 Kind Kubernetes 集群中配置 NGINX Ingress Controller 的完整过程，包括遇到的问题、解决方案和最佳实践。

这里我们先注意一下版本信息

  • Kubernetes 版本: v1.23.6
  • Ingress Controller: NGINX Ingress Controller v1.8.1

4.1 Kind 配置

由于我们需要对外暴露服务，我们需要重新调整一下 Kind 集群的配置，我们先来写一个 Kind 配置：

<em># 创建kind-config.yaml</em>
cat > kind-config.yaml << 'EOF'
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP
  - containerPort: 30000
    hostPort: 30000
    protocol: TCP
  - containerPort: 32767
    hostPort: 32767
    protocol: TCP
EOF

4.2 kind 集群创建

<em># 删除现有集群</em>
kind  delete  cluster  --name  dev
<em># 使用新配置创建集群</em>
kind  create  cluster  --name  dev  --config  kind-config.yaml  --image  kindest/node:v1.23.6

执行结果：

Creating cluster "dev" ...
 ✓ Ensuring node image (kindest/node:v1.23.6) 🖼
 ✓ Preparing nodes 📦  
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-dev"

验证集群状态

kubectl  cluster-info
kubectl  get  nodes

4.3 重新部署 Go Web 应用

由于重新创建集群了，现在需要将我们的服务重新部署起来：

<em># 部署应用</em>
kubectl  apply  -f  deployment.yaml
kubectl  apply  -f  service.yaml

<em># 检查状态</em>
kubectl  get  pods
kubectl  get  svc

执行结果：

NAME                                 READY   STATUS    RESTARTS   AGE
go-web-deployment-79bd88cb47-rldr5   1/1     Running   0          11s
go-web-deployment-79bd88cb47-ztcnl   1/1     Running   0          21s
NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
go-web-service   ClusterIP   10.96.195.234   <none>        80/TCP    72m

测试一下 web 服务是否能正常访问：

<em># 端口转发测试</em>
kubectl  port-forward  service/go-web-service  8080:80  &
curl  http://localhost:8080/ping

执行结果：

{"age":18,"name":"xxxxxx","school":"家里蹲大学"}

4.4 Ingress Controller 配置

镜像准备

由于我们 K8S 集群还没配置对外访问，我们需要提前准备一下镜像

<em># 拉取Ingress Controller镜像</em>
docker  pull  registry.k8s.io/ingress-nginx/controller:v1.8.1
docker  pull  registry.k8s.io/ingress-nginx/kube-webhook-certgen:v20230407

<em># 加载镜像到集群</em>
kind  load  docker-image  registry.k8s.io/ingress-nginx/controller:v1.8.1  --name  dev

kind  load  docker-image  registry.k8s.io/ingress-nginx/kube-webhook-certgen:v20230407  --name  dev

执行结果：

Image: "registry.k8s.io/ingress-nginx/controller:v1.8.1" with ID "sha256:825aff16c20cc2c6039fce49bafaa0f510de0f9238da475f3de949adadb9be7f" not yet present on node "dev-control-plane", loading...

Image: "registry.k8s.io/ingress-nginx/kube-webhook-certgen:v20230407" with ID "sha256:7e7451bb70423d31bdadcf0a71a3107b64858eccd7827d066234650b5e7b36b0" not yet present on node "dev-control-plane", loading...

下载配置文件

<em># 下载Ingress Controller配置文件</em>
wget  https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/kind/deploy.yaml  -O  ingress-nginx-kind.yaml

执行结果：

--2025-08-02 16:09:28--  https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/kind/deploy.yaml
Connecting to 127.0.0.1:7890... connected.
Proxy request sent, awaiting response... 200 OK
Length: 15997 (16K) [text/plain]
Saving to: 'ingress-nginx-kind.yaml'
ingress-nginx-kind.yaml                     100%[==========================================================================================>]  15.62K  --.-KB/s    in 0.02s

修改配置文件

需要修改三个关键配置：

  1. 去掉镜像的 sha256 部分
  2. 修改镜像拉取策略为 Never
  3. 确保节点选择器正确

需要将镜像拉取策略改为 Never，并且去掉镜像的 sha256 部分。
例如：imagePullPolicy: Never

<em># 修改镜像拉取策略</em>
imagePullPolicy: IfNotPresent
<em># 改为：</em>
imagePullPolicy: Never

<em># 去掉镜像的sha256部分（手动编辑）</em>
<em># image: registry.k8s.io/ingress-nginx/controller:v1.8.1@sha256:e5c4824e7375fcf2a393e1c03c293b69759af37a9ca6abdb91b13d78a93da8bd</em>
<em># 改为：</em>
<em># image: registry.k8s.io/ingress-nginx/controller:v1.8.1</em>

<em># 将以下行：</em>
<em># image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v20230407@sha256:543c40fd093964bc9ab509d3e791f9989963021f1e9e4c9c7b6700b02bfb227b</em>
<em># 改为：</em>
<em># image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v20230407</em>

节点标签配置

<em># 给节点添加必要的标签</em>
kubectl  label  node  dev-control-plane  ingress-ready=true

4.5 部署 Ingress Controller

准备好配置后，现在来部署 Ingress

kubectl  apply  -f  ingress-nginx-kind.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

验证部署状态

<em># 检查Pod状态</em>
kubectl  get  pods  -n  ingress-nginx

<em># 检查Job状态</em>
kubectl  get  jobs  -n  ingress-nginx

执行结果：

NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-t6cf9        0/1     Completed   0          6s
ingress-nginx-admission-patch-xwfdv         0/1     Completed   1          6s
ingress-nginx-controller-76789fd998-9nfdl   1/1     Running     0          6s

NAME                             COMPLETIONS   DURATION   AGE

ingress-nginx-admission-create   1/1           3s         25s

ingress-nginx-admission-patch    1/1           4s         25s

4.6 部署 Ingress

创建 Ingress 资源配置

<em># ingress.yaml</em>
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: go-web-ingress
 annotations:
 nginx.ingress.kubernetes.io/rewrite-target: /
 nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
 ingressClassName: nginx
 rules:
- host: go-web.local
 http:
 paths:
- path: /
 pathType: Prefix
 backend:
 service:
 name: go-web-service
 port:
 number: 80

部署 Ingress

kubectl  apply  -f  ingress.yaml

执行结果：

ingress.networking.k8s.io/go-web-ingress created

验证 Ingress 状态

kubectl  get  ingress
kubectl  describe  ingress  go-web-ingress

执行结果：

NAME            CLASS   HOSTS         ADDRESS   PORTS   AGE
go-web-ingress  nginx   go-web.local             80      10s

4.6 测试外部访问

配置 hosts 文件
这里我们先给内部访问添加一下域名：

<em># 配置本地hosts</em>
echo  "127.0.0.1 go-web.local" >> /etc/hosts

测试访问

<em># 测试API访问</em>
curl  http://go-web.local/ping

执行结果：

{"age":18,"name":"xxxxxx","school":"家里蹲大学"}

这样内部测试就没有问题啦，接下来我们要看看外部公网访问，你可能需要检查一下防火墙 80 端口可以访问，这里我使用本地的 PC 直接公网 ip 进行请求

PowerShell 7.5.2
PS C:\Users\SZ24-Storm006> curl http://14.159.10.1/ping
{"age":18,"name":"xxxxxx","school":"家里蹲大学"}
PS C:\Users\SZ24-St

完美！这样我们就完成了从服务器 K8S 环境搭建，创建集群，镜像构建，服务部署，网关部署，对外提供服务整个流程，恭喜你，可以在自己的服务器上学习或者部署一些简单的应用了，当然如果你觉得这就完了，那就草率了，下面是我在整个流程中遇到的问题及其解决方案

4.7 遇到的问题及其解决方案

问题 1：镜像拉取失败

现象：

Failed to pull image "registry.k8s.io/ingress-nginx/controller:v1.8.1": rpc error: code = Unknown desc = failed to pull and unpack image

原因：集群内部无法访问外网，镜像拉取失败
解决方案：

  1. 在宿主机拉取镜像
  2. 使用 kind load docker-image 加载到集群
  3. 设置 imagePullPolicy: Never

问题 2：镜像版本不匹配

现象：

ErrImageNeverPull: Container image "registry.k8s.io/ingress-nginx/kube-webhook-certgen:v20230407@sha256:..." is not present

原因：配置文件中的镜像包含 sha256，但集群中的镜像没有
解决方案：

  1. 去掉镜像名称中的 @sha256:... 部分
  2. 确保镜像版本一致

问题 3：节点选择器不匹配

现象：

0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector

原因：Controller Pod 需要 ingress-ready=true 标签
解决方案：

kubectl  label  node  dev-control-plane  ingress-ready=true

问题 4：Job 镜像拉取策略不可变

现象：

The Job "ingress-nginx-admission-create" is invalid: spec.template: Invalid value: field is immutable

原因：Job 创建后 Pod 模板不可修改
解决方案：

  1. 删除 Job
  2. 修改 YAML 文件中的镜像拉取策略
  3. 重新部署
    关键配置要点：
    镜像管理:
  • 使用 imagePullPolicy: Never 避免网络拉取
  • 确保镜像版本匹配
  • 去掉 sha256 标识符

节点配置:

  • 添加 ingress-ready=true 标签
  • 配置正确的端口映射

网络配置:

  • 使用 NodePort 类型的 Service
  • 配置 hosts 文件进行域名解析

问题 5：公网无法访问服务

我遇到一个比较复制的问题，公网无法访问服务，之前我们在服务器本地可以继续访问服务，所以服务器宿主机到 go-web 服务的整个链路肯定是没有问题的，简单画了一个网络请求流程图：

Kind 搭建 K8s 集群并部署 Go Web 应用
当前状态
  • ✅ 本地访问: 正常 (localhost:80)
  • ❌ 公网访问: 失败 (14.159.10.1:80)
可能原因
  1. 云服务商安全组: 80 端口未开放
  2. 网络路由: 公网 IP 路由问题
  3. NAT 配置: 端口转发规则缺失
    下面我们一个一个的来排查：
检查 80 端口

云控制台检查确定 80 端口是开放的

公网路由

直接在服务器本地运行 go-web 服务：

root@lavm-641m9i7vom:~/project/go-web<em># tree</em>
.
├── Dockerfile
├── go.mod
├── go.sum
└── main.go

0 directories, 4 files
root@lavm-641m9i7vom:~/project/go-web<em># go run main.go</em>
[GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.

[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
 - using env:   export GIN_MODE=release
 - using code:  gin.SetMode(gin.ReleaseMode)

[GIN-debug] GET    /ping                     --> main.Pong (3 handlers)
[GIN-debug] [WARNING] You trusted all proxies, this is NOT safe. We recommend you to set a value.
Please check https://pkg.go.dev/github.com/gin-gonic/gin<em>#readme-don-t-trust-all-proxies for details.</em>
[GIN-debug] Listening and serving HTTP on 0.0.0.0:8080

开放 8080 端口的防火墙后，在本地 pc 进行访问：

PS C:\Users\SZ24-Storm006> curl http://14.159.10.1:8080/ping
{"age":18,"name":"xxxxxx","school":"家里蹲大学"}
PS C:\Users\SZ24-Storm006>

可以看到整个公网 ip 到我们的服务器都是正常的，那问题就出现在服务器上 端口转发规则缺失

NAT 配置

宿主机网络：

<em># 网络接口</em>
eth0: 172.16.0.8/16 (内网IP)
br-ebc08f0aedad: 172.18.0.1/16 (Docker网络)

<em># 路由</em>
default via 172.16.0.1 dev eth0
172.18.0.0/16 dev br-ebc08f0aedad
  • 网络接口: eth0 (172.16.0.8/16)
  • Docker 网络: br-ebc08f0aedad (172.18.0.1/16)
  • 端口监听: 0.0.0.0:80 (docker-proxy)

检查一下 80 端口：

netstat -tlnp | grep :80
<em># 输出: tcp 0.0.0.0:80 0.0.0.0:* LISTEN 180819/docker-proxy</em>
  • 进程: docker-proxy (PID: 180819)
  • 监听: 0.0.0.0:80 (所有接口)
  • 转发: 到 Ingress Controller 容器

看上去宿主机到 docker 容器的配置页没有问题，排查一下  iptables规则检查:

<em># 检查iptables规则</em>
iptables  -L  -n  | grep  -E  "(DROP|REJECT)"
<em># 结果: 发现多个DROP规则</em>
<em># 检查DOCKER链</em>
iptables  -L  DOCKER  -n  --line-numbers
<em># 结果:</em>
<em># 5    ACCEPT     tcp  --  0.0.0.0/0            172.18.0.2           tcp dpt:80</em>
<em># 6    DROP       all  --  0.0.0.0/0            0.0.0.0/0</em>
<em># 7    DROP       all  --  0.0.0.0/0            0.0.0.0/0</em>

发现关键问题: DOCKER 链中 80 端口的 ACCEPT 规则被后面的 DROP 规则覆盖
解决方案：

<em># 删除DOCKER链中的DROP规则</em>
iptables  -D  DOCKER  6
iptables  -D  DOCKER  6
<em># 检查DOCKER-ISOLATION-STAGE-2链</em>
iptables  -L  DOCKER-ISOLATION-STAGE-2  -n
<em># 结果: 发现更多DROP规则</em>
<em># 删除DOCKER-ISOLATION-STAGE-2链中的DROP规则</em>
iptables  -D  DOCKER-ISOLATION-STAGE-2  1
iptables  -D  DOCKER-ISOLATION-STAGE-2  1

然后我重新从我的 pc 进行请求，还是不行，还得进行排查，清理 iptables：

<em># 完全清空iptables规则</em>
iptables  -F
iptables  -t  nat  -F
iptables  -t  mangle  -F
iptables  -X

再请求试试：

PowerShell 7.5.2
PS C:\Users\SZ24-Storm006> curl http://14.159.10.1/ping
{"age":18,"name":"xxxxxx","school":"家里蹲大学"}

总结一下：

根本原因

iptables 规则冲突导致 80 端口无法正常访问：

  1. Docker 自动生成的 iptables 规则中有 DROP 规则
  2. 这些 DROP 规则覆盖了 ACCEPT 规则
  3. 导致外部流量无法到达 Ingress Controller

解决方案

清空冲突的 iptables 规则，让网络流量正常转发。

验证结果

  • ✅ 本地访问: curl http://localhost/ping – 正常
  • ✅ 公网访问: curl http://14.159.10.1/ping – 正常
  • ✅ Ingress Controller: 正常工作
  • ✅ go-web 服务: 正常运行

结论

通过这次实践，成功搭建了 Kind Kubernetes 集群并部署了 Go Web 应用。过程中遇到的主要问题都与网络环境和镜像管理相关，通过正确的配置和策略设置，最终实现了稳定的部署，这个流程为后续的容器化应用部署提供了完整的参考模板，也为更复杂的 Kubernetes 应用管理奠定了基础。

The post Kubernetes集群搭建并部署Web应用 appeared first on 原立方.

]]> https://www.atomic-cube.cn/k8s%e9%9b%86%e7%be%a4%e6%90%ad%e5%bb%ba%e5%b9%b6%e9%83%a8%e7%bd%b2web%e5%ba%94%e7%94%a8/feed/ 0