Madison Digital Garden

Search

SearchSearch

쿠버네티스 딥다이브 : 7천+ 클러스터를 관리한 엔지니어의 MTTR 감소, SLA 증대 노하우 (6주차 - Open Source Projects)

Jun 10, 2023, 11 min read

강의 정보

강의 필기록 원본이라 글이 좀 어수선할 수 있습니다.

Logging

  • kubectl logs
    • --previous: 죽은 파드의 로그 조회 가능
  • stern: 여러 파드의 로그를 조회할 수 있게 해주는 서드파티 cli
    • 참고) Github/stern
    • 대신, 여러 파드를 조회하기 때문에 트래픽 부하를 많이 준다
  • Sidecar logging: 특이한 요구사항을 맞추기에는 좋지만 파드가 죽었을때 같이 죽어서 로그가 유실될 수 있다더라
  • Kubelet 버그: (기본) 50mb 까지만 파드의 로그를 저장하고 넘어가면 kubelet 이 정리해야되는데, 로그가 너무 많이 쌓이게 되면 (너무 빠르게?) 정리가 안된다더라
  • 로그를 저장하는건 CRI, 로그 저장 위치를 지정해주는건 Kubelet
  • pod log 는 /var/log/pods 에 저장되고, 이것은 하드코딩되어 있어 변경할 수 없다
    • 여기에는 ${NAMESPACE}_${NAME}_${UUID} 이름의 디렉토리가 있고, 이 안에는 컨테이너이름의 디렉토리, 그리고 그 아래는 ${INTEGER}.log 파일로 로그가 저장되어 있다
  • Logging component 들
    • Forwarder: (Fluentbit) 로그를 모아서 Aggregator 로 보냄
    • Aggregator: (Fluentd) 로그를 storage 로 보내기 전에 잠깐 버퍼로 가지고 있음 (어느정도 모이면 Storage 로 보냄)
    • Storage: (Elasticsearch) 로그를 모아 파싱, 인덱싱함
    • Visualization: (Kibana) 시각화
  • Splunk: Elasticsearch 의 유료버전, 무겁고 비쌈, 대신 Elasticsearch 는 성능 optimization 을 위해 고민을 많이 해야된다고 한다
  • Loki 의 장점: Kubernetes 호환성이 좋음 + 디스크를 사용하지만 버퍼의 성격이 강하고 S3 를 메인 스토리지로 사용
  • Datadog, New Relic, Dynatrace: 돈많을때 사용하면 됨
    • Datadog은 비싸지만 좋다
    • 돈이 없으면 New Relic 도 솔루션도 된다

Monitoring

  • 차이점:
    • 로그: 이벤트성, 메트릭: 상태 저장
    • 로그: 사고대처, 메트릭: 사고예방
  • 메트릭을 선정하고 시각화할때는 이상조건이 뭔지 항상 고민해야 한다
    • conntrack 임계값은 30만이기 때문에 TCP 커넥션이 30만이 넘는지 안넘는지 모니터링
  • Prometheus 도 remote storage 에 메트릭을 저장하게 할 수 있다
  • Prometheus 의 메트릭 포맷은 OpenMetrics 라는 이름으로 표준화되었다
  • exporter 등에서 HTTP endpoint 에서 주기적으로 긁어와 저장한다
  • KPS: 파드가 왜 죽었는지 확인해볼때
    • Kubernetes state (volume 갯수 등)을 계속 수집해서 prometheus 에서 가져갈 수 있게 함
  • 어떤 메트릭이 존재하는지 대강만 알아두고 문제가 발생하는 것만 대시보드로 만들어라
  • 메트릭 리뷰하는 법
    • github readme 에서 볼 수도 있지만 버전별, 옵션별 메트릭이 다르기 때문에 직접 /metrics 엔드포인트 접속해서 주석 읽어보는게 최고다
  • 추천 메트릭
    • CPU
      • CPU 사용량이 spike 치는 경우, 해당 시간대의 로그를 확인하며 원인분석하는 예시 (초단위 메트릭 추천)
      • CPU 스케일업을 위한 (의사결정을 위한) 데이터 확보
      • CPU 와 관련없는 것들에 대한 분석도 가능하다
        • User: 이건 진짜 pod 의 cpu usage
        • System: 이건 kernel 이 사용하는 CPU usage 인데, 보통 CNI 가 kernel 을 많이 사용하기 때문에 CNI 관련 예방할때 사용할 수 있다
        • Niced: 이건 0.0 이 아니면 문제있는것
        • Idle: 말그대로,,
        • Wait: Disk IO 관련 문제 디버깅 - DB 쪽 문제를 예방할 수 있다
        • HW / SW interrupt: 이쪽에 문제가 있다면, kernel 혹은 driver 가 원인이다
        • Steal: Noisy neighbor problem 와 관련; VM 이 너무 많이 떠있거나 가상환경 간의 간섭이 원인이다 - CPU usage (User?) 와 같은 경향성을 보인다면, VM 문제
    • MEM
      • 메모리가 진짜 여유있는지 아는 것은 많이 힘들다
        • 왜냐면, OpenJDK, Golang 등 여러 언어에서 대부분 메모리가 필요 없어졌을 경우에 바로 반납을 안하고 노드에 메모리가 부족해졌을 경우에 그제서야 반납하는 경우가 많기 때문
      • BestEffort 로 일주일 돌리고 피크값의 두배로 request / limit 을 설정하는게 베스트라고 하네
    • NET
      • 네트워크 장애시에는 어차피 메트릭 못보기 때문에 pdf 16p 에 있는 메트릭 정도만 추천
      • TCP retransmission 메트릭을 보고 이게 많다면 kernel 문제다
    • DISK
      • 응답속도 중심
    • API (kube-apiserver)
      • kube-apiserver 로 가는 request 가 초당 200 개로 제한 되어 있어 이것관련해서만 모니터링하면 된다고 하네

Tracing, Profiling

  • Tracing: 아직 제대로 된게 없다고 한다.
  • Profiling: 이것도 아직 experimental 단계이기 때문에 아직은 시기상조… netfilx 만 관측한다

수업 회고 및 잡담

  • Kafka operator 에서 해주는건지는 모르겠는데 mq 에 msg 가 많이 쌓이면 이것을 metric 으로 노출시켜 HPA 가 autoscaling 하게 할 수 있다
    • 즉, HPA 의 지표로 mq 길이를 활용할 수 있다는 것
    • 잘 되는지는 모르겠음 - 뭐 리밸런싱 관련 이슈가 있다고 하는거 같았는데
    • KEDA 를 사용하는 것이 해답이 될수도
    • autoscaling/v2 API 에서 공식 지원하는거같기도: ExternalMetricService 라는 필드로 custom metric 으로 scaling 하는 것 같다
    • Prometheus adapter 사용하면 prometheus metric 을 kubectl top 으로 볼 수 있다: autoscaling/v2 를 좀 찾아보자
  • DB in Kubernetes: remote pv 를 사용하는 건 문제가 생길 경우 복구할 방법이 없어서 (백업없이?) 추천하지 않는다고 함
    • Spotify 에서는 local volume 과 remote volume 을 RAID 1 로 묶고 DB 에서는 local volume 을 사용하도록 했다더라
  • K8s 에서 Jenkins CI 추천한다고 한다
  • Telepresence 는 지양하는게 좋다고 생각.. 나도 마찬가지: 로컬 테스트용도로 rds 에 접근하는건 말이 안된다
    • 로컬환경에서는 로컬에 모든 dependency 가 있도록
    • dev, prod 환경을 나눠서 테스트해볼 수 있도록
  • 쿠버네티스 버전업그레이드
    • release note 를 곰곰히 읽어보자
    • kube-apiserver 의 root path 로 접근하면 지원하는 모든 api 목록이 나오는데, 이걸 diff 뜨는 방법도 있다
    • kube-apiserver 와 kube-controller-manager 의 버전은 같게 하는게 좋다
      • 왜냐하면 kube-controller-manager 가 낮은 버전으로 defaulting 을 수행할 수도 있어서 문제가 생길 수 있다
    • 클러스터를 언제든지 바꿀수 있다는 생각으로 CD 파이프라인을 구성한다면, 장애시에나 버전업그레이드시에나 단순하게 CD target cluster 를 변경하는것으로 (문화적으로) 해결할 수도 있다
  • 멀티 클러스터 모니터링
    • prometheus remote backend 사용 - thanos
      • 근데 그럼 중앙 prometheus 가 메모리를 너무 많이 먹게 된다
      • (옛날 카카오) 에서는 prometheus 가 아닌 storage 에 메트릭을 저장하고, 이곳에 접근하는 prometheus 는 scale-out 이 가능하도록 구현… 쉽지는 않다고 한다
  • Jaeger… 병목 파악을 위한 APM 솔루션
    • 이걸 위한 좀 부실한 표준인것 같다고 한다: OpenTelemetry
  • 사내 k8s 이해도 높이기
  • 클러스터 분리: 조직의 구조를 따라 가는게 맞다… 콘웨이의 법칙
    • 사용하는 조직이랑 운영하는 조직이 다르다면 문제가 생길수밖에 없다… 이건 많이 느끼제
  • SRE 책 구글에서 무료로 푼다: Google - Site Reliability Engineering

Graph View

Backlinks