[KANS] 3주차 - Calico CNI & Mode 정리
Calico Overview
- Calico 관련된 설정을 하게되면 calico datastore에 모든 정보가 저장됨. 이 정보를 기반으로 calico-node Pod가 동작함
- calicoctl로 Calico 관련 설정들에 대한 CRUD를 할 수 있음
- calico-node Pod는 데몬셋으로 동작함
- 데몬셋 Pod는 호스트의 네트워크 인터페이스를 공유해서 사용
- calico-node는 bird, felix, confd로 구성됨
- 노드가 신규로 생성되면 각 노드의 bird 간에 마치 명함을 교환하는 것처럼 BGP 라우팅 프로토콜을 통해 상호 정보를 교환함 (정보를 동적으로 광고)
- Felix는 Bird를 통해 BGP로 받은 정보를 호스트의 라우팅 테이블에 반영하는 역할과 iptables의 규칙을 수정하는 역할을 함
- iptables rule을 살펴보면 "cali"라는 prefix를 가진 rule들이 felix에 의해 설정된 항목들
- confd는 calico datastore에 저장된 데이터가 변경됐을 때 동적으로 반영해주는 역할을 함
- Flannel은 host-local의 IPAM을 사용하지만 Calico는 자체 IPAM 플러그인을 제공하고, calicoctl ipam 명령으로 현재 IP 할당 현황을 확인할 수 있음 (EKS의 VPC CNI도 자체 IPAM을 가지고 있음)
Tips) BPG 라우팅 프로토콜이란?
- 마치 차량 내비게이션이 목적지까지 최적 경로를 안내하는 것과 같이 BGP는 인터넷에서 데이터 패킷이 목적지로 가는 최적의 경로를 찾는 역할을 수행
- 인터넷은 여러 독립적인 네트워크(AS)로 구성되어 있는데 BGP는 이런 AS들이 서로 경로 정보를 교환할 수 있게 해주는 공용어 역할을 함
- BGP는 응용 계층(Layer 7)에서 작동하는 라우팅 프로토콜
- 단순히 최단 경로만을 선택하는 것이 아니라 네트워크 관리자가 설정한 정책(비용, 성능, 보안 등)에 따라 최적의 경로를 결정함
- 계속 변화하는 인터넷 상황에 대응하여 실시간으로 라우팅 정보를 업데이트하는 역할을 함
- BGP는 대규모 네트워크에서도 안정적으로 작동하고 지속적으로 확장될 수 있도록 설계되어 전 세계 네트워크가 서로 연결되어 원할한 인터넷 통신이 가능하도록 함
- ARP가 로컬 네트워크에서 IP-MAC 주소 매핑을 위해 사용된다면 BGP는 인터넷 상의 대규모 라우팅 결정을 위해 사용됨
- 쿠버네티스는 로컬 네트워크라고 볼 수도 있을 것 같은데 왜 Calico는 BGP를 사용할까?
- BGP는 대규모 네트워크에서 효율적으로 작동하도록 설계되었고, 수많은 노드와 IP 주소를 가진 큰 클러스터에서도 잘 동작할 수 있음
- 네트워크 관리자가 라우팅 정책을 세밀하게 제어할 수 있기 때문에 복잡한 네트워크 토폴로지와 요구사항을 처리할 수 있음
- 서로 다른 AS 간의 라우팅을 가능하게 하기 때문에 다양한 네트워크 환경에서도 통신을 용이하게 함
- 메시지 인증 등의 보안 기능을 제공하기 때문에 네트워크 안전성을 높일 수 있음
Calico 통신
동일 노드 내 Pod 간 통신은 내부에서 직접 통신됨
- 위 그림에서 pod1과 pod2가 통신할 때는 물리 네트워크 인터페이스인 eth0를 거치지 않고 Virtual Router(calico-node)에 의해 Pod간에 직접 통신을 수행함
- 내부적으로는 iptables FORWARD Rule 정책에 의해 통신이 가능해짐
- 즉, 동일 노드 내 Pod 간 통신에서는 터널 인터페이스는 미관여
Tips) 터널 인터페이스란?
- 노드 간 오버레이 네트워크를 구성하는데 사용되는 인터페이스이며 대표적으로 IPIP와 VXLAN이 있음
- IPIP 터널 인터페이스 : Layer3 IP 패킷을 다른 IP 패킷 안에 캡슐화하는 IPIP 캡슐화를 사용하여 노드 간 통신
- VXLAN 터널 인터페이스 : Layer2 프레임을 UDP 패킷으로 캡슐화하는 VXLAN 캡슐화를 사용하여 노드 간 통신
- Wireguard 터널 인터페이스 : 오픈소스인 Wireguard를 사용해서 서버간 통신에도 패킷을 암호화해서 전송
- Zero trust를 위해 다양한 곳에서 사용되고 있고, Cillium에서도 서버간 통신 암호화에 Wireguard를 사용함
Pod 생성 시 네트워크 변화
아래와 같이 Pod가 생성된 워커 노드에서 ip -c link 명령으로 네트워크 인터페이스 현황을 확인해보면 cali로 시작하는 네트워크 네임스페이스가 추가된 것을 확인할 수 있고, @if3과 같이 Pod의 네트워크 인터페이스와 매핑정보를 확인할 수 있음
link-netns를 통해 연결된 네트워크 네임스페이스를 확인할 수 있는데 실제로 아래와 같이 lsns -t net 명령을 실행해보면 해당 Pod를 위한 별도의 네트워크 네임스페이스가 생성된 것을 확인할 수 있음. 이 네트워크 네임스페이스는 pause 컨테이너를 통해 공유된 네트워크 네임스페이스라는 것도 알 수 있음
호스트의 라우팅 정보를 확인해보면 172.16.158.0/24가 blackhole로 지정되어 있고, 새로 생긴 Pod도 동일한 ip range를 사용하기 때문에 트래픽이 전달되지 않을 것 같아 보이지만 라우팅은 항상 longist 매치를 하기 때문에 더 세분화된 경로로 설정된 경우를 우선으로 함. 이로 인해 명확하게 목적지가 지정된 라우팅을 우선하고 지정되지 않은 패킷에 대해서만 블랙홀로 drop됨
Tips) 블랙홀 라우팅이란?
- 특정 IP 주소나 네트워크로 향하는 트래픽을 의도적으로 버리는(drop) 라우팅 기법
- 지정된 목적지로 가는 트래픽을 블랙홀이라는 특수한 인터페이스로 보내고, 블랙홀은 해당 트래픽을 단순 폐기 후 어떠한 응답도 보내지 않음
- DDoS 공격 방어나 악성 트래픽 차단, 불필요한 트래픽을 제거(라우팅 루프 방지)하여 네트워크 효율성을 높이는 용도로 활용됨
- 잘못 설정하면 정상적인 트래픽도 차단될 수 있기 때문에 주의해야하고 신중한 설정과 모니터링을 해야함
- 쿠버네티스에서는 사용되지 않는 IP 범위로의 트래픽을 효과적으로 차단해서 클러스터의 네트워크 보안과 효율성을 향상시킴
Pod 외부 통신
Pod에서 인터넷 통신 시에는 해당 노드의 네트워크 인터페이스 IP 주소로 MASQUERADE(출발지 IP가 변경) 되어서 외부에 연결됨
이 때는 터널 인터페이스는 관여하지 않고 eth0를 통해서 외부로 통신함. Calico의 기본 설정은 natOutgoing: true이기 때문에 iptables에 MASQUERADE Rule에 의해서 외부에 연결됨
이 때 노드의 네트워크 인터페이스로 tcpdump를 실행해보면 외부로 요청하는 트래픽이 Pod의 IP가 아닌 노드의 IP로 변경되어 외부로 나가는 것을 알수 있음
이는 위에 보이는 것처럼 conntrack 명령을 해보면 처음 출발은 Pod의 IP로 출발했으나 SNAT가 발생하여 외부로 나갈때와 돌아올 때 노드의 IP로 변경되어 있는 것을 볼 수 있음
다른 노드에 있는 Pod와 통신
다른 노드로 트래픽이 향할 때 IP 패킷을 한번 더 감싸서 전송함 (IPIP 터널)
- 참고로 Azure는 IPIP 패킷은 block되어 있어서 사용 불가능, UDP는 사용가능하기 때문에 VXLAN 모드는 지원됨
tcpdump를 실행해보면 cali 인터페이스, tunl0 인터페이스, eth0 인터페이스 모두 트래픽이 잡히는 걸 확인할 수 있고, eth0 네트워크 인터페이스에서는 IPIP 터널로 패킷이 전송되는 것을 확인할 수 있음
IPIP 모드는 터널 인터페이스를 거치고 패킷을 캡슐화하고 디캡슐화하는 과정이 필요하기 때문에 Direct 모드 보다는 지연이 발생함. VXLAN은 패킷을 감싼다는 개념은 같지만 UDP를 사용하기 때문에 IPIP 모드보다는 성능이 좋음
Direct 모드는 Pod의 IP를 그대로 사용하는데 AWS EC2의 경우 인스턴스에 할당된 MAC이나 IP가 아닌 다른 IP로 트래픽이 들어오면 기본적으로 패킷을 drop해버림. 이를 방지하려면 소스/대상 확인 변경 메뉴에서 소스/대상 확인 설정을 중지 해야함
