CNI 와 Neutron 의 공존¶

참고

OpenStack on Kubernetes 에서는 OpenStack 서비스가 Kubernetes 위에서 실행되는 동시에, 그 서비스가 생성한 가상 머신에는 OpenStack 네트워크가 제공된다. 이 문서는 이때 컨테이너 네트워크 인터페이스(CNI)와 OpenStack 네트워킹 서비스(Neutron)가 각각 무엇을 담당하며 어떤 방식으로 공존하는지 설명한다.

두 스택이 공존하는 이유¶

OpenStack-Helm 은 Keystone, Nova, Neutron, Glance 등의 애플리케이션 프로그래밍 인터페이스(API)와 서버 구성 요소를 Kubernetes 파드로 배포한다. 이 파드들과 RabbitMQ, 데이터베이스 같은 백엔드 서비스가 통신하려면 Kubernetes 의 파드 네트워크가 필요하다.

한편 OpenStack 사용자가 생성한 Nova 가상 머신은 Kubernetes 파드가 아니다. 가상 머신의 네트워크, 서브넷, 포트, 라우터, 보안 그룹 및 플로팅 IP 는 OpenStack Networking 서비스인 Neutron 이 관리한다.

따라서 하나의 OpenStack on Kubernetes 환경에는 다음 두 네트워크가 동시에 존재한다.

Kubernetes 계층: CNI 가 OpenStack 서비스 파드와 백엔드 파드의 통신을 담당한다.
OpenStack 계층: Neutron 이 Nova 가상 머신과 테넌트 네트워크의 통신을 담당한다.

Kubernetes 가 설치된 물리 노드
├─ Kubernetes 계층
│  └─ OpenStack 서비스 파드 ─ CNI 기반 파드 네트워크
└─ OpenStack 계층
   └─ Nova 가상 머신 ─────── Neutron 네트워크
                             │
                   공통 물리 네트워크

두 네트워크는 같은 물리 노드와 물리 네트워크를 사용할 수 있지만 서로 다른 대상을 담당한다. CNI 는 파드를 연결하고, Neutron 은 가상 머신을 연결한다.

OpenStack 서비스 간의 네트워크 생성·변경 요청은 CNI 기반 파드 네트워크를 통해 Neutron 에 전달될 수 있다. 그러나 가상 머신의 실제 사용자 패킷이 OpenStack 서비스 파드를 거치는 것은 아니다. OpenStack 의 API 및 네트워크 관리 서비스가 원하는 네트워크 상태를 만들면, 이후 가상 머신의 통신은 Neutron 이 구성한 별도의 경로에서 처리된다.

OpenStack API 접근과 가상 머신 접근의 차이¶

외부에서 OpenStack 환경으로 들어오는 요청은 목적지에 따라 OpenStack API 에 대한 관리 요청과 가상 머신 애플리케이션에 대한 사용자 트래픽으로 구분할 수 있다.

구분	OpenStack API 접근	가상 머신 애플리케이션 접근
목적	가상 머신 생성·조회·삭제	가상 머신에서 실행되는 서비스 사용
목적지	`nova-api` 파드	Nova 가 관리하는 가상 머신
대표 경로	인그레스·로드밸런서 → Kubernetes 서비스 → API 파드	프로바이더 네트워크 → `br-ex` → 플로팅 IP → 가상 머신
담당 영역	Kubernetes 와 OpenStack 제어 서비스	Neutron 이 구성한 가상 머신 패킷 경로

첫 번째 경로는 OpenStack 자원을 생성하거나 조회하기 위한 관리 요청이고, 두 번째 경로는 가상 머신에서 실행되는 애플리케이션의 데이터를 주고받는 경로이다. 목적지가 다르기 때문에 필요한 노출 방식과 보안 정책도 다르다.

OpenStack 사용자
    └─ 인그레스·로드밸런서 ─ nova-api 서비스 ─ nova-api 파드

가상 머신 서비스 사용자
    └─ 프로바이더 네트워크 ─ br-ex ─ Neutron 라우터·플로팅 IP ─ 가상 머신

통신 사례로 보는 계층 구분¶

통신 사례	담당 계층	개념적인 경로
OpenStack API 파드가 다른 서비스 파드에 요청	Kubernetes 계층	송신 파드 → CNI 기반 파드 네트워크 → 대상 파드
같은 노드의 가상 머신 간 통신	Neutron	송신 가상 머신 → 노드의 가상 네트워크 → 수신 가상 머신
서로 다른 노드의 가상 머신 간 통신	Neutron	송신 가상 머신 → 송신 노드 → 물리 네트워크 → 수신 노드 → 수신 가상 머신
플로팅 IP 를 통한 외부 접근	Neutron	외부 네트워크 → Neutron 라우팅·주소 변환 → 대상 가상 머신

같은 물리 네트워크 위에서 두 종류의 통신이 흐르더라도 정책 경계는 분리된다. 파드 통신 정책은 Kubernetes 계층에서, 가상 머신의 보안 그룹과 라우팅 정책은 Neutron 계층에서 적용된다. 따라서 “파드 통신은 정상인데 가상 머신 통신만 실패하는” 상황이 발생할 수 있으며, 운영자는 먼저 어느 계층의 문제인지 구분해야 한다.

OpenStack-Helm 과 네트워크 구현체의 관계¶

OpenStack-Helm 은 특정 CNI 나 Neutron 네트워크 백엔드를 하나로 고정하지 않는다. OpenStack 서비스를 Kubernetes 에 배포하고, 선택한 네트워크 구현체를 Helm 설정값으로 구성할 수 있도록 제공한다.

Neutron 백엔드에는 Open vSwitch(OVS)나 Open Virtual Network(OVN) 기반 기술이 사용될 수 있다.

구분	예시
CNI 표준을 사용하는 파드 네트워크 구현체	Calico, Cilium, Flannel, ovn-kubernetes
Neutron 네트워크 백엔드	ML2/OVS, ML2/OVN, SR-IOV
현재 실습 구성	Calico 와 Neutron ML2/OVS

따라서 OpenStack on Kubernetes 의 네트워크 구조를 이해하려면 OpenStack-Helm 자체만 보는 것이 아니라 Kubernetes 에 적용된 CNI 플러그인과 Neutron 에 적용된 네트워크 백엔드의 조합을 함께 확인해야 한다. 이 조합에 따라 두 네트워크를 독립적인 기술 스택으로 운영할 수도 있고, 양쪽에 공통된 네트워크 기술을 적용해 운영 경험과 도구를 공유할 수도 있다.

통합 접근¶

CNI 와 Neutron 이 공존하는 방식은 크게 각 스택을 독립적으로 운영하는 구성과 양쪽에서 OVN 계열 기술을 사용하는 구성으로 나누어 볼 수 있다. 이는 CNI 와 Neutron 의 책임을 합치는 것이 아니라, 서로 다른 두 네트워크를 어떤 기술적·운영적 관계로 구성할지에 관한 선택이다.

두 스택을 각각 운영¶

Kubernetes 에는 Calico, Flannel, Cilium 같은 CNI 플러그인을 사용하고, OpenStack 가상 머신 네트워크에는 Neutron 의 별도 백엔드를 사용하는 방식이다. CNI 는 파드 네트워크를, Neutron 은 가상 머신 네트워크를 담당한 채 각각의 제어 영역과 운영 수명주기를 유지한다.

장점

기술 선택과 업그레이드를 독립적으로 수행할 수 있다. 한쪽의 구현체를 교체하거나 버전을 올릴 때 다른 쪽을 동시에 변경할 필요가 없다.
각 생태계에서 널리 검증된 구성을 선택할 수 있다. 조직의 정책, 성능 요구 및 운영 경험에 맞는 CNI 와 Neutron 백엔드를 각각 선택할 수 있다.
장애 범위를 구분하기 쉽다. 서비스 파드 통신 장애는 CNI 와 Kubernetes 서비스를, 가상 머신 통신 장애는 Neutron 포트·라우터·보안 그룹을 우선 조사할 수 있다.
변경의 영향 범위를 제한할 수 있다. 한쪽 네트워크의 변경이나 장애가 다른 쪽 데이터 평면에 직접 전파되지 않아 단계적인 검증과 롤백 계획을 세우기 쉽다.

고려 사항

주소 계획을 이중으로 관리해야 한다. 파드 주소 대역과 Neutron 테넌트 네트워크 대역이 겹치지 않도록 구축 단계에서 주소 범위를 정해야 한다.
정책이 서로 다른 위치에서 적용된다. 파드 접근 제어는 Kubernetes 네트워크 정책으로, 가상 머신 접근 제어는 Neutron 보안 그룹으로 관리한다.
관측 및 장애 대응 도구가 나뉜다. Kubernetes 의 파드·서비스·CNI 도구와 OpenStack 의 network·port·router 도구를 모두 사용해야 한다.
공통 물리 네트워크의 자원을 함께 사용한다. 같은 노드 NIC 와 물리 네트워크를 사용한다면 최대 전송 단위(MTU), 대역폭, 주소 경로를 함께 고려해야 한다.

OVN 계열 기술을 양쪽에서 사용¶

Kubernetes CNI 로 ovn-kubernetes 를 선택하고 Neutron 도 OVN 기반 백엔드를 사용하면 파드 네트워크와 가상 머신 네트워크가 모두 OVS·OVN 계열 기술을 사용한다.

OVN-Kubernetes ─ 파드 네트워크 ─┐
                                 ├─ 공통 기술 기반: OVN·OVS
Neutron + OVN ─ 가상 머신 네트워크 ┘

이 접근의 핵심은 두 계층에서 공통된 네트워크 기술을 사용해 운영 지식과 도구를 재사용하는 것이다. 다만 ovn-kubernetes 는 Kubernetes 의 파드, 서비스, 네트워크 정책을, Neutron 은 OpenStack 의 network, port, router, 보안 그룹을 각각 관리한다. 같은 기술을 선택해도 두 네트워크나 제어 영역이 자동으로 하나가 되는 것은 아니다. 데이터베이스와 제어 영역까지 공유하려면 호환성, 주소 관리, 정책 소유권과 장애 영향 범위를 별도로 설계하고 검증해야 한다.

장점

공통된 기술 모델과 운영 경험을 재사용할 수 있다. 양쪽 모두 OVN 의 논리 네트워크와 OVS 데이터 평면을 기반으로 하므로 관측 체계를 일관되게 가져갈 수 있다.
호스트의 네트워크 기술 구성을 일관되게 가져갈 수 있다. 기존의 OVN·OVS 모니터링, 성능 튜닝 또는 하드웨어 가속 경험을 양쪽에 활용할 수 있다.
향후 연계 가능성을 검토하기 쉽다. 파드와 가상 머신 연결, 공통 물리 네트워크 연계 같은 고급 통합을 설계할 때 공통 개념과 도구를 활용할 수 있다.

고려 사항

버전과 업그레이드 호환성을 확인해야 한다. ovn-kubernetes 와 Neutron 이 요구하는 OVN·OVS 버전 범위가 다를 수 있다.
정책과 주소 관리의 소유권은 여전히 분리된다. Kubernetes 네트워크 정책과 Neutron 보안 그룹은 서로 다른 API 와 리소스이다.
공통 기술 장애가 넓은 영향을 줄 수 있다. OVN·OVS 운영 구성이나 호스트 자원에 공통 문제가 생기면 두 네트워크가 동시에 영향을 받을 수 있어 장애 격리와 롤백 계획이 필요하다.

접근 방식 비교¶

항목	각각 운영	OVN 계열 기술 사용
기술 선택	각 계층에 적합한 구현체를 독립적으로 선택	두 계층에서 OVN·OVS 기반 기술을 사용
업그레이드	각 스택의 수명주기를 분리하기 쉬움	사용하는 OVN·OVS 버전의 호환성을 함께 고려
운영 지식	Kubernetes 와 OpenStack 도구를 각각 학습	공통된 OVN·OVS 개념과 관측 경험을 재사용 가능
정책	Kubernetes 정책과 Neutron 보안 정책이 분리	공통 기술을 사용해도 정책의 의미와 소유권은 구분 필요
복잡성	스택 수는 많지만 경계가 명확	기술은 일관되지만 통합 수준이 높을수록 결합도 증가

어느 방식을 선택하더라도 CNI 와 Neutron 이 담당하는 대상 자체는 달라지지 않는다. 중요한 것은 두 네트워크를 무조건 하나로 합치는 것이 아니라 운영 환경에 맞게 책임 범위와 장애 경계를 명확하게 설계하는 것이다.

실제 네트워크 구성과 가상 머신 패킷 경로¶

사용자가 가상 머신을 생성할 때 네트워크가 어떻게 구성되고, 구성이 끝난 뒤 실제 패킷이 어떤 경로로 이동하는지 구분해 보자. 이는 앞에서 설명한 두 네트워크에 새로운 네트워크를 하나 더 추가하는 것이 아니다. 같은 OpenStack 환경을 네트워크 설정을 만드는 과정과 만들어진 설정에 따라 패킷을 전달하는 과정으로 나누어 보는 것이다.

네트워크 구성 과정과 패킷 이동 과정¶

네트워크를 구성하는 과정: 가상 머신이 사용할 네트워크, 포트, IP, 보안 그룹과 전달 경로를 만든다. 이를 제어 평면(control plane)이라고 한다.
실제 패킷이 이동하는 과정: 구성된 가상 네트워크 장치(TAP), OVS 와 라우터를 따라 가상 머신의 패킷이 이동한다. 이를 데이터 평면(data plane)이라고 한다.

도로에 비유하면 네트워크 구성은 도로와 신호 체계를 만드는 작업이고, 패킷 이동은 완성된 도로 위로 자동차가 이동하는 것에 해당한다.

네트워크·포트·정책 정의 → TAP·OVS·라우터 구성 → 가상 머신 패킷 전달

두 용어는 특정 장비나 별도의 물리 네트워크 이름이 아니라 기능을 구분하는 표현이다. 다음 질문으로 쉽게 구분할 수 있다.

지금 전달되는 내용이 네트워크를 만들거나 변경하기 위한 명령인가, 아니면 가상 머신 애플리케이션이 주고받는 실제 데이터인가?

구분	네트워크를 구성하는 과정	실제 패킷이 이동하는 과정
목적	네트워크와 전달 규칙 생성	가상 머신의 실제 통신 전달
전달 내용	API 요청, 포트·라우터·정책 정보	이더넷 프레임, IP·TCP·UDP 패킷
주요 구성 요소	Nova API, Neutron Server, 데이터베이스, 메시지 큐, 에이전트	가상 머신 가상 네트워크 인터페이스(vNIC), TAP, OVS, Virtual Extensible LAN(VXLAN), 라우터, 물리 네트워크 인터페이스 카드(NIC)
동작 시점	생성·변경·삭제 시	가상 머신 통신이 발생할 때마다
대표 장애	가상 머신 생성 실패, 포트가 DOWN	가상 머신은 ACTIVE 지만 ping 이나 외부 접속 실패

장애 증상으로 담당 계층 구분하기¶

CNI 와 Neutron 은 같은 노드와 물리 네트워크를 공유할 수 있지만 관리 대상과 정책 경계는 분리된다. 통신 장애가 발생하면 먼저 파드와 가상 머신 중 어느 대상에서 문제가 발생했는지 구분해야 한다.

증상	우선 확인할 영역	대표 확인 대상
OpenStack API 파드끼리 통신하지 못함	Kubernetes 계층	파드, 서비스, 엔드포인트, Calico, 네트워크 정책
가상 머신 생성 또는 포트 연결이 완료되지 않음	OpenStack 네트워크 구성 과정	Nova, Neutron Server, 메시지 큐, Neutron 에이전트, 포트 바인딩
같은 노드의 가상 머신끼리 통신하지 못함	가상 머신의 로컬 패킷 경로	TAP, `br-int`, 보안 그룹, 가상 머신 포트
다른 노드의 가상 머신끼리만 통신하지 못함	오버레이 네트워크(overlay)와 언더레이 네트워크(underlay)	`br-tun`, VXLAN, 터널 IP, 노드 간 연결, MTU
내부 통신은 되지만 플로팅 IP 접속이 안 됨	외부 연결 경로	`br-ex`, 라우터, 플로팅 IP, 보안 그룹, 외부 방화벽

예를 들어 OpenStack API 호출과 파드 통신은 정상인데 가상 머신의 ping 만 실패한다면 CNI 보다 Neutron 포트, 보안 그룹과 OVS 경로를 먼저 확인하는 것이 적절하다. 반대로 API 파드 사이의 통신부터 실패한다면 가상 머신 데이터 경로보다 Kubernetes 서비스와 CNI 상태를 먼저 확인해야 한다.