Por padrão o cluster kubernetes tem topologySpreadConstraints
com maxSkew 3 por hostname.
Consequentemente o gitlab-runner gera 3 workers num mesmo node antes de gerar workers em novo node. O que deixa builds até 3 vezes mais lentas.
Uma build de 8 minutos, se executada com jobs em paralelo identicos leva 24 minutos. :o)
Preciso ativar o tipo KubeSchedulerConfiguration
.
A configuração tem que ser feita em arquivo fora do Kubernetes. O arquivo no K3s tem caminho/nome diferente. Imagino que seja: /var/lib/rancher/k3s/server/cred/kubeconfig-system.yaml
Referências:
- https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/
- kubernetes/website#21128
Desisti após experimentos. Não consegui ativar no K3s. (Deve ter um jeito só não achei.)
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: "DoNotSchedule"
labelSelector:
matchLabels:
app: gitlab-runner-worker
Alterei o código do gitlab-runner (monkey patch - fiz hardcoded inicialmente pra teste) para permitir configurar topologySpreadConstraints
,
e parece estar funcionando (vide build Nix).
Repositório: https://gitlab.com/superherointj/gitlab-runner-patched
Depois de muitos experimentos desisti. Tava complicado de acertar. Tá confuso o que fizeram.
Bloquei em um erro de download de dependências, exemplo de uma dependência:
go: finding module for package gitlab.com/gitlab-org/gitlab-runner/cache/gcs
gitlab.com/gitlab-org/gitlab-runner imports
gitlab.com/gitlab-org/gitlab-runner/cache/gcs: no matching versions for query "latest"
A url existe: https://gitlab.com/gitlab-org/gitlab-runner/-/tree/main/cache/gcs Porém o caminho não é o mesmo. Não sei se o Go faz mágica pro download de dependencias. Ou o que deveria fazer aqui.
IMPORTANTE: Os pacotes são locais no repositório do gitlab-runner.
Não saber Go dá nisso. Erro idiota! :@
Build OK! Aplicativo executou. Containerizei usando o Nix. Funcionou em testes locais. Mas apareceu problemas na produção qdo troquei a docker image da Helm Chart (que tem entrypoint diferente), aí o container novo foi atualizado mas ficou em CrashLoop.
Acredito que o problema seja na containerização que fiz do GitLab-Runner. Algum detalhe... Alguma coisinha.
Helm Chart docs:
- https://docs.gitlab.com/runner/install/kubernetes.html
- https://gitlab.com/gitlab-org/charts/gitlab-runner/blob/main/values.yaml
- https://gitlab.com/gitlab-org/charts/gitlab-runner/blob/main/values.yaml#L565
[To-Do: Adicionar logs do Kubernetes do pod em loop. Mas não lembro de ter visto nada especial.]
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: kubernetes.io/hostname
- https://docs.openshift.com/container-platform/3.11/admin_guide/scheduling/pod_affinity.html
- https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
labelSelector:
matchLabels:
gitlab-runner: worker
Parei os esforços aqui.