컨테이너 오케스트레이션이란 무엇인가요?

컨테이너 오케스트레이션은 컨테이너화된 애플리케이션의 구축, 관리 및 확장을 자동화하는 기술입니다. 많은 수의 컨테이너를관리하는 복잡한 작업을 간소화합니다. Kubernetes와같은 컨테이너 오케스트레이터는 이러한 컨테이너가 서로 다른 서버와 환경에서 효율적으로 상호 작용하도록 보장합니다. 오케스트레이터는 컨테이너 수명 주기를 관리하고, 서비스 검색을 용이하게 하며, 고가용성을 유지하기 위한 프레임워크를 제공합니다. 클라우드 네이티브 애플리케이션이 수많은 상호 의존적인 구성 요소로 구성된 마이크로서비스 아키텍처의경우, 이 프레임워크가 기본입니다.

DevOps 팀은 컨테이너 오케스트레이션을 활용하여 프로비저닝, 리소스 할당, 대규모 확장을 간소화함으로써 컨테이너화의 잠재력을 최대한 활용하고 이를 비즈니스 목표에 맞출 수 있습니다.

 

컨테이너 오케스트레이션 설명

컨테이너 오케스트레이션은 컨테이너화된 애플리케이션의 구축, 관리 및 확장을 자동화합니다. 기업에서는 오케스트레이터를 활용하여 수많은 컨테이너를 제어하고 조정하여 여러 서버에서 효율적으로 상호 작용할 수 있도록 합니다.

오케스트레이션 계층은 새로운 버전의 마이크로서비스를 구축하고, 수요에 맞게 마이크로서비스를 대규모로 확장하며, 성능 및 상태를 위해 마이크로서비스를 모니터링합니다.

그림 1: 오케스트레이션 계층은 새로운 버전의 마이크로서비스를 구축하고, 수요에 맞게 마이크로서비스를 대규모로 확장하며, 성능 및 상태를 위해 마이크로서비스를 모니터링합니다.

Kubernetes와 같은 오케스트레이터는 라이프사이클을 관리하고, 서비스 검색을 용이하게 하며, 고가용성을 유지합니다. 컨테이너는 클라우드 네이티브 애플리케이션이 수많은 상호 의존적인 구성 요소로 구성된 마이크로서비스 아키텍처에 필수적인 컨테이너가 함께 작동할 수 있게 해줍니다.

실제로 컨테이너 오케스트레이션 시장은 마이크로서비스 아키텍처, 클라우드 네이티브 애플리케이션, 컨테이너화의채택과 보조를 맞추고 있습니다. 2022년 7억 4,572만 달러(5년 동안 26% 증가)로 계산된 시장 규모는 지속적으로 증가하여 2029년에는 10억 8,479만 달러에 달할 것으로 예상됩니다.

 

오케스트레이션 도구

오케스트레이션 도구는 컨테이너 워크로드 자동화를 위한 프레임워크를 제공하여 DevOps 팀이 컨테이너의 수명주기를 관리할 수 있도록 합니다. 이러한 시스템 또는 오케스트레이션 엔진은 고급 네트워크 기능을 촉진하여 컨테이너와 마이크로서비스의 프로비저닝을 간소화하는 동시에 수요에 맞게 리소스를 조정합니다. DevOps 팀은 오케스트레이터를 통해 컨테이너화의 잠재력을 최대한 발휘하여 비즈니스 목표에 맞게 조정할 수 있습니다.

인기 있는 컨테이너 오케스트레이션 엔진

  • Kubernetes®(K8s)
  • 랜처
  • SUSE 랜처
  • 아마존 엘라스틱 쿠버네티스 서비스(EKS)
  • Azure Kubernetes 서비스(AKS)
  • 구글 쿠버네티스 엔진(GKE)/안토스
  • 레드햇 오픈시프트 컨테이너 플랫폼(OCP)
  • Mesos
  • Cisco 컨테이너 플랫폼(CCP)
  • 쿠버네티스용 오라클 컨테이너 엔진(OKE)
  • 에릭슨 컨테이너 클라우드(ECC)
  • 도커 스웜
  • 해시코프 노마드

오케스트레이션 엔진의 장점은 일반적으로 사용하는 선언적 모델에서 비롯되며, 이는 서비스형 인프라(IaaS)서비스형 플랫폼(PaaS)의 장점을 효과적으로 결합합니다.

  • IaaS는 개발자가 서버, 스토리지, 네트워크 등 기본 인프라를 관리할 수 있는 세분화된 제어 및 자동화를 제공합니다. 이를 통해 개발자는 특정 요구 사항을 충족하도록 구축 환경을 유연하게 사용자 지정할 수 있습니다.
  • PaaS는 개발자가 기본 인프라에 대해 걱정할 필요 없이 애플리케이션에만 집중할 수 있도록 더 높은 수준의 추상화를 제공합니다. PaaS를 사용하면 엔지니어가 애플리케이션을 더 쉽게 구축하고 관리할 수 있지만 인프라에 대한 통제력이 떨어지기도 합니다.

오케스트레이터는 물리적 머신과 온프레미스 데이터 센터부터 가상 구축 및 클라우드 기반 시스템에 이르기까지 다양한 환경에서 일관된 운영 환경을 제공할 뿐만 아니라 개발자에게 강력한 성능과 유연성을 제공합니다.

주요 오케스트레이션 엔진의 핵심 기능에는 스케줄링, 리소스 관리, 서비스 검색, 상태 확인, 자동 확장, 업데이트 및 업그레이드 관리 등이 있습니다.

 

오케스트레이터의 주요 구성 요소

컨테이너 오케스트레이션 구성 요소에 대한 용어는 현재 시중에 나와 있는 도구마다 다릅니다. 하지만 기본 개념과 기능은 비교적 일관되게 유지됩니다. 표 3은 주요 구성 요소와 인기 있는 컨테이너 오케스트레이터의 해당 용어를 비교한 개요입니다. 여기서는 오케스트레이션 메커니즘에 대한 이해를 돕기 위해 Kubernetes 용어를 사용하겠습니다.

컨테이너 오케스트레이션 구성 요소 개요

그림 2: 컨테이너 오케스트레이션 구성 요소 개요

Kubernetes와 같은 오케스트레이션 엔진은 컨테이너의 수명 주기를 관리하기 위해 함께 작동하는 몇 가지 주요 기술 구성 요소로 구성된 복잡한 구조입니다. 주요 구성 요소를 이해하면 컨테이너화 기술을 가장 잘 활용하는 방법을 이해할 수 있습니다.

제어 평면

애플리케이션 라이프사이클을 예약하고 관리하기 위한 명령 센터인 컨트롤 플레인이 Kubernetes의 핵심입니다. 컨트롤 플레인은 Kubernetes API를 노출하고, 구축을 오케스트레이션하며, 시스템 전체에서 통신을 지시합니다. 또한 컨테이너 상태를 모니터링하고 클러스터를 관리하여 구축 시 레지스트리에서 컨테이너 이미지를 쉽게 사용할 수 있도록 합니다.

쿠버네티스 컨트롤 플레인은 etcd, API 서버, 스케줄러, 컨트롤러-매니저 등 여러 구성 요소로 이루어져 있다.

Etcd

CoreOS가 개발하고 나중에 Red Hat이 인수한 etcd 데이터스토어는 클러스터의 구성 데이터를 보관하는 분산 키-값 저장소입니다. 선언적 정책에 정의된 대로 원하는 애플리케이션 상태를 유지하기 위한 오케스트레이터의 작업을 알려줍니다. 이 정책은 인스턴스 수, 스토리지 요구 사항, 리소스 할당과 같은 속성을 관리할 때 오케스트레이터를 안내하여 애플리케이션을 위한 최적의 환경을 설명합니다.

API 서버

Kubernetes API 서버는 중추적인 역할을 하며, RESTful 인터페이스를 통해 클러스터의 기능을 노출합니다. 요청을 처리하고, 유효성을 검사하고, 수신된 명령에 따라 클러스터의 상태를 업데이트합니다. 이 메커니즘을 통해 워크로드와 리소스를 동적으로 구성하고 관리할 수 있습니다.

스케줄러

쿠버네티스의 스케줄러는 리소스 가용성과 서비스 품질 및 선호도 규칙과 같은 기타 제약 조건에 따라 워커 노드에 워크로드를 할당합니다. 스케줄러는 클러스터의 현재 상태 및 리소스 구성에 맞게 워크로드 배포가 최적화된 상태로 유지되도록 합니다.

컨트롤러-관리자

컨트롤러 관리자는 애플리케이션의 원하는 상태를 유지합니다. 클러스터의 공유 상태를 모니터링하고 현재 상태를 원하는 상태에 맞추기 위해 조정하는 컨트롤러, 제어 루프를 통해 작동합니다. 이러한 컨트롤러는 노드와 파드의 안정성을 보장하고 클러스터의 상태 변화에 대응하여 운영의 일관성을 유지합니다.

컨테이너 오케스트레이터 컨트롤 플레인 컴포넌트 워커 노드 컴포넌트 구축 단위 서비스
Kubernetes API 서버, 스케줄러, 컨트롤러 관리자 등d kubelet Pod 서비스
도커 스웜 관리자 Worker 서비스 스택
Nomad 서버 에이전트 Job 할당
Mesos 마스터 에이전트 작업 Job
OpenShift 콘솔, 컨트롤러 관리자 등 노드 Pod 서비스
Amazon Elastic 컨테이너 서비스(ECS) 클러스터 컨트롤러 EC2 인스턴스 작업 서비스
구글 쿠버네티스 엔진(GKE) 제어 평면 노드 Pod 서비스
Azure Kubernetes 서비스(AKS) 제어 평면 노드 Pod 서비스

표 1: 다양한 오케스트레이션 엔진의 공통 구성 요소.

오케스트레이션 및 불변 인프라

기존 서버 및 가상 머신과 달리 컨테이너와 컨테이너 인프라는 불변의 패러다임으로 인해 구축 후 수정이 불가능합니다. 대신, 필요한 변경 사항이 있는 공통 이미지에서 새 컨테이너 또는 서버를 구축하여 업데이트 또는 수정 사항을 적용합니다.

불변 인프라의 고유한 프로그래밍 기능으로 자동화가 가능합니다. 코드형 인프라(IaC)는 애플리케이션이 필요한 인프라를 프로그래밍 방식으로 프로비저닝, 구성 및 관리할 수 있도록 하는 최신 인프라의 특징으로 두드러집니다. 컨테이너 오케스트레이션, 불변 인프라, IaC 기반 자동화의 결합으로 탁월한 유연성과 확장성을 제공합니다.

 

컨테이너 오케스트레이션과 파이프라인

컨테이너화와 DevOps라는 쌍둥이 엔진에 의해 추진되는 컨테이너 오케스트레이션은 속도와 확장성을 함께 제공하여 오늘날의 역동적이고 까다로운 프로덕션 파이프라인을뒷받침합니다.

CI/CD 파이프라인 애플리케이션 개발 라이프사이클

그림 3: CI/CD 파이프라인 애플리케이션 개발 라이프사이클

파이프라인 확보 및 구축 단계

획득 및 빌드 단계에서는 개발자가 버전 관리 리포지토리에서 코드를 가져와 빌드 프로세스를 시작합니다. 자동화된 도구는 소스 코드를 Docker 또는 BuildKit과 같은 도구를 사용하여 구축할 준비가 된 바이너리 아티팩트로 컴파일합니다. 컨테이너 이미지가 빌드되면 Docker Hub 또는 Google 아티팩트 레지스트리와 같은 레지스트리에 저장됩니다.

수집 및 빌드 단계에서는 종속성을 관리하고 예비 테스트를 실행하는 스크립트를 통해 애플리케이션의 일관된 구성을 촉진합니다. 그 결과 메인 브랜치와 통합하면 더욱 자동화된 프로세스를 트리거하는 신뢰할 수 있는 빌드가 생성됩니다.

실행 단계

빌드 단계가 끝나면 파이프라인은 제어된 환경에서 코드를 실행합니다. 스테이징 환경에서 컨테이너 이미지를 실행하는 것은 Kubernetes와 같은 컨테이너 오케스트레이션 도구를 사용하여 수행할 수 있습니다. 이 중요한 단계에서는 팀이 애플리케이션의 기능을 검증하기 위해 일련의 자동화된 테스트를 수행합니다. 개발자는 버그를 적극적으로 찾아 해결하여 파이프라인을 통해 고품질 코드만 진행되도록 합니다.

전달 단계

CI/CD 파이프라인의 배포 단계에서 팀은 새 코드가 리포지토리에서 프로덕션 준비 단계로 이동하는 과정을 자동화합니다. 모든 커밋은 일련의 엄격한 자동화된 테스트와 품질 검사를 시작하여 잘 검증된 코드만 스테이징 환경에 도달할 수 있도록 합니다. 여기서 소프트웨어는 추가적인 클라이언트 대면 검증을 거칩니다. 이 프로세스는 빌드를 안정성과 성능을 검증하는 환경으로 승격하는 과정을 캡슐화합니다. 제공 단계에 대한 팀의 헌신은 소프트웨어가 현재 개발 노력의 최고를 구현하도록 보장합니다.

구축 단계

구축 단계에서는 팀이 애플리케이션을 프로덕션 환경에 배포하면서 애플리케이션이 결정적인 순간에 도달합니다. Kubernetes와 같은 컨테이너 오케스트레이션 도구가 제어를 맡아서 애플리케이션을 대규모로 확장하고 최소한의 다운타임으로 업데이트합니다. 팀에는 롤백 메커니즘이 준비되어 있어 문제가 발생하면 이전 버전으로 되돌릴 수 있습니다. 이 시점에서 애플리케이션이 작동하여 의도한 사용자에게 서비스를 제공하고 디지털 생태계에서 그 목적을 달성하게 됩니다.

무대 유지 관리

구축 후에는 팀이 애플리케이션을 적극적으로 유지 관리하는 단계로 전환합니다. 이들은 런타임 솔루션을 사용하여 성능을 지속적으로 모니터링하고, 오류를 기록하고, 사용자 피드백을 수집하여 컨테이너 보안뿐만아니라 향후 개선 사항을 추진합니다.

개발자가 애플리케이션을 미세 조정하고, 보안 패치를 적용하고, 새로운 기능을 출시할 때 유지 관리 단계는 최신 애플리케이션 개발의 반복적인 특성을 강조합니다. 이 제품은 사용자 요구를 충족하고 최신 기술 발전을 통합하기 위해 지속적으로 발전하고 있습니다.

 

컨테이너 오케스트레이션의 이점

컨테이너 오케스트레이션은 DevOps의 목표에 부합하는 일련의 이점을 제공하여 궁극적으로 클라우드 환경의 운영 효율성을 향상하고 오버헤드를 줄입니다.

확장성 향상

컨테이너 오케스트레이션 플랫폼을 통해 기업은 사람의 개입이나 애플리케이션 부하 예측 없이도 변동하는 수요에 대응하여 컨테이너화된 애플리케이션을 대규모로 확장할 수 있습니다. 오케스트레이터의 빈 패키지 및 자동 확장 기능과 코드형 퍼블릭 클라우드 인프라가 결합되어 리소스를 동적으로 할당하여 피크 부하 시 최적의 성능을 보장합니다.

회복 탄력성 촉진

오케스트레이션 도구는 컨테이너 인스턴스를 여러 호스트에 분산하여 애플리케이션 복원력을 강화합니다. 장애를 감지하고 컨테이너를 자동으로 재시작하여 가동 중단 시간을 최소화하고 서비스 연속성을 유지합니다.

효율성 향상

오케스트레이션 엔진은 다양한 사용 시나리오에서 애플리케이션의 요구 사항에 맞게 리소스를 조정하여 만연한 오버프로비저닝을 방지하거나 조직이 높은 물 사용률을 위해 설계 및 계획해야 하는 상황을 방지합니다. 이러한 효율성을 통해 인프라 비용을 절감하고 투자 수익률을 극대화할 수 있습니다.

관리 간소화

컨테이너 오케스트레이터는 컨테이너 클러스터를 관리할 수 있는 통합 인터페이스를 제공하여 복잡한 작업을 추상화하고 운영 부담을 줄여줍니다. 팀은 최소한의 수동 개입으로 업데이트를 구축하고, 상태를 모니터링하고, 정책을 시행할 수 있습니다.

보안 향상

컨테이너 오케스트레이션은 패치 및 보안 업데이트 구축을 자동화하여 보안을 강화합니다. 전체 컨테이너 차량에 일관된 보안 정책을 적용하여 취약성 위험을 줄입니다.

휴대성 지원

오케스트레이션은 컨테이너화된 애플리케이션이 기본 인프라에 구애받지 않고 다양한 클라우드 환경과 온프레미스 데이터센터 간에 이동성을 유지하도록 보장합니다.

구축 주기 단축

구축 프로세스를 자동화하는 오케스트레이션 도구는 개발에서 프로덕션까지 걸리는 시간을 단축하여 신속한 반복 작업과 새로운 기능의 출시 시간을 단축할 수 있습니다.

DevOps 사례 지원

CI/CD 파이프라인과 통합되어 소프트웨어 개발의 민첩성을 향상시키는 컨테이너 오케스트레이션은 개발팀과 운영팀 간의 협업을 촉진합니다. 상태 모니터링 및 자가 복구와 같은 기능을 통해 팀은 시스템 지원 및 문제 해결을 덜 수행하여 DevOps 생산성을 최적화할 수 있습니다.

 

컨테이너 에코시스템

간단히 말해, 컨테이너 에코시스템은 애플리케이션 개발과 구축에 있어 중요한 변화를 의미합니다. 런타임 엔진부터 오케스트레이션 플랫폼, 레지스트리, 보안 도구에 이르기까지 다양한 구성 요소를 포괄하는 이 솔루션은 오늘날 급변하는 디지털 환경이 요구하는 가장 중요한 효율성을 기업에게 제공합니다.

물론 에코시스템의 중심에는 컨테이너 엔진과 오케스트레이션 엔진의 시너지가 있습니다. 이러한 기술은 컨테이너화된 애플리케이션의 복잡한 수명 주기 단계를 함께 안내합니다.

컨테이너 엔진은 개별 컨테이너를 생성하고 패키징하며, 오케스트레이터 엔진은 분산 인프라 전반에서 여러 컨테이너를 관리하고 오케스트레이션합니다.

개발 과정에서 컨테이너 엔진은 신속한 프로토타이핑과 테스트를 지원하므로 개발자는 빠르고 효율적으로 반복 작업을 수행할 수 있습니다. 애플리케이션이 성숙해지면 오케스트레이터는 이를 프로덕션 환경으로 전환하여 실제 워크로드를 처리할 수 있는 강력하고 확장 가능한 기반을 제공합니다.

컨테이너 및 오케스트레이션 엔진의 역학을 대표하는 Docker와 Kubernetes

그림 4: 컨테이너 및 오케스트레이션 엔진의 역학을 대표하는 Docker와 Kubernetes

비즈니스 리더를 위한 전략적 시사점

소프트웨어 구축의 민첩성 및 속도 향상

컨테이너 에코시스템은 애플리케이션 구축을 가속화합니다. 애플리케이션을 컨테이너에 캡슐화함으로써 조직은 기본 환경에 관계없이 개발에서 프로덕션으로 신속하게 이동할 수 있습니다. 이러한 민첩성은 시장 변화나 사용자 요구에 빠르게 적응해야 하는 조직에 매우 중요합니다.

효율성 및 리소스 최적화 향상

기존 가상 머신의 대안을 제공하는 컨테이너는 기본 OS 커널을 공유하며 더 적은 리소스를 사용합니다. 이러한 효율성은 운영 비용 절감과 컴퓨팅 리소스 활용도 향상으로 이어지며, 이는 대규모 애플리케이션을 관리하는 기업에게 중요한 이점입니다.

확장성 및 유연성

수요 변동이 심한 디지털 기업에 필수적인 컨테이너 에코시스템 내의 오케스트레이터를 통해 기업은 성능 저하 없이 애플리케이션을 대규모로 확장할 수 있습니다. 컨테이너 에코시스템은 전체적으로 확장성과 리소스 가용성을 위해 이전의 용량을 개선합니다.

환경 간 일관성 및 이식성 유지

컨테이너 에코시스템은 일관성과 이동성을 보장합니다. 컨테이너에 패키징된 애플리케이션은 온프레미스 데이터센터부터 퍼블릭 클라우드에 이르기까지 다양한 컴퓨팅 환경에서 균일하고 안정적으로 실행할 수 있습니다.

호스팅 컨테이너 환경의 해부학

그림 5: 호스팅 컨테이너 환경의 해부학

컨테이너 중심의 미래를 위한 준비

미래는 모든 애플리케이션은 아니더라도 대부분의 애플리케이션이 컨테이너에서 실행되는 디지털 세상을 가리킵니다. 경영진에게 컨테이너 에코시스템의 시너지를 이해하면 전략적 이점을 얻을 수 있습니다. 정보에 입각한 관점으로 무장하면 최신 소프트웨어 개발의 진화하는 요구 사항을 예측하고 효과적으로 충족할 수 있으며, 최적의 ROI를 달성할 수 있습니다.

 

컨테이너 오케스트레이션 FAQ

헬름은 쿠버네티스용 패키지 관리자로, 쿠버네티스 클러스터에서 애플리케이션의 구축과 관리를 간소화합니다. 사전 구성된 쿠버네티스 리소스인 차트라는 패키지를 사용합니다. 헬름 차트는 가장 복잡한 쿠버네티스 애플리케이션도 정의, 설치 및 업그레이드하는 프로세스를 간소화합니다. 차트 간의 종속성을 관리하고 제어된 방식으로 업데이트합니다. 헬름은 애플리케이션을 구축하는 효율적이고 반복 가능하며 표준화된 방법을 제공하므로 복잡한 구축을 관리하는 DevOps 팀에게 필수적입니다.
쿠버네티스의 레플리카셋은 지정된 수의 파드 레플리카가 지정된 시간에 실행되도록 한다. 주로 지정된 수의 동일한 파드의 가용성을 보장하는 데 사용됩니다. 파드가 실패하면 레플리카셋이 새 파드를 시작하여 이를 대체합니다. 레플리카셋은 특히 분산되고 동적인 클라우드 환경에서 애플리케이션의 원하는 상태와 고가용성을 유지하는 데 매우 중요합니다.
쿠버네티스 구축은 애플리케이션에 대한 선언적 업데이트를 제공한다. 이를 통해 앱에 사용할 이미지, 포드 수, 업데이트 방법 등 애플리케이션의 수명 주기를 설명할 수 있습니다. 구축은 레플리카셋을 관리하고 이전 구축 상태로 롤백하는 기능을 제공하므로 상태 비저장 애플리케이션을 관리하고 복원력 및 확장성을 보장하는 데 필수적입니다.
쿠버네티스의 스테이트풀셋은 스테이트풀 애플리케이션을 관리하는 데 사용됩니다. 구축에서 관리하는 상태 저장 애플리케이션과 달리 상태 저장 애플리케이션은 영구 저장소와 고유한 네트워크 식별자가 필요합니다. 스테이트풀셋은 각 파드에 대해 고정 ID를 유지하여 각 파드가 다른 노드로 이동하더라도 동일한 호스트 이름과 스토리지로 다시 예약되도록 합니다.
쿠버네티스의 데몬셋은 모든(또는 일부) 노드가 특정 파드의 사본을 실행하도록 합니다. 클러스터에 노드가 추가되면 자동으로 파드가 클러스터에 추가됩니다. 마찬가지로 클러스터에서 노드가 제거되면 해당 파드는 가비지 수집됩니다. 데몬셋은 전체 클러스터에서 이러한 작업의 구축과 규모를 자동으로 관리하므로 모든 노드에서 로깅, 모니터링 또는 네트워크 프록시와 같은 작업을 실행하는 데 이상적입니다.
쿠버네티스의 서비스는 논리적 파드 집합과 이에 액세스하기 위한 정책을 정의하는 추상화입니다. 이 추상화는 작업 정의를 포드에서 분리합니다. 서비스는 일반적으로 셀렉터에 의해 결정되는 일련의 파드에 걸쳐 트래픽을 라우팅합니다. 종속 파드 간의 느슨한 결합을 가능하게 하여 파드에 액세스할 수 있는 IP 주소와 DNS 이름을 제공합니다. 서비스는 네트워크에 연결된 애플리케이션이 기본 포드 구성의 변경에 쉽게 액세스하고 탄력적으로 대응할 수 있도록 하는 데 매우 중요합니다.
쿠버네티스의 인그레스는 클러스터 내의 서비스에 대한 외부 액세스를 관리하는 리소스로, 일반적으로 HTTP입니다. 인그레스를 사용하면 URL 경로, 로드 밸런싱, SSL 종료 및 이름 기반 가상 호스팅을 포함하여 서비스로 트래픽을 라우팅하는 규칙을 정의할 수 있습니다. 외부에서 컨테이너화된 애플리케이션에 대한 액세스를 관리하기 위한 핵심 구성 요소로, 단순한 포트 포워딩보다 더 정교하고 유연한 솔루션을 제공합니다.
쿠버네티스의 컨피그맵은 기밀이 아닌 데이터를 키-값 쌍으로 저장하는 데 사용되는 리소스입니다. 파드는 환경 변수, 명령줄 인수 또는 볼륨의 구성 파일로 컨피그맵을 사용할 수 있으므로 이미지 콘텐츠에서 구성 아티팩트를 분리할 수 있다.
쿠버네티스에서 PV(퍼시스턴트 볼륨)는 관리자가 프로비저닝하거나 스토리지 클래스를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지 조각이다. 노드와 마찬가지로 클러스터의 리소스이며 개별 파드의 수명 주기 이후에도 지속됩니다. PV는 애플리케이션이 기본 스토리지 인프라와 독립적으로 스토리지를 마운트할 수 있는 방법을 제공하여 스테이트풀 애플리케이션을 위한 보다 일관되고 통합된 스토리지 솔루션을 제공합니다.
쿠버네티스의 PVC(퍼시스턴트 볼륨 클레임)는 사용자의 스토리지 요청입니다. 파드는 노드 리소스를 소비하고 PVC는 PV 리소스를 소비한다는 점에서 파드와 유사합니다. PVC를 통해 사용자는 스토리지가 제공되는 방식과 소비되는 방식에 대한 세부 정보를 추상화할 수 있습니다. 사용자가 PVC를 요청하면 클러스터에서 사용 가능한 PV에 바인딩되어 Kubernetes 환경에서 스토리지 리소스를 동적으로 관리할 수 있는 방법을 제공합니다.
쿠버네티스의 자동 확장은 현재 로드에 따라 구축, 레플리카 세트 또는 스테이트풀 세트의 파드 수를 자동으로 조정하는 것을 의미합니다. 자동 확장은 애플리케이션이 주어진 시간에 적절한 양의 리소스를 확보하여 리소스 활용도를 개선하고 변동하는 워크로드를 효율적으로 처리하는 데 도움이 됩니다. 수평 파드 오토스케일러(HPA)와 수직 파드 오토스케일러(VPA)는 각각 파드 수와 파드의 규모를 확장하는 쿠버네티스의 두 가지 일반적인 유형의 오토스케일러이다.
이전 컨테이너 레지스트리 보안이란 무엇인가요?