Kubernetes란?

Kubernetes는 클러스터 전반에서 컨테이너를 배포, 관리, 확장하는 데 DevOps가 사용하는 오픈 소스 소프트웨어입니다. Docker는 또 다른 오픈 소스 기술이며, Kubernetes와 함께 흔히 사용하는 기본 컨테이너 파일 형식입니다.

컨테이너

컨테이너는 앱과 해당 종속성 및 구성을 함께 묶어 서로 다른 환경에서도 일관되게 실행되도록 합니다. 애플리케이션이 커지면 여러 서버에서 많은 컨테이너를 실행하게 될 수 있습니다. 이 모든 것을 수동으로 조정하는 일은 점점 복잡해집니다. Kubernetes는 오픈 소스 API와 제어 시스템으로 이 복잡성을 해결합니다. 무엇을 어디서 실행할지 결정하고, 계속 실행되도록 유지합니다.

Kubernetes가 수행하는 일

스케줄링 및 리소스 배치

Kubernetes는 가상 머신 클러스터를 조정하고, 사용 가능한 컴퓨팅 리소스와 각 컨테이너의 리소스 요구 사항에 따라 컨테이너를 예약합니다.

서비스 검색 및 부하 분산

Kubernetes는 서비스 검색과 부하 분산을 관리하므로, Pod가 시간에 따라 바뀌어도 트래픽을 올바른 Pod로 보낼 수 있습니다.

수요에 맞춘 확장

Kubernetes는 컴퓨팅 사용량과 설정한 원하는 상태를 기준으로 워크로드를 확장합니다.

문제가 생겨도 자동으로 복구

Kubernetes는 리소스 상태를 확인하고, 문제가 생기면 컨테이너를 다시 시작하거나 복제할 수 있습니다. 문제가 생긴 컨테이너는 다시 시작하거나 대체하고, 워크로드가 준비될 때까지 트래픽을 받지 않도록 합니다.

제어된 변경 지원

Kubernetes는 정의한 원하는 상태를 기준으로 자동 롤아웃과 롤백을 포함해 실행 중인 애플리케이션에 배포 패턴을 지원합니다.

구성 및 비밀 관리

Kubernetes는 암호나 토큰 같은 중요한 정보에 대한 비밀 정보와 구성 관리를 제공합니다.

스토리지 오케스트레이션

Kubernetes는 Kubernetes의 스토리지 조정 모델에 따라 여러분이 선택한 스토리지 시스템을 마운트할 수 있습니다. 예를 들어 로컬 스토리지나 퍼블릭 클라우드 옵션이 있습니다.

간단한 오브젝트 용어집

Kubernetes는 선언하고 관리하는 리소스인 API 개체를 중심으로 구성됩니다. 몇 가지 예를 살펴보겠습니다:

• Pod: 하나 이상의 컨테이너를 실행하는 기본 단위입니다.

• 서비스: 앱을 노출하고 변경되는 Pod로 트래픽을 보내는 안정적인 방법입니다.

• D배포: 원하는 앱 상태를 설명하고 시간이 지나면서 업데이트하는 방법입니다. 보통 롤아웃과 롤백에 연결됩니다.

• 노드: Pod가 실행되는 클러스터의 머신입니다.

• 컨트롤 플레인: 클러스터 상태와 예약 결정을 관리하는 구성 요소입니다.

전체 동작 방식

1. 애플리케이션의 원하는 상태를 선언합니다. 무엇을 실행할지, 몇 개를 복제할지, 필요한 리소스는 무엇인지 정의합니다.

2. 컨트롤 플레인은 Kubernetes API와 백업 저장소를 통해 해당 요청을 기록하고 처리합니다.

3. 스케줄러는 충분한 리소스가 있는 노드에 Pod를 배치합니다.

4. 노드 구성 요소가 워크로드를 실행합니다.

5. 컨트롤러는 실제 상태가 원하는 상태와 일치하도록 계속 조정합니다. 필요에 따라 워크로드를 확장, 교체 및 업데이트합니다.

주요 구성 요소

클러스터: 컨트롤 플레인과 작업자 노드

일반적으로 Kubernetes 클러스터는 두 부분으로 설명합니다. 클러스터를 관리하는 컨트롤 플레인과 워크로드를 실행하는 작업자 노드 입니다.

컨트롤 플레인 구성 요소

이 구성 요소는 클러스터의 전체 상태를 관리합니다.

• kube-apiserver: Kubernetes HTTP API를 노출합니다. 요청을 받는 앞문 역할을 합니다.

• etcd: 클러스터 데이터를 위한 일관되고 고가용성인 키-값 저장소입니다.

• kube-scheduler: 배치가 필요한 Pod를 찾아 노드에 할당합니다.

• kube-controller-manager: 실제 상태를 원하는 상태로 맞추는 컨트롤러를 실행합니다.

• cloud-controller-manager (선택 사항): Kubernetes를 클라우드 공급자별 제어 로직에 연결합니다.

노드 구성 요소

각 워커 노드는 Pod와 네트워킹 규칙을 유지하는 소프트웨어를 실행합니다.

• kubelet: 컨테이너를 포함해 노드에서 Pod가 실행되도록 보장합니다.

• kube-proxy (선택 사항): 서비스를 지원하는 네트워크 규칙을 유지합니다.

• 컨테이너 런타임: 노드에서 컨테이너를 실행합니다.

Pod: 기본 작업 단위

Kubernetes는 추상적으로 개별 컨테이너를 직접 예약하지는 않습니다. 대신 하나 이상의 컨테이너를 Pod로 묶고, 이를 기본 운영 단위로 사용합니다. 그다음 Pod는 정의한 원하는 상태를 향해 늘어나거나 줄어듭니다.

실제로는 다음과 같습니다:

1. 실행하려는 앱을 설명합니다.

2. Kubernetes는 사용 가능한 컴퓨팅 자원이 있는 머신에 Pod를 예약합니다.

3. 컨트롤러는 요청한 상태를 향해 클러스터가 계속 나아가도록 유지합니다.

서비스 네트워킹

Pod는 언제든 생겼다가 사라질 수 있습니다. 그래서 Kubernetes는 클러스터에서 애플리케이션을 설명하고 실행하는 데 함께 사용하는 기본 구성 요소인 프리미티브를 제공하며, 이를 통해 워크로드에 안정적으로 접근할 수 있습니다.

Pod 네트워킹 기본

각 Pod에는 클러스터 전체에서 고유한 IP 주소가 할당됩니다. Kubernetes 네트워크 모델에서는 NAT 없이도 Pod가 노드 간에 통신할 수 있습니다.

서비스

Service API는 개별 Pod가 시간에 따라 바뀌어도 백엔드 Pod 집합에 안정적인 IP 주소나 호스트 이름을 제공합니다.

EndpointSlice

Kubernetes는 현재 어떤 Pod가 서비스를 뒷받침하는지 추적하기 위해 엔드포인트 슬라이스 객체를 유지합니다.

수신/Gateway API

클러스터 밖의 클라이언트에 서비스를 노출하려면 Kubernetes는 Gateway API를 지원합니다. 이전에는 수신을 사용했습니다.

LoadBalancer 서비스

일부 환경에서는 LoadBalancer 서비스 유형을 사용해 서비스를 외부에 노출할 수 있습니다.

클러스터에서 실행할 수 있는 추가 기능

Kubernetes 클러스터에는 핵심 구성 요소를 넘어 기능을 확장하는 추가 기능이 포함되는 경우가 많습니다. 예를 들면 다음과 같습니다.

• 클러스터 전체 이름 확인을 위한 DNS.

• 클러스터 관리를 위한 웹 UI (대시보드).

• 컨테이너 리소스 모니터링으로 메트릭을 수집합니다.

• 클러스터 수준 로깅으로 로그를 중앙에서 수집합니다.

Kubernetes는 컨테이너화된 애플리케이션을 여러 머신으로 이루어진 클러스터에서 실행하고, 사용자가 지정한 상태로 유지합니다. 이를 위해 작업을 적절한 머신에 배치하고, 트래픽을 올바른 위치로 라우팅하고, 장애와 변경 사항을 모니터링합니다.

기본 흐름

1. 실행할 항목을 설명합니다.

대부분의 Kubernetes 워크로드는 선언한 “desired state”(실행되어야 하는 항목, 복제본 수 및 노출 방식)에서 시작합니다. Kubernetes는 선언적 구성과 자동화를 중심으로 설계되었습니다.

2. Kubernetes가 실행 위치를 결정합니다

Kubernetes는 사용 가능한 컴퓨팅 리소스와 각 컨테이너의 요구 사항을 기준으로 클러스터의 머신에 컨테이너를 스케줄합니다. 컨테이너는 컴퓨터에서 Kubernetes가 배치하는 단위인 Pod 내에서 실행됩니다.

3. Kubernetes는 실제 상태와 사용자가 원하는 상태를 계속 비교합니다.

컨트롤러는 클러스터를 감시하고 현재 상태를 원하는 상태에 더 가깝게 만들기 위해 작업합니다. 변경은 API 서버를 사용해 적용합니다.

컨테이너 스케줄링 및 일상 관리

스케줄링은 “어디에서 실행해야 할까?”를 뜻합니다 의사 결정.

1. 개별 컨테이너가 아니라 Pod가 스케줄링됩니다.

Kubernetes는 컨테이너를 Pod로 묶은 다음, 그 Pod를 머신에 배치합니다.

2. 스케줄러가 Pod를 적절한 노드에 할당합니다.

kube-scheduler는 아직 할당되지 않은 Pod를 찾아서 해당 Pod를 배치할 노드를 선택합니다.

3. 노드 에이전트가 Pod를 계속 실행 상태로 유지합니다.

각 노드에서 kubelet은 Pod가 실행 중인지 확인합니다. 컨테이너도 포함됩니다.

부하 분산 및 서비스 검색

컨테이너와 Pod는 생성되거나 이동되거나 교체될 수 있으므로, 애플리케이션에는 서로를 안정적으로 찾을 수 있는 방법이 필요합니다.

서비스 검색과 부하 분산은 기본 제공되는 동작입니다

Kubernetes는 서비스 검색을 관리하고 부하 분산을 사용하므로, 시간이 지나 Pod가 바뀌어도 트래픽을 계속 라우팅할 수 있습니다.

서비스는 바뀌는 Pod 집합에 대해 안정적인 주소를 제공합니다.

Service API는 하나 이상의 Pod가 뒷받침하는 서비스에 안정적인 IP 주소나 호스트 이름을 제공합니다. Kubernetes는 EndpointSlice 객체를 통해 뒷받침하는 Pod를 추적합니다.

Pod가 변경되면 트래픽 라우팅도 업데이트됩니다.

서비스 뒤의 Pod가 바뀌면 서비스 라우팅도 그에 맞게 조정되어 트래픽이 계속 현재 백엔드로 전달됩니다.

애플리케이션 확장하기 (그리고 “desired state”가 중요한 이유)

Kubernetes는 사용자가 설정한 상태를 향해 워크로드를 확장할 수 있습니다. 컴퓨팅 사용률을 기준으로도 확장할 수 있습니다.

일반적인 확장 방식은 다음과 같습니다:

• 복제본을 더 많이 추가하고(Pod 수 증가) 수요가 늘어난 상황을 처리합니다.

• 수요가 줄면 복제본 수를 줄입니다.

• 리소스 추적을 통해 배치 결정이 CPU와 메모리 요구 사항을 반영하도록 합니다.

이는 “desired state” 모델과 연결됩니다. 목표를 지정하면, 컨트롤러가 계속 그 목표를 향해 작업합니다.

자동 복구: 문제가 생기면 어떻게 될까요

Kubernetes에는 워크로드의 상태와 가용성을 유지하도록 돕는 자가 치유 동작이 포함되어 있습니다. 해당 지역은 다음과 같습니다.

• 실패한 컨테이너 다시 시작 (컨테이너 수준 재시작).

• 실패한 Pod를 교체 해 요청한 복제본 수를 유지합니다(복제본 교체).

• 노드를 사용할 수 없게 될 때 워크로드를 다시 예약합니다.

• 실패한 Pod를 서비스 엔드포인트에서 제거 해 트래픽이 건강한 Pod로만 가도록 합니다(서비스용 부하 분산).

자가 치유는 컨테이너 상태를 확인하고, 문제가 생기면 다시 시작하거나 복제합니다.

Kubernetes KPI의 역할

핵심 성과 지표(KPI 또는 메트릭)는 클러스터 상태와 워크로드 동작을 이해하는 데 사용됩니다.

KPI가 어디에서 오는지

• Kubernetes 시스템 구성 요소는 대시보드와 경고에 유용한 메트릭(Prometheus 형식)을 내보냅니다.

• 메트릭은 일반적으로 kube-apiserver, kube-scheduler, kubelet, kube-proxy, kube-controller-manager 같은 구성 요소를 포함해 각 구성 요소의 /metrics HTTP 엔드포인트에서 사용할 수 있습니다.

KPI로 확인할 수 있는 예

• 클러스터 상태 신호 (구성 요소 수준 메트릭과 오류 패턴)

• 워크로드 안정성 (예: 잦은 재시작이나 교체)

• 용량 압박 (리소스 할당과 수요의 관계로, 확장 결정과 연결됨)

일상 운영에서 이것이 중요한 이유

모니터링을 통해 팀은 클러스터 리소스, Kubernetes API, 컨테이너 및 로그를 더 폭넓게 볼 수 있습니다. 그래서 문제를 발견하고 해결하는 사이의 피드백 루프가 짧아집니다.

Kubernetes는 많은 컨테이너를 여러 머신에서 일관되게 실행해야 할 때 자주 선택됩니다. 이때 트래픽 라우팅, 확장 및 복구는 플랫폼이 처리합니다.

확장성

Kubernetes는 워크로드를 확장할 수 있습니다. 즉, 수요 변화에 맞춰 늘리거나 줄일 수 있습니다. 목표 상태를 기준으로 하며, 컴퓨팅 사용률에 따라도 확장할 수 있습니다.

일반 사용 예

• 트래픽이 변동하는 웹 앱 (캠페인, 계절성 피크): 부하가 바뀌면 복제본 수를 조정합니다.

• 배치 또는 이벤트 기반 처리: 급증 시 용량을 늘렸다가, 이후에는 다시 줄입니다.

• 마이크로서비스: 전체 애플리케이션이 아니라 특정 서비스만 확장합니다.

리소스 효율성

Kubernetes는 자동 빈 패킹도 지원합니다. 이는 CPU와 메모리 요구 사항에 따라 컨테이너를 노드에 배치해 사용 가능한 리소스를 더 효율적으로 쓰는 방식입니다. 또한 워크로드를 관리하는 동안 리소스 할당도 추적합니다.

일반 사용 예

• 여러 팀이 함께 쓰는 공유 클러스터: 리소스를 사용할 수 있는 위치에 워크로드를 배치해 낭비되는 용량을 줄입니다.

• 혼합 워크로드 클러스터 (서비스와 작업 모두 포함): 수동 배치 없이 노드를 계속 활용합니다.

서비스 검색 및 부하 분산

Kubernetes는 DNS 또는 IP 주소를 사용해 워크로드를 노출할 수 있고, 배포가 안정적으로 유지되도록 네트워크 트래픽을 분산할 수 있습니다. 또한 서비스 검색을 관리하고, 워크로드가 바뀔 때 부하 분산도 적용합니다.

일반 사용 예

• 마이크로서비스 간 통신: Pod가 바뀌어도 서비스는 안정적인 이름으로 서로를 찾습니다.

• 안정적인 엔드포인트 뒤의 내부 API: 현재 백엔드로만 트래픽을 라우팅합니다.

자동 복구

Kubernetes는 실패한 컨테이너를 교체하고, 노드를 사용할 수 없게 되면 워크로드를 다시 예약하고, 원하는 상태를 유지하도록 설계되었습니다. 예를 들어 컨테이너를 다시 시작하거나 복제본을 교체하고, 상태가 좋지 않은 Pod를 서비스 엔드포인트에서 제거해 트래픽이 정상적인 Pod로만 가도록 합니다.

일반 사용 예

• Always-on 서비스: 수동 개입 없이 실패한 인스턴스를 다시 시작하거나 교체합니다.

• 노드 변경이 잦은 클러스터: 노드가 중단되면 워크로드를 다시 예약합니다.

• 서비스 뒤의 서비스: 상태가 좋지 않은 Pod로는 트래픽을 보내지 않습니다.

더 안전한 릴리스

Kubernetes는 자동 롤아웃과 롤백을 지원합니다. 원하는 상태를 정의하면, Kubernetes가 실제 상태를 제어된 속도로 그 상태에 맞춰 갑니다.

일반 사용 예

• 자주 애플리케이션을 업데이트하는 경우: 변경 내용을 점진적으로 배포한 다음, 필요하면 되돌립니다.

• 여러 서비스를 배포하는 Teams: 앱 전반에서 릴리스 방식을 일관되게 유지하세요.

이식성

컨테이너화된 앱은 인프라와 분리되어 있습니다. Kubernetes는 로컬 머신에서 온-프레미스, 서버리스, 하이브리드 클라우드, 그리고 다중 클라우드 환경의 프로덕션으로 앱을 옮길 수 있게 도와주며, 환경 전반에서 일관성도 유지해 줍니다.

일반 사용 예

• 개발/테스트/프로덕션 환경의 일관성: 환경이 달라도 동일한 패키징과 스케줄링 모델을 유지합니다.

• 하이브리드 배포: 시스템의 일부는 온-프레미스에서, 일부는 클라우드에서 같은 오케스트레이션 방식으로 실행합니다.

Kubernetes는 선언적 구성과 기계 학습 자동화를 바탕으로, 컨테이너화된 워크로드를 실행하는 공통 방식을 제공합니다. 또한 방대하고 계속 성장하는 도구와 커뮤니티 지원도 함께 제공합니다.

클라우드 네이티브 앱에서 여전히 중요한 이유

팀이 많은 서비스, 단기 실행 워크로드 및 잦은 업데이트로 구성된 시스템을 만들 때도 Kubernetes는 반복 가능한 작업에 집중하기 때문에 실용적인 기반으로 남아 있습니다.

• 환경 전반에서 일관된 작업 (컨테이너를 종속성과 함께 패키징하고, 어디서나 같은 방식으로 실행).

• 서비스, 지원 및 도구를 폭넓게 이용할 수 있는 활발한 에코시스템.

• 커뮤니티가 만든 추가 기능과 플러그인으로 확장할 수 있고, 핵심 API를 버전 간에 일관되게 유지하는 적합성 프로그램도 제공합니다.

워크로드를 빌드하거나 실행하려는 경우, AKS(Azure Kubernetes Service)를 사용하면 컨테이너화된 애플리케이션을 배포하고 관리할 수 있습니다. 컨트롤 플레인은 Azure가 관리합니다.