제미나이 CLI(Gemini CLI)로 프로메테우스/그라파나 배포하기

9분

9시간 전

904

제미나이 CLI(Gemini CLI)는 터미널에서 인공지능 에이전트로 업무 효율성을 높일 수 있는 도구입니다.

앞선 글에서는 이러한 제미나이 CLI로 쿠버네티스를 관리하는 방법을 알아보았습니다. 이번에는 쿠버네티스 환경에서 가장 많이 쓰이는 프로메테우스(Prometheus)와 그라파나(Grafana)를 마찬가지 제미나이 CLI로 배포해 보도록 하겠습니다.

제미나이 CLI에 자연어로 프로메테우스와 그라파나 배포 요청하기

먼저 간단하게 프로메테우스와 그라파나를 배포하고, 두 서비스를 연동해 달라고 요청합니다.

Prompt | install prometheus and grafana and integration(or connection)

제미나이 CLI가 단계별 구성 방법에 대해서 설명합니다. 총 4단계입니다.

그대로 작업을 시키기 전, 수정이 필요한 부분이 보입니다.

2단계의 얼럿 매니저(Alertmanager)는 배포하지 않아도 됩니다. 제외해도 프로메테우스의 기본 동작에는 문제가 없기 때문입니다.

또한, 3단계에서는 프로메테우스가 로드밸런서(LoadBalancer)를 사용하길 원한다고 추가로 요청합니다.

Prompt |

2.I don't want to deploy Alertmanger and others are okay.
3.Prometheus use k8s loadbalaner

수정안을 받았는데, 하나 더 빠진 부분을 발견했습니다.

3단계 추가 요청으로 프로메테우스만 요청해서인지, 그라파나에 대한 적용이 빠졌습니다. 따라서 그라파나 역시 로드밸런서로 노출해 달라는 내용을 추가해 메시지를 보냅니다.

Prompt | 3.Grafana expose by k8s loadbalancer too

수정된 계획(Final Plan)이 원한 것과 같은지 검토했습니다. 해당 계획을 적용하도록 요청합니다.

Prompt | yes apply the plan

마지막으로 실제 수행될 첫 번째 명령을 확인합니다. 문제가 없다면 Yes, Allow once를 선택해 명령 실행을 허용합니다.

제미나이 CLI로 프로메테우스/그라파나 배포하기

제미나이 CLI가 첫 번째 명령과 관련된 helm update를 수행하겠다고 합니다. 내용을 확인하고, Yes, Allow once를 선택합니다.

helm update를 마치면, 이어서 ‘helm’을 통해 프로메테우스와 그라파나를 설치할 예정이라고 합니다. 마찬가지로 작업을 허가합니다.

곧바로 프로메테우스와 그라파나 설치 과정이 시작됩니다.

설치 과정 도중에는 확인 목적으로 아래와 같은 에러 메시지가 발생합니다. 다만, 시간이 지나면 정상적으로 진행되며, 설치 완료 메시지를 확인할 수 있습니다.

… 중략 …

마지막으로 nginx-deployment의 메트릭(metrics)을 프로메테우스가 정상적으로 수집할 수 있도록, 애너테이션(annotation)을 추가하는 명령을 진행한다고 합니다.

명령을 확인하고, Yes, Allow once를 선택했습니다.

이어지는 메시지로 해당 작업의 진행 과정과 완료 상태를 확인합니다.

마지막으로 프로메테우스와 그라파나가 로드밸런서(LoadBalancer)로 노출되었는지 직접 확인하겠습니다.

별도 터미널을 뛰워 k get svc 명령어를 입력하고 서비스의 상태를 확인합니다.

제미나이 CLI로 배포 과정의 오류 해결하기

하지만 문제가 있습니다. 어쩐 일인지 프로메테우스와 그라파나에 접속할 수가 없습니다.

프로메테우스와 그라파나에 무슨 문제가 있는지 제미나이 CLI에게 일단 물어봅니다.

Prompt | problem for prometheus-grafana?

AI가 현재 파드의 상태를 확인했습니다. 별다른 문제가 보이지 않는다고 합니다.

그래서 이번에는 로그를 분석해 달라고 요청합니다.

Prompt | I would like to analyze logs for it

AI가 로그를 분석해 보아도 서비스는 정상적으로 동작하고 있다고 보고합니다. 다만 로드밸런서에 문제가 있을 가능성이 있다며, kubectl port-forward를 사용해 보는 것이 어떨지 제안합니다.

… 중략 …

분석을 종합해 보면, 이번 문제는 아마도 외부로 노출된 포트와 내부 컨테이너에서 사용하는 포트가 서로 달라 발생한 것으로 보입니다.

따라서 포트를 변경해 달라고 요청합니다.

Prompt | prometheus and grafana port change

변경에 적합하게 제안된 포트를 확인했습니다. 빠른 변경을 위해 여전히 잘못된 응답(invalid response)을 받아 어려움을 겪고 있다는 것을 알려줍니다.

Prompt | yes currently invalid response

이제 포트 변경을 위한 명령어가 생성됩니다.

명령을 확인하고, Yes, Allow once를 선택해 수정해 달라고 합니다.

알아서 포트를 변경했다고 알려줍니다.

그러나 여전히 접속이 이루어지지 않습니다.

이번에는 프로메테우스와 그라파나가 모든 입력 신호를 받을 수 있도록, bind 0.0.0.0을 넣어달라고 제안합니다.

Prompt | put bind 0.0.0.0 for prometheus and grafana

이미 해당 옵션이 설정되어 있다고 합니다. AI는 연이어 서비스를 노드 포트(NodePort)로 변경해 볼 것을 제안합니다. 제안을 받아들여 포트를 변경해 달라고 합니다.

작업이 모두 끝난 다음 별도 터미널에서 k get po,svc 명령어로 변경 사항을 확인했습니다.

그렇게 변경한 노드 포트로 접속해 보니 프로메테우스와 그라파나를 제대로 확인할 수 있었습니다.

다만 이 상태로 마무리하기는 아쉬움이 남습니다. 노드 포트 방식으로 접속하는 것도 다소 번거로운 감이 있습니다.

그래서 노드 포트를 다시 로드밸런서로 변경해 달라고 요청합니다.

Prompt | Can I use loadbalancer for prometheus and grafana?

변경을 요청하니, 로드밸런서를 쓰려면 MetalLB와 같은 별도의 구성을 설치해야 한다고 합니다. 이미 현재 환경에 실리움(Cilium) 로드밸런서가 구성된 상태라고 AI에게 알려줍니다.

Prompt | Oh I use cilium loadbalancer

그러자 AI는 다시 실리움 구성을 해야한다고 답변합니다. 이에 해당 구성 역시 이미 되어 있다고 전달합니다.

Prompt | cilium configuration already applied

이제 별말 없이 로드밸런서로 변경하는 커맨드를 전달합니다. 확인하고 Yes, Allow once를 눌러 적용했습니다.

성공적으로 변경이 끝났습니다. 바뀐 프로메테우스와 그라파나의 접속 주소를 확인할 수 있습니다.

혹시 모르니 터미널에서도 k get po,svc 명령어로 다시 한번 확인합니다.

마지막으로 바뀐 주소에 접속해 프로메테우스와 그라파나가 정상적으로 동작하는지 확인합니다. 문제가 없습니다.

이렇게 간단한 배포 작업을 마쳤습니다.

생성된 헬름(helm) 차트의 자세한 내용은 더 봐야겠지만, 이번 과정에서는 문제 발생 부분까지 함께 포함하여 진행해 보았습니다. 의도적으로 실제 코드는 직접 보지 않았습니다. AI와 사람이 대화를 나누듯 진행하며 문제를 해결하고 배포하는 과정은 어떤지 보여드리고 싶었기 때문입니다.

마치며: 제미나이 CLI를 잘 쓰기 위해 알아야 하는 것

실제로 아무것도 미리 알 필요가 없습니다(라고들 이야기합니다.)

하지만, AI 도구를 써볼수록 개인적으로 얇고 넓게라도 기초 지식을 알아두는 것이 중요하다는 생각이 듭니다. 지금은 모두가 AI 자체 모델과 기술이 가진 다양한 형태, 그리고 그 빠른 발전 속도에만 집중하고 있습니다. 그러나 일정 수준에 도달하면 마치 검색 엔진을 쓰는 것처럼 자연스럽게 AI가 개발자와 엔지니어의 일상으로 들어올 것입니다.

이때 중요한 것은 질문을 잘하는 방법, 그리고 AI가 제공하는 답을 잘 구분하는 능력입니다.

질문을 잘하는 방법은 사람과 소통하는 방식에 가깝습니다. 잘 정리하고 정돈된 질문이 좋은 답변을 이끌어 냅니다.

*제가 정리한 질문을 잘하기 위한 방법을 참고해도 좋습니다.

AI가 제공하는 답을 잘 구분하는 방법은 더욱 중요합니다. 그 답이 맞는지 또는 틀렸는지 판단하고 적용할지 여부를 결정해야 하기 때문입니다. 이러한 판단을 내리려면 그 분야에 대한 기초 지식이 필수입니다.

앞서 우리가 본 것처럼 AI는 좋은 분석과 제안을 할 수 있지만, 그 내용을 판단하고 적용 여부를 결정하는 역할은 오롯이 인간의 몫입니다. (또는 인간이 정의해 둔 워크플로우(workflow)에 의해 동작할 것입니다.) AI 기술이 앞으로 꾸준히 발전한다고 해도, 이 영역은 인간의 몫으로 남을 것입니다.

AI 도구가 발전하며 “아무것도 몰라도 된다”고들 말하지만, 오히려 더 많은 부분을 알아야 합니다. 그래야 판단할 수 있습니다. 또, 직접 수정하지 않더라도 수정을 제안할 수 있습니다.

물론 이러한 한계에도 AI는 개발 과정에서 매우 높은 생산성을 제공하는 도구입니다. 이를 적절히 활용하면 현재의 업무 생산성을 극도로 끌어올릴 수 있습니다. 그러니 지금 바로 적용하고 사용해 볼 것을 권장하고 싶습니다.

+사족이지만, 이처럼 AI를 터미널에서 사용할 수 있다면 K8SGPT가 설 자리는 없어질 듯합니다.

작가

조훈(CNCF 앰버서더)

시스템/네트워크 IT 벤더의 경험 이후, 메가존 GCP 클라우드 팀에서 쿠버네티스와 연관된 모든 프로젝트에 대한 Tech Advisor 및 Container Architecture Design을 제공하고 있다. 페이스북 ‘IT 인프라 엔지니어 그룹’의 운영진을 맡고 있으며, 오픈 소스 컨트리뷰터로도 활동한다. 지식 공유를 위해 인프런/유데미에서 앤서블 및 쿠버네티스에 관한 강의를 하기도 한다. 책 <컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커> 등 3권을 썼다. CNCF(Cloud Native Computing Foundation) 앰버서더로서 쿠버네티스 생태계가 더 활발하게 퍼질 수 있도록 기여하고 있다.

심근우

LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.

문성주

체커(CHEQUER) 사의 DevOps Engineer로서 쿠버네티스의 멀티 클러스터 관리 방법론과 쿠버네티스 구현체(CAPI, OCI)에 대한 명세와 컨테이너 리소스 격리 방법에 대한 연구를 병행하고 있다. 이런 연구 활동을 기반으로 쿠버네티스 볼륨 테스트 파트에 컨트리뷰션했다. 본업은 쿠버네티스 오퍼레이터와 같은 CRD(커스텀 리소스)를 개발해 현업에서 쿠버네티스를 좀 더 편리하게 사용할 수 있도록 돕는 일이다. 또한, 페이스북 그룹 ‘코딩이랑 무관합니다만'과 ‘IT 인프라 엔지니어 그룹'의 운영진을 맡고 있다.

이성민

미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.