백엔드 전반에 대한 구축과 EKS 클러스터 환경에 대한 관리를 하다 프로젝트가 끝이 났다.
프로젝트 중 궁금했던 것에 대한 질의 응답과 회고에 대해 짧게 적어본다 🔥
질의 응답
질의 응답은 카카오 클라우드 관련 직무에 계시는 개발자님과 멘토링 했던 내용으로 작성했다.
모든 질문은 내가 궁금했던 것들을 적어둔 것이다.
죽은 pod는 정리해야 하는가?
pod를 띄우고 죽이고를 반복하다 보면 자동적으로 pod는 사라지게끔 클러스터가 관리하고 있음을 알 수 있다.
그러나 가끔 pod를 조회하면 evict 된 것들이 리스트 업되는 순간을 목격한 적이 있어 이런 궁금증이 생겼었다.
결론은 그럴 필요는 없다.
terminate라면 더욱 상관 없고 evict 같은 것은 pod가 node의 자원을 최대로 사용하려는 시도 때문에 발생하는 것이라고 한다.
그리고 이를 방지하기 위해 resuorce requet/limit 설정이 필수라 한다.
- request : 해당 pod가 사용하는 최소 메모리 값 명시
- limit : 해당 pod가 사용하는 최대 메모리 값 명시
백엔드 환경의 env 파일 관리법?
env 파일을 git에 커밋하면 안되기 때문에 불편한 점이 많았었다.
실무에서는 이를 어떻게 해결하는지 궁금했다.
회사 실무마다 다 다를 것이라고 한다.
git, jenking 같은 곳에서 환경 변수를 관리할 수 있을 것이다.
그러나 이는 수정을 해야 할 때 어려움이 있을 수 있다.
개발자님께서는 valut server를 통해 환경 변수를 관리하고 해당 서버에 API 요청을 통해 값을 받아온다고 얘기했다.
실제로 구현도 굉장히 쉬울 것이라고 한다.
클러스터 내 pod의 기본 배포는 rolling update인데 실무도 같은지?
롤링 업데이트를 왜 하는지 여쭤 보셨고 실무도 똑같이 한다고 답했다.
다만 몇 개를 죽이고 업데이트할지 정할 수 있다고 한다.
고가용성이 중요한 서비스는 [1개 죽이고 업데이트하기] or [1개 생성하고 죽이기] 이런식으로 할 수 있다고 한다.
CD 파이프라인에 대해
CI와 CD는 분명하게 분리되는 것이 좋다.
코드의 모든 변경이 CD에 포함되는 것은 맞지 않기 때문이다.
버전에 대한 배포만 이루어져야 한다.
예를 들어 argo가 git의 특정 파일을 감지해서 해당 파일의 버전 변경이 발생했을 때 CD가 진행되게끔 하는 것이 좋다.
프로젝트 회고
한 줄로 표현하면 아쉬움이 정말 많이 남은 시간이었다.
모든 것을 털어놓을 수는 없으니 의미있는 얘기만 해보자면...
나는 팀원과의 소통을 적극적으로 한 것 같다.
팀의 리더 그리고 k8s팀 내에서 같이 협업한 동료와 적극적으로 소통을 시도했었다.
Terraform을 사용하지 못한 것이 아쉽다.
다른 팀은 잘 활용한 것 같고 또 채용 공고를 보니 이런 경험이 필수인 곳이 많이 보였다.
private 환경에 있는 서비스를 노출해야 하니 ingress/LB/Nodeport의 중요성을 제대로 느끼는 시간이었다.
이전까지 public 환경을 주로 다뤄 저런 것들의 중요성을 크게 느끼지 못했는데 이번에 부딪혀 보며 왜 필요한지 제대로 알 수 있었다.
프로젝트를 하며 못하고 아쉬웠던 내용들을 보충해 나가야겠다.
Terraform, CI/CD, ingress 등 다양한 기술에 대해 사용하고 글로 남겨 보겠다.
30년을 살면서 스스로를 follower(팔로워) 타입이라 생각했는데 난 leader(리더) 타입인 것 같다.
작년 프로젝트에서 리더를 맡아 팀과 프로젝트 모두를 성공적으로 이끌었고
이번 프로젝트에서 팀원의 자리에서 무기력함과 리더에 대한 아쉬움을 느끼는 시간이었다.
무엇보다 개인주의를 좋아하지만 팀을 이끄는 능력이 출중하기에
사람들을 많이 만나며 좋은 네트워크를 가꿔 나가야겠다.
좋은 경험이었다 CodeMind 🤣
