среда, 2 апреля 2025 г.

GitLab k8s runner даёт ошибку " failed to verify certificate: x509: certificate signed by unknown authority" во время регистрации на сервере

Довольно долго провозился с этой темой.

Как оказалось проблема не в сертификате (его содержимом).

Основная история вот в чём:

1. сертификат долженг иметь такое же имя, как вы указали в параметре tls-ca-file файла /etc/gilab-runner/config.toml

2. после создания секрета в k8s, в values.yaml  создайте две переменные окружения 

envVars:

  - name: <secret_name>
    value: /home/gitlab-runner/.gitlab-runner/certs/<certificate_name>


P.S. после этого, если на runner выскакивает ошибка kubectl  с аналогичным кодом - просто добавьте "--insecure-skip-tls-verify."



 


среда, 12 марта 2025 г.

Small note on git clone issue

 git clone https://some_fqdn/development-group/k8sdemo.git

Клонирование в «k8sdemo»...

Username for 'https://some_fqdn':

Password for 'https://some_fqdn':

remote: HTTP Basic: Access denied. If a password was provided for Git authentication, the password was incorrect or you're required to use a token instead of a password. If a token was provided, it was either incorrect, expired, or improperly scoped. See https://devops.test-lab.ru/help/topics/git/troubleshooting_git.md#error-on-git-fetch-http-basic-access-denied


Просто добавь "git clone https://gitlab_user_name@some_fqdn/development-group/k8sdemo.git" и исполоьзуй Private Access Token (PAT). Либо переводи на ssh.

вторник, 11 марта 2025 г.

Веселье перевода GitLab на https и другие пляски

Продолжение приключений в лабе.

В общем, столкнулся с такой бедой, что k8s runner Gitlab требует наличия https и доп. ключи в командах не помогают. Подробнее можно ознакомиться тут.

"Yes, kubectl would never send credentials over a cleartext connection. --insecure-skip-tls-verify wouldn't help, it just disables TLS verification, but TLS is still required for it to send credentials."

Смысл проблемы понятен и я стал переводить лабу на https, выпустив сертификат самоподписанный для сервера GitLab и всех необходимых SAN (Subject Alternative Name).

После того, как я настроил https на сервере, естественно отвалился KAS (k8s agent server) GitLab, ибо он был настрое для http. Следом отвалилась Visual Studio Code, отказывающаяся принимать самопдписанный серт. 

Первое я починил сделав несколько приседаний с размещением сертификатов в /usr/local/shara/ca-certificates на серверах k8s и GitLab, с последующей коммандой sudo update-ca-trust. В Helm вызове обвноления развёртывания KAS необходимо было указать 

--set-file config.kasCert=/opt/<cert_name.crt> и --set config.kasAddress=wss://<gitlab.domain.ru>/-/kubernetes-agent/  (может использоваться ссылка =ws://, если мы говорим о http), внести в /etc/gitlab-runner/config.toml директиву tls-ca-file="/usr/local/shara/ca-certificates/<cert_name.crt>" в секции [[runners]]. После этого KAS позеленел (при обновлении стоит не забывать актуализировать версию агента - я про это забыл и потерял некоторое кол-во времени дополнительно, поймав рассинхрон между сервером GitLab и KAS по версиям). 

Второе же, почилилось без сложных приседаний: я нашел рекомендацию, где сказано, что надо отключить "HTTP: Proxy support", что и проделал. Детали можно посмотреть тут

Осталось починить runners, пока pipeline зависает, т.к. runners потеряли gitlab сервер.

Продолжаем-с....

P.S. А, забыл, Container Registry тоже отлетел. Не забываем менять /etc/gitlab/gitlab.rb в части registry_external_url 'https://<gitlab.domain.ru>:<port_number>', после выполнения команд из предыдущей статьи nginx упал с ошибкой.

[ladmin@k8srepo ~]$ sudo gitlab-ctl status nginx
down: nginx: 1s, normally up, want up; run: log: (pid 1077) 1717

По-умолчанию, nginx пытается открыть файл ключа и сертификата с именем, как в выводе ниже.

 [emerg] 1920#0: cannot load certificate "/etc/gitlab/ssl/<gitlab.domain.ru>.crt": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/gitlab/ssl/<server_fqdn>.crt','r') error:2006D080:BIO routines:BIO_new_file:no such file)

Детализацию получил с помощью команды  sudo gitlab-ctl tail.

Отсюда и проблема, дериктивы  ssl_certificate и ssl_certificate_key - почему-то не зарешали. Смысл в том, что файлы сертификата и ключа имели другое имя. В общем, после того, как это поправил - всё взлетело.






суббота, 4 января 2025 г.

Заметки о сосуществовании сервера GitLab и кластер Kubernetes

Забавно было пропасть на 3 года.

Ниже приведены заметки и личный субъективный опыт отработки взаимодействия k8s кластера и сервера GitLab - каждому своё.

  • в своей лаборатории я разносил namespace для gitlab-agent и gitlab-runner, из плюсов - атамарное управление разными уровнями функциональной нагрузки:

[ladmin@k8sm01 k8sdemo]$ kubectl get namespaces | grep gitlab

gitlab-agent-k8s    Active   36d

gitlab-runners-ns   Active   52m

  • правильные настройки в values.yaml  для установки gitlab-runner на k8s в части репозитария и образа:
image:
  registry: registry.gitlab.com
  image: gitlab-org/gitlab-runner
  tag: alpine-v17.6.0
версия образа - будет меняться по необходимости.

  •  я использовал  встроенный в GitLab сервер Container Registry без использования SSL сертификатов - лень было делать в лаборатории. В результате я получал ImagePullBackOff при попытке развернуть что-либо с детализацией ошибки "server gave HTTP reply to HTTPS client". Исправил это путём модификации /etc/containerd/config.toml каждого узла кластера k8s.
        
    
    далее следует выполнить:
sudo systemctl restart containerd.service
  • после обновления GitLab сервер необходимо также обновить GitLab agent на кластере k8s.

helm upgrade <release_name> gitlab/gitlab-agent  --namespace <k8s_namespace_name> --set image.tag=vX.Y.Z --set config.token=<your_token>  --set config.kasAddress=ws://devops.test-lab.ru/-/kubernetes-agent/ --set replicas=1

            Если забыть указать токен, то вы получите ошибку 

kubectl logs  k8s-gitlab-agent-v2-56777f97d6-dnbqq  -n gitlab-agent-k8s

{"time":"2025-01-04T10:21:36.816484327Z","level":"ERROR","msg":"Program aborted","error":"token file: open /etc/agentk/secrets/token: no such file or directory"}

  • при конфигурации GitLab сервер для использования Container Registry я допустил ошибку, использовав один и тот же порт для нескольких элементов GitLab. Ошибку удалось вычислить по записи в /var/log/gitlab/registry/current.
sudo cat /var/log/gitlab/registry/current | tail -10

 

"2024-12-26_08:22:56.55672 time="2024-12-26T11:22:56.556+03:00" level=fatal msg="listen tcp 127.0.0.1:5005: bind: address already in use"

          Что было исправлено:


    Далее необходимо выполнить команды ниже, иначе ошибка никуда не уйдёт (по-моему, "gitlab-ctl reconfigure" будет достаточно):

sudo systemctl restart gitlab.target

sudo gitlab-ctl restart nginx

sudo gitlab-ctl reconfigure

sudo gitlab-ctl status


  • если в секции ниже в values.yaml для gitlab runner значения параметров  "allowPrivilegeEscalation", "privileged" будут иметь разные значения - получите ошибку "cannot set `allowPrivilegeEscalation` to false and `privileged` to true". 

securityContext:
  allowPrivilegeEscalation: true
  readOnlyRootFilesystem: false
  runAsNonRoot: true
  privileged: true
  capabilities:
    drop: ["ALL"]