개요
나는 토이 프로젝트에서 백엔드를 맡아서 진행하고 있었다. 그러다가 배포는 어떻게 하지?, 트래픽이 몰리면 어떻게 하지? (<= 현실: 나만 씀) 와 같은 다양한 고민들이 생겼고 결국 현재 온프레미스 로 쿠버네티스 를 배포하고 있다. 그래서 내가 만든 프로젝트 내용을 공유하려 한다.
쿠버네티스로의 이전
나는 4개월 전부터 아래의 그림을 직접 그리면서 쿠버네티스로의 마이그레이션을 꿈꿨다. (관련 블로그 링크)
쿠버네티스의 여러가지 장점이 탐났었다. ( 온프레미스 상에서도 CI / CD 가 자동으로 되게 하고 싶었고 트래픽, 로그도 더욱 간편하게 보고 싶었다. 덤으로 자동 인증서 갱신까지... ㄷㄷ!! )
그래서 아래와 같이 점진적으로 인프라를 개선했다.
- 우선
도커 강의를 통해도커를 익힌 뒤 앱을도커 이미지로 만들어 배포를 해보았고 - 이후
쿠버네티스 강의를 통해미니큐브를 통해쿠버네티스로 배포하였으며 - 그 다음에는
인터넷 검색등을 통해 익힌 뒤,다중 노드 쿠버네티스로 배포하였다.
참고로 Docker & Kubernetes : 실전 가이드 강의 를 들었는데 기초를 잡기에 매우 좋았다.
위처럼 개선하는 와중에 필요한 네트워크 지식은 아래의 책들을 참고하였다. 쿠버네티스를 알기 위해서는 네트워크에 대한 지식도 필요했다. 쿠버네티스도 결국 네트워크를 통해서 서로 통신하기 때문이다.
- 네트워크 관련 도움받은 책:
- TCP/IP 쉽게, 더 쉽게
- 매우 매우 도움을 많이 받았다. 이해가 쉽도록 그림으로 최대한 설명하려 한다. 특히 인증서를 이해하는데 도움을 많이 받았다.
- 그림으로 배우는 네트워크 원리
- 꽤 괜찮다. 다만 설명을 이해하기 어려운 부분도 있었다.
- TCP/IP 쉽게, 더 쉽게
개선 작업을 하는 도중마다 나 스스로 잊어버릴 것 같은 지식들은 블로그로 작성하였다.
그 외에 많은 삽질들이 있었다...
그리고... (결국?) 쿠버네티스로의 이전이 완료하였다.
그래서 어떤 게 좋아졌는데??
1. CI / CD 개선
argoCD 와 github actions 를 사용하여, 백엔드 코드가 변경되면 자동으로 변경내용이 서버에 반영되도록 하였다. 이제는 백엔드 코드가 변경된다고 직접 서버를 껐다 킬 필요가 없게 되었다. 다운 타임이 거의 사라진 것은 덤이다.
2. 트래픽 처리 능력 향상
이제 서버의 트래픽을 각각의 서버가 분산하기에 사용자의 더 많은 트래픽을 받을 수 있게 되었다.
3. 일관된 환경 구축
argoCD 와 Kustomize 를 활용해 동일한 프로젝트 리소스들을 하나의 커맨드로 손쉽게 생성/제거할 수 있게 되었다.
4. 쿠버네티스 생태계 진입
쿠버네티스 생태계는 굉장히 잘 구성되어 있다. 이러한 생태계와 연결되어, 로그를 손쉽게 보는 도구, 그리고 메트릭을 손쉽게 확인하는 도구 등을 사용할 수 있다. 아직 제대로 적용해보진 못했지만 꾸준히 해볼 생각이다.
프로젝트 구조
서버 하드웨어 는 노트북 3대로 구성하였다.
인프라 스펙
| Role | OS | Memory | CPU | SSD |
|---|---|---|---|---|
| Master Node | Ubuntu 20.04 | 16GB | 2.6 Ghz | 256 Gi |
| Worker Node | Ubuntu 22.04 | 32GB | 2.9 Ghz | 256 Gi |
| Worker Node | Ubuntu 22.04 | 32GB | 2.9 Ghz | 256 Gi |
쿠버네티스는 어플리케이션 관점과 인프라 관점으로 나눌 수 있을 것 같다.
🔸 애플리케이션 관점
우선 애플리케이션 관점에서는 리소스가 어떤 노드에 위치해 있는 지 보다는 어떤 리소스가 어떤 리소스와 관련있는 지에 대해서 볼 수 있다.
아래는 나의 ArgoCD 화면이다.
Ingress, Deployment, PV, PVC 등의 리소스들이 사용되었다.
우선 사용자 가 Ingress Contoller 를 통해 접속한다. (만약 http 로 접속하였다면 https 로 다시 리다이렉트를 진행한다.)
Ingress Contoller 에서는 사용자가 접속한 URL 에 맞게 서비스로 라우팅을 진행한다. 각각의 서비스 는 파드 들에게 로드밸런싱을 진행한다.
백엔드 Pod 는 외부 시스템 (MySQL 서버, NFS) 을 사용한다.
🔸 인프라 운용 관점
다음은 인프라 관점에서 바라본 상황이다. 쿠버네티스가 내 프로젝트에서 어떤 식으로 통신을 하고 있는 지에 대한 내용이다.
위의 그림에 번호를 매겼다. 관련 번호에 대한 설명이다.
1 번 : GitOps 를 적용하였다.
- 개발자가
Source Repo에Push하면Github Actions에서 빌드를 진행하고도커 허브에 이미지를 저장하며GitOps Repo에 해당 이미지의 태그를 업데이트한다.ArgoCD는 변경점을 확인하여 자동으로Cluster의 리소스를GitOps Repo에 맞게 클러스터에 반영한다.
2 번 : 사용자 는 Ingress Controller 를 통해 접속한다.
3 번 : 인프라 엔지니어 는 kubectl 등을 통해 클러스터 를 직접 운용 / 관리를 진행할 수 있다.
4 번 : 각 Node 끼리 통신한다. Kubelet 은 리소스 스케쥴 관리를 담당하며 Kube-Proxy 는 노드 간 통신 을 담당한다.
프로젝트 링크
🔸 프로젝트 웹 사이트
쿠버네티스로 배포중인 웹 사이트입니다. 블로그의 기능을 가지고 있습니다.
🔸 ArgoCD
argoCD 를 통해 쿠버네티스 리소스를 관리하고 있다.
아래의 링크 와 아이디 를 통해 접속하여 직접 프로젝트 현황 을 확인해볼 수 있다.
링크: https://argocd.enttolog.shop/applications?showFavorites=false&proj=&sync=&autoSync=&health=&namespace=&cluster=&labels=아이디(읽기 전용)
ID: guestPWD: 게스트1!
🔸 그라파나
프로메테우스 로 얻은 프로젝트 의 Metric 정보를 통해 Metric (CPU, Memory etc) 등의 현황을 관리할 수 있다.
링크: https://gf.enttolog.shop/d/nginx/nginx-ingress-controller?orgId=1&refresh=5s아이디(읽기 전용)
ID: guestPWD: guest1!
🔸 프로메테우스
프로젝트 의 Metric 정보를 확인할 수 있습니다.
후기
장작 4개월 전부터 생각해왔던 것들을 결국 해냈다. 그렇지만 해놓고 보니 아직도 고민하고 처리해야되는 것들이 많이 쌓여 있었다. 뭐 하나 빠지지 않는 프로젝트를 만들고 싶었는데 생각보다 하다보면 해야될 게 참 많다. 이전에는 백엔드와 데브옵스 두가지를 다 하는 멋있는 나! 를 꿈꿨는데 제대로 이해하려면 하나만 하기도 참 빠듯하다는 걸 느끼고 있다. 특히 독학을 하고 있다보니 스스로를 조절하는 게 참 어려운 것 같다. 외롭기도 하고 그렇다. 그럼에도 꾸준히하면 길은 보인다는 생각으로 하루에 조금씩이라도 나아가려 한다. 잘 되어보자!!
