[ 인프런 워밍업 클럽 4기 Devops ] 4 주 차 발자국 (13일의 금요일 -안상민)

월 - Helm과 Kustomize 비교하며 사용-2화 - ArgoCD 빠르게 레벨업-1수 - ArgoCD 빠르게 레벨업-2목 - ArgoCD 빠르게 레벨업-3 이번주는 배포 자동화를 중점으로 배웠는데요.ArgoCD를 좀더 깊게 알아 볼 수 있어서 좋았습니다.블루 그린, 카나리 배포를 도와 주는 Rollout과이미지의 변경을 감지하여서 레파지토리에 자동으로 빌드 해주는 Image Updater그리고 ArgoCD 서버의 전체적인 구성과 제공하는 서비스들을 익힐 수 있었습니다. 특히 현업에서 사용될만한 비슷한 환경 구성 해보는 실습들이 있어전체적인 DevOps 업무들의 전체적인 흐름을 이해 할 수 있어서 좋았습니다. Sprint 3,4를 통해 더 배울 디테일들이 더 기대가 되네요! 칭찬하고 싶은 점드디어 끝까지 완주했네요! 자신에게 잘했다고 해주고 싶습니다.같이 커리큘럼 따라오신 분들 대단히 고생 많으셨습니다~!! 아쉬웠던 점음 개인에게 아쉬웠던 점은 잘 생각이 안나네요.이 과정이 벌써 끝나서 아쉽네요 ! Sprint 3,4도 같이 커리큘럼이 있으면 더 좋을거 같습니다. 보안해야 될 점이번에 블로깅을 아직 습관화를 하진 못했지만 예전에 다큐멘터리에서 어떤 뇌 과학자가 힘들더라도 딱 2달 정도 꾸준히 지속하면 내 습관으로 만들 수 있다는 이야기가 생각납니다. Sprint 3,4도 수강할 예정이고 다음 과정도 바쁘더라도 짬을 내서 복습 블로깅을 꼭 하려고 합니다! 그럼 딱 두달정도 되겠네요! 회고 그 과정이 끝난 후에도 인프런 발자국처럼 개인 블로그에 회고 형식으로 적어볼 생각입니다.발자국 지금 생각해 보는거지만 용어가 한글이여서 친숙하고 참 좋네요! 그리고 이번 커리 큘럼 감상평이라고 해야 할까요? 길지도 짧지도 않은 한달이였지만 주어진 기간동안 한주 한주 남긴 발자국들이 모여 의미 있는 발 자취가 되어서 뿌듯한 걸음들이 됬던거 같습니다.완주까지 잘 하신 분들 고생많으셨습니다!!못하신 분들이라도 결과 보다는 다음에 있을 비슷한 경험들을 통해 성장는 과정이 있는 러너분들이 되셨으면 좋겠습니다. 앞으로 마주할 과제들도 잘 마무리 시키는 과정을 통해서 보람도 느끼고 성장하셨으면 바랍니다! 응원하겠습니다~!! 보상들이나 격려의 말씀으로 완주를 독려해주신 일프로 강사님께도 감사합니다~!!

[ 인프런 워밍업 클럽 4기 Devops ] 3 주 차 발자국 (13일의 금요일 -안상민)

월 - 데브옵스 한방 정리화 - 손쉽게 데브옵스 환경을 구축하는 방법수 - 배포를 시작하기 전에 반드시 알아야 할 것들목 - Jenkins Pipeline (기초부터 Blue/Green 까지)A금 - Helm과 Kustomize 비교하며 사용-1 칭찬하고 싶은 점좋은 선생님을 만나 아직은 끝나진 않았지만 잘 마무리 할 수 있을것 같다는 느낌이 듭니다! 마라톤을 빗대어 말하자면 좋은 페이스 메이커가 만들어준 러닝 페이스를 잘 따라가고 있다는 생각이 들어 보람도 있고 잘하고 있다고 칭찬을 하고 싶네요. 아쉬웠던 점취준하면서 알바 하며 생활비를 충당하고 있는데 이번주에는 다음주 것 까지 마무리 지어 놓으려고 했었습니다만 못한것이 아쉽습니다. 그리고 이미 레퍼런스가 카페에 있는데 찾아 보지 않고 리눅스 커널이 뻗어버리는 버그를 혼자힘으로 해결 해보겠다고 이틀을 보낸게 영 도움이 되지 않은건 아니지만 시간을 잘 활용해서 쓰지 못했다는 생각이 들어 좀 아쉽네요. 보안해야 될 점버그나 에러가 발생했을 때 보통 수강생분들 환경에서 일어 나 듯이 우선 관련되어 있는 그룹에서 케이스를 찾아보거나 해당 커뮤니티에서 도움을 요청하려 합니다. 회고 저는 서른 초반입니다. 25세 때 처음으로 하프 마라톤을 해본적이 있습니다. 끝까지 완주해본 기억이 너무 뿌듯해서 아직까지 그 추억이 좋아서 지금까지 러닝을 해왔는데요. 일프로 강사님도 러너이시고 마라톤을 하신다고 하셔서 단방향이지만 그 이야기를 듣고 무척 내적 친밀감이 들었습니다. 그리고 이번 주를 회고를 하자면 벌써 이 과정도 75 프로나 왔네요.블로깅은 IT 업계를 들어오고 나서 복습이나 트러블 슈팅할 때 마다 정리해서 블로그 글로 게시하는 습관이 우리의 실력을 쌓는다고 종종 들어왔습니다.다음에 쓰일 때가 되서 까먹었다고 할지라도 아카이브 처럼 언제든지 쉽게 찾아 볼 수 있어서. 빠르게 다시 습득 할 수 있다고 귀에 익히 들어서 시작했지만 몇 일 못가고 지속하지 못한 기억들이 꽤 있는데,귀찮으면 잘 하지 않는 나를 잘아시는지 이번에 다시 그 중요성을 상기 시켜 주셔서 다시 블로그에 복습 글을 올리기 시작했습니다. 지인 추천을 받아 시작한 이 과정을 마라톤에 대입 해보자면 마치 페이스 메이커분을 잘 만났다는 생각이 듭니다. 좀 힘들어할 때 즈음 격려의 메세지로 힘을 주시는 것이 마라톤 대회 때 화이팅이라고 외쳐주시는 같은 마라톤 참가자 분들 서포터 분 처럼 많은 도움이 되었습니다. 마라톤이 장거리 스포츠인 만큼 전략도 필요한데 초반에 무리해서 달리면 후반가서 달리기 힘든데 이번주 수업도 추천해주시는 전략도 참 유익했던것 같습니다. DevOps 파이프 라인 수업도 1~4단계로 나눠서 처음부터 점점 복잡한 레벨로 올라가는 것이 처음 부터 뛰기 힘든 강도로 뛰는게 아니라 차근차근 천천히 뛰기 시작해서 점점 강도를 올리기는거 처럼 IT업계의 커리어도 안정적으로 늘려 나아가는데 있어 가장 좋은 방법론 이라 생각이 들었습니다. 남은 한주 마지막까지 화이팅 입니다! ※ 배운 내용 정리

[ 인프런 워밍업 클럽 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 자격증은 땃었지만 겉할기 식으로 배운거 같다 몰랐던 내용들이 꽤 있다 😂 미션미션 중 트러블슈팅 등 기록으로 남길 내용은 미션 마감 전에 업데이트하겠습니다!

[ 인프런 워밍업 클럽 4기 Devops ] 1 주차 발자국(13일의 금요일 -안상민)

강의 수강 내용월 - OT, Q & A화 - Sprint1 컨테이너 한방 정리수 - 무게감 있게 쿠버네티스 설치목 - 실무에서 느껴 본 쿠버네티스 정말 평한 이유금 - Object를 그려보며 쿠버네티스 이해 강의 칭찬하고 싶은 점칭찬하고 싶었던점 헤이해졌었지만 다시 마음 잡아 공부를 시작한거 복습 글을 모두 작성했던 것 칭찬하고 싶습니다.아쉬웠던 점필기로 그려봐서 나의 것으로 확실히 만들려 했는데 글이나 그림 그리는데 시간이 부족해서 다 하지 못했습니다.그리고 시간이 상당히 오래 걸려서 비효율적이였습니다.보안해야 될 점쓸데 없는데 힘 빼지 말고(그림이나 글 직접 그리거나 쓰기) 공부하는 시간 딱 집중해서 수업을 듣고 복습 내용 바로 정리 해서 글 올리기, 발자국을 일주일 다되서 작성하지 말고 복습 그날그날 하면서 회고 때 넣을 내용 생각날 때 적어두기(생각 이 안남) 미션 미션 해결 하는 과정VM & K8S 설치 스크립트 도중에 종료처음에 스크립트가 시간이 꽤나 오래 걸리는지 모르고 렉이 걸려서 안되는지 알았다. ctrl + c 로 중지하게 되었다.그랬더니 남아 있는 베이그란트 프로세스가 컴퓨터 관리자에 남아 있어서 vagrant up 명령이 듣지를 않았다.검색 후에 돌아가고 있는 vagrant 프로세스를 다 종료, VM 에 남아 있는 모든 vagrant 관련 디렉터리를 삭제 후에다시 설치 했더니 문제가 해결이 되었다. 프로메테우스 모니터링 보드 오류프로메테우스 모니터링 보드에 모든 데이터가 No data 로 되어 있어서 Locky 가 k8s 클러스터 상의 컴포넌트들의 메트릭스를 수집 못하고 있나해서 Locky를 삭제 후 다시 깔았다. But 증상은 똑같았고 프로메테우스와 Locky를 모두 삭제 후 다시 설치 했더니 정상적으로 K8s의 파드 디폴로이 먼트 등 컴포넌트들의 모니터링이 가능해졌다.