OpenStack Zed 수동 구축 - 11. kuryr-kubernetes(4)

Kuryr-Kubernetes 환경에서 Pod와 서비스가 정상적으로 작동하려면, 쿠버네티스의 API 서버와 통신이 가능해야 하며, 이를 위해 **OpenStack의 Neutron 라우터가 Pod와 서비스 대역을 중계(L3 Connectivity)**해주어야 합니다.

1. 인프라 기반 마련: 기존 Router(router02) 활용

신규 라우터를 생성할 수도 있지만, 이미 OpenStack Zed 수동 구축 과정에서 생성해 둔 router02를 활용하면 자원 효율성을 높일 수 있습니다. 이 라우터는 이미 외부 네트워크와 연결되어 있어 Pod와 Service의 외부 통신(SNAT)을 위한 게이트웨이 역할을 수행할 준비가 되어 있습니다.

2. 네트워크 및 라우터 인터페이스 구성

Pod 서브넷(10.1.0.0/16)과 Service 서브넷(10.2.0.0/16)을 router02에 인터페이스로 연결하여 L3 계층의 통신 경로를 확보합니다.

• 이유: 쿠버네티스의 파드(Pod)들은 사설 대역을 사용합니다. 이들이 클러스터 외부의 API 서버와 통신하거나, 쿠버네티스 서비스(ClusterIP/LoadBalancer)를 호출하려면 계층 간(Layer 3) 연결이 필수적입니다. 라우터가 없다면 Pod는 자신의 대역에 갇혀 외부(API 서버 등)로 나갈 경로를 찾지 못합니다.

Kuryr가 Pod와 Service 네트워크를 제어할 수 있도록, OpenStack 내부에 전용 네트워크와 서브넷을 구축하고 기존 라우터와 통합하는 과정입니다.

1단계. Pod 및 Services 네트워크 생성

가장 먼저 격리된 네트워크를 생성합니다. Pod 대역과 서비스 대역을 분리하여 관리합니다.

Bash

 

# Pod 네트워크 생성
openstack network create pod

# Services 네트워크 생성
openstack network create services

2단계. 네트워크별 서브넷 구축

각 네트워크의 IP 대역을 할당합니다. DHCP는 Kuryr가 담당하므로 --no-dhcp 옵션을 사용합니다.

Bash

 

# Pod 서브넷 생성 (10.1.0.0/16)
openstack subnet create --network pod --no-dhcp \
    --gateway 10.1.255.254 \
    --subnet-range 10.1.0.0/16 \
    pod_subnet

# Services 서브넷 생성 (10.2.0.0/16)
openstack subnet create --network services --no-dhcp \
    --gateway 10.2.255.254 \
    --ip-version 4 \
    --allocation-pool start=10.2.128.1,end=10.2.255.253 \
    --subnet-range 10.2.0.0/16 \
    service_subnet

3단계. 라우터 인터페이스 연결 (L3 Connectivity)

생성한 서브넷들을 기존 router02에 연결하여 Pod와 외부, Pod와 서비스 간의 통신 경로를 확보합니다.

Bash

 

# 1. 게이트웨이 포트 생성
openstack port create --network pod --fixed-ip ip-address=10.1.255.254 pod_subnet_router
openstack port create --network services --fixed-ip ip-address=10.2.255.254 service_subnet_router

# 2. 라우터 연결 (생성된 포트의 ID를 입력하세요)
openstack router add port router02 <pod_subnet_router_ID>
openstack router add port router02 <service_subnet_router_ID>

 

4. 보안 그룹(Security Group) 설정: Pod와 서비스 간 격리

Kuryr 환경에서 Pod는 독립적인 Neutron 포트를 할당받습니다. 따라서 Pod가 외부나 다른 대역으로 무분별하게 접근하지 않도록, **'서비스 대역으로만 통신을 허용'**하는 보안 그룹을 생성하고 적용해야 합니다.

보안 그룹 생성 및 규칙 추가

service_pod_access_sg를 생성하여 Pod가 서비스 대역(10.2.0.0/16)의 트래픽 및 Pod 대역, 워커, 마스터 노드의 트래픽을 허용하도록 합니다. 

Bash

 

# 1. 보안 그룹 생성
openstack security group create service_pod_access_sg

# 2. 서비스 서브넷 대역(10.2.0.0/16)에 대한 TCP 통신 허용 규칙 추가
openstack security group rule create \
    --remote-ip 10.2.0.0/16 \
    --ethertype IPv4 \
    --protocol tcp \
    [service_pod_access_sg​의 id]
    
# 1. 워커, 마스터 노드 서브넷 전체 허용 (워커 노드 간 통신 및 CNI 트래픽 보장)
openstack security group rule create \
    --remote-ip 192.168.100.0/24 \
    --ethertype IPv4 \
    --protocol tcp \
     [service_pod_access_sg​의 id]

# 2. Pod 서브넷 전체 허용 (Pod 간 통신 보장)
openstack security group rule create \
    --remote-ip 10.1.0.0/16 \
    --ethertype IPv4 \
    --protocol tcp \
     [service_pod_access_sg​의 id]

# 1. 워커 노드 서브넷 UDP 53 포트 허용 (워커 노드 간 통신 및 CNI 트래픽 보장)
openstack security group rule create \
  --ingress --ethertype IPv4 --protocol udp \
  --dst-port 53:53 \
  --remote-ip 192.168.100.0/24 \
  [service_pod_access_sg​의 id]

.

5. 이 작업이 중요한 이유: "API 서버와의 통신"

쿠버네티스 클러스터에서 Pod가 정상적으로 네트워크에 참여하려면 다음 조건이 충족되어야 합니다:

1. API Reachability: Pod 네트워크에서 쿠버네티스 API 서버의 IP에 접근 가능해야 합니다. (라우터가 이 길을 뚫어주는 역할을 합니다.)
2. Service ClusterIP/LB: 로드밸런서 VIP와 서비스 대역이 라우터를 통해 노출되어야 Pod들이 서비스를 정상적으로 호출할 수 있습니다.

master 노드의 private ip 를 확인합니다.

로드밸런서(LB) VIP가 수행하는 역할: "클러스터의 대동맥 연결"

지금 우리가 수행하는 로드밸런서 구축 작업은 쿠버네티스 클러스터의 '뇌'인 API 서버와 '손과 발'인 Pod들을 연결하는 대동맥을 개통하는 과정과 같습니다. 이 작업이 중요한 이유는 다음과 같습니다.

• 통신 경로의 추상화 및 고정화: Pod들은 API 서버의 노드 IP(예: 192.168.100.163)를 직접 호출하지 않습니다. 대신 로드밸런서 VIP(10.2.0.1)를 통해 API 서버에 접근함으로써, 향후 마스터 노드의 교체나 스케일링이 발생해도 Pod는 변경 사항을 신경 쓸 필요가 없는 **'고정된 엔드포인트'**를 확보하게 됩니다.
• 통신 표준화 (HTTPS:443): 로드밸런서는 Pod들이 사용하는 표준적인 접근 방식인 HTTPS:443 요청을 받아, API 서버의 실제 운영 포트인 6443으로 안전하게 포워딩합니다. 이 과정은 쿠버네티스 서비스 인터페이스의 표준을 인프라 레벨에서 구현하는 중요한 절차입니다.
• 서비스 대역(Service ClusterIP)의 실체화: 로드밸런서 VIP는 쿠버네티스가 내부적으로 관리하는 서비스 클러스터 IP 범위의 시작점을 담당합니다. 이를 통해 Pod 네트워크(10.1.0.0/16)는 비로소 서비스 대역(10.2.0.0/16)의 핵심 자원인 API 서버와 계층(Layer)을 넘어서 통신할 수 있는 신뢰 가능한 경로를 갖게 됩니다.

6. Kubernetes API 서버를 위한 로드밸런서(LB) 구성

Pod들이 API 서버와 안정적으로 통신할 수 있도록, OpenStack Octavia를 사용하여 로드밸런서를 생성하고 연결하는 과정입니다.

1단계: 로드밸런서(LB) 생성

쿠버네티스 서비스 대역의 첫 번째 IP(10.2.0.1)를 VIP로 지정하여 로드밸런서를 생성합니다.

Bash

 

openstack loadbalancer create --vip-address 10.2.0.1 \ ##svc ip 대역의 첫번째 ip
    --vip-subnet-id  service_subnet \
    --name default/kubernetes

 

 

loadbalancer 생성확인

 

2단계: API 서버용 풀(Pool) 생성

API 서버들로 트래픽을 분산할 풀을 생성합니다. 알고리즘은 부하가 적은 곳으로 연결하는 LEAST_CONNECTIONS를 사용합니다.

Bash

 

openstack loadbalancer pool create --name default/kubernetes:HTTPS:443 \
    --protocol HTTPS --lb-algorithm LEAST_CONNECTIONS \
    --loadbalancer <LOADBALANCER_ID>

 

3단계: API 서버 멤버(Member) 추가

실제 API 서버가 구동 중인 마스터 노드를 멤버로 등록합니다. (여러 대일 경우 반복 수행)

Bash

 

openstack loadbalancer member create \
    --name k8s-master-0 \
    --address <MASTER_IP> \
    --protocol-port 6443 \
    <POOL_ID>

4단계: 리스너(Listener) 생성

외부 요청을 받아 위에서 만든 풀로 전달하는 리스너를 생성합니다. 443 포트로 들어오는 요청을 받아 API 서버의 6443으로 전달합니다.

Bash

 

openstack loadbalancer listener create \
    --name default/kubernetes:HTTPS:443 \
    --protocol HTTPS \
    --default-pool <POOL_ID> \
    --protocol-port 443 \
    <LOADBALANCER_ID>