책보고 따라해보는 쿠버네티스: (4) Ingress, PV, PVC

 

책 98% 구글링 1% 실습경험 1%의 기록..

출처: 시작하세요 도커/쿠버네티스 - 용찬호 지음

 

이제 뭔가 실무랑 밀접한 것들이 나오는것 같다

 

인그레스 Ingress

$ kubectl get ing (역시나 줄임말, 익숙해지자)

=>No resources found 

만들어보자

$ vi ingress-example.yaml

alicek106.example.com 으로 오는 요청에 대해 처리 규칙이 보이는데

alicek106.example.com/echo-hostname이라는 요청을 hostname-service라는 서비스로 전달하고 있다.

단지 규칙이므로 인그레스 컨트롤러(Ingress Controller)라는 특수 서버에 적용해야만 그 규칙을 사용할 수 있으니 반드시 인그레스와 인그레스 컨트롤러 서버는 함께 사용되어야 한다.

( @Controller에서 @RequestMapping 을 정의 해야한다는 말 같다 )

 

인그레스 컨트롤러 Ingress Controller

종류가 많다고 한다. 책에서는 Nginx 웹서버 인그레스 컨트롤러가 나옴

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.35.0/deploy/static/provider/aws/deploy.yaml

nginx 웹서버 인그레스 컨트롤러 생성하려고 하니 네임스페이스부터 컨피그맵등 온갖 리소스가 생성되고 있다.

아래 명령어로 확인해보면 Nginx 웹서버가 생성되어 있음

$ kubectl get pods,deployment -n ingress-nginx

자동생성된 서비스는 LoadBalancer 타입

$ kubectl get svc -n ingress-nginx

일단 여기까지 소감은 인그레스는 L4 스위치 같다?

 

 

인그레스 어노테이션 Ingress annotation

 

# $ kubectl api-resource로 보면 리소스가 어떤 apiVersion과 매핑되는지 알 수 있다.

apiVersion: networking.k8s.io/v1beta1  
kind: Ingress

metadata:
        name: ingress-example
        annotations:
                nginx.ingress.kubernetes.io/rewrite-target: /$2 # path 이하 경로를 전달한다.
                kubernetes.io/ingress.class: "nginx"    # 어떤 ingress controller 사용하는지 명시

spec:

        tls:  # tls 옵션 적용. https로 redirect 된다. 
                - hosts:
                        - fullmooney.tistory.com
                  secretName: tls-secret
        rules:
                - host: fullmooney.tistory.com
                  http:
                          paths:
                                  - path: /echo-hostname(/|$)(.*) # echo-hostname 뒤 경로는 annotation으로 전달 
                                    backend:
                                            serviceName: hostname-service
                                            servicePort: 80

 

/chapter8/$ kubectl delete -f ./ # 경로상의 리소스 정리

 

 

퍼시스턴트볼륨 PV

 

특정노드에 볼륨이 마운트 되어 있으면 파드가 옮겨갈경우 이전 데이터를 못찾는 상황이 나올테니 어느 노드에서도 접근가능한 persistent한 volume을 만든것이 PV

ex) NFS, AWS의 EBS(elastic block store), Ceph, GlusterFS 등 storage다 

 

1. 로컬볼륨: hostPath, emptyDir

  1) hostPath

   -  호스트와 볼륨 공유

   -  모든 노드에 볼륨을 배치해야 하는 특수한 포드에서는 유용. ex: 모니터링 툴

apply 이후에 워커노드에서 $ ls /tmp/mydata로 보면 폴더 생성됨

  2) emptyDir

   - 포드의 컨테이너간 볼륨 공유

   - 영속적인 볼륨 X , 포드가 실행중일때 휘발성 데이터를 컨테이너가 공유할 수 있도록 임시저장  

   - 한 컨테이너가 파일 관리하고 사용하는 경우 유용

 

/data 에 파일생성하면 아파치 웹서버에서 접근가능

2. 네트워크 볼륨

  1) NFS (Network File System)

    - 대부분의 운영체제에서 사용 가능, 여러개의 클라이언트가 동시에 마운트해 사용가능

    - 하나의 서버만으로 간편하게 사용, 로컬스토리지처럼 사용 가능

   nfs-deployment.yaml 과 nfs-service.yaml 작성하여 apply 한 뒤 

nfs-pod를 직접 작성. 

NFS_SERVICE_IP 부분때문에 바로 apply 하면 에러난다

error: error validating "nfs-pod.yaml": error validating data: ValidationError(Pod.spec.volumes[0].nfs.server): invalid type for io.k8s.api.core.v1.NFSVolumeSource.server: got "map", expected "string"; if you choose to ignore these errors, turn validation off with --validate=false

string이 들어와야하는데 맵이왔다, 애런말인데 {}로 감싸서 나는 말이고, IP를 세팅해주면 되는데..

$ kubectl get svc 해서 앞에서 생성한 nfs-service의 CLUSTER_IP를 메모해서 nfs-pod 에 적용해주자

$ kubectl exec -it nfs-pod sh / # df -h 의 결과, 클러스터IP인데 그냥 지워봄

파일시스템명은 앞서 적은 CLUSTER_IP가 되고 Size가 엄청 크게 잡혀있는게 보이는데, 

NFS는 그 저장소의 최대치까지로 세팅이 되기 때문이라고 한다.

 

 

PV, PVC

디플로이먼트에 볼륨을 명시하면서 어플리케이션과 밀접하게 연관이 되면, 서로 분리할 수 없는 상황이 발생 => 다른데 적용할때마다 문제가 된다.

PV는 포드를 생성하는 YAML 입장에서 볼륨의 종류가 무없인지 상관없이 볼륨을 사용할 수 있도록 하는 것

=> 상세 정보는 빼고 볼륨 클레임을 명시만 한다? interface 너낌으로 implements를 해서 사용한다는 것인듯

 

$ kubectl get pv,pvc (줄임말!)

 

1. PV와 PVC 사용하기

1) pv

- apiVersion: v1

- kind: PersistentVolume

- pv는 네임스페이스에 속하지 않는 클러스터 단위의 오브젝트 - 종속적이지 않다. namespaced=false란 말

$ kubectl api-resources --namespaced=false로 보면 persistentvolumes가 보인다. pvc는 true에서 보임

따라서 $ kubectl get pv 하면 모든 pv가 ns에 상관없이 조회됨

- spec.persistentVolumeReclaimPolicy (Reclaim Policy): pv 삭제하거나 했을때 볼륨 어떻게 할지.. Retain, Delete, Recycle. Retain이 보존이고Recycle은 PV나 스토리지는 남기고 데이터만 삭제하는 정책이다. $ kubectl get pv 하면 조회된다.

 

2) pvc 

- apiVersion: v1

- kind: PersistentVolumeClaim

- pvc에서 요청하는 조건(spec.accessModes, spec.resources.requests.storage)에 맞는 PV와 연결함 or spec.selector.matchLabels로 특정 pv와 연결 가능

- spec.accessModes

   a. ReadWriteOnce (RWO) - 1:1 마운트, 읽기/쓰기

   b. ReadOnlyMany (ROX) - 1:N 마운트, 읽기전용

   c. ReadWriteMany (RWX) - 1:N 마운트, 읽기/쓰기 --> NFS는 여러클라이언트가 동시 마운트 되니 RWX가 적합

 

 

책에서는 AWS의 EBS를 퍼시스턴트 볼륨으로 사용하는데 나는 보안정책상 이렇게 사용할 일이 당장 없을거라 생각이 들어서 NFS로 해보기로함. 구글링 시작

 

 

 

다이나믹 프로비저닝과 스토리지클래스 Dynamic Provisioning & StorageClass(SC)

 

다이나믹 프로비저닝은 PVC가 요구하는 PV가 없으면 자동으로 PV와 외부스토리지를 함께 프로비저닝하는 기능!

외부 스토리지를 미리 생성할 필요가 없다.  스토리지 클래스에 privisioner, parameter, reclaimPolicy가 포함되며 이는 다이나믹 프로비저닝에 사용. 

 

https://kubernetes.io/ko/docs/concepts/storage/storage-classes/ 

스토리지 클래스

전제조건은 다이나믹 프로비저너가 미리 활성화 되있어야한다는것? provisioner 를 반드시 명시하라는 말인듯하다.(위링크 참조)

 

pv는 물리디스크를 클러스터상에서 사용할 수 있게 필요한 만큼 정의한것이고, PVC는 pod랑 PV를 연결하는 관계가 되는데 pvc에서 요구하는 사항과 정확하게 일치하는 pv를 매칭을 시켜야하는 불편함 또는 더 작은 스토리지를 정의했지만 적합한 pv가 없을경우 더 큰 pv가 매칭되는 상황이 나올수 있다. 그래서 storageClass로 다이나믹프로비저닝을 하면 필요한 만큼 자동 생성해서 매칭해주니 훌륭한것