创建集群范围的服务帐户以连接 gitlab
Create cluster wide service account to connect with gitlab
我有一个自托管的 gitlab,我想部署应用程序。我正在尝试部署一个跑步者,以便 gitlab 可以连接到 kubernetes 集群。我的 kubernetes 集群启用了 RBAC。
这是我的 gitlab-ci.yml 用于跑步者:
services:
- docker:18-dind
stages:
- deploy
deploy:
image:
name: thorstenhans/helm3:latest
entrypoint: ["/bin/sh", "-c"]
stage: deploy
environment:
name: staging
kubernetes:
namespace: runners
script:
- echo ${CI_JOB_NAME}
- helm version
- kubectl version
- helm repo add gitlab https://charts.gitlab.io/
- helm install gitlab/gitlab-runner --version 0.20.0 -f values.yml
这是 values.yml 文件:
## The GitLab Server URL (with protocol) that want to register the runner against
## ref: https://docs.gitlab.com/runner/commands/README.html#gitlab-runner-register
##
gitlabUrl: https://gitlab.mydomain.com/
## The registration token for adding new Runners to the GitLab server. This must
## be retrieved from your GitLab instance.
## ref: https://docs.gitlab.com/ee/ci/runners/
##
runnerRegistrationToken: "registration code here"
## Set the certsSecretName in order to pass custom certificates for GitLab Runner to use
## Provide resource name for a Kubernetes Secret Object in the same namespace,
## this is used to populate the /etc/gitlab-runner/certs directory
## ref: https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates
##
#certsSecretName:
## Configure the maximum number of concurrent jobs
## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
concurrent: 10
## Defines in seconds how often to check GitLab for a new builds
## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
checkInterval: 30
## For RBAC support:
rbac:
create: false
## Run the gitlab-bastion container with the ability to deploy/manage containers of jobs
## cluster-wide or only within namespace
clusterWideAccess: true
## If RBAC is disabled in this Helm chart, use the following Kubernetes Service Account name.
##
# serviceAccountName: default
## Configuration for the Pods that the runner launches for each new job
##
runners:
## Default container image to use for builds when none is specified
##
image: ubuntu:18.04
## Run all containers with the privileged flag enabled
## This will allow the docker:stable-dind image to run if you need to run Docker
## commands. Please read the docs before turning this on:
## ref: https://docs.gitlab.com/runner/executors/kubernetes.html#using-docker-dind
##
privileged: false
## Namespace to run Kubernetes jobs in (defaults to 'default')
##
# namespace:
## Build Container specific configuration
##
builds:
# cpuLimit: 200m
# memoryLimit: 256Mi
cpuRequests: 100m
memoryRequests: 128Mi
## Service Container specific configuration
##
services:
# cpuLimit: 200m
# memoryLimit: 256Mi
cpuRequests: 100m
memoryRequests: 128Mi
## Helper Container specific configuration
##
helpers:
# cpuLimit: 200m
# memoryLimit: 256Mi
cpuRequests: 100m
memoryRequests: 128Mi
如何为 gitlab 创建服务帐户,以便它可以在整个集群范围内部署应用程序?
你可以在 gitlab documentation.
中找到这些信息
Enabling RBAC support
If your cluster has RBAC enabled, you can choose to either have the chart create its own service account or provide one on your own.
To have the chart create the service account for you, set rbac.create to true:
rbac:
create: true
To use an already existing service account, use:
rbac:
create: false
serviceAccountName: your-service-account
因此您必须将 values.yaml 更改为
rbac:
create: false
clusterWideAccess: true
serviceAccountName: your-service-account
有rbac和服务账号的相关文档。
- https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions
- https://unofficial-kubernetes.readthedocs.io/en/latest/admin/authorization/rbac/
- https://www.magalix.com/blog/kubernetes-authorization
还有另一个 Whosebug post 和一个 gitlab 问题,应该有助于为您的用例创建服务帐户。
您可以使用:
End goal: Execute all helm operations as GitLab CI yml in the connected
cluster repo (vs running on server).
- 集群管理项目模板
参见 GitLab 14.0(2021 年 6 月)
Cluster management project template
In this release, we are moving away from the CI/CD template-based approach for cluster management.
Cluster management is the ability to manage Kubernetes clusters to improve application availability running on a cluster.
The old method hides too much of the logic, restricts customizations and extensions of your apps.
With the new approach, you can easily create a cluster management project from a project template and fully control your applications.
A project created using the new template contains the code needed for cluster management jobs, including built-in support for several applications. You can easily extend the project to other applications and own them completely.
Additionally, new applications will be installed using Helm v3. If you have former GitLab Managed Applications installed using Helm v2, check the Helm migration guide and the GitLab Managed Apps migration guide. The CI/CD job output will also guide you through these migrations.
In GitLab 14.0, the cluster management project supports only certificate-based cluster integrations. We plan to add support for the GitLab Kubernetes Agent in the next release.
See Documentation and Issue.
我有一个自托管的 gitlab,我想部署应用程序。我正在尝试部署一个跑步者,以便 gitlab 可以连接到 kubernetes 集群。我的 kubernetes 集群启用了 RBAC。
这是我的 gitlab-ci.yml 用于跑步者:
services:
- docker:18-dind
stages:
- deploy
deploy:
image:
name: thorstenhans/helm3:latest
entrypoint: ["/bin/sh", "-c"]
stage: deploy
environment:
name: staging
kubernetes:
namespace: runners
script:
- echo ${CI_JOB_NAME}
- helm version
- kubectl version
- helm repo add gitlab https://charts.gitlab.io/
- helm install gitlab/gitlab-runner --version 0.20.0 -f values.yml
这是 values.yml 文件:
## The GitLab Server URL (with protocol) that want to register the runner against
## ref: https://docs.gitlab.com/runner/commands/README.html#gitlab-runner-register
##
gitlabUrl: https://gitlab.mydomain.com/
## The registration token for adding new Runners to the GitLab server. This must
## be retrieved from your GitLab instance.
## ref: https://docs.gitlab.com/ee/ci/runners/
##
runnerRegistrationToken: "registration code here"
## Set the certsSecretName in order to pass custom certificates for GitLab Runner to use
## Provide resource name for a Kubernetes Secret Object in the same namespace,
## this is used to populate the /etc/gitlab-runner/certs directory
## ref: https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates
##
#certsSecretName:
## Configure the maximum number of concurrent jobs
## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
concurrent: 10
## Defines in seconds how often to check GitLab for a new builds
## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
checkInterval: 30
## For RBAC support:
rbac:
create: false
## Run the gitlab-bastion container with the ability to deploy/manage containers of jobs
## cluster-wide or only within namespace
clusterWideAccess: true
## If RBAC is disabled in this Helm chart, use the following Kubernetes Service Account name.
##
# serviceAccountName: default
## Configuration for the Pods that the runner launches for each new job
##
runners:
## Default container image to use for builds when none is specified
##
image: ubuntu:18.04
## Run all containers with the privileged flag enabled
## This will allow the docker:stable-dind image to run if you need to run Docker
## commands. Please read the docs before turning this on:
## ref: https://docs.gitlab.com/runner/executors/kubernetes.html#using-docker-dind
##
privileged: false
## Namespace to run Kubernetes jobs in (defaults to 'default')
##
# namespace:
## Build Container specific configuration
##
builds:
# cpuLimit: 200m
# memoryLimit: 256Mi
cpuRequests: 100m
memoryRequests: 128Mi
## Service Container specific configuration
##
services:
# cpuLimit: 200m
# memoryLimit: 256Mi
cpuRequests: 100m
memoryRequests: 128Mi
## Helper Container specific configuration
##
helpers:
# cpuLimit: 200m
# memoryLimit: 256Mi
cpuRequests: 100m
memoryRequests: 128Mi
如何为 gitlab 创建服务帐户,以便它可以在整个集群范围内部署应用程序?
你可以在 gitlab documentation.
中找到这些信息Enabling RBAC support
If your cluster has RBAC enabled, you can choose to either have the chart create its own service account or provide one on your own.
To have the chart create the service account for you, set rbac.create to true:
rbac:
create: true
To use an already existing service account, use:
rbac:
create: false
serviceAccountName: your-service-account
因此您必须将 values.yaml 更改为
rbac:
create: false
clusterWideAccess: true
serviceAccountName: your-service-account
有rbac和服务账号的相关文档。
- https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions
- https://unofficial-kubernetes.readthedocs.io/en/latest/admin/authorization/rbac/
- https://www.magalix.com/blog/kubernetes-authorization
还有另一个 Whosebug post 和一个 gitlab 问题,应该有助于为您的用例创建服务帐户。
您可以使用:
End goal: Execute all helm operations as GitLab CI yml in the connected cluster repo (vs running on server).
- 集群管理项目模板
参见 GitLab 14.0(2021 年 6 月)
Cluster management project template
In this release, we are moving away from the CI/CD template-based approach for cluster management.
Cluster management is the ability to manage Kubernetes clusters to improve application availability running on a cluster.
The old method hides too much of the logic, restricts customizations and extensions of your apps.
With the new approach, you can easily create a cluster management project from a project template and fully control your applications.A project created using the new template contains the code needed for cluster management jobs, including built-in support for several applications. You can easily extend the project to other applications and own them completely.
Additionally, new applications will be installed using Helm v3. If you have former GitLab Managed Applications installed using Helm v2, check the Helm migration guide and the GitLab Managed Apps migration guide. The CI/CD job output will also guide you through these migrations.
In GitLab 14.0, the cluster management project supports only certificate-based cluster integrations. We plan to add support for the GitLab Kubernetes Agent in the next release.
See Documentation and Issue.