• 규모가 크지 않을 경우에는 시스템 전체를 구성하기 위한 모든 마이크로서비스의 매니페스트 파일을 하나의 디렉터리로 통합하여 사용하는 것이 좋다.
• 마이크로서비스마다 디렉터리로 구분하여 리소스 종류별로 파일을 생성할 수도 있다.
  • 가독성이 높아진다는 장점은 있지만, 적용 순서 제어가 어렵다.

하나의 매니페스트 파일에 여러 리소스를 정의

• 한 개의 매니페스트 파일에 여러 리소스를 정의하거나 여러 매니페스트 파일을 동시에 적용할 수 있다.
• 일반적인 사용 사례로 ‘파드를 기동하는 워크로드 API 카테고리의 리소스’와 ‘외부에 공개하는 서비스 API 카테고리의 리소스’를 매니페스트에 통합하여 작성하는 방법이 있다.
• 단, 공통으로 사용되는 리소스는 별도 매니페스트로 분리하는 것이 좋다.

어노테이션과 레이블

• 어노테이션과 레이블은 ‘[접두사]/키:값’으로 구성된다.
• 어노테이션 : 시스템 구성 요소가 사용하는 메타데이터
  • 리소스에 대한 메모로 볼 수 있다.
  • metadata.annotations
  • 사용 목적
    • 시스템 구성 요소를 위한 데이터 저장
    • 모든 환경에서 사용할 수 없는 설정
      • 클라우드 환경에서 사용할 수 있다.
      • 클라우드 프로바이더나 벤더가 독자적으로 구현한 확장 설정은 다른 쿠버네티스 환경에서는 당연히 사용할 수 없다.
      • 쿠버네티스 클러스터의 파드에 대해 클러스터 외부에서 접속할 수 있도록 외부 로드 밸런서 등과 연계하는 서비스 리소스를 예로 들 수 있다.
      • GKE의 ‘cloud.google.com/load-balancer-type: “Internal”’
    • 정식으로 통합되기 전의 기능을 설정
      • 쿠버네티스에 공식적으로 통합되기 전의 실험적인 기능과 평가 중인 새로운 기능 설정을 어노테이션으로 사용할 수 있다.
      • 스토리지클래스(StorageClass)나 초기화 컨테이너(Init Container) 등의 설정도 이전에는 어노테이션으로 설정해야 했다.
• 레이블 : 리소스 관리에 사용하는 메타데이터
  • 리소스를 구분하기 위한 정보같은 것
  • 매니페스트로 작성할 수도 있고, kubectl에서 직접 부여할 수도 있다.
  • 사용 목적
    • 개발자가 사용하는 레이블
    • 시스템이 사용하는 레이블
  • 권장 레이블 키 이름
    • app.kubernetes.io/name : 애플리케이션 이름
    • app.kubernetes.io/version : 애플리케이션 버전
    • app.kubernetes.io/component : 애플리케이션 내 구성 요소
    • app.kubernetes.io/part-of : 애플리케이션이 전체적으로 구성하는 시스템 이름
    • app.kubernetes.io/instance : 애플리케이션이나 시스템을 식별하는 인스턴스명
    • app.kubernetes.io/managed-by : 이 애플리케이션을 관리하는 데 사용되는 도구