Kubernetes - Core Concept(2)

developowl·2026년 3월 2일
ckakubernetes

Kubernetes

목록 보기
3/3
post-thumbnail

Mumshad Mannambeth 님의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 들으며 정리한 내용들입니다.
Udemy Mumshad님- CKA 강의 들으러 가기

19. Pods

K8s의 궁극적인 목표

  • 클러스터의 워커노드로 구성된 머신 세트에 컨테이너 형태로 Application을 배포하는 것

⚠️ 쿠버네티스는 워커노드에 직접 배포하지 않음

→ 컨테이너는 Pod 라는 객체(Object)로 캡슐화됨

  • Pod는 Application의 단일 인스턴스

  • 일반적으로 Application을 실행하는 컨테이너 : 파드 = 1 : 1

    • 하나의 파드에 동일한 애플리케이션을 실행하는 컨테이너는 두 개 이상 배치하지 않음(가능은 하지만, 1:1이 관례)

Multi-Container PODs

  • 하나의 파드에 두 개 이상의 컨테이너가 담긴 형태
  • 네트워크 공유
    • 두 컨테이너는 동일한 네트워크 공간을 공유하기 때문에 서로를 localhost라고 지칭.
  • 자원 공유
    • 같은 볼륨(저장소)을 마운트 해서 데이터를 주고 받음

Helper Containers

  • 멀티 컨테이너 파드에서 메인 애플리케이션을 보조하기 위해 옆에 두는 컨테이너
  • 대표적인 활용 예시 (사이드카 패턴)
    • 로그 수집기 (Log Shipper)
      • 메인 컨테이너는 웹 서버 역할만 하고, 옆에 붙은 헬퍼 컨테이너가 메인 컨테이너가 남긴 로그 파일을 읽어서 중앙 로그 저장소로 보내주는 역할
    • 데이터 동기화 (Data Sync)
      • 메인 컨테이너가 사용할 최신 소스코드나 데이터를 외부 저장소에서 주기적으로 다운로드하여 공유 디렉토리에 넣어주는 역할
    • 프록시 (Proxy)
      • 네트워크 보안이나 통신을 보조하기 위해 앞단에서 통신을 대신 처리해줌

How to Deploy PODs

# 이미지를 사용하여 파드 생성하기
kubectl run nginx-image nginx

# 파드 목록 확인하기
kubectl get pods

20. Pods with YAML

  • Kubernetes 에서의 YAML → 오브젝트(Pod, Replica, Deploy, Service, …) 생성을 위한 입력
# Pod-definition.yml
apiVersion: "k8s API 버전"   # Strings
kind: "객체의 종류"            # Strings
metadata: "이름표"            # Dictionary
	name:                     # String
	labels:                   # - Dictionary
		app:                    # - Dictionary  
		type:                   # - Dictionary
spec:                       # Dictionary
	containers:               # - List / Array
		- name:                 # 목록의 첫번째 요소 앞에 '-'작성
			image:

  • 최상위 / 루트 수준의 속성 → 필수

    • apiVersion
    • kind
    • metadata

  • K8s API 버전

    • Pod - v1
    • Service - v1
    • ReplicaSet - apps/v1
    • Deployment - apps/v1
# 파드 생성
kubectl create -f pod-definition.yml

# 파드 상태 확인
kubectl get pods

# 파드의 상세 정보 확인
kubectl describe pod myapp-po
  • kube create
    • 없을 때 새로 만듦 (있으면 에러)
  • kube apply
    • 없으면 만들고, 있으면 수정사항을 반영함.

Dry Run

kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
  • YAML 파일의 뼈대 파일을 자동으로 만들어줌

실습

# 파드 개수 확인
kubectl get pods
	# 파드가 0개일 때 >>> No resources found in default namespace.

# nginx image를 사용하여 새로운 파드 생성하기
# kubectl run [이름] --image=[이미지명]
kubectl run nginx --image=nginx

# newpods-xxxx 파드들이 어떤 컨테이너 이미지를 사용해서 만들었는지 확인
kubectl describe pods newpods-

# 어떠한 노드에 파드가 위치하는지 확인
kubectl describe pods <pod name> 
	# >>> Node: 항목 확인
	
# webapp 파드 삭제하기
kubectl delete pod webapp

# 잘못된 이미지를 사용하여 파드를 생성한 경우
kubectl run redis --image=redis123123
	# kubectl get pods > STATUS: ErrImagePull

# 이미지를 수정하는 법
# 1) set image 사용
# kubectl set image pod/[파드이름] [컨테이너이름]=[새로운이미지]
kubectl set image pod/redis redis=redis 

# 2) 에디터를 열어서 설정 파일을 직접 수정
# kubectl edit pod [파드이름]
kubectl edit pod redis
  • kubectl get pods 의 실행 결과 중 READY 열에 있는 숫자들의 의미는?
    • 현재 준비된 컨테이너 수 / 파드 내 전체 컨테이너 수

26. ReplicaSets

Replication Controller

High Availability

  • Replication Controller는 쿠버네티스 클러스터에서 단일 파드의 여러 인스턴스를 실행하는데 도움이 됨
  • Replication Controller는 기존 파드가 실패하면 자동으로 새 파드를 불러와서 도움을 줄 수 있음

Load Balancing and Scaling

  • 사용자 수가 증가하면 추가 파드를 배포하여 두 파드 간의 부하를 분산시킴
  • 수요가 더 증가하여 첫 번째 노드에서 리소스가 부족해지면 클러스터의 다른 노드에 추가 파드를 배포할 수 있음
  • 복제 컨트롤러는 클러스터의 여러 노드에 걸쳐 있음

Replication Controller vs Replica Set

  • replication controller - 구형 기술
  • replica set - 복제를 설정하는 새로운 권장 방법

Repliation Controller 생성

  • rc-definition.yaml
apiVersion: v1
kind: ReplicationController
metadata: # -->> Replication Controller
	name: myapp-rc
	labels:
		app: myapp
		type: front-end
spec: # -->> Replication Controller
	template:
		metadata: # -->> Pod
			name: myapp-pod
			labels:
					app: myapp
					type: front-end
		spec: # -->> Pod
			containers:
			- name: nginx-container
				image: nginx
	replicas: 3

Replica Set 생성

apiVersion: apps/v1
kind: ReplicaSet
metadata:
	name: myapp-replicaset
	labels:
			app: myapp
			type: front-end
spec:
	template:
	
		metadata: 
			name: myapp-pod
			labels:
					app: myapp
					type: front-end
		spec:
			containers:
			- name: nginx-container
				image: nginx
	replicas: 3
	selector:
		matchLabels:
			type: front-end
  • ReplicaSet은 selector 정의가 필요함
    • ReplicaSet 이 어떤 파드에 해당되는지 식별하는 데 도움이 됨
    • ReplicaSet 은 ReplicaSet 생성의 일부로 생성되지 않은 파드도 관리할 수 있음

Labels & Selectors

쿠버네티스에서 파드와 오브젝트에 레이블을 지정하는 이유는 무엇일까?

  • 클러스터에는 서로 다른 애플리케이션을 실행하는 수백 개의 다른 파드가 있을 수 있음. → 레이블을 통해 ReplicaSet 이 모니터링할 파드를 알 수 있음

Scale

  • ReplicaSet 을 확장하는 방법
  1. definition.yaml 파일의 replicas 항목을 변경
    • replicas: 3 → replicas: 6
    • kubectl create -f replicaset-definition.yaml
  2. kubectl scale —replicas=6 -f replicaset-definition.yaml
  3. kubectl scale —replicas=6 [TYPE][NAME]

Commands

# 입력으로 제공하는 파일에 따라 Replicaset 등 쿠버네티스의 모든 오브젝트 생성
kubectl create -f replicaset-definition.yaml

# 생성된 레플리카셋의 정보 확인
kubectl get replicaset

# 레플리카셋 삭제
kubectl delete replicaset myapp-replicaset

# 레플리카셋 교체 및 업데이트
kubectl replace -f replicaset-definition.yaml

# 레플리카셋 확장
kubectl scale --replicas=6 -f [파일 이름]

실습

# 현재 존재하는 파드의 수
kubectl get pods

# 현재 존재하는 레플리카셋의 수
kubectl get replicasets

# 특정 레플리카셋에서 DESIRED 상태의 파드 개수 조회
kubectl get replicaset new-replica-set

# 특정 레플리카셋에서 사용된 이미지 정보
kubectl describe replicaset new-replica-set

# 레플리카셋을 생성하기
kubectl create -f replicaset-def.yaml

29. Deployment

Deployment 는 ReplicaSet 의 상위 객체로, RollingUpdate 를 통해 무중단 배포를 가능하게 하고 장애 시 손쉽게 Rollback 할 수 있게 해주는 배포 관리자.

1. 계층 구조 (Hierarchy)

  • 쿠버네티스에서 배포를 관리하는 방식은 부모-자식 관계를 가짐
  • Deployment : 배포 전략(업데이트, 롤백)을 결정하는 두뇌
  • ReplicaSet : 지정된 개수의 파드가 항상 떠 있도록 유지하는 관리자
  • Pod : 실제 애플리케이션이 돌아가는 최소 단위

2. Rolling Update

  • 서비스를 중단하지 않고 파드를 하나씩(또는 일정 비율씩) 순차적으로 교체하는 방식
  • 방식 : 새 버전의 파드를 하나 만들고, 확인이 되면 구 버전의 파드를 하나 죽임. 이를 반복함
  • 장점 : 사용자가 서비스가 끊기는 것을 전혀 느끼지 못함 (Zero Downtime)
  • Rollback : 만약 새 버전에 버그가 있다면, 즉시 이전 상태의 ReplicSet으로 되돌릴 수 있음

3. Deployment의 주요 특징

  • 추상화 : 파드나 레플리카셋을 직접 만지는 대신, 더 높은 수준의 객체인 Deployment 를 통해 모든 것을 제어
  • 배포 전략 제어 : RollingUpdate 뿐만 아니라 한 번에 싹 다 바꾸는 Recreate 방식도 선택 가능
  • 버전 관리(History) : 배포 기록이 남기 때문에 언제든 과거의 특정 시점으로 복구할 수 있음

실습

# Deployment 정보 조회
kubectl get deployment

# Deployment 상세 정보 조회
kubectl describe deployment <Deployment Name>

# Deployment 생성
kubectl create -f <deployment-file.yaml>

# Name, Replicas 수, Image 정보가 주어졌을 때 새로운 디플로이먼트 생성
kubectl create deployment httpd-frontend --image=httpd:2.4-alpine --replicas=3 --dry-run=client -o yaml > httpd-frontend.yaml

34. Services

Service는 동적으로 변하는 파드들에게 고정된 IP와 DNS 이름을 제공하는 네트워크 객체

유형용도특징
ClusterIP(기본값)내부 통신용클러스터 내부에서만 접근 가능. 프론트엔드가 백엔드를 찾을 때 사용
NodePort외부 접속용 (테스트)모든 노드의 특정 포트(30000~32767)를 열어 외부 접속 허용
LoadBalancer운영 접속용CSP의 로드밸런서를 생성하여 외부와 연결

NodePort

  • NodePort (30008)

    • 외부 사용자가 노드 IP를 통해 접속하는 포트 (대문 역할)
    • 30000~32767

  • Port (80)

    • 서비스 객체 자체가 클러스터 내부에서 들고 있는 포트 (안내 데스크 역할)

  • TargetPort (80)

  • 실제 파드(컨테이너) 안에서 애플리케이션이 리스닝하는 포트 (실제 방)

  • 단일 서비스 내에 포트 매핑을 여러 개 가질 수 있음

apiVersion: v1
kind: Service
metadata:
	name: myapp-service
	
spec:
	type: NodePort
	ports:
	- targetPort: 80  # 파드의 포트
		port: 80        # 서비스의 포트
		nodePort: 30008 # 외부 접속 포트
	selector:
		app: myapp
		type: front-end
  • selector
    • Service는 selector에 적힌 레이블(app: myapp)을 보고 파드들을 찾음
    • 이때 찾아낸 파드들의 실제 IP 목록을 Endpoints 라는 객체로 관리
    • 파드가 새로 생기거나 죽으면 Service가 자동으로 이 목록을 업데이트
# 생성 명령
kubectl create -f service-definition.yml

📌 하나의 노드에 동일한 레이블을 갖는 파드가 여러 개 존재하는 경우

  • 애플리케이션을 여러 인스턴스로 실행하는 경우(ex: 3개)
  • 서비스를 생성하는 동안 동일한 레이블이 selector로 사용됨.
  • 서비스가 생성되면 레이블과 일치하는 파드를 찾고 그 중 3개를 찾음
  • 서비스는 자동으로 3개의 파드를 모두 엔드포인트로 선택하여 외부 요청을 전달
  • 3개의 서로 다른 파드 간에 부하를 분산하기 위해서 랜덤 알고리즘을 사용

📌 파드가 여러 노드에 분산되어 있는 경우

  • 서비스를 생성하면 쿠버네티스는 클러스터의 모든 노드에 걸쳐 서비스를 자동으로 생성하고 대상 포트를 클러스터의 모든 노드에 있는 동일한 노드 포트에 매핑

35. Service - ClusterIP

  • 쿠버네티스 안에서 파드는 생성되고 죽을 때마다 IP가 계속 바뀜
  • ClusterIP는 파드 그룹 앞에 고정된 대표 IP를 하나 만들어 줌
    • 예시: 프론트엔드는 백엔드의 개별 IP를 알 필요 없이, Service의 이름이나 Service의 고정 IP로만 요청을 보내면 됨
  • Service는 파드를 함께 그룹화하고 그룹 내 파드에 액세스할 수 있는 단일 인터페이스를 제공하는데 도움이 됨
apiVersion: v1
kind: Service
metadata:
	name:back-end
	
spec:
	type: ClusterIP # 생략 시 자동으로 ClusterIP 할당
	ports:
	- targetPort: 80
		port: 80
	
	selector:
		app: myapp
		type: back-end
  • targetPort
    • 파드가 노출되는 포트
  • port
    • 서비스가 노출되는 포트

36. Service - LoadBalancer

  • 단 하나의 고정된 외부 IP(External IP)를 제공

1. 계층적 구조

  • ClusterIP 생성 (내부 통신용)
  • NodePort 생성 (노드별 포트 개방)
  • External LB 생성 (CSP가 제공하는 로드밸런서)

2. 사용 목적 (장점)

  • 단일 진입점 : 노드가 100개라도 사용자는 클라우드 업체가 준 IP 하나로만 접속할 수 있음
  • 부하 분산 : 외부 로드밸런서가 여러 노드로 트래픽을 골고루 나눠줌
  • 보안 : 사용자가 노드의 개별 IP나 3만 번대 포트를 알 필요가 없음 (보통 80, 443 포트 사용 가능)
apiVersion: v1
kind: Service
metadata:
  name: frontend-lb
spec:
  type: LoadBalancer    # 클라우드 업체에 LB 생성을 요청함
  ports:
    - port: 80          # 사용자가 접속할 외부 포트 (LB의 포트)
      targetPort: 80    # 파드 내부의 포트
  selector:
    app: myapp

쿠버네티스 Service 유형 비교

구분ClusterIPNodePortLoadBalancer
주요 용도내부 통신용외부 접속용 (테스트/개발)외부 접속용 (운영/실서비스)
접근 범위클러스터 내부에서만 가능노드 IP + 포트를 통해 외부 가능단일 외부 IP를 통해 외부 가능
포트 할당서비스 내부 포트만 사용모든 노드에 동일 포트(30000~32767) 개방CSP가 제공하는 포트(80, 443 등) 사용
IP 특징클러스터 내부 가상 IP노드 각각의 실제 IP 사용클라우드가 할당한 고정 외부 IP
계층 관계(가장 기본)ClusterIP를 포함ClusterIP + NodePort를 모두 포함함
환경 제약모든 환경 지원모든 환경 지원CSP 환경 필수

39. Namespaces

Namespace 는 하나의 물리적 클러스터를 여러 개의 논리적인 가상 클러스터로 나누는 ‘방 나누기’ 개념

왜 사용하는가?

  • 리소스 격리 및 할당량(Resource Quota)
    • 특정 네임스페이스가 클러스터 전체 자원을 독점하지 못하도록 CPU/메모리 사용 한도를 제한할 수 있음
  • 보안 및 정책
    • 네임스페이스별로 누가 무엇을 할 수 있는지에 대한 RBAC 을 적용할 수 있음
  • 엔터프라이즈 확장성
    • 대규모 프로젝트나 프로덕션 환경에서 팀별, 프로젝트별로 환경을 분리하여 관리하기 용이

Default Namespaces

  • 쿠버네티스를 설치하면 자동으로 생성되는 방들
  • default
    • 사용자가 별도로 지정하지 않았을 때 모든 리소스가 생성되는 기본 공간
  • kube-system
    • 쿠버네티스 시스템 운영을 위한 핵심 구성 요소 (DNS, 네트워킹 등)들이 모여 있는 공간
  • kube-public
    • 모든 사용자가 읽을 수 있는 클러스터 정보(인증 등)가 담긴 공개된 공간

DNS 주소 체계 (도메인 규칙)

  • 네임스페이스 안의 리소스는 서로 이름만 부를 수 있지만, 다른 네임스페이스에 있는 리소스를 부를 때는 풀네임이 필요함
<서비스명>.<네임스페이스>.<서비스종류(svc)>.<도메인(cluster.local)>

# ex
mysql.dev.svc.cluster.local

필수 명령어

조회 및 생성

# 현재 네임스페이스의 파드만 보기
kubectl get pods

# 특정 네임스페이스의 파드 보기
kubectl get pods -n <네임스페이스명>

# 전체 네임스페이스의 파드 보기
kubectl get pods -A
kubectl get pods --all-namespaces

# 새 네임스페이스 만들기
kubectl create namespace <네임스페이스명>

리소스 생성 및 기본 설정 변경

# 특정 네임스페이스에 파드 바로 띄우기
kubectl run <파드명> --image=<이미지> -n <네임스페이스명>

# Dry-run 으로 설계도 뽑기
kubectl run redis --image=redis -n finance --dry-run=client -o yaml > redis-pod.yaml

# 기본 네임스페이스 변경하기
kubectl config set-context $(kubectl config current-context) --namespace=<네임스페이스명>

42. Imperative vs. Declarative

Imperative

  • 명령형 방식
  • 해야 할 일과 더 중요한 일을 지정하는 것이 필수

Declarative

  • 선언형 방식
  • 어떻게 할 것인지가 아니라 무엇을 할 것인지 명시하는 것

Infrastructure as Code

  • Imperative

    • 해야하는 작업들을 명령들을 순서에 맞추어 명령
    • kubectl run → create → expose → edit → scale → set → create -f → replace -f → delete -f 등의 과정과 작업이 필요함

  • Declarative

    • 요구 사항을 선언
    • 단계별 지침 제공 x
    • 애플리케이션과 서비스의 예상 상태를 정의하는 파일 세트를 생성
    • kubectl apply -f 명령으로 쿠버네티스가 스스로 작업을 결정하여 진행

Imperative Commands

Create Objects

  • kubectl run
  • kubectl create
  • kubectl expose

Update Objects

  • kubectl edit
  • kubectl scale
  • kubectl set

문제점

  • 고급 사용 사례의 경우 길고 복잡한 명령을 직접 만들어야 함
  • 이러한 명령형 방식의 명령은 한 번 실행되면 잊혀짐
    • 명령을 입력한 사용자의 세션에서만 볼 수 있음.
    • 다른 사용자는 이러한 개체가 어떻게 생성되었는지 추적하기가 어렵다

오브젝트 정의 파일, 구성 파일 또는 매니페스트 파일을 생성하면 오브젝트의 모양을 YAML 형식으로 정확히 기록하고 kubectl create 명령을 사용하여 오브젝트를 생성하는데 도움이 될 수 있다.

# Create Objects
kubectl create -f nginx.yaml

# Update Objects
kubectl edit deployment nginx
kubectl replace -f nginx.yaml
kubectl replace --force -f nginx.yaml

Declarative

# Create Objects
kubectl apply -f nginx.yaml
kubectl apply -f /path/to/config-files

# Update Objects
kubectl apply -f nginx.yaml

44. Kubectl Explain Command

kubectl api-resources

  • 현재 클러스터에서 사용할 수 있는 모든 API 리소스의 목록을 보여줌

출력 항목

  • NAME
    • 리소스의 전체 이름(ex: pods, deployments 등)
  • SHORTNAMES
    • kubectl 명령어에서 사용할 수 있는 줄임말
  • APIVERSION
    • 해당 리소스가 속한 API 그룹과 버전(ex: v1, apps/v1)
  • NAMESPACED
    • true
      • 네임스페이스별로 격리되는 리소스 (Pod, Services 등)
    • false
      • 클러스터 전체에 걸쳐 있는 리소스 (Node, Namespace 등)
  • KIND
    • YAML의 kind 필드에 작성해야 하는 공식 명칭

kubectl explain

  • 특정 리소스의 구조(Schema)와 각 필드의 상세 설명을 확인하는 명령어

활용법

  • kubectl explains <리소스명>
    • 해당 리소스가 무엇인지, 어떤 최상위 필드(spec, status 등)를 가지는지 설명
  • kubectl explain pods.spec.containers
    • 컨테이너 설정 아래에 어떤 옵션이 있는지 구체적으로 확인
  • kubectl explain pods --recursive
    • 하위 필드의 하위 필드까지 트리 구조로 모든 필드를 나열

실습

# 파드 생성 / 파드명, 이미지명
kubectl run <파드명> --image=<이미지명>

# 파드 생성 / 파드명, 이미지명, 라벨
kubectl run <파드명> --image=<이미지명> --labels="<레이블명>"

# 서비스 생성 / 서비스명, 이미 존재하는 파드 연결, 클러스터 내부에서 노출, 포트 설정
kubectl expose pod <파드명> --port=<포트번호> --name=<서비스명>

# 디플로이먼트 생성 / 디플로이먼트명, 이미지명, 레플리카 수
kubectl create deployment <디플로이먼트명> --image=<이미지명> --replicas=<레플리카수>

# 파드 생성 / 파드명, 이미지명, 포트번호
kubectl run <파드명> --image=<이미지명> --port=<포트번호>

# 네임스페이스 생성 / 네임스페이스명
kubectl create ns <네임스페이스명>

# 디플로이먼트 생성 / 디플로이먼트명, 네임스페이스명, 이미지명, 레플리카수
kubectl create deployment <디플로이먼트명> --image=<redis> --replicas=2 -n <네임스페이스명>

# 파드 생성 / 파드명, 이미지명, 서비스 타입, 포트번호, 네임스페이스=default
# 1. default 네임스페이스에 이미지명을 명시한 파드 생성
kubectl run <파드명> --image=<이미지명>

# 2. 서비스 생성
kubectl expose pod <파드명> --port=<포트번호> --name=<서비스명> --type=<서비스타입>

# 클러스터에서 사용할 수 있는 모든 API 리소스 목록 조회
kubectl api-resources

# 리소스의 SHORTNAME 조회
kubectl api-resources | grep <리소스명>

# 리소스의 정의와 상세 명세 확인
kubectl explain pods

# 실행 중인 인스턴스의 상태 확인
kubectl describe pods

# YAML 명세서(Manifest)를 작성할 때, containers 항목 아래에 어떤 필드를
# 사용할 수 있는지 확인하는 법
kubectl explain pods.spec.containers

# kubectl explain 과 함께 --recursive 플래그를 사용하면?
-> 하위 필드의 하위 필드까지(Nested fields) 모든 구조를 한 번에 펼쳐서 보여줌

📌 Cluster-scoped Resources

→ 특정 네임스페이스에 할당되지 않으며, 클러스터 전체 인프라 및 관리 정책을 정의

  • Nodes
    • 클러스터를 구성하는 물리적 또는 가상 머신 객체로, 모든 네임스페이스의 파드가 스케줄링 되는 기반 리소스
  • Namespaces
    • 리소스를 논리적으로 격리하는 최상위 추상화 객체 자체
    • 다른 네임스페이스에 포함될 수 없음
  • PersistentVolumes (PV)
    • 스토리지 클래스에 의해 할당된 실제 물리적 스토리지 리소스
    • 클러스터 수준에서 관리되며 특정 네임스페이스의 PVC(PersistentVolumeClaim)에 바인딩 되어 사용
  • ClusterRoles / ClusterRoleBindings
    • 특정 네임스페이스에 국한되지 않고 클러스터 전체 리소스에 대한 권한 제어(RBAC)를 정의하는 보안 객체
  • APIService / CustomResourceDefinition (CRD)
    • API 서버의 기능을 확장하거나 새로운 리소스 타입을 정의하는 메타 데이터 성격의 리소스

📌 Namespaced Resources

→ 특정 네임스페이스 내에서만 고유한 이름을 가지며, 해당 네임스페이스의 정책과 할당량(Resource Quota)의 제한을 받음

  • Workload Resources (Pods, Deployments, ReplicaSets, StatefilSets)
    • 실제 컨테이너가 실행되는 단위로, 네임스페이스 단위의 스케줄링 및 관리가 이루어짐
  • Discovery & LB Resources (Services, Endpoints, Ingress)
    • 파드 집합에 대한 네트워크 접근 지점을 정의하며, 동일 네임스페이스 내 리소스와 우선적으로 통신함
  • Config & Storage Resources (ConfigMaps, Secretes, PVCs)
    • 애플리케이션 설정 정보나 민감 정보, 그리고 특정 네임프세이스 내 파드가 요청한 스토리지 볼륨 요청서

47. Kubectl Apply Command

3-Way Merge 전략

세 가지 구성 요소

  • Local File
    • 방금 수정한 최신 YAML 파일
  • Live Object Configuration
    • 현재 쿠버네티스 클러스터 메모리(etcd)에서 실제로 실행 중인 객체의 상태
    • 시스템이 자동으로 부여한 status, IP 정보가 포함됨
  • Last Applied Configuration
    • 가장 마지막에 apply 를 성공했던 시점의 데이터

Annotation의 정체와 역할

  • Last Applied Configuration 을 저장하는 장소

  • 저장 위치

    • Live Object 의 metadata.annotations 필드 안에 kubectl.kubernetes.io/last-applied-configuration 라는 키로 저장됨

  • 저장 형식

    • 로컬 YAML 파일 내용이 JSON 형식으로 변환되어 통째로 기록

→ 왜 필요할까?

  • 로컬 파일에서 특정 필드를 삭제했을 때, 쿠버네티스는 이 어노테이션을 보고 “이전에는 있었지만, 현재는 없으니 Live Object 에서도 지워야겠다” 라고 판단을 한다.
profile
developowl
Don’t get mad at the computer.
이전 포스트

쿠버네티스 공식 문서에 기여하는 법(한글화 기여)

0개의 댓글