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

centos7 이미지를 생성해  마스터 노드와 워커 노드를 만듭니다. port 를 생성한 후 trunk 를 만들 것입니다.

1. CentOS 7 Cloud 이미지 등록 (Glance)

이미지 파일이 있는 경로에서 아래 명령어를 실행하세요.

Bash

 

# 1. 이미지 다운로드 (이미 받으셨다면 생략)
wget https://fast-mirror.isrc.ac.cn/centos-cloud/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2

# 2. OpenStack Glance에 이미지 업로드
openstack image create "CentOS-7-Cloud" \
  --file CentOS-7-x86_64-GenericCloud.qcow2 \
  --disk-format qcow2 \
  --container-format bare \
  --public \
  --property os_distro=centos \
  --property os_version=7

---

2. Flavor (m1.medium) 생성

K8s 클러스터 노드로 쓰기 적절한 사양인 m1.medium을 생성합니다. (보통 RAM 4GB, CPU 4core, Disk 40GB 정도로 설정합니다.)

Bash

 

openstack flavor create m1.medium \
  --id auto \
  --ram 4096 \
  --disk 40 \
  --vcpus 4

설정값 참고:

• --ram 4096: 4GB RAM
• --disk 40: 40GB 루트 디스크
• --vcpus 4: 4개의 가상 CPU

[실전] 워커 노드 생성 및 연결 (명령어 셋)

 

1. (참고) 만약 포트를 새로 만들어야 한다면

혹시 포트를 새로 생성해야 한다면 아래 명령어를 사용하세요.

Bash

 

openstack port create --network private --security-group default port0

3. Trunk 포트 생성 및 적용 (Worker 노드용)

Bash

# 1. 생성한 포트를 Parent Port로 지정하여 Trunk 생성
openstack network trunk create --parent-port port0 trunk0

# 2. Trunk 상태 확인
openstack network trunk list

 

 

포트 생성

생성한 포트로 트렁크 생성

 

4. 보안 그룹 설정 전략

본 설정은 다음과 같은 가이드라인을 준수합니다.

• 노드 간 통신: 동일 보안 그룹(Default SG) 내 노드 간 통신을 보장하여 마스터-워커 노드 간 정합성을 유지합니다.
• 제어 평면 통신: Controller 노드 대역에서 API 서버(6443)로의 접근을 허용합니다.
• CNI 네트워크 격리: Pod 및 Service 대역을 별도로 정의하여 Kuryr 기반의 네트워크 통신을 가능하게 합니다.

보안 그룹 규칙(Security Group Rule) 적용

적용 대상 보안 그룹 ID: 7e09f4d1-6740-4f25-922b-c732b9c0f1d9

① Controller 노드 API 접근 허용 (6443)

외부에서 클러스터를 제어하기 위해 API 서버 포트를 허용합니다.

Bash

 

openstack security group rule create \
  --protocol tcp \
  --dst-port 6443:6443 \
  --remote-ip [controller노드의 ip] \
  [rule을 추가하고자 하는 sg 의 id]

② Kubernetes Pod 대역 허용 (10.1.0.0/16)

Kuryr를 통해 Neutron 포트로 생성되는 Pod 간 통신을 위해 대역을 허용합니다.

Bash

 

openstack security group rule create \
  --protocol tcp \
  --remote-ip 10.1.0.0/16 \ #[생성한 pod의 대역]
  [rule을 추가하고자 하는 sg id]

③ Kubernetes Service 대역 허용 (10.2.0.0/16)

Service VIP 및 로드밸런서(Octavia) 통신을 위한 대역을 허용합니다.

Bash

 

openstack security group rule create \
  --protocol tcp \
  --remote-ip 10.2.0.0/16 \ #[생성한 svc의 대역]
  [rule을 추가하고자 하는 sg id]

 

[추가] 동일 보안 그룹(Default SG) 내 통신 허용

보안 그룹은 기본적으로 해당 그룹에 속한 인스턴스들 간의 트래픽을 차단하는 경우가 많습니다. 동일 클러스터 내 노드 간 원활한 통신을 위해 자신의 보안 그룹 ID를 참조하여 트래픽을 허용하는 규칙을 추가해야 합니다.(마스터 노드와 워커 노드)

Bash

 

# 자기 자신(Default SG)으로부터 들어오는 모든 TCP/UDP/ICMP 트래픽 허용
openstack security group rule create \
  --protocol tcp \
  --remote-group  [rule을 추가하고자 하는 sg id]



openstack security group rule create \
  --protocol udp \
  --remote-group  [rule을 추가하고자 하는 sg id] 


openstack security group rule create \
  --protocol icmp \
  --remote-group  [rule을 추가하고자 하는 sg id]

5. 워커 노드 생성 (현재 보유한 포트 ID 사용)

이미지 이름이 centos7이므로 이를 정확히 지정해야 합니다. 생성한 port0 을 nic 로 해서 생성합니다

Bash

 

openstack server create --image "centos7" \
  --flavor m1.medium \
  --nic port-id=port0 \
  --key-name mykey \
  worker

 

6. 마스터 노드 외부 접속용 Floating IP 할당

마스터 노드도 관리를 위해 외부 IP가 필요하다면 할당해 줍니다.

Bash

 

# 플로팅 IP 생성 (네트워크 이름 확인 후 진행)
openstack floating ip create public2

# 생성된 플로팅 IP를 마스터 노드 포트에 연결
openstack server add floating ip worker <생성된_FLOATING_IP>

 

7. 마스터 노드용 포트 생성

포트를 미리 생성해두면 나중에 IP가 바뀌지 않아 관리하기 훨씬 편합니다.

Bash

 

# 마스터 노드용 포트 생성 (네트워크와 보안그룹 지정)
openstack port create --network private --security-group default master_port

8. 마스터 노드 생성 (서버 생성)

생성한 master_port를 NIC로 지정하여 인스턴스를 올립니다.

Bash

 

# 마스터 노드 인스턴스 생성
openstack server create --image "centos7" \
  --flavor m1.medium \
  --nic port-id=master_port \
  --key-name mykey \
  master

9. 마스터 노드  외부 접속용 Floating IP 할당

마스터 노드도 관리를 위해 외부 IP가 필요하다면 할당해 줍니다.

Bash

 

# 플로팅 IP 생성 (네트워크 이름 확인 후 진행)
openstack floating ip create public2

# 생성된 플로팅 IP를 마스터 노드 포트에 연결
openstack server add floating ip master <생성된_FLOATING_IP>

 

 

 

출저: Linux - CentOS 7.9 Yum 리포지토리 설정 변경 방법 (EOL 문제 해결)

[최종 정리] CentOS 7 인프라 구성 및 리포지토리 복구 워크플로우

1. 노드 생성 및 설정 (마스터/워커)

이전 단계에서 마스터/워커 노드를 생성한 후, SSH로 접속합니다.

2. CentOS 7 리포지토리 복구 (Vault 전환)

공식 미러 서버가 모두 종료되었으므로, 보관소(Vault)로 리포지토리 설정을 변경해야 패키지 설치가 가능합니다.

1) 리포지토리 설정 파일 수정 마스터와 워커 노드 각각에서 아래 명령을 수행합니다.

Bash

 

# 리포지토리 설정 파일 편집
vi /etc/yum.repos.d/CentOS-Base.repo

2) 파일 내용 변경 (Mirrorlist 주석 처리 및 Baseurl 변경) 파일 내부의 모든 섹션(base, updates, extras 등)에서 mirrorlist를 주석(#) 처리하고, baseurl을 아래와 같이 수정합니다.

Ini, TOML

 

[base]
name=CentOS-$releasever - Base
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
baseurl=http://vault.centos.org/centos/7/os/$basearch/
gpgcheck=1

[updates]
name=CentOS-$releasever - Updates
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra
baseurl=http://vault.centos.org/centos/7/updates/$basearch/
gpgcheck=1

[extras]
name=CentOS-$releasever - Extras
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra
baseurl=http://vault.centos.org/centos/7/extras/$basearch/
gpgcheck=1

(참고: $releasever 대신 직접 7을 입력하는 것이 더 확실합니다.)

3) 설정 적용 및 확인

Bash

 

# 캐시 삭제 및 리스트 업데이트
yum clean all
yum makecache

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

# 패키지 설치 테스트 (EPEL 설치)
yum install -y epel-release

 

10. worker 노드 내 ovs 설치

Kuryr CNI가 파드(Pod)의 네트워크 인터페이스를 물리 망과 연결하기 위해서는 워커 노드에 OVS(Open vSwitch) 설치가 필수입니다. 하지만 CentOS 7은 공식 저장소에서 최신 OVS 패키지를 제공하지 않으므로, 소스 코드를 통해 직접 RPM을 빌드하여 설치하는 과정을 가이드합니다.

① 빌드 필수 패키지 설치

빌드에 필요한 의존성 패키지들을 먼저 설치합니다.

Bash

 

yum install -y epel-release


yum -y install wget openssl-devel gcc make python-devel kernel-devel graphviz \
kernel-debug-devel autoconf automake rpm-build redhat-rpm-config libtool \
libcap-ng-devel groff checkpolicy selinux-policy-devel gcc-c++ python3-devel \
python3-sphinx unbound unbound-devel

② OVS 빌드 환경 설정

안정적인 LTS 버전인 2.13.4를 기준으로 빌드를 진행합니다. (루트 계정 또는 일반 사용자 계정 모두 가능합니다.)

Bash

 

# 빌드 디렉토리 생성
mkdir -p ~/rpmbuild/SOURCES

# OVS 소스 다운로드 및 압축 해제
wget https://www.openvswitch.org/releases/openvswitch-2.13.4.tar.gz
cp openvswitch-2.13.4.tar.gz ~/rpmbuild/SOURCES/
tar -xvf openvswitch-2.13.4.tar.gz

③ RPM 패키지 빌드 및 설치

소스 코드를 RPM 패키지로 변환한 후 로컬 설치를 진행합니다.

Bash

 

# RPM 빌드 수행
rpmbuild -bb --nodeps --nocheck openvswitch-2.13.4/rhel/openvswitch-fedora.spec

# 완성된 RPM 패키지 설치
yum localinstall /home/ovs/rpmbuild/RPMS/x86_64/openvswitch-2.13.4-1.el7.x86_64.rpm -y

④ 서비스 시작 및 설치 확인

설치 후 OVS 서비스를 활성화하고, 정상적으로 설치되었는지 확인합니다.

Bash

 

# 서비스 활성화 및 재시작
systemctl enable openvswitch.service
systemctl restart openvswitch.service

# OVS 버전 확인
ovs-vsctl -V

---

💡 엔지니어의 구축 팁 (Kuryr 통합을 위해)

• br-int 자동 생성: OVS 서비스가 정상 시작되면, Kuryr CNI가 노드에 배포될 때 br-int 브리지를 자동으로 생성합니다. 만약 생성되지 않는다면 수동으로 ovs-vsctl add-br br-int를 실행하여 브리지를 먼저 구성하십시오.
• 설치 확인: ovs-vsctl show 명령어를 실행했을 때 브리지 정보가 출력된다면 Kuryr가 사용할 준비가 된 것입니다.
• 주의사항: OVS는 커널 모듈을 사용하므로 설치 후 노드 전체를 한 번 재부팅하는 것이 커널 안정성 측면에서 가장 확실합니다.

 

11. 왜 OVS가 메인 이더넷의 통로가 되는가?

파드(Pod)는 기본적으로 호스트 네트워크를 직접 쓰지 않는 격리된 환경(NetNS)에 있습니다. 이 파드들이 외부(혹은 다른 노드의 파드)와 통신하려면 반드시 **가상 브리지(OVS)**를 거쳐야만 물리적인 세상으로 나갈 수 있습니다.

• 파드(Pod) 입장: 나는 내 파드 내부 eth0를 통해 패킷을 던졌을 뿐인데, OVS가 이를 가로채서 eth0에 VLAN 태깅을 하고, 물리 NIC(메인 이더넷)을 통해 밖으로 쏘아 올립니다.
• 물리 NIC(eth0) 입장: 내 위에는 OVS가 얹혀 있고, 나는 그냥 OVS가 "이 패킷은 이 VLAN 태그 달고 외부로 보내!"라고 명령하면 그대로 쏘아 보내는 **통로(Pipe)**가 됩니다.

① 패킷 이동 경로 (Traffic Flow)

패킷이 이동하는 경로를 따라가 보면 OVS의 중요성을 실감하실 수 있습니다:

1. Pod의 VIF(Virtual Interface): 파드 내부에서 생성된 인터페이스.
2. veth pair: 파드 내부와 호스트(워커 노드)를 연결하는 파이프.
3. br-int (OVS): 여기가 핵심입니다. 파드에서 올라온 패킷에 OpenStack이 부여한 VLAN ID를 찍어줍니다.
4. Physical NIC (eth0): 태그가 붙은 패킷을 호스트 밖(OpenStack 물리 네트워크)으로 내보냅니다.
5. OpenStack Network: Neutron 네트워크가 이 VLAN 태그를 보고 목적지(다른 노드의 파드 혹은 외부 네트워크)로 정확히 배달합니다.

② "그럼 메인 이더넷은 OVS에 종속되는 건가요?"

사실상 Kuryr 환경에서는 워커 노드의 메인 이더넷이 OVS에 의해 완전히 제어되는 구조가 됩니다.

• 왜 이런 복잡한 짓을 하나요?:
  • 단순한 NAT(IP 주소 변환) 방식의 CNI는 클러스터 외부에서 파드 IP로 직접 접속이 어렵습니다.
  • 하지만 OVS + VLAN 방식을 쓰면, 파드가 마치 OpenStack의 가상 머신(VM)과 똑같은 네트워크 지위를 갖게 됩니다. * 즉, 파드에 별도의 NAT 없이도 OpenStack 인프라가 파드 IP를 직접 라우팅할 수 있게 되어, L3 수준의 고성능 통신이 가능해지는 것입니다.