Gitlab-第四天-CD到k8s集群的坑
rbac要设置为true,他会自动创建一个根据你配置的 serviceAccountName,进行创建。上面的role配置,你可以edit修改你的role的yaml进行覆盖即可,不用重启pod.上面是正确的role配置,特别是你要部署的工作负责是deployments,并且会根据你配置的rule配置的权限生成role-权限,一、.gitlab-ci.yml #CD到k8s集群的。上面这个配置是错的
一、.gitlab-ci.yml #CD到k8s集群的
stages:
- deploy-test
build-image-deploy-test:
stage: deploy-test
image: bitnami/kubectl:latest # 使用一个包含 kubectl 工具的镜像
tags:
- k8s
script:
- ls -al
- kubectl apply -f deployment.yaml # 根据实际情况替换为你的 Kubernetes 部署配置文件路径
二、部署时的RBAC权限
部署的报错:
helm的配置:
rbac要设置为true,他会自动创建一个根据你配置的 serviceAccountName,进行创建。
并且会根据你配置的rule配置的权限生成role-权限,
上面这个配置是错的哈,不要看。看我下面的role:
验证:
kubectl get sa -n gitlab-runer
kubectl get role -n gitlab-runer
kubectl get rolebinding -n gitlab-runer
他运行默认会用default,你可以再helm的values.yaml中定义runer使用的sa名称:
这个sa你自己管理权限,就会覆盖你自己创建的sa。
注意权限问题,同时如果要用这个sa拉取仓库的配置,要配置secret:
三、解决办法
给权限撒~
rules:
- apiGroups:
- ""
resources:
- events
- configmaps
- pods
- pods/attach
- secrets
- services
- deployments
- pods/exec
verbs:
- apply
- get
- list
- watch
- create
- patch
- update
- delete
- apiGroups:
- apps
resources:
- deployments
verbs:
- apply
- create
- patch
- delete
- list
- watch
- apiGroups:
- apps
resources:
- deployments
verbs:
- get
- list
kind: List
metadata:
resourceVersion: ""
上面是正确的role配置,特别是你要部署的工作负责是deployments,你需要list和get权限。
上面的role配置,你可以edit修改你的role的yaml进行覆盖即可,不用重启pod.
同时需要你修改了runer的配置,通过helm配置时要重启pod才能生效。
更多推荐
所有评论(0)