[ 인프런 워밍업 클럽 4기 Devops ] 2 주 차 발자국 (13일의 금요일 -안상민)
강의 수강 내용월 - Application 기능으로 k8s 이해 - Probe화 - Application 기능으로 k8s 이해 - Configmap, Secret수 - 무게감 있게 쿠버네티스 설치목 - Application 기능으로 k8s 이해 - PV/PVC, Deployment, Service, HPA금 - Component 동작으로 k8s 이해 강의 칭찬하고 싶은 점바빴지만 이번 주도 마감 전에 복습과 발자국 완성을 지킨 점을 칭찬하고 싶습니다. 아쉬웠던 점이번 주는 평일에 일정이 많고 약속도 많아서 분주했습니다.수업을 들을 때가 밤늦게가 되어 시작하게 되어서 집중이 잘 안됐던 것 같습니다.연휴가 있어 미션도 미리 해둘 수 있었는데, 조금 게으름을 피우느라 늦어졌던 점이 아쉽네요. 보안해야 될 점저번 주에 그날그날 복습해서 블로깅하는 것을 보완할 점으로 적었는데, 잘 지켜지지 않았습니다.다음 주는 좀 피곤하더라도 꼭 지켜보려고 합니다! 회고 개인적으로 이번주는 시간이 많지 않아 수업영상만 보고 실습을 별도로 하지 못한 채 학습이 진행되었습니다. 감안 해주셔서 읽어 주시면 감사하겠습니다. ※ 배운 내용 정리 이번주 시작하고 3일 동안의 강의는 k8s 클러스터 환경에 있는 서비스 되고 있는 서버에서의 각 오브젝트들의 역할을 기준으로 설명해주셨습니다.각 오브젝트들을 기업측면에서 본다면 개발자 / 운영자 / 인프라 별로 어떻게 사용하고, 어떻게 활용 할 수 있을지 고민을 할 수 있었습니다.취업을 하게 되어 협업을 하게 된다면 소통이 필요한 부분들을 미리 그려볼수 있어서 좋았습니다. Application 기능으로 이해하기 - Probe Probe는 최종적으로는 에플리케이션이 정상적으로 클라이언트에게 서비스되고 서비스 되기 전까지 단계별로 체크해야 할 사항들을 고려해서 k8s에서 만든 설정으로 이해했습니다. 자세히 정리하면 다음과 같습니다. k8s 에서는 세가지 Probe가 있습니다.Startup Probe (시작 상태 체크) 목적: 컨테이너가 완전히 시작됐는지 확인동작: 프로브가 성공하기 전까지 Liveness/Readiness Probe를 실행하지 않음실무 사용: 시작이 느린 애플리케이션(예: 대용량 데이터 로딩, 복잡한 초기화)이 시작 중에 잘못 재시작되는 것을 방지예시: HTTP, TCP, 명령어 실행 등으로 상태 체크 Liveness Probe (활성 상태 체크)목적: 컨테이너가 정상적으로 동작하는지 주기적으로 확인동작: 프로브가 실패하면 쿠버네티스(kubelet)가 해당 컨테이너를 자동 재시작실무 사용: 애플리케이션이 죽거나, 데드락(교착 상태) 등 복구 불가능한 상태에 빠졌을 때 자동으로 재시작해 서비스 가용성을 높임예시: HTTP, TCP, 명령어 실행 등으로 상태 체크 Readiness Probe (서비스 준비 상태 체크)목적: 컨테이너가 트래픽을 받을 준비가 되었는지 확인동작: 프로브가 실패하면 서비스 엔드포인트에서 해당 Pod를 자동으로 제외시켜 트래픽이 전달되지 않음실무 사용: 애플리케이션이 초기화, 대용량 데이터 로딩, 외부 서비스 연결 대기 등으로 트래픽을 받을 준비가 안 된 경우 트래픽을 차단예시: HTTP, TCP, 명령어 실행 등으로 상태 체크※ yaml 파일에서 사용하는 probe 공동 옵션initialDelaySeconds: 컨테이너가 시작된 후 첫 번째 probe를 실행하기까지 기다리는 시간(초).periodSeconds: probe 간격(초). 이 시간마다 probe를 반복해서 실행.timeoutSeconds: probe의 응답을 기다릴 최대 시간(초). 이 시간 내에 응답이 없으면 실패로 간주.successThreshold: probe가 연속으로 성공해야 하는 횟수. 기본값은 1failureThreshold: probe가 연속으로 실패해야 하는 횟수. 이 횟수만큼 실패하면 probe가 최종 실패로 간주이 옵션들을 사용해서 각 단계별 확인이 필요한 부분들을 유연하게 결정해야 합니다. Application 기능으로 이해하기 - ConfigMap, Secret 좀 시간이 되었지만 자바 개발자로 일하던 때가 잠깐 2년 정도 있었습니다.그 당시 회사에 개발인력이 소수라서 앱에 필요한 Properties와 yml 파일들을 환경별로 관리하는 업무도 맡았었는데옛날 기억이 나서 반가웠던 파트입니다! K8s 클러스터에서의 환경변수 관리 방법을 강의을 통해 들은 내용 토대로 정리합니다! 빌드 타임에 결정: application.yaml런타임에 결정: ConfigMap절대 노출되면 안 되는 것: Secret ( Base64인코딩과 추가로 k8s의 보안적인 요소가 있긴하지만 한계가 명확) ConfigMap 과 Secret은 환경변수들을 처리하기 위해 만들어졌고 Secret은 이름 그대로 민감한 정보를 처리하기 위해서 만들어 졌지만 k8s 에서는 Base64 인코딩만 한 뒤 etcd 서버 저장 됩니다. 따라서 ectd 서버에 접근해서 가능해 디코딩만 한다면 민감정보들을 탈 취 당할 수 있다는 단점이 있습니다. 솔루션과 각 솔루션별 특징Cluster 안에서 관리 하는 방법 노드가 죽거나 클러스터 전체가 장애 나면 데이터가 사라진다는 단점이 있습니다. 암호화 시키는 Key를 따로 관리 key를 네트워크가 없는 물리적 디스크에 보관하고(보안 USB 등)가지고 있는 관리자만 소지. 보안적으로는 매우 좋지만, key를 관리하는 사람이 인사변동 되었을 때 인수인계가 제데로 되지 않으면, 환경변수에 접근 할 수 없습니다. 서드파티 솔루션 사용HashiCorp Vault, Akeyless 등을 사용하여 복구 키 관리와 설정을 맡길 수 있습니다. 2, 3번의 장점은 외부 해킹 시도로 시스템이 노출 되었다고 왔다고 해도 안전하다는 장점이 있습니다. Application 기능으로 이해하기 - PVC, PV, Deployment, Service, HPA PV/PVC파드가 장애로 인해 죽게 되면 컨테이너도 다운되고 그 안에 데이터 또한 복구가 어렵게 됩니다.이 것을 방지하기 위해 PV(Persistent Volume)이 필요 합니다. 파드가 죽어도 데이터가 보존되는 저장소. hostPath노드의 경로를 그대로 마운트파드가 다른 노드로 스케줄링되면 데이터를 못 찾음 -> nodeSelector로 노드를 고정쿠버네티스 공식 문서에서 사용하지 않는걸 권장하고 있음local PVnodeAffinity로 어느 노드에 있는 스토리지인지 명시쿠버네티스가 스케줄링할 때 이를 고려위 옵션은PV, PVC와 비슷한 역할을 하지만 노드가 죽으면 같이 사라진다는 치명적인 단점이 존재 합니다. PVC(Persistent Volume Claim)가 생기고 나서개발자가 PVC를 통해 요청을 한다면 용량에 맞게 쿠버네티스가 PV에 바인딩 해준다. 단 스토리지 용량이 PV 보다 작아야 하고,AccessMode(접근 모드)가 일치가 필수적으로 필요하고옵션으로StorageClass가 있다면 StorageClass와 기타 조건도 있다면 PVC, PV 설정을 서로 일치 시켜야 합니다. 개발자가 PVC를 보낼 때에는 위의 것들이 고려 되어야 합니다. Deployment k8s cluster 환경에서는무중단 배포를 지원한다! 전에 직장에서는 에플리케이션 버전 업데이트를 할 때 트래픽이 가장 적은 3~4시에 진행 했었는데, k8s 에서는 그런 수고로움을 덜을 수 있어 좋다. 엡이 돌아가는 환경에 따라 맞춰 사용할 수 있게끔 다음 배포 전략들이 있다.Rolling Update기본 배포 전략. 새 버전을 하나씩 올리고 구 버전을 하나씩 내리는 방식maxSurge와 maxUnavailable 옵션으로 리소스 사용량과 안정성 사이에서 균형을 맞출 수 있다.Recreate모든 구 버전을 내리고 새 버전을 올린다.다운타임이 발생하지만 잠깐 멈춰도 별 상관없는 서비스 라면 트래픽이 거의 없는 시간대에 크게 나쁘지 않은 전략Blue-Green 두 개의 완전한 환경을 준비하고 트래픽을 한 번에 전환. 롤백이 간단.단점은? 리소스가 두 배. 추가적인 자동화 도구가 필요.Canary새 버전에 트래픽의 일부만 보내서 테스트. 문제없으면 점진적으로 확장.Istio나 Flagger 같은 도구와 함께 쓰면 자동화도 가능. 여담: 재밌게 들었던 이야기옛날 광부들은 지하 갱도로 내려갈 때 카나리아라는 새를 두어마리 데리고 내려갔다고 합니다. 갱에서 나오는 이산화탄소나 메탄가스가 무색 무취여서 자신도 모르는 새에 중독 될 위험이 있기 때문에, 그런 환경에 민감한 카나리아 새를 데리고 들어간 거죠. 만약 카나리아가 노래도 하며 팔팔하다면 아직 가스 중독에 위험이 없고, 노래도 하지 않고 비실비실 하다면 이미 가스를 마셨다는 증거가 되서 즉각 대피 경고가 내려졌답니다. 이렇게 카나리아 새는 위험을 알리는 경고등처럼 사용되어졌고, 비슷한 일을 하는 카나리 테스트 이름의 유례가 되었다고 합니다. Rolling Update 가 가장 기본적인 쿠버네티스의 전략입니다. --------------------다른 분의 블로그를 둘러보다 더 알게된 내용https://inf.run/pG62s그런데 Rolling Update 중에 readiness Probe가 너무 빨리 성공해서, 아직 캐시 워밍업이 안 된 Pod에 트래픽이 들어갔다면? 이는 응답 지연이나 에러 발생의 원인이 된다. 이것을 방지하기 위해서는 [점진적 헬스 체크] 설정이 중요하다고 한다. initialDelaySeconds를 충분히 확보livenessProbe가 10초 뒤에 최초 실행되는 등readinessProbe에서 진짜 준비 상태를 판단하도록 구현단순히 HTTP 200이 아닌, 내부적으로 캐시, DB, 외부 API 등의 상태가 정상인지 점검하여 응답하게 만듦 HPAKubernetes에서 애플리케이션의 부하에 따라 파드(Pod)의 개수를 자동으로 조정해주는 기능입니다. 주로 CPU 사용량, 메모리 사용량, 혹은 커스텀 메트릭을 기준으로 동작합니다 적용 대상:Deployment, ReplicaSet, StatefulSet 등 파드의 개수를 조정할 수 있는 워크로드 리소스에 적용할 수 있습니다.자동 스케일링:HPA는 Metrics Server를 통해 주기적으로 리소스 사용량을 확인한 뒤, 설정한 메트릭 값(예: CPU 50%)을 기준으로 파드의 개수를 늘리거나 줄입니다.스케일링 공식:원하는 파드 수는 아래와 같이 계산합니다.원하는 레플리카 수=⌈현재 레플리카 수×현재 메트릭 값목표 메트릭 값⌉원하는 레플리카 수=⌈현재 레플리카 수×목표 메트릭 값현재 메트릭 값⌉예를 들어, 목표 CPU 사용률이 50%이고 실제 사용률이 100%라면 파드 수가 2배로 늘어납니다.스케일링 범위:최소/최대 파드 개수를 지정할 수 있습니다. 예를 들어, 최소 1개, 최대 10개로 제한할 수 있습니다.주기적 동작:HPA 컨트롤러는 기본적으로 15초마다 메트릭을 확인하고, 필요시 파드 수를 조정합니다. 이 주기는 설정으로 변경할 수 있습니다.여러 메트릭 지원:CPU/메모리 외에도 사용자 정의 메트릭, 외부 메트릭 등 다양한 기준으로 스케일링이 가능합니다. 하지만 강의에서는 CPU 외에 메트릭은 오토스케일을 할 때 필요한 값으로 적당하지 않아 보통 CPU 사용률의 메트릭 정보를 파드를 스케일을 할지 말지 정하는 기준이 됩니다. 빠른 스케일 아웃 방지: Behavior 설정빠른 스케일 다운 방지: scaleDown의 stabilizationWindowSeconds HPA의 역할에도 엉청난 트래픽이 몰릴 때는 파드들이 시작 도중에도 트래픽이 발생함으로 부하로 인해 장애가 날 수도 있다. 따라서 사전에 트래픽이 몰리는 시점에 미리 리소스들을 생성해 놓는 등의 조치가 추가적으로 필요한 경우가 있다. ✏정리2주차 에는 많은 오브젝트들을 배웠는데데브옵스 부서에서 일하게 된다면 오브젝트들을 Probe로 각 파드를(앱 로딩 -> 지속적으로 앱 살아있는지 체크 -> DB등 내부 설정을 마무리 한 뒤 외부 트래픽 활성화) 단계 별로 헬스 체크를 하고ConfigMap/Secret을 통해 에플리케이션에 필요한 환경변수를 설정하고Deployment 를 통해 서비스별 회사의 상황에 맞게 배포 전략을 정하며HPA를 통해 트래픽에 변화에 맞춰 따라 리소스를 줄이거나 늘리는 설정으로 변칙적인 트래픽에 탄력적으로 대응이렇게 쓸거 같다! CKA 자격증은 땃었지만 겉할기 식으로 배운거 같다 몰랐던 내용들이 꽤 있다 😂 미션미션 중 트러블슈팅 등 기록으로 남길 내용은 미션 마감 전에 업데이트하겠습니다!
