Проще всего установить shared runner (то есть тот, который может использоваться любым проектом данной инсталляции GitLab) с помощью helm-чарта.
Создадим неймспейс:

kubectl create ns gitlab

Создадим секрет с корневым сертификатом, чтобы доверять инсталляции GitLab. Имя записи в секрете должна быть hostname.crt, где hostname - это имя хоста GitLab (gitlab.domain.local):

kubectl create secret generic -n gitlab ca-cert --from-file=gitlab.domain.local.crt=./CA.cer

Для того, чтобы раннер смог взаимодействовать с GitLab ему нужно передать пару параметров - адрес инсталляции GitLab и registration token.
Чтобы получить registration token идем в Admin Area → Runners и там берем строчку registration token, а затем подствляем в файл с values для чарта:

cat <<EOF > ./gitlab-runner-settings.yaml
image: gitlab/gitlab-runner:alpine-v13.8.0
runnerRegistrationToken: "dqjNDHQsum1zW1gVmtXc"
logLevel: debug
runners:
  privileged: true
  config: |
    [[runners]]
      [runners.kubernetes]
        image = "docker:dind"
  helpers:
    image: "gitlab/gitlab-runner-helper:x86_64-bleeding"
gitlabUrl: https://gitlab.domain.local/
certsSecretName: ca-cert
EOF

Устанавливаем GitLabRunner

helm repo add gitlab https://charts.gitlab.io
helm upgrade --install gitlab-runner-shared  -n gitlab -f ./gitlab-runner-settings.yaml gitlab/gitlab-runner

Дадим прав раннеру в кластере (то есть дадим прав дефолтной ServiceAccount в неймспейсе gitlab):

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: "ClusterRoleBinding"
metadata:
  name: gitlab-runner-admin
  namespace: gitlab
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: "ClusterRole"
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: default
  namespace: gitlab
EOF

В итоге - данная конфигурация позволит запускать раннер в кластере и позволит раннеру деплоить собранное. Не забываем, что речь иде о dev-кластере.

• Включаем CI/CD для проекта - Settings → General → Visibility, project features, permissions → Pipelines
• Настраиваем переменные - Settings → CI/CD → Variables. Нужно добавить DOCKER_REGISTRY_URL и конфиги для кластеров (переменные KUBECONFIG_PROD и KUBECONFIG_TEST), отличных от того, где работает раннер (в своем кластере раннер имеет права). Если docker registry требует аутентифиуации, то добавляем переменные DOCKER_REGISTRY_LOGIN и DOCKER_REGISTRY_PASS и расскоментируем в .gitlab-ci.yaml соответствующие строчки.

services:
#  - name: docker.rdleas.ru/docker:dind
# Последнюю версию dind (20+) не удается использовать из-за ошибки: https://github.com/containerd/containerd/issues/4837
# Нужно обновлять container.d на хостах
# В остальном - всё уже готово. 
  - name: docker.rdleas.ru/docker:19-dind
    command: 
      - /bin/sh
      - -c
      - |
        openssl s_client -showcerts -connect docker.rdleas.ru:443 </dev/null 2>/dev/null | awk '/BEGIN/ { i++; } /BEGIN/, /END/ { print }' > /usr/local/share/ca-certificates/ca.crt
        update-ca-certificates
        unset DOCKER_TLS_CERTDIR
        dockerd-entrypoint.sh

stages:
  - build

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: ""
  DOCKER_HOST: tcp://0.0.0.0:2375

build:
  image:
    name: docker.rdleas.ru/k8s-skaffold/skaffold:v1.19.0
  stage: build
#  before_script:
#    - docker login -u `echo $DOCKER_REGISTRY_LOGIN` -p `echo $DOCKER_REGISTRY_PASS` `echo $DOCKER_REGISTRY_URL`
#https://skaffold.dev/docs/references/cli/
  script:
    - | 
      openssl s_client -showcerts -connect ${DOCKER_REGISTRY_URL}:443 </dev/null 2>/dev/null | awk '/BEGIN/ { i++; } /BEGIN/, /END/ { print }' > /usr/local/share/ca-certificates/ca.crt
      update-ca-certificates
      env
      echo "waiting for the DinD..."
      timeout 60 bash -c 'until printf "" 2>>/dev/null >>/dev/tcp/$0/$1; do sleep 1; done' 0.0.0.0 2375
      if [ "$CI_COMMIT_BRANCH" = "DEV" ]; then
        skaffold run -f skaffold-run.yaml --default-repo ${DOCKER_REGISTRY_URL}/vrm
      else
        skaffold build -f skaffold-build.yaml
      fi

Что тут прроисходит?

• service: - эта инструкция запускает некую сущность (доступную по сети из скрипта для сборки). У гитлаба написано, что изначально так запускали БД. Теперь так запускаем docker и в дальнейшем передаем ему Dockerfile для сборки. Для того, чтобы этот сервис доверял нашим сертификатам - мы сначала добавляем сертификат в доверенные, а затем стартуем штатный Entrypoint.
• stages: - список этапов конвейера, которые будут объявлены позднее.
• variables: - список переменных среды, которые будут добавлены к другим переменным и доступны в контейнерах, которые будут запускаться в дальнейшем.
• build: - собственно описание на данный момент единственной стадии конвейера. В ней мы стартуем контейнер skaffold, выполняем before_script, который логинится в приватный Docker Registry. Логин, пароль и url этого registry заданны в настройках проекта GitLab в виде Variables. Конструкции вида

  `echo $DOCKER_REGISTRY_LOGIN`

  сделаны для того, чтобы избежать ошибки:

  cannot perform an interactive login from a non TTY device

  Дальше - сам скрипт script. В нем тоже добавляется в доверенные сертификат нашего registry, а затем запускается skaffold с параметром run, который выполняет все стадии конвейера - сборку (а в процессе сборки запускается и тестирование) и деплой с помощью чарта.

Тут происходит вот что.
Как понятно из манифеста - это Config для skaffold. Полное описание всего этого доступно https://skaffold.dev/docs/references/yaml/.
Итак. С точки зрения skaffold, работающего в контейнере, мы выполняем сборку локально, на что указывает тег local: {}.
Мы собраем артефакт с помощью клиента докера (тег docker), который будет общаться с сервером Docker, который является запущенным ранее service: и доступен нам благодаря объявленной переменной среды DOCKER_HOST.
Так вот этому докеру будет передан Dockerfile, путь к которому задан с помощью тега dockerfile: относительно пути context:.
А после сборки мы выкатываем релиз с помощью helm (который будет запущен из контейнера skaffold) в тот кластер на котором работает наш runner. Подробнее о том как скаффолд работат с кластером - тут https://skaffold.dev/docs/environment/kube-context/#kubeconfig-selection

apiVersion: skaffold/v2beta11
kind: Config
build:
  local: {}
  tagPolicy:
    envTemplate:
      template: "{{.CI_COMMIT_BRANCH}}"
  artifacts:
  - image: vrm
    context: .
    docker:
      dockerfile: Dockerfile
      buildArgs:
        CI_COMMIT_SHORT_SHA: '{{.CI_COMMIT_SHORT_SHA}}'
deploy:
  helm:
    releases: 
    - name: vrm
      chartPath: chart/
      namespace: vrm
      valuesFiles:
        - '{{.VALUES}}'
      artifactOverrides:
        image: vrm

#https://docs.docker.com/engine/examples/dotnetcore/
FROM docker.rdleas.ru/amd64/maven:3.6.3-jdk-11 as builder
WORKDIR /app
COPY . .
RUN mvn -gs /app/.m2/settings.xml -Pnexus clean compile test-compile \
 && mvn -gs /app/.m2/settings.xml -Pnexus package

FROM docker.rdleas.ru/openjdk:11.0.10-jre-buster
ENV CI_COMMIT_SHORT_SHA=$CI_COMMIT_SHORT_SHA
WORKDIR /app
COPY --from=builder /app/. ./
CMD ["/usr/local/openjdk-11/bin/java", "-jar", "/app/target/vrm-1.0.0-SNAPSHOT.jar"]

Тут у нас двухстадийная сборка (multistage).
Сначала мы запускаем контейнер maven, который получает псевдоним builder, который выкачивает зависимости из локальной proxy-репы maven-central на базе nexus (директория .m2 с файлом settings.xml лежит в репозитории проекта). А далее мы собираем второй контейнер на базе образа OpenJDK JRE, в который копируем файлики, полученные в результате работы первого контейнера-билдера.

План такой:

• создаем неймспейс, в который будем деплоить релиз с помощью helm-чарта
• создаем ServiceAccount, который будет иметь права на все объекты в данном неймспейсе.
• Создаем фалик KUBECONFIG, который мы передадим skaffold и с помощью которого будем обращаться к кластеру.
• Созданный файлик KUBECONFIG кодируем в base64 и помещаем в переменную окружения проекта, чтобы передать его skaffold.

переключаемся на контекст тестового кластера:

kubectl config use-context test

Создаем неймспейс:

kubectl create ns vrm

Создаем ServiceAccount. Я создам его в неймспейсе kube-system:

kubectl create sa -n kube-system vrm-ns-admin

Дадим этой SA права в неймспейсе vrm:

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: vrm-ns-admin
  namespace: vrm
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: "RoleBinding"
metadata:
  name: vrm-ns-admin
  namespace: vrm
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: "Role"
  name: vrm-ns-admin
subjects:
- kind: ServiceAccount
  name: vrm-ns-admin
  namespace: kube-system
EOF

Дальше получаем имя токена:

TOKEN_NAME=`kubectl get secret -n kube-system -o name | grep vrm-ns-admin-token`

и его содержимое:

TOKEN=`kubectl get $TOKEN_NAME -n kube-system -o "jsonpath={.data.token}" | base64 -d`

а также корневой сертификат кластера:

TOKEN_CA=`kubectl get $TOKEN_NAME -n kube-system -o "jsonpath={.data['ca\.crt']}"`

и URL для control plane:

CONTROL_PLANE=`kubectl cluster-info | grep 'Kubernetes control plane' | awk '{print $NF}' | sed -r "s/[[:cntrl:]]\[([0-9]{1,3};)*[0-9]{1,3}m//g"`

И, наконец, генерируем собственно сам KUBECONFIG:

cat <<EOF > ./vrm-admin-kubeconfig
apiVersion: v1
kind: Config
preferences: {}
# Define the cluster
clusters:
- cluster:
    certificate-authority-data: $TOKEN_CA
    server: $CONTROL_PLANE
  name: cluster

# Define the user
users:
- name: vrm-ns-admin
  user:
    as-user-extra: {}
    client-key-data: $TOKEN_CA
    token: $TOKEN

# Define the context: linking a user to a cluster
contexts:
- context:
    cluster: cluster
    namespace: vrm
    user: vrm-ns-admin
  name: vrm

# Define current context
current-context: vrm
EOF

Проверяем, что полученный kubeconfig работает:

KUBECONFIG=./vrm-admin-kubeconfig kubectl get po -n vrm

Теперь - добавляем содержимое этого файла в свойтсвах проекта в переменную типа File. В итоге -содержимое файла будет доставлено в контейнер skaffold в виде временного файла, а её значение будет указать на расположение этого файла. А gitlab-ci.yml станет такой:

services:
#  - name: docker.rdleas.ru/docker:dind
# Последнюю версию dind (20+) не удается использовать из-за ошибки: https://github.com/containerd/containerd/issues/4837
# Нужно обновлять container.d на хостах
# В остальном - всё уже готово. 
  - name: docker.rdleas.ru/docker:19-dind
    command: 
      - /bin/sh
      - -c
      - |
        openssl s_client -showcerts -connect docker.rdleas.ru:443 </dev/null 2>/dev/null | awk '/BEGIN/ { i++; } /BEGIN/, /END/ { print }' > /usr/local/share/ca-certificates/ca.crt
        update-ca-certificates
        unset DOCKER_TLS_CERTDIR
        dockerd-entrypoint.sh

stages:
  - build

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: ""
  DOCKER_HOST: tcp://0.0.0.0:2375

build:
  image:
    name: docker.rdleas.ru/k8s-skaffold/skaffold:v1.19.0
  stage: build
  before_script:
    - docker login -u `echo $DOCKER_REGISTRY_LOGIN` -p `echo $DOCKER_REGISTRY_PASS` `echo $DOCKER_REGISTRY_URL`
#https://skaffold.dev/docs/references/cli/
  script:
    - | 
      openssl s_client -showcerts -connect ${DOCKER_REGISTRY_URL}:443 </dev/null 2>/dev/null | awk '/BEGIN/ { i++; } /BEGIN/, /END/ { print }' > /usr/local/share/ca-certificates/ca.crt
      update-ca-certificates
      env
      echo "waiting for the DinD..."
      timeout 60 bash -c 'until printf "" 2>>/dev/null >>/dev/tcp/$0/$1; do sleep 1; done' 0.0.0.0 2375
      case $CI_COMMIT_BRANCH in
        DEV)      
          VALUES="chart/values_dev.yaml" skaffold run -f skaffold-run.yaml --default-repo ${DOCKER_REGISTRY_URL}/vrm
        ;;
        TEST)
          VALUES="chart/values_test.yaml" \
          KUBECONFIG=$KUBECONFIG_TEST \
          skaffold run -f skaffold-run.yaml \
          --default-repo ${DOCKER_REGISTRY_URL}/vrm
        ;;
        PROD)
          KUBECONFIG=$KUBECONFIG_PROD \
          VALUES="chart/values_prod.yaml" \
          skaffold run -f skaffold-run.yaml \
          --default-repo ${DOCKER_REGISTRY_URL}/vrm
        ;;
        *)
          skaffold build -f skaffold-build.yaml
        ;;
      esac