Kubernetes 5일차 인그레스, 스토리지(rook-ceph설치), 정적볼륨프로비저닝, 동적볼륨프로비저닝,

* 인그레스

inbound - ingress

인그레스 리소스가 작동하려면 인그레스 컨트롤러가 필요하다.

Nginx 인그레스 컨트롤러를 설치한다.

https://kubernetes.github.io/ingress-nginx/deploy/ <설치 링크>

우리 환경은 onpremise의 bare metal 이다.

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

위의 명령을 사용하여 k-control에 설치하여준다. 

 

external ip 로 노드의 ip를 지정해준다.

kubectl edit svc -n ingress-nginx ingress-nginx-controller

<spec 부분의 아무곳에 저장> node1,node2 의 vm의 ip 주소

 

서비스를 노출시키는 방법이다. HTTP 요청의 주소를 구분해 하나의 인그레스 리소스를 활용해 각 서비스에 라우팅 하는 기능을 한다.

외부의 myapp.example.com FQDN 주소로 리소스에 접속하면 myapp-svc-np 서비스에 라우팅한다. myapp-svc-np 서비스는 레이블 셀렉터에 매핑된 파드로 라우팅 해준다. 

*스토리지

1) emptydir

임시 데이터를 저장하는 빈 볼륨

kubectl exec myapp-rs-fortune-2kv7c -c webserver -- cat /usr/share/nginx/html/index.html 

하면 나오는 오류

[오류] error: unable to upgrade connection: pod does not exist

오류 해결 == internal ip를 nat용으로 되어있는 것을 vm의 ip로 재설정해준다.

 

echo "KUBELET_EXTRA_ARGS='--node-ip 192.168.200.51'" | sudo tee /etc/default/kubelet

sudo systemctl daemon-reload

sudo systemctl restart kubelet

 

동일한 파드 내의 컨테이너 간에 데이터를 공유할 때 유용하게 사용한다.

 

비어있는 디렉토리를 공유하기때문에 contents를 생성하는 컨테이너와 외부에 제공해주는 컨테이너가 필요하다. 

2) gitRepo

지정한 레포지토지를 채우는 볼륨

초기화 작업시에 InitContainers 사용한다.

156~159 다시 해보기

 

3) hostPath

도커에서의 볼륨과 비슷한 개념, 노드의 파일 시스템을 제공

미리 데이터를 채워서 제공하는 것이 가능하다.

파드와 파드간에 공유는 X, 컨테이너 내의 파드끼리는 공유 O

같은 노드에 배치된 파드 및 컨테이너에게 공유 디렉토리를 제공가능

다른 노드에 배치된 파드 및 컨테이너에는 데이터를 공유할 수 없다. 

 

yaml 파일 작성 전 k-node1 으로 접속하여 /web_contents 밑에 파일을 작성해준다.

 

yaml 파일은 위와같이 작성가능

현재 나의 환경에서는 control을 제외한 노드가 k-node1으로 하나이다. 

따라서 노드를 지정해주지는 않았는데 

spec:에 nodeName: k-node1 이런식으로 지정가능하다(containers 위에 자리함)

hostpath 이기 때문에 container는 node1 에 생성된 후 내부의 디렉토리를 마운트하여 사용한다. 

.volumes.hostPath.type: 볼륨 종류 지정

Directory, File, Socket 등이 있다.

4) 네트워크 스토리지 볼륨

네트워크 기반 스토리지, 일반적으로 사용, NFS 같은 것

 

5) 클라우드 스토리지 볼륨

AWS EBS ..

 

6) 정적/동적 프로비저닝 볼륨

persistentVolume 및 persistentVolumeClaim 볼륨 

PVC는 파드와 PV를 연결하기 위한 리소스이다. 

관리자는 PV를 만들어 스토리지와 연결해두고, 파드 개발자는 PV를 생성해 PV와 연결하여 파드상에서 볼륨을 사용할 수 있게한다.

1)프로비저닝

PV가 만들어지는 단계

PV 직접생성 ⇒ 정적 프로비저닝, 

PV 자동생성 ⇒ 동적 프로비저닝,

 

2) 바인딩

PVC를 만들어서 PV와 연결 (1ㄷ1로만 연결가능)

 

3) 사용

PVC에서 제공한 볼륨을 파드가 마운트하여 사용하고 있는 단계 

파드가 사용중인 PVC및 PVC가 사용중인 PV는 임의로 삭제되지 않는다.

 

4) 회수

PVC가 종료/삭제되면 PV를 회수한다.

유지 삭제 재활용의 회수정책이 있다. 

*유지 회수정책

데이터는 그대로 남아있지만, 그것을 다시 사용할 수는 없다.

 

PV삭제->스토리지에서 삭제->다시 사용할것이라면 유지시켜둔 데이터를 통해 PV를 새로 만들어서 사용해야한다

 

*삭제 회수정책

PVC 리소스를 삭제

PV, 스토리지 모두 삭제된다.

 

*재활용 정책

NFS와 hostPath만 지원

PVC가 삭제되고 모두 삭제되고 다시 PV를 생성됨 

이제는 안씀

 

(1) 정적 볼륨 프로비저닝

NFS가 pod에 직접 마운트되어 사용되는 것이 아니라, NFS 구성이 호스트(노드)에 연결되고

노드가 파드로의 연결을 해주는 것이다. 

 

***PV리소스에서 정의할 주요 필드

spec.capacity.storage 용량지정

 

spec.accessMode 접근방식 관련 옵션

스토리지에 따라 지원되는 옵션이 다르다. 

ReadWriteOnce: 하나의 파드만 일기/쓰기가능

ReadWriteMany: 여러파드 읽기/쓰기 가능

ReadOnlyMany: 여러파드 읽기만 가능

 

spec.persistentVolumeReclaimPolicy 회수정책

Retain, Delete, Recycle

 

***PVC 리소스 정의

accessModes 가 PV의 필드와 같아야한다.

 

PVC와 연결할 레플리카셋 yaml 도 작성한다.

 

**정적프로비저닝

파드가 pvc와 연결 pvc가 pv의 볼륨과 연결 pv가 실제 스토리지와 연동

170~179 실습 다시해보기

아마 myapp-svc-fortune이나 hp가 올라와있기 때문에 port가 거부당한듯..

지우고 또 해보기

 

PV가 availabel 상태에서만 PVC 연결가능하다 

(2) 동적 볼륨 프로비저닝

*StorageClass

PV를 어떻게 만들어야하는지 설명이 들어있는 파일 

https://rook.io/

rook.io 애드온을 사용한다.

storage는 Ceph 스토리지 사용한다.

block storage 는 공유의 개념이 아니다. file storage는 공유의 개념

 

*Rook-ceph 설치

[ceph cluster]

 

git clone --single-branch --branch v1.6.7 https://github.com/rook/rook.git

 

cd rook/cluster/examples/kubernetes/ceph

 

kubectl create -f crds.yaml -f common.yaml -f operator.yaml

 

kubectl create -f cluster.yaml (3 worker)

또는

kubectl create -f cluster-test.yaml (1 worker)

 

kubectl delete -f crds.yaml -f common.yaml -f operator.yaml

kubectl delete -f cluster-test.yaml 

 

[block] https://rook.io/docs/rook/v1.6/ceph-block.html  블록 스토리지 설치 

 

kubectl create -f csi/rbd/storageclass.yaml

[file] https://rook.io/docs/rook/v1.6/ceph-filesystem.html 파일 스토리지 설치 

 

kubectl create -f filesystem.yaml (3 worker)

또는

kubectl create -f filesystem-test.yaml (1 worker)

kubectl create -f csi/cephfs/storageclass.yaml

kubectl delete -f filesystem-test.yaml

 

kubectl delete -f csi/cephfs/storageclass.yaml

*ceph 스토리지가 설치되었는지 알아보는 방법

<toolbox.yaml>

apiVersion: apps/v1

kind: Deployment

metadata:

  name: rook-ceph-tools

  namespace: rook-ceph

  labels:

    app: rook-ceph-tools

spec:

  replicas: 1

  selector:

    matchLabels:

      app: rook-ceph-tools

  template:

    metadata:

      labels:

        app: rook-ceph-tools

    spec:

      dnsPolicy: ClusterFirstWithHostNet

      containers:

      - name: rook-ceph-tools

        image: rook/ceph:v1.6.7

        command: ["/tini"]

        args: ["-g", "--", "/usr/local/bin/toolbox.sh"]

        imagePullPolicy: IfNotPresent

        env:

          - name: ROOK_CEPH_USERNAME

            valueFrom:

              secretKeyRef:

                name: rook-ceph-mon

                key: ceph-username

          - name: ROOK_CEPH_SECRET

            valueFrom:

              secretKeyRef:

                name: rook-ceph-mon

                key: ceph-secret

        volumeMounts:

          - mountPath: /etc/ceph

            name: ceph-config

          - name: mon-endpoint-volume

            mountPath: /etc/rook

      volumes:

        - name: mon-endpoint-volume

          configMap:

            name: rook-ceph-mon-endpoints

            items:

            - key: data

              path: mon-endpoints

        - name: ceph-config

          emptyDir: {}

      tolerations:

        - key: "node.kubernetes.io/unreachable"

          operator: "Exists"

          effect: "NoExecute"

          tolerationSeconds: 5

 

kubectl create -f toolbox-job.yaml

 

kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

#bash로 들어가서 ceph status 치고

위와같은 상태 HEALTH_OK 를 확인한다면 ceph 설치완료 

 

kubectl -n rook-ceph delete deploy/rook-ceph-tools

#위의 명령어로 toolbox 관련 삭제