오브젝트들을 간략하게 알아보고,
디테일은 추후 사용하며 보강한다.

Pod

출처: https://kubetm.github.io/k8s/03-beginner-basic-resource/pod/

Pod란 쿠버네티스에서 실행되는 최소 단위로, 하나의 서비스를 독립적으로 구동할 수 있는 컨테이너들을 가진다.
Pod의 컨테이너는 하나의 호스트로 묶여있다고 볼 수 있다.
그래서 다른 컨테이너여도 Port 번호가 중복되어서는 안된다.

이 Pod는 고유의 IP 주소가 할당된다.
쿠버네티스 클러스터 내에서만 이 IP를 통해 접근할 수 있고,
외부에서 접속하고자 하면 별도의 설정이 필요하다.
Pod는 언제든지 죽을 수 있음을 상정하고 만들어진 오브젝트로써,
Pod에 문제가 생겼다고 판단되면 쿠버네티스는 이 Pod를 삭제하고 새롭게 만들어 내는 오토 힐링 기능을 실행한다.
그러면서 이 IP 주소는 새롭게 할당되는데, 이 과정을 통해 Pod의 IP는 휘발성이 있음을 알 수 있다.

Label

각각의 파드나 오브젝트별로 Label을 key:value 값으로 설정해 줄 수 있다. 주로 pod를 프로덕션, 개발, db 등 환경을 나눠서 Lable을 정해준 뒤, 사용성에 맞게 분류하고 접근하기 쉽도록 사용한다.

Node Schedule

Pod를 생성할 때, 원하는 Node를 선정해서 사용할 수 있다.
보통은 스케쥴러가 자동으로 할당한다.

이는 리소스의 제약에 맞추어 설정하게 된다.
부가적으로 알아둘 것은 Memory는 초과시 Pod를 종료시키지만, CPU는 request 수치까지 낮출 뿐 Pod를 종료시키진 않는다.

Service

서비스는 외부에서 쿠버네티스 클러스터에 접근하기 위한 방법을 말한다.

Cluster IP

디폴트 설정으로, 서비스에 클러스터 IP (내부 IP)를 할당한다.(Pod의 IP와 유사하다)
쿠버네티스 클러스터 내에서는 이 서비스에 접근이 가능하지만, 클러스터 외부에서는 외부 IP를 할당 받지 못했기 때문에, 접근이 불가능하다.

NodePort

노드포트 서비스를 지정하게 되면 모든 워커 노드의 특정 포트를 열고 이 포트로 오는 모든 요청을 노드포트 서비스로 전달한다.
그리고 노드포트 서비스가 해당 요청을 처리할 수 있는 파드로 요청을 전송한다.

간단한 NodePort의 yaml 파일이다.

apiVersion: v1
kind: Service
metadata:
  name: svc-2
spec:
  selector:
    app: pod
  ports:
    - port: 8080
      targetPort: 80
      nodePort: 31001
  type: NodePort

Port 정보가 많아 헷갈리기 쉬워 정리하자면,

• NodePort
  외부에서 접속하기 위해 사용하는 포트

• port
  Cluster 내부에서 사용할 Service 객체의 포트

• targetPort
  Service 객체로 전달된 요청을 Pod(deployment)로 전달할때 사용하는 포트

전체 서비스 흐름으로 보면 NodePort --> Port --> targetPort

LoadBalancer

로드밸런서는 우리가 흔히 아는 로드밸런서와 같이 부하를 분산해주는 서비스이다.
로드밸런서 타입을 사용하려면 외부 서비스 업체의 도움을 받거나 플러그인이 필요하다.
보통 클라우드 벤더에서 제공하는 설정 방식이다.

Ingress

클러스터 외부에서 내부로 접근하는 요청들을 어떻게 처리할 지 정의해둔 규칙들의 모음이다.

• 외부에서 접속가능한 URL 사용
• 트래픽 로드밸런싱
• SSL 인증서 처리
• 도메인 기반 가상 호스팅 제공

인그레스는 위와 같은 기능들에 대해 정의해둔 규칙들을 정의해둔 리소스이고, 이를 실제 동작하기 위해서는 인그레스 컨트롤러가 필요하다.

인그레스 컨트롤러가 있어야 인그레스를 충족할 수 있다.
인그레스 리소스만 생성한다면 효과가 없다.

ingress-nginx와 같은 인그레스 컨트롤러를 배포해야 할 수도 있다.
여러 인그레스 컨트롤러 중에서 선택할 수도 있다.

인그레스 컨트롤러의 궁극적인 목표는 접속하는 경로에 따라 다른 결괏값을 제공하기 위함이다.

Volume

쿠버네티스 파드 내에서 돌아가는 컨테이너는 고유한 파일 시스템을 갖는다.
그렇기 때문에 컨테이너가 재시작하게 되면 이전에 컨테이너에서 쓰여진 파일시스템은 새롭게 시작된 컨테이너가 볼 수 없다.
이러한 한계를 극복하기 위해 볼륨을 사용한다.

emptyDir

emptyDir 볼륨은 이름에서 알 수 있듯이 빈 디렉터리로 초기화되는 볼륨이다.
이 볼륨 유형은 동일 파드에서 실행 중인 컨테이너 간 파일을 공유할 때 사용한다.

emptyDir 볼륨은 이를 포함하는 파드를 위해 특별히 생성되고 독점적으로 사용되는 디렉터리이다.
파드가 삭제되면 볼륨과 이에 저장된 파일들은 삭제된다.

hostPath

emptyDir Volume은 Pod가 종료되면 삭제되는 반면 hostPath은 그렇지 않다.

hostPath은 호스트의 디렉터리(Node 단위)를 Pod와 공유하여 데이터를 저장한다.
hostPath은 노드 데이터에 접근하기 위한 용도로 사용할 때 유용하다.

hostPath은 데이터 저장소로 채택하기에는 적합하지 않다.
볼륨이 노드를 기준으로 생성되기 때문에, 여러가지 이유로 파드가 같은 노드에 생성되지 않는다면 기존의 볼륨에 연결할 수 없다.

PVC/PV

PV는 볼륨 자체를 뜻한다. 클러스터 안에서 자원으로 다루고, 파드와는 별개로 관리되며 별도의 생명 주기가 있다.

PVC는 사용자가 PV에 하는 요청이다.
사용하고 싶은 용량은 얼마인지, 읽기/쓰기는 어떤 모드로 설정하고 싶은지 등을 정해서 요청한다.

이렇게 까다로운 볼륨을 만든 이유는 볼륨 관리를 관리자와 사용자의 입장으로 나누기 위해서이다.

쿠버네티스에 애플리케이션을 배포하는 개발자는 어떤 종류의 스토리지 기술이 사용되는지 알 필요가 없으며, 이를 전적으로 클러스터 관리자만의 영역으로 분리하기 위함이다.

시스템 관리자가 실제 물리 디스크를 생성한 후에, 이 디스크를 PersistentVolume이라는 이름으로 쿠버네티스에 등록한다.
개발자는 Pod를 생성할때, 볼륨을 정의하고, 이 볼륨 정의 부분에 물리적 디스크에 대한 특성을 정의하는 것이 아니라 PVC를 지정하여, 관리자가 생성한 PV와 연결한다.

PVC/PV 생명주기

1. Provisioning(프로비저닝)
   PV를 만드는 단계를 프로비저닝(Provisioning)이라고 한다. 프로비저닝 방법에는 두 가지가 있는데, PV를 미리 만들어 두고 사용하는 정적(static) 방법과 요청이 있을 때 마다 PV를 만드는 동적(dynamic) 방법입니다.

2. Binding(바인딩)
   바인딩(Binding)은 프로비저닝으로 만든 PV를 PVC와 연결하는 단계이다. PVC에서 원하는 스토리지의 용량과 접근방법을 명시해서 요청하면 거기에 맞는 PV가 할당 된다. 이 때 PVC에서 원하는 PV가 없다면 요청은 실패하지만, PVC는 원하는 PV가 생길 때까지 대기하다가 바인딩합니다.
   PV와 PVC의 매핑은 1대1 관계 이다.

3. Using(사용)
   PVC는 파드에 설정되고 파드는 PVC를 볼륨으로 인식해서 사용합니다.
   할당된 PVC는 파드를 유지하는 동안 계속 사용하며 시스템에서 임의로 삭제할 수 없다.

4. Reclaiming(반환)
   사용이 끝난 PVC는 삭제되고 PVC를 사용하던 PV를 초기화(reclaim)하는 과정을 거친다.

설정

ConfigMap, Secret

컨피그맵은 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 오브젝트이다. 파드는 볼륨에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있다.

ConfigMap에 저장된 데이터는 1MiB를 초과할 수 없다. 이 제한보다 큰 설정을 저장해야 하는 경우, 볼륨을 마운트하거나 파일을 사용해야 한다.

ConfigMap은 보안 또는 암호화를 제공하지 않는다. 저장하려는 데이터가 기밀인 경우, Secret을 사용한다.

자원 격리

Namespace

네임스페이스는 쿠버네티스 클러스터 하나를 여러 개의 논리적인 단위로 나누어서 사용하는 것이다.
네임스페이스 덕분에 쿠버네티스 클러스터 하나를 여러 개 팀이나 사용자가 공유할 수 있다.
또한 클러스터 안에서 용도에 따라 실행해야 하는 앱을 구분할 때도 네임스페이스를 사용한다.

ResourceQuota

리소스 쿼터는 네임스페이스별 총 리소스 사용을 제한하는 제약 조건을 설정한다.
유형별로 네임스페이스에서 만들 수 있는 오브젝트 수와 해당 네임스페이스의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을 제한할 수 있다.
특정 부분에서 리소스를 과도하게 사용하지 못하도록 하기 위함이다.
리소스쿼터를 설정하게되면 각 파드에 리퀘스트와 리미트를 반드시 설정해야한다.

LimitRange

기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 컴퓨팅 리소스로 실행된다.
네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있는데, 이 때 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있어 리미트레인지로 네임스페이스에서 파드 하나하나의 리소스량의 상한을 설정한다.

출처: https://kubetm.github.io/k8s/03-beginner-basic-resource/namespace/

ReplicaSet

레플리카셋은 실행되는 파드 개수에 대한 가용성을 보증 하며 지정한 파드 개수만큼 항상 실행될 수 있도록 관리 한다.

레플리카셋은 템플릿, 레플리카, 셀렉터 세가지 속성으로 관리된다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
spec:
  template:
    metadata:
      name: nginx-replicaset
      labels:
        app: nginx-replicaset
    spec:
      containers:
      - name: nginx-replicaset
        image: nginx
        ports:
        - containerPort: 80
  replicas: 3
  selector:
    matchLabels:
      app: nginx-replicaset

• Template
  템플릿은 레플리카셋이 파드를 유지하기 위해 재생성되는 파드가 어떤 속성 값을 가질지 지정하는 속성이다.

• Replicas
  유지될 파드의 개수를 지정한다. 현재 레플리카셋을 구동중이어도 이 Replicas 속성을 조절하여 스케일링이 가능하다.

• Selector
  matchLabels와 matchExpressions라는 속성을 통해 라벨을 디테일하게 지정할 수 있다. 세부 옵션으로는 Exists, DoesNotExist, In, NotIn이 있다.

Deployment

Deployment는 ReplicaSet 보다 큰 상위 오브젝트이며, 배포 작업을 좀 더 세분화 하여 조작할 수 있는 기능을 가지고 있다.

디플로이먼트는 레플리카셋과 비슷한 구성을 가져간다.
실제로 디플로이먼트를 선언하면, 레플리카셋을 생성하고 레플리카셋을 통해 파드를 생성한다.

디플로이먼트를 사용하는 이유는 배포에 강점이 있기 때문이다.

디플로이먼트를 통해 할 수 있는 기능은 아래와 같다.

• 리크리에이트
• 롤링 업데이트
• 블루/그린 업데이트
• 카나리아 업데이트

DaemonSet

레플리카셋같은 경우는 노드의 자원량에 따라 파드를 유동적으로 스케쥴링한다.
하지만 데몬셋은 이런 부분을 신경쓰지 않고 반드시 노드당 하나씩 Pod를 생성하는 오브젝트이다.

데몬셋은 딱 하나씩만 필요한 작업들에 주로 사용한다.
주로 로그, 모니터링같은 시스템이다.