티스토리 뷰

1탄!! 쿠버네티스 구성준비! [마스터노드] [WORKER NODE] 셋팅하기   

2탄!! 쿠버네티스와 컨테이너를 쉽게 이해하기

3탄!! Kubernetes 구성도 알아보자!

4탄!! NFS 설정입니다.

5탄!! helm install 방법

6탄 !! 도커 컴포즈 VS 쿠버네티스 컴포즈

7탄!! 쿠버네티스에 pod 올리자! pod? 뭐에요?

부록!! 쿠버네티스 장애 처리5탄부록!! 쿠버네티스 장애 처리

8탄!! K8S 대시보드 설치

9탄!! 쿠버네티스 오토스케일링(kubernetes autoscaling)

10탄!! K8S Namespace 생성방법

11탄!! 쿠버네티스 용어 정리

12탄!! 도커 깔끔히 삭제하기

 

#기타 참고하기  

마이크로 쿠버네티스 설치 해보기

쿠버네티스(컨테이너) 환경 구축의 어려운점~!

쿠버네티스(튜토리얼 실습)

쿠버네티스 초기설치및  볼트 디비 올리기[샘플]

헬름챠트로 올리기[샘플]11) 쿠버네티스 가상스토리지(Ceph) 설치

 

 

 

1. Master node 에서 NFS Server install 인스톨 합니다.

[Master node NFS Server install 설치]

$yum install nfs-utils nfs-utils-lib -y
$systemctl enable nfs-server.service
$systemctl start nfs-server.service

 

2. NFS mount 허용할 디렉터리 생성 및 권한부여

  • 권한 부여 확인!
[마스터 서버]
$mkdir /srv/nfs/kubedata -p
$chown nobody: /srv/nfs/kubedata

3. NFS Server의 마운트디렉토리에 대한 설정

[마스터 서버]
$vi /etc/exports
/srv/nfs/kubedata *(rw,sync,no_subtree_check,no_root_squash,no_all_squash,insecure)
exportfs -rav
exportfs -v

rw                      -> 읽기 쓰기 권한 부여 한다.
sync                    -> 동기화한다.
root_squash             -> 클라이언트에서 root를 서버상의 nobody 계정으로 매핑한다.
all_squash              -> root 계정이 아닌 다른 계정도 사용 할  수 있게한다.
no_root_squash          -> 클라이언트 및 서버 모두 root 계정 사용한다.


누구나 쓰기 가능 

예제!!
[서버]
#>vi /etc/export
/nfs    192.168.100.* (rw,all_squash,sync)
#>systemctl restart nfs
#>chmod o+w /nfs

 

4. worker node NFS client install

[ 클라이언트 설치]
$yum install nfs-utils nfs-utils-lib -y 
$systemctl enable nfs-client.target
$systemctl start nfs-client.target

 

5. worker node에서 master node로 NFS 정상적으로 연결되는지 확인

  • 특정 worker node에 pod 랜덤으로 생성됨
  • 전체의 worker node에서 NFS로 master node와 접근이 가능해야됨
[워크 노드]
mount -t nfs 192.168.56.150:/srv/nfs/kubedata /tmp

예제!!
[클라이언트]
#>mount -t nfs 192.168100.151:/nfs /nfs
#>touch /nfs/client.txt

 

[VoltDB 테스트를 위한..Master node ]

 

Statefulset 환경을 NFS로 설정하기 위한 yaml 파일 다운로드

yum install wget
$yum install wget
$wget https://raw.githubusercontent.com/sangkyu-test/voltdb/master/rbac.yaml
$wget https://raw.githubusercontent.com/sangkyu-test/voltdb/master/class.yaml
$wget https://raw.githubusercontent.com/sangkyu-test/voltdb/master/deployment.yaml
$wget https://raw.githubusercontent.com/sangkyu-test/voltdb/master/pvc-nfs.yaml
$wget https://raw.githubusercontent.com/sangkyu-test/voltdb/master/4-busybox-pv-hostpath.yaml

1. rbas 는 
2. class.yaml은 storageClassName을 지정합니다.
3. deployment.yaml은 nfs-server의 IP를 지정해주고 마운트위치를 지정
4. pvc-nfs.yaml 은 storageClass를 지정해서 pvc를 생성해 할당요청을 하면 자동으로 pv할당
5. 4-busybox-pv-hostpath.yaml은 위에서 생성한 PersistentVolumeClaim을 이용해 pod를 
   생성하면 생성되어 있는 pv,pvc를 기준으로 올라간다.


$kubectl create -f rbac.yaml
$kubectl create -f class.yaml
$kubectl create -f deployment.yaml
$kubectl create -f pvc-nfs.yaml
$kubectl create -f 4-busybox-pv-hostpath.yaml

pod를 yaml 파일로 올릴 때  pvc에 지정한 storageClassName으로 할당을 자동으로 할 수 있다.
나중에 worker node를 추가할려면 해당 토큰이 24시간밖에 유효하지 않기 때문에 재 생성해서 노드를 추가해줘야 한다.
마스터에서 kubeadm token create --print-join-command
$kubeadm token create --print-join-command
kubeadm join 192.168.56.150:6443 --token db0xur.z2wmw9g3qfxg6fdg     --discovery-token-ca-cert-hash sha256:f5b21bb40ced8d371ad3d2d4cefdf289033c5f4836d2f03fe9567f11f1a14faa


************

퍼시스턴트볼륨(PersistentVolume) 템플릿

퍼시스턴트 볼륨 템플릿은 다음과 같은 구조입니다.

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv-hostpath

spec:

  capacity:

    storage: 2Gi

  volumeMode: Filesystem

  accessModes:

    - ReadWriteOnce

  storageClassName: manual

  persistentVolumeReclaimPolicy: Delete

  hostPath:

    path: /tmp/k8s-pv

 

1. apiVersion, kind, metadata부분은 다른 것들과 비슷한 구조

2. spec의 capacity부분을 보면 storage용량으로 1기가를 설정

3. 현재는 용량 관련한 설정만 가능하지만 앞으로는 IOPS나 throughput등도 설정할 수 있도록 추가될 예정

4. volumeMode는 쿠버네티스 1.9버전에 알파 기능으로 추가된 옵션입니다.

5. 기본값은 filesystem으로 볼륨을 파일시스템형식으로 붙여서 사용

6. 추가로 설정가능한 옵션은 raw입니다.

7. 볼륨을 로우블록디바이스형식으로 붙여서 사용

8. 로우블록디바이스를 지원하는 플러그인들은 AWSElasticBlockStore, AzureDisk, FC (Fibre Channel),    GCEPersistentDisk, iSCSI, Local volume, RBD (Ceph Block Device) 등

9. accessModes는 볼륨의 읽기/쓰기에 관한 옵션을 지정

10. 볼륨은 한번에 하나의 accessModes만 설정할 수 있고, 다음 3가지중 하나를 지정

 

  • ReadWriteOnce : 하나의 노드가 볼륨을 읽기/쓰기 가능하게 마운트할 수 있음.

  • ReadOnlyMany : 여러개의 노드가 읽기 전용으로 마운트할 수 있음.

  • ReadWriteMany : 여러개의 노드가 읽기/쓰기 가능할게 마운트할 수 있음.

볼륨 플러그인 별로 지원가능한 옵션은 다음과 같습니다.

 

 

1. persistentVolumeReclaimPolicy 에는 PV가 해제되었을때의 초기화옵션

2. Retain, Recycle, Delete중 하나가 올 수 있습니다.

3. mountOptions이라는 옵션

   - 볼륨을 마운트할때 추가적인 옵션을 설정할 수 있는 스토리지들에서 사용

   - 마운트 옵션을 사용할 수 있는 스토리지에는 GCEPersistentDisk, AWSElasticBlockStore, AzureFile, AzureDisk, NFS,         iSCSI, RBD (Ceph Block Device), CephFS, Cinder (OpenStack block storage), Glusterfs, VsphereVolume, Quobyte         Volumes등이 있습니다. 마운트 옵션이 잘못되어 있으면 마운트 실패

 

4.  hostPath는 이 PV가 hostPath타입이라는걸 명시

    - 하위에 마운트 시킬 호스트의 경로를 path를 이용해서 지정

5. pv-hostpath.yaml 파일로 저장하고 적용

6. pv의 상태를 확인해보면 다음처럼 Available 상태로 나오는걸 확인할 수 있습니다.

$ kubectl apply -f pv-hostpath.yaml

persistentvolume "pv-hostpath" created

$ kubectl get pv

NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE

pv-hostpath   2Gi        RWO            Delete           Available             manual                   7s

 

pv의 상태는 Available을 포함해서 다음 4가지

 

1. Available : PVC에서 사용할 수 있게 준비된 상태

2. Bound : 특정 PVC에 연결된 상태


3. Released : PVC는 삭제된 상태이고 PV는 아직 초기화되지 않은 상태

 

4. Failed : 자동 초기화가 실패한 상태

퍼시스턴트볼륨클레임(PersistentVolumeClaims) 템플릿

PVC의 간단한 예제는 다음 템플릿 내용으로 확인할 수 있습니다. 

 

pvc-hostpath.yaml

kind: PersistentVolumeClaim

apiVersion: v1

metadata:

  name: pvc-hostpath

spec:

  accessModes:

    - ReadWriteOnce

  volumeMode: Filesystem

  resources:

    requests:

      storage: 1Gi

  storageClassName: manual

 

이 내용을 pvc-hostpath.yaml로 저장하고 적용합니다. 그럼 다음처럼 앞에서 만들었던 PV와 연결된걸 확인할 수 있습니다. PV정보를 조회해보면 이제 PVC에 연결되어서 상태가 Bound로 나오는걸 확인할 수 있습니다.

$ kubectl apply -f pvc-hostpath.yaml

persistentvolumeclaim "pvc-hostpath" created

$ kubectl get pvc

NAME           STATUS    VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE

pvc-hostpath   Bound     pv-hostpath   2Gi        RWO            manual         3s

$ kubectl get pv

NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                  STORAGECLASS   REASON    AGE

pv-hostpath   2Gi        RWO            Delete           Bound     default/pvc-hostpath   manual                   11m

 

1. PVC의 설정

2. spec 하위 내용

3. accessModes에는 PV와 마찬가지로 어떤 읽기/쓰기 모드로 연결할지를 지정

4. ReadWriteOnce, ReadOnlyMany, ReadWriteMany 등

5. volumeMode도 PV와 동일한 옵션

6. 파일시스템인지 블록 디바이스인지를 filesystem, raw등을 통해 설정

7. resources는 얼만큼의 자원을 사용할 것인지에 대한 요청(request)

8. 1기가를 요청

9. 앞에서 만들어둔 PV의 용량이 2기가 였기 때문에 현재 PVC에서 사용

10. 만약에 PVC가 requests의 storage에 2기가 이상의 용량을 입력

11. PV가 없어서 PVC는 Pending상태로 남게 되고 생성이 안됨

12. storageClassName에는 사용할 스토리지클래스를 명시

 

레이블을 이용해서 pvc, pv 연결하기

pv는 쿠버네티스 내부에서 사용되는 자원이고 pvc는 그 자원에 대한 요청을 하는 것이기 때문에 포드와 서비스를 연결할 때 처럼 레이블을 사용할 수 있습니다. 앞에서 사용했던 pv와 pvc에 다음처럼 label관련 설정을 추가하면 됩니다. 

 

pv-hostpath-label.yaml

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv-hostpath-label

  labels:

    location: local

spec:

  capacity:

    storage: 2Gi

  volumeMode: Filesystem

  accessModes:

    - ReadWriteOnce

  storageClassName: manual

  persistentVolumeReclaimPolicy: Delete

  hostPath:

    path: /tmp/k8s-pv

 

pvc-hostpath-label.yaml

kind: PersistentVolumeClaim

apiVersion: v1

metadata:

  name: pvc-hostpath-label

spec:

  accessModes:

    - ReadWriteOnce

  volumeMode: Filesystem

  resources:

    requests:

      storage: 1Gi

  storageClassName: manual

  selector:

    matchLabels:

      location: local

 

pv에는 metadata부분에 레이블을 추가했고, pvc에는 spec하위에 selector를 둬서 거기서 matchLabels를 통해서 앞의 pv에서 사용했던 레이블인 location: local을 지정했습니다. pvc에서는 matchLabels뿐만 아니라 다음처럼 matchExpressions를 통해서 원하는 레이블 조건을 명시할 수도 있습니다. 

spec:    

  selector: 

    matchExpressions:

      - {key: stage, operator: In, values: [development]}

 

pod 에서 PVC를 볼륨으로 사용하기

마지막으로 이렇게 만들어진 PVC를 실제 포드에 붙여 보도록 하겠습니다. 

다음내용으로 deployment-pvc.yaml 파일을 만들어서 적용합니다.

apiVersion: apps/v1

kind: Deployment

metadata:

  name: kubernetes-simple-app

  labels:

    app: kubernetes-simple-app

spec:

  replicas: 1

  selector:

    matchLabels:

      app: kubernetes-simple-app

  template:

    metadata:

      labels:

        app: kubernetes-simple-app

    spec:

      containers:

      - name: kubernetes-simple-app

        image: arisu1000/simple-container-app:latest

        ports:

        - containerPort: 8080

        imagePullPolicy: Always

        volumeMounts:

        - mountPath: "/tmp"

          name: myvolume

      volumes:

      - name: myvolume

        persistentVolumeClaim:

          claimName: pvc-hostpath

 

1. spec.template.spec 부분에 볼륨관련한 설정

2. volumes라고해서 사용할 볼륨을 myvolume이라는 이름으로 선언

3. myvolume을 persistentVolumeClaim으로 선언 사용할 pvc의 이름은 앞에서 만들었던 pvc-hostpath로 지정

4. 디플로이먼트의 포드에서 사용할 myvolume라는 볼륨이 준비

5. 실제 컨테이너에 연결하는건 spec.template.spec.containers 하위의 컨테이너 설정에 있는 volumeMounts 설정

6. mountPath라는 옵션으로 컨테이너의 “/tmp” 디렉토리에 앞서 생성했던 myvolume 을 마운트하도록 설정

7. simple-container-app은 /tmp 디렉토리에 app.log라는 이름으로 접속로그

8. 포드 이름을 확인한 다음에 아래 명령으로 포드에 접근 가능한 포트를 설정한 다음에 브라우저에서 localhost:8080으로 몇 번 접속

 

kubectl port-forward pods/kubernetes-simple-app-6d7d997c7c-lnwkz 8080:8080

앞에서 우리는 PV를 /tmp/k8s-pv라는 경로에 만들어 지도록 설정했었습니다. 지금까지의 설정에 따르면 로컬머신 내부경로의 /tmp/k8s-pv가 컨테이너의 /tmp 경로에 마운트되어 있을 겁니다. 그래서 kubernetes-simple-app 디플로이먼트의 접속로그인 app.log가 컨테이너의 /tmp/app.log에 남게되고 그 로그의 내용을 다음처럼 로컬머신의 내부경로인 /tmp/k8s-pv/app.log에서 확인할 수 있게 됩니다.

$ cat /tmp/k8s-pv/app.log

[GIN] 2018/08/19 - 07:32:17 | 200 |       777.2µs |       127.0.0.1 | GET      /

[GIN] 2018/08/19 - 07:32:19 | 200 |       241.2µs |       127.0.0.1 | GET      /

[GIN] 2018/08/19 - 07:32:19 | 200 |       138.9µs |       127.0.0.1 | GET      /

 

PVC 크기 늘리기

 

1. 한번 할당한 PVC의 크기를 늘리는 것도 가능

2. gcePersistentDisk, awsElasticBlockStore, Cinder, glusterfs, rbd, Azure File, Azure Disk, Portworx

3. 볼륨 타입을 사용하면 가능

4. 기능을 사용하려면 스토리지클래스에 allowVolumeExpansion 옵션이 true로 설정

5. 기존에 있는 PVC에 있는 스토리지 사이즈를 늘리고 적용

6. 볼륨에서 사용중인 파일시스템이  XFS, Ext3, Ext4인 경우에는 파일시스템이 볼륨의 크기를 늘리는 것이 가능

7. 파일시스템이 있는 볼륨의 크기를 늘리는 작업은 그 PVC를 사용하는 새로운 포드가 실행됐을때만 진행

8. 기존에 특정 포드가 사용중인 볼륨의 크기를 늘리려면 포드를 재시작

9. 사용중인 포드를 재시작하는건 아무래도 서비스 운영에 불편

10. 쿠버네티스 버전 1.11에서는 사용중인 볼륨의 사이즈를 조절하는 기능이 알파 버전으로 도입

 

 

노드별 볼륨 개수 제한

쿠버네티스에서는 하나의 노드에 붙일 수 있는 볼륨 개수에 제한을 두고 있습니다. 스케쥴러에 KUBE_MAX_PD_VOLS 환경변수를 이용해서 설정해 줄 수 있습니다. 클라우드 서비스를 이용하는 경우에는 각 클라우드별로 다음과 같은 제한사항을 가지고 있습니다.

클라우드 서비스

노드당 최대 볼륨개수

Amazon Elastic Block Store (EBS)

39

Google Persistent Disk

16

Microsoft Azure Disk Storage

16



 

댓글