oc rsync kładzie procesy mastera OKD

Może to brzmieć nieco dziwnie, ale tak właśnie jest. Próbowałem skonfigurować montowanie NFS w docker registry OKD (według tego tutoriala). Podczas oc rsync z wnętrza kontenera docker-registry okazało się, że procesy mastera OKD padają, bo health check uznaje, że wystąpił problem z łącznością. Wynikło to stąd, że oc rsync nie ma funkcji ograniczania przepustowości, a jeśli w pełni wykorzysta sieć lokalną, to nie zostaje już pasmo dla samego klastra.

Kilka rzeczy wyciągniętych z logów (/var/log/messages):

19,270,533,120  70%   57.87MB/s    0:02:19  The connection to the server okd-master:8443 was refused - did you specify the right host or port?

Liveness probe for "okd-master.local_kube-system (xxx):etcd" failed (failure): member xxx is unhealthy: hot unhealthy result

okd-master origin-node: cluster is unhealthy

Początkowy transfer z kontenera docker-registry jest na poziomie 200MB/s. Nie jestem do końca pewien, czy sieć faktycznie jest w stanie osiągnąć taką prędkość. Problem jest powtarzalny – po wyzwoleniu liveness probe master, etcd i webconsole są restartowane, co może prowadzić do niestabilności klastra. Jeśli to możliwe, powinniśmy tego unikać. Niestety kontener docker-registry jest bardzo podstawowy, bez ip, ifconfig, ssh, scp ani żadnych narzędzi, które mogłyby pomóc w przesłaniu plików na zewnątrz. Ale…

• adres IP kontenera możesz sprawdzić w webconsole
• możesz uruchomić serwer HTTP python -m SimpleHTTPServer na porcie 8000
• następnie możesz pobrać plik poleceniem wget x.x.x.x:8000/file.tar --limit-rate=20000k

To naprawdę zabawne, że kontenerowi brakuje podstawowych narzędzi, ale ma Pythona. Ustaw w wget limit na rozsądnym poziomie, tak aby sieć wewnętrzna nie była w pełni wykorzystana. Podsumowując: nie spotkałem się z takim problemem w żadnym innym środowisku, ani bare-metal, ani zwirtualizowanym, więc może to być związane w szczególności z SDN Microsoft Azure i tym, jak zachowuje się przy takim obciążeniu ruchem.