인프런 워밍업 스터디 클럽 4기 데브옵스 - 4주차 발자국

4주차 요약 정리 섹션 18. Helm과 Kustomize 비교하며 사용하기Helm템플릿 기반 배포 도구로, values.yaml을 통해 반복되는 설정을 효율적으로 관리.helm install, upgrade, rollback 등으로 배포 전 과정을 CLI로 관리.디렉토리 구조(charts, templates, values.yaml)를 이해하고, 복잡한 애플리케이션의 배포를 간결하게 처리 가능.Kustomize오버레이 방식의 선언적 구성 도구로, 리소스를 직접 수정하지 않고 환경별 분리를 가능하게 함.base와 overlay 구조를 활용해 운영/개발 환경에 따라 다른 설정을 적용할 수 있어 유지보수에 유리.비교 및 활용Helm은 복잡한 구조, 패키징 중심에 유리하며, Kustomize는 간단한 환경 분리와 선언적 구성에 적합.YAML 중복, 설정 분리, 관리 효율성을 고려해 실제 파이프라인 설계 시 도구 선택 기준을 학습함. 섹션 19. ArgoCD 빠르게 레벨업 하기ArgoCD 개요GitOps 철학 기반의 배포 도구로, Git 저장소의 상태를 기준으로 Kubernetes 클러스터와 동기화.애플리케이션 상태를 UI 또는 CLI에서 실시간으로 모니터링하고 관리 가능.주요 구성 요소Server: Web UI 및 CLI API 제공Repo Server: Git 저장소로부터 manifest 불러오기Application Controller: Desired vs Live 상태 비교 후 동기화Kube API: Kubernetes 리소스와 통신Redis: 상태 캐싱Dex: SSO 등 외부 인증 연동실습 포인트Application 리소스를 정의해 Git과 쿠버네티스를 연결하고, 자동 배포 구성Argo Image Updater를 활용해 Docker 이미지 태그 변경 시 자동으로 Sync 수행Argo Rollouts로 Blue-Green, Canary 배포 전략 실습 → 트래픽을 점진적으로 전환하며 안정성 확보활용 및 이해수동 배포 없이 Git 상태만으로 자동 배포 관리 가능상태 기반 배포 시스템의 장점: 추적 가능성, 자동 롤백, 변경 이력 관리🌱 발자국 4주차 회고 💡 배운 점Helm과 Kustomize의 철학과 구조적 차이를 명확히 이해하고, 어떤 상황에 어떤 도구가 적합한지 판단할 기준을 마련함ArgoCD를 통해 GitOps 방식의 배포를 실현하고, Rollouts와 Image Updater를 통한 자동화와 고급 배포 전략을 경험함 🙆‍♂ 잘한 점Helm과 Kustomize의 구조 및 설정을 실습하며 실제 프로젝트 적용 가능성을 높임ArgoCD의 구성요소와 배포 흐름을 이해하며 도구 간 연동 방식을 익힘 ⚠ 아쉬운 점Helm/Kustomize의 고급 기능(예: 조건 분기, hooks 등)을 더 실습하지 못한 점Rollouts에서 트래픽 조정, 자동 중단 조건 등 실전 적용 요소를 더 경험해보지 못한 점 🎯 다음 목표실제 업무 환경에 도입할 수 있는 배포 전략을 시뮬레이션 해보기. ☺ 한마디도구는 단지 수단일 뿐,중요한 건 무엇을 위해, 어떻게 사용할 것인지에 대한 것을 많이 배운 시간이었습니다.4주라는 것이 길다면 길고 짧다면 짧은 시간이지만 의미있는 시간이었길 바랍니다.이제 도구들을 사용하는 방법을 알게 되었으니, 내가 어떻게 만들고 어떻게 적용해나갈지 끈임없이 고민해보겠습니다.그동안 너무 감사했습니다. ㅎㅎ 다들 고생 많으셨어요.

인프런 워밍업 스터디 클럽 4기 데브옵스 - 미션5 (Docker와 Containerd)

Docker와 Containerd 명령 실습 [미션5]쿠버네티스 설치 시 Docker Hub에서 여러 이미지를 다운로드하는 과정에서, "toomanyrequests" 에러가 발생할 수 있음. 이유는 Docker Hub의 요청 제한 정책 때문익명 사용자: 6시간 동안 최대 100건로그인 사용자: 6시간 동안 최대 200건회사에서 여러 사람이 같은 IP로 요청하면 제한에 쉽게 걸릴 수 있음6시간을 기다리는 것이 아니라 다른 우회 방법을 찾고자 함 방법- 개인 PC인 경우: 휴대폰 테더링으로 IP를 바꿔 우회 가능- 회사 내부망 전용 PC/VM의 경우: 이미지를 다른 경로(복사 등)로 전달하는 방법을 고려해야 함 결론- 네트워크 제약이 있는 환경이라면 이미지 복사 등 대안이 필요- 제한을 우회하려면 IP 분리 또는 프록시 등의 방법을 고민할 수 있음 내 개인 노트북을 통해서 이미지를 다운 받고 -> 쿠버네티스가 있는 서버에 복사 하는 플로우 예시 [도커 6]->[도커 7]->[컨테이너디 7] 순으로 작업 dockercontainerdDocker 명령어 실습사전 준비(코드 다운로드)도커 파일 및 App 소스 다운로드curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/etc/docker/Dockerfilecurl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/etc/docker/hello.js 전체 실습 명령어docker build -t noah1209/hello:1.0.0 .docker image listdocker tag noah1209/hello:1.0.0 noah1209/hello:2.0.0docker login -u noah1209docker push noah1209/hello:1.0.0docker rmi noah1209/hello:1.0.0docker pull noah1209/hello:1.0.0docker save -o file.tar noah1209/hello:1.0.0docker load -i file.tar 빌드이미지 리스트 조회태그 변경로그인 및 이미지 업로드이미지 삭제이미지 다운로드이미지 -> 파일로 변환파일 -> 이미지로 변환 Containerd 명령어 실습전체 실습 명령어ctr ns listctr -n k8s.io image listctr images pull docker.io/noah1209/hello:1.0.0ctr images tag docker.io/noah1209/hello:1.0.0 docker.io/noah1209/hello:2.0.0ctr image push docker.io/noah1209/hello:2.0.0 --user ratschectr -n default image export file.tar docker.io/noah1209/hello:1.0.0ctr -n k8s.io image import file.tarctr -n k8s.io image remove docker.io/noah1209/hello:1.0.0 네임스페이스 조회특정 네임스페이스 내 이미지 조회다운로드 및 이미지 확인태그 변경업로드이미지 -> 파일로 변환파일 -> 이미지(namespace : k8s.io)로 변환삭제 (namespace : k8s.io) 같은 이미지를 도커에서 받았을 때와 쿠버네티스에서 받았을 때 사이즈가 다른 이유 Docker와 Containerd에서 다운로드 받고 이미지 Size를 확인Docker 다운로드 -> 520MBContainerd 다운로드 -> 247.8MB분석같은 이미지를 받았는데 사이즈가 이렇게 다를 수 있나? 싶었습니다.Docker로 1pro/api-tester:latest 이미지를 받았을 땐 520MBContainerd로 받았을 땐 247.8MB처음엔 "혹시 Docker는 amd64 버전을 받고, Containerd는 arm64로 받아서 그런가?" 의심했지만,두 환경 모두 linux/amd64 플랫폼에서 테스트한 결과, 이건 아니었습니다.Containerd에서 PLATFORMS 항목에 여러 아키텍처가 표시되는 건,"이 이미지는 여러 플랫폼을 지원한다"는 정보일 뿐,여러 플랫폼의 레이어를 실제로 다 받아온 건 아니더라고요.그렇다면 왜 사이즈 차이가 날까요? 간단히 말하면, Docker는 이미지를 조금 더 '포장'해서 보관합니다.Docker는 이미지 내에 각종 히스토리, 빌드 정보, 메타데이터 등을 추가로 저장하고, 이걸 자기만의 방식으로 압축하고 재구성해요. 반면 Containerd는 꼭 필요한 것만 가져다 쓰는 경량화 버전입니다.실제로 Docker에서 이미지를 save해서 파일로 만든 후 Containerd로 가져가면, 파일 사이즈는 줄어들고 그 반대는 오히려 파일 사이즈가 커졌습니다. 결론결국 사이즈 차이는 런타임의 성격 차이에서 비롯된 것 같습니다.Docker는 만능툴답게 이미지에 이것저것 부가 정보를 더 많이 붙입니다. 그래서 같은 이미지라도 더 크게 보이고,Containerd는 핵심만 챙기는 실속형 런타임이라 같은 이미지라도 더 작고 가볍게 보입니다.그렇기 때문에 오프라인 환경에서 이미지 파일을 주고받을 때는, 사용 중인 런타임에 맞춰 이미지 저장 방식도 맞추는 게 좋습니다. 예를 들어, Kubernetes에서 Containerd를 쓰고 있다면 Docker로 받은 이미지보다 Containerd에서 직접 받은 이미지 파일을 쓰는 게 더 효율적이라고 생각합니다.

인프런 워밍업 스터디 클럽 4기 데브옵스 - 3주차 발자국

3주차 요약 정리 3주차 요약 정리 섹션 13. 데브옵스(DevOps) 한방 정리데브옵스 파이프라인이 아무리 복잡해도 결국은 개발한 코드를 빌드해서 실행 가능한 파일로 만드는 게 본질이라는 점이 가장 인상 깊었어요. 개발, CI/CD, 인프라 환경(개발/QA/운영)에서 각각 어떤 도구와 역할이 필요한지 명확히 알게 됐고요. 특히 운영 환경의 이중화와 QA 환경을 운영과 똑같이 만드는 것의 중요성을 뼈저리게 느꼈습니다. GitHub와 Jenkins를 활용해 소스 관리부터 빌드, 배포 자동화의 기본 흐름을 파악한 것도 큰 수확이었습니다. 섹션 14. 손쉽게 데브옵스 환경을 구축하는 방법VirtualBox와 Vagrant로 CI/CD 서버를 직접 구축하고 Jenkins에 접속하는 경험은 정말 값졌습니다. Docker Hub나 GitHub 계정 연동, Jenkins 기본 설정, Kubernetes 인증서 복사까지, 파이프라인의 기반을 직접 다져보니 훨씬 잘 이해가 되더라고요. Jenkins에서 소스 빌드, 컨테이너 빌드, 배포 프로젝트를 직접 만들고 실행하면서 전체 흐름을 체감한 것도 뿌듯한 경험이었습니다. 섹션 15. 배포를 시작하기 전에 반드시 알아야 할 것들CI/CD 파이프라인 구성: 단순히 기능 좋은 툴을 고르는 게 아니라, 누가 관리할지, 단일 구성이 편할지 아니면 분리 구성으로 장애 영향을 최소화할지 등 다양한 측면을 고려해야 한다는 점이 신선했어요. 툴 선정 시 데이터 보안 환경은 물론, GitHub Actions나 Jenkins처럼 레퍼런스가 많은 툴과 유지보수 가능 여부를 꼭 따져봐야 한다고 배웠습니다. Docker의 단점(무거움, 데몬 필요)도 알게 됐지만, 여전히 Docker가 대세라는 점과 Buildah, Podman 같은 대안 툴도 존재한다는 점도 흥미로웠습니다.배포 전략 수립: Recreate나 Rolling Update 같은 기본 방식 외에, 무중단 배포의 핵심인 Blue-Green과 Canary 배포에 대해 깊이 있게 다뤘습니다. Blue-Green은 빠른 롤백과 운영 DB 테스트에, Canary는 점진적인 트래픽 유입으로 콜드 스타트 방지 및 A/B 테스트에 활용할 수 있다는 점을 이해했습니다. DB 스키마 변경처럼 서비스 중단이 불가피한 예외 상황도 있다는 점을 잊지 말아야겠다고 생각했어요.단계별 파이프라인 로드맵: Jenkins 기본(레벨 1)부터 시작해 Jenkins Pipeline(레벨 2)으로 스크립트 기반 관리를, Kustomize/Helm(레벨 3)으로 YAML 파일의 동적 구성을, 그리고 마지막으로 Argo CD(레벨 4)로 GitOps 기반 배포를 하는 로드맵을 제시해 주셔서 앞으로의 학습 방향이 명확해졌습니다. 섹션 17. Jenkins Pipeline (기초부터 Blue/Green 까지)섹션 18. Helm과 Kustomize 비교하며 사용하기이론을 바탕으로 Jenkins Pipeline을 UI에서 스크립트 기반으로 전환하며 배포 단계를 세분화하고 Blue-Green 배포를 직접 구현해본 건 정말 값진 경험이었어요. 자동 배포의 기초를 닦은 기분이랄까요!그리고 Helm의 패키지(차트) 관리와 Kustomize의 오버레이 방식을 비교하며, YAML 파일을 재사용하고 커스터마이징하는 법을 배운 것도 유용했습니다. 실제 배포 파이프라인 구축 시 마주할 고민들을 미리 짚어주신 것도 도움이 많이 됐습니다. 🪵 발자국 3주차 회고 발자국 3주차 회고💡배운 점DevOps가 단순히 툴 사용을 넘어 애플리케이션 운영 철학과 밀접하며, 개발-빌드-실행 파일의 핵심 흐름을 이해하는 것이 중요함을 깨달았습니다.CI/CD 환경 구축과 배포 전략 수립 시 기술적 효율성뿐 아니라 운영 환경, 보안, 조직 문화 등 다양한 요소를 고려해야 한다는 점을 배웠습니다.Jenkins Pipeline 스크립트, Blue-Green/Canary 배포, 그리고 Helm/Kustomize를 통한 YAML 동적 구성이 실제 배포 자동화와 유연성에 어떻게 기여하는지 체감했습니다. 🤷‍♂잘한 점CI/CD 서버 구축 실습에서 문제를 직접 해결하며 학습 능력을 높였습니다.'왜' 이런 설계가 필요한지 끊임없이 질문하며 DevOps 개념에 대한 구조적 이해를 심화했습니다. ⚠아쉬운 점Blue-Green/Canary 배포의 트래픽 전환과 앱 영향에 대해 깊게 고민 하지 못함.Helm/Kustomize 부분이 밀려서 집중 해서 듣지 못함 🎯다음 주 목표섹션 18 Helm, Kustomize 부분 다시 복습하기내용 정리해서 기록하기 ☺한마디3주차는 DevOps와 배포 전략에 대한 사고의 폭을 넓힌 시간이었던 것 같습니다.단순히 도구를 익히는 것을 넘어, '적절한 기술'을 선택하고 '단계적으로' 적용해나가야 할 것 같습니다.다음 주가 마지막 스터디 주인데, 내용 놓친것 없는지 다시 한번 복습하면서 마무리 잘해나갑시다.🚀

인프런 워밍업 스터디 클럽 4기 데브옵스 - 미션4(PVC/PV, Deployment 등)

Application 기능으로 이해하기 - PVC/PV, Deployment, Service, HPA [미션4] PVC / PV 실습1-1. local 및 hostPath 설정 실습 Step 1~4. local PV 동작 확인create-file-pod, create-file-pv API 호출로 파일 생성Pod 내 경로 확인:kubectl exec -n anotherclass-123 -it -- ls /usr/src/myapp/tmp kubectl exec -n anotherclass-123 -it -- ls /usr/src/myapp/files/dev Master 노드에 실제 저장:ls /root/k8s-local-volume/1231Pod 삭제 후에도 /files/dev 경로의 데이터는 유지됨list-file-pod, list-file-pv API로 확인 Step 5. hostPath로 수정 후 재확인PVC 설정 제거hostPath 설정:volumes: - name: files hostPath: path: /root/k8s-local-volume/1231 다시 1~4단계 반복 → 동일하게 파일 유지 및 공유 확인 Deployment 실습2-1. RollingUpdateHPA minReplica를 2로 설정하거나 직접 scale:kubectl patch -n anotherclass-123 hpa api-tester-1231-default -p '{"spec":{"minReplicas":2}}' 이미지 변경으로 롤링 업데이트 실행:kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v2.0.0 서비스 중단 없이 버전 순차 업데이트 확인 2-2. RollingUpdate 전략 수정maxUnavailable: 0%, maxSurge: 100% 설정으로 무중단 배포 보장 2-3. Recreate 전략 실습전략 변경:strategy: type: Recreate 업데이트 시 전체 Pod가 삭제되었다가 다시 생성됨 → 일시적 서비스 중단 확인 2-4. 롤백kubectl rollout undo -n anotherclass-123 deployment/api-tester-1231이전 버전으로 손쉽게 복원됨 Service 실습3-1. Service 명으로 내부 API 호출Pod 내부에서 DNS를 통해 호출:curl http://api-tester-1231:80/version 3-2. Deployment에서 ports 제거, Service의 targetPort 수정containerPort 제거 후에도 호출 정상 작동 확인 → targetPort 명시로 연결 가능 HPA 실습4-1. 부하 발생 → 자동 스케일 확인CPU 부하 API 호출:curl "http://192.168.56.30:31231/cpu-load?min=3&thread=5"kubectl top pods로 부하 확인일정 시간 후 Replica 수 증가 → 자동 스케일 아웃 확인 4-2. behavior 미사용 설정 실습behavior 항목 제거하고 부하 재시도 → 즉각적인 반응성과 디폴트 동작 확인 미션4 소감Pod가 죽어도 데이터는 살아있고, 서비스 중단 없이 업데이트되고, CPU 부하에 따라 알아서 확장되는 것을 직접 확인하니 쿠버네티스가 왜 필요한지 확실히 와닿았다.PVC는 데이터 지속성을, Deployment는 무중단 배포를, Service는 안정적인 통신을, HPA는 자동 확장성을 제공한다는 것을 실습으로 체감할 수 있었다.

인프런 워밍업 스터디 클럽 4기 데브옵스 - 미션3 (Configmap, Secret)

Application 기능으로 이해하기 - Configmap, Secret > 응용과제 [미션3] ConfigMap, Secret이란?Kubernetes에서 ConfigMap은 설정 파일이나 일반 설정값Secret은 민감한 정보를 안전하게 관리하기 위한 리소스 응용1. ConfigMap의 환경변수들을 Secret으로 전환해라Step 1. Secret 생성 방법Dashboard에서 Secret 생성:apiVersion: v1 kind: Secret metadata: namespace: anotherclass-123 name: api-tester-1231-properties labels: part-of: k8s-anotherclass component: backend-server name: api-tester instance: api-tester-1231 version: 1.0.0 managed-by: dashboard stringData: spring_profiles_active: "dev" application_role: "ALL" postgresql_filepath: "/usr/src/myapp/datasource/dev/postgresql-info.yaml"kubectl로 Secret 생성 (YAML):kubectl apply -f - kubectl 단축 명령어로 생성:kubectl create secret -n anotherclass-123 generic api-tester-1231-properties2 \ --from-literal=spring_profiles_active=dev \ --from-literal=application_role=ALL \ --from-literal=postgresql_filepath="/usr/src/myapp/datasource/dev/postgresql-info.yaml" Step 2. Deployment에 적용envFrom: - secretRef: name: api-tester-1231-propertieskubectl edit -n anotherclass-123 deployments.apps api-tester-1231 응용2. Secret의 DB정보를 ConfigMap으로 전환해보라Step 1. ConfigMap 생성apiVersion: v1 kind: ConfigMap metadata: namespace: anotherclass-123 name: api-tester-1231-postgresql labels: part-of: k8s-anotherclass component: backend-server name: api-tester instance: api-tester-1231 version: 1.0.0 managed-by: dashboard data: postgresql-info.yaml: | driver-class-name: "org.postgresql.Driver" url: "jdbc:postgresql://postgresql:5431" username: "postgres" password: "postgres" Step 2. Deployment에 VolumeMount 설정volumeMounts: - name: configmap-datasource mountPath: /usr/src/myapp/datasource/dev volumes: - name: configmap-datasource configMap: name: api-tester-1231-postgresql kubectl edit -n anotherclass-123 deployments.apps api-tester-1231 미션3 소감ConfigMap과 Secret은 쿠버네티스 환경에서 설정값을 분리하고 보안을 강화하는 도구임을 확인함Secret을 환경변수로 직접 연결하거나, ConfigMap을 파일로 마운트하는 방식 모두 실전에서 다양하게 활용될 수 있다는 것을 확인했고, 실제 운영을 위한 구성을 경험해볼 수 있었음

인프런 워밍업 스터디 클럽 4기 데브옵스 - 미션2 (Probe)

Application 기능으로 이해하기 - Probe > 응용과제 [미션2] Probe란?Kubernetes에서 Probe는 컨테이너 상태를 체크하기 위한 매커니즘입니다.startupProbe: 앱이 기동됐는지 확인readinessProbe: 앱이 트래픽을 받을 준비가 되었는지 확인livenessProbe: 앱이 살아있는지 확인 응용1. startupProbe가 실패하도록 설정해서 Pod가 무한 재기동 상태가 되도록 하라방법startupProbe: httpGet: path: "/startup" port: 8080 periodSeconds: 5 failureThreshold: 1 readinessProbe: httpGet: path: "/readiness" port: 8080 periodSeconds: 10 failureThreshold: 3 livenessProbe: httpGet: path: "/liveness" port: 8080 periodSeconds: 10 failureThreshold: 3 /startup 엔드포인트가 기동 직후 실패하도록 App을 수정failureThreshold: 1 설정으로 한 번 실패하면 Pod는 무한 재시작 결과kubectl get pods로 확인 시, Pod가 CrashLoopBackOff 상태로 반복 재기동kubectl describe pod에서 startupProbe 실패 로그 확인 응용2. App이 부하로 인해 30초 뒤 트래픽이 중단되고, 3분 뒤 재기동 되게 하라방법livenessProbe: httpGet: path: "/liveness" port: 8080 periodSeconds: 60 failureThreshold: 3 readinessProbe는 10초 주기로 3번 실패 시 트래픽 차단 (30초 후)livenessProbe는 60초 주기로 3번 실패 시 재시작 (180초 후)/server-load-on API로 내부 상태 변경 결과부하 API 호출 후, 30초 후에 서비스 응답 끊김 (kubectl describe pod로 확인)약 3분 뒤에 livenessProbe에 의해 자동 재기동응용3. readinessProbe로 Secret 파일 존재 여부를 확인하라방법readinessProbe: exec: command: ["cat", "/usr/src/myapp/datasource/postgresql-info.yaml"] periodSeconds: 10 failureThreshold: 3 해당 경로에 Secret 파일이 존재하지 않으면 readinessProbe 실패파일이 생성된 후에야 서비스로 트래픽 전달 가능결과파일 존재하지 않을 때 NotReady 상태 유지kubectl logs로 command 실행 실패 확인파일 생성 후, Pod가 Ready 상태로 전환됨 미션2 소감Kubernetes의 Probe는 단순한 헬스체크가 아닌, 운영자의 철학을 반영하여 정교하게 확인하는 것을 알게 되었음오동작보다 무서운 것은 오동작을 감지하지 못하는 것이고, Probe는 그 위험을 미연에 막아주는 역할

인프런 워밍업 스터디 클럽 4기 데브옵스 2주차 발자국

2주차 요약 정리 Probe: 어플리케이션 생명주기를 반영하는 헬스체크Startup Probe: 앱이 완전히 기동되기 전까지의 초기화 확인.Readiness Probe: 트래픽 수신 가능 여부 확인 (연결/해제).Liveness Probe: 앱이 살아있는지 주기적 확인 (장애시 재기동).실습을 통해 실제 로그 흐름과 API 응답 시점, Probe 실패 → 재기동 상황까지 체감함.일시적 장애에 대한 Probe 설정 전략 (readiness만 실패 허용, liveness는 재기동 지연 설정)이 중요 포인트. ConfigMap & Secret: 설정과 민감 정보를 외부에서 주입ConfigMap: 환경 변수, 실행 설정 등 일반 설정 값 주입.Secret: Base64 인코딩 기반 민감 정보 전달. 실질적 보안은 RBAC/암호화와 병행 필요.마운트 방식에 따라 실시간 반영 가능 여부 달라짐 → envFrom vs. volumeMount 비교 실습.설정 변경 반영에는 Pod 재기동이 필요하다는 사실 확인. PV / PVC: 컨테이너 외부로의 데이터 영속화PV (영구 볼륨): 실제 물리 스토리지와 연결된 인프라 측 설정.PVC (볼륨 클레임): 앱에서 요청하는 인터페이스.local + nodeAffinity, hostPath 방식 실습 → 운영 환경에서의 주의점 인식.볼륨 설계는 앱 구조뿐 아니라 운영 자동화 전략과 직결됨을 이해. Deployment / Service / HPADeploymentRecreate: 서비스 중단 있지만 간결함.RollingUpdate: 중단 없이 점진적 배포. maxSurge, maxUnavailable로 유연하게 조정.실무에선 서비스 특성 + 자원 고려로 전략 선택 필요.ServiceClusterIP / NodePort → 내부/외부 접근.Service Discovery / Registry / Load Balancing 모두 포함된 멀티 기능.타겟 포트와 이름 기반 라우팅 실습으로 구조적 이해 확장.HPA (Auto Scaling)CPU 기반 스케일링 → 평균 사용률이 핵심.behavior 설정으로 불필요한 스케일링 방지.CPU 외의 지표 (Queue, Thread, DB 커넥션 등)에 대한 관찰 중요. 🪵 발자국 2주차 회고 💡 배운 점Probe를 통해 앱 상태의 생애주기를 쿠버네티스가 어떻게 자동화하는지 이해함.ConfigMap/Secret의 주입 방식, 실시간 반영 여부의 차이를 실습으로 체감.PVC/PV는 단순 저장공간이 아니라 운영 설계 철학과도 연결되어 있음.RollingUpdate 전략을 조절하며 중단 없는 배포와 자원 최적화의 균형을 고민하게 됨.HPA는 “자동”이지만 “만능”은 아님 → 스케일링의 현실을 정확히 바라보는 시야가 열림. 🤷‍♂ 잘한 점각 오브젝트를 앱 관점에서 재정의하며, 도구가 아닌 개념으로 이해하려 함.실습 로그와 API 응답 시점을 주의 깊게 분석하며 실제 운영 흐름을 그려봄.“기능”보다 “왜 그런 설계가 되었는가”에 집중해 구조적 통찰을 넓힘. ⚠ 아쉬운 점Probe 실패 시 앱 장애 로그 해석에 익숙하지 않아 시간이 걸림.HPA behavior 설정이 실제 환경에선 어떻게 적용될지 아직 가늠이 부족함.PVC 설정 시 nodeAffinity 이해에 다소 시간이 소요됨. 🎯 다음 주 목표쿠버네티스 전체 개념 복습하기Ingress 구조확인 & CI/CD 서버환경 구성하기 배포 파이프라인 구성하기 ☺한마디이번 주는 쿠버네티스를 단지 “컨테이너 자동화 플랫폼”이 아니라, 애플리케이션 운영의 철학과 구조를 담은 생태계로 느끼기 시작한 시간이었다.쿠버네티스를 알면 알수록, 단순한 툴을 넘어 사고방식의 변화가 필요하다는 걸 실감하고 있다.실수해도 괜찮다. 중요한 건 이 구조 안에서 직접 시행착오를 겪고 내 앱의 주인이 되는 것이다.다음 주에도 더 깊이 파고들어 보자.“기능을 배우는 게 아니라, 원리를 꿰뚫는 눈을 기르는 것”이 목표다.파이팅입니다 🔥💻🚀

인프런 워밍업 스터디 클럽 4기 데브옵스 1주차 미션 - 구간별 상태 확인

쿠버네티스 무게감 있게 설치하기 (1)# 구간별 상태 확인- MAC OS 기준[3-1] Rocky Linux 버전 확인▶ k8s-master 원격접속 후 명령어 실행cat /etc/*-release[3-2] Hostname 확인▶ k8s-master 원격접속 후 명령어 실행hostname[3-3], [3-4] Network 확인▶ k8s-master 원격접속 후 명령어 실행ip addr[3-5] 자원(cpu, memory) 확인▶ k8s-master 원격접속 후 명령어 실행lscpufree -h 쿠버네티스 무게감 있게 설치하기 (2)구간별 상태 확인- MAC OS 기준[4] Rocky Linux 기본 설정▶ 타임존 설정 확인timedatectl[5] kubeadm 설치 전 사전작업▶ 방화벽 해제 확인systemctl status firewalld▶ 스왑(swap) 비활성화 확인free[6] 컨테이너 런타임 설치[6-1] 컨테이너 런타임 설치 전 사전작업▶ iptables 세팅cat /etc/modules-load.d/k8s.confcat /etc/sysctl.d/k8s.conflsmod | grep overlaylsmod | grep br_netfilter[6-2] 컨테이너 런타임 (containerd 설치)[6-2-1] containerd 패키지 설치 (option2)[6-2-1-1] docker engine (containerd.io)만 설치▶ docker repo 설정 확인repolist enabled▶containerd 설치 확인systemctl status containerd▶설치 가능한 버전의 containerd.io 리스트 확인yum list containerd.io --showduplicates | sort -r [6-3] 컨테이너 런타임 (CRI활성화)▶ cri 활성화 설정 확인cat /etc/containerd/config.toml▶ kubelet cgroup 확인 (configmap)kubectl get -n kube-system cm kubelet-config -o yaml▶ kubelet cgroup 확인 (kubelet)cat /var/lib/kubelet/config.yaml[7] kubeadm 설치▶ repo 설정 확인yum repolist enabled▶ SELinux 설정 확인cat /etc/selinux/configsestatus▶ kubelet, kubeadm, kubectl 패키지 설치kubeadm versionkubectl versionsystemctl status kubeletcat /var/lib/kubelet/config.yamljournalctl -u kubelet | tail -10▶ 설치 가능한 버전의 kubeadm 리스트 확인yum list --showduplicates kubeadm --disableexcludes=kubernetes[8] kubeadm으로 클러스터 생성[8-1] 클러스터 초기화 (Pod Network 세팅)▶ 클러스터 상태 확인kubectl get nodekubectl cluster-info dump | grep -m 1 cluster-cidrkubectl cluster-infokubectl get pods -n kube-system[8-2] kubectl 사용 설정▶ 인증서 설정 확인cat ~/.kube/config[8-3] CNI Plugin 설치 (calico)▶ calico pod 설치 및 pod network cidr 적용 확인kubectl get -n calico-system podkubectl get -n calico-apiserver podkubectl get installations.operator.tigera.io default -o yaml | grep cidr [8-4] Master에 pod를 생성 할 수 있도록 설정▶ Master Node에 Taint 해제 확인kubectl describe nodes | grep Taints [9] 쿠버네티스 편의 기능 설치[9-1] kubectl 자동완성 기능▶ kubectl 기능 설정 확인cat ~/.bashrc[9-2] Dashboard 설치▶ dashboard 설치 확인kubectl get pod -n kubernetes-dashboard[9-3] Metrics Server 설치▶ metrics server 설치 확인kubectl get pod -n kube-system | grep metricskubectl top pod -A ☕ 한마디처음엔 "무게감 있게"라는 표현이 과한 줄 알았지만, 각 설정의 깊이와 연관성을 느끼면서 정말 그렇게 불러도 될 만큼의 깊이를 느꼈습니다. 이번 실습을 통해 쿠버네티스를 단순한 도구가 아닌 운영체제 위에 올라가는 하나의 플랫폼처럼 바라보게 된 계기가 되었어요.앞으로 더 깊이 들어갈 여지가 많은 만큼, 이번 기초가 든든한 초석이 되기를 바랍니다. 모두 화이팅입니다! 💪

인프런 워밍업 스터디 클럽 4기 데브옵스 1주차 발자국

1주차 요약 정리 컨테이너와 런타임컨테이너는 커널 기술(namespace, cgroup, chroot) 위에서 실행되는 프로세스.Docker는 하이레벨 런타임, containerd와 runC는 로우레벨 런타임.Docker는 사용자 친화적인 기능(CLI, 로그, 네트워크 등)을 많이 포함.containerd는 핵심 컨테이너 생성만 담당.쿠버네티스는 이런 런타임과 연동하기 위해 CRI(Container Runtime Interface)를 도입. 쿠버네티스와 런타임 흐름kube-apiserver → kubelet → container runtime 순으로 파드를 생성.1.20 버전부터 Docker 지원 종료 논란 → 실제로는 Docker Shim 제거.현재는 CRI-dockerd, containerd, CRI-O 등 다양한 런타임 지원.컨테이너 이미지는 OCI(Open Container Initiative) 표준에 따라 호환됨. 대표 기능 실습 요약Deployment: 파드 이중화 및 업데이트 관리.Service: 트래픽 라우팅 및 로드밸런싱.HPA: CPU 부하 기준 파드 자동 스케일링.Liveness/Readiness Probe: 앱 상태 기반 트래픽 연결 및 재시작 제어.PVC/PV: 저장 공간 볼륨 매핑.ConfigMap/Secret: 환경변수 및 민감 데이터 주입. Object 구성 및 연결레이블(Label): 오브젝트 메타 정보 및 매칭용 키-값.셀렉터(Selector): 레이블 기반 오브젝트 연결.네이밍 규칙: 앱 이름 + 인스턴스 식별자 조합으로 유니크성 확보.오브젝트 간 관계 (Deployment → ReplicaSet → Pod), (PVC → PV) 등 그림으로 구조화 가능. 🪵 발자국 1주차 회고 💡 배운 점Docker는 하이레벨, containerd/runC는 로우레벨 컨테이너 런타임임.쿠버네티스는 kube-apiserver → kubelet → container runtime 흐름으로 파드 생성.Label과 Selector는 오브젝트 연결 핵심 도구.Self-Healing, AutoScaling, RollingUpdate 개념을 실습으로 체감. 🤷‍♂ 잘한 점흐름을 구조적으로 이해하려고 노력함.실습하면서 오브젝트 간 관계를 눈으로 확인하고 정리함. ⚠ 아쉬운 점Label-Selector 매칭 방식이 처음엔 헷갈렸음.Deployment → ReplicaSet → Pod 생성 흐름이 처음엔 추상적으로 느껴졌음. 🎯 다음 주 목표Probe, ConfigMap/Secret 동작 원리 익히기.PV/PVC 구조 및 RollingUpdate 전략 실습해보기. ☺한마디최근 이직한 곳에서 쿠버네티스를 쓰는 환경이라 두려움도 있었지만, 실습과 구조 이해를 통해 자신감을 얻기 시작했습니다. 오히려 데브옵스라는 분야에서도 관심이 가게 되네요 🚀"한 번에 모든 걸 외우려 하지 말고, 자주 마주치고 정리하며 익숙해지자"는 마음으로 차근차근 가겠습니다.다음 주도 모두 파이팅입니다 💪🔥

Java 스터디 회고록 [김영한의 자바 기본편] with 우리의 스터디 클럽

회고록 김영한의 실전 자바 - 기본편2024년 11월 11일 → 2024년 11월 25일 목표김영한의 실전 자바 - 기본편 강의를 진도에 맞게 듣고 인증각 섹션별 미션 문제를 수행하고 정리하여 공유 목표 수행 여부목표 1 : ✅목표 2 : ✅ Keep입문편에 이어서 연속으로 기본편 스터디도 참여하게 되었습니다.기본편부터는 자바의 문법보다는 객체지향 프로그래밍을 위한 생성자, 접근제어자, 상속, 다형성 등에 대해 학습하였는데요. 신기하게 4년전 자바를 처음 배울때와 또 다르게 느껴졌던 것 같아요.왜 객체지향이 생겨났는지? 어떤게 객체지향적인 코드인지 다시금 깨닫게 되는 시간이었던 것 같습니다.기본기를 튼튼히 하자! 라는 스터디 참여 목표에 좀 더 다가갈 수 있게 된 것 같습니다.처음엔 했던거 또하는게 맞을까라는 생각이 계속 들었는데, 계속 이 방향으로 가는게 미래의 저한테 더 도움이 될 것 같다는 확신이 점점 듭니다. 또한 이전 입문편에서 개념을 정리하는 부분이 늘어지는게 고민이었는데 조금은 깔끔하게 정리 되고 있어서 발전하고 있다고 느낍니다.이번에도 14일간의 시간동안 17시간의 진도인증 + 미션 풀이 + 공유를 모두 완주하게 되어 기쁘고 뿌듯합니다. Problem이번 스터디에서는 새롭게 깃허브에 미션 코드를 올리고 공유하고 피드백하는 시스템이 추가되었는데요.생각보다 코드에 제 의도가 잘 보이지 않는 문제가 있었던 것 같아요. 좀 더 친절하게 보는 사람이 의도를 명확히 이해하는 코드를 만들도록 노력해야 할 것 같습니다.개인적으로 어렵기도 했지만 이번 스터디에 코드를 공유하는 부분은 너무 만족스러웠던 것 같습니다. Try다음 스터디도 바로 이어서 자바 중급편이 진행될 것 같습니다. 실무에 필요한 자바의 중급 기능을 배우게 될 텐데 본질적인 이해를 바탕으로 기능들을 하나하나 알아 가게 될 것 같아서 기대가 됩니다. 더 자연스럽게 자바를 사용하고 싶네요.빠지지 않고 진도인증, 미션을 모두 끝까지 완주하도록 노력해야 할 것 같아요. 무튼 스터디장이신 성빈님 너무 고생많으셨고, 다른분들도 너무 너무 고생많으셨습니다. 이번에도 많이 배웠습니다.!! 🙌