[패스트캠퍼스 챌린지 12일차] Service & PVC

쿠버네티스 리소스 마지막으로 다룰 예정입니다. Service와 PVC인데요. 각각 다루어보겠습니다.

 

1. Service의 정의

Service는 쿠버네티스에 배포한 application(Pod)를 외부에서 접근하기 쉽게 추상화한 리소스입니다. 

Pod는 IP를 할당받고 생성되지만, 언제든지 죽었다가 살아날 수 있으며, 그 과정에서 IP는 항상 재할당을 받게 됩니다. 여기서 문제는 고정된 IP로 원하는 Pod에 접근을 할 수 없다는 점입니다. 따라서 클러스터 외부 혹은 내부에서 Pod에 접근할 때, Pod의 IP가 아닌 Service를 통해 접근하는 방식을 거칩니다. Service는 고정된 IP를 가지며, 하나 혹은 여러 개의 Pod와 매칭 하게 되며 클라이언트가 Service의 주소로 접근하면, 실제로는 Service에 매칭된 Pod에 접속할 수 있습니다. 

 

2. Service 생성하기

minikube를 실행하고, 지난 글에서 생성한 deployment를 다시 생성(deployment.yaml)합니다. 그 후 실행(kubectl apply -f deployment.yaml)을 해봅니다. 

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

 

생성된 Pod의 ip를 확인하고 접속을 시도해봅니다.

# Pod 의 IP 를 확인
kubectl get pod -o wide

curl -X GET <POD-IP> -vvv
ping <POD-IP>

접속이 안되는 것을 알 수 있다. 

 

이를 실행하고 Pod를 보면 ip(POD-IP)가 다 pod마다 다른 것을 확인이 가능합니다. 이 ip들은 클러스터 내부에서만 접근이 가능한 ip입니다. minikube 내부로 접속해서 통신이 되는지 확인해보겠습니다.

# minikube 내부로 접속
minikube ssh

curl -X GET <POD-IP> -vvv
ping <POD-IP>

minikube 내부로 접속 후 통신이 되는 것을 알 수 있다. 

 

이제 위에서 만든 deployment와 맞는 service를 생성(service.yaml)해보겠습니다. 

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  type: NodePort # Service 의 Type 을 명시하는 부분 ** 
  ports:
  - port: 80
    protocol: TCP
  selector: # 아래 label 을 가진 Pod 을 매핑하는 부분
    app: nginx

spec에 type 부분이 있습니다. Service의 Type을 비교할 때에는 NodePort, LoadBalancer, ClusterIP가 있습니다. 이 부분은 여기를 참고해주시면 좋을 것 같습니다. 저희는 NodePort을 이용해 보겠습니다.

 

 

 

그 후 service를 실행(kubectl apply -f service.yaml)합니다. 그 후 service를 get해봅니다.

# PORT 80:<PORT> 숫자 확인
kubectl get service

# 이렇게 서비스를 통해서 클러스터 외부에서도 정상적으로 pod 에 접속할 수 있는 것을 확인!
curl -X GET $(minikube ip):<PORT>

get service를 이용해 port를 확인함(사진에서는 30441)

 

 

html 형태로 나오면 성공

 

 

 

 

 

 

 

 

 

 

 

 

 

3. PVC 정의

stateless 한 pod를 영구적으로 Data를 보존하고 싶은 경우에 사용하는 리소스를 PVC(Persistent Volume Claim)라고 부릅니다. PVC는 PV(Persistent Volume)라는 리소스가 함께 따라다닙니다. 두 리소스 PV, PVC의 차이를 정리해보면,

- PV는 관리자가 생성한 실제 저장 공간의 정보를 담고 있음

- PVC는 사용자가 요청한 저장 공간의 스펙에 대한 정보를 담고 있는 리소스

입니다. 관리자와 사용자의 차이가 있다는 것을 염두하시면 될 것 같습니다. Pod 내부에서 작성한 데이터는 기본적으로 언제든지 사라질 수 있기 때문에 보존하고 싶은 데이터가 있다면 Pod에 PVC를 mount를 해서 사용해야 한다는 것을 기억하셔야 합니다. PVC를 사용하면 여러 pod 간의 data 공유가 쉽게 가능합니다. 이러한 PVC의 역할은 도커에 docker run의 -v 옵션인 도커 볼륨과 유사한 역할을 한다고 생각하시면 됩니다. 

 

 

4. PVC 생성하기

minikube를 생성하면 기본적으로 minikube와 함께 설치되는 storageclass가 존재합니다.("kubectl get storageclass"를 통해 이미 설치된 storageclass를 확인할 수 있습니다.) 이는 PVC를 생성하면 해당 PVC의 스펙에 맞는 PV를 즉시 자동으로 생성해준 뒤, PVC와 매칭 시켜준다고 생각하면 됩니다. pvc.yaml을 아래 내용을 붙여 실행("kubectl apply -f pvc.yaml")합니다. 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec: # pvc 의 정보를 입력하는 파트
  accessModes:
    - ReadWriteMany # ReadWriteOnce, ReadWriteMany 옵션 선택 가능
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Mi # storage 용량 설정
  storageClassName: standard # 방금 전에 확인한 storageclass 의 name 을 입력

 

pvc와 동시에 pv까지 함께 생성된 것을 확인할 수 있습니다.

kubectl get pvc,pv

 

 

5. Pod에서 PVC 사용하기

PVC의 역할을 제대로 확인하기 위해 pod를 생성하고 지우는 행위를 할 예정입니다. 

volumeMounts, columes가 추가된 pod를 생성합니다. 이름은 "pod-pvc.yaml"로 하겠습니다. 그 후 실행("kubectl apply -f pod-pvc.yaml")하겠습니다. 

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html" # mount 할 pvc 를 mount 할 pod 의 경로 작성
        name: mypd # 어떤 이름이든 상관없으나, 아래 volumes[0].name 과 일치해야함
  volumes:
    - name: mypd # 어떤 이름이든 상관없으나, 위의 volumeMounts[0].name 과 일치해야함
      persistentVolumeClaim:
        claimName: myclaim # mount 할 pvc 의 name 을 작성

그 후 아래 명령어를 통해 pod에 접속하여 mount 한 경로와 그 외 경로에 파일을 생성합니다. mount한 경로에도 파일을 추가로 생성했다는 것을 기억해두세요.

kubectl exec -it mypod -- bash

touch hello-pvcpvc

cd /var/www/html # mount path로 이동

touch hello-pvcpvc

mount 경로와 그 외 경로에 파일을 하나씩 생성함

 

 

pod를 삭제하고 pvc가 그대로 남아 있는지 확인해봅니다.

kubectl delete pod mypod

kubectl get pvc,pv

 

 

해당 pvc를 mount 하는 pod를 다시 생성해봅니다. 여기서 pod에 접속하여 이전에 작성한 파일들이 지워졌는지, 그대로 있는지 확인해보겠습니다. 

kubectl apply -f pod-pvc.yaml

kubectl exec -it mypod --bah

ls # hello-pvcpvc 파일이 사라져 있음

cd /var/www/html

ls # hello-pvcpvc 파일이 보존이 되어있음

ls를 수행 후 mount된 경로에만 존재하는 것을 알 수 있다. 

 

 

이상으로 쿠버네티스의 리소스들을 조금씩 알아보았습니다. 정말 간단한 개념만 짚고 넘어갔습니다. 다음 글 부터는 Data Management 시리즈로 찾아뵙겠습니다. 

 

쿠버네티스 조금 더 알아보기 위한 초심자 레퍼런스

- 공식 Document

https://kubernetes.io/ko/docs/home/

쿠버네티스 문서

 

- Interactive Tutorial

https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/

대화형 튜토리얼 - 클러스터 생성하기

---

https://bit.ly/37BpXiC

패스트캠퍼스 [직장인 실무교육]

 

* 본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

 

 

 

 

---