본문으로 바로가기 본문 바로가기
WIKI 기술 지식 베이스

자주 묻는 질문

원문 보기 위키 갱신

Calico Open Source를 쓰면서 자주 나오는 궁금증을 모은 FAQ 페이지예요. 네트워킹 모드와 IP 주소 관리, BGP, 정책 동작, 플랫폼 지원 같은 주제를 질문과 답 형태로 정리했어요. 궁금한 항목만 골라서 읽어도 괜찮아요.

출처: 문서

본문

왜 Calico를 사용하나요?

Calico가 해결하려는 문제는 대규모 환경에서 워크로드(VM, 컨테이너 등)를 네트워킹하는 일이에요. 이 문제를 풀던 기존 L2 기반 방식은 대규모 환경에서 문제를 드러내요. 이와 비교하면 Calico가 더 확장 가능하고, 더 단순하고, 더 유연하다고 생각해요. 한 사이트에 노드가 몇 개를 넘어선다면 Calico를 살펴볼 가치가 있어요.

Calico는 또한 풍부한 네트워크 보안 모델을 제공해요. 운영자와 개발자가 의도 기반(intent-based) 네트워크 보안 정책을 선언하면, 그 정책이 컨테이너, VM, 서버 클러스터 전반에 분산 방화벽 규칙으로 자동 렌더링돼요.

이 주제를 더 자세히 다룬 내용은 블로그 글 Why Calico?을 참고하세요.

Calico는 IPv6와 함께 동작하나요?

네! Calico의 핵심 컴포넌트는 IPv6를 기본적으로 지원해요. 다만 Calico가 통합하는 모든 오케스트레이터가 아직 IPv6를 지원하지는 않아요.

제 컨테이너에 169.254.1.1로 가는 라우트가 있는 이유는 무엇인가요?

Calico 네트워크에서는 각 호스트가 자신이 호스팅하는 워크로드의 게이트웨이 라우터 역할을 해요. 컨테이너 배포에서 Calico는 169.254.1.1을 Calico 라우터의 주소로 사용해요. 링크 로컬 주소를 활용하면 소중한 IP 주소를 아낄 수 있고, 적절한 주소를 직접 설정하게 만들지 않아도 돼요.

LAN 네트워킹을 설정하는 데 익숙한 분에게는 라우팅 테이블이 조금 이상해 보일 수 있지만, 서브넷 로컬 게이트웨이 대신 명시적 라우트를 사용하는 방식은 WAN 네트워킹에서는 꽤 흔해요.

컨테이너화된 kubelet과 함께 쓰면 Calico가 동작하지 않는 이유는 무엇인가요?

Calico 호스티드(hosted) 설치 방식은 매니페스트에 지정된 호스트 디렉터리에 필요한 CNI 바이너리와 구성을 각 Kubernetes 노드에 배치해요. 기본으로 바이너리는 /opt/cni/bin에, 구성은 /etc/cni/net.d에 놓여요.

hyperkube로 kubelet을 컨테이너로 실행할 때는 설치된 CNI 네트워크 플러그인과 구성을 kubelet 컨테이너에 마운트해서 볼 수 있도록 해야 해요.

예를 들어 kubelet-wrapper 서비스에 다음 인자를 추가하세요.

--volume /etc/cni/net.d:/etc/cni/net.d \
--volume /opt/cni/bin:/opt/cni/bin \

위 볼륨 마운트가 없으면 kubelet이 Calico CNI 바이너리를 호출하지 않아요. 그 결과 Calico 워크로드 엔드포인트가 만들어지지 않고, Calico 정책도 적용되지 않아요.

Calico CNI 로그는 어떻게 확인하나요?

Calico CNI 플러그인은 로그를 stderr로 내보내고, kubelet이 그 로그를 기록해요. 로그가 어디에 남는지는 kubelet 설정 방식에 달려 있어요. systemd를 사용하는 배포라면 journalctl로 확인할 수 있어요.

로그 레벨은 CNI 네트워크 구성 파일에서 log_level 키의 값을 바꿔 설정할 수 있어요. 자세한 내용은 Configuring the Calico CNI plugins를 참고하세요.

CNI 플러그인 로그는 /var/log/calico/cni에서도 찾을 수 있어요.

pod IP 범위는 어떻게 설정하나요?

Calico IPAM을 사용하면 IP 주소는 IP Pool에서 할당돼요.

기본적으로 활성화된 모든 IP 풀이 사용돼요. 하지만 CNI network config에서 IP 주소 관리에 쓸 IP 풀을 지정하거나, Kubernetes annotation으로 pod 단위로 지정할 수도 있어요.

pod에 특정 IP 주소를 할당하려면 어떻게 하나요?

대부분의 사용 사례에서 Kubernetes pod에 특정 IP 주소를 할당할 필요는 없고, 대신 Kubernetes 서비스를 쓰는 게 권장돼요. 그래도 pod에 특정 주소를 할당해야 한다면 Calico는 두 가지 방법을 제공해요.

  • cni.projectcalico.org/ipAddrs annotation으로 Calico IPAM에서 사용 가능한 IP를 요청할 수 있어요.
  • cni.projectcalico.org/ipAddrsNoIpam annotation으로 IP를 요청할 수도 있어요. 이 annotation은 설정된 IPAM 플러그인을 우회하기 때문에 대부분의 경우에는 위 annotation을 쓰는 게 권장돼요.

자세한 내용은 CNI 플러그인 레퍼런스 문서의 Requesting a specific IP address 섹션을 참고하세요.

위에서 언급한 169.254.1.1 주소가 제 호스트에는 안 보이는 이유는 무엇인가요?

Calico는 호스트의 다른 구성을 방해하지 않도록 애써요. 각 워크로드 인터페이스의 호스트 쪽에 게이트웨이 주소를 추가하는 대신, Calico는 인터페이스에 proxy_arp 플래그를 설정해요. 그 덕분에 호스트가 게이트웨이처럼 동작해 169.254.1.1에 대한 ARP에 응답하면서도, 실제로 그 IP 주소를 인터페이스에 할당할 필요가 없어요.

모든 cali* 인터페이스의 MAC 주소가 ee:ee:ee:ee:ee:ee인 이유는 무엇인가요?

일부 환경에서는 커널이 영속적인 MAC 주소를 만들지 못하기 때문에 Calico가 직접 MAC 주소를 할당해요. Calico는 포인트 투 포인트 라우티드 인터페이스를 사용하기 때문에 트래픽이 데이터 링크 계층에 도달하지 않아 MAC 주소가 실제로 쓰이지 않아요. 그래서 모든 cali* 인터페이스가 같은 MAC 주소를 가져도 괜찮아요.

Kubernetes pod이 나가는 연결을 시작하지 못하게 막을 수 있나요?

네! Kubernetes NetworkPolicy API는 v1.8에서 egress 정책 지원을 추가했어요. calicoctl을 사용해 egress 정책을 구성하면 라벨, Kubernetes 네임스페이스, CIDR, 포트를 포함한 지원되는 Calico 정책 프리미티브 전체를 기준으로 pod이 나가는 연결을 막을 수 있어요.

Calico가 프록시 ARP를 사용한다고 들었어요. 프록시 ARP는 많은 문제를 일으키지 않나요?

그럴 수 있지만, Calico가 사용하는 방식에서는 그렇지 않아요.

컨테이너 배포에서 Calico는 169.254.1.1 주소를 해결할 때만 프록시 ARP를 사용해요. 컨테이너 안의 라우팅 테이블이 모든 트래픽을 169.254.1.1 게이트웨이로 보내도록 보장하기 때문에, 컨테이너가 ARP로 알아보는 IP는 그 하나뿐이에요.

Calico는 PCI/DSS 요구사항을 준수하나요?

PCI 인증은 종단 간 시스템 전체에 적용되고, Calico는 그 일부가 될 거예요. 현재 대부분의 솔루션이 VLAN을 사용한다는 건 알고 있지만, PCI 요구사항 문서를 연구한 결과 Calico도 그 요구사항을 충족하며 문서 어디에도 VLAN 사용을 강제하는 내용은 없다고 판단했어요.

IP 풀에서 IP-in-IP와 NAT outgoing은 어떻게 켜나요?

  1. 현재 IP 풀 구성을 조회해요.

    calicoctl get ipPool --export -o yaml > pool.yaml

  2. IP 풀 구성을 수정해요.

    IP-in-IP와 NAT outgoing을 켜도록 풀의 spec을 고치세요. (수정할 수 있는 다른 설정은 IP pools를 참고하세요.)

    - apiVersion: projectcalico.org/v3
  kind: IPPool
  metadata:
   name: ippool-1
  spec:
    cidr: 192.168.0.0/16
    ipipMode: Always
    natOutgoing: true

  3. 수정한 파일을 로드해요.

    calicoctl replace -f pool.yaml

Calico는 저장된 상태를 어떻게 유지하나요?

Calico 배포에서 상태는 글로벌 상태인지 로컬 상태인지에 따라 몇 군데에 저장돼요.

로컬 상태는 단일 컴퓨트 호스트에 속한 상태로, 실행 중인 단일 Felix 인스턴스와 연관돼요(커널 라우트, tap 장치 같은 것들이죠). 로컬 상태는 전적으로 호스트의 Linux 커널이 저장하고, Felix는 임시 미러로만 보관해요. 덕분에 Felix는 사실상 상태가 없고, 한쪽에는 커널이 백킹 데이터스토어로, 다른 쪽에는 etcd가 데이터 소스로 있어요.

Felix가 재시작되면 시작할 때 커널을 조회해 현재 로컬 상태를 학습해요. 그다음 etcd에서 자신이 가져야 할 로컬 상태 전부를 읽고, 커널을 그에 맞게 갱신해요. 이 접근은 복원력이 뛰어나서, Felix가 재시작돼도 VM이나 컨테이너 접근이 갑자기 끊기지 않아요. Linux 커널만 돌아가고 있으면 기능은 그대로 유지돼요.

글로벌 상태의 대부분은 플러그인을 호스팅하는 컴포넌트가 마스터로 관리해요.

  • OpenStack의 경우 Neutron 데이터베이스가 그 역할을 해요. OpenStack 플러그인은 Neutron 데이터베이스를 조회해 배포 전체의 상태를 파악하고, 그 상태가 etcd에 반영되어 Felix까지 전달돼요.
  • 어떤 경우에는 etcd 자체가 데이터의 마스터 복사본을 갖고 있어요. 일부 Docker 배포는 필요한 복원력 특성을 갖춘 etcd 클러스터를 두고 시스템 구성 전체를 저장하기 때문에, etcd가 중요한 데이터에 적합한 저장소가 되도록 구성되기도 해요.
  • 다른 오케스트레이션 시스템에서는 플러그인이 직접 소유하거나 오케스트레이터 자체가 소유하는 분산 데이터베이스에 저장될 수 있어요.

Calico 네트워크에서 유일하게 남은 상태 저장소는 BGP 세션이에요. BGP는 라우트의 분산 데이터베이스에 가까운 역할을 해요. 이 BGP 상태는 오케스트레이터가 제공한 글로벌 상태를 바탕으로 Felix가 구성한 호스트별 라우트의 복제본일 뿐이에요.

이렇게 상태를 거의 저장하지 않기 때문에 Calico 설계는 매우 단순해요. 모든 컴포넌트는 필요할 때 상태를 다시 동기화하기 때문에 위험 없이 종료하고 재시작할 수 있어요. 덕분에 컴포넌트 동작을 모델링하기 매우 쉽고, 버그의 복잡도도 줄어들어요.

Calico가 레이어 2를 권한다고 들었어요. 레이어 3가 아니었나요? 무슨 일이죠?

Calico가 데이터 센터에 호스팅되는 워크로드에 제공하는 것(순수한 레이어 3 네트워크)과, Calico 프로젝트가 운영자에게 권장하는 기반 네트워크 패브릭 구축 방식을 구분하는 게 중요해요.

Calico의 핵심 원칙은 애플리케이션과 워크로드는 통신에 IP 연결성만 있으면 충분하다는 거예요. 그래서 테넌트 애플리케이션과 워크로드를 서로 그리고 더 넓은 세계와 연결하는 IP 포워딩 네트워크를 만들어요.

다만 기반이 되는 물리 패브릭도 당연히 구축해야 해요. 여기서 Calico는 레이어 2 패브릭(여기)과 레이어 3 패브릭(여기)을 각각 Calico와 통합하는 방법을 논의했어요. 이것이 Calico 모델의 큰 강점 중 하나예요. 테넌트 애플리케이션과 워크로드에 보여주는 것과 인프라를 분리(decoupling)할 수 있거든요.

서로 다른 인터커넥트 방식에 대한 생각은 위에서 언급했지만, 패브릭을 만드는 레이어 2 방식과 레이어 3 방식이 있고 그 결정이 라우트 스케일에 영향을 줄 수 있다고 말한다고 해서, Calico가 "이더넷으로 회귀"한다거나 테넌트 애플리케이션에 레이어 2를 권한다는 뜻은 아니에요. 어떤 아키텍처로 패브릭을 만들든 IP 패킷은 항상 포워딩해요.

가상/물리 방화벽 없이 정책/연결성을 어떻게 제어하나요?

Calico는 매우 풍부한 보안 정책 모델을 제공해요. Calico 네트워크 안에서 라우티드 트래픽의 첫 홉과 마지막 홉(소스와 목적지 컴퓨트 호스트)에 정책을 적용해요.

이 모델은 중앙 집중식 방화벽 기반 모델보다 장애에 훨씬 강해요. 특히 Calico 접근 방식에는 단일 장애 지점(SPOF)이 없어요. 방화벽을 적용하는 장치가 실패했다면 그 트래픽에 관여한 워크로드 중 하나도 이미 실패했다는 뜻이거든요(방화벽은 컴퓨트 호스트가 적용하니까요).

이 모델은 스케일 아웃에도 매우 유리해요. 정책 구성의 중앙 저장소는 두지만, 정책을 필요한 곳, 즉 네트워크 가장자리(호스트)에 적용하기 때문에 규칙이 데이터 센터 토폴로지와 자동으로 일치해요. 스케일 아웃이 쉽고, 단일 방화벽의 장점(규칙을 한 곳에서 관리)은 취하면서 단점(단일 장애 지점, 상태 공유, 트래픽 헤어핀 등)은 피할 수 있어요.

마지막으로, 노드의 도달 가능성과 그 노드에 적용되는 정책을 분리해요. BGP로 네트워크 토폴로지를 배포해서 모든 노드가 모든 엔드포인트로 가는 방법을 알게 해요. 두 노드가 통신해야 하는지와, 통신한다면 어떻게인지는 정책으로 결정해요. 정책이 바뀌어 이전에는 통신하면 안 됐던 두 엔드포인트가 이제 통신해야 한다면, 바꿔야 하는 건 정책뿐이고 도달 가능성 정보는 그대로예요. 나중에 통신을 거부해야 한다면 정책만 다시 갱신하면 되고, 도달 가능성 역시 바꿀 필요가 없어요.

Calico는 Neutron API와 어떻게 상호작용하나요?

Calico's interpretation of Neutron API calls 문서에서 다양한 Neutron API 호출이 Calico 동작으로 어떻게 변환되는지 아주 자세히 다뤄요.

docker run의 -p 플래그가 기대대로 동작하지 않는 이유는 무엇인가요?

-p 플래그는 Docker에게 docker0 브리지를 통해 Docker 호스트의 포트를 컨테이너의 포트에 연결하는 포트 매핑을 설정하라고 지시해요.

호스트의 컨테이너들이 docker0 브리지 인터페이스에 연결되어 있다면, Calico는 같은 호스트에 있는 워크로드 사이의 보안 규칙을 적용할 수 없어요. 브리지 위의 모든 컨테이너가 서로 통신할 수 있게 되죠.

Calico 컨테이너가 풀 안의 어떤 IP 주소든, 서브넷 네트워크/브로드캐스트 주소까지 쓸 수 있나요?

네! Calico는 완전 라우티드 네트워크라서 Calico 풀 안의 모든 IP 주소는 워크로드에 할당하는 프라이빗 IP 주소로 쓸 수 있어요. 즉 .0이나 .255로 끝나는 IPv4 주소처럼 L2 서브넷에서 흔히 예약되는 주소도 전혀 문제 없이 사용할 수 있어요.

네트워크 트래픽을 제 Calico 클러스터 안팎으로 어떻게 가져오나요?

Calico 네트워크로 트래픽을 주고받는 권장 방식은 기존 데이터 센터 L3 라우터와 BGP 피어링을 맺고, 인터넷에서 접근해야 하는 컨테이너에는 글로벌 라우터블 IP(퍼블릭 IP)를 할당하는 거예요. 이렇게 하면 NAT 없이도 들어오는 트래픽을 컨테이너로 직접 라우팅할 수 있어요. 이 플랫 L3 방식은 탁월한 네트워크 확장성과 성능을 제공해요.

흔한 시나리오는 컨테이너 호스트들이 서버실의 랙이나 데이터 센터 전체처럼 자체적으로 격리된 레이어 2 네트워크에 있는 경우예요. 그 네트워크로의 접근은 라우터를 거치고, 그 라우터가 모든 컨테이너 호스트의 기본 라우터 역할도 해요.

인프라가 이에 해당한다면 [Configure outgoing NAT](../networking/configuring/workloads-outside-cluster.mdx 문서가 무엇을 해야 하는지 더 자세히 설명해요. 반대로 레이어 3(IP) 패브릭을 갖고 있다면 Calico over IP fabrics에 데이터 센터 네트워킹 권장 사항이 자세히 나와 있어요. 여러분의 환경에 대해 논의하려면 get in touch도 환영해요.

프라이빗 IP 주소를 가진 컨테이너의 나가는 트래픽에 NAT를 켜려면 어떻게 하나요?

프라이빗 IP 주소를 가진 컨테이너가 인터넷에 접근할 수 있게 하려면 데이터 센터의 기존 아웃바운드 NAT 기능(보통 데이터 센터 보더 라우터가 제공)을 사용할 수 있어요.

다른 방법으로는 Calico IP 풀에서 Calico의 내장 아웃바운드 NAT 기능을 켜는 방법이 있어요. 이 경우 Calico는 각 컨테이너가 호스팅되는 컴퓨트 노드에서 아웃바운드 NAT를 수행해요.

cat <<EOF | calicoctl apply -f -
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: ippool-1
spec:
  cidr: <CIDR>
  natOutgoing: true
EOF

<CIDR>는 IP 풀의 CIDR이에요. 예를 들어 192.168.0.0/16 같은 값이죠.

기억하세요: 컨테이너의 보안 프로파일도 인터넷으로 나가는 트래픽을 허용해야 해요. 정책 구성 방법은 여러분이 쓰는 오케스트레이션 시스템에 맞는 가이드를 참고하세요.

프라이빗 IP 주소를 가진 컨테이너로 들어오는 트래픽에 NAT를 켜려면 어떻게 하나요?

앞서 말했듯이, 인터넷에서 접근해야 하는 컨테이너로 트래픽을 받는 권장 방식은 퍼블릭 IP 주소를 부여하고 Calico가 데이터 센터의 기존 L3 라우터와 피어링하도록 구성하는 거예요.

이게 불가능한 경우라면 데이터 센터의 기존 보더 라우터에서 인바운드 NAT(DNAT라고도 해요)를 구성할 수 있어요. 또는 컨테이너가 실행 중인 호스트에서 포트 매핑과 함께 인바운드 NAT를 구성할 수도 있어요.

  1. NAT 규칙을 담을 expose-ports라는 새 체인을 만들어요.

    iptables -t nat -N expose-ports

  2. OUTPUT과 PREROUTING 체인에서 그 체인으로 점프해요.

    iptables -t nat -A OUTPUT -j expose-ports
iptables -t nat -A PREROUTING -j expose-ports

    SUCCESS: OUTPUT 체인은 호스트 자신이 시작한 트래픽이 지나가고, PREROUTING 체인은 다른 곳에서 오는 트래픽이 지나가요.

  3. 노출할 포트마다 expose-ports 체인에 규칙을 추가해요. <PUBLIC_IP>는 포트를 노출할 때 쓸 호스트 IP로, <PUBLIC_PORT>는 호스트 포트로 바꾸세요.

    iptables -t nat -A expose-ports -p tcp --destination <PUBLIC_IP> \
--dport <PUBLIC_PORT> -j DNAT  --to <CALICO_IP>:<SERVICE_PORT>

예를 들어 CALICO_IP로 192.168.7.4를 할당한 컨테이너가 있고, 그 안에서 NGINX가 8080 포트로 돌고 있다고 해봐요. 이 서비스를 80 포트로 노출하고 호스트 IP가 192.0.2.1이라면 다음 명령어를 실행할 수 있어요.

iptables -t nat -N expose-ports
iptables -t nat -A OUTPUT -j expose-ports
iptables -t nat -A PREROUTING -j expose-ports

iptables -t nat -A expose-ports -p tcp --destination 192.0.2.1 --dport 80 -j DNAT --to 192.168.7.4:8080

이 명령어들은 호스트가 재시작될 때마다 다시 실행해야 해요.

기억하세요: 컨테이너의 보안 프로파일도 노출된 포트로 들어오는 트래픽을 허용해야 해요. 정책 구성 방법은 여러분이 쓰는 오케스트레이션 시스템에 맞는 가이드를 참고하세요.

퍼블릭 클라우드 환경에서 Calico를 실행할 수 있나요?

네. Calico 호스트 사이에 L3 피어링이나 L2 연결을 허용하지 않는 퍼블릭 클라우드에서 실행 중이라면 Calico IP 풀에서 IP-in-IP를 켜면 돼요.

cat <<EOF | calicoctl apply -f -
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: ippool-1
spec:
  cidr: <CIDR>
  ipipMode: Always
  natOutgoing: true
EOF

그러면 Calico는 IP-in-IP로 Calico 호스트 사이의 트래픽을 라우팅해요.

AWS에서 최고의 성능을 내려면 IP-in-IP나 VXLAN 대신 Source/Destination Check를 비활성화할 수 있어요. 단, 모든 인스턴스가 VPC의 같은 서브넷에 있을 때만 그렇게 할 수 있어요. EC2 인스턴스가 호스트 인터페이스 IP 주소와 일치하지 않는 트래픽을 처리하려면 이 설정이 Disable이어야 해요. 클러스터가 여러 서브넷에 걸쳐 있을 때도 마찬가지로 적용돼요. 클러스터 트래픽이 서브넷을 넘는다면 캡슐화 오버헤드를 줄이려고 ipipMode(또는 vxlanMode)를 CrossSubnet으로 설정하세요. 자세한 내용은 configuring overlay networking을 확인하세요.

Source/Destination Check는 Felix configuration, AWS CLI, EC2 콘솔로 비활성화할 수 있어요. 예를 들어 AWS CLI를 쓰면 이렇게 해요.

aws ec2 modify-instance-attribute --instance-id <INSTANCE_ID> --source-dest-check "{\"Value\": false}"

cat <<EOF | calicoctl apply -f -
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: ippool-2
spec:
  cidr: <CIDR>
  natOutgoing: true
EOF

AWS에서 IP-in-IP를 쓰면 워크로드 사이에 연결이 아예 없거나, 양방향으로 ping해야만 연결이 보이는 이유는 무엇인가요?

기본적으로 AWS 보안 그룹은 들어오는 IP-in-IP 트래픽을 차단해요.

그런데 인스턴스가 최근에 IP-in-IP 트래픽을 밖으로 보낸 상태에서 들어오는 IP-in-IP 트래픽을 받으면, AWS는 그 트래픽을 나가는 연결에 대한 응답으로 보고 통과시켜요. 그래서 트래픽이 차단되다가 갑자기 동작하기 시작하는 아주 혼란스러운 동작이 생겨요.

이 문제를 해결하려면 보안 그룹에 호스트 사이의 인바운드·아웃바운드 IP-in-IP 트래픽(IP 프로토콜 번호 4)을 허용하는 규칙을 추가하세요.

Calico for OpenStack에서 VM이 기본 게이트웨이를 ping하지 못하는 이유는 무엇인가요?

기본 게이트웨이 개념은 같은 Neutron 네트워크에 속한 VM 사이에 직접 레이어 2(이더넷) 연결을 시뮬레이션하는 OpenStack 네트워킹 드라이버에서 의미가 있어요. 그런 시뮬레이션에서는 다음과 같이 동작해요.

  • VM이 같은 네트워크의 다른 VM으로 보낼 때는 VM 입장에서 라우팅이 전혀 없어요. (물론 컴퓨트 호스트가 다른 서브넷에 있을 수 있으니 언더레이 네트워크에는 라우팅이 있을 수 있어요.)

  • VM이 자기 네트워크 밖으로 보낼 때는 시뮬레이션된 레이어 2에 따라 먼저 기본 게이트웨이로 가고, 그다음 목적지로 라우팅돼요.

하지만 OpenStack은 Calico를 포함해 Neutron 네트워크의 VM 사이에 라우팅을 사용하는 드라이버도 허용해요. 특히 Calico에서는 VM이 보내는 모든 패킷이 VM의 컴퓨트 호스트에서 레이어 2가 종단 처리되고 IP 라우팅돼요. 같은 네트워크의 다른 VM으로 보내든 다른 어디로 보내든 마찬가지예요. 그래서 Calico에는 "기본 게이트웨이" 개념이 필요 없고, Calico에서는 크게 의미도 없어요. VM이 "내 기본 게이트웨이는 내가 보낸 패킷이 IP 라우팅될 수 있는 첫 홉"이라고 생각하거나 어떤 식으로든 그것에 의존한다면, Calico 네트워킹에서는 그 생각이 틀려요.

그런데 여기까지 말하고 나서 덧붙이면, DHCP 서버(dnsmasq)와 관련한 세부적인 기술적 이유 때문에 Calico는 실제로 관련 Neutron 네트워크에 VM이 하나 이상 있는 모든 컴퓨트 호스트에 기본 게이트웨이 IP를 설정해요. 즉 Linux 네트워크 인터페이스에 바인드해요. 그리고 그것이 Linux에서 VM이 그 IP를 ping할 수 있는 데 필요한 재료 중 하나예요.

그럼에도 VM이 그 IP를 ping할 수 없는 이유는, Calico가 기본으로 iptables 규칙을 구성해 자기 호스트로 들어오는 거의 모든 통신을 차단하기 때문이에요. 일반적으로 워크로드가 자기 호스트에 접근해 손상시킬 수 있으면 안 되니까요. DHCP 같은 몇 개의 핀홀은 있지만, 그 목록에는 ping(ICMP Echo)은 없어요. 컴퓨트 호스트에서 watch 'sudo iptables-save -c | grep DROP' 같은 명령어를 실행한 뒤, 그 호스트의 VM에서 기본 게이트웨이 IP로 ping을 시도하면 ping 패킷이 보내지고 차단될 때마다 DROP 카운트가 늘어나는 걸 볼 수 있어요.

이 동작은 DefaultEndpointToHostAction이라는 구성 파라미터가 제어하며 기본값은 DROP이에요. 시연을 위해서라면 /etc/calico/felix.cfg에 DefaultEndpointToHostAction = RETURN을 추가하고, sudo systemctl restart calico-felix로 Felix를 재시작하면, 그 호스트의 VM이 기본 게이트웨이를 ping할 수 있게 돼요. 다만 DefaultEndpointToHostAction = RETURN 상태로 상시 운영하는 것은 권장하지 않아요. 악의적인 VM이 자기 호스트를 손상시킬 가능성을 열어두기 때문이에요.

정리하면, Calico에서 VM이 보통 기본 게이트웨이를 ping하지 못하는 데는 두 가지 이유가 있어요.

  1. 컴퓨트 노드에서 모든 것을 라우팅하는 Calico의 방식을 고려하면, 기본 게이트웨이 개념은 사실 맞지 않고 필요하지도 않아요. 이것은 OpenStack을 위한 Calico 네트워킹의 근본적인 특성이에요.

  2. Calico의 iptables 규칙은 일반적으로 VM이 자기 호스트에 접촉하는 것을 허용하지 않아요.

Calico는 IP 멀티캐스트를 할 수 있나요?

Calico는 각 pod이 /32를 받는 라우티드 L3 네트워크예요. pod을 위한 브로드캐스트 도메인이 없어요. 그래서 멀티캐스트가 브로드캐스트의 부수 효과로 동작하지는 않아요. 멀티캐스트를 동작시키려면 호스트가 어떤 식으로든 멀티캐스트 게이트웨이 역할을 해야 해요. Calico 아키텍처는 그 경우까지 확장될 수 있도록 설계됐지만, 아직 제품의 일부는 아니에요.

더 알아보기 (Learn more)

자주 겪는 문제는 FAQ에서 먼저 확인하고, 그래도 해결되지 않으면 해당 주제의 레퍼런스 문서로 이어서 살펴보세요. OpenStack이나 클라우드 환경이라면 위의 IP-in-IP와 NAT 관련 항목이 특히 도움이 됩니다.