[HomeLab] Calico와 Tailscale 충돌 문제

서론

내부망에 쿠버네티스 클러스터를 올리고 외부의 인바운드를 열어놓지 않은 상황이었다.
워크로드 MVP 개발을 마무리한 후에 특정 서비스를 외부망에 열어놓으려 했다.
반대로 특정 서비스는 내부망에서만 접근이 가능하도록 하려 했다.

VPN을 쓸까?

클러스터는 Calico CNI를 사용하고 있는 상태였고 각 노드와 내부망에 접근하기 위해 VPN을 직접 구축하려 했다.
직접 구축해도 되었지만 이건 별도로 해도 상관 없을 것 같았고 빠르게 사용하기 위해서 Tailscale을 각 노드에 설치했다.

MetalLB의 IP 대역 할당이 정상적으로 이루어지지 않는 문제

NodePort를 써도 충분했지만 서비스를 LoadBalancer 타입으로 서빙하고 싶었다.
그래서 MetalLB를 설정하고 DHCP의 IP 대역을 정리해서 IP Pool로 일부 대역을 할당했다.

• MetalLB에 대한 내용은 기회가 되면 따로 다뤄보겠다.

 

여기서 문제가 생긴다.
내부망에서 테스트 용으로 올려둔 서비스가 접근이 되지 않았다.

문제 원인을 하나하나 추적해보기로 했다.

• DHCP가 할당하는 IP가 충돌한다. ❌
  • DHCP가 할당할 수 있는 IP 대역을 분리했다.
• Calico의 Internal IP의 CIDR 대역과 클러스터의 Pod CIDR 대역이 일치하지 않는다. ❌
  • 오버레이를 쓰니 상관 없다고 생각했다.
• MetalLB를 L2 모드로 동작하도록 설정했다. ❌
  • ARP를 쓰니 게이트웨이를 통해서 해당 대역이 전파된다.

원인 파악

하나하나 따져보았지만 마땅한 원인을 찾지 못하고 있었다.
추가로 활용할 수 있는 정보가 없을까 했다.

Calico-CLI를 설치하고 각 노드의 피어 연결을 확인했다.
Calico가 피어 연결을 Tailscale 인터페이스를 활용하고 있었다.

./kubectl-calico node status

Calico process is running.

IPv4 BGP status
+--------------+-------------------+-------+------------+-------------+
| PEER ADDRESS |     PEER TYPE     | STATE |   SINCE    |    INFO     |
+--------------+-------------------+-------+------------+-------------+
| 100.xx.xx.xx | node-to-node mesh | start | 2024-xx-xx | Connect     |
| 100.xx.xx.xx | node-to-node mesh | start | 2024-xx-xx | Connect     |
| 100.xx.xx.xx | node-to-node mesh | start | 2024-xx-xx | Connect     |
| 100.xx.xx.xx | node-to-node mesh | start | 2024-xx-xx | Connect     |
+--------------+-------------------+-------+------------+-------------+

워커 노드 하나에 접근에 ARP 테이블도 확인했다.
ARP가 정상적으로 전파되면 각 노드의 테이블에 서비스의 External IP가 등록되어야 했지만 찾지 못하고 있었다.

 

문득 든 생각은 VPN 메시로 설치한 Tailscale에 문제가 있지 않을까 생각이 들었다.
ARP를 통해서 External IP를 게이트웨이를 통해서 전파해야 했다.
하지만 Calico가 노드 피어링을 VPN Mesh을 통해 하고 있었기에 내부망의 게이트웨이를 찾지 못하고 있다고 생각했다.

 

felix/bird 로그도 함께 찾아보자.

calico-node 파드 로그를 보면 felix가 리눅스의 네트워크 인터페이스를 tailscale0로 변경했다.

felix/int_dataplane.go 1286: Linux interface addrs changed. addrs=set.Set{~~~~~} ifaceName="tailscale0"

 

felix가 route 테이블을 제대로 갱신했는지도 살펴봤다.
기존에는 아래와 같이 tunl0 인터페이스가 존재했지만 이 인터페이스가 생성되지 않았다.

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
...
Calico 대역1     <워커 노드 1>     255.255.255.192 UG    0      0        0 tunl0
Calico 대역2     <워커 노드 2>     255.255.255.192 UG    0      0        0 tunl0
Calico 대역3     <워커 노드 3>     255.255.255.192 UG    0      0        0 tunl0
...

 

Calico는 기본 IPIP 모드로 설치되었고 여기서 노드 간의 네트워크 터널링을 위한 tunl0가 존재하지 않았다.
결국 Calico의 노드 Peer 연결이 Established 되지 않고 Connect 에서 멈춰있는 이유도 여기에 있나 싶었다.

임시 방편

일련의 사고 흐름을 우선 멈추고 클러스터 노드 간의 통신이 다시 이루어지게 하려 했다.
다시 노드 BGP Mesh의 피어링 주소를 내부망 주소로 바꾸고 Calico를 갱신했다.

Calico도 다시 tunl0 인터페이스를 생성했고 Peering도 다시 연결된 것을 확인할 수 있었다.

Received interface addresses update msg=&intdataplane.ifaceAddrsUpdate{Name:"tunl0", Addrs:set.Typed[string]{~~~~}}

./kubectl-calico node status

Calico process is running.

IPv4 BGP status
+--------------+-------------------+-------+------------+-------------+
| PEER ADDRESS |     PEER TYPE     | STATE |   SINCE    |    INFO     |
+--------------+-------------------+-------+------------+-------------+
| <내부망 IP 1>  | node-to-node mesh | up    | 2024-xx-xx | Established |
| <내부망 IP 2>  | node-to-node mesh | up    | 2024-xx-xx | Established |
| <내부망 IP 3>  | node-to-node mesh | up    | 2024-xx-xx | Established |
| <내부망 IP 4>  | node-to-node mesh | up    | 2024-xx-xx | Established |
+--------------+-------------------+-------+------------+-------------+

 

After that

Tailscale 설치 과정에서 felix가 정상적인 라우팅 테이블을 생성하지 못해서 발생한 문제였다. 

 

우선 다시 클러스터를 연결했지만 노드 접속을 위해서는 VPN 자체는 써야했다.
클러스터 내 리소스로 Tailscale을 배포하고 외부에 노출되지 않는 서비스에 접근하는 것 역시 가능하다.

 

하지만 나는 노드 자체도 접근하기를 원했기에 다시금 VPN을 재설정하려고 한다.

이어서는 다시 Tailscale을 설정하면서 왜 네트워크 인터페이스가 정상적으로 생성되지 못했는지도 알아보겠다.

 

 

<해당 포스팅은 작성자의 다른 블로그로 이관될 수 있습니다.>