개요
나는 기존 온-프레미스 서버 에 쿠버네틱스 를 적용하였다. 이전에는 단순히 앱을 실행시키는 구조 로 동작하였는데, 이번에는 앱을 도커 이미지로 만들고 쿠버네틱스로 적용 한 것이다. 이번 글에서는 쿠버네틱스 를 적용함으로써 얻은 이점과 내가 설정한 쿠버네틱스 인프라 구조 를 설명하여 프로젝트 상태를 공유하려 한다.
프로젝트 결과물
🔸 배포 URL & 깃허브 링크
쿠버네틱스를 통해서 총 4개의 서비스를 배포하였다.
프론트엔드 : https://www.enttolog.shop
그라파나 : https://gf.enttolog.shop
프로메테우스 : https://pmt.enttolog.shop
벡앤드 : https://api.enttolog.shop
🔸 프로젝트 인프라 구조
아래의 그림이 현재의 아키텍쳐이다. CI / CD 를 제외하고 모두 구현이 되었다. (CI / CD 는 현재 개발 진행중인 상태이다.)
우선 TLS Secret 을 사용하여 HTTPS 인증서 를 Ingress Controller 단에서 전담하도록 하여 각각의 서비스가 직접 HTTPS 인증서 작업을 하지 않아도 되도록 하였다.
그리고 서비스를 총 4개를 두었는데, 각각 프론트엔드 , 백엔드 , 그라파나 (GUI) , 프로메테우스 (모니터링 정보 획득) 으로 구성되어 있다. 이를 통해 하나의 웹서비스에 필요한 구성을 구현하였다. 아직은 테스트 상태인지라 파드를 각각 하나씩만 두었다. 실무에서는 가용성을 위해서 최소 3개 이상을 두어야 할 것이다.
프론트 의 경우 리액트 프로젝트를 빌드하여 Nginx 도커 이미지 에 넣고 실행되도록 하였으며,
백엔드 의 경우 쿠버네틱스 외부의 MySQL 서버에 접근하도록 하고 그림 이미지 도 외부의 File Storage 와 마운트하여 읽기 / 쓰기 를 하도록 구현하였다.
또한 그라파나 와 프로메테우스 를 사용하여 모니터링 시스템을 구축하였다.
CI / CD 의 경우 현재 작업중에 있다. 깃허브 액션 을 통해 kubectl 로 변경을 시도하게 할 계획이다.
변경으로 얻은 이점
🔸 TLS 인증서 자동 갱신
TLS Secret 이 자동으로 인증서를 갱신시켜준다. 따라서 인증서 갱신을 개발자가 직접 해주지 않아도 된다.
🔸 대중적인 모니터링 시스템 구현
쿠버네틱스의 인그레스 컨트롤러 로부터 많은 메트릭 을 얻을 수 있는데 이를 프로메테우스 가 조회할 수 있고, 이를 그라파나 를 통해 시각화할 수 있기에 필요한 정보들을 손쉽게 확인할 수 있다.
아래는 그라파나로 얻은 내 프로젝트의 정보 이다.
🔸 CI / CD 의 용이함
쿠버네틱스 의 argoCD 를 이용하면 손쉽게 적용이 가능할 것으로 보인다. 다만 아직은 구현은 하지 못한 상태이다. argoCD 에 대해 파악하고 있는 단계이다.
🔸 도메인 기반 트래픽 분배 (로드 밸런서)
클라이언트 로부터 받은 요청을 도메인 기반 으로 서비스 에 라우팅할 수 있게 되었고, 서비스 가 파드 들에게 골고루 트래픽을 분배할 수 있는 환경이 조성되었다.
추가로 더 공부가 필요한 부분
argoCD를CI / CD를 적용하는 방법에 대해 알아보고 있다.미니큐브에서kubeadm으로 변경하는 것을 고려하고 있다. 아무래도미니큐브가 가상화이다보니 성능에 저하가 발생할 수 밖에 없고 단일 컴퓨터만 사용할 수 있어쿠버네틱스의 서버에게 균일하게 트래픽 분배함으로써 얻을 수 있는가용성을 얻지 못하는 점이 있어 변경을 고려하고 있다.
참고자료
