Intermittierendes Netzwerk-Timeout im Docker

Question

Ich habe ein Netzwerk- / http-Timeout-Problem mit einer Docker-in-Docker-App, die in einem Kubernetes-Cluster ausgeführt wird, und ich benötige Hilfe, um herauszufinden, was möglicherweise passiert.

Ich führe einen Docker-Container in Docker aus (es ist ein Build-Tool). Im innersten Container hängt der Docker-Build an der Ausführung dieser Zeile in der Docker-Datei: apk add --no-cache tzdata

Die Konsolenausgabe lautet: fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz

Ich habe eine einfache Locke mit dieser URL ausprobiert und sie funktioniert ungefähr 50% der Zeit, der Rest der Zeit läuft sie ab. Das Problem ist auch auf die alpine CDN-URL beschränkt. So kann ich beispielsweise 100% der Zeit ein Bild von flickr.com herunterladen. Außerdem wird 100% der Zeit in einem anderen Cluster in einer anderen VPC heruntergeladen. Daher hat dieser bestimmte Kubernetes-Stapel und diese bestimmte URL etwas Besonderes, das das Problem verursacht. Ich brauche Hilfe, um weiter zu graben und das Problem zu identifizieren.

Ich habe die App auf das Wesentliche reduziert, das das Problem hervorhebt. Hier ist die Projektstruktur:

Hier ist app.py:

from time import sleep

while True:
    sleep(60)

Dies ist die Docker-Datei:

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" ]

Dies ist 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

Und 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

Das Problem hing mit der MTU zusammen. Unser Cluster verwendet ein Calico VXLAN-Netzwerk mit einer MTU von 1450. Der innere Docker-Container hat dies nicht berücksichtigt und scheint während der Pfad-MTU-Erkennung (PMTUD) nicht erfasst worden zu sein. Seltsamerweise war dies ein Problem mit dem Fastly CDN und nicht mit anderen Server-Hosts, die ich ausprobiert habe. Das war also ein zusätzlicher Störfaktor. Das Problem verschwand, als ich die MTU für die inneren Docker-Container ebenfalls auf 1450 stellte.