Page MenuHomePhabricator

The airflow-gitsync pods are adversely affected by gitlab being put behind the CDN
Closed, ResolvedPublic

Description

We have received multiple alerts of this nature:

AirflowDeploymentUnavailable data-platform (airflow-gitsync airflow-platform-eng k8s-dse critical eqiad prometheus)

Upon investigation, we can confirm that the airflow-gitsync pods are in a crashloop state.

btullis@deploy1003:~$ kube-env airflow-platform-eng-deploy dse-k8s-eqiad
btullis@deploy1003:~$ kubectl get pods
NAME                                                              READY   STATUS             RESTARTS        AGE
airflow-envoy-696fdc57fc-g55cl                                    1/1     Running            0               22d
airflow-gitsync-54845464d5-qpt8n                                  0/1     CrashLoopBackOff   13 (105s ago)   22d
airflow-hadoop-shell-56c9455c87-f94mr                             1/1     Running            0               22d
airflow-kerberos-5b48d6d54f-7w44s                                 1/1     Running            0               22d
airflow-scheduler-7984fb654c-246z7                                1/1     Running            1 (11d ago)     12d
airflow-statsd-85fc54bb4-9q847                                    1/1     Running            0               34d
airflow-task-shell-64b8ff584-ff49j                                1/1     Running            0               22d
airflow-webserver-7bf6b5c7d8-qhbd2                                2/2     Running            0               22d
postgresql-airflow-platform-eng-1                                 1/1     Running            0               34d
postgresql-airflow-platform-eng-2                                 1/1     Running            0               34d
postgresql-airflow-platform-eng-pooler-rw-6f76b54fb6-lzsfp        1/1     Running            0               34d
postgresql-airflow-platform-eng-pooler-rw-6f76b54fb6-nvskj        1/1     Running            0               34d
postgresql-airflow-platform-eng-pooler-rw-6f76b54fb6-spvs5        1/1     Running            0               34d
<snip>

I checked the logs of the pod and it said this.

btullis@deploy1003:~$ kubectl logs airflow-gitsync-54845464d5-qpt8n
INFO: detected pid 1, running init handler
{"logger":"","ts":"2026-08-19 08:48:03.904420","caller":{"file":"main.go","line":568},"level":0,"msg":"starting up","version":"4.2.4","pid":11,"uid":900,"gid":900,"home":"/home/runuser","flags":["--depth=1","--link=airflow_dags","--period=5m0s","--ref=main","--repo=https://gitlab.wikimedia.org/repos/data-engineering/airflow-dags.git","--root=/dags","--sparse-checkout-file=/etc/gitsync/sparse-checkout.conf"]}
{"logger":"","ts":"2026-08-19 08:48:03.905684","caller":{"file":"main.go","line":673},"level":0,"msg":"git version","version":"git version 2.39.2"}
{"logger":"","ts":"2026-08-19 08:50:18.748648","caller":{"file":"main.go","line":855},"msg":"too many failures, aborting","error":"Run(git fetch https://gitlab.wikimedia.org/repos/data-engineering/airflow-dags.git main --verbose --no-progress --prune --no-auto-gc --depth 1): context deadline exceeded: { stdout: \"\", stderr: \"fatal: unable to access 'https://gitlab.wikimedia.org/repos/data-engineering/airflow-dags.git/': Failed to connect to gitlab.wikimedia.org port 443 after 134536 ms: Couldn't connect to server\" }","failCount":1}

I deleted the pod and watched the recovery,

btullis@deploy1003:~$ kubectl delete pod airflow-gitsync-54845464d5-qpt8n
pod "airflow-gitsync-54845464d5-qpt8n" deleted

But pretty soon it started going into a crashloop again.

btullis@deploy1003:~$ kubectl get pods
NAME                                                              READY   STATUS             RESTARTS      AGE
airflow-envoy-696fdc57fc-g55cl                                    1/1     Running            0             22d
airflow-gitsync-54845464d5-b5nr4                                  0/1     CrashLoopBackOff   2 (10s ago)   7m12s
`

Event Timeline

This seems very likely related to this currentl work: T425441: gitlab behind CDN

We are now starting to receive alerts for more Airflow instances being unstable, although it might be transitory for each.

Monitoring for stability.

It is affecting all gitsync pods

root@deploy1003:~# kube-env admin dse-k8s-eqiad 
root@deploy1003:~# kubectl get -A pod -l app=airflow,component=gitsync
NAMESPACE                   NAME                                                      READY   STATUS             RESTARTS           AGE
airflow-analytics-product   airflow-gitsync-76c9cff97d-4m76z                          1/1     Running            20 (106s ago)      22d
airflow-analytics-test      airflow-gitsync-586cf964b7-wp6hb                          1/1     Running            23 (102s ago)      13d
airflow-dev                 airflow-dev-aqu-gitsync-5446c45fd8-ndk6l                  1/1     Running            16 (73s ago)       25h
airflow-dev                 airflow-dev-atsuko-gitsync-55947f5f6-flh5k                1/1     Running            16 (96s ago)       21h
airflow-dev                 airflow-dev-btullis-gitsync-86d78fcb8d-g8s9m              1/1     Running            27 (71s ago)       7d
airflow-dev                 airflow-dev-cdobbins-gitsync-759668d8fd-s8dcb             1/1     Running            27 (54s ago)       14d
airflow-dev                 airflow-dev-kcvelaga-api-daily-gitsync-674d9b47cf-rml59   1/1     Running            32 (53s ago)       22d
airflow-dev                 airflow-dev-kcvelaga-gitsync-757f899444-6v8lb             1/1     Running            1 (115s ago)       4m13s
airflow-dev                 airflow-dev-lerickson-gitsync-6b5f75bf9f-hrp68            0/1     CrashLoopBackOff   290 (2m17s ago)    37h
airflow-dev                 airflow-dev-trueg-gitsync-86cd6f86cc-pq5vs                0/1     CrashLoopBackOff   2197 (4m45s ago)   8d
airflow-dumps               airflow-gitsync-6b985497f7-z8n9n                          0/1     Error              23 (2m35s ago)     14d
airflow-fr-tech             airflow-gitsync-7db9b4cfff-zzzdl                          1/1     Running            21 (50s ago)       20d
airflow-main                airflow-gitsync-8448f7dd79-mtmwg                          1/1     Running            14 (113s ago)      19h
airflow-ml                  airflow-gitsync-544d47b665-gmsgc                          1/1     Running            19 (23s ago)       22d
airflow-platform-eng        airflow-gitsync-54845464d5-b5nr4                          1/1     Running            8 (107s ago)       38m
airflow-research            airflow-gitsync-5f8dbc89bb-z7xhc                          1/1     Running            22 (119s ago)      22d
airflow-search              airflow-gitsync-68f6cf6f6-28nvd                           1/1     Running            23 (79s ago)       22d
airflow-sre                 airflow-gitsync-bfb7c864d-cppdx                           1/1     Running            23 (2m17s ago)     22d
airflow-test-k8s            airflow-gitsync-57b45795cd-9mwrp                          1/1     Running            19 (109s ago)      11d
airflow-wikidata            airflow-gitsync-757768ff65-gskd5                          1/1     Running            22 (2m1s ago)      13d
airflow-wmde                airflow-gitsync-9cb566d8b-bgr7s                           1/1     Running            28 (102s ago)      22d

I don't think we can connect at all

runuser@.../home/git-sync$ getent hosts gitlab.wikimedia.org
2620:0:861:2:208:80:154:145 gitlab.wikimedia.org
runuser@...:/home/git-sync$ /usr/bin/openssl s_client -connect gitlab.wikimedia.org:443 -debug
...

Yeah, applying external_services

[. dse-k8s-eqiad] external-services, gitlab-wikimedia, Endpoints (v1) has changed:
[. dse-k8s-eqiad] ...
[. dse-k8s-eqiad]       chart: external-services-0.0.3
[. dse-k8s-eqiad]       release: external-services
[. dse-k8s-eqiad]       heritage: Helm
[. dse-k8s-eqiad]   subsets:
[. dse-k8s-eqiad]     - addresses:
[. dse-k8s-eqiad] -     - ip: 208.80.154.224 
[. dse-k8s-eqiad] -     - ip: 2620:0:861:ed1a::1 
[. dse-k8s-eqiad] +     - ip: 208.80.154.145 
[. dse-k8s-eqiad] +     - ip: 2620:0:861:2:208:80:154:145 
[. dse-k8s-eqiad]       ports:
[. dse-k8s-eqiad]       - port: 443
[. dse-k8s-eqiad]         name: https
[. dse-k8s-eqiad]         protocol: TCP

Service accounts seems to have ssh access, too. We can potentially switch to use SSH instead of https.

Sorry I missed that answer @atsuko

! In T435292#12230200, @atsuko wrote:
Service accounts seems to have ssh access, too. We can potentially switch to use SSH instead of https.

using SSH should be possible but I'm wondering: does the bug still happens? Because Gitlab is no longer behind CDN (see operations/dns/+/1327066) since 11:26~ (CEST) this morning.

@ABran-WMF The issue doesn't happen anymore after the DNS was reverted and external services IP addresses were updated in K8S. The comment was mostly an idea for @BTullis how we can navigate this in the future.

Sorry I missed that answer @atsuko

! In T435292#12230200, @atsuko wrote:
Service accounts seems to have ssh access, too. We can potentially switch to use SSH instead of https.

using SSH should be possible but I'm wondering: does the bug still happens? Because Gitlab is no longer behind CDN (see operations/dns/+/1327066) since 11:26~ (CEST) this morning.

Sorry I missed that answer @atsuko

! In T435292#12230200, @atsuko wrote:
Service accounts seems to have ssh access, too. We can potentially switch to use SSH instead of https.

Cool, thanks. Do we know why we were blocked?
I wonder if it was something to do with user-agent policy or some other rate-limiting that is in Varnish/HAproxy, but not in GitLab.

Maybe we could do something along the lines of allowing dse_kubepods_networks ty bypass rate-limiting.

using SSH should be possible

I'm also wondering if we would be restriucted to the same SSH rate-limiting as we get with HTTPS (if that's what it is).

Unauthenticated HTTPS access seems like the simplest option from a maintenance perspective, as we are only pulling from a publicly readable repository.

BTullis renamed this task from The airflow-gitsync pod for the platform-eng instance is crash-looping to The airflow-gitsync pods are adversely affected by gitlab being put behind the CDN.Aug 19 2026, 3:49 PM

Cool, thanks. Do we know why we were blocked?

Yes! As mentioned here: T425441#12231758 → text-lb nodes on the CDN were dropping traffic from your pods.

using SSH should be possible

I'm also wondering if we would be restriucted to the same SSH rate-limiting as we get with HTTPS (if that's what it is).

Unauthenticated HTTPS access seems like the simplest option from a maintenance perspective, as we are only pulling from a publicly readable repository.

Fwiw, the SSH stack to go through is thinner than the HTTPS one. We chose to skip CDN for SSH on Gitlab, which is now served by a new FQDN (gitlab-ssh.wm.o).
Once the firewall config has been updated, both options should be similarly stable and available.

@ABran-WMF based on the fact that our lb stack is very aggressively limiting access with default useragent strings, should we use specific user agent to avoid rate-limiting from lb?

@BTullis we can use GIT_HTTP_USER_AGENT environment variable.

Change #1332720 had a related patch set uploaded (by Arnaudb; author: Arnaudb):

[operations/puppet@production] kubernetes: allow pod egress to text-lb for gitlab

https://gerrit.wikimedia.org/r/1332720

@ABran-WMF based on the fact that our lb stack is very aggressively limiting access with default useragent strings, should we use specific user agent to avoid rate-limiting from lb?

I think it's worth using a user agent (see T400119: Block traffic from user-agents not honoring our policy for reference), but I'm not sure there is anything specific to be done.
I'm not sure your pods will be subject to rate-limiting either because their packets come from an known origin.

About the initial issue behind this task, it seem the initial idea that there was drops at text-lb level was - at least partially - wrong. The drop seems to have been caused by an egress policy that we can already update to avoid replaying the same scenario.
More about this in that comment and in that change.

I've talked to @ABran-WMF and I think there's an easier way of going about it. We could probably have our gitsync pods clone airflow-dags through the https://gitlab.discovery.wmnet:8443 internal endpoint (itself exposed to the wider internet via ATS).

This would require 3 things:

  • exposing a new gitlab-discovery external_services pointing to the gitlab hosts' IPV4/6 IPs and port 8443
  • adding DSE_KUBEPODS_NETWORKS to the src_sets allowed by gitlab
  • switching the gitsync gitlab endpoint to the discovery one

This is the only place where we have a direct link between airflow and gitlab. Indeed, the task-pod egress network policy (detailing what services task pods can egress to) does not list gitlab.

brouberol@deploy1003:~$ k get networkpolicies.crd.projectcalico.org airflow-production-egress-external-services-gitsync -oyaml | grep gitlab
        name: gitlab-wikimedia
brouberol@deploy1003:~$ k get networkpolicies.crd.projectcalico.org airflow-production-egress-external-services-task-pod -oyaml | grep gitlab
brouberol@deploy1003:~$

We _do_ have DAGs with https://gitlab.wikimedia.org in their code, but they are running SparkSqlOperator tasks, meaning that the call to gitlab.wikimedia.org is made from within an-worker hosts.

brouberol@an-worker1200:~$ curl -v https://gitlab.wikimedia.org
* Uses proxy env variable no_proxy == 'wikipedia.org,wikimedia.org,wikibooks.org,wikinews.org,wikiquote.org,wikisource.org,wikiversity.org,wikivoyage.org,wikidata.org,wikiworkshop.org,wikifunctions.org,wiktionary.org,mediawiki.org,wmfusercontent.org,w.wiki,wikimediacloud.org,wmnet,127.0.0.1,::1'
*   Trying [2620:0:861:2:208:80:154:145]:443...
* Connected to gitlab.wikimedia.org (2620:0:861:2:208:80:154:145) port 443 (#0)
...

Change #1333119 had a related patch set uploaded (by Brouberol; author: Brouberol):

[operations/puppet@production] gitlab: allow pods running in the dse clusters to egress to internal endpoint

https://gerrit.wikimedia.org/r/1333119

Change #1333120 had a related patch set uploaded (by Brouberol; author: Brouberol):

[operations/puppet@production] global_config: register the internal gitlab endpoint

https://gerrit.wikimedia.org/r/1333120

Change #1333124 had a related patch set uploaded (by Brouberol; author: Brouberol):

[operations/deployment-charts@master] airflow: allow gitsync to egress to the gitlab internal endpoint

https://gerrit.wikimedia.org/r/1333124

Change #1333119 merged by Arnaudb:

[operations/puppet@production] gitlab: allow pods running in the dse clusters to egress to internal endpoint

https://gerrit.wikimedia.org/r/1333119

Change #1333120 merged by Brouberol:

[operations/puppet@production] global_config: register the internal gitlab endpoint

https://gerrit.wikimedia.org/r/1333120

Thanks @brouberol, it is now possible to fetch data from gitlab's discovery record:

runuser@airflow-gitsync-5ddf9fcd68-lhqpk:/dags/.git$ timeout 3 git ls-remote https://gitlab.discovery.wmnet:8443/repos/data-engineering/airflow-dags.git|head -1
818a72515ca0e89aec4c96080967741725e455c4	HEAD

This removes the last identified blocker to move forward with T425441: gitlab behind CDN

Change #1333124 merged by Brouberol:

[operations/deployment-charts@master] airflow: allow gitsync to egress to the gitlab internal endpoint

https://gerrit.wikimedia.org/r/1333124

Confirmed!

brouberol@deploy1003:~$ k logs -f airflow-gitsync-85b56d87f8-ffdgh
INFO: detected pid 1, running init handler
{"logger":"","ts":"2026-09-01 09:48:47.043073","caller":{"file":"main.go","line":568},"level":0,"msg":"starting up","version":"4.2.4","pid":11,"uid":900,"gid":900,"home":"/home/runuser","flags":["--depth=1","--link=airflow_dags","--period=5m0s","--ref=main","--repo=https://gitlab.discovery.wmnet:8443/repos/data-engineering/airflow-dags.git","--root=/dags","--sparse-checkout-file=/etc/gitsync/sparse-checkout.conf"]}
{"logger":"","ts":"2026-09-01 09:48:47.044457","caller":{"file":"main.go","line":673},"level":0,"msg":"git version","version":"git version 2.39.2"}
{"logger":"","ts":"2026-09-01 09:48:48.169413","caller":{"file":"main.go","line":1682},"level":0,"msg":"update required","ref":"main","local":"818a72515ca0e89aec4c96080967741725e455c4","remote":"818a72515ca0e89aec4c96080967741725e455c4","syncCount":0}
{"logger":"","ts":"2026-09-01 09:48:48.969054","caller":{"file":"main.go","line":1728},"level":0,"msg":"updated successfully","ref":"main","remote":"818a72515ca0e89aec4c96080967741725e455c4","syncCount":1}

On our side, we still need to allow Blunderbuss (a system in charge of downloading artifacts from archiva, gitlab, external URLs, etc, and caching them to our HDFS cluster) to egress to the gitlab internal endpoint, and ensure all artifacts are addressed using the discovery.wmnet subdomain.

Change #1332720 abandoned by Arnaudb:

[operations/puppet@production] kubernetes: allow pod egress to text-lb for gitlab

Reason:

not needed anymore - https://phabricator.wikimedia.org/T435292#12274188

https://gerrit.wikimedia.org/r/1332720

Change #1333153 had a related patch set uploaded (by Brouberol; author: Brouberol):

[operations/deployment-charts@master] blunderbuss: allow egress to the internal gitlab endpoint

https://gerrit.wikimedia.org/r/1333153

Change #1333158 had a related patch set uploaded (by Brouberol; author: Brouberol):

[operations/puppet@production] gitlab: allow traffic from our analytics subnet

https://gerrit.wikimedia.org/r/1333158

Change #1333158 merged by Arnaudb:

[operations/puppet@production] gitlab: allow traffic from our analytics subnet

https://gerrit.wikimedia.org/r/1333158

We can now reach out to the gitlab private endpoint from the analytics VLAN, which will allow the hadoop workers to download the SQL/HQL files when running spark3-submit, as orchestrated by airflow.

brouberol@an-worker1200:~$ wget https://gitlab.discovery.wmnet:8443/hghani/movement-insights-requests/-/raw/main/T402058%20-%20SDS%201.1.2/sql/actor_metrics_hourly_pageviews/update_actor_metrics_hourly_pageviews.hql
--2026-09-01 12:32:02--  https://gitlab.discovery.wmnet:8443/hghani/movement-insights-requests/-/raw/main/T402058%20-%20SDS%201.1.2/sql/actor_metrics_hourly_pageviews/update_actor_metrics_hourly_pageviews.hql
Resolving gitlab.discovery.wmnet (gitlab.discovery.wmnet)... 2620:0:861:2:208:80:154:144, 208.80.154.144
Connecting to gitlab.discovery.wmnet (gitlab.discovery.wmnet)|2620:0:861:2:208:80:154:144|:8443... failed: Connection refused.
Connecting to gitlab.discovery.wmnet (gitlab.discovery.wmnet)|208.80.154.144|:8443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11465 (11K) [text/plain]
Saving to: ‘update_actor_metrics_hourly_pageviews.hql’

update_actor_metrics_hourly_pa 100%[=================================================>]  11.20K  --.-KB/s    in 0s

2026-09-01 12:32:02 (284 MB/s) - ‘update_actor_metrics_hourly_pageviews.hql’ saved [11465/11465]

Change #1333153 merged by jenkins-bot:

[operations/deployment-charts@master] blunderbuss: allow egress to the internal gitlab endpoint

https://gerrit.wikimedia.org/r/1333153

brouberol opened https://gitlab.wikimedia.org/repos/data-engineering/airflow-dags/-/merge_requests/2597

Use the internal gitlab endpoint when downloading query files at spark-submit time

brouberol merged https://gitlab.wikimedia.org/repos/data-engineering/airflow-dags/-/merge_requests/2597

Use the internal gitlab endpoint when downloading query files at spark-submit time

I have deployed the latest round of gitlab.wikimedia.org -> gitlab.discovery.wmnet replacements in airflow variables. We now have gitsync, spark-submit and blunderbuss all use the internal endpoint. We should be done.

Change #1339917 had a related patch set uploaded (by Aleksandar Mastilovic; author: Aleksandar Mastilovic):

[operations/deployment-charts@master] Chart to install Blunderbuss 2.9.11 with GitLab CDN support

https://gerrit.wikimedia.org/r/1339917

Change #1339917 merged by Bking:

[operations/deployment-charts@master] Chart to install Blunderbuss 2.9.11 with GitLab CDN support

https://gerrit.wikimedia.org/r/1339917