강의 수강 일자 : 25.05.30 (금)
블로그 복습 일자 : 25.06.01 (일)

우선 강의를 시작하기 전에, 쿠버네티스를 사용하면서 주로 마주치게 될 카테고리들이 존재하고,
카테고리별로 어떤 App을 쓰는지, 어떤 역할을 하는 지 알려준다.

[개발]

개발 분야는 웹 서비스에 필요한 개발 도구들을 나열한 것이다.
DB, 메세징, 빌드, CI/CD 등 각각 어떤 소프트웨어를 주로 사용하는 지 알 수 있고, 개발부터 배포까지의 흐름을 따라가면 주로 사용할 소프트웨어들이다.

[오케스트레이션/매니징]

이 부분은 내가 잘 모르는 분야인데, IT서비스를 구축할 때, MSA(마이크로 서비스 구조)로 구축할 때 사용하면 좋은 기술들이라고 한다. 나중에 사용할 일이 있을 때 자세하게 기술해보겠다.

[플랫폼 / 런타임]

주로 배포 간 클라우드 서비스를 이용할 때 사용하게 될 기술들이다.

미션에서 설치했던 컨테이너 런타임, CNI 네트워크, 쿠버네티스들이 보이고, 클라우드 서비스로 유명한 AWS나 NCP도 보인다.

이번 블로그에서 그나마 자세하게 알아볼 카테고리는

[분석] 이다.

쿠버네티스를 사용하기 이전에는 큰 규모의 프로젝트를 생성하려면 개별로 모니터링 및 로깅 시스템을 구축해야 했다.

하지만 개발과 분석 시스템을 개별로 구현을 하려면 실제로 다음과 같은 문제들이 발생하게 된다.

개발을 하는 초창기에는 모니터링 시스템을 구축하기가 어려워 로우레벨에서 로그와 성능을 찾아보게 되고,
이후 모니터링 시스템이 오픈되어도 이미 익숙해진 로우레벨 방식을 사용하게 된다.

이러한 개발 시나리오로 인해 위 사진과 같이 개발과 모니터링 시스템이 엮일 수 밖에 없고, 개발을 편하게 하기 위해 모니터링 시스템을 만들었지만, 개발과 모니터링 방향성이 다르게 흘러가는 상황으로 바뀌게 된다. 심지어 개발이 진행되면서 App의 구현 범위도 상당히 바뀌게 되는데, 이를 모니터링하는 구조도 바꾸다보면 개발 프로젝트와 모니터링 시스템이 서로 다른 범위의 App을 가리키고 있을 수도 있다.

-> 그래서 쿠버네티스에서 지원되는 각종 모니터링 / 로깅 툴들을 이용하면,
인프라 환경을 구축하면서 개발 초기부터 곧바로 모니터링 시스템을 사용할 수 있고, App 범위가 바뀌어도 자동으로 툴에서 설정을 해주니 편리하게 개발에만 집중하고, 성능이 나오지 않을 때 분석 툴로 도움을 받는 구조가 된다.

아래 링크는 모니터링 툴을 설치해보고, 실제 내 쿠버네티스 파드들을 확인해볼 수 있다.

https://cafe.naver.com/f-e/cafes/30725715/articles/30?boardtype=L&menuid=13&referrerAllArticles=false&page=2

설치하게 되면 프로메테우스를 가상OS환경에 설치를 하고, 쿠버네티스 파드들을 분석할 수 있다.

실제 모니터링을 하는 예시 사진이 아래에 마련되어있다.

우리는 모니터링 기술 중 Grafana 툴을 사용해 Pod 성능을 확인할 수도 있고,

로깅 툴 중 Grafana Loki를 사용해 App이 실행될 때 출력되는 로그를 확인할 수도 있다.

쿠버네티스 대표기술들 사용해보기

기존에 설치했던 쿠버네티스 파드들을 통해 쿠버네티스 대표 기술들을 알아보려고 한다.

1. Traffic Routing

[root@k8s-master ~]# while true; do curl http://192.168.56.30:31221/hostname; sleep 2; echo ''; done;

master node 부분에 해당 코드를 입력하면 아래 사진과 같이 두 파드를 번갈아 가면서 트래픽을 보내주게 된다.
traffic routing은 App에 파드가 여러 개 일때 트래픽을 분산시켜주는 작업이다.

2. Self-Healing

[root@k8s-master ~]# curl 192.168.56.30:31221/memory-leak

코드는 App에 메모리 누수가 나도록 유도하는 코드이고, memory leak이 발생하면 파드 하나가 죽게 되고, 다시 쿠버네티스가 해당 파드를 자동으로 재시작하는 걸 사진으로 볼 수 있다.

이처럼 특정 오류로 인해 파드가 죽더라도 쿠버네티스가 감지해 죽은 파드를 재시작해주는 기능이 Self-Healing이다.

이로 인해 서비스를 안정적으로 운영할 수 있게 해준다.

3. AutoScaling

[root@k8s-master ~]# curl 192.168.56.30:31221/cpu-load

위 코드는 App에 부하를 주는 코드이다. 파드마다 CPU 사용량이 40% 이상이 되면 파드를 자동으로 늘려주는 스크립트가 구현되어있고, 이렇게 App의 파드들 만으로 기능이 어렵도록 성능에 무리를 주는 작업이 발생하면, 자동으로 파드들을 늘려주는 기능을 AutoScaling이라 한다.

시간이 지나고 부하가 떨어지면 자동으로 늘렸던 파드 개수를 조정도 해준다.

4. RollingUpdate

[root@k8s-master ~]# kubectl set image -n default deployment/app-1-2-2-1 app-1-2-2-1=1pro/app-update

위 코드는 파드를 업데이트 해주는 작업이다. 파드가 Running 중에 있을 때도 업데이트를 하게 될 때, 기존에 있던 파드들이 종료되지 않고, 파드가 새로 생성되고 정상 작동되는 걸 확인하면 기존 파드와 교체를 하는 방식이다.

위 기능을 통해 무중단 배포가 가능하게 된다.

정리

기존 쿠버네티스를 사용하지 않고, 서비스를 배포할 때 여러 App들을 VM환경에 구축하고,

추가로 App을 생성하려면 사람이 직접 왼쪽처럼 세팅을 다 해줘야 했는데,

쿠버네티스를 사용하면 이 세팅들이 자동으로 구성이 되도록 코드만 짜주면 추가로 파드를 구성하는게 문제가 없다.

이렇게 자동화된 덕분에 서비스를 구축하고 크기를 조정하는 과정이 수월해져 안정성이 더 높아졌다.

또한, 인프라 환경을 코드로 구현해 관리를 하게 되니,

인프라 History 관리를 Github를 통해 버전 관리하기 쉬워지고, 기존 작업의 추적도 가능해졌다.

또한 인프라 환경은 개발, 검증, 운영 환경으로 나누어 따로 환경을 구축해야 할 때, 그냥 코드 이름만 바꿔서 파일을 생성하면 환경별로 파일이 생성되니 반복 작업을 할 필요가 없어졌다.