Pod

Container : 독립적인 서비스 운영

• 한 파드에 1개 이상의 컨테이너가 존재할 수 있음
• 파드 내의 Container에 할당되는 Port는 중복될 수 없음
• 파드 내의 컨테이너들은 하나의 호스트에 연결되어 있음 (localhost:[포트번호]로 통신 가능)
• 파드가 생성될 때 IP가 할당되는데, 이 IP는 노드 내에서만 통신 가능한 IP임 (like 사설 IP)
• 파드가 재생성되면 IP 주소는 변경됨

Label : 목적에 따라 object를 분류하고 사용하기 위해 사용

• Key-Value 쌍으로 구성됨
• 각 오브젝트는 여러 개의 Label을 가질 수 있음

Node Schedule : Pod를 적절한 노드에 할당(생성)

• 직접 선택 : 파드를 할당할 노드에 라벨을 지정하여 해당 노드에 파드를 생성
• 스케줄러가 판단 : 노드의 사용가능한 자원량과 파드가 요구하는 자원량을 확인하고, 적절한 노드에 파드를 스케줄링
  • 파드를 생성할 때 자원의 요구량(request)과 최대 사용 가능한 양(limit)을 설정할 수 있음
  • limit 설정
    • 파드가 사용하는 cpu의 양이 limit 을 초과할 경우 쿠버네티스가 사용량을 조절하여 파드가 종료되지 않음
    • 파드가 사용하는 memory 양이 limit을 초과할 경우 파드가 종료됨

Service

Service를 이용하는 이유

• 파드의 IP가 가변적이기 때문에 파드로만 네트워크를 구성할 경우 안정적이지 않음 (항상 원하는 파드에 접근할 수 있다고 확신할 수 없음)
• 서비스를 이용하여 항상 원하는 파드에 접근할 수 있도록 보장

ClusterIP : 쿠버네티스 클러스터 내에서만 접근 가능한 IP 이용

• 외부에서는 이 서비스를 통해 파드로 접근할 수 없음
• 서비스에는 1개 이상의 파드를 연결할 수 있으며, 여러 개의 파드가 연결되었을 경우 서비스가 Load Balancing을 수행
• 서비스에 **Selector** 옵션으로 라벨을 달아주고, 파드에 동일한 라벨을 지정하면 연결됨
• 서비스의 기본(default) 타입임

💡 인가된 사용자(운영자)만 접근 가능하고, 내부 대시보드를 확인하거나 파드의 상태를 디버깅하는 용도로 사용

• 🥨 심화 설명 서비스의 port와 targetPort 역할
  • port : 서비스가 파드로 트래픽을 전달하기 위해 열어놓는 포트 번호
  • targetPort : 파드가 서비스로부터 트래픽을 받기 위해 열어놓는 포트 번호

NodePort

• 서비스와 각 워커노드의 포트를 연결
• 외부에서 [노드IP]:[포트번호]로 접근하면 서비스로 트래픽이 전달되고, 서비스는 트래픽을 파드로 전달
• 포트 번호는 30000-32767번 중 하나로 할당
• 직접 설정하거나, 임의로 할당할 수 있음

💡 내부에서 사용하다가 외부에서 가끔 접속해야 할 경우 외부망과 포트포워딩을 통해 연결 가능

LoadBalancer

• NodePort와 같은 특성을 가짐 (노드의 한 포트와 서비스가 연결됨)
• 외부에서 LoadBalancer에 접근하면 LoadBalancer가 각 노드의 특정 포트로 트래픽을 LoadBalancing 하는 방식
• CSP에서 사용가능한 서비스 타입

💡 외부에 시스템을 노출하는 용도로 사용

Volume

emptyDir : 컨테이너가 저장공간을 공유하기 위해 사용

• 컨테이너가 동일한 volume을 mount 하면 컨테이너끼리 파일을 공유할 필요 없이 volume에 접근할 수 있음
• pod가 생성될 때 함께 생성되고, pod가 삭제되면 함께 삭제됨 (일시적으로 사용하는 데이터만 저장)
• 같은 volume을 공유할 때 mountPath를 다르게 설정해도 같은 volume을 mount 하고 있는 것

hostPath : pod 간 저장공간을 공유하기 위해 사용

• 같은 호스트(node)를 공유하는 pod는 동일한 volume에 접근 가능
• pod가 재생성될 때 다른 호스트에 생성될 경우 이전 호스트의 volume에는 접근할 수 없음(hostPath이기 때문)
• 다른 노드의 pod와 같은 volume을 공유하고 싶을 때에는 각 hostPath volume의 경로를 동일하게 지정하고, mount하면 됨 (수동으로 mount 해야 함)
• 호스트 내의 파일에 접근해야 할 경우 사용
• 파드가 생성되기 전에 이미 volume이 생성되어야 오류 없이 생성됨

PVC/PV : pod에 영속성있는 저장공간을 제공하기 위해 사용

• PV는 accessModes, localPath, nodeAffinity 등의 속성을 지정해야 함
• PVC는 사용자가 PV를 사용하기 위해 생성
• PVC는 accessModes, resource requests 등의 속성을 지정해야 함
• PVC의 내용을 보고 적절한 PV가 연결됨
• PV 정의 생성 → PVC 생성 → PV 연결 → Pod 생성 시 PVC 마운팅

ConfigMap, Secret

• 환경마다 변수 값을 다르게 설정해야 하는 경우, image를 환경별로 생성/관리하는 것은 비효율적임
• 환경마다 분리해야 하는 변수 값은 ConfigMap, Key 값 등 보안을 위해 사용하는 Key 등은 Secret 이라는 오브젝트에 정의하여 관리

ConfigMap과 Secret 사용

Literal

• ConfigMap과 Secret 모두 Key-Value 쌍으로 메모리에 저장됨
• ConfigMap은 주로 환경변수로 사용하고, Secret은 비밀번호 등 보안과 관련된 요소로 사용
• ConfigMap은 다른 쿠버네티스 오브젝트와 마찬가지로 쿠버네티스 DB(etcd???)에 저장되지만, Secret은 메모리에 저장됨
• ConfigMap은 무한히(무조건은 아님) 저장 가능하지만, Secret은 1Mbyte만 저장 가능 (메모리 성능에 영향을 주는 Secret)
• pod 생성 시 envFrom 속성으로 ConfigMap과 Secret을 지정

File

• File 자체를 ConfigMap 또는 Secret으로 설정 가능
• Secret을 파일로 설정할 경우, 자동으로 파일을 Base64 형식으로 암호화하기 때문에 이미 암호화 되어있는 파일은 설정할 수 없음

Volume Mount (File)

• ConfigMap 또는 Secret으로 설정할 파일을 Volume에 저장하고, Pod가 해당 볼륨을 마운팅하는 방식
• ConfigMap 또는 Secret에서 지정한 파일 경로에 Pod가 접근할 수 있음

💡 File 방식과 Volume Mount 방식의 차이

• File 방식은 이미 Pod가 생성될 때 ConfigMap 또는 Secret이 주입되었기 때문에 File 내용이 변경되어도 Pod에 영향을 미치지 않음 (Pod가 재생성될 경우에만 변경된 File 내용이 반영됨)
• File Mount 방식은 원본이 Pod에 Mount 되기 때문에 File 내용이 변경되면 Pod에 즉시 영향을 미침

Namespace, ResourceQuota, LimitRange

사용 목적

💡 kubernetes 클러스터에서는 사용 가능한 자원이 한정되어 있기 때문에 Namespace 별로 파드를 나누고, ResourceQuota로 자원을 한정하여 다른 Namespace에 영향을 주지 않도록 하고, 너무 큰 자원을 사용하는 Pod로 인해 다른 Pod가 namespace에 들어오지 못하는 일이 없도록 LimitRange로 pod의 자원 사용량을 제한

→ 클러스터 내 자원을 문제없이 관리하기 위해 사용

• Namespace : 쿠버네티스 오브젝트를 분리하는 영역(?)
• ResourceQuota : 쿠버네티스 클러스터의 자원을 할당
• LimitRange : 지정된 자원 사용량 limit을 초과하는 오브젝트 차단 (?)

Namespace

• 네임스페이스 별로 오브젝트를 분리하여 관리할 수 있음
• 쿠버네티스 오브젝트들은 속한 네임스페이스 내에서만 연결 가능 (Node, PV 등은 제외)
• 네임스페이스가 삭제되면 그 안에 있던 오브젝트도 모두 삭제됨

ResourceQuota

• 네임스페이스(또는 노드)의 사용 가능한 자원량을 제한
• ResourceQuota가 설정된 네임스페이스에 Pod를 생성할 경우 반드시 자원 요구량(requests)과 최대 사용량(limits)을 설정해주어야 함
• requests, limits가 설정되지 않은 파드 또는 네임스페이스에 남은 자원량을 초과하는 request를 가진 파드의 경우 해당 네임스페이스에 생성되지 않음

💡 Compute Resource (제한 가능한 자원 사용량)

: CPU, Memory, Storage

Objects Count (제한 가능한 자원 개수)

: Pod, Service, ConfigMap, PVC

LimitRange

• min : 최소 자원 요구량 (requests가 min 이상이어야 함)
• max : 최대 자원 요구량 (limits가 max 이하여야 함)
• maxLimitRequestsRatio : 최대 자원 요구 비율 (limits/request가 비율을 초과하면 안됨)
• defaultRequest : pod의 request를 설정하지 않으면 자동으로 설정되는 requests
• default : pod의 limit을 설정하지 않으면 자동으로 설정되는 limits