이제 나도 클라우드 네이티브 전문가: 쿠버네티스 구축부터 운영 완전 정복

쿠버네티스 클러스터가 커지면서 그 안에서 관리해야 하는 오브젝트의 수가 점점 늘어나면, 이들을 효율적으로 식별하고, 그룹화하며, 특정 오브젝트 집합에 대해 일괄적인 작업을 수행하는 것이 매우 중요해집니다. 마치 수많은 책이 꽂힌 도서관에서 원하는 책을 쉽게 찾기 위해 분류 체계가 필요하듯이, 쿠버네티스에서도 오브젝트들을 체계적으로 관리하기 위한 메커니즘이 필요합니다. 바로 이 역할을 수행하는 핵심적인 도구가 레이블(Labels)과 셀렉터(Selectors)입니다. 이번 섹션에서는 레이블을 사용하여 오브젝트에 의미 있는 식별 정보를 부여하고, 셀렉터를 통해 이러한 정보를 바탕으로 원하는 오브젝트들을 정확하게 찾아내고 연결하는 방법을 자세히 알아보겠습니다. 레이블과 셀렉터는 쿠버네티스의 느슨하게 결합된(loosely coupled) 아키텍처를 가능하게 하는 매우 중요한 개념이며, 이를 잘 활용하면 클러스터 운영의 유연성과 효율성을 크게 향상시킬 수 있습니다.

• 레이블(Labels)은 쿠버네티스 오브젝트(예: 파드, 서비스, 디플로이먼트, 노드 등)에 첨부할 수 있는 키-값 쌍(key-value pairs) 형태의 메타데이터입니다. 마치 물건에 이름표나 태그를 붙이듯이, 레이블을 사용하여 각 오브젝트에 사용자가 원하는 다양한 식별 정보나 속성을 부여할 수 있습니다. 이러한 레이블은 오브젝트의 핵심 기능에는 직접적인 영향을 미치지 않지만, 오브젝트들을 의미 있는 방식으로 분류하고 그룹화하는 데 매우 유용하게 사용됩니다.
• 레이블의 특징 및 구문:
  • 각 레이블은 키(key)와 값(value)으로 구성되며, 하나의 오브젝트에는 여러 개의 레이블을 가질 수 있습니다.
  • 레이블 키는 고유해야 하며, 일반적으로 도메인 접두사(선택 사항)와 이름 부분으로 구성됩니다 (예: app.kubernetes.io/name). 접두사가 없는 키는 사용자에게 예약된 것으로 간주됩니다.
  • 레이블 키와 값은 문자열이며, 특정한 문법 규칙(예: 길이 제한, 허용되는 문자 등)을 따릅니다. (자세한 내용은 공식 문서를 참고하세요.)
  • 레이블은 오브젝트의 metadata 필드 아래 labels 맵(map)에 정의됩니다. 예를 들어, 파드 매니페스트 파일에서 다음과 같이 레이블을 정의할 수 있습니다.

• 레이블의 활용 목적:레이블은 단순히 오브젝트를 식별하는 것을 넘어, 다음과 같은 다양한 목적으로 활용될 수 있습니다.
  • 조직화 및 필터링: kubectl get pods -l environment=production과 같이 특정 레이블을 가진 오브젝트들만 쉽게 조회하고 관리할 수 있습니다. 이는 대규모 클러스터에서 특정 애플리케이션, 환경, 팀, 또는 버전과 관련된 리소스들을 효율적으로 찾는 데 매우 유용합니다.
  • 서비스 디스커버리 및 로드 밸런싱: Service 오브젝트는 레이블 셀렉터를 사용하여 자신이 트래픽을 전달해야 할 백엔드 파드들을 동적으로 식별합니다. 서비스는 특정 레이블(예: app=my-app)을 가진 모든 파드들을 자신의 엔드포인트로 간주하고 이들 사이에서 로드 밸런싱을 수행합니다. 이는 파드의 IP 주소가 변경되더라도 서비스가 항상 올바른 파드들과 연결될 수 있도록 하는 핵심 메커니즘입니다.
  • 디플로이먼트 및 워크로드 관리: Deployment, ReplicaSet, StatefulSet, DaemonSet, Job과 같은 워크로드 컨트롤러들은 레이블 셀렉터를 사용하여 자신이 관리해야 할 파드들을 식별하고 제어합니다. 예를 들어, Deployment는 특정 레이블을 가진 ReplicaSet을 생성하고, 이 ReplicaSet은 다시 동일한 레이블을 가진 파드들을 생성하고 관리합니다.
  • 스케줄링 제약 조건: 노드 어피니티(Node Affinity)나 파드 안티-어피니티(Pod Anti-affinity)와 같은 고급 스케줄링 규칙을 정의할 때, 레이블을 사용하여 특정 노드나 다른 파드와의 관계를 명시할 수 있습니다. 예를 들어, “이 파드는 region=us-east 레이블이 붙은 노드에만 배치되어야 한다” 또는 “이 파드는 app=database 레이블이 붙은 다른 파드와는 같은 노드에 배치되지 않아야 한다”와 같은 규칙을 설정할 수 있습니다.
  • 리소스 할당 및 정책 적용: 특정 레이블을 가진 오브젝트 그룹에 대해 리소스 쿼터(ResourceQuota)를 설정하거나, 네트워크 정책(NetworkPolicy)을 적용하여 네트워크 접근을 제어하는 등 정책 기반 관리에 활용될 수 있습니다.
  • 비용 추적 및 관리: 클라우드 환경에서는 특정 프로젝트나 팀에 속한 리소스에 레이블을 부여하여 비용을 추적하고 할당하는 데 사용될 수 있습니다.
• 권장 레이블 (Recommended Labels):쿠버네티스 커뮤니티에서는 애플리케이션을 설명하는 데 유용한 표준화된 레이블 키 세트를 권장하고 있습니다. 이를 사용하면 다양한 도구나 대시보드에서 일관된 방식으로 애플리케이션을 식별하고 시각화하는 데 도움이 됩니다. 주요 권장 레이블은 다음과 같습니다 (보통 app.kubernetes.io/ 접두사를 사용합니다).
  • app.kubernetes.io/name: 애플리케이션의 이름 (예: mysql, nginx)
  • app.kubernetes.io/instance: 애플리케이션의 특정 인스턴스를 식별하는 고유 이름 (예: mysql-primary, nginx-blue)
  • app.kubernetes.io/version: 현재 애플리케이션의 버전 (예: 5.7.21, 1.19.0)
  • app.kubernetes.io/component: 아키텍처 내에서 이 컴포넌트의 역할 (예: database, web, api)
  • app.kubernetes.io/part-of: 이 애플리케이션이 속한 더 큰 규모의 애플리케이션 이름 (예: wordpress)
  • app.kubernetes.io/managed-by: 이 리소스를 관리하는 도구 (예: helm, kustomize, operator-sdk)

  이러한 권장 레이블을 사용하는 것은 필수는 아니지만, 클러스터 관리의 일관성과 상호 운용성을 높이는 데 좋은 관행입니다.

레이블은 단순하지만 매우 강력한 개념입니다. 사용자가 자유롭게 의미를 부여하고 오브젝트를 분류할 수 있는 유연성을 제공하며, 이는 쿠버네티스의 다른 많은 기능들이 원활하게 동작하도록 하는 기반이 됩니다. 중요한 것은, 레이블은 오브젝트 간의 관계를 정의하는 데 사용되며, 식별 및 선택을 위한 것이지, 임의의 메타데이터를 저장하는 용도가 아니라는 점입니다. 임의의 비식별 메타데이터는 주로 어노테이션을 사용합니다.

레이블이 오브젝트에 이름표를 붙이는 행위라면, 셀렉터(Selectors)는 이 이름표를 보고 원하는 물건(오브젝트)들만 골라내는 도구와 같습니다. 즉, 셀렉터는 특정 레이블 키-값 쌍을 기준으로 오브젝트 집합을 식별하고 필터링하는 방법을 정의합니다. 쿠버네티스에서 많은 컨트롤러(예: Service, Deployment, ReplicaSet)들은 바로 이 셀렉터를 사용하여 자신이 관리하거나 상호작용해야 할 대상 오브젝트들을 찾아냅니다.

쿠버네티스에는 두 가지 주요 유형의 레이블 셀렉터가 있습니다.

가장 일반적이고 간단한 형태의 셀렉터입니다. 특정 레이블 키가 특정 값을 가지고 있거나(equality, =), 가지고 있지 않은(inequality, !=) 오브젝트를 선택합니다. 여러 개의 레이블 조건을 쉼표(,)로 구분하여 나열하면, 모든 조건을 동시에 만족하는(AND 연산) 오브젝트만 선택됩니다.

• kubectl에서의 사용법 (-l 또는 –selector 옵션):kubectl get pods -l environment=production : environment 레이블의 값이 production인 모든 파드를 조회합니다.kubectl get pods -l ‘app=my-app,tier=frontend’ : app 레이블이 my-app이고 동시에 tier 레이블이 frontend인 모든 파드를 조회합니다. (쉼표로 연결된 조건은 AND로 동작합니다.)kubectl get pods -l ‘environment!=staging’ : environment 레이블의 값이 staging이 아닌 모든 파드를 조회합니다. (또는 environment notin (staging)과 같이 집합 기반 셀렉터로 표현 가능)
• 매니페스트 파일에서의 사용법 (예: Service의 selector 필드):Service 오브젝트는 spec.selector 필드를 사용하여 자신이 트래픽을 전달할 백엔드 파드들을 선택합니다.
  클립보드에 복사

  Syntax HighlighterapiVersion: v1 kind: Service metadata: name: my-app-service spec: selector: app: my-app # 'app' 레이블이 'my-app'인 파드들을 선택 tier: backend # 그리고 'tier' 레이블이 'backend'인 파드들을 선택 ports: - protocol: TCP port: 80 targetPort: 8080
  위 예시에서 my-app-service는 app: my-app 레이블과 tier: backend 레이블을 모두 가진 파드들에게만 트래픽을 전달합니다.

등가 기반 셀렉터보다 더 표현력이 풍부하며, 레이블 값의 집합에 대한 포함/비포함 관계를 기준으로 오브젝트를 선택할 수 있습니다. 세 가지 주요 연산자를 사용합니다.

• in: 특정 레이블 키의 값이 지정된 값들의 집합 안에 포함되는 오브젝트를 선택합니다. (예: environment in (production, qa))
• notin: 특정 레이블 키의 값이 지정된 값들의 집합 안에 포함되지 않는 오브젝트를 선택합니다. (예: tier notin (frontend, cache))
• exists (키 존재 여부): 특정 레이블 키를 가지고 있는 모든 오브젝트를 선택합니다 (값은 중요하지 않음). (예: partition – partition이라는 레이블 키를 가진 모든 오브젝트)
• doesNotExist (키 부재 여부, 공식적인 연산자는 아니지만 !와 함께 사용 가능): 특정 레이블 키를 가지고 있지 않은 모든 오브젝트를 선택합니다. (예: !partition – partition이라는 레이블 키가 없는 모든 오브젝트)
• kubectl에서의 사용법:kubectl get pods -l ‘environment in (production,qa)’ : environment 레이블의 값이 production 또는 qa 중 하나인 모든 파드를 조회합니다.

  kubectl get pods -l ‘tier notin (frontend)’ : tier 레이블의 값이 frontend가 아닌 모든 파드를 조회합니다.

  kubectl get pods -l ‘partition’ : partition이라는 레이블 키를 가진 모든 파드를 조회합니다.

  kubectl get pods -l ‘!ssd’ : ssd라는 레이블 키를 가지고 있지 않은 모든 파드를 조회합니다.

  등가 기반 셀렉터와 집합 기반 셀렉터를 쉼표로 연결하여 함께 사용할 수도 있습니다. (예: kubectl get pods -l ‘app=my-app,environment in (dev,staging)’)

• 매니페스트 파일에서의 사용법 (예: Deployment의 spec.selector.matchExpressions 필드):워크로드 컨트롤러(예: Deployment, ReplicaSet)의 spec.selector 필드에서는 matchLabels (등가 기반) 또는 matchExpressions (집합 기반)를 사용하여 관리할 파드를 선택할 수 있습니다.
  클립보드에 복사

  Syntax HighlighterapiVersion: apps/v1 kind: Deployment metadata: name: my-complex-app spec: replicas: 3 selector: matchLabels: # 등가 기반 조건 (선택 사항, matchExpressions와 함께 사용 가능) app: my-complex-app matchExpressions: # 집합 기반 조건 - {key: tier, operator: In, values: [frontend, api]} - {key: customer, operator: NotIn, values: [internal]} - {key: experimental, operator: Exists} template: # 파드 템플릿 ... metadata: labels: # 생성될 파드에 적용될 레이블 (반드시 셀렉터 조건과 일치해야 함) app: my-complex-app tier: frontend experimental: "true" # ...
  위 예시에서 디플로이먼트는 app: my-complex-app 레이블을 가지고, tier 레이블이 frontend 또는 api 중 하나이며, customer 레이블이 internal이 아니고, experimental 레이블을 가지고 있는 파드들을 관리하게 됩니다. 중요한 점은, spec.template.metadata.labels에 정의된 파드 템플릿의 레이블이 spec.selector의 조건과 반드시 일치해야 한다는 것입니다. 그렇지 않으면 디플로이먼트는 자신이 생성한 파드를 인식하지 못하는 문제가 발생할 수 있습니다.

레이블과 셀렉터의 강력한 조합:

레이블과 셀렉터는 서로를 보완하며 쿠버네티스에서 오브젝트들을 느슨하게 연결하고 관리하는 핵심적인 메커니즘을 제공합니다.

• 서비스와 파드의 연결: 서비스는 셀렉터를 사용하여 동적으로 파드 그룹을 식별하고 트래픽을 분배합니다. 파드에 레이블을 변경하거나 새로운 파드를 추가/삭제하면 서비스는 자동으로 이를 감지하고 엔드포인트를 업데이트합니다.
• 워크로드 컨트롤러와 파드의 연결: 디플로이먼트, 레플리카셋 등은 셀렉터를 사용하여 자신이 관리해야 할 파드 집합을 정의합니다. 이를 통해 원하는 수의 파드 복제본을 유지하고, 롤링 업데이트나 롤백과 같은 정교한 배포 전략을 수행할 수 있습니다.
• 유연한 리소스 관리: 관리자는 kubectl 명령어에서 셀렉터를 사용하여 특정 기준을 만족하는 오브젝트들만 선택하여 조회, 수정, 삭제하는 등의 작업을 효율적으로 수행할 수 있습니다.

결론적으로, 레이블과 셀렉터는 쿠버네티스에서 오브젝트들을 조직화하고, 서로 다른 컴포넌트들이 동적으로 상호작용할 수 있도록 하는 데 필수적인 도구입니다. 마치 잘 정리된 데이터베이스에서 인덱스와 쿼리를 사용하여 원하는 정보를 효율적으로 찾는 것처럼, 레이블과 셀렉터를 잘 활용하면 복잡한 쿠버네티스 환경에서도 원하는 오브젝트를 정확하게 찾아내고, 애플리케이션의 배포와 관리를 훨씬 더 유연하고 지능적으로 수행할 수 있게 될 것입니다. 처음에는 다소 복잡하게 느껴질 수 있지만, 실제로 사용해보면서 그 강력함과 편리함을 경험해보시길 바랍니다.