Kubernetes 1일차 개념 정리

가상 머신: 하드웨어 관점의 추상화(전체 OS와 가상 하드웨어를 포함)

 

컨테이너: 서비스(APP) 관점의 추상화 
->
쿠버네티스: 서비스 인프라 관점의 추상화
->
서비스 매쉬: 서비스 트래픽 추상화 및 가시화

 

 

쿠버네티스

 

쿠버네티스(Kubernetes) : 사용자가 설정한 이상적인 상태(ideal state)와 실제 상태(actual state)를 계속 비교해서,
스스로 상태를 회복(self-healing) 하는 시스템

 

• 쿠버네티스는 선언형!! -> API 중심, 자동 복구, DevOps 친화적
• 사용자가 manifest(YAML 파일, 이상적인 상태!!!)에 "이런 상태가 되도록 해줘!"라고 선언
• 쿠버네티스는 그걸 기준으로 끊임없이 실제 상태를 감시하고 맞추려 함
  → 이것이 선언형 방식의 핵심

 

명령형 (Imperative) : 사용자가 "무엇을 할지" 명령함 (kubectl run, kubectl expose)

선언형 (Declarative) : 사용자가 "무엇이 되어야 하는지" 선언함 (YAML 파일 작성 후 kubectl apply)

 

쿠버네티스 클러스터: 컨테이너화된 애플리케이션들을 자동으로 배포, 관리, 확장, 운영할 수 있게 해주는 시스템의 구성 단위

 

KIND(Kubernetes IN Docker): 개발, 테스트 목적의 쿠버네티스 클러스터를 도커 컨테이너 안에 손 쉽게 띄울 수 있게 해주는 도구

• kind create cluster 명령어로 도커 컨테이너에 빠르게 클러스터 생성
• 이때 kubeconfig에 자동으로 연결 정보가 추가되고 ~/.kube/config 파일이 생성됨

 

 

~/.kube/config: : kubectl이 어떤 클러스터에 접속할지 정보를 담은 설정파일

• kubectl 명령어가 이 주소로 연결해 클러스터와 통신

 

kubectl(큐브커틀): 쿠버네티스 클러스터를 제어하는 커맨드라인 클라이언트 도구(CLI 툴)

• kubectl get pods – 실행 중인 파드 목록 보기
• kubectl apply -f [yml 파일] – 설정 파일 기반 리소스 생성

 

kubectx(큐브 콘텍스트): 여러 Kubernetes 클러스터(또는 context) 간 빠르게 전환할 수 있는 CLI 도구

 

• 현재 context는 AWS EKS 클러스터
  → arn:aws:eks:ap-northeast-2:212...:cluster/cwave
• kubectx kind-cwave-cluster 명령어로 context 전환
  → 로컬 KIND 클러스터(kind-cwave-cluster)로 연결됨

 

쿠버네티스 기본 구성 단위

• Control Plane(Master) - 클러스터 상태 감시, 파드를 생성/스케줄링/관리하는 중앙 제어 시스템
  • kube-scheduler (스케줄러): 새로 생성된 Pod를 어떤 노드에 배치할지 결정
  • kube-controller-manager: 여러 컨트롤러(자동 감시/복구 담당) 들을 통합해서 실행
  • kube-apiserver (API 서버): 모든 요청(kubectl, 클라우드 API 등)을 받는 REST API 엔드포인트
  • etcd: 쿠버네티스의 데이터 저장소 (Key-Value DB) / 분산 키-값 저장소
    • 클러스터의 원하는 상태(desired state) 저장
    • 모든 리소스 정보 (Pod, Service, ConfigMap, Deployment 등) 저장
    • API Server가 읽고 쓰는 유일한 저장소
  • container runtime (ex. containerd, Docker 등): 실제로 컨테이너(Pod)를 실행시키는 역할

 

 

• Nodes(Worker1, 2)
  
  • kube-proxy: 각 노드에서 실행되며 네트워크 라우팅 담당
  • container-runtime:  실제로 컨테이너(Pod)를 실행시키는 역할
  • kubelet: 각 노드에서 실행되며 API 서버와 통신

 

 

실습 환경

1. docker container 하나 생성 → 이름: cwave-cluster-control-plane(마스터 노드)
2. 이 컨테이너 내부에서 쿠버네티스가 작동 (즉, 이게 "쿠버네티스 클러스터"임)
3. 하지만 이 컨테이너의 IP는 Docker 네트워크 내에서만 유효하므로
4. 외부에서 kubectl 명령으로 접근하려면 Kubernetes API Server의 주소를 관리하는~/.kube/config 파일에서 직접 수정해줘야 함

 

 

 

 

 

Pod

 

Pod(파드): 쿠버네티스 애플리케이션의 가장 작은 기본 실행 단위

• 파드당 컨테이너 비율은 대체로 1:1 이 관례
• 모든 Pod는 네트워크 통신이 가능하다!!
• Pod는 같은 IP를 가진 plat network로 구성되어 있음 → SDN!!

 

pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

• metadata:name: Pod의 이름
• spec: Pod의 **구체적인 사양(specification)**을 정의하는 블록
• container: Pod 안에 실행될 컨테이너 목록 (여기선 하나만 정의)
  • name: 컨테이너의 이름
  • image: 사용할 Docker 이미지
  • ports: 컨테이너가 외부에 노출할 포트  

 

 

 

Namespace

단일 클러스터(4개의 노드, 여러 노드를 포함하는 네임스페이스)

 

Namespace: 단일 클러스터 내에서의 논리적인 리소스 격리

• Namespace 내에서는 리소스 이름이 고유함
• CPU/MEMORY/DISK/GPU를 제어 가능
• Namespace에 트래픽이 나가고 들어오는 것을 제어할 수 있음 → NetworkPolicy
• 권한 제어도 가능 → RBAC(Role-Based Access Control, 역할 기반 접근 제어)
• Namespace 삭제 시 그 안에 들어있는 모든 리소스(Pod, Service...) 삭제

 

 

 

내가 속해있는 namespace를 가리키는명령어 → kubens

• default라는 namespace가 지정되어 있는 것 확인 가능(기본 namespace)
• kubens 명령어로 namespace 이동도 가능
• 해당 namespace에서 리소스(deployment, service, pod..)들을 생성, 삭제 등 관리

 

 

Replication Controller(rc)

Replication Controller: 어떠한 이유로는 Pod 가 사라지게 되면, 원하는 개수(Replicas)를 유지하기 위해 새로운 파드를 자동으로 다시 만들어 주는 객체

• 그림처럼 Node 1이 내려가면서 Pod B가 사라지자, Replication Controller가 이를 감지하고 Node 2에 Pod B2를 즉시 생성해 파드 수를 복구
• Replication Controller 생성 시, 지정한 수만큼 Pod도 자동으로 생성!!!!

 

 

apiVersion: v1
kind: ReplicationController
metadata:
  name: goapp-rc
spec:
  replicas: 3
  selector:
    app: goapp
  template:
    metadata:
      name: goapp-pod
      labels:
        tier: forntend
        app: goapp
        env: prod
        priority:  high
    spec:
      containers:
      - name: goapp-container
        image: dangtong/goapp
        ports:
        - containerPort: 8080

• replicas: 실행해야 하는 Pod의 원하는 수를 지정하는 복제본 수 (replicas), 감시할 대상의 수
• selector: app:goapp라는 Pod의 라벨을 감시하는 조건
• (Pod)Template: 새로운 Pod 복제본을 만들때 사용
  • ReplicationController나 Deployment가 Pod를 새로 만들거나 교체해야 할 경우, 이 Template를 기반으로 새로운 Pod 인스턴스가 생성

 

 

Replicaset(rs)

 

Replicaset: Replication Controller 를 대체 하기 위해 나옴 → ReplicaSet을 주로 사용

 

• Replication Controller : 감시 대상을 (Label)selector로만 가능
• ReplicaSet은 표현식이 더 풍부해짐 → 서로 다른 라벨을 가져도 표현식을 통해 가능
  • rc에는 없고 rs에만 있는 표현식: matchLabels, matchExpressions

    matchLabels:
      tier: frontend
    matchExpressions:
      - {key: env, operator: In, values: [prod]}
      - {key: priority, operator: NotIn, values: [low]}

 

 

Label & Annotaion

항목	Label(라벨)	Annotation(주석)
용도	리소스 필터링, 쿼리, 조회, 셀렉션	메타데이터 저장(비검색/비필터용)
구조	key/valuevalue는 63자까지 허용	key/valuevalue는 245KB 까지 허용
셀렉터(selector)	사용 가능 → 문법으로 쿼리가 된다는 뜻	불가능 → 쿼리 안됨
예시 용도	app=nginx, env=prod	description,build info,creator info

• 대규모 쿠버네티스 클러스터에서는 수많은 리소스(Pod, Node, Service 등)가 존재
  • Label을 활용해 리소스를 논리적으로 그룹화하고, 효율적으로 필터링하거나 선택할 수 있음
• 쿠버네티스의 네트워크 서비스(Service)는 Label Selector를 기반으로 라우팅 대상(Pod)을 결정함(매우 중요!!)
• Label은 ‘이름표’이자 ‘주소 역할’
• Service, ReplicaSet, Deployment 모두 Label을 기반으로 Pod와 연결
• Annotation은 참고 메모용일 뿐임

 

 

 

apiVersion: v1
kind: Pod
metadata:
  name: goapp-pod
  labels:
    env: prod
    tier: backend
spec:
  containers:
  - image: dangtong/goapp
    name: goapp-container
    ports:
    - containerPort: 8080
      protocol: TCP

• metadata.labels: Pod에 붙일 Label들 (key-value 쌍)

 

• 생성한 Pod에 Annotation(주석) 달기 -> 참고 메모용

 

 

Probe

 

 

Probe:  쿠버네티스가 쿠버네티스 컨테이너의 상태를 감시하고, 필요할 경우 재시작하거나 트래픽을 차단할 수 있게 해주는 건강 체크(Health Check) 기능

 

Probe 종류

 

 

Probe 설정 값

 

Liveness-probe(비연결 지향형) Pod 생성

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3
      failureThreshold: 3
      successThreshold: 3

• initialDelaySeconds: 3  →  컨테이너가 시작된 후 3초 뒤부터 첫 체크
• periodSeconds: 3  →  매 3초마다 헬스 체크 반복

• [0~3초]: 아직 initialDelaySeconds 기간 → probe 동작 안 함
• [3초] : 첫 probe 요청 시도 (GET /healthz) -> 실패 (응답 없음 or 500 에러)
• [6초] : 두 번째 probe 요청 시도 → 실패
• [9초]: 세 번째 probe 요청 시도 → 실패

→ 총 3번 연속 실패 = failureThreshold 만족 → Kubernetes가 "비정상" 판단 → 컨테이너 자동 재시작! 

• successThreshold는 반대로, 회복 시 몇 번 성공해야 정상으로 간주할지를 결정

즉, LivenessProbe는 “죽었는지”를 감지해서 죽었으면 컨테이너를 재시작!!!

 

 

Readiness(연결 지향형) Pod 생성

apiVersion: v1
kind: Pod
metadata:
  name: readiness-http-pod
spec:
  containers:
  - name: readiness-http
    image: nginx:latest
    ports:
    - containerPort: 80
    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 3
      timeoutSeconds: 2
      failureThreshold: 2

• Readiness Probe: 컨테이너가 트래픽 받을 준비가 되었는지 감지
• /로 5초 뒤 첫 체크 → 3초 간격, 응답 2초 내 실패 2회 → 트래픽 차단
• 하지만 컨테이너는 죽지 않음, 단지 서비스 연결에서 빠짐

 

 

🔹 Liveness Probe는 “죽었으면 다시 시작”
🔹 Readiness Probe는 “준비 안 됐으면 요청 받지 마”