deployment 和 service 是部署 go graphql 应用最核心的两个 kubernetes 资源：deployment 管理 pod 副本与生命周期，service 提供稳定网络入口；需确保端口一致、探针合理、敏感配置用 secret，且 go 服务正确注册 /graphql 路由并监听所有接口。
Deployment 和 Service 是部署提供 GraphQL 接口的 Go 应用最核心的两个资源对象。你不需要额外的网关或中间层，只要 Go 服务本身暴露了 GraphQL endpoint（比如 /graphql），Kubernetes 就能原生支持。
Go 服务必须实现标准 HTTP 处理器并监听正确端口
Hasura 或 TypeGraphQL 类服务是开箱即用的 GraphQL 引擎，但如果你自己用 Go 写 GraphQL 接口（例如基于 graphql-go、gqlgen 或 neelance/graphql-go），关键点在于：服务必须启动一个标准 http.Server，且路由注册明确指向 GraphQL handler。
常见错误现象：
- Pod 启动后立即 CrashLoopBackOff —— 很可能是
main()没有调用http.ListenAndServe，或端口与containerPort不一致 - Service 可访问但返回 404 —— GraphQL 路由未注册到根
http.DefaultServeMux，或用了自定义http.ServeMux却没传给ListenAndServe
实操建议：
- 确保
main.go中至少有一行类似http.Handle("/graphql", handler)，且handler是合法的http.Handler - 监听端口必须和 Deployment YAML 中的
containerPort严格一致（如都设为8080） - 不要在代码里硬编码
localhost或127.0.0.1；绑定地址应为:8080（即空 host，默认监听所有接口）
Deployment 配置要启用健康检查与资源限制
Kubernetes 不会自动知道你的 Go GraphQL 服务是否“真正就绪”，必须显式配置探针。否则流量可能打到尚未加载 schema 的 Pod 上，导致请求失败。
实操建议：
-
livenessProbe：用httpGet请求/health，路径需在 Go 服务中实现（返回 200 即可） -
readinessProbe：同样用httpGet，但建议额外加一个轻量级 GraphQL 查询（如{ __typename }）验证引擎是否初始化完成 - 务必设置
initialDelaySeconds：gqlgen 启动时需解析 schema、连接数据库，延迟至少15秒再开始探测 - 资源
requests/limits建议设为memory: "256Mi"、cpu: "100m"起步；GraphQL 解析较吃内存，OOMKill 是常见原因
Service 类型选 ClusterIP 还是 LoadBalancer？
取决于你的 GraphQL 服务是否需要被集群外访问。内部微服务间调用用 ClusterIP；前端或外部客户端直连则需 LoadBalancer（云厂商）或 NodePort（裸金属）。
容易踩的坑：
- 误用
type: ExternalIPs—— 已废弃，不生效 - Service 的
selector标签和 Deployment 的podTemplate.labels不匹配，导致 endpoints 为空（kubectl get endpoints查看） - 没开放
targetPort对应的容器端口，防火墙或云安全组拦截了入向流量
示例关键片段：
apiVersion: v1
kind: Service
metadata:
name: graphql-service
spec:
selector:
app: graphql-go # 必须和 Deployment 中的 pod labels 一致
ports:
- protocol: TCP
port: 4000 # Service 暴露的端口（外部访问用）
targetPort: 8080 # 容器内实际监听的端口
type: LoadBalancer
敏感配置（如数据库 URL、Admin Secret）必须用 Secret
GraphQL 服务通常依赖 Postgres，并可能启用 HASURA_GRAPHQL_ADMIN_SECRET 或自定义鉴权密钥。这些绝不能写死在 Deployment YAML 里，也不能用 ConfigMap 存明文。
为什么这样做：
-
Secret数据默认 base64 编码（虽非加密，但避免 kubectl get configmap 直接泄露） - 挂载为文件比注入环境变量更安全：环境变量可能被
ps aux或日志误采 - Kubernetes 1.24+ 默认禁止从
serviceAccount自动挂载 token，但 Secret 挂载不受影响
实操建议：
- 创建 Secret：
kubectl create secret generic graphql-env --from-literal=DATABASE_URL="postgres://..." --from-literal=ADMIN_SECRET="xxx" - 在 Deployment 中通过
envFrom: [{secretRef: {name: graphql-env}}]注入，或用volumes挂载为文件 - 确认 Go 应用读取逻辑兼容：比如从
os.Getenv("DATABASE_URL")改为从文件读取时需调整初始化顺序
真正卡住人的地方往往不是部署命令本身，而是 Go 服务启动逻辑和 Kubernetes 探针之间的节奏差——比如 schema 加载耗时 22 秒，但 readiness probe 在 10 秒就开始发请求，结果所有流量都被标记为“未就绪”。这个时间窗口必须对齐。
