VPN 위의 Docker Swarm: 작업은 실행되지만 서비스 호출은 실패한다

두 사이트 모두에서 작업은 실행되지만 서비스 간 호출은 시간 초과된다. overlay에는 노드 간 경로, 변환되지 않은 주소, VXLAN을 위한 50바이트의 여유가 필요하다.

두 사이트에 걸친 세 개의 매니저와 다섯 개의 워커가 터널로 연결되어 있고, docker service ls는 양쪽에서 실행 중인 작업을 보여 주지만 서비스 간 호출은 시간 초과된다. Swarm 로그에는 잘못된 것이 없어 보인다. 이 조합은 데이터 플레인 문제의 전형이다. 컨트롤 플레인은 노드를 찾았고, 캡슐화된 프레임은 목적지에 도달하지 못했다.

overlay보다 메시가 먼저 있어야 한다

Swarm의 overlay는 캡슐화된 프레임을 노드 주소 사이로 직접 보낸다. 즉 모든 노드에는 다른 모든 노드가 변환 없이 도달할 수 있는 주소가, 터널이 제공하는 인터페이스 위에 필요하다. 클라이언트를 공개 포트로 데려가는 터널만으로는 부족하다. 언더레이는 양방향으로 노드에서 노드로 라우팅할 수 있어야 한다.

Swarm을 건드리기 전에 이것부터 시험하라. 각 노드에서 피어의 터널 주소로 가는 경로를 확인하고 ping을 보낸 뒤 제어 포트를 시험하라. ping은 되고 포트가 안 되면 터널은 정상이고 필터가 가로막고 있다.

ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377

경로가 tun0나 wg0 대신 물리 인터페이스를 가리키면, overlay는 원격 사이트가 도달할 수 없는 주소로 캡슐화하고 증상은 패킷 손실처럼 보인다.

각 노드가 어떤 주소를 광고하는지 확인하라

데몬은 주소 하나를 광고하고 피어는 그것을 데이터 플레인에 쓴다. 여러 네트워크가 있는 호스트에서는 터널이 다른 것을 나르는 동안 LAN이나 공인 주소를 광고하기 쉽다. 추측하지 말고 확인하고, 기본값이 틀렸다면 참여할 때 --advertise-addr로 고정하라. 자기만 도달할 수 있는 주소를 광고한 노드도 swarm에는 참여하며, 장애는 나중에 사이트 간에 통신하지 못하는 서비스로 나타난다.

광고 주소를 나중에 바꾸는 것은 설정 편집이 아니다. 노드가 빠졌다가 다시 참여해야 한다.

노드별 광고 주소를 메모에 적어 두라. 비대칭 장애의 대부분을 설명해 준다.

보통 범인은 masquerade다

노드와 터널 사이에 게이트웨이가 있을 때 흔한 실수는 물리 인터페이스로 나가는 모든 것에 masquerade를 거는 것이다. 그러면 overlay의 내부 주소까지 다시 쓰이므로 모든 피어가 게이트웨이에서 오는 것처럼 보이고 VXLAN 피어끼리 서로를 알아보지 못한다. 결과는 일반 ping은 되는데 캡슐화 트래픽이 사라지거나 한 방향만 흐르는 것이다.

overlay 프리픽스는 게이트웨이를 거쳐 라우팅하고 변환하지 않은 채로 두라. 다른 프리픽스에 변환이 정말 필요하다면 거기에만 한정하고 overlay가 쓰는 범위에는 절대 적용하지 마라.

ip route add 172.16.0.0/22 via 10.20.0.1
iptables -t nat -I POSTROUTING -o tun0 -s 172.16.0.0/22 -j ACCEPT

규칙의 순서와 내용을 함께 확인하라. 체인 앞쪽의 넓은 MASQUERADE가 뒤쪽의 좁은 예외를 이긴다.

VXLAN은 패킷 안의 여유가 필요하다

VXLAN은 나르는 프레임에 50바이트를 더한다. 1500바이트 언더레이가 1500바이트 내부 프레임을 나르면 어떤 경로도 전달하지 못할 캡슐화 패킷이 생기고, 장애는 크기 문제가 아니라 간헐적인 서비스 검색처럼 보인다. 양쪽 끝에서 터널 MTU를 낮추거나, 드라이버가 들어맞는 페이로드를 광고하도록 overlay MTU를 설정하라.

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay

ingress 네트워크는 자동으로 만들어지므로, 바꾸려면 그 자리에서 편집하는 것이 아니라 지우고 다시 만들어야 한다.

터널의 한쪽만 고친다면 더 작은 MTU가 여전히 문제를 좌우한다.

로그가 아니라 데이터 플레인을 보라

양쪽 끝에서 VXLAN 포트를 캡처하라. 한쪽에서 나가 반대쪽에 도착하는 프레임은 언더레이가 정상이고 문제가 overlay 안에 있다는 뜻이다. 나가기만 하고 도착하지 않는 프레임은 경로나 필터를 뜻한다. 아예 나가지 않는 프레임은 출발지 주소가 틀렸다는 뜻이다.

몇 초 뒤 사라지는 서비스 검색 실패는 보통 패킷 여유나 흔들리는 경로를 가리키며 raft 쿼럼 문제가 아니다.

정상일 때의 캡처를 남겨 두라. 깨졌을 때와 비교하는 편이 설정을 다시 읽는 것보다 빠르다.

관련 글