[쿠버네티스] Object를 그려보며 쿠버네티스 이해 #7

1. 레이블-셀렉터 시스템의 중요성

• 레이블과 셀렉터 시스템은 단순한 메타데이터가 아닌 오브젝트 간 연결의 핵심 메커니즘

• 체계적인 네이밍과 레이블링은 팀 협업과 시스템 유지보수의 필수 요소

• 초기 설계의 중요성과 운영 중 변경의 어려움 고려 필요

2. 기본 환경 구성과 네임스페이스

2.1 마스터 노드 디렉토리 구조

• Kubernetes 실습을 위한 마스터 노드 디렉토리 구조 생성 필요

• Pod에서 파일 저장 용도로 사용되며 Persistent Volume과 연결되는 중요한 구성 요소

/root/k8s-local-volume/1231

• 로컬 볼륨을 활용한 데이터 저장 시나리오에서 필수적

• Pod 생성 전에 미리 준비되어야 함

• 실제 운영에서는 네트워크 스토리지나 클라우드 스토리지 사용 권장

2.2 네임스페이스의 역할과 네이밍

네임스페이스 기본 구조

apiVersion: v1
kind: Namespace
metadata:
  name: anotherclass-123
  labels:
    part-of: k8s-anotherclass
    managed-by: kubectl

• 클러스터 내에서 고유한 이름 보유 필수

• 수업별 넘버링(123)을 통한 실습 환경 격리

• 각 수업에서 생성된 오브젝트가 다른 수업에 영향 미치지 않도록 구성

네임스페이스 네이밍 전략

• 포함될 애플리케이션의 범위를 명확히 표현

• 예시: monitoring (모니터링 관련 앱들), anotherclass-123 (실습 환경)

• 기능별, 환경별, 팀별 구분 기준 적용

오브젝트 이름 중복 관리 규칙

• 네임스페이스 내에서 같은 종류 오브젝트 간 이름 중복 불허

• 서로 다른 종류 오브젝트(Deployment와 Service)는 같은 이름 허용

• 각 오브젝트 타입이 독립적인 네임스페이스를 가지기 때문

네임스페이스 삭제와 연쇄 효과

• 네임스페이스 삭제 시 해당 네임스페이스에 속한 모든 오브젝트 함께 삭제

• 실습 환경 정리 작업에 유용하지만 운영 환경에서는 신중히 사용

• 한 번의 명령으로 전체 프로젝트 리소스 일괄 삭제 가능

참고: Persistent Volume(PV) 같은 클러스터 레벨 오브젝트는 네임스페이스 삭제 시에도 별도 삭제 필요

3. 레이블 시스템의 이해

3.1 레이블링의 개념과 현실적 비유

옷 라벨과 Kubernetes 레이블의 유사성

• 옷에 붙은 라벨을 통해 제조 정보, 세탁 방법 등을 한눈에 파악 가능

• Kubernetes에서도 동일한 원리로 오브젝트 관리와 식별에 활용

• 아무리 옷이 많아도 라벨만 잘 붙어있으면 정보 파악 가능

레이블링의 실무적 가치

• 초기에는 필요성을 못 느끼지만 오브젝트 수가 증가하면서 관리의 복잡성 증대

• 체계적인 라벨링을 통해 오브젝트가 속한 애플리케이션 정보를 즉시 파악

• 운영 효율성과 장애 대응 속도에 직접적 영향

• 팀 협업과 지식 공유에 필수적인 요소

3.2 레이블의 두 가지 역할

정보성 라벨링

• 오브젝트에 대한 메타 정보 제공

• 애플리케이션 식별, 버전 관리, 소유자 정보 등

• 사람이 읽고 이해하기 위한 목적

기능성 라벨링

• 오브젝트 간 연결과 선택을 위한 식별자

• 셀렉터를 통한 자동 매칭과 연결

• 시스템이 동작하기 위한 필수 요소

3.3 Kubernetes 권장 레이블 구조

Prometheus를 통한 실제 사례 분석

• Kubernetes에서 권고하는 레이블링 방법을 실제로 적용한 사례

• 체계적인 레이블 구조를 통한 효과적인 오브젝트 관리 방법 제시

app.kubernetes.io/part-of: 애플리케이션 전체 이름

labels:
  app.kubernetes.io/part-of: kube-prometheus

• 전체 서비스를 대표하는 최상위 레이블

• 여러 컴포넌트로 구성된 애플리케이션의 통합 식별자

• 마이크로서비스 아키텍처에서 서비스 그룹핑에 활용

app.kubernetes.io/component: 기능별 구성 요소

labels:
  app.kubernetes.io/component: prometheus

• 애플리케이션 내에서 각각의 분리된 기능을 나타냄

• Prometheus: 메트릭 수집과 성능 정보 API 제공

• Exporter: 메트릭 데이터 제공

• Grafana: 데이터 시각화

• 기능별 명확한 역할 구분을 통한 관리 효율성 증대

app.kubernetes.io/name: 실제 애플리케이션 이름

labels:
  app.kubernetes.io/name: prometheus

• 구체적인 애플리케이션의 실제 이름

• Component와 Name의 차이점 이해 중요

• 하나의 Component 내에 여러 Name이 존재 가능

• 예시: exporter component 내 kube-state-metrics, node-exporter 등

app.kubernetes.io/instance: 인스턴스 식별자

labels:
  app.kubernetes.io/instance: prometheus-k8s

• 동일한 애플리케이션을 여러 개 설치할 때 구분하는 식별자

• 환경별(dev, staging, prod) 또는 목적별 구분에 활용

• 클러스터 내 동일 애플리케이션의 복수 배포 시 필수

• 인스턴스별 독립적인 관리와 모니터링 가능

app.kubernetes.io/version: 애플리케이션 버전

labels:
  app.kubernetes.io/version: "2.44.0"

• 배포된 애플리케이션의 버전 정보

• 다른 레이블과 달리 애플리케이션 업데이트 시 변경 필요

• 롤백과 버전 관리에 중요한 정보

• 카나리 배포나 A/B 테스트 시 버전 구분에 활용

app.kubernetes.io/managed-by: 관리 도구

labels:
  app.kubernetes.io/managed-by: helm

• 오브젝트를 생성하고 관리하는 도구 식별

• kubectl, helm, kustomize, ArgoCD 등 배포 도구 구분

• 관리 주체 명확화를 통한 책임 소재 확실화

• 자동화 도구와 수동 관리의 구분

3.4 실습 환경의 레이블 구조

강의에서 사용된 실제 레이블 구조

metadata:
  labels:
    app.kubernetes.io/part-of: k8s-anotherclass
    app.kubernetes.io/component: backend-server
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231
    app.kubernetes.io/version: "1.0.0"
    app.kubernetes.io/managed-by: kubectl

• 체계적인 레이블 구조를 실제 적용한 사례

• 수업별 인스턴스 넘버링(1231)으로 중복 방지

• 백엔드 서버 기능을 명확히 표시

3.5 커스텀 레이블과 프리픽스 활용

도메인 기반 프리픽스

labels:
  app.kubernetes.io/name: api-tester
  company.com/team: platform
  custom.domain.com/owner: devops-team

• 도메인 프리픽스를 통한 레이블 네임스페이스 구분

• 여러 조직이나 팀에서 동일한 클러스터 사용 시 충돌 방지

• 표준 레이블과 커스텀 레이블의 명확한 구분

기타 유용한 레이블들

labels:
  # 환경 정보
  environment: production
  stage: dev
  # 소유권 정보  
  owner: team-backend
  # 애플리케이션 역할
  app-role: server
  # 릴리즈 정보
  release: release-1.2.1

4. Deployment와 Pod 관리 체계

4.1 Deployment의 역할과 구조

• Deployment는 Pod 생성과 업그레이드를 담당하는 핵심 오브젝트

• 애플리케이션 생명주기 관리에서 가장 중요한 역할 수행

• 선언적 방식으로 원하는 상태 정의 및 유지

기본 구조

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: anotherclass-123
  name: api-tester-1231
  labels:
    app.kubernetes.io/part-of: k8s-anotherclass
    app.kubernetes.io/component: backend-server
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231
    app.kubernetes.io/version: "1.0.0"
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app.kubernetes.io/name: api-tester
      app.kubernetes.io/instance: api-tester-1231

4.2 Deployment-ReplicaSet-Pod 생성 메커니즘

실제 동작 과정

• Deployment 생성: api-tester-1231 이름으로 Deployment 생성

• ReplicaSet 자동 생성: Kubernetes가 api-tester-1231-xxxx 형태로 ReplicaSet 생성

• Pod 생성: ReplicaSet이 api-tester-1231-xxxx-yyyy 형태로 Pod 생성

이름 생성 규칙

Deployment: api-tester-1231
    ↓ (임의 문자열 추가)
ReplicaSet: api-tester-1231-abc123
    ↓ (추가 임의 문자열)
Pod: api-tester-1231-abc123-def456

• Deployment 이름에 임의의 문자열을 추가하여 ReplicaSet 이름 생성

• ReplicaSet 이름에 다시 임의 문자열을 추가하여 Pod 이름 생성

• 각 레벨에서 고유성 보장

역할 분담

• Deployment: Pod의 업데이트와 롤백 관리 담당

• ReplicaSet: Pod의 복제본 수 유지와 생성/삭제 담당

• Pod: 실제 애플리케이션 컨테이너 실행

ReplicaSet의 Pod 관리 특성

• ReplicaSet이 실제로 replicas 수만큼 Pod 생성

• Pod 하나가 삭제되면 ReplicaSet이 즉시 감지하여 새 Pod 생성

• 항상 지정된 수의 Pod를 유지하는 자가 치유 메커니즘

4.3 Pod 템플릿과 레이블 상속

template:
  metadata:
    labels:
      app.kubernetes.io/part-of: k8s-anotherclass
      app.kubernetes.io/component: backend-server
      app.kubernetes.io/name: api-tester
      app.kubernetes.io/instance: api-tester-1231
      app.kubernetes.io/version: "1.0.0"
  spec:
    nodeSelector:
      kubernetes.io/hostname: k8s-master
    containers:
    - name: app
      image: kubetm/app

• Pod 템플릿의 레이블이 실제 생성되는 모든 Pod에 적용

• nodeSelector를 통한 특정 노드 배치 설정

• 마스터 노드의 실제 레이블(kubernetes.io/hostname: k8s-master)과 매칭

5. 셀렉터를 통한 오브젝트 연결

5.1 레이블-셀렉터 매칭 시스템

기본 동작 원리

• 레이블은 단순히 정보 제공용이 아닌 오브젝트 간 연결의 핵심 메커니즘

• 셀렉터를 통해 두 오브젝트를 동적으로 연결

• 추가적인 기능이 있는 바로 셀렉터와 매칭되어 두 오브젝트를 연결하는데 사용

매칭 규칙

# Deployment의 selector
selector:
  matchLabels:
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231

# Pod의 labels (매칭 대상)
metadata:
  labels:
    app.kubernetes.io/part-of: k8s-anotherclass
    app.kubernetes.io/component: backend-server
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231
    app.kubernetes.io/version: "1.0.0"

• 셀렉터의 모든 조건이 레이블에 존재해야 매칭 성공

• 레이블에 추가 키-값 쌍이 있어도 매칭에 영향 없음 (버전처럼 레이블에 추가로 더 있는 건 괜찮음)

• 셀렉터에만 있고 레이블에 없는 조건이 있으면 매칭 실패

인스턴스 기반 고유 매칭

• 인스턴스 이름의 고유성을 활용한 단순 매칭 전략

• 복잡한 다중 조건 대신 인스턴스만으로도 정확한 매칭 가능

• 추가 레이블 조건은 선택사항으로 유연한 운영 가능

5.2 주요 오브젝트별 연결 방식

Deployment ↔ ReplicaSet ↔ Pod

# Deployment selector → ReplicaSet 연결
selector:
  matchLabels:
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231

# ReplicaSet selector → Pod 연결 (동일한 selector 사용)

• Deployment가 ReplicaSet을 통해 Pod 관리

• 레이블-셀렉터 매칭을 통한 계층적 연결 구조

Service ↔ Pod

# Service
apiVersion: v1
kind: Service
metadata:
  name: api-tester-1231
spec:
  selector:
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231
  ports:
  - port: 80
    targetPort: 8080

• Service가 해당 레이블을 가진 모든 Pod에 트래픽 라우팅

• 동적 Pod 생성/삭제에도 자동으로 연결 관계 유지

HPA ↔ Deployment

# HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-tester-1231-default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-tester-1231  # 직접 이름 참조

• HPA는 scaleTargetRef를 통해 Deployment 직접 참조

• 레이블-셀렉터 방식이 아닌 이름 기반 참조

5.3 PVC와 PV 연결

# PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: api-tester-1231-files
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: api-tester
      app.kubernetes.io/instance: api-tester-1231-files
      
# PV  
apiVersion: v1
kind: PersistentVolume
metadata:
  name: api-tester-1231-files
  labels:
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231-files

• 스토리지 리소스 할당에서도 동일한 매칭 메커니즘 적용

• 특정 요구사항에 맞는 PV 자동 선택

5.4 Kubernetes의 두 가지 연결 방식

레이블-셀렉터 방식

• Deployment, Service, ReplicaSet, PVC 등에서 주로 사용

• 유연하고 동적인 연결 관계 지원

• 조건 기반 다중 오브젝트 선택 가능

직접 이름 참조 방식

• ConfigMap, Secret, PVC 등에서 사용

• Pod 설정에서 직접 오브젝트 이름 지정

volumes:
- name: config-volume
  configMap:
    name: api-tester-1231-config

• HPA의 scaleTargetRef: Deployment를 직접 이름으로 참조

• 각 오브젝트 타입별 최적화된 연결 방식 제공

6. 다양한 셀렉터 문법

6.1 기본 문법 (Service 등)

selector:
  app: api-tester
  instance: api-tester-1231

6.2 matchLabels 문법 (Deployment, ReplicaSet, PVC 등)

selector:
  matchLabels:
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231

6.3 노드 어피니티의 복잡한 표현

nodeAffinity:
  required:
    nodeSelectorTerms:
    - matchExpressions:
      - key: kubernetes.io/hostname
        operator: In
        values:
        - k8s-master

• 마스터 노드의 실제 레이블과 매칭

• 복잡한 조건식을 통한 정교한 노드 선택

6.4 실무에서의 셀렉터 관리 전략

• 모든 문법을 암기할 필요 없음

• 검증된 템플릿 활용하여 필요한 부분만 수정

• 점진적 학습을 통한 복잡한 패턴 습득

• 개인 또는 팀 차원의 템플릿 라이브러리 구축 권장

• Google Drive나 개인 드라이브에 잘 가지고 있으면 됨

7. 환경변수와 구성 관리

7.1 ConfigMap을 통한 환경변수 관리

apiVersion: v1
kind: ConfigMap
metadata:
  name: api-tester-1231-properties
  namespace: anotherclass-123
  labels:
    app.kubernetes.io/part-of: k8s-anotherclass
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231
data:
  database_url: "postgresql://localhost:5432/mydb"
  log_level: "info"

ConfigMap의 다양한 활용

• 환경변수 제공 외에도 다양한 데이터를 Pod에 전달 가능

• Prometheus 예시에서는 성능 정보 계산 공식을 저장 (prometheus-k8s-rule)

• 애플리케이션 기동 시 초기 데이터로 활용

• 목적에 따른 ConfigMap 네이밍: properties, rules, config 등

• 사용 목적에 따라 네이밍을 추가하면 좋음

Pod에서 ConfigMap 참조

containers:
- name: app
  envFrom:
  - configMapRef:
      name: api-tester-1231-properties

• Pod가 ConfigMap 모든 데이터를 환경변수로 수신

• 애플리케이션은 표준적인 환경변수 접근 방법으로 값들 사용

7.2 Secret을 통한 민감 정보 관리

apiVersion: v1
kind: Secret
metadata:
  name: api-tester-1231-postgresql
  namespace: anotherclass-123
  labels:
    app.kubernetes.io/part-of: k8s-anotherclass
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231
stringData:
  username: admin
  password: secretpassword

• Secret 데이터는 Pod 내부 특정 경로에 파일로 마운트 가능

• 애플리케이션이 환경변수가 아닌 파일 시스템을 통해 민감 정보 접근

• ConfigMap과 달리 stringData 필드 사용

• 이 내용들을 가지고 이 파일이 Pod 안에 만들어짐

8. 스토리지 관리와 노드 연결

8.1 Persistent Volume의 클러스터 레벨 특성

apiVersion: v1
kind: PersistentVolume
metadata:
  name: api-tester-1231-files
  labels:
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231-files
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  local:
    path: /root/k8s-local-volume/1231
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - k8s-master

• 네임스페이스에 속하지 않는 클러스터 레벨 오브젝트

• 마스터 노드의 실제 레이블(kubernetes.io/hostname: k8s-master)과 연결

• 로컬 볼륨 경로와 노드 어피니티를 통한 정확한 위치 지정

• PV를 만들 때 문제가 생기기 때문에 디렉토리를 미리 만들어 둔 것

8.2 노드 레이블과 연결 메커니즘

마스터 노드의 자동 생성 레이블

# Kubernetes가 자동으로 생성하는 노드 레이블
labels:
  kubernetes.io/hostname: k8s-master
  kubernetes.io/os: linux
  node-role.kubernetes.io/master: ""

• Kubernetes가 클러스터를 구성하면서 자동으로 만들어 놓은 오브젝트에 레이블 존재

Pod의 노드 선택

# Pod template의 nodeSelector
nodeSelector:
  kubernetes.io/hostname: k8s-master

• 노드의 실제 레이블과 정확히 매칭

• 특정 노드에 Pod와 PV를 모두 배치하여 로컬 스토리지 활용

• nodeSelector로 지정한 마스터 노드에서 이 레이블과 연결

레이블의 정보 역할과 기능성 역할

• 정보 역할만 하는 레이블: 사람이 보기 위한 메타데이터

• 기능성 역할을 하는 레이블: 시스템이 오브젝트를 연결하기 위해 사용

• Pod는 nodeSelector와 PV는 nodeAffinity로 노드 레이블과 연결

9. 서비스와 네트워킹

9.1 Service의 용도별 네이밍

# 내부 통신용 Service
apiVersion: v1
kind: Service
metadata:
  name: api-tester-1231-internal
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231

---
# 외부 노출용 Service  
apiVersion: v1
kind: Service
metadata:
  name: api-tester-1231-external
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: api-tester
    app.kubernetes.io/instance: api-tester-1231

Service 네이밍 전략

• Pod에는 여러 Service 연결 가능

• 클러스터 내부 전용: internal 접미사

• 외부 접속 전용: external 접미사

• 목적에 따른 명확한 네이밍으로 관리 효율성 증대

• 사용 목적에 맞게 네이밍을 추가하면 됨

10. 자동 확장과 부하 관리

10.1 HPA의 다양한 정책 관리

기본 HPA 설정

# 기본 HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-tester-1231-default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-tester-1231
  minReplicas: 2
  maxReplicas: 4
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 40

특별한 이벤트용 HPA

# 특별한 이벤트용 HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-tester-1231-event
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-tester-1231
  minReplicas: 5
  maxReplicas: 20

HPA 네이밍 전략

• 특정 이벤트를 위한 임계치 조정으로 여러 HPA 오브젝트 생성 가능

• 목적에 따른 네이밍으로 구분 (default, event, peak-hours 등)

• 특정 이벤트를 위해서 임계치를 다르게 해준 오브젝트를 따로 만들어 놓게 되면 이런 이름을 쓸 수 있음

11. 오브젝트 레벨과 스코프

11.1 클러스터 레벨 vs 네임스페이스 레벨

클러스터 레벨 오브젝트

• Persistent Volume, Node, Namespace가 대표적

• 전체 클러스터에서 유일하며 모든 네임스페이스에서 접근 가능

• 클러스터 관리자 권한 필요

• 네임스페이스 삭제 시에도 별도 삭제 필요

• 네임스페이스 개념이 없어 글로벌 범위에서 관리

네임스페이스 레벨 오브젝트

• Deployment, Service, ConfigMap, Secret, PVC가 해당

• 특정 네임스페이스 내에서만 존재

• 네임스페이스 삭제 시 함께 삭제

• 멀티 테넌시 환경에서 리소스 격리와 접근 제어의 핵심

11.2 오브젝트 연결 방식의 분류

레이블-셀렉터 기반 연결

• Deployment → ReplicaSet → Pod

• Service → Pod

• PVC → PV (선택적)

• 동적이고 유연한 연결 관계

• 조건 기반 다중 오브젝트 선택 가능

직접 이름 참조 기반 연결

• HPA → Deployment (scaleTargetRef)

• Pod → ConfigMap (configMapRef)

• Pod → Secret (secretRef)

• Pod → PVC (persistentVolumeClaim)

• 명시적이고 안정적인 연결 관계

Kubernetes의 연결 방식 정리

• 크게 두 가지 연결 방식 제공

• 오브젝트마다 다른 방법을 제공

• 각 오브젝트 타입별 최적화된 연결 방식 선택

12. 모니터링과 관찰 가능성

12.1 Prometheus를 통한 메트릭 수집

메트릭 수집 아키텍처

• Prometheus: 중앙 집중식 메트릭 수집과 저장, 성능 정보에 대한 API 제공

• Exporter: 다양한 소스로부터 메트릭 데이터 제공

• Grafana: 수집된 메트릭의 시각화와 대시보드 구성

kube-state-metrics의 역할

• Kubernetes 클러스터 자체의 메트릭 정보 제공

• 오브젝트 상태, 리소스 사용량, 클러스터 헬스 모니터링

• 클러스터 운영에 필수적인 관찰 데이터 생성

Node Exporter의 기능

• 개별 노드(VM)의 시스템 메트릭 수집

• CPU, 메모리, 디스크, 네트워크 사용률 모니터링

• 인프라 레벨의 성능 데이터 제공

12.2 모니터링 네임스페이스 설계

metadata:
  namespace: monitoring

• 모니터링 관련 모든 컴포넌트를 전용 네임스페이스에 배치

• 시스템 모니터링 도구들의 격리와 독립적 관리

• 모니터링 인프라의 안정성 보장

• 네임스페이스 이름은 이 네임스페이스에 들어가는 앱들에 대한 범위를 나타내는 이름이 좋음

13. 실무에서의 고려사항과 교훈

13.1 레이블과 네이밍의 중요성에 대한 실무 교훈

2년 경력 후의 깨달음

• 강의에서 언급된 실무 경험담이 보여주는 핵심 교훈

• 레이블과 셀렉터, 네이밍 규칙이 단순 기술 설정을 넘어 팀 협업과 시스템 유지보수에 직결

• 초기 설계의 중요성과 나중에 수정하기 어려운 현실적 제약

• 실제로 Kubernetes를 시작하고 2년 정도가 지나서야 이 부분을 신경쓰기 시작

조기 학습의 중요성

• 실제 구성한 YAML 파일에 대한 설명 요구 상황 시 당황하지 않기 위함

• 체계적인 레이블링과 네이밍이 전문성의 지표

• 기본기의 탄탄함이 복잡한 운영 환경에서의 자신감으로 연결

• 만약에 이걸 신경쓰기 전에 제가 구성한 야물파일들을 보고 누군가 이 구성을 왜 이렇게 했는지 물어봤다면 매우 부끄러웠을 것

현실적인 경험담의 교훈

• 이름을 잘 모르는 동료 상황과 유사한 느낌

• 시간이 어느 정도 지났을 때 모르고 있으면 찾피한 상황들 발생

• 지금부터 배울 내용이 바로 이런 느낌

13.2 운영 환경에서의 변경 관리

레이블과 이름 변경의 위험성

• 오브젝트 이름과 레이블은 연결 요소이므로 변경 시 연쇄 영향 발생

• 운영 중인 시스템에서는 네이밍 변경이 매우 부담스러운 작업

• 초기 설계 단계에서 충분한 검토와 계획 필요

• 이런 부분들은 운영에 올라가기까지 정말 많이 고민을 해보시고 만들길 당부

템플릿 기반 관리 전략

• 개인 또는 팀 차원의 YAML 템플릿 라이브러리 구축

• Google Drive나 Git 저장소를 활용한 템플릿 관리

• 검증된 패턴을 재사용하여 일관성 유지와 실수 방지

• 그런 템플릿을 불러가가 했던 개인 구글 드라이브가 했던 내가 언제든 바로 쓸 수 있는 형태로만 잘 가지고 있으면 됨

13.3 과정에서의 어려움과 중요성

이과정이 제일 어려운 부분

• 네이밍과 레이블 구성을 위한 과정이 가장 어려운 부분

• 이런 걸 처음 많이 고민해서 만들어 놔야 되는 게 이름이랑 레이블들은 다 오브젝트 연결 요소

• 나중에 수정하다가 예리가 날 수도 있음

운영까지 간 상황에서의 부담

• 이미 운영까지 간 상황이라면 벌써 아닌 네이밍조차도 수정하기가 많이 부담스러움

• 초기 계획과 설계의 중요성

13.4 학습과 복습 전략

점진적 숙달 방법

• 처음에는 많은 내용처럼 보이지만 실제로는 자주 사용하는 핵심 기능들

• 반복 사용을 통한 자연스러운 습득

• 부담 갖지 말고 꾸준한 실습을 통한 숙련도 향상

• 조금만 쓰다보면 금방 익숙해질 부분들이니까 너무 부담 갖지 마시고

실습 환경 활용

• 생성된 오브젝트들을 직접 조작하며 내용 복습

• 다양한 명령어와 참고 자료를 활용한 능동적 학습

• 이론과 실습의 균형을 통한 깊이 있는 이해

• 다음 수업을 들기 전에 현재 만들어진 오브젝트들을 이것저것 놀리보면서 내용을 한번 복습을 해보세요

14. 전체 시스템 아키텍처 정리

14.1 실제 구성된 오브젝트 관계도

수업별 넘버링 체계

• Namespace: anotherclass-123 (수업별 넘버링)

• 각 수업에서 만들었던 오브젝트가 전체 수업에 영향이 없도록 하기 위한 목적

• 수업 때마다 네이밍 이름을 다르게 하여 격리

Pod 업데이트 관리

• Deployment: Pod의 업데이트를 관리하고 ReplicaSet이 복제본을 관리하는 역할

• ReplicaSet: 복제본을 관리하는 역할을 하는 거

• 정확하게는 Deployment가 파드의 업데이트를 관리

selector와 matchLabels 연결

• Deployment와 ReplicaSet에 어떤 select와 label로 연결되어 있음

• Service도 Pod에 연결할 때 마찬가지

• PVC랑 PV도 이렇게 연결

• selector와 label은 오브젝트를 매칭해주는 역할

14.2 클러스터 전체 구성

네임스페이스와 클러스터 레벨 분리

• Service, PVC와 PV도 연결되는데 노드도 클러스터를 구성

• Kubernetes가 자동으로 만들어 놓은 오브젝트가 있고 이 오브젝트에도 레이블이 있음

• PAD에서는 노드 셀렉터가 그리고 PV에서는 노드 어피니티가 이 레이블과 연결

레이블의 이중 역할 재강조

• 레이블에는 정보와 기능성 역할을 하는 레이블의 정보 역할만 하는 레이블이 있음

• 앞에 prefix를 붙일 수도 있어요 (도메인을 가리킴)

• 특히 Kubernetes 분석에 있는 아울 파일들에서 이런 예제들을 많이 볼 수가 있음

15. 결론

15.1 핵심 구성 요소별 역할 정리

• 네임스페이스를 통한 논리적 그룹핑으로 리소스 격리와 관리

• Deployment와 Service를 통한 애플리케이션 배포와 네트워킹

• ConfigMap과 Secret을 통한 구성 관리와 보안

• PV/PVC를 통한 데이터 영속성 보장

• HPA를 통한 자동 확장과 리소스 최적화

15.2 레이블-셀렉터 시스템의 핵심 가치

• 오브젝트 간 연결 관계와 레이블-셀렉터 메커니즘의 정확한 이해 필수

• 체계적인 레이블링과 네이밍이 단순 기술 지식을 넘어 실무 성공의 핵심 요소

• 초기 설계의 중요성과 운영 중 변경의 어려움을 고려한 신중한 접근 필요

15.3 실무 적용을 위한 권장사항

Kubernetes 권장 레이블 적극 활용

• app.kubernetes.io/* 프리픽스를 활용한 표준화된 레이블링

• part-of, component, name, instance, version, managed-by 구조 활용

• 추가적으로 의미 있는 정보들을 더 만들면 좋음