쿠버네티스 오브젝트(1) - Pod, Service, Volume
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
파드는 여러 노드들 중 한 노드에 올라가야 하는데, 노드에 파드를 올리는 방법은 두 가지가 있다.
- 파드를 만들 때 올릴 노드를 지정하는 방법
# yaml 파일
nodeSelector:
hostname: node1
- 쿠버네티스의
Scheduler
가 판단해서 파드와 노드를 연결해주는 방법
파드를 생성할 때, 파드에서 요구될 리소스의 사용량을 명시할 수 있다.이 때 노드의 메모리와 파드의 메모리를 보고 스케줄러가 판단해서 적절한 노드에 파드를 연결해준다.
resources:
requests:
memory: 2Gi
limits:
memory: 3Gi
파드가 실행되는 도중 메모리가 limits
의 memory
를 넘기면 파드가 자동으로 종료된다.
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
이렇게 옵션을 주면 트래픽이 발생한 해당 파드에게만 트래픽을 전달해준다.
만약 node1
의 pod1
을 삭제하고 node1
의 포트번호로 연결하면 아무것도 호출되지 않는다. 해당 옵션을 사용하지 않으면 서비스가 트래픽을 node2
의 pod2
로 전달해 pod2
가 호출된다.
NodePort
서비스는 클러스터 밖에 있긴 하지만 그래도 내부망 안에서 써야 할 때 사용한다.
예를 들면 개발 도중 잠시 데모를 보여줘야 할 때 사용할 수 있는데, 이럴 때는 예외적으로 잠시 노드포트를 뚫어놓고 외부에 보여줄 수 있다.
3. Load Balancer
Load Balancer
서비스도 역시 NodePort
서비스의 성격을 그대로 포함한다.
Load Balancer
서비스는 로드 밸런서가 있고, 각각 노드의 트래픽을 분산시켜주는 역할을 한다.
로드 밸런서에 접속하기 위한 IP
주소는 쿠버네티스에서 기본적으로 생성해주지 않으며, 별도로 외부 접속 IP
를 할당해주는 플러그인이 설치되어 있어야 IP
주소가 생긴다. Google Cloud
나 amazon
같은 서비스를 이용할 경우 자동으로 생성된다.
이 로드밸런서 IP
를 통해 외부에서 접속이 가능해지며, 실제로 외부에 시스템을 노출할 때 Load Balancer
서비스를 사용한다.
Volume
Volume
은 파드에 종속되는 디스크이다. 데이터를 저장할 때 사용하며, Volume
도 역시 emptyDir
, hostPath
, PVC / PV
의 세 가지 종류를 소개하겠다.
1. emptyDir
가장 기본적인 볼륨이다. 컨테이너들끼리 데이터를 공유하기 위해서 볼륨을 사용한다. 볼륨이 최초로 생성될 때는 볼륨이 비어있기 때문에 emptyDir
로 명칭한 것이다.
볼륨을 로컬 파일처럼 사용해서 컨테이너들끼리 따로 파일을 주고받을 필요 없이 편하게 사용할 수 있다.
볼륨은 파드에 생성하기 때문에 파드가 재생성되면 볼륨도 삭제 후 재생성되어 데이터가 모두 사라진다. emptyDir
볼륨에 사용하는 데이터는 일시적인 사용 목적에 의한 데이터만 저장해야 한다.
2. hostPath
노드의 path
를 볼륨으로 사용한다. 해당 path
를 각각의 파드들이 마운트해서 공유하기 때문에 파드들이 죽거나 재생성되어도 볼륨은 사라지지 않는다.
데이터가 사라지지 않는다면 무조건 좋을 것 같지만 그렇지 않다. 파드 입장에서는 단점이 있다.
만약 node1
에 있던 pod1
이 죽어서 재생성될 경우, 꼭 이전의 노드에 재생성된다는 법은 없다. 재생성될 때 node2
에 만들어질 수도 있는 것이다. 또 node1
에 장애가 생겨 pod1
이 node2
로 옮겨질 수도 있다.
이렇게 파드가 다른 노드로 옮겨졌을 경우 node1
에 있는 volume
에 node2
의 파드는 마운트를 할 수가 없다.
굳이 방법을 찾는다면 node2
가 추가될때마다 똑같은 이름의 경로를 만들어서 직접 노드에 있는 path
끼리 연결해줄 수 있다. 리눅스의 마운트를 사용해서 연결을 직접 해주어야 한다. 이는 쿠버네티스가 제공하는 기능이 아니고, 사람이 하는 거다 보니 실수할 수도 있기 때문에 추천하는 방법은 아니다.
각각의 노드에는 기본적으로 각 노드 자신을 위해 사용되는 시스템 파일, 설정 파일 등이 있는데, hostPath
볼륨은 파드가 이 데이터를 쓸 때 사용한다. 즉, 파드 자신이 할당되어있는 호스트의 데이터를 읽거나 사용해야할 때 쓰면 된다. 이 때 주의할 점은 hostpath
는 파드가 만들어지기 전에 사전에 만들어져있어야 한다.
파드의 데이터를 저장하기 위한 용도가 아니라, 노드의 데이터를 파드에서 쓰기 위한 용도이다.
3. PVC / PV
PVC
와 PV
는 파드의 영속성있는 볼륨을 제공하기 위해 사용한다.
볼륨은 로컬 볼륨, 외부 amazon, git 등 외부 볼륨, 볼륨을 직접 만들고 관리할 수 있는 솔루션들도 있다.
이런 볼륨들을 직접 PV(Persistent Volume)
을 만들어 연결해주는 것이다. 파드는 PVC(Persistent Volume Claim)
을 둬서 PV
와 연결한다.
영역을 나누면 다음과 같다.
Admin 영역 : PV, Volume
User 영역 : Pod, PVC
PVC
와 PV
를 사용할 때의 순서는 다음과 같다.
Admin
이PV
정의를 생성한다.User
가PVC
를 생성한다.Kubernetes
가 적절한PV
로PVC
를 연결해준다.User
가Pod
를 생성할 때PVC
를 마운팅한다.
즉, 전문적으로 관리하는 운영자가 PV
를 만들어놓고. 사용자가 그 PV
를 쓰겠다고 요청하는 과정이다.
Author And Source
이 문제에 관하여(쿠버네티스 오브젝트(1) - Pod, Service, Volume), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@younge/쿠버네티스-오브젝트-Pod-Service-Volume저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)