디플로이먼트

디플로이먼트는 소프트웨어 개발 라이프사이클에서 최종 산출물인 애플리케이션이나 서비스를 특정 운영 환경에 설치하고 구성하여 최종 사용자가 접근하고 사용할 수 있도록 만드는 일련의 과정을 의미한다. 이 과정은 단순한 파일 복사나 설치를 넘어, 애플리케이션이 의도한 대로 안정적으로 실행될 수 있도록 필요한 모든 리소스와 의존성을 준비하는 것을 포함한다. 따라서 디플로이먼트는 개발 단계와 실제 서비스 운영 단계를 연결하는 핵심적인 다리 역할을 한다.

이 과정의 궁극적인 목적은 개발된 기능을 실제 프로덕션 환경에 릴리스하여 사용자에게 가치를 전달하는 것이다. 이를 위해 디플로이먼트는 단순한 배포뿐만 아니라, 배포 후 애플리케이션의 상태를 지속적으로 확인하고 문제가 발생할 경우 신속하게 대응하거나 이전 상태로 복구하는 활동까지 포괄한다. 이는 DevOps 문화와 실천법에서 특히 강조되는 부분으로, 개발과 운영의 경계를 허물고 지속적인 전달과 안정성을 추구한다.

디플로이먼트는 일반적으로 몇 가지 주요 단계를 거쳐 진행된다. 먼저 소스 코드를 컴파일하고 패키징하는 빌드 단계를 거친 후, 다양한 테스트를 통해 품질을 검증한다. 이후 검증된 패키지를 목표 환경에 릴리스하고, 서비스가 정상적으로 동작하는지 모니터링한다. 이러한 단계들은 자동화 도구를 통해 파이프라인 형태로 구성되어, 신속하고 반복 가능한 배포를 가능하게 한다.

효율적이고 안전한 디플로이먼트를 위해 여러 배포 전략이 활용된다. 대표적으로 서버를 차례로 교체해 가며 업데이트하는 롤링 업데이트, 새 버전과 구 버전의 환경을 병행 운영하는 블루-그린 배포, 일부 사용자에게만 새 버전을 적용해 테스트하는 카나리 배포, 그리고 서로 다른 버전을 사용자 그룹에 나누어 제공하는 A/B 테스트 등이 있다. 이러한 전략들은 서비스 중단 시간을 최소화하고 배포 위험을 관리하는 데 기여한다.

디플로이먼트의 궁극적인 목적은 개발된 소프트웨어 애플리케이션을 실제 서비스 환경, 즉 프로덕션에 안정적으로 릴리스하여 최종 사용자에게 가치를 전달하는 것이다. 이는 단순히 코드를 서버에 복사하는 것을 넘어, 애플리케이션이 의도한 대로 작동하고 사용자 요청에 응답할 수 있도록 모든 필요한 구성 요소를 특정 환경에 설치하고 구성하는 포괄적인 과정을 의미한다.

이 과정을 통해 개발 팀의 작업 결과물이 실제 비즈니스 가치로 전환된다. 디플로이먼트 없이는 웹사이트, 모바일 앱, 기업용 소프트웨어 등 어떤 애플리케이션도 사용자에게 서비스될 수 없다. 따라서 디플로이먼트는 소프트웨어 개발 수명 주기에서 개발 단계와 운영 단계를 연결하는 핵심적인 다리 역할을 하며, DevOps 문화의 실현을 가능하게 하는 기반 활동이다.

또한 현대적인 디플로이먼트는 단순한 배포를 넘어 서비스의 지속적인 가용성과 안정성을 보장하는 것을 목표로 한다. 이를 위해 롤링 업데이트, 블루-그린 배포, 카나리 배포 같은 다양한 배포 전략을 사용하여 새로운 버전의 애플리케이션을 중단 없이 배포하거나, 문제 발생 시 빠르게 이전 상태로 롤백할 수 있도록 한다. 이는 다운타임을 최소화하고 사용자 경험을 보호하기 위함이다.

궁극적으로 효율적인 디플로이먼트는 배포 속도를 높이고 배포 위험을 낮추어 조직이 시장 변화에 빠르게 대응하고, 기능을 지속적으로 개선하며, 안정적인 서비스 품질을 유지하도록 돕는다. 이는 지속적 통합 및 지속적 배포 파이프라인의 최종 단계를 구성하여 소프트웨어 제공의 자동화와 효율성을 극대화하는 데 기여한다.

디플로이먼트는 소프트웨어를 개발 환경에서 프로덕션 환경으로 이전하는 일련의 과정이다. 이 과정은 단순한 파일 복사가 아니라, 애플리케이션이 안정적으로 실행되고 사용자 요청을 처리할 수 있도록 인프라를 구성하고 소프트웨어를 설치 및 설정하는 것을 포함한다. DevOps 문화에서는 개발과 운영의 경계를 허물고, 디플로이먼트를 자동화하여 더 빠르고 안정적인 서비스 제공을 추구한다.

디플로이먼트의 주요 특징은 자동화, 일관성, 그리고 가시성에 있다. 자동화된 파이프라인을 통해 빌드, 테스트, 배포 단계를 반복적이고 오류 없이 수행할 수 있으며, 이는 배포 속도와 신뢰성을 크게 향상시킨다. 특히 인프라를 코드로 관리하는 IaC 방식을 통해 동일한 환경을 재현할 수 있어, 개발 환경과 운영 환경 간의 차이로 인한 문제를 줄일 수 있다.

또한, 다양한 배포 전략을 활용하여 서비스 중단 시간을 최소화하고 위험을 관리하는 것이 특징이다. 롤링 업데이트는 새 버전을 점진적으로 교체하며, 블루-그린 배포는 완전히 별도의 환경을 준비하여 전환하는 방식이다. 카나리 배포나 A/B 테스트는 특정 사용자 그룹에게만 새 버전을 노출하여 성능과 안정성을 검증한 후 전체에 적용하는 전략이다.

마지막으로, 배포 후 애플리케이션 성능과 상태를 실시간으로 모니터링하고 로그를 수집하는 것은 현대 디플로이먼트의 필수 요소이다. 이를 통해 문제를 신속하게 감지하고, 필요한 경우 이전 안정 버전으로의 롤백을 수행할 수 있어 서비스의 가용성과 안정성을 유지하는 데 기여한다.

파드 템플릿은 디플로이먼트가 생성하고 관리할 파드의 사양을 정의하는 청사진이다. 이 템플릿은 디플로이먼트의 핵심 구성 요소로, 애플리케이션을 실행하는 컨테이너의 이미지, 환경 변수, 리소스 요청 및 한계, 볼륨 마운트와 같은 설정을 포함한다. 디플로이먼트는 이 템플릿을 기반으로 지정된 레플리카 수만큼 동일한 파드 인스턴스를 생성하고, 파드가 중단되면 템플릿을 사용해 새로운 파드를 교체한다.

파드 템플릿은 쿠버네티스 매니페스트 파일의 spec.template 필드에 정의된다. 이는 레플리카셋의 템플릿과 동일한 구조를 가지며, 디플로이먼트가 내부적으로 레플리카셋을 생성하여 파드 관리를 위임하기 때문이다. 템플릿을 변경하면, 예를 들어 컨테이너 이미지의 버전을 업데이트하면, 디플로이먼트는 이를 새로운 릴리스로 인식하고 설정된 업데이트 전략에 따라 파드를 점진적으로 교체한다. 따라서 파드 템플릿은 애플리케이션의 원하는 상태를 선언적으로 정의하는 역할을 한다.

디플로이먼트에서 레플리카 수는 실행되어야 하는 동일한 파드의 인스턴스 개수를 지정하는 핵심 구성 요소이다. 이 수치는 애플리케이션의 가용성과 처리 용량을 결정한다. 관리자는 디플로이먼트 매니페스트 파일에서 replicas 필드에 원하는 숫자를 명시적으로 정의함으로써, 쿠버네티스 클러스터가 해당 애플리케이션을 몇 개의 복제본으로 운영할지 지시한다.

레플리카 수를 조정하는 것은 스케일링의 기본 형태이다. 수요 증가에 대응하여 처리량을 높이려면 레플리카 수를 늘리는 수평 스케일 아웃을 수행한다. 반대로, 리소스를 절약하거나 트래픽이 적은 시간대에는 레플리카 수를 줄이는 스케일 인이 가능하다. 이 조정은 수동으로 명령을 실행하거나, Horizontal Pod Autoscaler를 설정하여 CPU 사용률 같은 지표를 기반으로 자동화할 수 있다.

디플로이먼트의 컨트롤러는 선언된 레플리카 수를 지속적으로 모니터링하며 현재 상태를 의도한 상태와 비교한다. 만약 어떤 파드가 장애로 종료되거나 노드에서 삭제되면, 디플로이먼트는 실행 중인 파드의 수가 지정된 레플리카 수보다 적어짐을 감지하고, 즉시 새로운 파드를 생성하여 개수를 맞춘다. 이 자기 치유 메커니즘은 애플리케이션의 고가용성을 보장하는 데 필수적이다.

디플로이먼트의 업데이트 전략은 애플리케이션의 새 버전을 중단 없이 안전하게 교체하기 위한 방법을 정의한다. 쿠버네티스의 디플로이먼트는 주로 롤링 업데이트 방식을 기본 전략으로 채택하며, 이를 통해 서비스의 가용성을 유지하면서 점진적으로 파드를 업데이트한다. 이 전략은 새 파드를 하나씩 생성하고 기존 파드를 하나씩 제거하는 방식으로 진행되어, 항상 지정된 레플리카 수만큼의 파드가 서비스를 제공할 수 있도록 보장한다.

주요 업데이트 전략으로는 롤링 업데이트 외에도 재생성(Recreate) 전략이 있다. 재생성 전략은 모든 기존 파드를 한 번에 종료한 후 새 버전의 파드를 일괄 생성하는 방식이다. 이 방법은 업데이트 중에 짧은 다운타임이 발생할 수 있지만, 애플리케이션의 상태가 완전히 초기화되어야 하거나 버전 간 호환성이 보장되지 않는 경우에 유용하다. 사용자는 디플로이먼트 매니페스트에서 .spec.strategy.type 필드를 설정하여 원하는 전략을 명시할 수 있다.

롤링 업데이트를 세부적으로 제어하기 위해 maxUnavailable와 maxSurge 파라미터를 조정할 수 있다. maxUnavailable은 업데이트 과정에서 사용 불가능하게 허용할 최대 파드 수를 지정하며, maxSurge는 레플리카 수를 초과하여 생성할 수 있는 최대 파드 수를 정의한다. 이러한 파라미터를 조정하면 업데이트 속도와 서비스의 안정성 사이의 균형을 맞출 수 있다. 예를 들어, maxUnavailable을 0으로 설정하면 업데이트 중 가용 파드 수가 레플리카 수 이하로 떨어지지 않도록 보장할 수 있다.

이러한 업데이트 전략은 블루-그린 배포나 카나리 배포 같은 고급 배포 패턴을 구현하는 기반이 된다. 디플로이먼트는 업데이트 과정에서 발생할 수 있는 문제를 신속하게 감지하고, 사용자가 이전 안정 버전으로의 롤백을 쉽게 수행할 수 있도록 한다. 이를 통해 DevOps 팀은 지속적 제공 파이프라인을 구축하고 마이크로서비스 아키텍처 환경에서 효율적인 애플리케이션 라이프사이클 관리를 실현할 수 있다.

디플로이먼트는 쿠버네티스에서 애플리케이션을 배포하고 관리하기 위한 핵심 컨트롤러이다. 사용자는 YAML 또는 JSON 형식의 선언적 매니페스트 파일을 작성하여 디플로이먼트를 생성한다. 이 파일에는 실행할 컨테이너 이미지, 필요한 레플리카 수, 그리고 파드의 구성 템플릿과 같은 원하는 상태가 명시된다. kubectl 명령줄 도구를 사용해 이 매니페스트를 쿠버네티스 API 서버에 적용하면, 디플로이먼트 오브젝트가 생성된다.

생성된 디플로이먼트는 선언된 상태를 유지하기 위해 지속적으로 작동한다. 디플로이먼트 컨트롤러는 실제 상태를 주기적으로 관찰하며, 지정된 레플리카 수와 현재 실행 중인 파드 수를 비교한다. 만약 파드가 의도한 수보다 적게 실행 중이면, 디플로이먼트는 내부적으로 레플리카셋을 생성하거나 조정하여 새로운 파드를 기동한다. 반대로 파드가 너무 많으면 초과분을 종료한다. 이 과정을 통해 노드 장애로 인한 파드 손실도 자동으로 복구된다. 또한, 애플리케이션 업데이트 시 새로운 파드 템플릿을 적용하면 디플로이먼트는 새로운 레플리카셋을 생성하고 정해진 업데이트 전략에 따라 기존 파드를 점진적으로 새로운 파드로 교체한다.

디플로이먼트의 스케일링은 애플리케이션의 트래픽 부하나 리소스 요구사항 변화에 대응하여 실행 중인 파드의 복제본 수를 동적으로 조정하는 기능이다. 이는 쿠버네티스가 제공하는 핵심적인 자동화 관리 기능 중 하나로, 애플리케이션의 가용성과 성능을 유지하는 데 필수적이다. 사용자는 원하는 레플리카 수를 명시적으로 지정하거나, Horizontal Pod Autoscaler를 설정하여 CPU 사용률 같은 지표를 기반으로 자동으로 스케일링되도록 구성할 수 있다.

스케일링은 주로 두 가지 방식으로 이루어진다. 수동 스케일링은 관리자가 kubectl scale 명령어를 사용하거나 디플로이먼트 매니페스트 파일의 replicas 필드를 수정하여 직접 복제본 수를 변경하는 방식이다. 반면, 자동 스케일링은 HPA를 통해 시스템이 미리 정의된 메트릭 임계값을 모니터링하다가 조건에 맞춰 파드 수를 늘리거나 줄이는 방식으로 작동한다. 이를 통해 피크 시간대의 트래픽 급증에 대비하거나, 유휴 시간대의 리소스를 절약할 수 있다.

스케일링 작업이 실행되면, 디플로이먼트 컨트롤러는 현재 상태를 원하는 상태로 조정하기 위해 작업을 시작한다. 복제본 수를 늘리는 스케일 아웃의 경우, 디플로이먼트는 지정된 파드 템플릿을 바탕으로 새로운 파드를 생성하여 클러스터 내 노드에 스케줄링한다. 반대로 복제본 수를 줄이는 스케일 인의 경우, 실행 중인 파드 중에서 종료할 대상을 선정하여 정상적으로 종료 절차를 진행한다. 이 모든 과정은 디플로이먼트에 의해 관리되는 레플리카셋을 통해 실제 파드의 생성과 삭제가 이루어진다.

롤링 업데이트는 애플리케이션의 새 버전을 무중단으로 배포하기 위한 전략이다. 이 방식은 새 버전의 인스턴스를 하나씩 또는 소수씩 순차적으로 교체해 나가며, 이전 버전의 인스턴스는 새 인스턴스가 정상적으로 가동될 때까지 계속 서비스를 제공한다. 이를 통해 전체 서비스의 가용성을 유지하면서 점진적으로 업데이트를 완료할 수 있다.

쿠버네티스의 디플로이먼트는 롤링 업데이트를 기본 업데이트 전략으로 채택하고 있다. 사용자는 파드 템플릿의 이미지 태그나 설정을 변경하면, 디플로이먼트 컨트롤러가 지정된 레플리카 수를 유지하면서 기존 파드를 새 사양의 파드로 교체한다. 교체 속도는 maxUnavailable와 maxSurge 파라미터로 제어할 수 있다.

롤링 업데이트의 주요 장점은 배포 중 서비스 중단을 최소화할 수 있다는 점이다. 또한 새 버전에 문제가 발생했을 때 롤백 절차를 신속하게 시작할 수 있어 위험을 줄인다. 하지만 업데이트가 완료되기까지 시간이 상대적으로 길며, 배포 과정에서 일시적으로 이전 버전과 새 버전이 공존할 수 있어 호환성 관리가 필요하다.

이 전략은 지속적인 서비스 제공이 필수적인 웹 애플리케이션이나 마이크로서비스 아키텍처에서 널리 사용된다. 블루-그린 배포나 카나리 배포와 같은 다른 무중단 배포 전략에 비해 인프라 자원을 추가로 요구하지 않는다는 점이 특징이다.

롤백은 새로운 애플리케이션 버전을 배포한 후 문제가 발생했을 때, 시스템을 이전의 안정적인 버전으로 되돌리는 작업이다. 이는 디플로이먼트의 핵심 기능 중 하나로, 소프트웨어 개발과 운영을 통합하는 DevOps 관행에서 서비스의 가용성과 안정성을 보장하는 중요한 안전 장치 역할을 한다. 롤백은 배포 후 발견된 치명적인 버그, 성능 저하, 호환성 문제 등으로 인해 서비스 장애가 발생하거나 발생할 가능성이 높을 때 신속하게 실행된다.

디플로이먼트는 일반적으로 롤백을 자동화된 방식으로 지원한다. 예를 들어, 롤링 업데이트 전략을 사용하는 경우, 새로운 파드를 점진적으로 생성하고 기존 파드를 제거하며 업데이트를 진행한다. 이 과정에서 사전 정의된 건강 검사에 실패하거나 관리자가 명시적으로 지시하면, 디플로이먼트 컨트롤러는 자동으로 업데이트를 중단하고 이전 버전의 파드 템플릿을 사용해 서비스를 원래 상태로 복구한다. 이를 통해 수동 개입을 최소화하면서도 빠른 복구가 가능하다.

롤백을 효과적으로 수행하기 위해서는 이전 버전의 애플리케이션 아티팩트와 구성 정보가 명확히 관리되어야 한다. 또한, 변경 사항에 대한 철저한 버전 관리와 함께, 모니터링 및 알림 시스템을 통해 문제를 조기에 감지하는 것이 선행되어야 한다. 이러한 과정은 블루-그린 배포나 카나리 배포와 같은 다른 배포 전략에서도 핵심적인 요소로 작용하며, 최종적으로는 위험을 최소화하면서도 신속한 배포를 가능하게 하는 CI/CD 파이프라인의 완성도를 높인다.

디플로이먼트는 웹 애플리케이션을 쿠버네티스 환경에 배포하고 관리하는 핵심 객체이다. 웹 서버나 API 서버와 같이 스테이트리스한 특성을 가진 애플리케이션을 배포하는 데 가장 적합하다. 디플로이먼트는 사용자가 정의한 파드 템플릿을 기반으로 레플리카셋을 생성하고, 이를 통해 지정된 수의 동일한 파드 인스턴스를 안정적으로 유지한다. 이는 웹 애플리케이션의 고가용성을 보장하는 기반이 된다.

웹 애플리케이션 배포 시 디플로이먼트의 가장 큰 장점은 손쉬운 업데이트와 롤백 메커니즘을 제공한다는 점이다. 새로운 버전의 컨테이너 이미지로 애플리케이션을 업데이트해야 할 때, 디플로이먼트는 롤링 업데이트 전략을 기본으로 적용한다. 이 전략은 새 파드를 하나씩 생성하고 기존 파드를 순차적으로 제거하는 방식으로, 서비스 중단 없이 배포를 진행할 수 있게 한다. 또한 문제 발생 시 이전 안정적인 버전으로의 롤백이 간단한 명령어로 가능하다.

디플로이먼트를 통한 배포는 애플리케이션의 규모를 유연하게 조정할 수 있게 한다. 트래픽 증가에 대응하기 위해 레플리카 수를 수동으로 조정하거나, Horizontal Pod Autoscaler를 연동하여 CPU나 메모리 사용량 같은 지표를 기준으로 자동 스케일링을 구현할 수 있다. 이렇게 배포된 웹 애플리케이션 파드들은 일반적으로 쿠버네티스 서비스와 연동되어, 단일 진입점을 통해 외부 요청을 분산받게 된다.

이러한 특성으로 인해 디플로이먼트는 마이크로서비스 아키텍처 기반의 현대적 웹 애플리케이션 배포에 사실상의 표준으로 자리 잡았다. 개발팀은 지속적인 통합 및 지속적 배포 파이프라인에 디플로이먼트 매니페스트를 통합함으로써, 테스트 환경부터 프로덕션 환경까지 일관되고 자동화된 방식으로 애플리케이션을 릴리스할 수 있다.

디플로이먼트는 마이크로서비스 아키텍처 환경에서 각각의 독립적인 서비스를 안정적으로 운영하고 관리하는 핵심 도구이다. 마이크로서비스는 하나의 큰 애플리케이션을 여러 개의 작은 서비스로 분해하여 개발하는 방식으로, 각 서비스는 자체적인 라이프사이클을 가지며 독립적으로 배포와 확장이 가능해야 한다. 디플로이먼트는 이러한 각 마이크로서비스의 인스턴스를 선언적으로 정의하고, 원하는 상태를 유지하며, 업데이트와 스케일링을 자동화하는 역할을 담당한다.

마이크로서비스 관리에서 디플로이먼트의 주요 가치는 서비스의 무중단 배포와 복원력을 보장하는 데 있다. 예를 들어, 롤링 업데이트 전략을 통해 디플로이먼트는 새로운 버전의 서비스 컨테이너를 점진적으로 생성하고, 기존 버전의 컨테이너를 하나씩 교체함으로써 서비스의 가용성을 유지한다. 이 과정에서 헬스 체크를 활용하여 새로 배포된 인스턴스가 정상적으로 작동하는지 확인한 후에만 트래픽을 전환한다. 또한, 특정 서비스에 트래픽이 급증할 경우 디플로이먼트의 레플리카 수를 쉽게 증가시켜 수평적 확장을 수행할 수 있다.

여러 마이크로서비스를 조화롭게 운영하기 위해서는 디플로이먼트가 쿠버네티스의 다른 객체들과 협력한다. 각 서비스의 디플로이먼트가 생성한 파드는 일반적으로 서비스(쿠버네티스) 객체를 통해 외부 또는 내부에 노출되어, 안정적인 엔드포인트와 로드 밸런싱 기능을 제공받는다. 또한, 환경 변수나 컨피그맵, 시크릿을 활용하여 서비스별 구성 정보를 안전하게 주입할 수 있다. 이러한 연동을 통해 개발팀은 각 마이크로서비스를 빠르고 독립적으로 반복 배포하는 CI/CD 파이프라인을 구축할 수 있으며, 이는 애자일 및 데브옵스 문화의 실현에 기여한다.

레플리카셋은 쿠버네티스에서 지정된 수의 동일한 파드 복제본이 항상 실행되도록 관리하는 컨트롤러이다. 주된 목적은 파드 집합의 안정적인 복제본 수를 유지하는 것이다. 사용자가 정의한 파드 템플릿과 원하는 레플리카 수를 바탕으로, 레플리카셋은 파드가 너무 적게 실행되면 새로운 파드를 생성하고, 너무 많이 실행되면 초과분을 제거하여 원하는 상태를 유지한다.

레플리카셋은 주로 디플로이먼트와 같은 상위 수준의 추상화 객체를 통해 사용된다. 디플로이먼트는 애플리케이션의 배포와 업데이트 전략을 관리하는 반면, 실제로 파드 복제본을 생성하고 관리하는 작업은 내부의 레플리카셋에 위임된다. 이 구조는 애플리케이션의 롤링 업데이트나 롤백 같은 복잡한 배포 작업을 디플로이먼트가 담당하게 하여, 레플리카셋이 단순히 복제본 수를 유지하는 데 집중할 수 있도록 한다.

레플리카셋은 파드를 선택하기 위해 셀렉터를 사용한다. 셀렉터는 파드에 부여된 레이블을 기준으로 매칭하여 관리 대상 파드를 식별한다. 따라서 레플리카셋의 관리 범위는 특정 레이블을 가진 모든 파드에 적용되며, 파드 템플릿을 통해 생성된 파드뿐만 아니라, 수동으로 생성되었거나 다른 컨트롤러에 의해 생성된 파드라도 동일한 레이블을 가지고 있다면 레플리카셋의 관리 대상이 될 수 있다.

레플리카셋과 유사한 객체로 스테이트풀셋이 있다. 스테이트풀셋은 각 파드에 지속적이고 안정적인 식별자(예: 순서 인덱스)를 부여하여 영구 저장소와의 연결을 보장하는 등, 상태를 가지는 애플리케이션을 배포할 때 사용된다. 반면 레플리카셋은 상태가 없고(stateless), 완전히 교체 가능한 파드 복제본을 관리하는 데 적합하다.

스테이트풀셋은 쿠버네티스에서 상태를 유지해야 하는 애플리케이션을 관리하기 위한 워크로드 API 오브젝트이다. 디플로이먼트가 레플리카셋을 관리하며 무상태 애플리케이션을 배포하는 데 적합한 반면, 스테이트풀셋은 각 파드가 지속적인 스토리지와 안정적인 네트워크 식별자를 필요로 하는 상태 저장 애플리케이션을 배포하고 확장하는 데 사용된다. 데이터베이스, 키-값 스토어, 메시징 시스템과 같이 고유한 데이터와 상태를 가지는 애플리케이션을 운영할 때 필수적이다.

스테이트풀셋의 주요 특징은 각 파드에 안정적이고 고유한 식별자를 부여한다는 점이다. 이 식별자는 파드가 재스케줄링되거나 노드 간에 이동하더라도 변하지 않는다. 파드는 순서대로 생성되고, 확장하며, 삭제되는 예측 가능한 방식을 따른다. 또한, 스테이트풀셋은 퍼시스턴트볼륨클레임을 통해 각 파드에 지속적인 스토리지를 안정적으로 연결할 수 있도록 보장한다. 이를 통해 파드의 수명 주기와 관계없이 데이터가 유지되도록 한다.

스테이트풀셋의 일반적인 사용 사례로는 분산 데이터베이스, 분산 캐시, 메시지 큐 시스템의 배포가 있다. 예를 들어, MySQL 클러스터나 Redis 클러스터, Apache Kafka와 같은 애플리케이션은 각 인스턴스가 고유한 데이터와 역할을 가지므로 스테이트풀셋을 사용하여 배포하는 것이 바람직하다. 이러한 애플리케이션들은 안정적인 네트워크 호스트명과 지속적인 스토리지 볼륨이 필수적이며, 스테이트풀셋은 이를 정확하게 제공한다.

스테이트풀셋은 디플로이먼트나 레플리카셋과 달리 롤링 업데이트를 기본적으로 지원하지 않는다. 대신, 수동으로 파드를 하나씩 업데이트하거나, 온라인 스테이트풀셋 업데이트와 같은 고급 기능을 활용해야 한다. 이는 상태 저장 애플리케이션의 데이터 무결성과 서비스 연속성을 보장하기 위한 설계적 선택이다. 따라서 운영자는 애플리케이션의 특성에 맞게 무상태 워크로드에는 디플로이먼트를, 상태 저장 워크로드에는 스테이트풀셋을 선택하여 사용한다.

서비스는 쿠버네티스에서 파드 집합에 대한 네트워크 접근을 추상화하고 제공하는 핵심 객체이다. 파드는 일시적이며 동적으로 생성되고 소멸하기 때문에, 클라이언트가 특정 파드의 IP 주소를 직접 추적하여 연결하는 것은 불가능하다. 서비스는 이러한 문제를 해결하기 위해, 일정한 도메인 이름과 IP 주소(클러스터 IP)를 부여받고, 해당 서비스의 셀렉터와 일치하는 모든 실행 중인 파드로의 트래픽을 자동으로 로드 밸런싱한다. 이를 통해 애플리케이션의 내부 또는 외부 구성 요소가 파드의 생명주기와 무관하게 안정적으로 서로 통신할 수 있게 한다.

서비스의 주요 유형으로는 클러스터 내부에서만 접근 가능한 ClusterIP, 단일 노드의 포트를 통해 외부에 노출하는 NodePort, 그리고 클라우드 제공자의 로드 밸런서를 자동으로 프로비저닝하여 외부 트래픽을 받는 LoadBalancer가 있다. 또한, 외부 서비스를 쿠버네티스 내부에서 참조하기 위한 ExternalName 타입도 존재한다. 서비스는 레플리카셋이나 디플로이먼트와 같은 컨트롤러와 함께 사용되어, 애플리케이션의 마이크로서비스 구성 요소 간의 안정적인 네트워킹을 뒷받침한다.

서비스의 동작 방식은 기본적으로 쿠버네티스 API 서버와 kube-proxy 컴포넌트에 의해 구현된다. 서비스가 생성되면, 각 노드에서 실행 중인 kube-proxy는 해당 서비스의 엔드포인트(실제 파드 IP와 포트 목록)를 감시하고, iptables나 IPVS 규칙을 설정하여 서비스의 가상 IP로 들어오는 요청을 적절한 백엔드 파드로 전달한다. 이 과정은 완전히 자동화되어 있어, 사용자는 서비스의 논리적 이름을 통해 애플리케이션에 접근하기만 하면 된다.