devops와 k8s(쿠버네티스) 강의 후기

github action을 활용한 기초적인 jar파일 자동 배포부터 devops수업이 시작되었다.
그 과정에서 aws의 기본적인 서비스인 ec2, rds, vpc와 보안그룹, 로드밸런서, iam 등을 활용해보았다.
 
docker를 배우면서 dockerhub에 이미지를 배포했고, ec2에 jar 배포가 아닌 이미지를 통한 컨테이너 배포도 진행하였다.
 
금주에는 주로 컨테이너 오케스트레이션 서비스인 쿠버네티스에 대해 학습했고, aws의 k8s서비스인 eks를 활용하여 배포실습을 진행하였다.
 
k8s는 크게는 클러스터 단위로 자원이 구분다. 클러스터내에 마스터노드를 만들고, 워커노드를 추가하여 클러스터를 구성하게 된다.
 
eks를 사용하게 되면 마스터노드를 별도로 구성할 필요 없이 주요 요소들이 클러스터 생성과 동시에 생성되고, 워커노드만 노드그룹을 추가하면 된다.
 
쿠버네티스에서 컨테이너를 구성하고 관리하기 위한 주요 요소로는 POD, DEPLOYMENT, SERVICE, CERTIFICATE, SECRETS 등이 있는데, 가장 기본적인 구성으로는 deployment를 통해 pod를 만들고, service를 통해 네트워크 구성을 하는 것이라 볼수 있겠다.
 
우리 수업에서는 ingress를 통해 외부 http 요청을 클러스터 내부의 service로 라우팅하게 하는 아키텍처를 사용하였다. ingress와 ingress컨트롤러를 구성하여, 특정 uri 패턴에 따라 특정 service로 라우팅하게 하였고, service마다 pod의 label이 select되어있어서 최종적으로 pod까지 요청이 도달하도록 라우팅하였다.
 
k8s는 로드밸런싱, 라우팅의 간결성과 편의성이 매우 높고 편리하다. 신규 서비스가 추가될경우 service와 depl 한 1set만 ingress에 추가하고, 트래픽에 따라 pod의 개수를 증가시킨다 하더라도 service에서 별다른 설정추가 없이 늘어난 pod로 로드밸런싱이 수행된다. 또한 컨테이너간 내부통신 또한 service명으로만 http 호출하면 해결되기에 매우 간결하다. 그리고, 무엇보다 선언적 자원관리로 인해 서버가 죽어서 장애가 발생하는 예상치 못한 상황이 현저히 줄어들게 되는 장점이 있다.
 
물론 k8s 환경구성 자체의 복잡도는 k8s의 단점이 될수가 있고, 서비스 자체가 단순하다면 k8s를 위한 클러스터 구성자체가 과한 엔지니어링이 되는 것은 단점이다.
 
그럼에도 k8s는 msa아키텍처에 매우 적합하고, 성장하고 있는 서비스에서 부하를 언제든 증가시킬수 있는 아키텍처이므로 수강생들이 언젠가 근무하게 될 회사에서 아키텍처를 구성해야 한다면 수업시간에 배운 쿠버네티스의 장단점을 떠올리고, 아키텍처의 선택지 중 하나로 놓고 고민해볼 수 있다면 좋을것 같다.
 
이번주에는 유독 불친절한 실습환경속에 수강생들이 불편함을 느꼈을수 있다고 생각한다. 다소 통제되지 못한 환경에서 실습의 진도가 안나가기도 했다. 그럼에도 잘 참아주고 여전히 열의를 가지고 실습에 참여해주고 열심히 공부해준 수강생들에게 감사함을 전하고 싶다.
 
그리고, 이번기회에 CI/CD 등 서버구성에 대한 설계와 구성에 대한 재미를 느낀 수강생들이 늘어나면 좋을것 같다. 이 작업은 java, spring을 이용한 프로그램 개발보다 디버깅도 어렵고, 논리적으로 예상한 결과가 나오는 통제성은 다소 떨어지지만, 오랜 삽질(?)끝에 상상했던 아키텍처가 완성되었을때 느껴지는 성취감도 큰편이다.
 
혹시나 추후 수강생들이 작은 스타트업에서 일하게 되면, 프로그램 개발부터 CI/CD까지 모두 담당하게 될 가능성이 높으니 이번 devops 프로젝트까지 잘 마무리 지으면서 개발부터 배포와 서버운영 까지 한 사이클을 직접 구성하고 개발해보는 것이 아주 좋은 경험이 될것 같다.