GitLab中Kubernetes前端部署失败求助:容器无资源请求被准入Webhook拦截
解决GitLab部署Kubernetes时的前端准入错误与代码生效问题
一、先搞定当前前端部署的准入控制报错
你碰到的这个错误是集群里的Gatekeeper准入控制器在强制执行资源请求规则——它要求所有容器必须定义 resources.requests,但你的前端Deployment里只配置了 resources.limits,缺了requests部分。
修改你的Deployment配置,给容器补上requests字段就行,建议设置成比limits小的合理值,比如:
apiVersion: apps/v1 kind: Deployment metadata: name: IE599-dashboard namespace: IE599-dev labels: app: IE599-dashboard spec: replicas: 1 selector: matchLabels: app: IE599-dashboard template: metadata: labels: app: IE599-dashboard spec: containers: - env: - name: API_URL value: https://IE599-api-dev.app.com/api name: IE599-dashboard image: registry.app.com/IE599/IE599-dashboard:$CI_COMMIT_SHORT_SHA imagePullPolicy: Always resources: requests: # 新增这部分配置 cpu: '50m' memory: 128Mi limits: cpu: '100m' memory: 256Mi securityContext: runAsNonRoot: true runAsUser: 1000 imagePullSecrets: - name: regcred-dashboard
requests是K8s给容器分配的最小资源,limits是容器能用到的最大资源,Gatekeeper的这个规则是为了避免集群资源被不合理占用,补上之后就能通过校验了。
二、解决之前代码变更(密码更新、Liquibase新表)不生效的问题
从你的描述看,删除dev命名空间重新部署后后端成功了,但之前的变更没生效,大概率是这几个原因:
1. 旧Pod没被正确替换
如果之前的Deployment用的是固定镜像标签(比如latest),K8s会认为镜像没变化,不会重启Pod。不过你现在用的是$CI_COMMIT_SHORT_SHA(每次提交的短哈希),理论上能触发滚动更新,但可以确认下:
- 手动触发GitLab部署时,
$CI_COMMIT_SHORT_SHA是不是对应最新提交的哈希 - 部署后用
kubectl get pods -n IE599-dev看后端Pod的创建时间,是不是刚生成的新Pod
2. Liquibase执行异常
后端Pod启动了但新表没创建,得进Pod里看Liquibase的日志找问题:
# 把<backend-pod-name>换成你的后端Pod实际名称 kubectl exec -n IE599-dev <backend-pod-name> -- tail -f /path/to/liquibase/logs
常见坑点:
- Liquibase配置文件是不是指向了正确的数据库
- 数据库账号有没有创建表的权限
- 变更集(changelog)有没有语法错误,或者有没有被正确加载
3. 前端缓存问题(如果密码是前端配置项)
如果密码是前端配置的一部分,浏览器可能缓存了旧的静态资源。可以试试:
- 确认前端构建时是否给资源加了版本哈希(一般Webpack这类工具会自动处理)
- 用浏览器隐私窗口测试,或者手动清除缓存
总结
先把前端Deployment的resources.requests补上,解决Gatekeeper的报错,完成部署。然后针对之前的代码变更问题,从Pod更新状态、Liquibase日志、前端缓存这几个方向排查,应该就能找到根源了。
内容的提问来源于stack exchange,提问作者Mistic1987PL
相关产品推荐
相关产品推荐

