개요

---

나는 토이 프로젝트에서 백엔드를 맡아서 진행하고 있었다. 그러다가 배포는 어떻게 하지?, 트래픽이 몰리면 어떻게 하지? (<= 현실: 나만 씀) 와 같은 다양한 고민들이 생겼고 결국 현재 온프레미스 로 쿠버네티스 를 배포하고 있다. 그래서 내가 만든 프로젝트 내용을 공유하려 한다.

쿠버네티스로의 이전

나는 4개월 전부터 아래의 그림을 직접 그리면서 쿠버네티스로의 마이그레이션을 꿈꿨다. (관련 블로그 링크)
쿠버네티스의 여러가지 장점이 탐났었다. ( 온프레미스 상에서도 CI / CD 가 자동으로 되게 하고 싶었고 트래픽, 로그도 더욱 간편하게 보고 싶었다. 덤으로 자동 인증서 갱신까지... ㄷㄷ!! )

그래서 아래와 같이 점진적으로 인프라를 개선했다.

• 우선 도커 강의 를 통해 도커 를 익힌 뒤 앱을 도커 이미지 로 만들어 배포를 해보았고
• 이후 쿠버네티스 강의 를 통해 미니큐브 를 통해 쿠버네티스 로 배포하였으며
• 그 다음에는 인터넷 검색 등을 통해 익힌 뒤, 다중 노드 쿠버네티스 로 배포하였다.

참고로 Docker & Kubernetes : 실전 가이드 강의 를 들었는데 기초를 잡기에 매우 좋았다.

위처럼 개선하는 와중에 필요한 네트워크 지식은 아래의 책들을 참고하였다. 쿠버네티스를 알기 위해서는 네트워크에 대한 지식도 필요했다. 쿠버네티스도 결국 네트워크를 통해서 서로 통신하기 때문이다.

• 네트워크 관련 도움받은 책:
  • 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 는 노드 간 통신 을 담당한다.

프로젝트 링크

---

🔸 프로젝트 웹 사이트

쿠버네티스로 배포중인 웹 사이트입니다. 블로그의 기능을 가지고 있습니다.

링크 : https://www.enttolog.shop

🔸 ArgoCD

argoCD 를 통해 쿠버네티스 리소스를 관리하고 있다.

아래의 링크 와 아이디 를 통해 접속하여 직접 프로젝트 현황 을 확인해볼 수 있다.

• 링크 : https://argocd.enttolog.shop/applications?showFavorites=false&proj=&sync=&autoSync=&health=&namespace=&cluster=&labels=
• 아이디 (읽기 전용)
  • ID : guest
  • PWD : 게스트1!

🔸 그라파나

프로메테우스 로 얻은 프로젝트 의 Metric 정보를 통해 Metric (CPU, Memory etc) 등의 현황을 관리할 수 있다.

• 링크 : https://gf.enttolog.shop/d/nginx/nginx-ingress-controller?orgId=1&refresh=5s
• 아이디 (읽기 전용)
  • ID : guest
  • PWD : guest1!

🔸 프로메테우스

프로젝트 의 Metric 정보를 확인할 수 있습니다.

링크 : https://pmt.enttolog.shop

후기

---

장작 4개월 전부터 생각해왔던 것들을 결국 해냈다. 그렇지만 해놓고 보니 아직도 고민하고 처리해야되는 것들이 많이 쌓여 있었다. 뭐 하나 빠지지 않는 프로젝트를 만들고 싶었는데 생각보다 하다보면 해야될 게 참 많다. 이전에는 백엔드와 데브옵스 두가지를 다 하는 멋있는 나! 를 꿈꿨는데 제대로 이해하려면 하나만 하기도 참 빠듯하다는 걸 느끼고 있다. 특히 독학을 하고 있다보니 스스로를 조절하는 게 참 어려운 것 같다. 외롭기도 하고 그렇다. 그럼에도 꾸준히하면 길은 보인다는 생각으로 하루에 조금씩이라도 나아가려 한다. 잘 되어보자!!