Unable to apk add or apk update with default repositories

[DvdChe]

Hello,I'm trying to build containers with dind in Gitlab-CI on k8s.

Problem is that the container can be blocked when it is calling apk command such as apk add <any packet> or apk update .

It's not happening all the time but once in two generally and only with Alpine ( No problem at all with Debian )

This behavior occurs in any project, with any dockerfile and even with the simplest file as possible with just aapk updatecommand in the dockerfile.

Here is the output of a blocked build job :

Step 8/18 : RUN apk update --verbose
 ---> Running in c92605754e8c
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz

Nothing will happens until jobs got killed at the job timeout.Another example :

Step 8/18 : RUN apk update --verbose
 ---> Running in c92605754e8c
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
v3.10.2-18-g578c97338a [http://dl-cdn.alpinelinux.org/alpine/v3.10/main]
v3.10.2-7-g312cad7bde [http://dl-cdn.alpinelinux.org/alpine/v3.10/community]
OK: 10339 distinct packages available
Removing intermediate container c92605754e8c
 ---> 68a10fedd184
Step 9/18 : RUN apk add --verbose --update alpine-sdk git
 ---> Running in 81675b71cf07
(1/38) Upgrading musl (1.1.22-r2 -> 1.1.22-r3)

I tried to run manually apk commands in interactive shell, on a blocked container and the apk command works always successfully.

I also made a strace on the processes which are blocked and nothing happens. same thing with tcpdump.

The apk --verbose don't show anything.

I already investigated on the network side and every curl,ping or dig or whatever succeed.

The only workaround i found consists to replace the default repository ( dl-cdn.alpinelinux.org ) by another such as uk.alpinelinux.or and then, call apk commands.

It's always working like this.I would like to know if i'm the only one who have this issue and if there is a more convenient fix instead of this workaround ?

Thanks for your help.

[wglambert]

I'd also encountered this issue, on inspecting the packets the stream just paused with no error or termination, then after a period of two minutes exactly the stream would continue completely normally. The two minutes was an interval however, so after that period it might not do anything, might have needed to wait four, six, or eight minutes for it to continue where it left off.

The workaround I found was to use host networking. The issue was only in a containerized Alpine or Debian container when trying to connect to the fastly cdn for packages.

[Laur1nMartins]

I have this exact issue across different VMs. I used wireguard:alpine and wanted to add squid but it just hangs on fetching the APKINDEX.tar.gz. The host can download the file just fine. The most recent try used a freshly installed docker.

The workaround with network_mode: host works though.