ASHD Dev_Blog

K8s를 시작하기 전에

K8s를 시작하기전 온프레미스 서버의 현재 상태에 대한 간략 정리

이재룡
이재룡 Jun 30, 2025
 

[ 0. K8s를 시작하며 ]

[위 이미지는 On-premise 환경에서 K8s 서버를 어떻게 구현해야하는지에 대한 요약이다]

⇒ 현직자분께 시스템 이해를 위해 설명을 요쳥했고, 설명해주신 내용을 일단 이해한대로 요약을 해보면 아래와 같다.

 

[ 1. 정기관 서버 구조 및 VM 기본 설정 : PROXMOX -VM ]

  • 정기관 서버는 172.30/16의 IPTIME 네트워크에 연결되어 DHCP 형식으로 IP를 부여받는다.
  • 정기관 서버(HOST)는 192.30.0.2/32 대역을 사용하며, PROXMOX가 설치되어 있음
  • 정기관 서버 자원의 일부분을 사용해서, VM을 만들고
    • ubuntu → K8s로 가는 기본적인 설정을 cloud-init을 통해 자동화함,
      • ⇒ 즉 cloud-init을 통해, 기본 설정을 만들어 놓음으로써, 템플릿을 사용하여 복제가 가능하도록!

        기본적인 설정 예시 : k8s-ssh접속 / qemu-agent [proxmox에서 VM 및 네트워크 확인 가능]

        ✅ 수동 설정해야 할 항목들

        1. ✅ 호스트네임 설정

        • cloud-init은 자동으로 hostname을 바꿔주지만, 수동이라면:

        2. ✅ 사용자 계정 생성 (클라우드 초기 사용자)

        • cloud-init은 자동으로 ubuntu 같은 사용자 생성 + SSH키 등록
        • 수동이라면:

        3. ✅ SSH 키 등록 (비밀번호 없이 접속하고 싶을 경우)

        4. ✅ 정적 IP 설정 (보통 cloud-init이 자동 설정)

        예시 설정:

        적용:

        5. ✅ qemu-guest-agent 설치 및 활성화

        6. ✅ 패키지 설치 (docker, kubelet, rke2 등)

        7. ✅ 시간대 / 로케일 설정

        8. ✅ 방화벽 / 포트 설정 (필요 시)

        9. ✅ 초기 스크립트 실행 (bootstrap)

        cloud-init에서는 runcmd, bootcmd로 가능했지만, 수동이면 bash 스크립트 직접 실행:

 
Callout icon'
- proxmox : VM 관리 플랫폼 = 호스트 시스템 (⇒ 템플릿 만들기가 가능)

- cloud-init : VM이 설치된 이후, 실행되는 스크립트 설정 (⇒ 템플릿 마다 자동 설정 부여)

- qemu-agent : 호스트 시스템과 VM을 연결해주는 데몬
 
 

[ 2. VM을 cloud 환경으로 : Provision ]

⇒ 외부(Terraform?)에서 RKE2를 활용한 프로비져닝이 자동화

  • Proxmox REST API를 사용해서, VM템플릿을 활용 1개의 마스터, 3개의 워커 노드 생성 = ubuntu설치 + cloud-init 설치 및 메타데이터 실행
  • cloud-init에서 rke2_role = "server” 와 같이 서로 다른 롤을 부여해서, RKE2-server / RKE2-agent 생성
  • 각 노드를 rancher를 사용해서 연결하는 것(master-worker) 까지 자동으로
 
Callout icon'
- PROXMOX REST API : 탬플릿을 이용하여 VM 생성을 API로

- cloud-init : ROLE(master/worker)에 따른 설정 부여 + 각 RKE 연결 까지
 

[ 3. HTTP traffic을 어떻게 처리하나? : Networking ]

  1. 외부 사용자가 브라우저 접속 : https://main.test.com
  1. 라우터가 요청을 Nginx Proxy Manager에게 전달
    1. ⇒ DNS를 통해 https://test.com 주소가 192.168.0.100(Nginx Proxy Manager IP)로

  1. Nginx Proxy 규칙에 따라, main. 은 proxy_pass http://192.168.0.240:80으로 전달 (내부망 IP)
      • Nginx Proxy Manager는 https://main.test.com/hello 요청을 받아서 그대로 http://192.168.0.240:80/hello로 대신 전달(proxy)
      • 여기서 192.168.0.240:80이 IP가 metalLB를 통해서 로드밸런서 서비스에 부여한 가상 L2 IP
  1. MetalLB에서 192.168.0.240가 할당된 특정 노드 A를 찾아 연결 172.30.0.1
  1. kube-proxyK8s 서비스 ClusterIP(172.30.0.1)를 → 선택된 pod(172.30.3.5:8080)로 라우팅
 

역할 정리

Callout icon'
- Nginx Proxy Manager : 받은 HTTPS 요청을 URL 라우팅 및 SSL 설정 등을 한 후, 전달
⇒ 전달 IP : MetalLB로 만든 가상 L2 IP

- MetalLB : 내부망의 특정 노드와 연결되는 외부 IP를 제공
⇒ 전달 IP : 노드 A의 클러스터 IP

- K8s : kube-proxy를 통한 클러스터 IP 요청을 실제 Pod로 연결
⇒ 전달 IP : Pod
 

공부했지만 못적은 것들 (후에 RKE-etcd 묶고, metalLB ingress 부분 묶고, 설치해서 실행 되는거 까지 해보기)

 

클러스터안에 설치되는 프로그램들

 

RKE

Kubernetes RKE1 vs RKE2

 

etcd

tech.kakao.comtech.kakao.comKubernetes 운영을 위한 etcd 기본 동작 원리의 이해 - tech.kakao.com

WallarmWallarmetcd란 무엇인가? 🔆 쿠버네티스와 클러스터 — Wallarm

TISTORYTISTORYKubernetes 기본 구조와 etcd 역할 및 클러스터 구성

 

metal LB vs Ingress

TISTORYTISTORYMetalLB란?

TISTORYTISTORY[Kubernetes] 인그레스(Ingress)란 무엇인가?

 
 

 

추천 글

BlogPro logo