Service
파드 컨테이너는 일시적인 존재이기 때문에 언제든지 할당된 IP_주소가 바뀔 수 있다. 클라이언트 입장에서는 늘 변하는 파드 서버의 IP_주소를 알기 어렵기 때문에 쿠버네티스에서는 Service 객체를 통해서 이 Service의 고정된 IP_주소를 사용하게 한다.
여기서 사용되는 Service는
￭ ClusterIP : 타입을 지정하지 않으면 기본으로 실행되는데 클러스터 내부의 파드에 Service의 이름으로 접근하게 한다.
￭ NodePort : ClusterIP의 접근 범위뿐만 아니라 쿠버네티스 클러스터 외부에서 '노드의_IP_주소:포트_번호'로 접근하게 한다. 외부 호스트 Ubuntu 머신에서 내부 컨테이너에 접속하는 경우이다.
￭ LoadBalancer : NodePort의 접근 범위뿐만 아니라 쿠버네티스 클러스터 외부에서 대표 IP_주소로 접근하게 한다.
￭ ExternalName : 쿠버네티스 클러스터 내부의 파드에서 외부 IP_주소에 Service 이름으로 접근하게 한다. 내부 컨테이너에서 외부 호스트 Ubuntu 머신과 접속하는 경우이다.
- CluserIP
Service를 만들 때 Service 타입을 지정하지 않으면 ClusterIP로 생성되는데 명시적으로 지정해도 된다. 이것은 클러스트 내부에서 내부 DNS에 등록한 이름으로 특정 파드에 요청을 전송하게 한다. 매니페스트에 clusterIP:None으로 써주면 Headless 설정으로 Service가 동작하는데 대표 IP_주소를 획득하지 않고 로드 밸런싱도 이뤄지지 않지만 파드들의 IP_주소를 내부 DNS에 등록해서 파드의 IP_주소 변경을 최신 상태를 유지시킨다.
- NodePort
Service 타입에 NodePort를 지정하면 ClusterIP 기능에 더해서 노드의 IP_주소에 공개 포트가 열린다. 이를 통해서 쿠버네티스 클러스터 외부에서 내부의 파드에게 요청을 보낼 수 있게 되는데 공개 포트의 범위는 기본적으로 30,000~32,767까지이다. 클라이언트가 노드의 IP와 포트로 요청을 보내면 파드에게 전달된다. NodePort 타입의 Service를 만들면 클러스터의 모든 노드에 지정한 포트가 열리게 되고, 각 노드가 수령한 요청의 대상이 되는 파드들에게 로드 밸런싱으로 전송된다. 노드들 앞에 로드 밸런서가 있는 것이 좋은 설정이다.
하지만 사용자가 특정 노드에 접속하고 있을 때 해당 노드가 하드웨어 등의 문제로 셧다운 되면 Service를 이용할 수 없게 되고, 이미 사용 중인 포트도 쓸 수 없게 된다. 네임스페이스로 쿠버네티스 클러스터를 분할해서 사용할 때 이런 문제가 발생될 수 있다. 따라서 NodePort는 정식 Service에서는 별로 사용을 권하지 않는다.
- LoadBalancer
이 로드밸런서는 외부에서의 요청이 파드들에게 고르게 전해지게 해준다. 또 이것은 NodePort를 사용하기 때문에 ClusterIP도 자동으로 만들어진다. AWS와 같은 퍼블릭 클라우드에서는 각 업체가 공개하는 로드 밸런서와 연동된다. 이때 방화벽도 각 클라우드 업체별로 별도 설정이 필요할 수 있다.
- ExternalName
ExternalName은 지금까지 알아본 것들과 반대로 파드에서 쿠버네티스 클러스터의 외부 엔트포인트의 이름을 풀어서 접속하게 해주는 서비스이다. 예를 들어 노드 내의 파드 내의 어느 컨테이너가 외부 AWS와 같은 퍼블릭 클라우드의 데이터베이스나 인공지능 API 서버 등에 접근할 때 사용될 수 있다. 파드에서 쿠버네티스 클러스터 외부의 엔드 포인트에 접속할 때 네임스페이스에서 Service_명으로 IP_주소를 얻을 수 있다.
또 쿠버네티스 클러스터 내의 Service 교체도 용이하다. 다만 외부 DNS_명을 등록할 때 spec.externalName에는 IP_주소를 설정할 수 없다는 제한이 있다. Service의 매니페스트에 IP_주소를 설정하지 않는다면 Headless 서비스를 이용하는 것이 좋다.
Service와 파드의 연결
외부에서의 Service 요청을 파드 컨테이너에게 전송할 때 어느 파드에게 연결할지 셀렉터의 라벨과 일치하는 파드를 etcd(외부 저장공간)에서 선택해서 결정한다. Service 매니페스트와 디플로이먼트 매니페스트의 Service 셀렉터와 디플로이먼트 파드 템플릿에서 metadata. label에 app:web을 각각 기술하면 동일한 라벨 서비스 요청을 웹 파드에 전송한다. 하나의 파드 템플릿으로 만들어지는 파드들(파드_그룹)은 속성이 같아서 라벨도 같다. 따라서 디플로이먼트로 만들어지는 파드들(파드_그룹)은 같은 라벨을 가지고 있어서 Service 요청도 함께 받는다. 이처럼 라벨에 의해 전송되는 파드 결정 방식은 유연성이 크기 때문에 셀렉터의 값을 바꾸기만 하면 Service를 받는 파드의 그룹을 쉽게 변경할 수 있다.
wget –q –O – http://web-service(Service_명)나
OR wget –q –O – http://10.105.121.218(IP_주소) 해서 외부 노드에서 Nginx의 웹 사이트를 서비스_명과 IP_주소로 확인해본다.
Session Affinity
경우에 따라서는 외부에서 온 요청을 언제나 같은 파드로 전송해야 할 때도 있다. 그런 경우에 매니페스트에서 sessionAffinity를 ClientIP로 설정하면 된다.
=>파드의 각 호스트_명을 동일하게 하면 round-robin이 되어서 어느 파드나 동일한 실행이 된다. 클라이언트 쪽에서 보면 어느 노드에 접속하는지 알 필요가 없다.
NodePort
NodePort는 외부에서 접속할 때 사용되는 첫번째 포트이다. 그리고 그냥 Port는 클러스터 내부에서 사용되는 외부에서 접속할 때 사용되는 두번째 포트이고, targetPort는 Service 객체로 전달된 요청을 파드(deployment)로 전달할 때 사용되는 포트이다.
NodePort ->Port ->targetPort로 진행된다고 볼 수 있다.
ExternalName 서비스
이 서비스는 쿠너네티스 상의 파드에서 외부의 어플에 접속하는 하이브리드 구성 어플을 개발할 때 유용하다. 파드는 이 서비스_명으로 외부의 엔트 포인트에 접근할 수 있게 된다.
스토리지
쿠버네티스에 배포된 파드에 실행중인 어플이 데이터를 보존하기 위해서는 내부 혹은 외부의 스토리지 시스템과 연결해서 퍼시스턴트 볼륨으로 이용해야 한다. 데이터 보존이란 데이터의 분실, 파손, 잘못된 변경 등을 막는 일이다. 데이터 분실은 조작 실수, 해킹, 디스크 고장, 프로그램 예외나 에러, 비정상 종료, 데드락 등에 의해서 발생된다.
외부 스토리지 시스템을 사용하면 여러 개의 물리적인 장비들을 묶어서(NAS 서버 방식) 단일 장애점의 문제를 극복하고 가용성을 높일 수 있다. 외부 스토리지 시스템으로는 하드웨어적인 전용 스토리지 장비 사용이나 소프트웨어적인 일반적인 서버를 클러스터화해서 저장장치로 사용하는 SDS(Software Defined Storage), 그리고 이 둘의 조합을 생각해 볼 수 있다.
퍼시스턴트 볼륨에서 퍼시스턴트란 컨테이너나 파드가 종료되어도 그 안의 데이터는 분실되지 않는다는 의미이다. 볼륨이란 외부 스토리지를 컨테이너에 마운트한 논리적인 볼륨을 말한다. 쿠버네티스에서는 이런 외부 볼륨을 은폐하는 구조로 되어 있어서 스토리지의 추상화라고 부른다.
스토리지의 종류와 클러스터 구성
쿠버네티스와 외부 스토리지를 연동해서 사용할 수도 있지만 빠르게 읽고 쓸 수 있는 클러스터 내부의 볼륨을 사용하는 것도 가능하다. 노드 내부에서 간단하게 사용할 수 있는 볼륨으로 emptyDir과 hostPath가 있다.
▪ emptyDir : 노드의 디스크를 파드가 일시적으로 사용하게 하는 방법인데 같은 파드의 컨테이너 간에는 볼륨을 공유할 수 있지만 다른 파드에서는 접근할 수 없다. 그리고 파드가 종료하면 emptyDir은 삭제된다.
▪ hostPath : emptyDIR처럼 동일하게 노드의 디스크를 사용하지만 같은 파드의 컨테이너 간에서 볼륨을 공유할 수 없다. 파드가 종료되어도 hostPath는 파드와 함께 삭제되지 않지만 각 노드의 디스크를 사용하기 때문에 다른 노드에 배포된 파드 간에 데이터 역시 공유할 수 없다. 그리고 노드가 정지하면 데이터에 접근하지 못하므로 외부 스토리지가 준비되기 전에 임시적으로 간단히 사용하는데 쓰일 수 있다.
외부 스토리지와 파드가 연동되면 모든 노드에서 외부 스토리지 시스템에 접근할 수 있게 된다. 그러면 노드가 정지되어도 파드가 다른 노드로 이동해서 어플은 지속적으로 서비스된다. 하지만 외부 스토리지 시스템을 사용한다고 해서 반드시 여러 노드에서 볼륨을 공유할 수 있는 것은 아니다. 이는 서버와 스토리지를 연결하는 NFS, NAS, iSCSI(Webmin), 소프트웨어, 그리고 클라우드 스토리지 서비스 등 스토리지의 작동 방식에 따라서 다른데, NFS처럼 파일 시스템을 공유하는 경우 여러 노드에서 볼륨을 공유할 수 있지만, iSCSI나 NAS처럼 블록 스토리지를 기반으로 하는 경우에는 하나의 노드에서만 접근이 가능하다.
파드가 외부의 저장 공간을 이용하는 방법으로
▪ local의 HDD를 마운트하는 방법이 있고
▪ NFS(Network File System: Linux와 Linux 간의 파일 공유)를 이용해서 다른 호스트에 있는 저장 공간을 마운트하는 방법이 있으며
<= Windows와 Linux 간의 파일/프린터 공유는 Samba를 사용한다.
▪ NAS(Network Attached Storage)를 이용해서 별도의 저장 공간을 마운트하는 방법이 있다.
- 스토리지 시스템 방식
스토리지 시스템의 특징에 따라 퍼시스턴트 볼륨의 기능에 차이가 있다.
▸hostPath : 쿠버네티스와 연계 가능한 대표적인 스토리지 시스템으로 파드가 배포된 노드의 파일 시스템상 디렉터리에 마운트
▸local : 노드의 디스크를 마운트
▸iSCSI : iSCSI를 마운트
▸NFS : NFS의 파일 시스템을 마운트
▸GlusterFS : SDS 중 하나인 GlusterFS의 논리 볼륨을 마운트
▸awsElasticBlockStore : 컨테이너에서 aws의 EBS를 마운트
▸azureDisk : Azure 디스크를 마운트
▸azureFile : Azure의 SMB 파일 시스템을 마운트
▸gcePersistentDisk : GCE(Google Compute Engine) 디스크를 마운트
▸IBM Cloud Storage-File Storage : IBM Cloud의 파일 스토리지(NFS)를 마운트
▸IBM cloud Storage-Block Storage : IBM Cloud의 블록 스토리지(iSCSI)를 마운트
등이 있다.
- 스토리지 추상화와 자동화
파드 상의 컨테이너는 공통된 정의 방법에 따라 퍼시스턴트 볼륨을 마운트할 수 있다. 추상화 레이어 객체 덕분에 다양한 스토리지 시스템의 상세한 파라미터를 설정하지 않고도 매니페스트의 파드 템플릿에 간단히 기술해서 퍼시스턴트 볼륨을 사용할 수 있다.
쿠버네티스 객체는 PV(Persistent Volume)를 요구하는 PVC(PV Claim)와 실제 볼륨인 PV로 이뤄져 있다. PV를 작성해두고 파드의 매니페스트에 PVC 이름을 기술하면 컨테이너가 PV 퍼시스턴트 볼륨을 마운트한다. 이들은 PVC를 YAML 파일로 작성해서 적용한다.
▪ 동적 프로비저닝 : 컨테이너 ->파드 ->PVC ->Storage Class(Provisor, Persistent Volume) ->Storage Service ->Storage로 작동되고
▪ 수동 스토리지 : 컨테이너 ->파드 ->PVC -> PV ->Storage Service ->Storage로 작동된다.
파드를 생성하는 YAML 파일에 PVC를 volumeMounts에 pvc1 이름으로 기술해서 파드의 컨테이너 파일 시스템 /mnt/로 마운트한다. pvc1은 persistentVolumeClaim의 PVC 이름으로 data1으로 지정한다. data1 PVC의 스토리지 클래스는 standard 2GiB 용량으로 지정한다.