EKS 모니터링, 로깅
March 2024 (2007 Words, 12 Minutes)
EKS Monitoring, Logging
Monitoring을 위해서는 컴퓨팅 리소스가 조금 필요하여 t3.xlarge를 이용한 노드그룹으로 프로비저닝을 진행합니다
# YAML 파일 다운로드
curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick3.yaml
# Cloudformation Provisioning
aws cloudformation deploy --template-file eks-oneclick3.yaml --stack-name myeks --parameter-overrides KeyName=kp-gasida SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 MyIamUserAccessKeyID=AKIA5... MyIamUserSecretAccessKey='CVNa2...' ClusterBaseName=myeks --region ap-northeast-2
학습에 앞서 기본 설정을 또 진행합니다
# default 네임스페이스 적용
kubectl ns default
# 노드 정보 확인 : t3.xlarge
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone
eksctl get iamidentitymapping --cluster myeks
# 노드 IP 확인 및 PrivateIP 변수 지정
N1=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a -o jsonpath={.items[0].status.addresses[0].address})
N2=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2b -o jsonpath={.items[0].status.addresses[0].address})
N3=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2c -o jsonpath={.items[0].status.addresses[0].address})
echo "export N1=$N1" >> /etc/profile
echo "export N2=$N2" >> /etc/profile
echo "export N3=$N3" >> /etc/profile
echo $N1, $N2, $N3
# 노드 보안그룹 ID 확인
NGSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ng1* --query "SecurityGroups[*].[GroupId]" --output text)
aws ec2 authorize-security-group-ingress --group-id $NGSGID --protocol '-1' --cidr 192.168.1.100/32
# 워커 노드 SSH 접속
for node in $N1 $N2 $N3; do ssh ec2-user@$node hostname; done
기타 Addon들 설치를 진행합니다
# ExternalDNS
MyDomain=aews.montkim.com
echo "export MyDomain=aews.montkim.com" >> /etc/profile
MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)
echo $MyDomain, $MyDnzHostedZoneId
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/aews/externaldns.yaml
MyDomain=$MyDomain MyDnzHostedZoneId=$MyDnzHostedZoneId envsubst < externaldns.yaml | kubectl apply -f -
# kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'
kubectl annotate service kube-ops-view -n kube-system "external-dns.alpha.kubernetes.io/hostname=kubeopsview.$MyDomain"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=1.5"
# AWS LB Controller
helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=$CLUSTER_NAME \
--set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller
# EBS csi driver 설치 확인
eksctl get addon --cluster ${CLUSTER_NAME}
kubectl get pod -n kube-system -l 'app in (ebs-csi-controller,ebs-csi-node)'
kubectl get csinodes
# gp3 스토리지 클래스 생성
kubectl get sc
kubectl apply -f https://raw.githubusercontent.com/gasida/PKOS/main/aews/gp3-sc.yaml
kubectl get sc
EKS Console
Iam 역할
EKS Cosole에 접속하면
세부 리소스들이나 네트워크 구조, 스토리지 등에 대한 정보를 자세히 확인 할 수 있습니다.
Logging
모든 로깅을 활성화 해보겠습니다.
aws eks update-cluster-config --region $AWS_DEFAULT_REGION --name $CLUSTER_NAME \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
# 로그 그룹 확인
aws logs describe-log-groups | jq
cloudwatch 로그 확인하기
https://console.aws.amazon.com/cloudwatch/home#logsV2:logs-insights
에서 확인이 가능합니다.
기본 쿼리뿐만아니라 원하는 양식에 맞는 쿼리가 가능합니다.
# EC2 Instance가 NodeNotReady 상태인 로그 검색
fields @timestamp, @message
| filter @message like /NodeNotReady/
| sort @timestamp desc
# kube-apiserver-audit 로그에서 userAgent 정렬해서 아래 4개 필드 정보 검색
fields userAgent, requestURI, @timestamp, @message
| filter @logStream ~= "kube-apiserver-audit"
| stats count(userAgent) as count by userAgent
| sort count desc
#
fields @timestamp, @message
| filter @logStream ~= "kube-scheduler"
| sort @timestamp desc
#
fields @timestamp, @message
| filter @logStream ~= "authenticator"
| sort @timestamp desc
#
fields @timestamp, @message
| filter @logStream ~= "kube-controller-manager"
| sort @timestamp desc
아직 비정상적인 유형의 데이터가 없기때문에, 정상적인 데이터를 조회해보겠습니다.
# EC2 Instance가 Ready 상태인 로그 검색
fields @timestamp, @message
| filter @message like /Ready/
| sort @timestamp desc
해당 결과들은 json 기반으로 당연히 aws cli로도 조회가 가능합니다.
위에서 조회했던 Ready 상태인 node 갯수 쿼리의 aws cli 버전입니다.
# CloudWatch Log Insight Query
aws logs get-query-results --query-id $(aws logs start-query \
--log-group-name '/aws/eks/myeks/cluster' \
--start-time `date -d "-1 hours" +%s` \
--end-time `date +%s` \
--query-string 'fields @timestamp, @message | filter @message like /Ready/ | sort @timestamp desc'\
| jq --raw-output '.queryId')
json 형태로 결과를 응답받아도 가시화가 안되면 알아보기가 꽤 힘드네요
다시 비활성화를 진행하겠습니다.
# EKS Control Plane 로깅(CloudWatch Logs) 비활성화
eksctl utils update-cluster-logging --cluster $CLUSTER_NAME --region $AWS_DEFAULT_REGION --disable-types all --approve
# 로그 그룹 삭제
aws logs delete-log-group --log-group-name /aws/eks/$CLUSTER_NAME/cluster
# NGINX 웹서버 배포
helm repo add bitnami https://charts.bitnami.com/bitnami
# 사용 리전의 인증서 ARN 확인
CERT_ARN=$(aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text)
echo $CERT_ARN
# 도메인 확인
echo $MyDomain
# 파라미터 파일 생성 : 인증서 ARN 지정하지 않아도 가능! 혹시 https 리스너 설정 안 될 경우 인증서 설정 추가(주석 제거)해서 배포 할 것
cat <<EOT > nginx-values.yaml
service:
type: NodePort
networkPolicy:
enabled: false
ingress:
enabled: true
ingressClassName: alb
hostname: nginx.$MyDomain
pathType: Prefix
path: /
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
#alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/load-balancer-name: $CLUSTER_NAME-ingress-alb
alb.ingress.kubernetes.io/group.name: study
alb.ingress.kubernetes.io/ssl-redirect: '443'
EOT
cat nginx-values.yaml | yh
# 배포
helm install nginx bitnami/nginx --version 15.14.0 -f nginx-values.yaml
# 확인
kubectl get ingress,deploy,svc,ep nginx
kubectl get targetgroupbindings # ALB TG 확인
# 접속 주소 확인 및 접속
echo -e "Nginx WebServer URL = https://nginx.$MyDomain"
curl -s https://nginx.$MyDomain
kubectl logs deploy/nginx -f
## 외부에서는 접속이 잘되나, myeks EC2에서 url 접속이 잘 되지 않을 경우 : 이전 aws DNS cache 영향(추정)
dig +short nginx.$MyDomain
dig +short nginx.$MyDomain @192.168.0.2
dig +short nginx.$MyDomain @1.1.1.1
dig +short nginx.$MyDomain @8.8.8.8
cat /etc/resolv.conf
sed -i "s/^nameserver 192.168.0.2/nameserver 1.1.1.1/g" /etc/resolv.conf
cat /etc/resolv.conf
dig +short nginx.$MyDomain
dig +short nginx.$MyDomain @8.8.8.8
dig +short nginx.$MyDomain @192.168.0.2
curl -s https://nginx.$MyDomain
----
# 반복 접속
while true; do curl -s https://nginx.$MyDomain -I | head -n 1; date; sleep 1; done
# (참고) 삭제 시
helm uninstall nginx
접속로그
해당 로그는 다음과 같은 경로에 남는데, kubernetes에서 컨테이너의 로그는 kubelet-config에서 default로 10Mi 만큼만 설정이 되어있습니다.
온프레미스 클러스터 기준으로 해당 kubelet config 파일이 조회가 잘 되지만,
EKS에서 생성한 클러스터의 경우 노드에서 직접적인 kubelet을 관리할수는 없지만, eksctl로 생성한 클러스터이기때문에
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: <cluster-name>
region: eu-central-1
nodeGroups:
- name: worker-spot-containerd-large-log
labels: { instance-type: spot }
instanceType: t3.large
minSize: 2
maxSize: 30
desiredCapacity: 2
amiFamily: AmazonLinux2
containerRuntime: containerd
availabilityZones: ["eu-central-1a", "eu-central-1b", "eu-central-1c"]
kubeletExtraConfig:
containerLogMaxSize: "500Mi"
containerLogMaxFiles: 5
nodegroup의 kubelet ExtraConfig을 이용해서 수정을 진행해줘야합니다.
별도로 기존의 nodegroup에서 kubelet Extraconfig 만 patch를 진행하는 방법을 찾아보았지만, 해당 기능은 지원되지않아 직접 nodegroup에 대해서 변경점을 진행해야할것같습니다.
CCI와 Fluentbit for EKS 를 이용한 Pod Logging
CloudWatch Container Insight : 노드에 CW Agent 파드를 배포하여 Metrics를 수집합니다.
컨테이너형 어플리케이션, 마이크로 서비스에 대한 모니터링, 트러블슈팅 및 알람을 위한 “완전 관리형 관측 서비스”
cloudwatch 콘솔에서 container metrics, prometheus metrics, application logs 및 performance event를 탐색, 분석 및 시각화 할 수 있습니다.
Fluentbit 컨테이너를 각 노드마다 Daemonset 형태로 배포해
- Container/Pod 로그
- Node 로그
- Kubernetes Dataplane 로그
등을 수집합니다. 저번 게시글에서 인스턴스스토어를 활용한 노드그룹을 만들었을때도
/var/lib/containerd 디렉토리만 해당 디렉토리만 인스턴스스토어의 디렉토리를 마운트 시켰던 이유도, 노드에서 추가적으로 수집해야할 데이터들을 Hostpath형태로 수집할 수 있기때문에 남겼습니다.
CCI 설치
aws eks create-addon --cluster-name $CLUSTER_NAME --addon-name amazon-cloudwatch-observability
# cloudwatch-agent 설정 확인
kubectl describe cm cloudwatch-agent-agent -n amazon-cloudwatch
# Fluent Bit 로그 설정
kubectl describe cm fluent-bit-config -n amazon-cloudwatch
application-log.conf:
----
[INPUT]
Name tail
Tag application.*
Exclude_Path /var/log/containers/cloudwatch-agent*, /var/log/containers/fluent-bit*, /var/log/containers/aws-node*, /var/log/containers/kube-proxy*
Path /var/log/containers/*.log
multiline.parser docker, cri
DB /var/fluent-bit/state/flb_container.db
Mem_Buf_Limit 50MB
Skip_Long_Lines On
Refresh_Interval 10
Rotate_Wait 30
storage.type filesystem
Read_from_Head ${READ_FROM_HEAD}
[FILTER]
Name kubernetes
Match application.*
Kube_URL https://kubernetes.default.svc:443
Kube_Tag_Prefix application.var.log.containers.
Merge_Log On
Merge_Log_Key log_processed
K8S-Logging.Parser On
K8S-Logging.Exclude Off
Labels Off
Annotations Off
Use_Kubelet On
Kubelet_Port 10250
Buffer_Size 0
[OUTPUT]
Name cloudwatch_logs
Match application.*
region ${AWS_REGION}
log_group_name /aws/containerinsights/${CLUSTER_NAME}/application
log_stream_prefix ${HOST_NAME}-
auto_create_group true
extra_user_agent container-insights
Fluentbit의 파싱설정입니다.
개인적으로 마이크로 서비스를 개발하여 EFK로 수집하려 하는데 컨테이너 로그 파싱하는 것과 동일합니다.
Fluentbit는 hostpath로 컨테이너로그가 노드에서 수집되는것을 직접 확인하여 패턴에 맞게 가공합니다.
기존에는 Fluentbit에서 /var/run/docker.sock을 hostpath로 마운트해서 취약점으로 지적될만한 부분이 존재 했던것 같습니다.
현재는 마운트 구조가 변경되었으며, securityContext에서도 별도의 권한이 없어 아마 해당 fluentbit pod가 권한이 탈취되는 경우의 수가 크게 발생하지는 않겠지만, 언제나 최소권한의 원칙을 만족해야하기때문에 더 나은 파일구조를 볼 수 있다면 좋을거같습니다.
해당 로깅은 CloudWatch에 수집되는것을 확인할 수 있습니다.
아까 띄웠던 nginx pod에 대해서 반복접속을 통해 nginx 로그를 모니터링해보겠습니다.
# 부하 발생
curl -s https://nginx.$MyDomain
yum install -y httpd
ab -c 500 -n 30000 https://nginx.$MyDomain/
# 파드 직접 로그 모니터링
kubectl logs deploy/nginx -f
Metric Server
metric server는 kubelet으로부터 수집한 리소스 메트릭을 수집/집계하는 애드온입니다.
https://kubernetes.io/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/
다음과 같은 구조로 이루어져있으며 설치를할경우 kubectl 명령어로도 cpu / memory metric에 대한 모니터링이 이루어집니다.
# 배포
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
Webhook 알림받기
알림 웹훅 소스들이 많이있지만, 입맛에 맞게 구성을하려고 최근에 구성하던 소스코드를 조금 공개해봤습니다.
https://github.com/idoyo7/event-monitor/tree/main
그중 가장 기본인 kubernetes 의 event 기준으로 webhook을 날리는 구조로 이루어져있고
webhook은 slack이 아닌 teams 기준으로 프로그래밍 되어있지만 동일한 구조로 날라갈거라 믿어 의심치 않습니다.
tree
clusterrolebinding으로 클러스터에 발생되는 이벤트들을 모니터링해서 특정 조건에 맞게 pending이 이루어질때 웹훅주소로 웹훅을 발송해주는 녀석입니다.
if event.Reason == "FailedScheduling" && strings.Contains(event.Message, "Insufficient cpu") {
현재는 CPU가 부족해 “Failed Scheduling” 이벤트가 발생될때, 이벤트의 내용중 insufficient cpu 가 같이 들어있을경우 웹훅을 보내줍니다.
추후에 필요한만큼 RBAC을 부여하여 kubernetes에 API 요청을 통해 원하는 리소스 컨트롤리 가능합니다.
주어진 오픈소스 외에도 필요한 기능을 직접 구현해야한다면 코드로 작성하여 연동된 작업들을 진행할수있지않을까 싶네요.
수많은 addon들과 연동하여 유동적으로 쿠버네티스 클러스터에 일어나는 이벤트 기반의 확장이 가능해집니다.
Kube-Prometheus-Stack
프로메테우스, 그라파나 및 Alertmanager까지 원클릭으로 설치가 가능하게 해주는 helm chart 이름입니다.
개인적으로 생각하는 “인프라 모니터링” 영역에서 꽤나 간편한 오픈소스로 이루어져 있고, 오픈소스중에선 꽤나 완성도가 높은 솔루션이라고 생각됩니다.
물론 부분적으로 튜닝할 요소 또는 또다른 애드온들을 통해 부족한 부분들을 보완해나갈수있는 여지가 있습니다.
# 모니터링
kubectl create ns monitoring
watch kubectl get pod,pvc,svc,ingress -n monitoring
# 사용 리전의 인증서 ARN 확인 : 정상 상태 확인(만료 상태면 에러 발생!)
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo $CERT_ARN
# repo 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
# 파라미터 파일 생성
cat <<EOT > monitor-values.yaml
prometheus:
prometheusSpec:
podMonitorSelectorNilUsesHelmValues: false
serviceMonitorSelectorNilUsesHelmValues: false
retention: 5d
retentionSize: "10GiB"
storageSpec:
volumeClaimTemplate:
spec:
storageClassName: gp3
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 30Gi
ingress:
enabled: true
ingressClassName: alb
hosts:
- prometheus.$MyDomain
paths:
- /*
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
alb.ingress.kubernetes.io/group.name: study
alb.ingress.kubernetes.io/ssl-redirect: '443'
grafana:
defaultDashboardsTimezone: Asia/Seoul
adminPassword: prom-operator
ingress:
enabled: true
ingressClassName: alb
hosts:
- grafana.$MyDomain
paths:
- /*
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
alb.ingress.kubernetes.io/group.name: study
alb.ingress.kubernetes.io/ssl-redirect: '443'
persistence:
enabled: true
type: sts
storageClassName: "gp3"
accessModes:
- ReadWriteOnce
size: 20Gi
defaultRules:
create: false
kubeControllerManager:
enabled: false
kubeEtcd:
enabled: false
kubeScheduler:
enabled: false
alertmanager:
enabled: false
EOT
cat monitor-values.yaml | yh
# 배포
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 57.1.0 \
--set prometheus.prometheusSpec.scrapeInterval='15s' --set prometheus.prometheusSpec.evaluationInterval='15s' \
-f monitor-values.yaml --namespace monitoring
배포는 helm install 명령어로 진행하지만, 개인적으로는 helm upgrade –install 형태로 설치를 진행하는것을 더 좋아합니다.
최초로 설치해도 동일하고, 두번 실행해도 에러 멘트가 안 뜨거든요!
AWS CNI Metrics 수집
# PodMonitor 배포
cat <<EOF | kubectl create -f -
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
name: aws-cni-metrics
namespace: kube-system
spec:
jobLabel: k8s-app
namespaceSelector:
matchNames:
- kube-system
podMetricsEndpoints:
- interval: 30s
path: /metrics
port: metrics
selector:
matchLabels:
k8s-app: aws-node
EOF
프로메테우스 웹서버에서 추가한 메트릭이 수집되는것을 확인했습니다.
이런식으로 수집할 metric들을 추가하는건 자유롭지만, 노드갯수만큼 scrape 해오는 정보들이 많아질경우 기하급수적 으로 부하가 증가하기떄문에 custom metric 수집은 최소화하며 prometheus를 관리하는것이 좋을거같습니다.
높아진 부하분산을 처리하기위해
프로메테우스는 Sharding 구성이 가능합니다.
prometheus:
prometheusSpec:
# replicas: 2
shards: 2
이제 이 두가지 메트릭을 어떻게 가공할것인가는 Thanos를 이용해서… 처리하지만 이것은 기회가 된다면 다음기회에 다뤄보겠습니다.
https://blog.montkim.com/prometheus-thanos
기존에 작성해둔게 있으니 참조해보면 좋을것같습니다. 타노스의 탄생배경에 대해 다루었지만, 타노스 자체적으로 깊이있게 다뤄보질 못하여 깊이가 많이 부족합니다.
주석처리해둔 sharding 외에 replicaset 구성을 할경우 HA 구성이되는데, 중복된 메트릭은 thanos query의 “use deduplication” 기능으로 중복 제거를 진행합니다.
PromQL
promql은 prometheus server가 TSDB 형태로 축적된 데이터를 쿼리할 수 있는 강력한 QL문입니다.
“대충날려도 알아서 잘 알아먹는” 게 특징이며, 자동완성이나 범위쿼리 혹은 벡터검색등 정말 다양한 기능을 제공합니다.
아까 만들었던 NGINX 컨테이너에 부하테스트를 진행해보겠습니다
servicemonitor에 새로 생성된 nginx에 대해서 수집을 시작한것을 확인했습니다.
부하테스트를 진행하며
nginx_http_requests_total
sum(nginx_http_requests_total) without (instance,container,endpoint,job,namespace)
같은 쿼리를 보다 깔끔하게 확인하는 과정에 컨테이너의 사용량 기준으로 보면 어떨까? 라는 생각을 해봤습니다.
container_cpu_usage_seconds_total{pod="nginx-7f7b5d655f-zf684", container="nginx"}[2m]
scrape config 별로 축적되는 컨테이너의 cpu usage time이 key / value 형태로 누적되는것이 보입니다. 해당 메트릭등을 가시적으로 나타낸다면 Grafana에서 보는 값과 동일할겁니다.
이번에는 쿼리에 시간단위를 제외하여 Graph 형태로 데이터를 조회해보겠습니다.
container_cpu_usage_seconds_total{pod="nginx-7f7b5d655f-zf684", container="nginx"}
점점 증가하는 값을 가시적으로 볼 수 있었고, 그라파나에서 조회하는것과 동일한지 확인해보겠습니다.
Grafana
신규로 설치한 그라파나에서… 기본대시보드가 depricated 라며 기존의 메트릭을 볼수가 없네요
조금 더 깔끔하게 볼겸 신규 dashboard를 추가해봅니다.
추가할 custom dashboard는 import dashboard 항목에서 추가가 가능하며
#15757, #17900 입니다
두번째 대시보드의경우 “컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커” 책 저자분들이 만드신 대시보드로 알고있습니다.
다음과 같이 import를 진행하고 들어가보면
한눈에 클러스터의 상태를 전부다 볼 수 있는 대시보드가 import됩니다.
꼭 kubernetes와 prometheus 데이터가 아니여도 grafana는 어떤 형태의 데이터들을 모두 시각화하는데 특화되어있으며, iot 디바이스들을 연동해 전체적인 상황을 모니터링하거나 등의 구성도 가능합니다.
다시 돌아와서
아까 부하테스트하던 pod 자체의 메트릭을 볼수는 없었지만, 부하테스트를 진행하며 node의 cpu 값이 확 뛰는것을 볼 수 있습니다.
별도로 request / limit을 설정하지않아 qos class가 best effort로 설정이 되었지만, 현재 노드에 떠있는 다른 pod들이 자원사용량이 없어 노드의 사양 전부다 사용이 가능했을겁니다.
구체적인 노드 / 파드의 자원관리에 대해서는 다른 주제에서 다루지않을까 싶네요
https://blog.montkim.com/eviction-priorityclass
해당 게시글에서도 다룬적이 있습니다.