쿠버네티스 오브젝트(1) - Pod, Service, Volume

6607 단어 kuberneteskubernetes

Pod

파드의 특징은 크게 Container, Labels, Node Schedule 세 가지로 말할 수 있다.

1. Container

파드 안에는 하나의 독립적인 서비스를 구동할 수 있는 Container가 있다. 컨테이너들은 서비스와 연결될 수 있도록 포트를 가지고 있다. 컨테이너는 여러 포트번호를 가질 수 있지만 한 파드 내에서 컨테이너끼리 포트가 중복될 수는 없다.

2. Labels

Label은 목적에 따라 쿠버네티스 오브젝트를 분류하기 위해 사용한다.
한 파드에는 여러 개의 라벨을 달 수 있고, yaml 파일에서 Key Value 형식으로 만들어준다.
해시태그를 달아 검색하듯이 사용 목적에 따라 파드를 연결할 수 있다.

예를 들면, type:web 이라는 라벨이 달린 파드들을 Service에 연결하거나 Io:production 이라는 라벨이 달린 파드들을 Service에 연결할 수 있다.

Service에 해당 라벨을 연결하기 위해서는 Service를 생성할 때 yaml 파일에 selector:라는 속성으로 라벨을 지정해주면 된다.

3. Node Schedule

파드는 여러 노드들 중 한 노드에 올라가야 하는데, 노드에 파드를 올리는 방법은 두 가지가 있다.

  1. 파드를 만들 때 올릴 노드를 지정하는 방법
# yaml 파일
nodeSelector:
	hostname: node1
  1. 쿠버네티스의 Scheduler가 판단해서 파드와 노드를 연결해주는 방법

파드를 생성할 때, 파드에서 요구될 리소스의 사용량을 명시할 수 있다.이 때 노드의 메모리와 파드의 메모리를 보고 스케줄러가 판단해서 적절한 노드에 파드를 연결해준다.

resources:
   requests:
      memory: 2Gi
   limits:
      memory: 3Gi

파드가 실행되는 도중 메모리가 limitsmemory를 넘기면 파드가 자동으로 종료된다.
cpu는 초과할 경우 request로 낮추고, over시에도 종료되지 않는다.

쿠버네티스가 노드 스케줄링을 할 때, 노드마다 자원량 점수를 매겨서 가장 점수가 높은 노드에 파드를 연결해준다. node1, node2가 있고 두 노드 모두 메모리가 남아있을 때 메모리가 더 많이 남아있는 노드에 연결해준다.

Service

Service는 자신의 Cluster IP를 가지고 있고, 서비스에 파드를 연결해놓으면 서비스의 IP로도 파드에 접근할 수 있다.

파드도 IP 주소를 가지고 있는데 왜 굳이 서비스를 쓸까?

파드는 쿠버네티스에서 시스템장애, 성능장애와 같은 이유로 언제든지 죽을 수 있다. 파드가 죽으면 재생성되면서 IP가 바뀌게 된다. (AWS EC2의 elastic IP를 생각하면 이해가 편하다.)
하지만 서비스의 IP는 절대 바뀌지 않는다. 그래서 서비스에 접근하면 연결되어있는 파드에 항상 접근할 수 있게 된다.

Service는 여러 종류가 있고 사용 목적이 각각 다르다. 여기서는 ClusterIP, NodePort, Load Balancer 세 가지를 소개하겠다.

1. ClusterIP

가장 기본적인 Service로, 기본값으로 설정되어 있다. 서비스를 생성할 때 yaml파일에서 따로 타입을 지정하지 않으면 ClusterIP로 생성된다.

ClusterIP 는 클러스터 내에서만 접근할 수 있고 외부에서는 접근할 수 없다.
서비스에는 파드를 하나는 물론 여러 개까지 연결할 수 있다. 여러 개의 파드를 연결했을 때, 서비스는 트래픽을 분석해서 어떤 파드가 호출될지 결정해 해당 파드에 전달해준다.

외부에서 접근이 불가능하고 클러스터 내에서만 사용하는 IP이기 때문에, IP에 접속할 수 있는 대상은 클러스터 내부에 접근할 수 있는 인가된 사용자이다. (ex.운영자)

ClusterIP의 역할은 쿠버네티스 대시보드를 관리하거나, 각 파드의 서비스 상태 관리하는 것이다.

2. NodePort

ClusterIP가 기본적으로 할당되어 ClusterIP의 기능을 모두 포함한다.

쿠버네티스 클러스터에 있고, NodePort 서비스에 연결되어있는 모든 노드에게 똑같은 포트를 할당한다. 외부로부터 어떤 노드건 그 IP의 포트로 접속하면 서비스로 연결된다.

이 때 NodePort 서비스는 마찬가지로 자신에게 연결되어있는 파드들한테 트래픽을 전달해준다. (node1의 pod1과 node2의 pod2 분산)

어떤 노드로 온 트래픽이건 간에 서비스는 자신에게 연결된 모든 파드에게 트래픽을 전달한다. 이 기능을 쓰지 않으려면 서비스를 생성할 시 yaml파일에 아래의 옵션을 주면 된다.

externalTrafficPolicy: Local

이렇게 옵션을 주면 트래픽이 발생한 해당 파드에게만 트래픽을 전달해준다.

만약 node1pod1을 삭제하고 node1의 포트번호로 연결하면 아무것도 호출되지 않는다. 해당 옵션을 사용하지 않으면 서비스가 트래픽을 node2pod2로 전달해 pod2가 호출된다.

NodePort 서비스는 클러스터 밖에 있긴 하지만 그래도 내부망 안에서 써야 할 때 사용한다.
예를 들면 개발 도중 잠시 데모를 보여줘야 할 때 사용할 수 있는데, 이럴 때는 예외적으로 잠시 노드포트를 뚫어놓고 외부에 보여줄 수 있다.

3. Load Balancer

Load Balancer 서비스도 역시 NodePort 서비스의 성격을 그대로 포함한다.

Load Balancer 서비스는 로드 밸런서가 있고, 각각 노드의 트래픽을 분산시켜주는 역할을 한다.

로드 밸런서에 접속하기 위한 IP 주소는 쿠버네티스에서 기본적으로 생성해주지 않으며, 별도로 외부 접속 IP를 할당해주는 플러그인이 설치되어 있어야 IP주소가 생긴다. Google Cloudamazon같은 서비스를 이용할 경우 자동으로 생성된다.

이 로드밸런서 IP를 통해 외부에서 접속이 가능해지며, 실제로 외부에 시스템을 노출할 때 Load Balancer 서비스를 사용한다.

Volume

Volume은 파드에 종속되는 디스크이다. 데이터를 저장할 때 사용하며, Volume도 역시 emptyDir, hostPath, PVC / PV의 세 가지 종류를 소개하겠다.

1. emptyDir

가장 기본적인 볼륨이다. 컨테이너들끼리 데이터를 공유하기 위해서 볼륨을 사용한다. 볼륨이 최초로 생성될 때는 볼륨이 비어있기 때문에 emptyDir로 명칭한 것이다.

볼륨을 로컬 파일처럼 사용해서 컨테이너들끼리 따로 파일을 주고받을 필요 없이 편하게 사용할 수 있다.

볼륨은 파드에 생성하기 때문에 파드가 재생성되면 볼륨도 삭제 후 재생성되어 데이터가 모두 사라진다. emptyDir 볼륨에 사용하는 데이터는 일시적인 사용 목적에 의한 데이터만 저장해야 한다.

2. hostPath

노드의 path를 볼륨으로 사용한다. 해당 path를 각각의 파드들이 마운트해서 공유하기 때문에 파드들이 죽거나 재생성되어도 볼륨은 사라지지 않는다.

데이터가 사라지지 않는다면 무조건 좋을 것 같지만 그렇지 않다. 파드 입장에서는 단점이 있다.

만약 node1에 있던 pod1이 죽어서 재생성될 경우, 꼭 이전의 노드에 재생성된다는 법은 없다. 재생성될 때 node2에 만들어질 수도 있는 것이다. 또 node1에 장애가 생겨 pod1node2로 옮겨질 수도 있다.

이렇게 파드가 다른 노드로 옮겨졌을 경우 node1에 있는 volumenode2의 파드는 마운트를 할 수가 없다.

굳이 방법을 찾는다면 node2가 추가될때마다 똑같은 이름의 경로를 만들어서 직접 노드에 있는 path끼리 연결해줄 수 있다. 리눅스의 마운트를 사용해서 연결을 직접 해주어야 한다. 이는 쿠버네티스가 제공하는 기능이 아니고, 사람이 하는 거다 보니 실수할 수도 있기 때문에 추천하는 방법은 아니다.

각각의 노드에는 기본적으로 각 노드 자신을 위해 사용되는 시스템 파일, 설정 파일 등이 있는데, hostPath 볼륨은 파드가 이 데이터를 쓸 때 사용한다. 즉, 파드 자신이 할당되어있는 호스트의 데이터를 읽거나 사용해야할 때 쓰면 된다. 이 때 주의할 점은 hostpath는 파드가 만들어지기 전에 사전에 만들어져있어야 한다.

파드의 데이터를 저장하기 위한 용도가 아니라, 노드의 데이터를 파드에서 쓰기 위한 용도이다.

3. PVC / PV

PVCPV는 파드의 영속성있는 볼륨을 제공하기 위해 사용한다.

볼륨은 로컬 볼륨, 외부 amazon, git 등 외부 볼륨, 볼륨을 직접 만들고 관리할 수 있는 솔루션들도 있다.
이런 볼륨들을 직접 PV(Persistent Volume)을 만들어 연결해주는 것이다. 파드는 PVC(Persistent Volume Claim)을 둬서 PV와 연결한다.

영역을 나누면 다음과 같다.

Admin 영역 : PV, Volume
User 영역 : Pod, PVC

PVCPV를 사용할 때의 순서는 다음과 같다.

  1. AdminPV 정의를 생성한다.
  2. UserPVC를 생성한다.
  3. Kubernetes가 적절한 PVPVC를 연결해준다.
  4. UserPod를 생성할 때 PVC를 마운팅한다.

즉, 전문적으로 관리하는 운영자가 PV를 만들어놓고. 사용자가 그 PV를 쓰겠다고 요청하는 과정이다.

좋은 웹페이지 즐겨찾기