[Kubernetes] 쿠버네티스 오브젝트

3.4 알아두면 쓸모 있는 쿠버네티스 오브젝트

• 오브젝트에는 데몬셋, 컨피그맵, PV, PVC, 스테이트풀셋 등 이 있다.

3.4.1 데몬셋

• 데몬셋은 디플로이먼트의 replicas가 노드 수만큼 정해져 있는 형태라고 할 수 있으며, 노드 하나당 파드 한 개만을 생성한다.
• 노드를 관리하는 파드라면 데몬셋으로 만드는 게 가장 효율적이다.
• 데몬셋을 만드는 예제를 보며 작동 원리를 확인해 보자.

  # 현재 MetalLB의 스피커가 각 노드에 분포돼 있는 상태를 확인한다.
  kubectl get pods -n metallb-system -o wide
  

  # 워커 노드를 추가 후 -w 옵션을 추가하여 실시간으로 오브젝트 상태 변화를 감지한다.
  kubectl get pods -n metallb-system -o wide -w
  

  # 자동으로 추가된 노드에 설치된 스피커가 데몬셋이 맞는지 확인.
  kubectl get pods [생성 된 스피커 이름] -o yaml -n metallb-system
  

3.4.2 컨피그맵

• 컨피그맵은 설정을 목적으로 하는 오브젝트이다.
• 컨피그맵으로 작성 된 MetalLB의 IP 설정을 변경해 보자.

  #테스트용 디플로이먼트를 cfgmap 이라는 이름으로 생성.
  kubectl create deployment cfgmap --image=sysnet4admin/echo-hname
  

  #cfgmap을 로드밸런서를 통해 노출하고 이름은 cfgmap-svc 로 지정
  kubectl expose deployment cfgmap --type=LoadBalancer --name=cfgmap-svc --port=80
  

  # 생성된 서비스 IP 확인
  kubectl get services
  

  # sed 명령을 사용항려 기존 IP를 변경 (11 -> 21, 13 -> 23)
  sed -i 's/11/21;s/13/23/' ~/config.yaml
  

  #apply를 실행하여 변경된 설정을 적용
  kubectl apply -f ~/config.yaml
  

  # MetalLB와 관련된 모든 파드를 삭제하면 이후에 kubelet에서 해당 파드를 자동으로 모두 다시 생성한다. -all 옵션을 통해 한번에 모두 삭제 할 수 있다.
  kubectl delete pods --all -n metallb-system
  

  # 새롭게 생성 된 MetalLB의 파드들을 확인
  kubectl get pods -n metallb-system
  

  # 기존에 삭제한 서비스를 동일한 이름으로 다시 생성하여 새로운 컨피그맵을 적용한 서비스가 올라오게 한다.
  kubectl delete service cfgmap-svc
  kubectl exposd deployment cfgmap --type=LoadBalancer --name=cfgmap-svc --port=80
  

  # 새로 올라온 서비스의 IP가 바뀌었는지 확인.
  kubectl get services
  

3.4.3 PV와 PVC

• 쿠버네티스는 다음과 같은 목적으로 다양한 형태의 볼륨을 제공한다.

구분	볼륨
임시	emptyDir
로컬	host Path, local
원격	persistentVolumeClaim, cephfs, cinder, csi, fibre channel, flexVolume, flocker, glusterfs, iscsi, nfs, portworkxVolume, quobyte, rbd, scaleIO, storageos, vsphereVolume
특수 목적	downwardAPI, configMap, secret, azureFile, projected
클라우드	awsElasticBlockStore, azureDisk, gcePersistentDisk

• PV는 볼륨을 사용할 수 있게 준비하는 단계이고, PVC는 준비된 볼륨에서 일정 공간을 할당받는 것이다. 비유하면 PV는 요리사가 피자를 굽는 것이고, PVC는 손님이 원하는 만큼의 피자를 접시에 담아 가져오는 것이다.

NFS 볼륨에 PV/PVC를 만들고 파드에 연결하기

# 공유할 디렉토리를 생성하고 NFS로 받아들일 IP 영역을 정한다.
mkdir /nfs_shared
echo '/nfs_shared 192.168.1.0/24(rw,sync,no_root_squash)' >> /etc/exports

# NFS 서버를 활성화하고 다음에 시작할때 자동으로 적용 되도록 한다.
systemctl enable --now nfs

# 오브젝트 스펙을 실행하여 PV를 생성
kubectl apply -f ~/nfs-pv.yaml

nfs-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 100Mi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 192.168.1.10
    path: /nfs_shared

# PV의 상태가 Available(사용가능)임을 확인
kubectl get pv

# 오브젝트 스펙을 실행하여 PVC를 생성
kubectl apply -f ~/nfs-pvc.yaml

nfs-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Mi

# 생성한 PVC를 볼륨으로 사용하는 디플로이먼트 오브젝트 스펙을 배포
kubectl apply -f ~/nfs-pvc-deploy.yaml

nfs-pvc-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-pvc-deploy
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nfs-pvc-deploy
    template:
      metadata:
        labels:
          app: nfs-pvc-deploy
    template:
      metadata:
        labels:
          app: nfs-pvc-deploy
      spec:
        containers:
        - name: audit-trail
          image: sysnet4admin/audit-trail
          volumeMounts:
          - name: nfs-vol
            mountPath: /audit
        volumes:
        - name: nfs-vol
          persistentVolumeClaim:
            claimName: nfs-pvc

# 생성된 파드를 확인 후 생성한 파드 중 하나에 exec로 접속
kubectl get pods
kubectl exec -it nfs-pvc-deploy-788b77964-69c8n -- /bin/bash

# 외부에서 파드에 접속할 수 있도록 expose로 로드밸런서 서비스를 생성
kubectl expose deployment nfs-pvc-deploy --type=LoadBalancer --name=nfs-pvc-deploy-svc --port=80

# 다른 파드 1개를 추가로 exec로 접속
kubectl exec -it nfs-pvc-deploy-7888b77964-c66nrp -- /bin/bash

• 이전에 접속한 파드에서 ls /audit 명령어를 통해 audit 로그를 확인하고, 다른 파드에서도 동일하게 ls /audit 명령어를 치고 동일한 로그파일인지 확인.

NFS 볼륨을 파드에 직접 마운트하기

• 사용자와 관리자가 동일한 단일 시스템이라면 PV와 PVC를 사용할 필요가 없다. 따라서 볼륨을 마운트 해보자.

  kubectl apply -f ~/nfs-ip.yaml
  

  nfs-ip.yaml

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  name: nfs-ip
  spec:
  replicas: 4
  selector:
    matchLabels:
      app: nfs-ip
  template:
    metadata:
      labels:
        app: nfs-ip
    spec:
      containers:
      - name: audit-trail
        image: sysnet4admin/audit-trail
        volumeMounts:
        - name: nfs-vol
          mountPath: /audit
      volumes:
      - name: nfs-vol
        nfs:
          server: 192.168.1.10
          path: /nfs_shared
  

  # 새로 배포된 파드를 확인하고 그중 하나를 exec 로 접속한다.
  kubectl get pods
  kubectl exec -it nfs-ip-84fd4d6f69-475vb --v /bin/bash
  

• 동일하게 양쪽에서 ls /audit 를 실행해 동일한 NFS 볼륨을 바라보고 있는지 확인.

3.4.4 스테이트풀셋

• 파드가 만들어지는 이름과 순서를 예측해야 할 때가 있다. 주로 레디스, 주키퍼, 카산드라, 몽고DB 등의 마스터-슬레이브 구조 시스템에서 필요하다. 이때 스테이트풀셋을 사용한다.
• 스테이트풀셋은 volumeClaimTemplates 기능을 사용해 PVC를 자동으로 생성한다.
• 각 파드가 순서대로 생성되기 때문에 고정된 이름, 볼륨, 설정 등을 가질 수 있다.

  # 스테이트풀셋을 다음 명령어로 생성
  kubectl apply -f ~/nfs-pvc-sts.yaml
  

  nfs-pvc-sts.yaml

  apiVersion: apps/1
  kind: StatefulSet
  metadata:
  name: nfs-pvc-sts
  spec:
  replicas: 4
  serviceName: sts-svc-domain
  selector:
    matchLabels:
      app: nfs-pvc-sts
    template:
      metadata:
        labels:
          app: nfs-pvc-sts
      spec:
        containers:
        - name: audit-trail
          image: sytsnet4admin/audit-trail
          volumeMounts:
          - name: nfs-vol
            mountPath: /audit
        volumes:
        - name: nfs-vol
          persistentVolumeClaim:
            claimName: nfs-pvc
  

  # 파드가 정상적으로 생성 되는지 확인
  kubectl get pods -w
  

• expose 명령으로는 스테이트풀셋 을 실행할 수 없다. expose 명령으로 서비스를 생성할수 있는 오브젝트는 디플로이먼트, 파드, 레플리카셋, 레플리케이션 컨트롤러 이다.

# 스테이트풀셋을 노출하기 위한 서비스를 생성, 생성한 로드밸런서 서비스를 확dls.
kubectl apply -f ~/nfs-pvc-sts-svc.yaml
kubectl get services

nfs-pvc-sts-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: nfs-pvc-sts-svc
spec:
  selector:
    app: nfs-pvc-sts
  ports:
    - port: 80
  type: LoadBalancer