Kubernetes Probe & ArgoCD

이종경·2025년 5월 16일
Infrak8s
0

Pod의 생명주기

Pod 생명주기

쿠버네티스에서 가장 기본적인 관리 단위가 Pod입니다. Pod는 하나 이상의 컨테이너 그룹을 포함하며, 컨테이너의 실행 상태를 단계별로 관리합니다. 주요 단계는 다음과 같습니다.

PhaseDescription
PendingPod Lifecycle 의 첫 시작 단계

Pod 가 Node 에 할당되었지만 아직 Container 설정이 진행되고 있거나 실행 준비가 되지 않은 상태

  • Node 를 사용할 수 없는 상태
  • Container 를 생성하기 위한 자원이 부족한 상태
  • Container Image 를 아직 가져오지 못한 상태 |
    | Running | Pod Container 가 생성되었고 1개 이상의 Container 가 실행중이거나 시작, 재시작 상태 |
    | Succeeded | Pod 내부의 모든 Container 가 성공적으로 종료된 상태 |
    | Failed | Pod 내부 모든 Container 가 종료되었고, 적어도 1개 이상의 Container 가 실패로 종료된 상태 |
    | Unknown | 어떤 이유에 의해서 Pod 의 상태를 얻을 수 없는 상태
    일반적으로 파드와 노드간의 통신 오류 |

Probe 매커니즘

쿠버네티스에서는 컨테이너의 상태를 주기적으로 점검(Health Check)하여 애플리케이션의 가용성을 높입니다. 이것을 Probe라고 합니다. Probe는 컨테이너가 정상 작동하는지를 주기적으로 확인하여 문제가 발생하면 재시작 등의 조치를 자동으로 수행합니다.

Probe 방식

  • exec: 컨테이너 내부에서 특정 명령어를 실행하여 상태 확인
  • grpc: gRPC 프로토콜로 상태를 확인 (일반적으로 전문적인 서비스에 사용)
  • httpGet: HTTP 요청을 보내 상태를 확인 (가장 흔히 사용됨)
  • tcpSocket: TCP 포트를 통해 서비스가 열려있는지 확인

Probe 종류

livenessProbe

  • 컨테이너가 살아있는지를 주기적으로 점검합니다.
  • 실패 시, 컨테이너를 재시작하여 자동으로 복구합니다.

livenessProbe 생성

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3 # 첫 번째 프로브를 수행하기 전 3초 대기
      periodSeconds: 3 # kubelet이 3초마다 LivenessProbe를 실행

위 pod를 배포하면 아래와 같이 실패할 경우 재시작되는 것을 확인할 수 있다.

pod 실행 상태 1

pod 실행 상태 2

readinessProbe

  • 서비스 트래픽을 받을 준비가 되었는지를 점검합니다.
  • 실패하면 서비스로부터 컨테이너를 재기동하지 않습니다.

readliness Probe 생성

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness-http
spec:
  containers:
  - name: readiness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

위 pod를 배포하면 아래와 같이 확인할 수 있다. liveness probe와 달리 컨테이너를 재기동하지 않으며 트래픽을 차단한다.

readiness probe1

readiness probe2

startupProbe

startup probe

  • 컨테이너 내의 애플리케이션이 시작되었는지 여부
  • 스타트업 프로브 (startup probe) 가 주어진 경우, 성공할 때까지 다른 나머지 프로브는 활성화되지 않는다.
  • 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다.
  • 컨테이너에 스타트업 프로브가 없는 경우, 기본 상태는 Success

Manifest 관리

쿠버네티스에서 리소스를 생성하거나 변경하기 위해 사용하는 YAML 파일을 Manifest라고 합니다. Manifest는 관리가 복잡할 수 있어서, 다양한 도구를 통해 효율적으로 관리합니다.

Manifest 관리의 필요성

  • 리소스 정의 및 관리의 용이성
  • 배포 환경의 일관성 유지
  • 리소스 변경 이력 관리

Kustomize

kustomize

  • 쿠버네티스 리소스를 템플릿 없이 YAML 파일을 직접 패치하거나 병합하여 관리하는 도구입니다.
  • 여러 환경(dev, staging, prod)에 따른 리소스 설정을 쉽게 관리할 수 있습니다.

디렉토리 구조

  • Base
    • Kustomize 를 통해 변경할 yaml 파일이 저장된 디렉토리
    • 재사용이 가능한 yaml 로 구성
      • deployment.yaml, service.yaml 같은 공통 파일
    • Terraform - Module / Helm - Helm Chart 와 유사
  • Overlay
    • Base 에 저장된 yaml 파일에 적용할 kustomization.yaml 이 저장된 디렉토리
    • 환경별 차이점 정의 (dev, stg, prd)
      • overlays/dev, overlays/stg, overlays/prd
  • kustomization.yaml
    • kustomize 가 실행될 때 어떤 필드를 재정의 할 것인가를 설정하는 파일
    • resource, patches, namePrefix, ConfigMapGenerator 등 다양한 설정

Kustomize 실행

# kustomize 설치
brew install kustomize
  1. kustomize.yaml 생성
resources:
  - pod.yaml

images:
  - name: nginx
    newName: new-nginx
    newTag: 1.23.1
  1. pod.yaml 생성
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: nginx
  name: nginx
spec:
  containers:
  - image: nginx:latest
    name: nginx
    resources:
      limits:
        cpu: 100m
        memory: 64Mi
  1. kustomize 실행
kubectl kustomize <PATH>

위 명령어를 실행하면 기존의 pod를 수정하지 않고 필드만 재정의된 것을 확인할 수 있다.

kustomize 배포

Helm

helm

쿠버네티스의 패키지 매니저 역할을 하며, Manifest 파일을 쉽게 관리하고 배포할 수 있도록 도와줍니다.

Hem 구조

helm 구조

  • Chart: Helm의 패키지 단위로, 리소스 정의를 포함합니다.
  • Repository: Helm Chart를 저장하고 관리하는 공간입니다.
  • Release: 특정 Chart를 클러스터에 배포한 상태를 나타냅니다.
  • Values: Chart에서 동적으로 설정 가능한 변수입니다. 파일구조

Helm 기본 명령어

# helm 생성
helm create myChart

# helm install <RELEASE_NAME> <패키지 경로> [flags]
helm install myapp .

# Helm Release 확인
helm list

# Helm 삭제
helm delete myapp

GitOps

GitOps

GitOps는 Git 저장소를 이용해 인프라 및 애플리케이션 배포를 자동화하는 방식을 말합니다.

핵심 개념

  • 선언적(Declarative) 정의: 모든 배포 상태가 Git에 저장된 코드로 선언됩니다.
  • 버전 관리: Git을 통해 모든 변경사항을 추적하며, Rollback도 간편합니다.
  • 자동 동기화: 클러스터의 상태를 Git의 상태와 일치하게 유지합니다.

ArgoCD

ArgoCD

쿠버네티스를 위한 대표적인 GitOps 도구 중 하나로, 지속적 배포(Continuous Delivery)를 수행합니다. Git 저장소의 변경을 모니터링하고, 선언된 상태를 클러스터에 자동으로 적용합니다.

  • 선언적 접근 방식(Declarative approach) 클러스터의 모든 상태를 Git 저장소에 명시적으로 선언된 코드로 관리합니다.
  • Git 중심의 버전 관리(Git-centric version management) 모든 변경 사항은 Git을 통해 관리되며, 코드 리뷰, 추적 및 롤백을 간편하게 수행할 수 있습니다.

ArgoCD 핵심 개념

  1. 선언적 관리 (Declarative Management)
    • 원하는 애플리케이션 상태를 Git에 선언적으로 정의하여 유지 관리합니다.
    • 개발자는 인프라가 아닌 애플리케이션 코드에 더 집중할 수 있습니다.
  2. 자동 동기화 (Automated Synchronization)
    • Git 저장소와 쿠버네티스 클러스터의 상태를 지속적으로 비교하여 자동 동기화합니다.
    • 클러스터 상태가 Git의 선언적 상태에서 벗어나면 이를 자동으로 정정합니다.
  3. 즉각적인 Rollback 및 Rollout
    • Git에 커밋한 내용을 기준으로 배포 상태를 쉽게 되돌릴 수 있습니다.
    • 버전 변경 이력이 명확하여 문제 발생 시 빠르게 이전 상태로 돌아갈 수 있습니다.
  4. 셀프 힐링(Self-Healing)
    • 클러스터 상태가 선언된 Git 상태와 다를 경우 자동으로 상태를 원상 복구합니다.
    • 의도하지 않은 수동 변경 또는 오류가 발생했을 때, 자동으로 수정 가능합니다.

ArgoCD 아키텍처

ArgoCD 아키텍처

구성 요소역할
API Server웹 UI, CLI, API를 통해 사용자와 상호작용하는 인터페이스 제공
Repository ServerGit 저장소로부터 Manifest(YAML 파일 등)를 가져와 처리
Application Controller클러스터의 상태와 Git 저장소의 상태를 비교하여 배포를 수행
Redis캐싱과 세션 상태 관리를 위한 저장소

각 구성 요소는 다음과 같은 방식으로 상호작용합니다.

  1. 사용자가 Git 저장소에 리소스를 선언적으로 정의합니다.
  2. ArgoCD의 Repository Server는 Git 저장소에서 이 변경사항(Manifest)을 가져옵니다.
  3. Application Controller는 Git 상태와 실제 쿠버네티스 클러스터 상태를 비교하여 배포 또는 상태 변경 작업을 수행합니다.
  4. 상태 정보는 Redis에서 빠르게 캐싱되어 성능을 높입니다.
  5. 사용자는 API Server를 통해 UI 및 CLI에서 배포 상태를 실시간으로 확인 가능합니다.

ArgoCD 설치 및 접속

# ArgoCD Namespace 생성
kubectl create ns argocd

# Helm Repo 등록
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

helm install argocd argo/argo-cd --set server.service.type=NodePort --namespace argocd

# ArgoCD 서비스 접근을 위한 노드포트 변경
kubectl patch svc argocd-server -n argocd \
  -p '{"spec": {"ports": [{"port": 443, "targetPort": 8080, "nodePort": 31001}]}}'
  
# 리소스 확인
kubectl get all -n argocd

# 초기 비밀번호 확인
kubectl patch svc argocd-server -n argocd \
  -p '{"spec": {"ports": [{"port": 443, "targetPort": 8080, "nodePort": 31001}]}}'

ArgoCD Best Practice

  • GitOps의 핵심은 Git 저장소를 Single Source of Truth로 사용하는 것입니다.
  • 선언적 정의를 통해 모든 환경(dev, staging, production)을 통일된 방식으로 관리하는 것이 중요합니다.
  • 모든 배포 변경사항을 Git을 통해 관리하여 추적성, 감사성, 그리고 롤백 가능성을 극대화합니다.
  • ArgoCD의 자동 동기화 기능을 활성화하여 배포의 안정성을 높이는 것이 추천됩니다.
profile
이종경
작은 성취들이 모여 큰 결과를 만든다고 믿으며, 꾸준함을 바탕으로 개발 역량을 키워가고 있습니다
이전 포스트

Backend For Frontend (a.k.a. BFF)

다음 포스트

실행 컨텍스트란?

0개의 댓글