GitLab can be configured to interact with Kubernetes, or other systems using the Kubernetes API (such as OpenShift).
Each project can be configured to connect to a different Kubernetes cluster, see the configuration section.
If you have a single cluster that you want to use for all your projects, you can pre-fill the settings page with a default template. To configure the template, see the Services Templates document.
Navigate to the Integrations page of your project and select the Kubernetes service to configure it.
The Kubernetes service takes the following arguments:
The API URL is the URL that GitLab uses to access the Kubernetes API. Kubernetes
exposes several APIs - we want the "base" URL that is common to all of them,
e.g., https://kubernetes.example.com
rather than https://kubernetes.example.com/api/v1
.
GitLab authenticates against Kubernetes using service tokens, which are
scoped to a particular namespace
. If you don't have a service token yet,
you can follow the
Kubernetes documentation
to create one. You can also view or create service tokens in the
Kubernetes dashboard - visit
Config -> Secrets
.
Fill in the service token and namespace according to the values you just got.
If the API is using a self-signed TLS certificate, you'll also need to include
the ca.crt
contents as the Custom CA bundle
.
The Kubernetes service exposes following deployment variables in the GitLab CI build environment:
KUBE_URL
- equal to the API URLKUBE_TOKEN
KUBE_NAMESPACE
- The Kubernetes namespace is auto-generated if not specified.
The default value is <project_name>-<project_id>
. You can overwrite it to
use different one if needed, otherwise the KUBE_NAMESPACE
variable will
receive the default value.KUBE_CA_PEM_FILE
- only present if a custom CA bundle was specified. Path
to a file containing PEM data.KUBE_CA_PEM
(deprecated)- only if a custom CA bundle was specified. Raw PEM data.NOTE: Added in GitLab 8.15. You must be the project owner or have
master
permissions to use terminals. Support is currently limited to the first container in the first pod of your environment.
When enabled, the Kubernetes service adds web terminal
support to your environments. This is based on the exec
functionality found in
Docker and Kubernetes, so you get a new shell session within your existing
containers. To use this integration, you should deploy to Kubernetes using
the deployment variables above, ensuring any pods you create are labelled with
app=$CI_ENVIRONMENT_SLUG
. GitLab will do the rest!
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )