-
질문 & 답변
카테고리
-
세부 분야
데브옵스 · 인프라
-
해결 여부
미해결
안녕하세요
24.03.08 03:34 작성 24.03.08 18:02 수정 조회수 124
0
질문 드립니다.
현재 4장에서 프로메테우스 스택 인스톨까지 진행하고나서
예전 질문에 답변주셨던 1장의 마리오 게임을 배포했던 부분과
4장의 Nginx 웹서버 배포를 복습하고 있습니다.
원클릭 -> 프로메테우스 스택 -> mario apply, nginx apply
마리오는 Service로/ nginx는 인그레스로 apply 하는데요 NLB와 ALB로 외부 노출해야하는 조건이나 이유가 있는건가요 앱에 따른 차이일까요?
프로메테우스 스택을 보면 하나의 ALB로 묶기 위한 그룹이 명시되어있는데 그룹으로 묶어서 ALB로 열어주는 kind: IngressClass 은 보이지 않습니다, helm install시 알아서 설치되는 건가요?
노드 익스포터가 포드로 배포되었기 때문에 노드에 존재하는 모든 앱의 메트릭 값을 자동으로 수집할 것이라고 생각했는데, nginx 파라미터 파일을 보면 metrics.enabled : true 소스가 있습니다. 각 앱을 apply 할때 metrics.enabled : true 값을 명시하는 것이 필수인 건가요?
metrics.enabled : true값이 필수라면 마리오 게임을 배포할 때 metrics.enabled : true 값이 없었으므로 메트릭 값이 수집 되지 않는 건가요? 추가해야 할까요?
4장의 nginx 파라미터 파일에 spec 소스를 추가 작성하면 도커허브의 html파일을 가져와서 배포할 수 있을까요?
nginx배포시 레플리카 부분이 명시되어 있지 않아 1개의 포드만 생성될 것이라 예상했고, kubeops를 확인하니 실제로 1개만 배포되었습니다. 하지만 kubectl get pods 명령어 확인하니 nginx 2/2 ready 상태입니다.
부하발생 실습 부분에서 레플리카를 늘려서도 시험해 보고 싶어서 helm upgrade nginx bitnami/nginx --version 14.1.0 -f nginx-values.yaml --set replicas=2 명령어를 사용했는데요, 업그레이드 됐다는 메시지는 출력 되는데 포드의 변화가 없습니다 어떻게 하면 될까요?
NGINX 모니터링 대시보드 : 12708 사용,
while true; do curl -s https://nginx.$MyDomain -I | head -n 1; date; sleep 1; done명령어 입력 후 3분 뒤 초록색 GO 사라지고 빨간색 NO DATA 출력, 모든 그래프 사라짐 -> Home Dashboards Kubernetes / Compute Resources / Namespace (Pods)에서 모니터링 네임스페이스 확인해보니 메모리 사용부분 1400% 찍혀있는데 서버 다운된건가요? 인스턴스 스케일업 해야하는건가요? t3미디엄입니다. - 만약 맞다면 추후 HPA나 CA를 통해 해결이 가능할까요?
앱 배포시 프로메테우스 target에 nginx 잡히는 것은 확인했습니다. 실제로 부하를 줄 시 프로메테우스에서 부터 수집되는 메트릭 값을 확인해 보고 싶고 -> 그 값이 실제로 그라파나에 동일한 값이 출력되는지 확인해보고 싶습니다. 하지만 현재 프로메테우스에서는 어떻게 확인하는지 모르겠고, 그라파나에서는 No Data로 오류발생입니다
답변을 작성해보세요.
0
Ongja_CloudNet@
지식공유자2024.03.10
안녕하세요. CloudNet@ 팀입니다.
많은 질문을 주셨는데요. 내용 확인 후 답변드립니다.
1. 서비스의 용도나 상황에 따라 로드밸런서 유형을 선택합니다. L4 영역의 정보를 확인해서 분산 처리한다면 NLB를 L7 영역까지 본다면 ALB로 지정해야겠네요.
참고로 nginx는 앞서 배포한 프로메티우스와 그라파나와 동일한 로드밸런서(ALB)를 사용합니다. L7 영역의 제어가 가능해서 http 해더 정보를 확인하고 대상을 전달하도록 처리한 것이죠.
2. helm 차트에서 프로메테우스 스택을 배포할 때 Value에 ingress를 정의해서 배포하고 있습니다.
3. metrics.enabled=true는 helm 차트로 배포 시 메트릭을 노출하는 옵션입니다. 메트릭을 노출하기 위해 모든 환경에서 해당 옵션을 부여하는 것은 아닙니다.
annotation을 통해 프로메테우스 대상을 자동으로 감지하게 하거나 프로메우스 오퍼레이터를 사용한다면 ServiceMonitor나 PodMonitor를 생성해 파드의 메트릭 값을 수집하도록 선언할 수도 있습니다. 또한 프로메테우스 설정 파일에서 수동으로 대상 타겟을 추가하도록 선언할 수도 있습니다.
4. 마리오 게임 배포는 helm 차트를 통한 배포가 아니어서 해당 옵션을 지정할 수 없겠네요. 다른 방식으로 메트릭을 노출하도록 정의해야 합니다.
현재 마리오 게임 배포는 게임 서비스를 위한 컨테이너만 정의되고 메트릭 노출에 대한 컨테이너가 존재하지 않습니다. 어떠한 형태든지 메트릭을 노출하는 exporter가 동작해야 해당 정보를 수집해서 프로메테우스에 출력하겠네요.
메트릭을 노출하는 로직은 개발자가 직접 관리해야 합니다. 이는 게임 서버나 애플리케이션 코드 내에서 프로메테우스 호환 메트릭 엔드포인트를 구현하거나, 적절한 메트릭 exporter를 파드에 추가하는 방식으로 이루어질 수 있습니다. 현재 마리오 게임은 어떠한 형태로 구성된 것이지 알 수 없어 대처가 어렵네요;;
5. helm 차트의 파라미터 파일(values.yaml)에 직접적으로 Docker 이미지의 소스를 추가하는 것은 지원되지 않습니다. 대신, Docker 이미지를 빌드하고, 그 이미지를 참조하여 helm 차트로 배포하는 과정을 거칩니다.
6. 대상 파드에서 표현되는 READY 2/2의 의미는 해당 파드에서 동작하는 컨테이너 수를 표현합니다.
kubectl describe pod 명령을 수행하면 Containers 영역에 nginx와 metics 2개의 컨테이너가 보일 것입니다. 각 컨테이너 용도는 예상되시겠죠?
7. 해당 nginx-value.yaml에 옵션 인자 값이 잘못된 것 같네요.
helm upgrade nginx bitnami/nginx --version 14.1.0 -f nginx-values.yaml --set replicaCount=2위와 같이 명령을 입력해 보세요.
8. 일단 증상이 재현되질 않습니다. 과도한 부하가 발생한 것으로 보이는데 이때 오토스케일을 통해 스케일링을 수행해야 겠지요.
9. 현재 테스트 용 nginx가 어떠한 메트릭을 노출하는지 알아둘 필요가 있습니다.
curl -s http://$NGINXIP:9113/metrics
nginx_connections_accepted 4262
nginx_connections_active 7
nginx_connections_handled 4262
nginx_connections_reading 0
nginx_connections_waiting 6
nginx_connections_writing 1
nginx_http_requests_total 4476
nginx_up 1
nginxexporter_build_info{arch="linux/amd64",commit="e4a6810d4f0b776f7fde37fea1d84e4c7284b72a",date="2022-09-07T21:09:51Z",dirty="false",go="go1.19",version="0.11.0"} 1현재 niginx 파드에서 노출하는 메트릭으로 대부분 http 세션 관련 메트릭 정보들로 부하에 따라 스케일링을 확인하는 요소는 없어보입니다. 즉 오토스케일링 용도의 테스트용으로 적합하지 않는 것이죠. 4번 답변과 비슷한 맥락으로 실제 해당 애플리케인션의 개발자 영역으로 제가 컨트롤할 수 없네요ㅠ
5장 실습에 해당하는 파드를 배포해서 테스트하시는 것이 좋을 것 같습니다.
감사합니다.
답변 1