[인프런 워밍업 클럽 4기 - DevOps] 미션 4. PVC/PV, Deployment

[PV, PVC]▶ 1~4. local 동작 확인// 1번 API - 파일 생성// 2번 - Container 임시 폴더 확인// 2번 - Container 영구저장 폴더 확인// 2번 - master node 폴더 확인// 3번 - Pod 삭제// 4번 API - 파일 조회▶ 5. hostPath 동작 확인 - Deployment 수정 후 [1~4] 실행// 1번 API - 파일 생성// 2번 - Container 임시 폴더 확인// 2번 - Container 영구저장 폴더 확인// 2번 - master node 폴더 확인// 3번 - Pod 삭제// 4번 API - 파일 조회 [Deployment]▶ 1. RollingUpdate 하기// 1) HPA minReplica 2로 바꾸기 (이전 강의에서 minReplicas를 1로 바꿔놨었음)// 2) 지속적으로 Version호출 하기 (업데이트 동안 리턴값 관찰)▶ 2. RollingUpdate (maxUnavailable: 0%, maxSurge: 100%) 하기▶ 3. Recreate 하기▶ 4. Rollback [Service] ▶ 1. Pod 내부에서 Service 명으로 API 호출 [서비스 디스커버리]// Version API 호출▶ 2. Deployment에서 Pod의 ports 전체 삭제, Service targetPort를 http -> 8080으로 수정 [HPA] ▶ 1. 부하 발생▶ 1. 부하 확인▶ 2. [behavior] 미사용으로 적용▶ 2. 부하 발생▶ 2. 부하 확인 (kubectl)

[인프런 워밍업 클럽 4기 - DevOps] 미션 3. Configmap, Secret

▶ 응용1 : Configmap의 환경변수들을 Secret을 사용해서 작성하고, App에서는 같은 결과가 나오도록 확인해 보세요.Step1. Secret 생성 (1) - dashboard Step1 - Secret 생성 (2) - kubectl #1 Step1 - Secret 생성 (2) - kubectl #2 Step2. Deployment의 envFrom.secretRef 부분 업데이트 ▶ 응용2 : 반대로 Secret의 DB정보를 Configmap으로 만들어보고 App을 동작시켜 보세요Step1. Secret 생성 (1) - dashboard Step2. Deployment의 volumeMounts.name과 volumes 부분 업데이트

[인프런 워밍업 클럽 4기 - DevOps] 미션 2. Probe 응용과제

▶ 응용1 : startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요.변경전"startupProbe": { "httpGet": { "path": "/startup", "port": 8080, "scheme": "HTTP" }, "timeoutSeconds": 1, "periodSeconds": 5, "successThreshold": 1, "failureThreshold": 36 } 변경후"startupProbe": { "httpGet": { "path": "/startup", "port": 8080, "scheme": "HTTP" }, "timeoutSeconds": 1, "periodSeconds": 5, "successThreshold": 1, "failureThreshold": 1 # startup의 failureThreshold의 값을 36 > 1로 변경 } 상태확인"Startup probe failed." 라는 에러메세지가 반복적으로 발생▶ 응용2 : 일시적 장애 상황(App 내부 부하 증가)가 시작 된 후, 30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요.변경전"livenessProbe": { "httpGet": { "path": "/liveness", "port": 8080, "scheme": "HTTP" }, "timeoutSeconds": 1, "periodSeconds": 10, "successThreshold": 1, "failureThreshold": 3 }, "readinessProbe": { "httpGet": { "path": "/readiness", "port": 8080, "scheme": "HTTP" }, "timeoutSeconds": 1, "periodSeconds": 10, "successThreshold": 1, "failureThreshold": 3 }, 변경후"livenessProbe": { "httpGet": { "path": "/liveness", "port": 8080, "scheme": "HTTP" }, "timeoutSeconds": 1, "periodSeconds": 60, "successThreshold": 1, "failureThreshold": 3 # 60초마다 3번 확인하여 실패시, 앱을 재기동 }, "readinessProbe": { "httpGet": { "path": "/readiness", "port": 8080, "scheme": "HTTP" }, "timeoutSeconds": 1, "periodSeconds": 10, "successThreshold": 1, "failureThreshold": 3 # 10초마다 3번씩 확인하여 실패시, 트래픽 중단 }, 상태확인부하를 준 후, 30초 후에 API 호출시 트래픽이 중단된 것을 확인부하를 준 후, 대략 3분 후 앱이 재기동 되는 것을 확인▶ 응용3 : Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요.변경전"readinessProbe": { "httpGet": { "path": "/readiness", "port": 8080, "scheme": "HTTP" }, "timeoutSeconds": 1, "periodSeconds": 10, "successThreshold": 1, "failureThreshold": 3 }, 변경후"readinessProbe": { "exec": { "command": [ "sh", "-c", "[ -s /usr/src/myapp/datasource/postgresql-info.yaml ]" ] }, # httpGet이 아니라 명령을 실행하도록 변경 "timeoutSeconds": 1, "periodSeconds": 10, "successThreshold": 1, "failureThreshold": 3 }, 상태확인

인프런 워밍업 클럽 4기 DevOps - 2주차 발자국

이번 주는 쿠버네티스의 핵심 리소스들을 학습하면서, 기존에 사용하던 ECS와 비교하면서 강의를 들었던 것 같습니다. 기능 자체는 대부분 유사하지만, 쿠버네티스는 선언적 구성과 리소스 중심의 구조 덕분에 운영과 관리가 더 유연하다는 느낌을 받았습니다.ECS와 비교하며 새로웠던 점Deployment ECS도 무중단 배포 지원함. minimumHealthyPercent, maximumPercent 값을 통해 배포 중 유지할 작업 수, 동시에 추가할 작업 수를 조절할 수 있음쿠버네티스는 RollingUpdate 전략에서 maxSurge, maxUnavailable 설정으로 배포 중 새 Pod 생성 수와 동시에 중단 가능한 기존 Pod 수를 정밀하게 제어할 수 있음 Probe (헬스 체크) ECS는 ALB 헬스 체크 위주. 태스크 내 애플리케이션 상태까지 세분화된 제어는 어려움. 쿠버네티스는 startupProbe, readinessProbe, livenessProbe로 상태별 헬스 체크 분리 가능. readinessProbe로 준비 안 된 Pod은 서비스에서 제외시켜 트래픽 유입 차단 가능. 앱 기동 지연이나 일시적 장애 등 다양한 상황에 유연하게 대응 가능함.ConfigMap / Secret ECS도 환경 변수, Secrets Manager, SSM Parameter Store 등을 통한 설정 주입 가능. 쿠버네티스는 설정(ConfigMap)과 민감 정보(Secret)를 리소스로 분리해 명시적으로 관리. 환경 변수뿐 아니라 파일로도 마운트 가능해서 설정 주입 방식이 유연함. 설정 재사용성과 형상 관리 측면에서 이점 있음.HPA (Auto Scaling) ECS도 CPU/Memory 기준 오토 스케일링 지원하고, CloudWatch 기반 커스텀 메트릭 확장 가능. 쿠버네티스는 YAML로 선언하고, 애플리케이션 중심 메트릭(HPA + Metrics Server, Prometheus 등) 연동 쉬움. PVC (스토리지) ECS에서는 EFS를 직접 마운트해서 사용했지만, 쿠버네티스는 PVC(PersistentVolumeClaim)를 통해 스토리지 요청과 실제 볼륨을 분리해 구성할 수 있다는 개념이 흥미로움 다음 주차도 화이팅!

인프런 워밍업 클럽 4기 DevOps - 1주차 발자국

최근 회사에서 웹서비스를 온프레미스에서 ECS로 마이그레이션 하는 프로젝트를 맡아 진행을 하며, 오케스트레이션 도구와 배포에 관련한 지식과 애정이 깊어가는 중 우연히 인프런에서 워밍업 클럽의 DevOps 과정을 보게 되었고 언젠가는 ECS를 넘어 EKS 혹은 쿠버네티스를 사용할 기회가 분명있을 거라는 생각에 워밍업 클럽에 등록하게 되었습니다 😊 이번 1주차에는 쿠버네티스를 이해하기 위한 사전 지식들과 역사에 대해서 배웠고, 쿠버네티스 환경 구축, 쿠버네티스가 제공하는 편한 기능들과 오브젝트의 일부분을 배우게 되었습니다. 강사님의 편안한 설명 방식 덕분에 전체적인 흐름을 자연스럽게 따라갈 수 있었고, ‘전체 → 세부’ 구조로 개념을 정리해 나갈 수 있었습니다. 강사님의 정리하는 방식, 기술적인 내용뿐 아니라 실무와 연결된 인사이트, 그리고 동기를 북돋아주는 이야기들까지 더해져 학습 몰입도가 높았다. 다음주차도 화이팅!

[인프런 워밍업 클럽 4기 - DevOPs] 미션 1. 쿠버네티스 설치 구간별 상태 확인

설치 환경칩 : Apple M2 Max메모리 : 32GBmacOS : Sonoma 14.5가상플랫폼 : UTM [3-1] Rocky Linux 버전 확인[3-2] Hostname 확인[3-3], [3-4] Network 확인[3-5] 자원(cpu, memory) 확인[4] Rocky Linux 기본 설정[5] kubeadm 설치 전 사전작업▶ 방화벽 해제 확인▶ 스왑(swap) 비활성화 확인[6] 컨테이너 런타임 설치[6-1] 컨테이너 런타임 설치 전 사전작업[6-2] 컨테이너 런타임 (containerd 설치)[6-3] 컨테이너 런타임 (CRI활성화)▶ kubelet cgroup 확인 (configmap)▶ kubelet cgroup 확인 (kubelet)[7] kubeadm 설치▶ SELinux 설정 확인▶ kubelet, kubeadm, kubectl 패키지 설치▶ 설치 가능한 버전의 kubeadm 리스트 확인[8] kubeadm으로 클러스터 생성[8-1] 클러스터 초기화 (Pod Network 세팅)[8-2] kubectl 사용 설정[8-3] CNI Plugin 설치 (calico)[8-4] Master에 pod를 생성 할 수 있도록 설정[9] 쿠버네티스 편의 기능 설치[9-1] kubectl 자동완성 기능[9-2] Dashboard 설치[9-3] Metrics Server 설치