쿠버네티스란?
줄여서 ‘K8s’ 라고도 하는 쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션의 실질적인 표준으로 자리매김한 오픈소스 플랫폼입니다. 2021년 CNCF에 따르면, 전 세계적으로 쿠버네티스의 사용량이 증가했습니다. 현재 전 세계적으로 560만 명의 개발자가 쿠버네티스를 사용하고 있으며, 이는 전체 백엔드 개발자의 31%에 해당하는 수치입니다.
컨테이너 오케스트레이션 시스템인 쿠버네티스는 최신 애플리케이션의 인프라를 구성하는 컨테이너들을 자동으로 예약, 확장 및 유지합니다. 쿠버네티스는 CNCF(Cloud Native Computing Foundation)의 대표적인 프로젝트로 Google, AWS, Microsoft, IBM, Intel, Cisco, Red Hat 등의 주요 기업들의 지원을 받고 있습니다.
쿠버네티스로 어떤 일을 할 수 있을까요?
쿠버네티스는 애플리케이션 실행에 필요한 소프트웨어를 구성하는 컨테이너를 관리하는 일상적인 운영 작업을 자동화해줍니다. 쿠버네티스는 애플리케이션 배포를 위해 내장된 명령을 사용하여 애플리케이션에 변경 사항을 롤아웃하고, 변화하는 요구에 맞게 애플리케이션을 확장하며, 애플리케이션을 모니터링하는 등 다양한 작업을 수행합니다. 쿠버네티스는 실행 위치에 상관없이 컨테이너를 조율하여, 인프라 플랫폼 간의 다중 클라우드 구축과 마이그레이션을 지원합니다. 간단히 말해, 쿠버네티스는 애플리케이션을 보다 쉽게 관리할 수 있습니다.
자동화된 상태 체크
쿠버네티스는 지속적으로 서비스에 대한 상태 점검을 실행합니다. 클라우드 네이티브 앱의 경우, 이는 일관되게 컨테이너를 관리할 수 있다는 것을 의미합니다. 쿠버네티스는 자동화된 상태 검사를 사용하여 오류가 발생하거나 중단된 컨테이너를 다시 시작합니다.
자동화된 운영
쿠버네티스에는 노동 집약적인 애플리케이션 관리 작업을 처리하는 명령이 내장되어 있어 쿠버네티스를 사용해 일상적인 시스템 관리 작업을 자동화할 수 있습니다. 쿠버네티스는 애플리케이션이 항상 설정된 대로 실행되도록 만들 수 있습니다.
인프라 추상화
쿠버네티스는 워크로드를 대신하여 컴퓨팅, 네트워킹 및 스토리지를 처리합니다. 따라서 개발자는 기저 환경에 대해 신경을 쓰지 않고 애플리케이션에 집중할 수 있습니다.
쿠버네티스가 모니터링 전략을 변경하는 방법
“쿠버네티스는 이해하기 쉽다”라고 말하는 사람이 있다면 아마 거짓말을 하고 있는 것입니다.
특히 가상 머신이나 온프레미스 서버 같은 기존 호스트에서 마이그레이션하는 경우, 쿠버네티스는 모니터링에 대한 새로운 접근 방식이 필요합니다.
컨테이너는 사용 수요에 맞춰 배포 및 재배포되기 때문에 한 번에 몇 분 동안만 지속될 수 있습니다. 더 이상 존재하지 않는데 어떻게 문제를 해결할 수 있을까요?
또한, 컨테이너는 전 세계의 물리적 서버에 위치한 여러 호스트에 분산되어 있습니다. 수집하고 있는 메트릭에 대한 적절한 컨텍스트가 없다면, 실패한 프로세스와 그 영향을 받는 애플리케이션을 연관시키기가 어려울 수 있습니다.
수명이 짧은 다수의 컨테이너를 모니터링하기 위해, 쿠버네티스에는 애플리케이션의 성능을 이해하는 데 도움을 주는 툴과 API가 내장되어 있습니다. 쿠버네티스를 활용하는 모니터링 전략을 사용하면 애플리케이션을 실행하는 컨테이너가 지속적으로 호스트 간에 이동하거나 확장 또는 축소되는 경우에도 전체 애플리케이션의 성능을 한 눈에 파악할 수 있습니다.
증가된 모니터링 책임
스택에 대한 완전한 가시성을 확보하려면 인프라를 모니터링해야 합니다. 현대의 기술 스택은 애플리케이션과 인프라 간의 관계를 과거보다 더 복잡하게 만들었습니다.
기존 인프라
기존 인프라 환경에서는 애플리케이션과 이를 실행하는 호스트(서버 또는 가상 머신)만 모니터링하면 되었습니다.
컨테이너의 도입
2013년, Docker는 컨테이너화를 세상에 선보였습니다. 컨테이너는 격리되고 예측 가능하며 반복 가능한 방식으로 애플리케이션과 그 종속성을 패키징하고 실행하는 데 사용됩니다. 이를 통해 인프라와 애플리케이션 사이에는 추상화 계층이 추가됩니다. 애플리케이션 대신 워크로드를 실행한다는 점에서 컨테이너는 기존 호스트와 유사합니다.
쿠버네티스
쿠버네티스를 사용하면 스택을 완전하게 파악할 수 있으므로 계속 자동으로 스핀업하며 수명이 다해가는 컨테이너에서 텔레메트리 데이터를 수집하는 동시에 쿠버네티스 자체에서도 텔레메트리 데이터를 수집할 수 있습니다. 창고에 위치한 서버에 켜진 표시등 몇 개를 확인하던 시대는 지났습니다!
쿠버네티스 환경에서는 모니터링해야 하는 4가지 구성 요소가 있으며, 각 요마다 특징과 도전과제가 다릅니다.
- 인프라(* 작업자 노드)
- 컨테이너
- 애플리케이션
- 쿠버네티스 클러스터(* 컨트롤 플레인)
* 이러한 개념은 이 가이드의 2부에서 다뤄집니다.
애플리케이션 메트릭과 인프라 메트릭 및 메타데이터를 상호 연관
쿠버네티스가 확장 가능한 애플리케이션을 쉽게 구축할 수 있도록 지원하면서, 애플리케이션과 인프라 간의 경계선이 모호해졌습니다. 개발자는 클러스터의 성능이 아니라 애플리케이션에 주로 초점을 맞추지만, 클러스터의 기본 구성 요소는 애플리케이션의 성능에 직접적인 영향을 미칠 수 있습니다. 예를 들어 쿠버네티스 애플리케이션의 버그는 물리적인 인프라 문제로 인해 발생할 수 있지만 구성 오류나 코딩 문제로 인해 발생할 수도 있습니다.
쿠버네티스를 사용할 때 애플리케이션 모니터링은 선택 사항이 아니라, 필수 사항입니다!
대부분의 애플리케이션 성능 모니터링(APM) 언어 에이전트는 애플리케이션이 실행되는 위치와 상관이 없습니다. 에이전트는 잊혀진 랙의 오래된 Linux 서버나 최신 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 실행될 수 있습니다. 그러나 오케스트레이션 계층에서 관리되는 애플리케이션을 모니터링할 때, 인프라에 대한 컨텍스트가 있으면 애플리케이션 오류 트레이스를 실행 중인 컨테이너, 파드 또는 호스트와 연관시킬 수 있기 때문에 디버깅이나 문제 해결에 매우 유용할 수 있습니다.
쿠버네티스에서 레이블 구성
쿠버네티스는 다양한 수명 주기를 가진 컨테이너의 생성 및 삭제를 자동화합니다. 이러한 전체 프로세스는 모니터링되어야 합니다. 변경되는 부분이 너무 많기 때문에, 측정 지표를 해당 애플리케이션, 파드, 네임스페이스, 노드 등에 매치시키려면 조직 전반에서 명확한 레이블 지정 정책을 수립해야 합니다.
서로 다른 객체에 일관성 있는 레이블을 연결시키면 쿠버네티스 클러스터에서 이러한 객체들을 쉽게 쿼리할 수 있습니다. 예를 들어, 개발자로부터 운영 환경이 다운되었는지 묻는 전화가 왔다고 가정해 보겠습니다. 운영 포드에 ‘파드’ 레이블이 있는 경우, 다음과 같은 kubtl 명령을 실행하여 모든 로그를 가져올 수 있습니다.
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/GB의 무료 데이터 인제스트가 포함됩니다.
이 블로그에 표현된 견해는 저자의 견해이며 반드시 New Relic의 견해를 반영하는 것은 아닙니다. 저자가 제공하는 모든 솔루션은 환경에 따라 다르며 New Relic에서 제공하는 상용 솔루션이나 지원의 일부가 아닙니다. 이 블로그 게시물과 관련된 질문 및 지원이 필요한 경우 Explorers Hub(discuss.newrelic.com)에서만 참여하십시오. 이 블로그에는 타사 사이트의 콘텐츠에 대한 링크가 포함될 수 있습니다. 이러한 링크를 제공함으로써 New Relic은 해당 사이트에서 사용할 수 있는 정보, 보기 또는 제품을 채택, 보증, 승인 또는 보증하지 않습니다.
