Codex 配 TaoToken走通 K8S Ingress 安装的 mandatory.yaml 步骤这篇记录一个很容易被教程带偏的场景K8S 里按 mandatory.yaml 安装 Ingresskubectl apply看起来成功curl却返回 404。TaoToken 官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 这里用 TaoToken 给 Codex 提供 API Key 和模型通道让 Codex 去检查、执行并解释这套安装步骤。TaoToken 只负责 Codex 的 API 通道Ingress 的 yaml、RBAC、Service、Pod 仍然走 K8S 原生流程。原问题与场景mandatory.yaml 装完 Ingress 后 curl 返回 404很多 K8S Ingress 安装教程的流程都很短下载mandatory.yaml执行kubectl apply -f ./mandatory.yaml然后kubectl get pods -n ingress-nginx最后用curl访问某个 IP。原文里提到返回 404 表示安装成功。这个结论本身没错但前提是你访问到的是 ingress-nginx controller 的入口而不是随便一个 Service并且 404 来自 nginx default backend而不是 K8S API、kubelet 或被防火墙拦截后的错误页。实际排障时curl返回 404 可能对应三种完全不同的状态第一种ingress-nginx controller 已经 RunningService 也暴露成功但因为还没有创建 Ingress 规则nginx 找不到匹配的 host/path于是返回 404。这时 404 确实是“安装成功”的信号下一步应该创建测试 Ingress。第二种你访问的地址根本不是 ingress-nginx controller。比如把 ClusterIP 当成外部地址或者 NodePort 填错或者 LoadBalancer 没有 EXTERNAL-IP请求落到别的服务上也可能返回 404。第三种mandatory.yaml里的 controller 版本太旧和当前 K8S 集群不兼容。Pod 没有正常 Running或者 admission webhook、RBAC、IngressClass 有问题。此时kubectl apply可能显示 created但实际并没有可用 controllercurl的结果也就没有参考价值。所以本文的视角不是再抄一遍安装命令而是把 Codex 接到 TaoToken 的模型通道上让 Codex 成为能读文件、核对版本、执行kubectl、查看 Pod 日志和解释 404 的助手。Codex 负责推理和命令编排TaoToken 负责模型 API 请求K8S 集群仍然由本机kubectl和 kubeconfig 控制。TaoToken 前置给 Codex 准备 API Key 与接入地址先到 TaoToken 官网创建 Key。打开https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content登录后进入控制台在 API Keys 页面创建一个新的 Key。这个 Key 后面会写进 Codex 的环境变量不要直接提交到 Git 仓库也不要贴到公开的博客评论区。创建完成后你会得到类似YOUR_API_KEY的字符串保存到本地密码管理器。TaoToken 的 API 地址按文档使用https://taotoken.net/api注意这个 API 地址不要额外拼接 UTM 参数它只用于 Codex 的base_url。如果你需要确认 Key 管理入口可以用这个链接API Keys接入参数和字段说明看接入文档接入文档这里要区分两件事TaoToken 的 Key 是给 Codex 调模型用的不是 K8S 的 kubeconfig。Codex 能不能执行kubectl取决于你本机的 kubeconfig、RBAC 权限和当前 contextTaoToken 不会绕过 K8S 认证也不会替代kubectl。换句话说模型通道和集群通道是两条线配置时不要混在一起。在终端先确认 Codex 可用codex --version which codex如果codex命令不存在先按 Codex 官方方式安装或更新。然后设置环境变量。Linux/macOSexport TAOTOKEN_API_KEYYOUR_API_KEYWindows PowerShell$env:TAOTOKEN_API_KEYYOUR_API_KEY为了让新终端也生效可以把 export 写入~/.bashrc或~/.zshrcecho export TAOTOKEN_API_KEYYOUR_API_KEY ~/.zshrc source ~/.zshrcCodex config.toml 可复制配置与启动验证Codex 的自定义模型提供方一般写在~/.codex/config.toml。下面是一份可复制的 TaoToken 接入配置重点是model_provider、base_url、env_key和wire_api# ~/.codex/config.toml model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat如果你的 Codex 版本或 TaoToken 文档要求使用 Responses API把最后一行改成wire_api responses如果控制台提示某些模型只兼容 Chat Completions就保留wire_api chatmodel的值不要死记应该换成 TaoToken 控制台里实际可用的模型 ID。上面写gpt-5-codex只是 Codex 场景下常见的示例真实可用模型以你的账号和控制台为准。配置保存后先做一次最小验证codex exec 只回复 OK不要执行命令如果返回OK说明 Codex 已经通过 TaoToken 的 API 通道拿到了模型响应。如果这一步报错先不要继续折腾 K8S因为后面让 Codex 读mandatory.yaml也会失败。常见错误包括401Key 无效或环境变量没加载。404base_url写错或者路径被重复拼接。400模型 ID 不存在或者wire_api与模型接口不匹配。连接超时本机网络或代理环境问题不要和 K8S 的 404 混在一起排查。验证通过后进入一个你准备执行 K8S 命令的目录例如mkdir -p ~/k8s-ingress cd ~/k8s-ingress codex在 Codex 交互界面里可以先用一句提示词确认它知道当前任务边界我会让你协助排查 K8S Ingress 安装。你负责读取文件、给出 kubectl 命令、解释输出但不要修改 kubeconfig不要执行删除操作。TaoToken 只是模型 API 通道K8S 操作仍由我确认后执行。在 Codex 中走通 mandatory.yaml版本核对、apply、Running 与 404 验证这一步开始进入 K8S 原生流程。先让 Codex 检查当前集群上下文和版本不要一上来就kubectl apply。kubectl config current-context kubectl cluster-info kubectl version --short kubectl get nodes -o wide把输出贴给 Codex或者让 Codex 自己执行。然后下载mandatory.yamlwget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.18.0/deploy/mandatory.yaml -O mandatory.yaml如果本机没有wget用curlcurl -L -o mandatory.yaml https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.18.0/deploy/mandatory.yaml注意原文使用的nginx-0.18.0是很旧的 ingress-nginx 版本。它对应老版本 K8S 的 API 和 RBAC放到新集群里可能直接因为extensions/v1beta1、rbac.authorization.k8s.io/v1beta1、IngressClass 缺失等问题失败。所以下载完成后先让 Codex 做静态检查不要直接 apply请读取当前目录下的 mandatory.yaml。列出其中所有 apiVersion、kind、namespace、Service 类型、container image、RBAC 资源和 IngressClass 相关内容。结合前面的 kubectl version 输出判断这个 ingress-nginx controller 版本是否兼容当前 K8S 集群。如果存在已废弃 API、缺失的 IngressClass 或 Service 暴露方式不匹配请先给出替换版本建议和需要修改的字段不要直接 apply。Codex 检查后通常会给出几类结论如果集群较老mandatory.yaml里的 API 版本可能还能用。如果集群是 v1.22 之后很多旧 API 已移除需要换成 ingress-nginx 新版本的deploy.yaml。如果使用新版本 ingress-nginx命名空间可能仍是ingress-nginx但资源名可能是ingress-nginx-controllerService 类型可能是LoadBalancer或NodePort。如果需要 IngressClass后续 Ingress 规则要带ingressClassName: nginx。确认没有明显版本冲突后再执行kubectl apply -f ./mandatory.yaml然后检查 Pod 是否 Runningkubectl get pods -n ingress-nginx -o wide kubectl get svc -n ingress-nginx如果 Pod 名字不确定先用kubectl get pods -n ingress-nginx看完整名称再 describekubectl describe pod -n ingress-nginx pod-name kubectl logs -n ingress-nginx pod-name --tail100等待 Pod 进入 Running 和 Readykubectl get pods -n ingress-nginx -w如果长时间不是 Running把describe和logs的输出交给 Codex让它按 Events 和日志判断是镜像拉取、RBAC、探针、admission webhook 还是版本兼容问题。Pod Running 后看 Service 暴露方式kubectl get svc -n ingress-nginx如果是NodePort取出形如80:31234/TCP的端口然后访问节点 IPcurl -I http://节点IP:NodePort如果是LoadBalancer且有 EXTERNAL-IPcurl -I http://EXTERNAL-IP如果返回HTTP/1.1 404 Not Found Server: nginx那么大概率说明 ingress-nginx controller 已经接管流量404 来自默认后端因为还没有配置 Ingress 规则。这正对应原文里“返回 404 表示安装成功”的现象。为了进一步确认可以创建一个最小测试服务、Service 和 Ingress。新集群 Ingress 示例apiVersion: apps/v1 kind: Deployment metadata: name: demo namespace: default spec: replicas: 1 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: - name: demo image: nginx:alpine ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: demo namespace: default spec: selector: app: demo ports: - port: 80 targetPort: 80 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo namespace: default spec: ingressClassName: nginx rules: - host: demo.local http: paths: - path: / pathType: Prefix backend: service: name: demo port: number: 80应用后访问curl -H Host: demo.local http://节点IP:NodePort/如果返回 nginx 欢迎页说明 Ingress 规则、Service、Endpoint 和 controller 整条链路都通了。旧版 ingress-nginx 如果不支持ingressClassName则改用 annotationmetadata: annotations: kubernetes.io/ingress.class: nginxmandatory.yaml 安装 Ingress 的常见错排查围绕mandatory.yaml和curl 404常见问题可以按下面顺序排查。kubectl apply成功但 Pod 不 Runningcreated不代表可用。先看kubectl get pods -n ingress-nginx kubectl describe pod -n ingress-nginx pod-name kubectl logs -n ingress-nginx pod-name --tail200如果是ImagePullBackOff检查镜像地址、网络和节点架构。旧mandatory.yaml可能引用老镜像仓库放到新环境拉取失败。如果是CrashLoopBackOff重点看 RBAC 权限、admission webhook 证书、启动参数和集群 DNS。curl返回 404但不确定是不是成功看响应头是否包含Server: nginx。如果 404 页面是 ingress-nginx 的默认后端说明 controller 已经工作。如果连接被拒绝、超时或者返回的是其他服务页面就不是“安装成功”。先确认你访问的是 controller 的 NodePort、LoadBalancer IP 或 hostNetwork 端口而不是普通 ClusterIP。Service 没有外部入口kubectl get svc -n ingress-nginx如果只显示ClusterIP外部curl节点 IP 是到不了 controller 的。裸金属环境常见做法是改NodePort、启用hostNetwork或者部署 MetalLB 给 LoadBalancer 分配 IP。Codex 可以根据当前 Service YAML 给出修改建议但执行修改仍要你确认。旧mandatory.yaml与 K8S 版本不兼容让 Codex 扫描 YAML 中的apiVersion。如果看到extensions/v1beta1、rbac.authorization.k8s.io/v1beta1等旧版本而集群已经是较新版本就不要硬套。正确做法是换 ingress-nginx 官方对应 K8S 版本的 deploy 文件或者按官方迁移说明调整 API 版本。mandatory.yaml这个文件名可以保留在你的操作记录里但实际资源内容要以兼容版本为准。Ingress 规则不生效如果 controller 正常但访问业务域名不是 404 而是 503检查 Service 的 Endpointskubectl get endpoints -n default demo如果没有 Endpoints说明 Service 没有选中 Pod或者 Pod 没 Ready。再检查 Ingress 的 host 是否和请求的Host一致path 是否匹配pathType是否正确ingressClassName是否缺失。Codex 调 TaoToken 失败与 K8S 404 混淆K8S 的 404 是 Ingress controller 返回的TaoToken 的 404 是 API 路径或模型名不对。判断方法很简单curl -I http://Ingress地址返回 404 且带 nginx 头属于 K8Scodex exec报 404则检查base_url是否为https://taotoken.net/api、model是否存在、wire_api是否匹配。401通常看TAOTOKEN_API_KEY是否在当前终端生效。语义一致的 CTAKey、文档、模型验证与 Coding Plan如果你已经能让 Codex 通过 TaoToken 正常回答并且mandatory.yaml的 Pod 也进入 Running那么接下来通常有两种需求一种是继续做 K8S Ingress 排障和接入配置另一种是把 Codex 长期放进日常运维、脚本检查和 Agent 工作流里。需要创建或轮换 Key去 API KeysAPI Keys需要核对config.toml、base_url、wire_api和模型字段去接入文档接入文档只想先验证模型通道是否可用去模型对话页发一条消息模型对话如果你准备让 Codex 长期参与 K8S 配置检查、Ingress 规则生成前的审阅、日志归纳和 Agent 任务可以看 Coding PlanCoding Plan控制台入口控制台最后再强调一次边界TaoToken 负责 Codex 的 API 通道mandatory.yaml的下载、版本核对、kubectl apply、Pod Running 检查和curl 404验证仍然由 K8S 原生流程完成。把这两条链路分开排障时就不会把模型请求错误和 Ingress 安装问题混在一起。