팀으로 변경후, 배포을 하면서 에러가 정말 많이 났다.
사내 메신저에 본부장님께서 본부 전체를 아침에 전부 호출 시켰다.
일단 앞 내용은 제가 지각을 해서 듣지 못했습니다.
간단하게 말하면, "모든 팀이 도와줘서 에러가 나지않게 해보자"
그때 좋은 의견에 대해서 물어봤지만, 솔직히 답변이 나오지 않았다.
gitlab branch는 main에 관리 안되고, 스테이징에서는 파이썬에 wsgi만 바꿔주면 실행이 되었는데, 운영은 아피치를 재시작해야 한다.
php 관리는 소스 위치는 스테이징과 상이한 부분도 있다.
가맹점에서 문제가 발생시, 롤백을 해야하는데 쉽지가 않다.
당연히 Jenkins나 gitlab runner의 방법도 있지만, 다른 신박한 방법이 있는지 알기 위해 쿠버네티스 밋업에 참여를 하게 되었다.
코드가 없으니, 스크롤로 천천히 내리면서 봐주세요~
구글 코리아서 밋업이 진행되었고, 외국인들도 있어 많이 당황했다.
싱가포르에서 오신 F5 Nginx 엔지니어분께서 발표를 하는데 영어로 처음에 운을 띄웠다.
5분정도 발표를 하다가 발표자분도 이상함을 감지했는지 한국어로 말할까요? 라고 질문해서 네 라고 바로 답을 했다.
IDC 환경에서는 맨위에 있는 로드밸런서는 사용을 하는 곳도 있고 없는 곳도 있는 L7 스위치이다.
흔히, URL, Method, queryParam으로 지정한 뒷단 로드밸러서로 변경을 해준다.
nginx 나 DB 위에 로드밸런서의 역할은 동일한 기능의 서버의 트래픽을 분활 시켜주는것으로 이해를 할 수 있다.
만약에, 쿠버네티스 환경이 되게 된다면, 클라이언트의 제일 처음 만나는 L7 로드밸런서는 Ingress 명칭으로 같은 역할을 하게 된다.
L4 스위치 역할은 서비스라는 이름으로 사용하게 되는 환경을 제공해주는게 쿠버네티스이다.
만약에, Ingress나 서비스를 실무에서 사용하게 되면 좀 더 복잡한 기능 및 확장성있는 구조로 짜고 싶은 마음이 들것이다.
그래서 나온것이 쿠버네티스 게이트웨이다.
쿠버네티스 게이트웨이 에이피아이을 사용하게 되면 기존에 Ingress 는 gateway로 변경이 되며, service는 위에 route 라는 개념이 한개더 생기면서 분기처야하는 조건들을 적는 역할을 하게 된다.
gateway로 바뀌면서 ingress에서 적용이 안되던 header값을 통한 분기나 Role기반(JWT, Basic) 같이 관리자, 사용자 인지를 구분할 수 있다.
또한, 인프라 영역과 클러스터 영역이 분리되면서 부서마다 관리할 수 있도록 수정이되었다.
인프라는 영역은 모니터링이나 아이디값을 관리하며, gateway는 nginx와 같은 protocol이나 Port 등을 관리하게 된다.
Nginx Gateway Fabric 을 사용하여 현대적인 쿠버네티스 환경을 만들어보는 예시를 보여줄려고한다.
기본 세팅은 minikube을 사용하여 구성을 해보았다.
kind cluster을 만들어준다.
kind create cluster --name nginx-gateway-cluster
간단하게, coffee, tea API를 만들어서 올리게 되면 아래와 같은 형태가 나오게 된다
그리고, nginx gateway Fabric 을 포트포워딩을 하여, 80 포트로 향하도록 설정을 해준다.
첫번째 예제는 Gateway 에서 url path를 통해 서비스를 분리하는 형태이다.
다른 예제로는 header 값이나, queryString 에 version에 따라 pod에 올라온 서비스로 분기 치기는 것도 가능하다.
다음 내용은 Kyverno을 이용한 쿠버네티스 관리를 위한 내용이다.
스마일게이트에서 발표를 해줬으며, 쿠버네티스를 사용하게 된 계기에 대해 얘기를 해주었다.
스마일게이트도 카카오와 같은 SK 데이터 센터를 사용을 하다 화재로 스토브 서비스가 모두 정지가 되어, 평소에는 IDC 환경 운영을 하다 DR 환경은 AWS로 돌릴 수 있는 환경을 구축을 하게 되었는데, 환경을 쉽게 맡추기위해 컨테이너 환경을 구성하게 되었다.
여기서 제일 힘든점은 IDC는 2~8개 트래픽을 분리할 수 있지만, AWS 환경은 평소에 1개의 인스턴스가 띄워 있다가 비상시에는 Iac로 여러 서버들이 구성되는 형태로 만들어져 있다.
어디에 배포하냐에 따라, helm을 실행하는 yaml이 조금씩 달라 지금까지 관리하였던 방법에 대해 발표를 해주었다.
처음 생각했던 방법은 kubernetes로 새로운 내용을 구성을 하게 되면 Admission Webhook으로 pod가 구성되기전에 설정값들이 환경에 맡게 설정이 되었는지 webhook으로 확인후 다음 설정을 진행하게 된다.
하지만, Admission Webhook 을 사용하게 된다면, 모든 어플리케이션 마다 python 으로 webhook을 만들어야 하는 단점이 생겨버렸다.
현재 서비스는 50개정도가 운영되고 있는데 우리는 개발자가 아니라, 엔지니어측에 속하여 어려움이 있었다. 그래서 도입하게 된것이
kyverno을 사용하는것이다.
Adminssion Controller을 사용할 수 있는것은 같지만, 파이프라인을 구축해주며, Webhook에 대한 것도 지원을 하며, Webhook을 python과 같은 언어로 작성하지 않아도 되며, yaml으로 작성이 가능하여 검증이 가능하게 되어, 엔지니어측에서는 환호하며 사용할만한 엔진이다.
스마일게이트 예시로는...
크게 검증하는 작업은 replocas 수 및 pinpoint agency 값 세팅과 같이 어플리케이션 마다 다른 값들을 설정하게 된다.
또한, CI/CD 에 대한 내용도 Webhooks을 전달후 진행 하도록 설정이 되어 있으며, gitlab runner와 연동하여 yaml lint와 CDN 영역 검증 작업등 진행을 하게 됩니다.
마지막으로 쿠버네티스가 이번년도에 10주년입니다.
이 글을 읽는 사람들은 한번은 알아주었으면 합니다.....
