쿠버네티스에는 수명이 짧은 다수의 컨테이너를 모니터링할 수 있도록 애플리케이션의 성능을 이해하는 데 도움을 주는 툴과 API가 내장되어 있습니다. 내장된 툴을 활용하는 모니터링 전략을 사용하면 애플리케이션을 실행하는 컨테이너가 지속적으로 호스트 간에 이동하거나 확장 또는 축소되는 경우에도 전체 애플리케이션의 성능을 한 눈에 파악할 수 있습니다.
인프라에 쿠버네티스 환경을 통합하는 경우 고려할 수 있는 몇 가지 모범 사례를 소개합니다.
포괄적인 인프라 옵저버빌리티를 위한 쿠버네티스 모니터링 가이드 시리즈 1부
이 글은 쿠버네티스 모니터링 시리즈의 1부로, 쿠버네티스를 모니터링하는 방법과 완전한 옵저버빌리티를 확보하는 데 필요한 요소를 살펴봅니다. 또한 쿠버네티스로 무엇이 가능하며, 보다 효과적인 모니터링 전략을 위해 쿠버네티스를 활용하는 모범 사례를 설명합니다.
쿠버네티스 모니터링이란?
쿠버네티스 모니터링은 쿠버네티스 클러스터의 문제를 신속하게 진단하고 리소스와 성능을 최적화하는 데 필요한 데이터를 수집 및 분석하는 데 도움을 줍니다. 쿠버네티스의 중추라고 할 수 있는 클러스터는 컨테이너화된 애플리케이션을 실행하는 다양한 머신(노드)로 구성되어 있습니다.
먼저, 쿠버네티스(Kubernetes)란 무엇일까요? 줄여서 ‘K8s’ 라고도 하는 쿠버네티스는 컨테이너 오케스트레이션의 실질적인 표준으로 자리매김한 오픈소스 플랫폼입니다. 2021년 CNCF에 따르면, 전 세계적으로 특히 대규모 조직들 사이에서 쿠버네티스의 사용이 증가했습니다. 현재 전 세계적으로 560만 명의 개발자가 쿠버네티스를 사용하고 있으며, 이는 전체 백엔드 개발자의 31%에 해당하는 수치입니다.
쿠버네티스는 컨테이너 오케스트레이션 시스템으로서, 최신 애플리케이션의 인프라를 구성하는 컨테이너들을 자동으로 예약, 확장 및 유지합니다. 쿠버네티스는 CNCF(Cloud Native Computing Foundation)의 대표적인 프로젝트로 Google, AWS, Microsoft, IBM, Intel, Cisco, Red Hat 등 주요 기업들의 지원을 받고 있습니다.
쿠버네티스를 어떻게 모니터링 할까요?
쿠버네티스는 애플리케이션 실행에 필요한 소프트웨어를 구성하는 컨테이너를 관리하는 일상적인 운영 작업을 자동화해줍니다. 쿠버네티스는 애플리케이션 배포를 위해 내장된 명령을 사용하여 애플리케이션에 변경 사항을 롤아웃하고, 변화하는 요구에 맞게 애플리케이션을 확장하며, 애플리케이션을 모니터링하는 등 다양한 작업을 수행합니다. 쿠버네티스는 실행 위치에 상관없이 컨테이너를 조율하여, 인프라 플랫폼 간의 다중 클라우드 구축과 마이그레이션을 지원합니다. 간단히 말해, 쿠버네티스는 애플리케이션을 보다 쉽게 관리할 수 있도록 합니다.
쿠버네티스를 모니터링하는 것이 왜 중요할까요?
쿠버네티스는 지속적으로 서비스에 대한 상태 점검을 실행합니다. 클라우드 네이티브 앱에서, 이는 일관되게 컨테이너를 관리할 수 있다는 것을 의미합니다. 쿠버네티스는 자동화된 상태 검사를 사용하여 오류가 발생하거나 중단된 컨테이너를 다시 시작합니다.
쿠버네티스에는 노동 집약적인 애플리케이션 관리 작업을 처리하는 명령이 내장되어 있어 쿠버네티스를 사용해 일상적인 시스템 관리 작업을 자동화할 수 있습니다. 쿠버네티스는 애플리케이션이 항상 설정대로 실행되게 만들 수 있습니다.
쿠버네티스는 워크로드를 대신하여 컴퓨팅, 네트워킹 및 스토리지를 처리합니다. 따라서 개발자는 기저 환경에 대해 신경 쓰지 않고 애플리케이션에 집중할 수 있습니다.
쿠버네티스 모니터링 모범 사례
쿠버네티스에는 수명이 짧은 다수의 컨테이너를 모니터링할 수 있도록 애플리케이션의 성능을 이해하는 데 도움을 주는 툴과 API가 내장되어 있습니다. 내장된 툴을 활용하는 모니터링 전략을 사용하면 애플리케이션을 실행하는 컨테이너가 지속적으로 호스트 간에 이동하거나 확장 또는 축소되는 경우에도 전체 애플리케이션의 성능을 한 눈에 파악할 수 있습니다.
인프라에 쿠버네티스 환경을 통합하는 경우 고려할 수 있는 몇 가지 모범 사례를 소개합니다.
- 네임스페이스를 사용해 클러스터에 있는 리소스를 체계화하고 격리합니다.
- 쉽게 식별하고 모니터링할 수 있도록 네임스페이스에 레이블을 붙이고 주석을 답니다.
- 과부하가 발생하지 않도록 리소스 요청과 한도를 설정합니다.
- 컨테이너의 상태와 가용성을 모니터링합니다.
- Prometheus, Grafana 등의 툴을 사용해 한 곳에서 로깅과 모니터링을 관리합니다.
- 구현을 자동화합니다.
- 클러스터와 컨테이너에 대해 정기적인 감사를 수행합니다.
- 최신 쿠버네티스 버전을 사용해 성능과 보안이 최고 수준으로 유지되도록 합니다.
모니터링 전략을 변화시키는 쿠버네티스
“쿠버네티스는 이해하기 쉽다”고 말하는 사람이 있다면 거짓말입니다.
특히 가상 머신이나 온프레미스 서버 같은 기존 호스트에서 마이그레이션하는 경우, 쿠버네티스는 모니터링에 대한 새로운 접근 방식이 필요합니다.
컨테이너는 수요에 맞춰 지속적으로 배포되기 때문에 한 번에 몇 분 동안만 지속됩니다. 더 이상 존재하지 않는데 어떻게 문제를 진단할 수 있을까요?
게다가, 컨테이너는 전 세계의 물리적 서버에 위치한 여러 호스트에 분산되어 있습니다. 수집하고 있는 메트릭에 대한 적절한 컨텍스트가 없다면, 실패한 프로세스와 그 영향을 받는 애플리케이션을 연관시키기가 어렵습니다.
쿠버네티스에는 수명이 짧은 다수의 컨테이너를 모니터링할 수 있도록 애플리케이션의 성능을 이해하는 데 도움을 주는 툴과 API가 내장되어 있습니다. 쿠버네티스를 활용하는 모니터링 전략을 사용하면 애플리케이션을 실행하는 컨테이너가 지속적으로 호스트 간에 이동하거나 확장 또는 축소되는 경우에도 전체 애플리케이션의 성능을 한 눈에 파악할 수 있습니다.
모니터링 부담 증가
스택에 대한 완전한 가시성을 확보하려면 인프라를 모니터링해야 합니다. 현대의 기술 스택으로 인해 애플리케이션과 인프라 간의 관계는 더 복잡해졌습니다.
기존 인프라
기존 인프라 환경에서는 애플리케이션과 이를 실행하는 호스트(서버 또는 가상 머신)만 모니터링하면 되었습니다.
컨테이너의 도입
2013년, Docker는 컨테이너화를 세상에 선보였습니다. 컨테이너는 격리되고 예측 가능하며 반복 가능한 방식으로 애플리케이션과 그 종속성을 패키지로 묶어 실행하는 데 사용됩니다. 이를 통해 인프라와 애플리케이션 사이에는 추상화 계층이 추가됩니다. 애플리케이션 대신 워크로드를 실행한다는 점에서 컨테이너는 기존 호스트와 유사합니다.
쿠버네티스
쿠버네티스를 사용하면 스택을 완전하게 파악할 수 있으므로 계속 자동으로 스핀업하며 수명이 다해가는 컨테이너에서 텔레메트리 데이터를 수집하는 동시에 쿠버네티스 자체에서도 텔레메트리 데이터를 수집할 수 있습니다. 서버에 켜진 표시등 몇 개만 확인하면 되던 시대는 지났습니다!
쿠버네티스 환경에서는 모니터링해야 하는 4가지 구성 요소가 있으며, 각 요소마다 특징과 도전과제가 다릅니다.
- 인프라(* 작업자 노드)
- 컨테이너
- 애플리케이션
- 쿠버네티스 클러스터(* 컨트롤 플레인)
*이러한 개념은 이 가이드의 2부에서 다루겠습니다.
애플리케이션 메트릭과 인프라 메트릭 및 메타데이터의 상호 연관
쿠버네티스가 확장 가능한 애플리케이션을 쉽게 구축할 수 있도록 지원하면서, 애플리케이션과 인프라 간의 경계선이 모호해졌습니다. 개발자는 클러스터의 성능이 아니라 애플리케이션에 주로 초점을 맞추지만, 클러스터의 기본 구성 요소는 애플리케이션의 성능에 직접적인 영향을 미칠 수 있습니다. 예를 들어 쿠버네티스 애플리케이션의 버그는 물리적인 인프라 문제로 인해 발생할 수 있지만 구성 오류나 코딩 문제로 인해 발생할 수도 있습니다.
쿠버네티스를 사용할 때 애플리케이션 모니터링은 선택 사항이 아니라, 필수 사항입니다!
대부분의 애플리케이션 성능 모니터링(APM) 언어 에이전트는 애플리케이션이 실행되는 위치와 상관이 없습니다. 에이전트는 잊혀진 랙의 오래된 Linux 서버나 최신 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 실행될 수 있습니다. 그러나 오케스트레이션 계층에서 관리되는 애플리케이션을 모니터링할 때, 인프라에 대한 컨텍스트가 있으면 디버깅이나 문제 해결에 매우 유용할 수 있습니다. 예를 들어 애플리케이션 오류 트레이스를 실행 중인 컨테이너, 파드 또는 호스트와 연관시킬 수 있습니다.
쿠버네티스에서 레이블 지정
쿠버네티스는 다양한 수명 주기를 가진 컨테이너의 생성 및 삭제를 자동화합니다. 이러한 전체 프로세스는 모니터링되어야 합니다. 변경되는 부분이 너무 많기 때문에, 메트릭을 해당 애플리케이션, 파드, 네임스페이스, 노드 등에 매치시키려면 조직 전반에서 명확한 레이블 지정 정책을 수립해야 합니다.
여러 다른 오브젝트에 일관성 있게 레이블을 지정하면 쿠버네티스 클러스터에서 이러한 오브젝트들을 쉽게 쿼리할 수 있습니다. 예를 들어, 개발자로부터 운영 환경이 다운되었는지 묻는 전화가 왔다고 가정해 보겠습니다. 운영 포드에 ‘prod’ 레이블이 있는 경우, 다음과 같은 kubectl 명령을 실행하여 모든 로그를 가져올 수 있습니다.
kubectl get pods -l name=prod:
NAME READY STATUS RESTARTS AGE
router-worker-6db6999875-b8t8m 0/1 ErrImagePull 0 1d4h
router-worker-6db6999875-7fn7z 1/1 Running 0 47s router-worker-6db6999875-8rl9b 1/1 Running 3 10h router-worker-6db6999875-b8t8m 1/1 Running 2 11h 이 예에서는 prod 파드 중 하나가 이미지를 가져와 해당 정보를 그 prod 파드를 사용하는 개발자에게 제공하는 데 문제가 있음을 볼 수 있습니다. 레이블이 없는 경우 kubbtl get 파드의 출력을 수동으로 가져와야 합니다.
일반적인 레이블 지정 규칙
위의 예에서는 파드가 환경별로 사용되었는지 확인하기 위해 ‘prod’라는 레이블이 붙은 인스턴스가 있었습니다. 각 팀마다 운영 방식이 다르지만, 팀들은 보통 다음과 같은 명명 규칙을 사용합니다.
환경별 레이블
속해 있는 환경에 대한 엔터티를 생성할 수 있습니다. 예를 들면,
env: production
env: qa
env: development
env: staging팀별 레이블
팀 이름에 대한 태그를 만들면, 어떤 팀, 그룹, 부서 또는 지역이 성능 문제를 야기했는지 이해하는 데 도움이 됩니다.
### Team tags
team: backend
team: frontend0
team: db
### Role tags
roles: architecture
roles: devops
roles: pm
### Region tags
region: emea
region: america
region: asia쿠버네티스 권장 레이블
쿠버네티스에서는 리소스 객체의 기본 그룹화를 허용하는 권장 레이블 목록을 제공합니다. 접두사 app.kubernetes.io는 쿠버네티스에서 권장하는 레이블과 company.com 접두사를 사용하여 별도로 추가할 수 있는 커스텀 레이블 간을 구분해줍니다. 가장 보편적으로 사용되는 쿠버네티스 레이블 몇 가지는 다음과 같습니다.
| 키 | 설명 |
app.kubernetes.io/name | 애플리케이션의 이름(예: redis) |
app.kubernetes.io/instance | 애플리케이션의 특정 인스턴스에 대한 고유 이름(예: redis-department-a) |
app.kubernetes.io/component | 구성 요소의 용도를 설명하는 식별자(예:login-cache) |
app.kubernetes.io/part-of | 이 리소스를 사용하는 상위 레벨 애플리케이션(예: company-auth) |
모든 쿠버네티스 객체에 레이블이 지정되면 옵저버빌리티 데이터를 쿼리하여 인프라 및 애플리케이션에 대한 포괄적인 정보를 파악할 수 있습니다. 메트릭을 필터링하여 스택의 모든 계층을 검토할 수 있고, 문제의 근본 원인을 찾기 위해 보다 세부적인 사항을 살펴볼 수도 있습니다.
따라서 쿠버네티스에 대한 모니터링 및 알림 전략에서는 이해하기 쉬운 레이블과 셀렉터를 생성하기 위해 명확하고 표준화된 전략을 갖추는 것이 중요합니다. 궁극적으로 상태와 성능 메트릭은 사용자가 설정한 레이블로만 집계될 수 있습니다.
뉴렐릭의 쿠버네티스 모니터링과 옵저버빌리티
지금까지 쿠버네티스의 정의, 수행할 수 있는 작업, 모니터링이 필요한 이유, 적절한 쿠버네티스 모니터링을 설정하는 모범 사례를 살펴보았습니다.
이 시리즈의 2부에서는 쿠버네티스 아키텍처에 대해 자세히 살펴보겠습니다.
다음 단계
뉴렐릭은 또한 쿠버네티스를 위한 사전 구축된 대시보드와 알림 세트를 제공합니다. 이 기능을 사용하려면, 지금 뉴렐릭 계정을 신청하십시오.무료 계정에는 뉴렐릭의 모든 기능에 액세스할 수 있는 한 명의 사용자와 보고를 확인할 수 있는 무제한 기본 사용자, 매월 100GB의 무료 데이터 인제스트가 포함됩니다.
이 블로그에 표현된 견해는 저자의 견해이며 반드시 New Relic의 견해를 반영하는 것은 아닙니다. 저자가 제공하는 모든 솔루션은 환경에 따라 다르며 New Relic에서 제공하는 상용 솔루션이나 지원의 일부가 아닙니다. 이 블로그 게시물과 관련된 질문 및 지원이 필요한 경우 Explorers Hub(discuss.newrelic.com)에서만 참여하십시오. 이 블로그에는 타사 사이트의 콘텐츠에 대한 링크가 포함될 수 있습니다. 이러한 링크를 제공함으로써 New Relic은 해당 사이트에서 사용할 수 있는 정보, 보기 또는 제품을 채택, 보증, 승인 또는 보증하지 않습니다.
