sseyeon.log

[쿠버네티스 어나더 클래스 - Sprint2] #4. Jenkins Pipeline (기초부터 Blue/Green 까지)

@sseyeon_ — Mon, 21 Sep 2026 18:20:25 +0900

[참고]
본 글은 인프런의
<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>
강의 내용과 실습을 바탕으로 정리한 기록입니다.

실습에서 다룬 Job (Pipeline)

2211-jenkins_pipeline-step1: 분리되어 있던 세 개의 Job을 하나의 Pipeline으로 통합
2212-jenkins_pipeline-step2: GitHub 연동 및 Pipeline script from SCM 방식으로 전환
2213-jenkins_pipeline-step3: input 스텝을 활용한 수동 Blue/Green 배포
2214: 배포 완료 여부를 폴링하는 자동 Blue/Green 배포

1. 분리된 Job을 하나의 Pipeline으로

Sprint 1에서는 2121-source-build, 2121-container-build, 2121-deploy 세 개의 Job을 각각의 stage로 나눠 관리했습니다.

이번 단계에서는 이 Job들을 하나의 Pipeline으로 합치는 작업을 수행했습니다. 실무에서 매일 하던 구성이라 이 부분은 빠르게 넘어갔습니다.

2. Pipeline script from SCM으로 전환

Jenkins UI에 스크립트를 직접 박아 넣는 대신, GitHub 저장소의 Jenkinsfile을 읽어오도록 변경했습니다.
설정 포인트 3가지

Definition: Pipeline script from SCM 선택 (SCM은 Git)
Repository URL: https://github.com/sseyeon/kubernetes-anotherclass-sprint2.git, Branch는 /main
Sparse Checkout paths: Additional Behaviours에서 체크아웃 경로를 2212로 지정

✅ Sparse Checkout을 쓰는 이유: 하나의 저장소에 여러 실습 번호(2211, 2212, 2213…)가 함께 들어 있을 때, 전체를 내려받지 않고 해당 Job이 필요로 하는 디렉토리만 체크아웃할 수 있습니다. 저장소가 커질수록 체크아웃 시간과 워크스페이스 용량에서 차이가 납니다.

3. Blue/Green 배포 실습 (수동)

input 스텝으로 각 단계마다 확인을 받으면서 트래픽이 어떻게 넘어가는지 직접 관찰했습니다.

3-1. Blue 배포 — Green Pod 생성

첫 번째 Yes를 누르면 기존 Blue Pod 2개는 그대로 둔 채, Green Pod 2개가 추가로 생성됩니다. 이 시점에는 Pod가 총 4개입니다.

# 운영 트래픽 — 계속 v1.0.0 응답
while true; do curl http://192.168.56.30:32213/version; sleep 1; echo ''; done;
# [App Version] : Api Tester v1.0.0
# [App Version] : Api Tester v1.0.0

# QA 담당자 전용 — 검증용 Service로 v2.0.0 직접 호출
curl http://192.168.56.30:32223/version
# [App Version] : Api Tester v2.0.0

✅ 핵심: 사용자는 여전히 v1을 보고 있는 상태에서, QA는 별도 포트(32223)로 v2를 미리 검증할 수 있습니다.

3-2. Green 전환

두 번째 Yes를 누르면 Service의 selector가 바뀌면서, 돌고 있던 32213 호출 결과가 v1에서 v2로 전환됩니다.

3-3. Blue 삭제

마지막으로 Done을 누르면 Blue Pod가 삭제되고 Green만 남습니다.

4. Blue/Green 배포 시 고려해야 할 요소

Sprint 1에서 라벨(Label)과 셀렉터(Selector) 매칭 구조를 정리했는데, Blue/Green은 그 설계가 실제로 왜 중요한지 바로 드러나는 지점이었습니다.

1) Blue-Green 배포를 고려한 Deployment 네이밍
Deployment 이름 뒤에 구분자를 붙입니다. api-tester-2213-1(Blue), api-tester-2213-2(Green) 형태로, 두 벌의 Deployment가 동시에 존재할 수 있어야 합니다.

2) Blue-Green 배포를 위한 추가 레이블 및 셀렉터
기존 5개 라벨(part-of, component, name, instance, version)에 blue-green-no 라벨을 하나 더 추가합니다.

구분	Deployment	Pod label	Service selector
Blue	api-tester-2213-1	blue-green-no: 1, version: 1.0.0	blue-green-no: "1"
Green	api-tester-2213-2	blue-green-no: 2, version: 2.0.0	blue-green-no: "2"

✅ 여기서 중요한 점: Service는 part-of, component, name, instance까지는 Blue/Green이 완전히 동일하고, 오직 blue-green-no 값 하나만 다릅니다. 그래서 이 라벨 값 하나만 1 → 2로 바꾸면 트래픽 전체가 넘어갑니다.

5. 리소스 변경 사항 정리

수동 배포 전체 흐름을 리소스 관점에서 3단계로 정리하면 다음과 같습니다.

생성: Green Deployment 생성 + 검증 전용 Service(api-tester-2) 생성
전환: 운영 Service의 selector blue-green-no를 "1" → "2"로 변경
정리: Blue Deployment 삭제, Green 전용 Service 삭제, 그리고 남은 리소스들의 version 라벨을 1.0.0 → 2.0.0으로 갱신

3번에서 문제가 드러납니다. Deployment만 정리하면 끝이 아니라 Service, ConfigMap, Secret에 붙은 version 라벨까지 전부 따라가야 합니다. 리소스가 늘어날수록 하나씩 누락될 위험이 커지고, 이걸 사람 손으로 챙기는 건 현실적이지 않습니다. Helm을 쓰는 이유가 여기서 나옵니다.
참고로 instance 라벨은 Blue/Green 간에 다르게 주는 경우가 많지는 않습니다.

6. 자동 배포 만들어보기

수동 단계의 input을 걷어내고, Green Pod가 전부 Ready가 될 때까지 폴링하도록 만들었습니다.

stage('쿠버네티스 Green배포') {
    steps {
        sh "kubectl apply -f ./${CLASS_NUM}/deploy/k8s/green/deployment.yaml"
    }
}

stage('Green 배포 확인중') {
    steps {
        script {
            def returnValue
            // Pod 2개가 모두 Ready("true true")가 될 때까지 5초 간격으로 확인
            while (returnValue != "true true") {
                returnValue = sh(returnStdout: true, encoding: 'UTF-8',
                    script: "kubectl get -n anotherclass-221 pods -l instance='api-tester-2214',blue-green-no='2' -o jsonpath='{.items[*].status.containerStatuses[*].ready}'")
                echo "${returnValue}"
                sleep 5
            }
        }
    }
}

stage('Green 전환 완료') {
    steps {
        // 라벨 하나만 바꿔서 트래픽 전환
        sh "kubectl patch -n anotherclass-221 svc api-tester-2214 -p '{\"spec\": {\"selector\": {\"blue-green-no\":\"2\"}}}'"
    }
}

stage('Blue 삭제') {
    steps {
        sh "kubectl delete -f ./${CLASS_NUM}/deploy/k8s/blue/deployment.yaml"
        // 남은 리소스들의 version 라벨 갱신
        sh "kubectl patch -n anotherclass-221 svc api-tester-2214 -p '{\"metadata\": {\"labels\": {\"version\":\"2.0.0\"}}}'"
        sh "kubectl patch -n anotherclass-221 cm api-tester-2214-properties -p '{\"metadata\": {\"labels\": {\"version\":\"2.0.0\"}}}'"
        sh "kubectl patch -n anotherclass-221 secret api-tester-2214-postgresql -p '{\"metadata\": {\"labels\": {\"version\":\"2.0.0\"}}}'"
    }
}

✅ 코드에서 읽어야 할 포인트

while 문이 핵심: jsonpath로 Pod의 containerStatuses[*].ready를 뽑아 "true true"가 될 때까지 대기합니다. Pod가 2개니까 true도 2개여야 합니다.
전환은 kubectl patch 한 줄: Service의 selector.blue-green-no만 바꾸면 끝입니다. 4번 항목의 라벨 설계가 그대로 코드에 반영된 모습입니다.
뒷정리 patch가 3줄: Service, ConfigMap, Secret의 version 라벨을 각각 수동으로 갱신하고 있습니다. 5번에서 말한 누락 위험이 코드에서 그대로 보입니다.

다만 이건 실무용이 아닙니다. while로 무한 대기하는 구조라 타임아웃도 없고, 실패 시 롤백 처리도 없습니다. Blue/Green이 원리적으로 이렇게 돌아간다는 것을 보여주는 코드에 가깝습니다.
그럼 실무에서는? → ArgoCD 같은 GitOps 툴을 활용합니다.

마무리

Sprint 1에서 라벨과 셀렉터 매칭 구조를 다이어그램으로 그려봤을 때는 “규칙을 잘 지키면 관리가 편해지겠구나” 정도의 감이었는데, Blue/Green을 직접 만들어보니 그 효용이 훨씬 구체적으로 와닿았습니다. 라벨 설계가 잘 되어 있으면 무중단 전환이 patch 한 줄로 끝나고, 안 되어 있으면 배포 때마다 리소스를 손으로 뒤져야 합니다.
동시에 왜 Helm과 ArgoCD가 필요한지도 자연스럽게 이해됐습니다. Jenkinsfile에 kubectl patch를 세 줄 쌓고 있는 순간, 이건 리소스가 늘어나면 관리가 안 되는 방식이라는 게 코드 자체로 드러났기 때문입니다.

[쿠버네티스 어나더 클래스 - Sprint2] #3. 배포를 시작하기 전에 반드시 알아야 할 것들

@sseyeon_ — Fri, 18 Sep 2026 16:22:23 +0900

[참고]

본 글은 인프런의

<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>

강의 내용과 실습을 바탕으로 정리한 기록입니다.

성공적인 데브옵스 환경 구축을 위해 CI/CD 파이프라인 설계 시 고려해야 할 구조적 요소와 상황에 맞는 쿠버네티스 배포 전략(Recreate, RollingUpdate, Blue/Green, Canary)을 정리합니다.

1. CI/CD 파이프라인 구성 시 고려 요소

CI/CD 환경과 실제 애플리케이션이 동작하는 인프라 환경은 명확히 구분되어 관리됩니다.

출처: 인프런 - [지상편] 배포를 시작하기 전에 반드시 알아야 할 것들

[관리 담당 및 파이프라인 분리]

이전 실습에서는 Jenkins를 통해 (1) 소스 빌드 ➔ (2) 컨테이너 빌드 ➔ (3) 배포(kubectl) 과정을 하나의 파이프라인에 통합해 구성하였습니다.
배포 방식은 단순 kubectl 외에도 Helm이나 Kustomize를 활용해 매니페스트를 효율적으로 관리할 수 있습니다.
실무에서는 업무 분장 및 관리 책임에 따라 빌드 단계(1~2)와 배포 단계(3)를 분리하여 운영하기도 합니다.

[운영 정책 및 ArgoCD 구축 구조]

소스/컨테이너 빌드(1~2)는 Jenkins가 담당하고, 쿠버네티스 배포(3)는 GitOps 도구인 ArgoCD가 전담하는 구조를 흔히 활용합니다.
1 : N 구조: 1개의 ArgoCD가 여러 인프라 환경(Dev, Stage, Prod)을 통합 관리
1 : 1 구조 (권장): 각 인프라 환경마다 별도의 ArgoCD를 1:1로 각각 구축
- 특징: 이중 관리의 번거로움은 있지만, 특정 환경의 장애가 타 환경으로 전파되지 않아 안전성이 높아 실무에서 더 선호되는 방식입니다.

2. 배포 전략(Deployment Strategy) 비교 및 고려 요소

출처: 인프런 - [지상편] 배포를 시작하기 전에 반드시 알아야 할 것들

상황과 요구조건(무중단 여부, 트래픽 제어 필요성, DB 스키마 변경 여부 등)에 따라 최적의 배포 전략을 선택해야 합니다.

배포 전략	배포 및 업데이트 메커니즘	주요 특징	유즈케이스 / 비고
Recreate	기존 Pod를 모두 삭제한 후 신규 v2 Pod 생성	• Downtime(서비스 중단) 발생 • 자동 배포 및 정지/롤백 가능 • 트래픽 제어 불가	DB 스키마 변경 등으로 신·구 버전 동시 실행이 불가능한 경우
RollingUpdate	v1이 동작하는 상태에서 v2 Pod를 순차적으로 생성 후 v1 교체	• 서비스 중단 없음 (무중단) • 배포 중 v1, v2 Pod 동시 호출 발생 • 자동 배포 및 정지/롤백 가능	일반적인 애플리케이션 무중단 배포
Blue/Green (ArgoCD)	v2 Deployment를 별도 생성 후, Service의 Selector를 v1 ➔ v2로 일괄 변경 (이후 v1 삭제)	• 기존 L4 레벨 배포 방식을 K8s로 구현 • 빠른 롤백 가능 (수동/스크립트 제어) • v2 전환 순간 과도한 트래픽 유입 주의	운영 환경에서만 직접 테스트가 필요한 경우
Canary (ArgoCD)	v2 Deployment/Service/Ingress를 별도 생성하여 Ingress에서 트래픽 비율 조절 (예: v1 90% : v2 10%)	• 트래픽 가중치 제어 가능 • 콜드 스타트 방지 및 두 버전 성능 비교 가능 • 배포 완료 후 v1 리소스 삭제	A/B 테스트 및 단계적 리스크 최소화 배포

A/B 테스트와 Canary의 차이

Canary: 신규 버전 배포 시 리스크를 줄이기 위해 트래픽 비율을 단계적으로 늘려가는 배포 전략입니다.
A/B 테스트: Canary 배포 환경을 활용하여 특정 조건(Source IP, User 계정, Language 등 특정 헤더 값)에 맞춰 v2로 트래픽을 유입시켜 사용자 반응을 비교·검증하는 테스트 방법론입니다.

✍️ 요약 및 회고

파이프라인 구성 시에는 관리 주체와 환경 분리(ArgoCD 1:1)를 우선적으로 고려해야 하며,

배포 전략 수립 시에는 트래픽 제어 필요성과 신·구 버전 동시 호출 문제(DB 영향) 를 기준으로

Recreate, RollingUpdate, Blue/Green, Canary 중 적절한 방식을 채택하는 것이 핵심입니다.

[쿠버네티스 어나더 클래스 - Sprint2] #2. 손쉽게 데브옵스 환경을 구축하는 방법

@sseyeon_ — Thu, 17 Sep 2026 17:24:12 +0900

[참고]

본 글은 인프런의

<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>

강의 내용과 실습을 바탕으로 정리한 기록입니다.

CI/CD 서버 사전 설정(Jenkins, Docker 로그인, GitHub Fork 등)을 마친 후, CI/CD 서버에서 쿠버네티스 클러스터를 제어할 수 있도록 인증서를 연동하고 파이프라인 배포 과제를 해결한 과정을 정리합니다.

1. CI/CD 서버와 Master Node 인증서 연동 (SCP)

Jenkins 서버에서 kubectl 명령어로 쿠버네티스 클러스터를 제어하기 위해 Master Node의 인증서 파일(/root/.kube/config)을 가져옵니다.

사전 체크사항:
- Master Node가 정상 동작 중인지 확인
- 반드시 root 계정이 아닌 jenkins 유저 권한으로 작업 진행

# 1. config 파일 저장 디렉토리 생성
[jenkins@cicd-server ~]$ mkdir ~/.kube

# 2. Master Node에서 인증서 복사 (SCP)
[jenkins@cicd-server ~]$ scp root@192.168.56.30:/root/.kube/config ~/.kube/
# 실행 후 fingerprint [yes] 입력 및 Master Node 비밀번호 입력

✅ 확인 결과

️ 연동 결과 검증

# Jenkins 유저 상태에서 클러스터 파드 목록 조회 확인
[jenkins@cicd-server ~]$ kubectl get pods -A

kubectl get pods -A 실행 시 전체 네임스페이스의 파드 목록이 정상 출력되면 CI/CD 서버에서의 클러스터 접근 권한 설정이 완료됩니다.

✅ 확인 결과

2. Jenkins 파이프라인 생성

배포 자동화를 위해 Jenkins에 다음 3가지 빌드/배포 파이프라인 아이템을 생성하였습니다.

2121-source-build: 소스 코드 검증 및 애플리케이션 빌드
2121-container-build: 빌드된 아티팩트를 기반으로 Docker 이미지 생성 및 레지스트리 푸시
2121-deploy: 쿠버네티스 클러스터에 매니페스트(YAML) 적용 및 배포

3. 배포 트러블슈팅: Pod Pending/Error 원인 및 해결

파이프라인 실행 후 배포된 Pod가 Running 상태로 전환되지 않고 오류가 발생하는 이슈가 있었습니다.

원인 분석:
- 배포 매니페스트에 정의된 pv.yaml 스토리지 설정 확인
- PV가 Master Node의 특정 로컬 디렉토리( path: "/root/k8s-local-volume/2121")를 참조하도록 작성되어 있으나, 실제 Master Node 상에 해당 디렉토리 패스가 존재하지 않아 PVC 바인딩 및 파드 생성 실패

해결 조치:
- Master Node에 접속하여 PV가 참조하는 디렉토리를 수동 생성

# Master Node 접속 후 볼륨 마운트 경로 생성
[root@k8s-master ~]$ mkdir -p /root/k8s-local-volume/2121

✅ 최종 정상 동작 확인

디렉토리 생성 후 PV/PVC가 정상적으로 바인딩(Bound)되었으며, 2121-deploy 파이프라인 재시동 시 파드가 정상적으로 Running 상태로 올라오는 것을 확인했습니다.

✍️ 요약 및 회고

CI/CD 서버에서 K8s를 제어하기 위한 핵심은 인증서(config) 권한 전달에 있으며, 로컬 볼륨(PV)을 사용하는 배포 환경에서는 실제 노드의 물리 패스 존재 여부를 사전에 체크하는 것이 트러블슈팅의 핵심 포인트였습니다.

2026 CKA 합격 후기

@sseyeon_ — Mon, 14 Sep 2026 14:32:50 +0900

안녕하세요 ㅎㅎ

미루고 미루다 드디어 CKA 시험을 보게 되었고, 합격하게 되어 후기 남깁니다.

1. 베이스

우선 저는 개발 경력 5년이지만, 실무에서는 쿠버네티스는 사용하지 않아

쿠버네티스 지식은 0 인 상태입니다 . (레거시 시스템이라 도커도 잘 안써요 ㅠ)

처음에는 Udemy 뭄샤드 유명한 강의가 있어, 구매 후 수강하였는데
가뜩이나 모르는 내용인데 한글자막이 없으니 이해가 하나도 안되더라구요.

그러던 중에, 어떤 블로그 후기에서 일프로님 CKA 인프런 강의를 접하게 되어 바로 수강 시작했습니다.
https://www.inflearn.com/course/certified-kubernetes?cid=339687

물론 뭄샤드 보다는 이해가 잘 되었지만,
CKA 강의를 2번을 돌려 들어도, 베이스가 제로인 상태라 머릿속엔 물음표만 남더라구요.

하지만 설명이 일목요연하고, 설명하시는 스타일도 여타 강의들과는 다르게 계속 듣게 되어서
에잇 이왕 공부하는거 확실히 이해하고 듣자 !! 하구 Sprint 1.2 강의도 구매하였습니다.

결론적으론 아주 잘 한 선택이었구요 ~~!

2. 시험 후기

빠른시일내에 자격증 취득하고 싶어서 Sprint 1 까지만 듣고
CKA 문제풀이를 시작했습니다.

여기서 가장 중요한 건 ‘직접 손으로 쳐보며 익숙해지는 것’이었어요.

개념만 외우려고 하면 금방 잊어버리기 때문에, 강의에 나오는 실습 환경과 문제들을 완전히 제 것으로 만들 수 있을 때까지 손에 익히는 연습을 꾸준히 했습니다.

그리고 카페에 올라오는 최신 업데이트 유형이나 팁들도 놓치지 않고 꼼꼼히 체크했어요!

시험장 입장 직전까지도 모르는거 나오면 어쩌지
하며 내내 떨었는데 문제 보자마자 안심했습니다.

손에 익을 정도로 실습 연습을 해둔 덕분에 당황하지 않고 차근차근 풀어나갈 수 있었습니다.

3. 마치며

공부하면서 막막할 때도 많았는데, 일프로님 강의 덕분에 노베이스 상태에서도 차근차근 개념을 잡고 합격까지 올 수 있었던 것 같아요.

이제 남은 Sprint 2와 추가로 구매한 Sprint 3까지 열심히 달려서 완강할 생각입니다!

이 글을 보시는 모든 분들 합격하세요 ~~

[쿠버네티스 어나더 클래스 - Sprint1] #8. Component 동작으로 이해하기

@sseyeon_ — Thu, 27 Aug 2026 13:41:03 +0900

[참고]
본 글은 인프런의
<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>
강의 내용과 실습을 바탕으로 정리한 기록입니다.

주요 컴포넌트 구성

출처: [지상편] 쿠버네티스 첫 오브젝트 잘 끼우기 > Component 동작으로 이해하기 > 주요 컴포넌트 구성

1. Resource 계층 (논리적 리소스 및 스토리지)

Cluster level & Namespace level: 클러스터 전체에 적용되는 Namespace, PV와 그 하위에서 격리되어 관리되는 리소스들로 구분됩니다.
Controller: HPA ➔ Deployment ➔ ReplicaSet으로 이어지며 타 컨트롤러나 오브젝트를 상태 정의에 맞게 제어합니다.
Object: Service, ConfigMap, Secret 등이 Pod와 연결되어 단독 인프라 기능을 수행하며, 데이터 보존을 위해 Pod ➔ PVC ➔ PV ➔ 외부 볼륨 솔루션(NFS, Ceph, AWS EBS 등)으로 이어집니다.

2. Kubernetes Cluster 계층 (클러스터 내부 컴포넌트)

Control Plane Component:
- kube-apiserver: 중앙에서 모든 API 요청을 수신하고 통신을 중계합니다.
- etcd: 클러스터의 모든 상태 정보(Database)를 안전하게 저장합니다.
- kube-controller-manager & kube-scheduler: 파드의 스케줄링 및 컨트롤러 상태를 관리합니다.
Worker Component & Addon Pod:
- 노드 네트워킹을 위한 kube-proxy와 실제 사용자의 User App Pod가 동작합니다.
- 클러스터 기능을 확장하는 metrics-server, coredns, calico, kube-dashboard 등이 Addon 파드로 설치됩니다.

3. VM 계층 (물리/가상 노드 및 실행 도구)

Master Node:
- kubectl: 인증서(/root/.kube/config)를 사용해 kube-apiserver로 명령을 전달합니다.
- kubeadm: 정적 파드 Manifests(/etc/kubernetes/manifests)를 통해 컨트롤 플레인을 구축합니다.
- kubelet: kube-apiserver의 요청을 받아 컨테이너 런타임(containerd)에 실제 컨테이너 생성을 명령합니다.
Worker Node: kubeadm join을 통해 클러스터에 참여하며 kubelet과 containerd가 실행되어 파드를 띄웁니다.

Resource 확인

$ kubectl api-resources

✅ 확인 결과

Cluster 주요 컴포넌트 로그 확인

// 주요 컴포넌트 로그 보기 (kube-system)
$ kubectl get pods -n kube-system
$ kubectl logs -n kube-system etcd-k8s-master
$ kubectl logs -n kube-system kube-scheduler-k8s-master
$ kubectl logs -n kube-system kube-apiserver-k8s-master

✅ 확인 결과

Master Node 파일 위치

// 쿠버네티스 인증서 위치
$ cd /etc/kubernetes
$ ls /root/.kube/config

// Control Plane Component Pod 생성 yaml 파일 위치
$ ls /etc/kubernetes/manifests

// 전체 Pod 로그
/var/log/pods/<namespace_<pod-name>_<uid>/<number>.log
/var/log/containers/<pod-name>_<namespace>_<container-name>_<container-id>.log

✅ 확인 결과

트러블 슈팅

// kubelet 상태 확인
1) systemctl status kubelet       // systemctl (restart or start) kubelet
2) journalctl -u kubelet | tail -10

// 상태 확인 -> 상세 로그 확인 -> 10분 구글링 -> VM 재기동 -> Cluster 재설치 ->  답을 찾을 때 까지 구글링

// containerd 상태 확인
1) systemctl status containerd
2) journalctl -u containerd | tail -10

// 노드 상태 확인
1) kubectl get nodes -o wide
2) kubectl describe node k8s-master

// Pod 상태 확인
1) kubectl get pods -A -o wide
// Event 확인 (기본값: 1h)
2-1) kubectl get events -A
2-2) kubectl events -n anotherclass-123 --types=Warning  (or Normal)
// Log 확인
3-1) kubectl logs -n anotherclass-123 <pod-name> --tail 10    // 10줄 만 조회하기
3-2) kubectl logs -n anotherclass-123 <pod-name> -f           // 실시간으로 조회 걸어 놓기
3-3) kubectl logs -n anotherclass-123 <pod-name> --since=1m   // 1분 이내에 생성된 로그만 보기

Pod 생성 및 probe 동작

출처: [지상편] 쿠버네티스 첫 오브젝트 잘 끼우기 > Component 동작으로 이해하기 > Pod 생성 및 probe 동작

쿠버네티스에서 사용자가 배포 명령을 내렸을 때, 컨트롤 플레인 내부에서 Pod가 생성되는 메커니즘과 노드 단에서 Probe 검사가 수행되는 전체 흐름을 보여주는 다이어그램입니다.

1. Resource 계층 (배포 관련 오브젝트 및 속성)

Deployment & ReplicaSet: Deployment 정의에 따라 ReplicaSet이 생성되고, 이는 지정된 개수만큼의 Pod를 관리합니다.
Pod 핵심 설정 속성:
- nodeSelector: 특정 노드(예: Master Node 등)를 지정하여 Pod가 배포될 위치를 결정합니다.
- resources: CPU, Memory의 requests 및 limits 자원 사용량을 설정합니다.
- probe: 컨테이너의 상태 체크(Startup, Readiness, Liveness) 메커니즘을 정의합니다.

2. Control Plane 계층 (Pod 생성 워크플로우)

요청 수신: kubectl 명령을 통해 kube-apiserver로 Deployment 생성 API가 호출됩니다.
상태 저장: kube-apiserver는 매 요청 및 클러스터 변경 사항을 etcd Database에 기록하고 업데이트합니다.
컨트롤러 동작: kube-controller-manager가 etcd 상태 변화를 모니터링하다가 ReplicaSet 및 Pod 생성 API를 수행합니다.
스케줄링: kube-scheduler가 노드의 자원 상태를 모니터링하여, 생성될 Pod를 어느 노드에 할당할지 결정(노드 스케줄링)합니다.

3. Node 계층 (컨테이너 생성 및 헬스 체크)

노드 모니터링: 해당 노드의 kubelet은 kube-apiserver를 감시하다가 자신에게 할당된 Pod 정보가 넘어오면 이를 감지합니다.
컨테이너 실행: kubelet이 로컬의 컨테이너 런타임(containerd)에 컨테이너 생성 요청을 전달하여 실제 프로세스를 띄웁니다.
Probe 체크 (상태 검사):
- 컨테이너가 띄워진 후, kubelet이 설정된 probe 기준에 따라 컨테이너 상태를 직접 주기적으로 검사합니다.
- Startup Probe: 앱 기동 완료 여부 확인 (실패 시 재기동)
- Readiness Probe: 트래픽 수신 준비 완료 여부 확인 (실패 시 서비스 엔드포인트 제외)
- Liveness Probe: 프로세스 생존 상태 확인 (실패 시 컨테이너 재시작)

Service 동작

출처: [지상편] 쿠버네티스 첫 오브젝트 잘 끼우기 > Component 동작으로 이해하기 > Service 동작

쿠버네티스에서 외부 사용자가 호출한 API 트래픽이 Service(NodePort)를 거쳐 최종 목적지인 Pod의 컨테이너까지 전달되는 전체 네트워크 포워딩 메커니즘을 보여주는 다이어그램입니다.

1. Resource 계층 (서비스 및 네트워크 설정)

Service (nodePort): NodePort 타입의 Service 오브젝트가 생성되어 외부 트래픽을 받기 위한 포트(예: 31231)를 노드 전체에 개방합니다.
Pod 연결: Service의 selector 조건과 Pod의 labels가 매칭되어, 진입한 트래픽이 올바른 타겟 파드로 라우팅될 수 있도록 연결 고리를 형성합니다.

2. Control Plane & Worker 계층 (네트워크 정책 구성)

Network 생성 요청: kube-apiserver에 Service 생성 요청이 등록되면, 각 노드의 kube-proxy가 이를 감지합니다.
CNI 연동 (calico): 클러스터 내부 및 Pod 간의 네트워크 통신 환경은 Addon Pod로 설치된 CNI 플러그인(calico)을 통해 제어됩니다.
iptables 규칙 업데이트: kube-proxy는 Service 및 Endpoints 정보를 기반으로 노드의 OS iptables 라우팅 규칙을 자동으로 업데이트합니다.

3. Node 계층 (실제 트래픽 흐름)

외부 API 호출: 외부 클라이언트가 http://Node_IP:31231/version 형태로 노드의 개방된 포트(31231)로 API 요청을 보냅니다.
iptables 포워딩: 노드의 OS 단 iptables가 들어온 요청(port 31231)을 낚아채어, 해당 서비스(api-tester-1231)와 매핑된 Pod IP 및 포트(targetPort)로 트래픽을 변환(NAT)합니다.
컨테이너 전달: 변환된 트래픽이 최종적으로 container로 전달되어 애플리케이션의 응답을 처리하게 됩니다.

Secret 동작

출처: [지상편] 쿠버네티스 첫 오브젝트 잘 끼우기 > Component 동작으로 이해하기 > Secret 동작

Secret 데이터를 볼륨(Volume) 마운트 방식으로 Pod에 주입했을 때의 데이터 동기화 메커니즘과 메모리 기반 마운트의 특징을 보여주는 다이어그램입니다.

1. Resource 계층 (Secret과 Volume 바인딩)

Secret ➔ Pod (volume): Secret 오브젝트에 정의된 data가 Pod 내부의 volume 영역으로 연결되어 있습니다.
내용 수정 시 동기화: Secret의 data 내용이 수정될 때, 볼륨으로 연결된 파드는 이를 동적으로 감지하여 반영할 준비를 합니다.

2. Control Plane & Worker 계층 (변경 사항 동기화)

주기적 변경 확인: 해당 노드의 kubelet이 kube-apiserver를 통해 Secret 오브젝트의 변경 사항을 주기적으로 감시(Poll/Watch)합니다.
볼륨 내용 업데이트: Secret 값이 변경되면 kubelet이 파드를 재시작하지 않고도, 컨테이너 내부로 마운트되어 있는 해당 파일 영역을 실시간으로 업데이트합니다.

3. Node 계층 (Memory 기반 마운트의 데이터 보안 특징)

Memory(tmpfs) 마운트: 노드의 물리 디스크가 아닌 노드의 메모리(Memory) 영역에 Secret 파일(postgresql-info.yaml)을 생성한 후 컨테이너 내부 지정 경로(/usr/src/myapp/datasource/postgresql-info.yaml)로 마운트합니다.
휘발성 특징 (전원 오프 시 데이터 삭제): 메모리 영역을 활용하기 때문에 서버 전원이 꺼지면 메모리에 올려두었던 데이터가 함께 삭제되어, 물리 디스크에 보안 데이터 흔적이 남지 않는 보안적 특성을 가집니다.

HPA 동작

출처: [지상편] 쿠버네티스 첫 오브젝트 잘 끼우기 > Component 동작으로 이해하기 > HPA 동작

클러스터 내 부하(CPU, Memory 등)를 감지하여 Pod 수량을 자동으로 조절하는 HorizontalPodAutoscaler(HPA)의 전체 매트릭 수집 및 스케일링 흐름을 보여주는 다이어그램입니다.

1. Resource 계층 (오토스케일링 대상 및 조건)

HPA (metrics): HPA 컨트롤러가 Target으로 지정된 Deployment의 리소스 사용 상태를 감시하며 스케일아웃/인 조건(임계값)을 제어합니다.
Deployment 제어: HPA 조건에 따라 Deployment의 replicas 수량을 변경하여 Pod 개수를 늘리거나 줄입니다.

2. Control Plane & Worker 계층 (메트릭 연동 및 스케일링)

메트릭 수집 (metrics-server): Addon Pod로 설치된 metrics-server가 각 노드의 kubelet으로부터 수집된 파드별 CPU/메모리 사용 데이터를 집계합니다.
임계값 비교 (kube-controller-manager):
- HPA 컨트롤러가 포함된 kube-controller-manager가 kube-apiserver를 통해 metrics-server에 요청을 보내 15초 주기로 현재 사용량 매트릭을 조회합니다.
- 조회한 매트릭과 HPA에 설정된 임계값(metrics)을 비교합니다.
스케일링 명령 수행: 임계치를 초과하거나 미달할 경우, HPA 컨트롤러가 Deployment의 replicas 수치를 조절하여 파드 확장을 명령합니다. (전체 반응 시간: 1~85초)

3. Node 계층 (실제 자원 메트릭 조회)

컨테이너 자원 조회: 각 노드의 kubelet이 containerd 런타임 및 cgroup을 통해 파드 내 컨테이너의 CPU/Memory 사용량을 10초 주기로 조회합니다.
자원 정보 집계: kubelet은 조회된 자원 사용량 메트릭을 60초 주기로 metrics-server로 전송 및 수집시킵니다.

[쿠버네티스 어나더 클래스 - Sprint1] #7. Application 기능으로 이해하기#3 - PV/PVC, Deployment, Service, HPA

@sseyeon_ — Wed, 26 Aug 2026 15:58:24 +0900

[참고]
본 글은 인프런의
<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>
강의 내용과 실습을 바탕으로 정리한 기록입니다.

PV, PVC 기본 개념

컨테이너 내부에서만 데이터를 저장하면 파드(Pod)가 재시작되거나 삭제될 때 내부 파일도 함께 사라집니다. 데이터의 영구적 보존을 위해 스토리지 오브젝트인 PV와 PVC가 필요합니다.

PV (PersistentVolume): 클러스터 내의 실제 물리/논리 스토리지 자원
PVC (PersistentVolumeClaim): 사용자가 PV를 할당받기 위해 전달하는 요청서
용량 매칭 규칙: PVC의 resource.request.storage 값과 PV의 capacity.storage 값은 동일하게 설정해야 정상 바인딩됩니다.
nodeAffinity 설정 이유: PV에서 특정 노드를 지정하는 설정입니다. 파드가 데이터가 존재하지 않는 다른 노드에 생성되는 현상을 방지합니다.

hostPath : PV, PVC를 거치지 않고 Pod에서 노드의 파일 시스템에 직접 연결하는 Pod 의 volumes.hostPath 속성도 존재합니다. 하지만 HostPath 볼륨에는 많은 보안 위험이 있어, 쿠버네티스 공식 문서에서는, 가능하면 사용하지 않을 것을 권장합니다.

️ 동작 확인

✅ 파일 생성 API 호출

✅ 경로별 생성 파일 확인

Pod 내 비마운트 경로: /usr/src/myapp/tmp (파드 삭제 시 소멸)
Pod 내 VolumeMount 경로: /usr/src/myapp/files/dev
PV Volume 저장 경로: /root/k8s-local-volume/1231 (실제 노드 경로)

✅ Pod 삭제 후 PV Volume 확인

Deployment 기본 개념 (배포 및 업데이트 전략)

Deployment는 Pod의 생성 및 업데이트를 관리합니다. Deploy의 spec.template 하위 설정이 하나라도 변경되면 자동으로 업데이트 프로세스가 수행됩니다.

Deployment Update 시 ReplicaSet 관리

새로운 이름의 replicaset 을 만듦
새(api-tester-1231-2xxxx) replicas : 2로 설정, 기존(api-tester-1231-1xxxx) replicas : 0 으로 설정
그럼 이전 pod 들은 삭제가 되는데, 기존 replicaset 은 그대로 있음 → 새버전의 문제가 생겨 롤백을 해야할 경우 사용

Recreate / RollingUpdate 두가지 방식에 따라 업데이트가 진행되는 과정이 다릅니다

배포 방식	동작 방식	장점	단점
Recreate	기존 파드를 모두 일시 삭제한 후, 새 파드들을 동시에 생성	자원 중복 사용 없음	새 파드 기동 완료까지 서비스 중단(Downtime) 발생
RollingUpdate	새 파드를 1개 생성하여 기동 완료되면 기존 파드 1개를 순차 삭제 반복	무중단 배포 가능	배포 중 순간 자원 사용량 증가(최대 150%), 두 버전 혼재 호출 발생

두 버전 혼재 이슈 대안: RollingUpdate 중 신·구 버전 API가 동시 호출되는 현상이 문제가 된다면 Blue/Green 배포 방식을 채택합니다.
RollingUpdate 제어 속성:
- maxUnavailable: 업데이트 과정 중 최대 몇 개의 파드가 서비스 불능 상태가 되는 것을 허용할지 결정
- maxSurge: 설정된 replicas 수 대비 최대 몇 개의 파드를 추가로 더 만들 수 있는지 결정

Service 기본 개념

Service는 spec.selector 조건과 Pod의 metadata.labels를 매칭하여 트래픽을 파드로 전달합니다. type: NodePort 사용 시 외부 트래픽을 쿠버네티스 내부 Pod로 포워딩할 수 있습니다.

주요 핵심 역할 3가지:
- 서비스 퍼블리싱: 외부 트래픽을 내부 Pod로 라우팅
- 서비스 디스커버리: IP가 가변적인 Pod 대신 고정된 Service 이름(내부 DNS)으로 API 호출
- 서비스 레지스트리: 동적으로 변하는 Pod IP를 추적·관리하고 로드밸런싱 수행

포트 추상화 기법 (Port Name 매칭)

애플리케이션 포트가 변경될 때마다 Service의 targetPort를 매번 수정하는 번거로움을 줄이기 위해 포트 이름(Name) 매칭 방식을 사용합니다.

# Pod (Deployment) 측 설정
containers:
  - ports:
      - name: http           # 포트 이름을 'http'로 명시
        containerPort: 8080  # App 포트가 변경되면 이 숫만 변경

# Service 측 설정
ports:
  - port: 80
    targetPort: http         # 숫자가 아닌 포트 이름 'http'를 타겟팅

HPA 기본 개념

HPA는 부하량에 따라 파드 개수를 유연하게 늘리거나 줄입니다.

기준값의 중요성: Pod에 설정된 resource.requests 값은 HPA가 100% 임계치를 계산하는 절대적인 기준점이 됩니다.
스케일아웃 계산 예시 (목표 평균 CPU Utilization: 60%):
Limits의 영향: resource.limits 설정 역시 애플리케이션의 최대 임계 한계치를 결정짓는 데 큰 영향을 미칩니다.
behavior 속성: 잦은 스케일인/아웃(Thrashing) 현상을 방지하기 위해 대기 시간(stabilizationWindowSeconds)이나 변동 비율을 제어합니다.

[쿠버네티스 어나더 클래스 - Sprint1] #6. Application 기능으로 이해하기#2 - Configmap, Secret

@sseyeon_ — Tue, 25 Aug 2026 11:12:01 +0900

[참고]
본 글은 인프런의
<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>
강의 내용과 실습을 바탕으로 정리한 기록입니다.

Configmap, Secret 기본 개념

쿠버네티스에서 ConfigMap과 Secret은 애플리케이션 코드와 설정값을 분리하여 외부에서 환경 데이터를 주입하기 위해 사용되는 오브젝트입니다.

ConfigMap에 저장되는 데이터:
- 인프라 환경 관련 값: 개발/검증/운영 환경(dev, stage, prod)에 따라 달라지는 설정
- App 기능 제어 값: 기능 On/Off 스위치, 로깅 레벨 등
- 외부 환경 주입 값: 외부 API 엔드포인트 URL 등 일반 설정 정보
Secret에 저장되는 데이터:
- DB 접속 정보: DB URL, 계정 및 비밀번호 (작성 시 stringData 필드 활용 가능)
- 인코딩 방식: Secret 내부 데이터는 Base64로 인코딩되어 저장 ( 암호화가 아닌 단순 인코딩에 불과함)

알아두면 좋은 점

중요 데이터를 반드시 Secret에 넣어야 하는 것은 아니며, 상황에 따라 ConfigMap에 두어도 동작상 문제는 없습니다.
Secret은 보안 목적 외에도 쿠버네티스 내부 리소스 간 규격화된 데이터를 다룰 때 자주 활용됩니다.
데이터 암호화는 ConfigMap/Secret 오브젝트 자체의 기능과 별개의 영역으로 다루어야 합니다.

ConfigMap과 Secret을 수정하더라도 애플리케이션에 즉시 반영되지 않을 수 있습니다. 주입 방식에 따라 실시간 반영 여부가 결정됩니다.

환경변수(envFrom, env) 주입: App 기동 시점에 값이 결정되므로, ConfigMap/Secret을 수정해도 Pod를 재시작하기 전까지는 반영되지 않음
볼륨(volumes, volumeMounts) 주입: 파일 형태로 Pod 내부 디렉토리에 마운트되며, ConfigMap/Secret 변경 시 실시간(수 초~수 분 내)으로 파일 내용이 업데이트됨

️ 동작 확인

✅ Configmap, Secret 입력값 확인

대시보드에서 확인하기

명령어로 확인하기

// Configmap 확인
$ kubectl describe -n anotherclass-123 configmaps api-tester-1231-properties
$ kubectl get -n anotherclass-123 configmaps api-tester-1231-properties -o yaml
$ kubectl get -n anotherclass-123 configmaps api-tester-1231-properties -o jsonpath='{.data}'

// Secret 확인
$ kubectl get -n anotherclass-123 secret api-tester-1231-postgresql -o yaml
$ kubectl get -n anotherclass-123 secret api-tester-1231-postgresql -o jsonpath='{.data}'

// Secret data에서 postgresql-info가 Key인 Value값만 조회 하기
kubectl get -n anotherclass-123 secret api-tester-1231-postgresql -o jsonpath='{.data.postgresql-info\.yaml}'

// Secret data에서 postgresql-info가 Key인 Value값을 Base64 디코딩해서 보기
kubectl get -n anotherclass-123 secret api-tester-1231-postgresql -o jsonpath='{.data.postgresql-info\.yaml}' | base64 -d

✅ 컨테이너 내부 주입 데이터 확인

// Configmap 환경 변수 확인
env

// Secret 파일 확인
ls /usr/src/myapp/datasource
cat /usr/src/myapp/datasource/postgresql-info.yaml

// java 실행 인자 확인
jps -v

✅ App API 조회 (/info), (/properties)

✅ Configmap 수정

configmap 만 수정했을 땐 app 기동 설정이 바뀌지 않음

application_role 이 여전히 ALL

secret 을 수정하면, 볼륨 마운트에 연결시켜놨기 때문에 값이 바뀜

✅ API 재확인 (/info), (/properties)

파드 삭제 전에는, configmap 은 적용 안되어 있고, secret 은 적용이 된 상태.

파드 재생성 후, Configmap 의 수정된 설정값 Role = GET

이름 때문에 기대가 컸던 Secret

Secret은 목적에 따라 type을 지정할 수 있으며, 각 타입에 맞는 정해진 Key-Value 템플릿 구조를 제공합니다.

type: Opaque: 가장 기본 유형으로 ConfigMap과 유사한 Key-Value 구조
type: kubernetes.io/docker-registry: 비공개 레지스트리(Docker Hub 등) 인증 정보 저장용 (정해진 Key값 사용)
type: kubernetes.io/tls: Ingress 등에서 HTTPS 통신을 위한 TLS 인증서 및 개인키(tls.crt, tls.key) 저장용

이처럼 쿠버네티스는 사용자 편의를 위한 템플릿(Type)을 제공하지만, 어떤 Type도 데이터 자체를 암호화해주지는 않습니다.

그래서 중요 데이터에 대한 암호화는 어떻게 해야하나?

Secret이 자체 암호화를 제공하지 않기 때문에, 실무에서는 중요 데이터를 안전하게 관리하기 위해 다음 3가지 방안을 사용합니다.

관리방안 1. 클러스터 내 직접 관리 (접근 제어)
- RBAC(Role-Based Access Control)을 사용해 Secret 리소스에 접근할 수 있는 권한을 엄격히 제한
관리방안 2. 애플리케이션 단 자체 암호화 (추천 ⭐)
- Secret에는 처음부터 암호화된 값을 저장하고, App 내부 복호화 로직을 통해 실행 시점에 복호화하여 사용
관리방안 3. 서드파티 솔루션 연동 (추천 ⭐)
- Vault, AWS Secrets Manager 등 전문 외부 보안 관리 솔루션을 연동하여 사용

Secret이라는 이름 때문에 당연히 데이터 암호화를 제공할 것으로 기대하기 쉽지만, 실상은 Base64 인코딩일 뿐입니다.

데이터 노출을 원천 차단하려면 관리방안 2, 3 처럼 관리하는 것이 권장됩니다.

[쿠버네티스 어나더 클래스 - Sprint1] #5. Application 기능으로 이해하기#1 - Pod(probe)

@sseyeon_ — Fri, 21 Aug 2026 14:51:56 +0900

[참고]

본 글은 인프런의

<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>

강의 내용과 실습을 바탕으로 정리한 기록입니다.

쿠버네티스에서 Probe(프로브)는 컨테이너의 상태를 주기적으로 진단(Health Check)하는 메커니즘입니다. 파드(Pod) 내부의 애플리케이션이 정상적으로 시작되었는지, 사용자 요청을 받을 준비가 되었는지, 혹은 죽지 않고 살아있는지를 쿠버네티스가 스스로 감시하도록 만듭니다.

쿠버네티스는 크게 3가지 Probe를 제공합니다.

Probe 종류	핵심 질문	주요 역할
startupProbe	"앱 초기화가 끝났는가?"	앱이 구동될 때까지 다른 Probe 동작을 유예 (초기 구동 보장)
readinessProbe	"지금 트래픽을 받을 수 있는가?"	준비 미달 시 Service 라우팅에서 제외 (트래픽 차단)
livenessProbe	"앱이 정상적으로 살아있는가?"	응답 불능(Deadlock 등) 시 컨테이너 강제 재기동 (Self-Healing)

deployment.yaml의 컨테이너 스펙 내에 3가지 Probe를 적용한다면 다음과 같습니다.

# deployment.yaml
# spec.template.spec.containers.*
          startupProbe:
            httpGet:
              path: "/startup"
              port: 8080
            periodSeconds: 5
            failureThreshold: 36
          readinessProbe:
            httpGet:
              path: "/readiness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: "/liveness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 3

어차피 장애 나면 둘 다 실패하는데, Probe를 굳이 구분하는 이유가 뭘까?

애플리케이션에 장애가 발생하면 livenessProbe와 readinessProbe 모두 실패(Fail)를 반환합니다. 그렇다면 왜 쿠버네티스는 굳이 이 둘을 나누어 놓았을까요?

그 이유는 "장애 발생 시 쿠버네티스가 취하는 대응 액션"이 완전히 다르기 때문입니다.

구분	readinessProbe	livenessProbe
목적	지금 트래픽을 받을 준비가 되었는가?	애플리케이션이 정상 동작 중(생존)인가?
실패 시 액션	Service 연결 해제 (트래픽 차단)	Pod 재기동 (Restart)
비유	"손님 받을 준비 안 됐으니 잠시 대기표 끊어!"	"앱이 멈췄으니(Deadlock) 강제 재부팅해!"

Application 동작 중심의 Probe 이해

위 다이어그램처럼 애플리케이션 라이프사이클과 연결하면 이해가 훨씬 쉬워집니다.

1. startupProbe (App 초기화 단계)

상태: DB 연결, Spring 초기화, Heavy한 초기 데이터 로딩 중
역할: 앱이 완전히 뜰 때까지 다른 Probe 실행을 유예합니다. 초기화가 느린 앱이 시작도 못 해보고 livenessProbe에 의해 재기동되는 불상사를 막아줍니다.

2. readinessProbe (User 초기화 & 트래픽 제어)

상태: 연동 시스템 체크, DB Data Validation 진행 중 또는 순간적인 부하 폭증 상태
역할: 실패 시 Service 라우팅 대상에서 해당 Pod를 즉시 제외합니다.
핵심: 앱이 완전히 죽은 것은 아니지만, 잠시 트래픽을 처리할 수 없는 상태(지연)일 때 Pod를 강제로 죽이지 않고 트래픽만 유예시켜 안전하게 복구될 시간을 벌어줍니다.

3. livenessProbe (App 기동 완료 후 생존 체크)

상태: 애플리케이션이 교착 상태(Deadlock)에 빠졌거나 무한 루프 등으로 응답 불가 상태
역할: 연속 실패 시 Pod를 강제로 재기동(Restart)하여 프로세스를 살려냅니다.

응용 과제

️ 응용1 : startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요.

✅ 과제 풀이

startupProbe 의 API Path를 존재하지 않는 경로로 설정하여 무한 재기동 상태를 유발했습니다.

failureThreshold : 3
httpGet.path : /startup_notFound

️ 응용2 : 일시적 장애 상황(App 내부 부하 증가)가 시작 된 후, 30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요. (아래 API를 날리면 readinessProbe와 livenessProbe가 동시에 실패하게 됩니다)

// 부하 증가 - (App 내부 isAppReady와 isAppLive를 False로 바꿈)
curl http://192.168.56.30:31231/server-load-on

// 외부 API 실패
curl http://192.168.56.30:31231/hello

// 부하 감소 API - (App 내부 isAppReady와 isAppLive를 True로 바꿈)
curl http://192.168.56.30:31231/server-load-off

️ 응용3 : Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요. (꼭 API를 날리는 것만이 readinessProbe 활용의 전부는 아닙니다)

[쿠버네티스 어나더 클래스 - Sprint1] #4. Object 그려보며 이해하기

@sseyeon_ — Wed, 19 Aug 2026 17:43:24 +0900

[참고]

본 글은 인프런의

<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>

강의 내용과 실습을 바탕으로 정리한 기록입니다.

주요 학습 대상 파일 (Object)

namespace.yaml: 클러스터 내 리소스들을 논리적으로 격리하고 구분하는 자원 공간 정의
pv.yaml / pvc.yaml: 스토리지 자원(PersistentVolume)과 이를 사용하기 위한 할당 요청(PersistentVolumeClaim) 정의
configmap.yaml / secret.yaml: 애플리케이션에 전달할 일반 설정값과 보안 데이터(비밀번호, 토큰 등) 관리
deployment.yaml: 파드(Pod)의 생성, 개수 유지, 업데이트 전략을 관장하는 워크로드 컨트롤러
service.yaml: 배포된 파드들에 접근할 수 있도록 고정 IP 및 로드밸런싱을 제공하는 네트워크 엔드포인트
hpa.yaml: 부하량(CPU/메모리 등)에 따라 파드의 개수를 자동으로 조절(Auto Scaling)하는 설정

아키텍처 다이어그램

기존 개념 도식표만으로는 오브젝트 간의 실질적인 연동 방식이 모호해,

HPA, Deployment, Service, PVC 등 실제 설정 파일의 어떤 값들이 서로 연결되어 작동하는지 실제 YAML 코드 구조를 바탕으로 매핑 관계도를 새로 그려보았습니다.

1. HPA ➔ DEPLOYMENT

HPA의 scaleTargetRef가 Deployment의 이름(api-tester-1231)을 가리키며 부하에 따른 자동 스케일링을 수행합니다.

2. SERVICE ➔ DEPLOYMENT (Pod)

노란색 점선(Selector - Labels): Service의 spec.selector 조건과 Deployment의 spec.template.metadata.labels가 매칭되어 Pod로 트래픽을 전달합니다.

3. DEPLOYMENT ➔ CONFIGMAP & SECRET

Deployment 내부 컨테이너의 envFrom 및 volumeMounts 구성을 통해 ConfigMap(환경변수)과 Secret(보안 데이터) 정보를 파드 내 디렉토리나 환경변수로 할당합니다.

4. DEPLOYMENT ➔ PVC ➔ PV ➔ Master Node (스토리지 연결)

파드가 데이터를 영구 저장하기 위해 PVC를 참조합니다.
파란색 점선: PVC의 matchLabels와 PV의 labels가 서로 매칭되어 연결됩니다.
최종적으로 PV에 정의된 nodeAffinity와 로컬 경로(hostPath/local)를 통해 Master Node의 실제 물리 디렉토리(/root/k8s-local-volume/1231)와 바인딩됩니다.

쿠버네티스를 처음 접할 때 가장 헷갈리는 부분이 'Deployment를 올렸는데 왜 ReplicaSet과 Pod가 따로 존재하는가?' 그리고 '이 많은 YAML 파일들이 대체 무슨 라벨(Label)로 연결되어 있는가?' 입니다.

이를 한눈에 이해하기 위해 Deployment를 ReplicaSet과 Pod 계층으로 쪼개고, Service·Pod 간의 민트색 라벨 매칭, PV·PVC 간의 파란색 스토리지 매칭, 그리고 Master Node의 실제 물리 경로 연결 흐름까지 하나의 인포그래픽으로 정리해 보았습니다.

1. Deployment ➔ ReplicaSet ➔ Pod 계층화

Deployment: 전체 배포 전략(RollingUpdate)과 파드 개수(replicas: 2)를 선언
ReplicaSet: Deployment에 의해 자동 생성되며, pod-template-hash 라벨을 통해 파드의 지정된 복제본 수를 실질적으로 유지·관리
Pod: 가장 기본 단위로 실행되며, 실제 컨테이너(api-tester-1231:v1.0.0) 환경 구축

2. 색상별 Selector & Labels 매칭 완벽 정리

노란색 점선 (Deployment ↔ ReplicaSet): scaleTargetRef 및 컨트롤러 단위의 매칭 관계
민트색 점선 (ReplicaSet ↔ Service ↔ Pod): part-of, component, name, instance 라벨과 pod-template-hash가 결합되어 Service 트래픽이 정확히 해당 Pod로 라우팅되는 매칭 구조
파란색 점선 (PVC ↔ PV): matchLabels를 통한 스토리지 볼륨 매칭 및 Master Node의 실제 로컬 디렉토리(/root/k8s-local-volume/1231) 바인딩

3. Pod 내부 연동 구조

ConfigMap / Secret: envFrom 및 volumes 설정을 통해 파드 내부의 환경변수 및 파일 형태로 바인딩되어 애플리케이션에 전달

실제 터미널에서 확인하는 계층 구조

작성한 다이어그램처럼 쿠버네티스 내부에서 Deployment ➔ ReplicaSet ➔ Pod 순으로 생성되었는지는 kubectl 명령어로 직접 확인할 수 있습니다.

# 1. Deployment 확인
kubectl get deployment -n anotherclass-123
# NAME              READY   UP-TO-DATE   AVAILABLE
# api-tester-1231   2/2     2            2

# 2. ReplicaSet 확인 (Deployment 이름 뒤에 해시값이 붙음)
kubectl get rs -n anotherclass-123
# NAME                         DESIRED   CURRENT   READY
# api-tester-1231-6b45d6f6b5   2         2         2

# 3. Pod 확인 (ReplicaSet 이름 뒤에 무작위 값이 붙음)
kubectl get pod -n anotherclass-123
# NAME                                 READY   STATUS    RESTARTS
# api-tester-1231-6b45d6f6b5-x8z9q     1/1     Running   0
# api-tester-1231-6b45d6f6b5-m2k4p     1/1     Running   0

✅ 이름 규칙 포인트:

ReplicaSet 이름: [Deployment 이름]-[Pod Template 해시값] (6b45d6f6b5)
Pod 이름: [ReplicaSet 이름]-[랜덤 문자열] (x8z9q, m2k4p)

이처럼 Pod 이름만 봐도 해당 파드가 어떤 ReplicaSet과 Deployment에 속해 있는지 역추적할 수 있습니다.

Label 및 Selector 설계 핵심 규칙

쿠버네티스에서 오브젝트 간의 관계를 유연하고 명확하게 연결하려면 라벨(Label) 규칙을 잘 설계하는 것이 무엇보다 중요합니다.

권장 Label 구성 5가지 핵심 요소:
- part-of: 전체 프로젝트/시스템명
- component: 해당 앱의 역할 (예: backend-server, database)
- name: 애플리케이션 이름 (예: api-tester)
- instance: 식별 가능한 인스턴스 명칭 (다른 오브젝트들의 이름으로 확장 사용)
- version: 배포 버전 (예: v1.0.0)
관리 도구 명시 (managed-by): Helm 등 배포 및 관리 도구 정보를 기록
Domain Prefix 사용: Label Key에 도메인 형태의 접두어를 사용해 식별성과 네임스페이스 명확화
Selector-Label 매칭 원칙:
- Service나 Deployment의 selector에 지정된 모든 항목은 대상 Pod의 labels에 100% 모두 존재해야 정상 매칭됨
- 설계 구조에 따라 instance 라벨 하나만으로도 유니크한 1:1 또는 N:1 매핑 구현 가능

쿠버네티스를 처음 공부하면서 단순히 추상적인 개념 도식표만 볼 때는 각 리소스가 따로 노는 것 같았지만, 실제 YAML 코드 기반의 라벨(labels)과 셀렉터(selector) 매칭 구조로 관계도를 직접 그려보니 전체적인 아키텍처 흐름이 한눈에 들어왔습니다.

표준화된 오브젝트 규칙만 잘 지켜서 구성해두면, 아무리 많은 애플리케이션과 솔루션이 추가되어도 운영과 자동화 관리가 왜 압도적으로 편해지는지 확실히 체감할 수 있는 계기가 되었습니다.

[쿠버네티스 어나더 클래스 - Sprint1] #3.실무에서 느껴본 쿠버네티스가 정말 편한 이유

@sseyeon_ — Thu, 13 Aug 2026 22:46:43 +0900

[참고]

본 글은 인프런의

<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>

강의 내용과 실습을 바탕으로 정리한 기록입니다.

이번 섹션에선 개발 → 분석(모니터링, 로깅) 으로 연결되는 흐름을 실습해봅니다.

이 실습의 궁극적인 목표는 "쿠버네티스가 왜 편한가?"를 직접 체감하고 이해하는 것입니다.

하나의 프로젝트에 서로 다른 60개의 솔루션이 포함되어 있어도, 쿠버네티스 표준을 따른다면 관리하기 수월해진다고 하는데, 왜 그렇게 되는지?

모니터링 도구 설치 (Prometheus - with Grafana, Loki-Stack)

k8s-master 에서 다음 명령 실행

Git REPO 받아오기

$ yum -y install git

# 로컬 저장소 생성 
$ git init monitoring
$ git config --global init.defaultBranch main
$ cd monitoring

# remote 추가
$ git remote add -f origin https://github.com/k8s-1pro/install.git

# sparse checkout 설정
$ git config core.sparseCheckout true
$ echo "ground/k8s-1.27/prometheus-2.44.0" >> .git/info/sparse-checkout
$ echo "ground/k8s-1.27/loki-stack-2.6.1" >> .git/info/sparse-checkout

# 다운로드 
$ git pull origin main

Prometheus (with Grafana) 설치

# 설치
$ cd ~/monitoring
$ kubectl apply --server-side -f ground/k8s-1.27/prometheus-2.44.0/manifests/setup
$ kubectl wait --for condition=Established --all CustomResourceDefinition --namespace=monitoring
$ kubectl apply -f ground/k8s-1.27/prometheus-2.44.0/manifests

✅ 확인 결과

Loki-Stack 설치

# 설치
$ cd ~/monitoring
$ kubectl apply -f ground/k8s-1.27/loki-stack-2.6.1

✅ 확인 결과

Grafana 접속 후, Loki 연결

입력 후, 하단으로 스크롤하여 save&test

임의로 deployment, replicaset, service 생성

Grafana에서 잘 모니터링 되는지 확인

모니터링할 네임스페이스를 지정하면(namespace = default), 현재 쿠버네티스에 배포된 파드를 별도의 복잡한 설정 없이 바로 모니터링할 수 있습니다.

쿠버네티스 생태계가 편리한 진짜 이유는 새로운 앱이 추가되더라도 수동 작업 없이 대부분의 과정이 자동화되어 있기 때문입니다. 그리고 이 모든 자동화가 가능한 근본적인 이유는, 모든 애플리케이션이 쿠버네티스 표준 아키텍처를 준수하며 배포되기 때문입니다.

실제 실무에서는 기존 VM 환경처럼 ①번(OS, JDK, WAS 등) 환경 구축부터 IP 설정, 모니터링 연동까지 여러 서버에 걸쳐 수작업으로 진행하는 경우가 많았습니다. (특히 ①번을 여러 서버에 걸쳐 여러번 진행하고 매번 다른 내용을 지원해 주었습니다..)

하지만 쿠버네티스를 도입하면 이러한 반복적인 수동 설정 과정을 오케스트레이션 도구가 자동화해 주기 때문에, 운영 및 배포 생산성이 크게 향상됩니다.

결국 쿠버네티스 표준을 따른다는 것은, 반복되는 수작업에서 벗어나 애플리케이션 구축과 운영을 훨씬 빠르고 안정적으로 자동화할 수 있음을 의미합니다.