You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

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

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.04.28 21:47:41