본문 바로가기
Tech/Kubernetes

[AEWS_1기] 4주차 - Observability (3/6) - Metrics-server & kwatch & botkube

by 구름_쟁이 2023. 5. 19.

 

 

본 시리즈는 가시다님의 AEWS(AWS EKS Workshop) 1기 진행 내용입니다. (가시다님 노션)

스터디에 사용되는 링크 (AWS EKS Workshop) 

 

목차

1. Logging in EKS (링크)
2. Container Insights metrics in Amazon CloudWatch & Fluent Bit (Logs) (링크)
3. Metrics-server & kwatch & botkube

4. 프로메테우스-스택
5. 그라파나 Grafana

6. kubecost

 

 

 

EKS 클러스터 세팅 (Cloudformation)

https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick3.yaml

 

 

 


3. Metrics-server & kwatch & botkube

Metrics-server 확인 : kubelet으로부터 수집한 리소스 메트릭을 수집 및 집계하는 클러스터 애드온 구성 요소

 - EKS Github Docs CMD

 

  • cAdvisor : kubelet에 포함된 컨테이너 메트릭을 수집, 집계, 노출하는 데몬

https://kubernetes.io/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/

# 배포
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 메트릭 서버 확인 : 메트릭은 15초 간격으로 cAdvisor를 통하여 가져옴
kubectl get pod -n kube-system -l k8s-app=metrics-server
kubectl api-resources | grep metrics
kubectl get apiservices |egrep '(AVAILABLE|metrics)'

# 노드 메트릭 확인
kubectl top node

# 파드 메트릭 확인
kubectl top pod -A
kubectl top pod -n kube-system --sort-by='cpu'
kubectl top pod -n kube-system --sort-by='memory'

kwatch 소개 및 설치/사용

kwatch helps you monitor all changes in your Kubernetes(K8s) cluster, detects crashes in your running apps in realtime, and publishes notifications to your channels (Slack, Discord, etc.) instantly - 링크 Helm Blog

 

 

PKOS에서 진행했던 부분으로 아래 링크에서 확인

(링크)

 

 

Botkube

 - 공홈 Blog

https://docs.botkube.io/next/architecture/

 

선행 작업

슬랙 앱 설정 : SLACK_API_BOT_TOKEN 과 SLACK_API_APP_TOKEN 생성

- Docs

두개 TOKEN은 개인이 준비


설치

# repo 추가
helm repo add botkube https://charts.botkube.io
helm repo update

# 변수 지정
export ALLOW_KUBECTL=true
export ALLOW_HELM=true
export SLACK_CHANNEL_NAME=webhook3

#
cat <<EOT > botkube-values.yaml
actions:
  'describe-created-resource': # kubectl describe
    enabled: true
  'show-logs-on-error': # kubectl logs
    enabled: true

executors:
  k8s-default-tools:
    botkube/helm:
      enabled: true
    botkube/kubectl:
      enabled: true
EOT

# 설치
helm install --version v1.0.0 botkube --namespace botkube --create-namespace \
--set communications.default-group.socketSlack.enabled=true \
--set communications.default-group.socketSlack.channels.default.name=${SLACK_CHANNEL_NAME} \
--set communications.default-group.socketSlack.appToken=${SLACK_API_APP_TOKEN} \
--set communications.default-group.socketSlack.botToken=${SLACK_API_BOT_TOKEN} \
--set settings.clusterName=${CLUSTER_NAME} \
--set 'executors.k8s-default-tools.botkube/kubectl.enabled'=${ALLOW_KUBECTL} \
--set 'executors.k8s-default-tools.botkube/helm.enabled'=${ALLOW_HELM} \
-f botkube-values.yaml botkube/botkube

# 참고 : 삭제 시
helm uninstall botkube --namespace botkube

사용 - Docs

# 연결 상태, notifications 상태 확인
@Botkube ping
@Botkube status notifications

# 파드 정보 조회
@Botkube k get pod
@Botkube kc get pod --namespace kube-system
@Botkube kubectl get pod --namespace kube-system -o wide

# Actionable notifications
@Botkube kubectl

잘못된 이미지 파드 배포 및 확인

# 터미널1
watch kubectl get pod

# 잘못된 이미지 정보의 파드 배포
kubectl apply -f https://raw.githubusercontent.com/junghoon2/kube-books/main/ch05/nginx-error-pod.yml
kubectl get events -w
@Botkube k get pod

# 이미지 업데이트 방안2 : set 사용 - iamge 등 일부 리소스 값을 변경 가능!
kubectl set 
kubectl set image pod nginx-19 nginx-pod=nginx:1.19
@Botkube k get pod

# 삭제
kubectl delete pod nginx-19

삭제

helm uninstall botkube --namespace botkube

 

 

슬랙 채널에 '@Botkube k get pod' 입력

명령어 입력 당시에는 파드가 없어서 response가 없다고 나오지만,

테스트 pod 배포하고 나서는 바로 create 정보가 나온다

여기 선택박스에서 describe를 선택하면 자세한 내용 확인 가능

 

 

잘못된 파드 배포

 

슬랙에서 아래와 같이 Failed 상태를 보여준다

 

set 명령어로 올바른 image로 설정

정상 배포 확인

 

 

 

 

삭제를 하게 되면

슬랙 봇이 이렇게 메시지를 보내준다

 

 

 

결론

요즘 시스템을 설계하는 중에 이런 봇을 연동한 서비스들을 보니 내부적으로나 서비스 연동에 써보면 어떨까 라는 생각이 든다.

아이디어가 마구마구 떠오르지만, 일단 해야할 일들을 처리하는 것만해도 벅찬 현실이 슬프다..

 

botkube는 특히나 kubectl 명령어에 익숙하지 않은 개발자들에게 제공하면 logs, describe, get, top 정도는 선택박스에서 고를 수 있기에 간단하게 문제를 확인하기에는 도움이 될 것 같다.

(외부 접속이 차단된 클러스터에 슬랙 연동해두면 내가 외근이여도 개발자들이 pod 배포가 실패했을 때 어떤 이유인지 슬랙채널을 통해 같이 살펴볼 수 있을 것 같다) (그래도 그런 일은 없어야지....제발..)

 

 

 

댓글