Tempo limite de rede intermitente no docker

Question

Estou tendo um problema de tempo limite de rede / http com um aplicativo docker-in-docker que está sendo executado em um cluster Kubernetes e preciso de ajuda para descobrir o que pode estar acontecendo.

Estou executando um contêiner do docker dentro do docker (é uma ferramenta de compilação). No contêiner mais interno, a compilação do docker trava ao executar esta linha no Dockerfile: apk add --no-cache tzdata

A saída do console diz: fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz

Eu tentei um curl simples com este URL e funciona cerca de 50% do tempo, o resto do tempo ele atinge o tempo limite. O problema também se limita ao URL do Alpine CDN. Por exemplo, posso baixar uma imagem do flickr.com 100% do tempo. Também está baixando 100% do tempo em um cluster diferente em um VPC diferente. Portanto, há algo particular nessa pilha específica do Kubernetes, e nesse URL específico, que está causando o problema. Preciso de ajuda é como pesquisar mais para tentar identificar o problema.

Eu reduzi o aplicativo à essência que destaca o problema. Aqui está a estrutura do projeto:

Aqui está app.py:

from time import sleep

while True:
    sleep(60)

Este é o Dockerfile:

FROM python:3.7-alpine3.11

RUN apk add --no-cache                                                  \
    docker

COPY entrypoint.sh /
RUN chmod 0700 /entrypoint.sh

RUN mkdir /app
WORKDIR /app/
COPY app /app/

ENTRYPOINT [ "/entrypoint.sh" ]

Este é o entrypoint.sh:

#!/bin/sh
set -e

echo 'Starting dockerd...'
# check if docker pid file exists (can linger from docker stop or unclean shutdown of container)
if [ -f /var/run/docker.pid ]; then
  rm -f /var/run/docker.pid
fi
mkdir -p /etc/docker
echo '{ "storage-driver": "vfs" }' > /etc/docker/daemon.json
nohup dockerd > /var/log/dockerd.log &

# The following command does not spawn execution to the background as
#     we need to leave something holding the container in run state.
echo "Starting canary app..."
exec python3 app.py

E service.yml

apiVersion: v1
kind: List
items:
- apiVersion: apps/v1
  kind: Deployment
  metadata:
    labels:
      run: canary
    name: canary
  spec:
    replicas: 1
    selector:
      matchLabels:
        run: canary
    template:
      metadata:
        labels:
          run: canary
      spec:
        containers:
          - image: canary
            imagePullPolicy: IfNotPresent
            name: canary
            securityContext:
              capabilities:
                add:
                  - SYS_ADMIN
              privileged: true
        dnsPolicy: ClusterFirst
- apiVersion: v1
  kind: Service
  metadata:
    name: canary
    labels:
      run: canary
  spec:
    ports:
      - port: 80
        protocol: TCP
    selector:
      run: canary
    sessionAffinity: None
    type: ClusterIP

Answer 1

O problema estava relacionado ao MTU. Nosso cluster está usando a rede Calico VXLAN, que tem um MTU de 1450. O contêiner Docker interno não estava tomando conhecimento disso e não parece ter sido detectado durante a descoberta de MTU do caminho (PMTUD). Estranhamente, esse era um problema com o Fastly CDN, e não com outros hosts de servidor que tentei, então esse foi um fator adicional de confusão. O problema foi embora quando eu configurei o MTU para os contêineres Docker internos para 1450 também.