100===Dev Ops/Kubernetes

쿠버네티스 온프레미스 설치부터 활용, 관리까지

블로글러 2025. 4. 10. 09:57

섹션 1: 소개: 쿠버네티스와 온프레미스 환경 이해하기

1.1 쿠버네티스란 무엇인가? (비유: 오케스트라 지휘자)

쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 오픈소스 플랫폼입니다.1 마치 오케스트라 지휘자가 각 악기(컨테이너)가 제 역할을 정확하고 조화롭게 수행하도록 이끄는 것처럼, 쿠버네티스는 복잡한 애플리케이션 환경을 조율합니다. 일부 연주자(서버)를 교체해야 하는 상황에서도 전체 연주(애플리케이션)가 원활하게 진행되도록 보장합니다.

원래 구글(Google)에서 개발되었으며, 현재는 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)에서 관리하고 있습니다.1 쿠버네티스는 선언적 구성과 자동화를 통해 컨테이너화된 워크로드와 서비스를 관리하는 강력한 기능을 제공하며 2, 분산 시스템을 탄력적으로 실행하기 위한 프레임워크 역할을 합니다.2 오늘날 많은 조직에서 분산 애플리케이션과 서비스를 대규모로 운영하기 위해 널리 채택되어 사실상의 표준(de facto standard)으로 자리 잡았습니다.1 쿠버네티스라는 이름은 그리스어로 '키잡이' 또는 '파일럿'을 의미합니다.2

1.2 왜 쿠버네티스를 사용하는가? 주요 이점

쿠버네티스는 현대적인 애플리케이션 운영 환경에서 다음과 같은 중요한 이점을 제공합니다.

  • 자동화: 배포, 확장, 리소스 할당과 같은 반복적이고 지루한 운영 작업을 자동화합니다.1 쿠버네티스는 컨테이너가 어디서 실행될지 결정하고, 사용자가 선언한 원하는 상태를 지속적으로 유지하도록 관리합니다.1
  • 확장성: 변화하는 요구 사항에 맞춰 애플리케이션을 쉽게 확장하거나 축소할 수 있습니다.2 쿠버네티스는 필요에 따라 리소스를 자동으로 조정할 수 있는 기능을 제공합니다.5
  • 복원력 및 자가 치유: 실패한 컨테이너를 자동으로 재시작하고, 노드(서버)가 다운되면 해당 노드에서 실행 중이던 컨테이너를 다른 정상 노드로 교체하고 재스케줄링하여 서비스의 고가용성을 보장합니다.2 롤링 업데이트 중 문제가 발생하면 이전 버전으로 쉽게 롤백할 수도 있습니다.7
  • 이식성: 개발, 테스트, 프로덕션 환경은 물론 온프레미스, 클라우드, 하이브리드 환경 등 다양한 인프라에서 일관되게 애플리케이션을 실행할 수 있습니다.2 쿠버네티스는 온프레미스와 퍼블릭 클라우드 모두에서 배포 가능하여 여러 환경에서 공통된 운영 모델을 제공합니다.8
  • 서비스 디스커버리 및 로드 밸런싱: 컨테이너들이 서로를 안정적으로 찾을 수 있는 방법을 제공하고, 네트워크 트래픽을 여러 컨테이너 인스턴스에 분산시켜 부하를 관리합니다.1 특정 노드에 장애가 발생해도 로드 밸런싱을 통해 서비스 연속성을 유지할 수 있습니다.9

1.3 온프레미스 vs. 클라우드 쿠버네티스: 차이점 이해하기

쿠버네티스를 운영하는 방식은 크게 온프레미스(On-Premise)와 클라우드 기반 관리형 서비스(Managed Service)로 나뉩니다.

  • 온프레미스 쿠버네티스: 사용자가 자체 데이터 센터 내에서 서버, 스토리지, 네트워크와 같은 물리적 하드웨어부터 운영체제, 쿠버네티스 컨트롤 플레인 및 워커 노드까지 모든 것을 직접 설치, 구성, 관리하는 방식입니다.10 이는 마치 기초 공사부터 시작해 집 전체를 직접 짓고 소유하는 것과 유사합니다.5
  • 클라우드 쿠버네티스 (관리형 서비스, 예: AWS EKS, Google GKE, Azure AKS): AWS, Google, Azure와 같은 클라우드 제공업체가 기본 인프라(서버, 네트워크 등)와 쿠버네티스 컨트롤 플레인의 설치, 운영, 유지보수를 책임지는 서비스입니다.11 사용자는 주로 자신의 애플리케이션을 배포하고 관리하는 데 집중할 수 있습니다.14 이는 모든 유지보수, 보안, 시설 관리를 집주인이 처리해주는 아파트에 입주하는 것과 비슷합니다.

두 방식의 주요 차이점은 관리 책임, 비용 모델, 유연성, 보안 책임 등 여러 측면에서 나타납니다.10 이러한 차이를 이해하는 것은 자신의 환경에 적합한 쿠버네티스 운영 방식을 선택하는 데 중요합니다.

표 1: 온프레미스 vs. 클라우드 쿠버네티스 비교
기능 온프레미스 클라우드 (관리형)
관리 부담 높음 (사용자 전체 책임) 5 낮음 (클라우드 제공업체 관리) 11
제어 수준 완전한 제어 12 제한적 (제공업체 제약) 12
비용 구조 초기 투자 비용(CapEx) + 운영 비용(OpEx) 5 운영 비용(OpEx, 사용량 기반) 10
확장 속도 느림 (하드웨어 조달 필요) 11 빠름 (API/콘솔 통해 즉시 가능) 10
보안 책임 사용자 전적 책임 12 사용자-제공업체 공동 책임 10
맞춤 설정 높음 16 중간 (제공업체 옵션 내)
벤더 종속성 낮음 15 잠재적으로 높음 15

1.4 왜 온프레미스 쿠버네티스를 선택하는가?

클라우드 기반 관리형 서비스의 편리함에도 불구하고 여러 이유로 온프레미스 환경에 쿠버네티스를 직접 구축하고 운영하는 것을 선택할 수 있습니다.

  • 제어 및 맞춤 설정: 하드웨어, 소프트웨어, 네트워크 구성, 보안 정책 등 인프라의 모든 측면을 완전히 제어하고 원하는 대로 맞춤 설정할 수 있습니다.12 특정 하드웨어(예: GPU 노드 9)를 사용하거나, 외부 네트워크와 완전히 분리된 에어갭(air-gapped) 환경을 구축하는 등 특수한 요구 사항을 충족시킬 수 있습니다.11
  • 보안 및 규정 준수: 민감한 데이터를 외부 클라우드 제공업체에 의존하지 않고 자체 인프라 내에 안전하게 보관할 수 있습니다.10 엄격한 산업 규제나 데이터 주권 요구 사항을 준수해야 하는 경우 온프레미스가 필수적일 수 있습니다.17 모든 보안 계층을 직접 통제하고 관리합니다.12
  • 비용 예측 가능성 (잠재적): 상당한 초기 하드웨어 투자(자본 지출, CapEx)가 필요하지만, 워크로드가 안정적이고 예측 가능하다면 장기적인 운영 비용(운영 지출, OpEx)이 변동성이 큰 클라우드 비용보다 낮거나 예측 가능할 수 있습니다.10 특히 대규모의 고정 워크로드를 처리할 때 유리할 수 있으며, 예기치 않은 클라우드 데이터 전송 비용이나 서비스 이용료 급증을 피할 수 있습니다.5
  • 기존 인프라 활용: 이미 투자한 데이터 센터 자원과 하드웨어를 효과적으로 활용할 수 있습니다.18 다른 온프레미스 시스템과의 긴밀한 통합이 필요한 경우에도 유리합니다.
  • 벤더 종속성 회피: 특정 클라우드 제공업체의 독점적인 서비스나 가격 정책에 얽매이지 않고 기술 선택의 유연성을 확보할 수 있습니다.1 오픈소스 기술 기반으로 인프라를 구축하여 종속성을 줄일 수 있습니다.15

온프레미스 쿠버네티스를 선택하는 결정은 종종 순수한 기술적 선호도보다는 비즈니스 요구 사항, 보안 정책, 규정 준수 필요성에 의해 주도됩니다.10 이는 클라우드 서비스의 편리함과 빠른 구축 속도를 포기하는 대신, 완전한 제어권, 강화된 보안, 특정 워크로드에 대한 잠재적인 장기 비용 최적화를 얻는 전략적 선택입니다. 관리 복잡성이 증가하는 것은 이러한 선택에 따르는 중요한 고려 사항입니다.

섹션 2: 쿠버네티스 핵심 개념 쉽게 이해하기

쿠버네티스를 효과적으로 사용하려면 몇 가지 핵심 개념을 이해하는 것이 중요합니다. 여기서는 비유를 통해 각 개념을 쉽게 설명합니다.

2.1 컨테이너: 애플리케이션의 표준화된 포장 (비유: 표준 규격 배송 컨테이너)

컨테이너(예: 도커 컨테이너)는 애플리케이션과 그 실행에 필요한 모든 종속성(코드, 런타임, 시스템 도구, 라이브러리 등)을 함께 묶어 패키징한 것입니다.2 이를 통해 애플리케이션을 기본 시스템 환경으로부터 격리시킬 수 있습니다.2

비유하자면, 컨테이너는 국제 표준 규격의 배송 컨테이너와 같습니다. 내용물(애플리케이션)이 무엇이든 표준화된 방식으로 포장하고 운송할 수 있게 해주어, 개발자의 로컬 머신이든, 온프레미스 서버든, 클라우드 환경이든 어디서나 동일하게 실행될 수 있도록 보장합니다.2 가상 머신(VM)과 달리 호스트 운영체제의 커널을 공유하기 때문에 훨씬 가볍고 빠르게 시작할 수 있습니다.2

2.2 파드(Pod): 애플리케이션 인스턴스의 집 (비유: 컨테이너를 위한 아파트)

파드는 쿠버네티스에서 생성하고 관리할 수 있는 가장 작고 기본적인 배포 단위입니다.3 파드는 애플리케이션의 단일 인스턴스를 나타냅니다.

파드는 하나 또는 그 이상의 밀접하게 연관된 컨테이너들의 그룹을 포함합니다.3 이 컨테이너들은 항상 함께 스케줄링되고 동일한 노드에서 실행됩니다.

비유하자면, 파드는 아파트 한 채 20 또는 작은 단독 주택 20과 같습니다. 그 안에 사는 거주자들 20 또는 방들이 바로 컨테이너입니다. 아파트 내의 거주자들은 전기, 수도와 같은 공용 시설(네트워크 주소, 스토리지 볼륨)을 공유합니다.3 파드 내의 컨테이너들은 고유한 IP 주소를 공유하며, localhost를 통해 서로 직접 통신할 수 있습니다.3 또한, 공유 스토리지를 마운트하여 데이터를 공유할 수 있습니다.2 애플리케이션이 단 하나의 컨테이너로 구성되더라도, 쿠버네티스에서는 반드시 파드 안에 배치하여 관리합니다.3

2.3 노드(Node): 파드를 실행하는 작업자 머신 (비유: 아파트를 수용하는 건물)

노드는 쿠버네티스 클러스터 내의 워커 머신(물리 서버 또는 가상 머신)입니다.2 노드의 주된 역할은 파드를 실행하는 것입니다.

비유하자면, 파드가 아파트라면 노드는 이러한 아파트들을 수용하는 건물 20입니다. 각 건물은 입주한 아파트들이 필요로 하는 기본적인 자원(CPU, RAM, 네트워크 등)을 제공합니다.20

모든 노드에는 다음과 같은 핵심 컴포넌트가 실행됩니다:

  • kubelet: 각 노드의 '건물 관리인'과 같습니다. 컨트롤 플레인과 통신하며 해당 노드의 파드들이 정상적으로 실행되도록 관리합니다.2
  • kube-proxy: 건물의 내부 전화망이나 우편 시스템처럼, 노드 내/외부의 네트워크 규칙을 관리하고 파드 간 통신을 가능하게 합니다.2
  • 컨테이너 런타임: 도커(Docker)나 컨테이너디(containerd)와 같이 실제로 컨테이너를 실행하는 엔진입니다.2

2.4 컨트롤 플레인(Control Plane): 클러스터의 두뇌 (비유: 도시 정부 또는 아파트 단지 관리 사무소)

컨트롤 플레인은 쿠버네티스 클러스터 전체의 상태를 관리하고 제어하는 중앙 두뇌 역할을 합니다.2 파드를 어느 노드에 배치할지 결정하고, 클러스터 이벤트를 감지하고 대응하는 등 전반적인 운영을 지휘합니다.

비유하자면, 도시 전체를 관리하는 시청 20 또는 아파트 단지의 중앙 관리 사무소와 같습니다. 직접 애플리케이션(주민 활동)을 실행하지는 않지만, 전체 시스템(도시/단지)이 원활하게 운영되도록 감독합니다.

주요 구성 요소는 다음과 같습니다:

  • kube-apiserver: 클러스터의 '프런트 데스크' 또는 '민원 창구'입니다. 모든 내부 및 외부 통신은 API 서버를 통해 이루어집니다.2
  • etcd: 도시의 모든 공식 기록(토지 대장, 주민 등록부 등)을 보관하는 안전한 데이터베이스입니다. 클러스터의 모든 구성 정보와 상태를 저장합니다.2
  • kube-scheduler: 새로운 아파트(파드) 신청이 들어왔을 때, 어느 건물(노드)에 배정할지 결정하는 '주택 배정 담당관'입니다.2
  • kube-controller-manager: 도시의 여러 부서(교통국, 환경국 등)처럼, 노드 상태 관리, 복제본 수 유지 등 다양한 제어 루프를 실행하여 클러스터 상태를 원하는 대로 유지합니다.2
  • cloud-controller-manager: 클라우드 환경에서 클라우드 제공업체의 API와 상호작용하는 컴포넌트입니다 (순수 온프레미스 환경에서는 덜 중요하지만 존재를 알아두면 좋습니다).2

2.5 디플로이먼트(Deployment): 애플리케이션 상태 관리자 (비유: 설계도 및 건설 현장 감독)

디플로이먼트는 동일한 파드들의 집합(레플리카셋을 통해)을 관리하는 상위 수준의 객체입니다.2 사용자는 디플로이먼트에 "원하는 상태" (예: "웹 서버 이미지 X를 사용하는 파드 3개를 항상 실행시켜줘")를 선언합니다.6

비유하자면, 디플로이먼트는 특정 유형의 주택(파드)에 대한 마스터 설계도와 건설 현장 감독을 합친 것과 같습니다.23 설계도에 따라 정확한 수의 주택이 건설되고 유지되도록 보장합니다. 만약 주택 하나가 손상되면(파드 실패), 감독관은 자동으로 새 주택을 건설합니다. 또한 설계도가 변경되면(새 애플리케이션 버전), 기존 주택을 새 설계도의 주택으로 점진적으로 교체하는 업데이트(롤링 업데이트) 과정을 원활하게 관리합니다.6

2.6 서비스(Service): 안정적인 통신 창구 (비유: 우체국 또는 내부 전화 교환 시스템)

서비스는 특정 파드 그룹에 접근할 수 있는 안정적인 단일 엔드포인트(고정 IP 주소와 DNS 이름)를 제공하는 추상화된 방법입니다.2 파드는 생성되고 삭제될 때마다 IP 주소가 변경될 수 있지만, 서비스는 고정된 주소를 유지하여 다른 애플리케이션이나 사용자가 해당 파드 그룹에 안정적으로 접근할 수 있도록 합니다.

비유하자면, 특정 부서의 대표 전화번호 23 또는 도시의 우체국 20과 같습니다. 부서 내 직원(파드)이 바뀌거나 자리를 옮겨도, 대표 번호(서비스 IP/이름)로 전화하면 항상 해당 부서와 연결될 수 있습니다. 우체국은 집 주소(파드 IP)가 바뀌더라도 정확한 집으로 우편물(네트워크 요청)을 배달해 줍니다. 서비스는 또한 들어오는 요청을 현재 사용 가능한 파드들에게 분산시키는 로드 밸런싱 기능도 수행합니다.19

2.7 네임스페이스(Namespace): 클러스터 자원 분리 (비유: 사무실 칸막이 또는 도시의 동네)

네임스페이스는 하나의 물리적인 쿠버네티스 클러스터를 여러 개의 가상 클러스터처럼 논리적으로 분할하여 사용하는 방법입니다.2 이를 통해 여러 사용자, 팀 또는 애플리케이션 간에 리소스를 격리하고 관리할 수 있습니다.21

비유하자면, 도시 안의 여러 동네 24 또는 사무실 내의 칸막이(큐비클) 25와 같습니다. 각 네임스페이스(동네/칸막이)는 자신만의 리소스(파드, 서비스, 디플로이먼트 등 - 주택, 상점, 건물 등)를 가질 수 있습니다.24 이는 리소스 이름 충돌을 방지하고, 각 그룹별로 접근 권한이나 리소스 사용량(쿼터)을 제한하는 데 유용합니다.19 특별히 지정하지 않으면 리소스는 default라는 기본 네임스페이스에 생성됩니다.25 시스템 내부적으로 사용되는 네임스페이스는 보통 kube-로 시작합니다 (예: kube-system).25

2.8 kubectl: 클러스터 제어 도구 (비유: 만능 리모컨)

kubectl은 쿠버네티스 클러스터와 상호작용하기 위한 기본 커맨드 라인 인터페이스(CLI) 도구입니다.3 이를 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 조회 및 관리하며, 로그를 확인하는 등 거의 모든 작업을 수행할 수 있습니다.27

비유하자면, 쿠버네티스 클러스터를 위한 만능 리모컨과 같습니다. 이 리모컨을 사용하여 클러스터에게 무엇을 할지 지시하고(리소스 생성, 업데이트, 삭제), 현재 상태를 확인할 수 있습니다. 명령어는 일반적으로 kubectl <명령> <타입> <이름> [옵션] 형식을 따릅니다.28

섹션 3: 준비 단계: 온프레미스 환경 요구 사항

온프레미스 환경에 쿠버네티스를 성공적으로 설치하고 운영하기 위해서는 사전에 하드웨어, 소프트웨어, 네트워크 환경을 적절히 준비해야 합니다.

3.1 하드웨어 요구 사항 (CPU, RAM, 스토리지, 네트워크)

쿠버네티스 클러스터를 구성하는 각 노드(서버)는 특정 최소 사양을 충족해야 합니다. 실제 필요한 사양은 운영하려는 애플리케이션의 워크로드에 따라 크게 달라질 수 있습니다.

  • 최소 권장 사양 (일반 가이드라인):
    • 컨트롤 플레인 (마스터) 노드: 노드당 최소 2개 이상의 CPU 코어와 2GB 이상의 RAM이 필요하며, 보통 4GB 이상을 권장합니다.18 클러스터의 상태 정보를 저장하는 etcd의 성능을 위해 SSD 사용이 강력히 권장됩니다.18 고가용성(HA) 구성을 위해서는 최소 3개의 마스터 노드가 필요합니다.9
    • 워커 노드: 노드당 최소 2개 이상의 CPU 코어와 2GB 이상의 RAM이 필요하며, 4GB 이상이 권장됩니다.31 하지만 실제 운영 환경에서는 애플리케이션의 요구 사항에 따라 훨씬 더 높은 사양(예: 노드당 8개 이상의 CPU 코어, 32GB 이상의 RAM)이 필요할 수 있습니다.18
  • 스토리지:
    • 노드 자체 스토리지: 운영체제, 컨테이너 런타임, kubelet 데이터 디렉토리, 컨테이너 이미지 캐시 등을 저장하기 위한 충분한 로컬 디스크 공간이 필요합니다. 일반적으로 노드당 최소 20GB에서 50GB 이상이 요구될 수 있습니다.33
    • 영구 볼륨(Persistent Volumes, PV): 데이터베이스나 상태를 유지해야 하는 애플리케이션(Stateful Application)을 위해서는 별도의 영구 스토리지가 필요합니다.1 온프레미스 환경에서는 NAS, SAN과 같은 네트워크 스토리지나 Ceph, GlusterFS, Portworx와 같은 분산 스토리지 솔루션을 구축하고 쿠버네티스와 연동해야 합니다.5 스토리지 솔루션의 안정성을 위해 RAID 구성 등을 고려할 수 있습니다.9 특정 애플리케이션은 최소 PV 크기를 요구하기도 합니다 (예: Prometheus 10GB 33, ArcGIS 일부 컴포넌트 16-32GB 32).
  • 네트워크: 모든 마스터 노드와 워커 노드 간에 안정적인 네트워크 연결이 필수적입니다.5 클러스터 내부 통신 및 외부 애플리케이션 트래픽을 처리하기에 충분한 대역폭이 확보되어야 합니다.5 네트워크 보안과 세분화(segmentation)도 중요한 고려 사항입니다.

온프레미스 환경에서는 클라우드처럼 필요할 때 즉시 자원을 늘릴 수 없으므로, 신중한 용량 계획(capacity planning)과 초기 하드웨어 투자가 매우 중요합니다.10 자원을 부족하게 준비하면 성능 문제가 발생하고, 과도하게 준비하면 불필요한 비용이 발생합니다.5 운영 환경에서는 최소 요구 사양보다 훨씬 넉넉하게 자원을 준비하는 것이 일반적입니다.18

표 2: 온프레미스 쿠버네티스 노드 최소 권장 하드웨어 사양
노드 유형 최소 노드 수 (Non-HA) 최소 노드 수 (HA/운영) 노드당 CPU 노드당 RAM 노드당 스토리지 (OS/런타임) 스토리지 유형 (마스터) 네트워크
컨트롤 플레인(마스터) 1 3 (홀수 권장) 18 2+ vCPU 30 2-4+ GB 30 ~20-50GB+ 33 SSD 권장 18 1+ Gbps
워커 노드 1 (테스트용) 2+ (워크로드 따라) 2+ vCPU 31 2-4+ GB 31 ~20-50GB+ + 앱 스토리지 32 - 1+ Gbps

3.2 소프트웨어 요구 사항

  • 운영체제(OS): 쿠버네티스와 호환되는 리눅스 배포판이 필요합니다. Ubuntu 18, CentOS/RHEL 18, Debian 등이 널리 사용됩니다. 선택한 쿠버네티스 버전 및 설치 도구와의 호환성을 확인해야 합니다.30 보안 강화를 위해 컨테이너 전용 OS(예: Flatcar Container Linux, Talos)를 고려할 수도 있지만, 학습 곡선이 더 가파를 수 있습니다.17
  • 컨테이너 런타임: 모든 노드에 컨테이너 런타임 인터페이스(CRI)와 호환되는 런타임이 설치되어 있어야 합니다.2
    • containerd: 경량이며 CRI 표준을 준수하여 널리 권장됩니다.9
    • CRI-O: CRI 호환성을 목표로 개발된 또 다른 옵션입니다.
    • Docker Engine: 쿠버네티스 v1.24부터는 CRI를 직접 지원하지 않습니다. 도커 엔진을 사용하려면 cri-dockerd라는 별도의 어댑터(shim)를 설치해야 합니다.30 많은 가이드가 여전히 도커를 사용하지만, 이 추가 단계를 인지해야 합니다.35
  • 필수 도구: kubeadm, kubelet, kubectl 세 가지 핵심 바이너리가 필요합니다. 일반적으로 함께 설치되며, 클러스터 버전과 일치하는 버전을 사용해야 합니다.26 설치 방법에 따라 추가 도구가 필요할 수 있습니다 (예: Kubespray 사용 시 Python, pip, Ansible 35; Helm 사용 시 Helm 바이너리 31). conntrack 패키지가 필요할 수도 있습니다.37

3.3 네트워크 구성

  • IP 주소 체계: 모든 노드는 서로 통신 가능한 고유 IP 주소를 가져야 합니다. 파드 네트워크 대역(--pod-network-cidr, 예: Calico의 경우 192.168.0.0/16 39)과 서비스 네트워크 대역(--service-cidr)을 미리 계획해야 합니다. 이 대역들은 노드 IP 대역이나 외부 네트워크와 겹치지 않아야 합니다.
  • 필수 포트 개방: 컨트롤 플레인 컴포넌트 간 통신, 노드와 컨트롤 플레인 간 통신, 파드 간 통신 등을 위해 특정 네트워크 포트들이 노드 간에 열려 있어야 합니다.30 공식 문서의 포트 및 프로토콜 목록을 참조하십시오. 일반적으로 API 서버(6443), etcd(2379-2380), kubelet API(10250), NodePort 서비스 범위(기본 30000-32767) 등이 포함됩니다.39 netcat (nc) 같은 도구를 사용하여 포트 연결성을 확인할 수 있습니다.30 선택한 CNI 플러그인에 따라 추가 포트 개방이 필요할 수 있습니다.30
  • CNI (Container Network Interface) 플러그인: 파드 간의 네트워킹을 담당하는 CNI 플러그인을 선택하고 설치해야 합니다. Calico 39, Flannel, Weave Net 등이 널리 사용됩니다. 각 CNI 플러그인은 자체적인 요구 사항(예: Calico의 경우 IP-in-IP 터널링 또는 BGP 설정)을 가질 수 있습니다.

3.4 필수 사전 점검 사항

설치를 시작하기 전에 다음 사항들을 반드시 확인해야 합니다.

  • 고유 식별자: 모든 노드가 고유한 호스트 이름(hostname), MAC 주소, product_uuid를 가지고 있는지 확인합니다.30 hostname, ip link 또는 ifconfig -a, sudo cat /sys/class/dmi/id/product_uuid 명령으로 확인할 수 있습니다.30 중복된 값이 있으면 설치 과정에서 실패합니다.30
  • 스왑(Swap) 비활성화: 모든 노드에서 스왑 메모리 사용을 비활성화해야 합니다. kubelet이 정상적으로 작동하기 위한 필수 조건입니다.30 swapon --show 명령으로 현재 상태를 확인하고, sudo swapoff -a 명령으로 즉시 비활성화한 후, /etc/fstab 파일에서 관련 라인을 주석 처리하여 영구적으로 비활성화합니다.38
  • 커널 파라미터 및 모듈: 필요한 커널 모듈(예: br_netfilter)이 로드되어 있고, 특정 커널 파라미터(예: net.bridge.bridge-nf-call-iptables=1)가 설정되어 있는지 확인합니다.38 대부분의 설치 도구가 이를 처리해주지만, 수동 확인이 도움이 될 수 있습니다.
  • 방화벽 규칙: 노드의 방화벽(iptables, firewalld, ufw 등) 설정이 쿠버네티스에서 요구하는 포트들의 트래픽을 허용하는지 확인합니다.30

섹션 4: 설치 경로 선택: Minikube, K3s, kubeadm 비교

쿠버네티스 클러스터 설치를 돕는 다양한 도구들이 존재합니다.26 여기서는 온프레미스 환경을 탐색하는 초보자에게 적합한 세 가지 인기 있는 옵션인 Minikube, K3s, kubeadm을 비교하고 각각의 특징을 살펴봅니다.

4.1 설치 도구 개요

쿠버네티스 설치 도구는 로컬 개발 환경 구축용부터 운영 환경 수준의 클러스터 설치용까지 다양합니다.42 각 도구는 사용 편의성, 기능, 유연성 등에서 차이가 있으므로, 자신의 학습 목표와 환경에 맞는 도구를 선택하는 것이 중요합니다.

4.2 Minikube: 로컬 학습 및 테스트용

  • 목적: 주로 개인의 로컬 머신(노트북/데스크톱) 내 가상 머신(VM)이나 컨테이너 안에 단일 노드 쿠버네티스 클러스터를 생성하는 도구입니다.26 쿠버네티스 기본 개념을 배우거나 애플리케이션을 로컬에서 테스트하는 데 매우 유용합니다.13
  • 특징: 리눅스, macOS, 윈도우 등 다양한 운영체제에서 쉽게 설치하고 사용할 수 있습니다.37 Docker, VirtualBox, Hyperkit 등 여러 가상화 드라이버를 지원합니다.26 minikube dashboard, minikube service와 같은 편리한 부가 명령을 제공하며, 애드온(add-on) 기능을 쉽게 설치할 수 있습니다.34
  • 장점: 설치 및 시작이 매우 간편합니다.37 멀티 노드 클러스터에 비해 자원 요구량이 적습니다.44 개인 개발자나 쿠버네티스 입문자에게 이상적입니다.41
  • 단점: 기본적으로 단일 노드로 구성되어 실제 멀티 노드 클러스터의 동작(네트워킹, 고가용성 등)을 경험하기 어렵습니다.26 운영 환경에는 적합하지 않으며 26, 쿠버네티스의 전체 아키텍처를 이해하기에는 기능이 너무 제한적일 수 있습니다.44
  • 설치 예시: Minikube 바이너리와 드라이버(예: Docker) 설치 후, minikube start 명령 실행.45

4.3 K3s: 가볍고 빠른 설치

  • 목적: 100MB 미만의 단일 바이너리로 패키징된, 완전한 기능을 갖춘 경량 쿠버네티스 배포판입니다.47 리소스가 제한적인 환경(IoT/엣지 컴퓨팅), 개발 환경, 또는 간단한 클러스터 구축에 적합하도록 설계되었습니다.27 Rancher Labs(현재 SUSE)에서 개발했습니다.27
  • 특징: 간단한 스크립트 실행만으로 매우 빠르게 설치할 수 있습니다.48 표준 쿠버네티스(K8s)보다 적은 리소스를 사용합니다 (레거시 기능 제거, 기본 데이터 저장소로 etcd 대신 sqlite 사용, containerd 기본 사용 등).27 Helm 컨트롤러와 Traefik 인그레스 컨트롤러가 내장되어 있습니다.27 멀티 노드 구성도 지원합니다.
  • 장점: 설치가 극도로 쉽고 빠릅니다.47 자원 사용량이 매우 적습니다.27 완전한 쿠버네티스 인증 배포판입니다.47 빠른 클러스터 구축, CI/CD 파이프라인, 엣지 환경 등에 유용합니다.27 설치 편의성 때문에 초보자에게 권장되기도 합니다.42
  • 단점: 단순화된 구조로 인해, 복잡하거나 고성능, 대규모 운영 환경에는 부적합할 수 있습니다.27 기본 sqlite 백엔드는 멀티 마스터 고가용성 측면에서 etcd보다 불리할 수 있습니다 (etcd 사용 설정 가능).
  • 설치 예시: 서버 노드에 curl -sfL https://get.k3s.io | sh - 실행.49 에이전트 노드 추가 시 K3S_URL, K3S_TOKEN 환경 변수 사용.49

4.4 kubeadm: 표준적이고 유연한 접근 방식

  • 목적: 쿠버네티스 프로젝트에서 공식적으로 제공하는 도구로, 모범 사례를 따르는 표준 쿠버네티스 클러스터를 부트스트랩(초기 설정)하는 데 사용됩니다.30 운영 환경 수준의 클러스터를 생성하는 것을 목표로 합니다.41
  • 특징: kubeadm init (마스터 노드 초기화) 및 kubeadm join (워커 노드 추가) 명령을 제공합니다.38 CNI 플러그인 선택, 컴포넌트 설정 변경 등 높은 수준의 구성 유연성을 제공합니다.38 VM이나 물리 서버 같은 인프라 자체를 프로비저닝하지는 않으므로, 서버는 미리 준비되어 있어야 합니다.14 kubelet, kubectl, 컨테이너 런타임은 사용자가 별도로 설치해야 합니다.26
  • 장점: 쿠버네티스 표준을 준수하는 클러스터를 생성하는 공식적인 방법입니다.14 매우 유연하고 사용자 정의 가능성이 높습니다.38 베어메탈, VM, 클라우드 VM 등 다양한 인프라 기반의 운영 환경 구축에 적합합니다.14 쿠버네티스 구성 요소와 설치 과정을 깊이 있게 학습하는 데 도움이 됩니다.42
  • 단점: Minikube나 K3s에 비해 설치 과정이 더 복잡합니다.3 사전 요구 사항 설치, CNI 플러그인 선택 등 수동으로 처리해야 할 단계가 더 많습니다.26 초보자에게는 다소 어렵게 느껴질 수 있습니다 ("hard way").44 멀티 노드 구성 시 Minikube보다 더 많은 하드웨어 자원을 요구합니다.44
  • 설치 예시: kubeadm, kubelet, kubectl 설치 후, 마스터 노드에서 kubeadm init 실행, 이후 워커 노드에서 kubeadm join 실행.38

4.5 초보자를 위한 권장 사항

어떤 도구를 선택할지는 학습 목표와 가용 자원에 따라 달라집니다.

  • 단순히 로컬에서 kubectl 명령어를 연습하고 싶다면: Minikube로 시작하는 것이 가장 빠르고 간편합니다.13
  • 간단한 멀티 노드 온프레미스 클러스터를 빠르게 구축하고 싶다면: K3s를 고려해볼 수 있습니다.42 설치가 매우 쉬워 초보자가 복잡한 설정 없이 기능하는 클러스터를 경험하기에 좋습니다.
  • 표준 설치 과정을 이해하고 향후 운영 환경에 가까운 유연성을 원한다면: kubeadm을 사용하는 것이 좋습니다.14 더 많은 노력이 필요하지만, 쿠버네티스 작동 방식에 대한 깊은 이해를 제공하고 공식적인 모범 사례를 따릅니다.

결국 사용 편의성과 학습 깊이/유연성 사이의 절충점을 고려해야 합니다. Minikube는 편의성에, K3s는 편의성과 기능성의 균형에, kubeadm은 유연성과 표준 준수에 중점을 둡니다. 초보자의 당면 목표가 빠른 실험인지, 아니면 더 견고한 클러스터 구축 경험인지에 따라 최적의 도구가 달라질 것입니다.

4.6 표 3: Minikube, K3s, kubeadm 비교 요약
기능 Minikube K3s kubeadm
주 사용 목적 로컬 학습/테스트 44 경량 클러스터/엣지/개발 27 표준/운영 클러스터 14
설치 용이성 매우 쉬움 44 매우 쉬움 (스크립트 기반) 48 중간/복잡 44
리소스 사용량 낮음 44 매우 낮음 27 높음 (표준 K8s)
노드 구성 주로 단일 노드 26 멀티 노드 멀티 노드
운영 환경 적합성 아니요 26 예 (제한적일 수 있음) 27 예 14
유연성/맞춤 설정 낮음 중간 (단순화됨) 높음 38
공식 K8s 도구 여부 아니요 (SIG 프로젝트) 아니요 (CNCF 프로젝트, Rancher/SUSE 개발) 예 (쿠버네티스 프로젝트 일부)

섹션 5: 설치 실습: 온프레미스 클러스터 구축하기

이 섹션에서는 표준적이면서도 학습 가치가 높은 kubeadm을 사용하여 온프레미스 쿠버네티스 클러스터를 구축하는 과정을 상세히 안내합니다. 비교를 위해 K3s와 Minikube의 간략한 설치 단계도 포함합니다. kubeadm 방식은 더 많은 노력이 필요하지만, 쿠버네티스의 내부 구성 요소를 이해하는 데 큰 도움이 됩니다.

5.1 kubeadm 사용 (상세 단계)

사전 준비 사항 확인: 섹션 3에서 설명한 하드웨어 및 소프트웨어 요구 사항을 모든 노드가 충족하는지 다시 확인합니다. 특히, 모든 노드의 고유 ID(호스트명, MAC, product_uuid), 스왑 비활성화, 필수 포트 개방, 호환되는 OS 및 컨테이너 런타임 설치 여부를 점검합니다.30

1단계: 컨테이너 런타임 설치 (모든 노드)

선택한 컨테이너 런타임(예: containerd 또는 Docker + cri-dockerd)을 모든 마스터 및 워커 노드에 설치합니다. 사용하는 OS에 맞는 공식 설치 가이드를 따릅니다.30 설치 후 런타임 서비스를 활성화하고 시작합니다.

Bash

# 예시: containerd 설치 (Debian/Ubuntu 기반)
sudo apt-get update
sudo apt-get install -y containerd
sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml
# systemd cgroup 드라이버 사용 설정 (권장)
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl enable containerd

2단계: kubeadm, kubelet, kubectl 설치 (모든 노드)

쿠버네티스 공식 문서에 따라 패키지 저장소를 추가하고, 원하는 버전의 kubeadm, kubelet, kubectl을 설치합니다.26 버전 불일치로 인한 문제를 피하기 위해 세 패키지의 버전을 일치시키는 것이 중요합니다.26 설치 후 kubelet 서비스를 활성화하고 시작합니다. 예기치 않은 업그레이드를 방지하기 위해 패키지 버전을 고정(apt-mark hold)하는 것이 좋습니다.40

Bash

# 예시: Debian/Ubuntu 기반 설치
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
# 특정 버전 설치 (예: 1.28.x)
sudo apt-get install -y kubelet=1.28.x-* kubeadm=1.28.x-* kubectl=1.28.x-*
sudo apt-mark hold kubelet kubeadm kubectl
sudo systemctl enable --now kubelet

3단계: 컨트롤 플레인 초기화 (마스터 노드에서만 실행)

kubeadm init 명령을 사용하여 마스터 노드를 초기화합니다.38 파드 네트워크 대역과 컨트롤 플레인 엔드포인트(마스터 노드 IP 또는 고가용성 VIP)를 지정해야 합니다.39

Bash

# <your-pod-cidr>는 사용할 CNI 플러그인에 맞춰 지정 (예: Calico의 경우 192.168.0.0/16)
# <master-node-ip>는 마스터 노드의 IP 주소
sudo kubeadm init --pod-network-cidr=<your-pod-cidr> --control-plane-endpoint=<master-node-ip>

초기화가 성공적으로 완료되면, 일반 사용자가 kubectl을 사용할 수 있도록 설정하는 명령어와 워커 노드를 클러스터에 추가할 때 사용할 kubeadm join 명령어가 출력됩니다. kubeadm join 명령어는 반드시 안전한 곳에 복사해 두어야 합니다.38

4단계: kubectl 접근 설정 (마스터 노드에서 일반 사용자로 실행)

kubeadm init 출력 결과에 나온 대로 명령어를 실행하여 현재 사용자가 클러스터와 통신할 수 있도록 kubectl 설정을 복사합니다.38

Bash

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

이제 kubectl get nodes 명령을 실행하여 마스터 노드가 보이는지 확인합니다. CNI 플러그인이 설치되기 전까지는 NotReady 상태로 표시될 수 있습니다.38

5단계: 파드 네트워크 애드온(CNI) 설치 (마스터 노드에서 실행)

파드 간 통신을 위해 CNI 플러그인을 설치해야 합니다. Calico, Flannel 등 여러 옵션 중 하나를 선택하고 해당 플러그인의 매니페스트 파일을 kubectl apply 명령으로 적용합니다.39

Bash

# 예시: Calico 설치 (버전 확인 필요)
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml

CNI 관련 파드들이 kube-system 네임스페이스에서 정상적으로 실행되는지 확인합니다 (kubectl get pods -n kube-system). CNI가 준비되면 마스터 노드의 상태가 Ready로 변경됩니다.

6단계: 워커 노드 추가 (각 워커 노드에서 실행)

3단계에서 저장해 둔 kubeadm join 명령어를 각 워커 노드에서 루트 권한으로 실행합니다.38

Bash

# 예시 명령어 형태
sudo kubeadm join <master-node-ip>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

토큰이 만료되었거나 분실한 경우, 마스터 노드에서 kubeadm token create --print-join-command 명령으로 새로운 join 명령어를 생성할 수 있습니다.38

7단계: 클러스터 설치 확인 (마스터 노드에서 실행)

모든 노드가 클러스터에 성공적으로 추가되었고 Ready 상태인지 확인합니다.38

Bash

kubectl get nodes -o wide

모든 노드가 Ready 상태로 표시되면 클러스터 설치가 완료된 것입니다.

5.2 K3s 사용 (간략 단계)

  1. 서버 노드 설치: curl -sfL https://get.k3s.io | sh - 49
  2. 토큰 확인: 서버 노드의 /var/lib/rancher/k3s/server/node-token 파일 내용 확인 49
  3. 에이전트 노드 설치: 각 에이전트 노드에서 curl -sfL https://get.k3s.io | K3S_URL=https://<server_ip>:6443 K3S_TOKEN=<token> sh - 실행 49
  4. kubectl 설정: 서버 노드의 /etc/rancher/k3s/k3s.yaml 파일을 로컬 머신의 ~/.kube/config로 복사하거나 KUBECONFIG 환경 변수 설정.49 K3s는 기본 CNI(Flannel)와 서비스 로드밸런서를 포함합니다.

5.3 Minikube 사용 (간략 단계)

  1. Minikube 및 드라이버 설치: Minikube 바이너리와 Docker 같은 가상화 드라이버 설치.36
  2. 클러스터 시작: minikube start [--driver=<driver_name>][--kubernetes-version=<version>].26
  3. kubectl 사용: Minikube가 자동으로 kubectl 설정을 관리하거나 관련 지침을 제공합니다. minikube kubectl -- 명령을 사용하거나 셸 별칭(alias)을 설정하여 사용.34

설치 과정의 복잡성은 선택한 도구에 따라 크게 달라집니다. kubeadm은 가장 많은 수동 설정과 쿠버네티스 내부 구성 요소에 대한 이해를 요구하지만, 그만큼 깊이 있는 학습 경험을 제공합니다. 반면 K3s는 설치 과정을 대폭 간소화하여 빠르게 클러스터를 구축할 수 있게 해주며, Minikube는 거의 즉각적으로 사용할 수 있는 독립적인 로컬 환경을 제공합니다.

섹션 6: 첫 애플리케이션 배포하기: 안녕하세요, Nginx!

이제 온프레미스 쿠버네티스 클러스터가 준비되었으니, 간단한 웹 서버 애플리케이션인 Nginx를 배포해 보겠습니다. 이 과정을 통해 기본적인 쿠버네티스 리소스 생성 및 관리 방법을 익힐 수 있습니다.

6.1 kubectl create deployment로 디플로이먼트 생성하기

kubectl의 명령형 커맨드를 사용하면 YAML 파일을 직접 작성하지 않고도 빠르게 디플로이먼트를 생성할 수 있습니다.50

Bash

kubectl create deployment nginx-deployment --image=nginx

이 명령어는 쿠버네티스에게 nginx-deployment라는 이름의 디플로이먼트를 생성하고, 공식 nginx 컨테이너 이미지를 사용하도록 지시합니다.50 디플로이먼트는 백그라운드에서 Nginx 컨테이너를 실행하는 파드를 생성하고 관리합니다.

6.2 디플로이먼트 매니페스트 이해하기 (YAML 간단히 보기)

위 명령어로 생성된 디플로이먼트의 실제 정의는 YAML 형식의 매니페스트 파일로 표현됩니다. kubectl get deployment nginx-deployment -o yaml 명령을 실행하면 해당 YAML 내용을 확인할 수 있습니다.

주요 필드를 간략히 살펴보면 다음과 같습니다 21:

  • apiVersion: 사용하는 쿠버네티스 API 버전 (예: apps/v1)
  • kind: Deployment: 리소스의 종류가 디플로이먼트임을 명시
  • metadata: {name: nginx-deployment}: 디플로이먼트의 이름
  • spec: 디플로이먼트의 상세 사양
    • replicas: 1: 실행할 파드의 개수 (기본값은 1)
    • selector: {matchLabels: {app: nginx-deployment}}: 이 디플로이먼트가 관리할 파드를 식별하는 레이블 셀렉터
    • template: 생성될 파드의 명세
      • metadata: {labels: {app: nginx-deployment}}: 파드에 적용될 레이블 (셀렉터와 일치해야 함)
      • spec: {containers: [...]}: 파드 내에서 실행될 컨테이너 목록
        • name: nginx: 컨테이너 이름
        • image: nginx: 사용할 컨테이너 이미지
        • ports: [{containerPort: 80}]: 컨테이너가 노출하는 포트 (Nginx 기본 포트)

쿠버네티스에서는 이처럼 YAML 파일을 사용하여 리소스의 '원하는 상태'를 선언적으로 정의하는 것이 표준적인 방식입니다.53

6.3 디플로이먼트 상태 확인하기

디플로이먼트와 그에 의해 생성된 파드의 상태를 확인합니다.

  • 디플로이먼트 롤아웃 상태 확인:

    Bash

      kubectl rollout status deployment/nginx-deployment

  • 디플로이먼트 목록 확인:

    Bash

      kubectl get deployments  # 또는 kubectl get deploy

    출력에서 DESIRED, CURRENT, UP-TO-DATE, AVAILABLE 개수를 확인하여 디플로이먼트가 정상적으로 생성되었는지 파악할 수 있습니다.

  • 파드 목록 확인:

    Bash

      kubectl get pods  # 또는 kubectl get po

    nginx-deployment-로 시작하는 이름의 파드가 생성된 것을 볼 수 있습니다. STATUS 열이 Running인지 확인합니다.53 -o wide 옵션을 사용하면 파드가 실행 중인 노드의 IP 등 더 자세한 정보를 볼 수 있습니다.52

6.4 kubectl expose deployment로 서비스 노출하기

생성된 Nginx 파드에 접근할 수 있도록 서비스를 생성하여 외부 또는 내부 네트워크에 노출해야 합니다. kubectl expose 명령을 사용하면 간단하게 서비스를 생성할 수 있습니다.50

Bash

kubectl expose deployment nginx-deployment --type=NodePort --port=80 --name=nginx-service
  • --type=NodePort: 서비스를 각 노드의 IP 주소와 특정 포트(NodePort)를 통해 외부에서 접근 가능하게 만듭니다.46 온프레미스 환경에서 외부 로드 밸런서 없이 간단하게 외부 접근을 설정하는 데 유용합니다.52
  • --port=80: 서비스 자체의 클러스터 내부 포트를 80으로 지정합니다.
  • --target-port=80: 서비스가 트래픽을 전달할 대상 파드(Nginx 컨테이너)의 포트를 80으로 지정합니다.52
  • --name=nginx-service: 생성될 서비스의 이름을 명시적으로 지정합니다.

6.5 서비스 타입 간략 소개

쿠버네티스 서비스에는 몇 가지 타입이 있습니다.

  • ClusterIP: 기본 타입. 클러스터 내부에서만 접근 가능한 가상 IP를 할당합니다.
  • NodePort: 각 노드의 IP 주소에 고정된 포트(기본 범위 30000-32767 39)를 열어 서비스를 노출합니다. <NodeIP>:<NodePort> 주소로 외부에서 접근할 수 있습니다.46
  • LoadBalancer: 클라우드 환경에서 주로 사용되며, 클라우드 제공업체의 로드 밸런서를 자동으로 프로비저닝하여 서비스를 외부에 노출합니다. 온프레미스에서는 MetalLB와 같은 추가 솔루션 설치가 필요합니다.
  • ExternalName: 서비스를 외부의 특정 DNS 이름에 매핑합니다.

이 예제에서는 온프레미스 환경에서 가장 간단하게 외부 접근을 구현할 수 있는 NodePort 타입을 사용합니다.52

6.6 Nginx 애플리케이션 접속하기

이제 생성된 NodePort 서비스를 통해 Nginx에 접속해 봅니다.

  1. NodePort 확인: kubectl get service nginx-service (또는 kubectl get svc nginx-service) 명령으로 서비스 정보를 확인하고, PORT(S) 열에서 NodePort 번호(30000번대 포트)를 확인합니다.51 예: 80:32161/TCP.
  2. 노드 IP 확인: kubectl get nodes -o wide 명령으로 워커 노드 중 하나의 외부 IP 주소를 확인합니다.52
  3. 접속: 웹 브라우저나 curl 명령을 사용하여 http://<NodeIP>:<NodePort> 주소로 접속합니다 (예: http://192.168.1.101:32161).52 성공적으로 접속되면 Nginx 기본 환영 페이지가 나타납니다.

쿠버네티스는 이처럼 '원하는 상태'를 디플로이먼트 같은 리소스로 선언하고(선언적 모델), kubectl 명령을 통해 빠르게 조작할 수도 있습니다(명령형 방식). 서비스는 파드의 IP가 계속 변하는 환경에서 안정적인 네트워크 접근점을 제공하는 핵심적인 추상화 계층입니다.2 NodePort는 온프레미스 환경에서 외부 접근을 위한 실용적인 출발점입니다.

섹션 7: 클러스터 관리하기: 필수적인 일상 작업

쿠버네티스 클러스터를 운영하면서 수행해야 하는 기본적인 관리 작업과 관련 kubectl 명령어들을 알아봅니다.

7.1 클러스터 및 노드 상태 확인하기

클러스터의 전반적인 건강 상태를 확인하는 가장 기본적인 방법은 노드 상태를 점검하는 것입니다.

Bash

kubectl get nodes

이 명령어는 클러스터에 속한 모든 노드의 목록과 각 노드의 상태(Ready, NotReady 등), 역할(control-plane, worker), 실행 시간, 쿠버네티스 버전 등을 보여줍니다.28 -o wide 옵션을 추가하면 노드의 내부/외부 IP 주소, OS 정보 등 더 자세한 내용을 확인할 수 있습니다.52 노드가 Ready 상태인지 주기적으로 확인하는 것은 클러스터 상태 점검의 기본입니다.

7.2 리소스 상세 정보 확인하기 (kubectl describe)

특정 리소스(파드, 노드, 서비스, 디플로이먼트 등)에 대한 자세한 정보를 확인하고 싶을 때 사용합니다.

Bash

kubectl describe <리소스 타입> <리소스 이름>
# 예시: kubectl describe pod nginx-deployment-xxxxx
# 예시: kubectl describe node my-worker-node
# 예시: kubectl describe service nginx-service

describe 명령어는 해당 리소스의 레이블, 어노테이션, 현재 상태, IP 주소, 리소스 요청/제한량, 그리고 가장 중요하게는 관련된 이벤트(Events) 목록을 보여줍니다.53 이벤트 로그는 리소스 생성 실패, 스케줄링 문제, 이미지 가져오기 오류 등 문제를 진단하는 데 매우 중요한 단서를 제공합니다.22

7.3 애플리케이션 로그 확인하기 (kubectl logs)

파드 내에서 실행 중인 컨테이너의 로그(표준 출력 stdout 및 표준 에러 stderr)를 확인하는 명령어입니다.56

Bash

kubectl logs <파드 이름> [-c <컨테이너 이름>]
  • -f 옵션을 사용하면 실시간으로 로그 스트림을 볼 수 있습니다 (파일의 tail -f와 유사).27
  • -p 또는 --previous 옵션을 사용하면 비정상적으로 종료된 컨테이너의 이전 로그를 확인할 수 있습니다.58
  • 하나의 파드에 여러 컨테이너가 실행 중인 경우, -c <컨테이너 이름> 옵션으로 특정 컨테이너를 지정해야 합니다.27

로그는 일반적으로 컨테이너가 실행 중인 노드에 파일 형태로 저장되며, kubelet이 관리합니다.56 kubectl logs 명령은 API 서버와 kubelet을 통해 이 로그를 가져와 보여줍니다.56 애플리케이션 오류를 디버깅하는 데 필수적인 명령어입니다.22

7.4 애플리케이션 확장하기 (kubectl scale deployment)

디플로이먼트가 관리하는 파드(레플리카)의 개수를 조절하여 애플리케이션을 수평적으로 확장하거나 축소합니다.

Bash

kubectl scale deployment <디플로이먼트 이름> --replicas=<원하는 파드 개수>
# 예시: kubectl scale deployment nginx-deployment --replicas=3

이 명령어는 nginx-deployment가 관리하는 파드의 개수를 3개로 조절합니다.59 부하 증가에 대응하기 위해 파드 수를 늘리거나(스케일 업), 자원 사용량을 줄이기 위해 파드 수를 줄일 수 있습니다(스케일 다운, 0으로 설정하여 완전히 중지하는 것도 가능).61 디플로이먼트 외에도 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등 다른 컨트롤러도 scale 명령으로 확장/축소할 수 있습니다.61

7.5 애플리케이션 업데이트하기 (간략 소개)

디플로이먼트는 애플리케이션 업데이트를 손쉽게 관리하는 롤링 업데이트(Rolling Update) 전략을 기본으로 사용합니다.6

  1. 이미지 변경: 디플로이먼트 정의에서 사용하는 컨테이너 이미지를 새 버전으로 변경합니다. kubectl set image 명령이나 YAML 파일을 수정한 후 kubectl apply를 사용합니다.

    Bash

     # 예시: nginx 이미지를 1.25.3 버전으로 업데이트
 kubectl set image deployment/nginx-deployment nginx=nginx:1.25.3

  2. 롤링 업데이트 진행: 쿠버네티스는 설정된 전략에 따라 점진적으로 기존 버전의 파드를 종료하고 새 버전의 파드를 생성하여 교체합니다.6 이 과정에서 서비스 중단을 최소화합니다.

  3. 상태 확인 및 롤백: kubectl rollout status deployment/<이름> 명령으로 업데이트 진행 상태를 모니터링할 수 있습니다. 문제가 발생하면 kubectl rollout undo deployment/<이름> 명령으로 이전 버전으로 쉽게 롤백할 수 있습니다.6

7.6 파드 내부 접속하기 (kubectl exec)

실행 중인 컨테이너 내부에 직접 접속하여 명령을 실행할 수 있습니다. 디버깅이나 상태 확인에 유용합니다.

Bash

kubectl exec -it <파드 이름> -- [-c <컨테이너 이름>] <실행할 명령어>
# 예시: 파드 내에서 bash 셸 실행
kubectl exec -it nginx-deployment-xxxxx -- bash

-it 옵션은 상호작용 가능한 터미널 세션을 제공합니다.54 이를 통해 컨테이너 내부의 파일 시스템을 탐색하거나, 네트워크 상태를 확인하거나, 필요한 유틸리티를 실행할 수 있습니다.22

7.7 기본적인 문제 해결 단계

클러스터나 애플리케이션에 문제가 발생했을 때 시도해 볼 수 있는 기본적인 진단 단계입니다.

  1. 파드 상태 확인: kubectl get pods 명령으로 파드 상태를 확인합니다. Error, CrashLoopBackOff, ImagePullBackOff, Pending 등의 비정상 상태를 주의 깊게 봅니다.53
  2. 파드 상세 정보 확인: 문제가 있는 파드에 대해 kubectl describe pod <파드 이름> 명령을 실행합니다.22 특히 하단의 Events 섹션에 오류 메시지(예: 스케줄링 실패, 이미지 가져오기 실패, Liveness/Readiness 프로브 실패 등)가 있는지 확인합니다.
  3. 컨테이너 로그 확인: kubectl logs <파드 이름> [-c 컨테이너 이름][--previous] 명령으로 애플리케이션 자체의 오류 로그를 확인합니다.22
  4. 디플로이먼트/서비스 상태 확인: kubectl get deployments, kubectl get services 명령으로 관련 컨트롤러와 서비스의 상태를 확인하고, kubectl describe 명령으로 상세 정보를 점검하여 설정 오류나 엔드포인트 연결 문제 등을 파악합니다.
  5. 클러스터 이벤트 확인: kubectl get events --sort-by='.metadata.creationTimestamp' 명령으로 클러스터 전반의 이벤트를 시간순으로 확인하여 광범위한 문제의 단서를 찾습니다.59

7.8 간단한 모니터링

클러스터의 기본적인 리소스 사용량을 확인하는 방법입니다.

  • 리소스 사용량 확인: kubectl top node 및 kubectl top pod 명령은 각각 노드와 파드의 현재 CPU 및 메모리 사용량을 보여줍니다. 이 명령어를 사용하려면 클러스터에 Metrics Server 애드온이 설치되어 있어야 합니다.63 Metrics Server는 실시간 측정치만 제공하며 데이터를 장기간 저장하지는 않습니다. 주로 Horizontal Pod Autoscaler(HPA)에서 사용됩니다.63
  • 쿠버네티스 대시보드: 쿠버네티스 클러스터를 위한 웹 기반 UI입니다. 클러스터에 별도로 배포해야 하며, 리소스 상태 확인, 기본적인 메트릭 조회, 일부 관리 작업 수행이 가능합니다.

이들은 기본적인 모니터링 도구이며, 실제 운영 환경에서는 시간에 따른 변화 추이를 보고 경고를 설정하기 위해 Prometheus + Grafana와 같은 보다 포괄적인 모니터링 시스템을 구축하는 것이 일반적입니다.1

효과적인 클러스터 관리는 몇 가지 핵심 kubectl 명령어(get, describe, logs, exec, scale)를 능숙하게 사용하는 것에서 시작됩니다. 특히 describe와 logs는 초기 문제 해결에 가장 중요한 도구입니다. 기본적인 모니터링은 kubectl top으로 시작할 수 있지만, 운영 환경에서는 더 강력한 솔루션이 필요하다는 점을 인지하는 것이 중요합니다.

7.9 표 4: 필수 kubectl 명령어 빠른 참조
명령어 목적
kubectl get <타입> [이름][-o wide][-n 네임스페이스] 리소스 목록 조회
kubectl describe <타입> <이름> [-n 네임스페이스] 리소스 상세 정보 및 이벤트 확인 29
kubectl apply -f <파일명.yaml> YAML 파일로부터 리소스 생성 또는 업데이트 54
kubectl delete <타입> <이름> |-f <파일명.yaml>
kubectl logs <파드> [-c 컨테이너][-f][-p] 컨테이너 로그 확인 (-f: 실시간, -p: 이전 로그) 56
kubectl exec -it <파드> -- [-c 컨테이너] <명령> 컨테이너 내부에서 명령어 실행 (예: bash) 54
kubectl scale deployment <이름> --replicas=N 디플로이먼트 파드 개수 조절 59
kubectl top node|pod [-n 네임스페이스]
kubectl get events 클러스터 이벤트 목록 확인 59

섹션 8: 온프레미스 환경의 현실: 도전 과제와 고려 사항

온프레미스 환경에서 쿠버네티스를 직접 운영하는 것은 클라우드 관리형 서비스를 사용하는 것과 비교하여 상당한 도전 과제를 안고 있습니다. 이러한 어려움을 미리 인지하고 대비하는 것이 중요합니다.

8.1 설치 및 유지보수의 복잡성

클라우드 제공업체가 처리해주는 많은 부분을 온프레미스에서는 사용자가 직접 책임져야 합니다. 초기 클러스터 설치, 구성부터 시작하여 하드웨어, 운영체제, 쿠버네티스 컴포넌트, 네트워킹, 스토리지 등 전체 스택에 대한 지속적인 유지보수 및 문제 해결이 필요합니다.16 이는 상당한 수준의 기술적 전문 지식과 노력을 요구합니다.18

8.2 업데이트 및 업그레이드

쿠버네티스는 약 3개월마다 새로운 버전이 릴리스됩니다.18 온프레미스 클러스터를 최신 상태로 유지하기 위한 업그레이드 과정(컨트롤 플레인, 노드, etcd, 애드온 등)은 매우 복잡하고 신중한 계획이 필요합니다.16 업그레이드 중 서비스 중단이 발생할 수 있으며, 버전 간 호환성 문제에 직면할 수도 있습니다.18 일반적으로 개발/테스트 환경에서 먼저 업그레이드를 검증한 후 운영 환경에 적용하는 단계적 접근 방식이 권장됩니다.18

8.3 보안 관리

온프레미스 환경에서는 클러스터 보안의 모든 측면이 사용자의 책임입니다.16 여기에는 다음 사항들이 포함됩니다:

  • 기반
728x90
저작자표시 비영리 변경금지

'100===Dev Ops > Kubernetes' 카테고리의 다른 글

Kubernetes 인그레스  (2) 2025.04.13
쿠버네티스(Kubernetes) Helm - 복잡한 애플리케이션 배포의 구세주! 🚀  (1) 2025.04.12

'100===Dev Ops/Kubernetes'의 다른글

  • 현재글쿠버네티스 온프레미스 설치부터 활용, 관리까지

관련글

티스토리툴바