CKA준비 Persistent Volumes, Persistent Volume Claims, Storage Class, Switching Routing

Persistent Volumes?

• 사용자가 많은 넓은 환경에서 많은 포드를 배포할 경우 사용자는 각각의 포드에 따라 매번 저장소를 구성해야한다.
• 사용자는 해당 포드를 배포할 때 자신의 환경에 있는 모든 포드 정의 파일에 그걸 구성해야한다.
• 변경사항이 있을 때 마다 사용자는 모든 포드에서 수정 사항을 작성해야한다. -> 대신 저장소를 보다 중앙에서 관리하는 것이다.
• 관리자가 거대한 저장소 풀을 생성할 수 있도록 구성되어야 하고 사용자가 요구에 따라 일부를 나눠야 한다.
• 클러스터에 있는 응용프로그램을 배포하는 사용자가 사용한다.
• 사용자는 영구적인 Volume클레임(PVC)을 이용해 풀에서 저장소를 선택할 수 있다.
• 엑세스 볼륨은 호스트에 볼륨이 어떻게 마운트되어야 하는지 정의한다. -> 읽기 전용 모드 및 읽기,쓰기 모드 등

728x90

Persistent Volume Claims?

• Persistent Volume 과 Persistent Volume Claims 는 쿠버네티스 네임스페이스에 있는 두 개으 다른 개체이다.
• 관리자는 영구 볼륨 세트를 만들고 사용자는 저장소를 사용하기 위해 영구 볼륨 클레임을 만든다.
• 영구 볼륨 클레임이 생성되면 쿠버네티스가 클레임에 영구 볼륨을 묶는다.
• 모든 볼륨 클레임은 단일 볼륨으로 묶여있다. -> 바인딩 과정에서 쿠버네티스는 요구대로 충분한 용량을 확보하려 한다.
• 볼륨을 사용하고 싶다면 라벨과 선택기를 사용해 볼륨에 바인딩 할 수 있다.
• 다른 모든 기준이 일치하고 더 나은 선택지가 없다면 더 작은  pvc가 더 큰 pv로 바인딩 될 수 있다.
• 클레임과 볼륨은 1대1 관계로 다른 클레임이 남은 용량을 활용할 수 없다.
• 사용 가능한 볼륨이 없다면 pvc 는 보류 상태로 남는다. -> 클러스터에 새로운 볼륨이 사용가능해 질 때 까지
• k get persistentvolumeclaim -> pvc 의 상태를 확인 할 수 있다.
• k delete persistentvolumeclaim myclaim -> 클레임이 삭제

Storage Class?

• pv가 생성되기 전에 구글 클라우드에 디스크를 생성해야한다.
• 응용 프로그램이 저장소를 요구할 때마다 먼저 구글 클라우드에서 수동으로 디스크를 공급해야한다. 그런 다음 수동으로 영구 볼륨 정의 파일을 만들어야한다. 만든 디스크와 같은 이름을 사용해야한다. -> Static Provisioning volume
• 구글 저장소 같은 것으로 저장소 클래스 Provisioner를 정의할 수 있다. -> 요구사항이 있으면 포드에 연결 할 수 있다. -> dynamic provisioning Volume
• 저장소 클래스를 가지고 있으면 pvc 정의파일에 pv 정의를 할 필요가 없다. -> pv에 관련된 저장소는 저장소 클래스가 생성되면 자동으로 생성되기 때문이다. 
• pvc 정의파일에 이제 저장소 클래스 명을 적어줘야한다.
• gcp volume 을 생성하는데 GCE provisioner를 사용했다.

Switching Routing?

• 스위치의 역할은 두 시스템을 포함하는 네트워크를 만드는 것이다. -> 각 호스트에 인터페이스가 필요하다.
• 호스트 인터페이스를 보기 위해서는 ip link명령어를 사용한다. -> Eth0 (스위치를 연결하는 데 사용된다.) 를 확인할 수 있다.
• 게이트 웨이는 다른 인터넷으로 통하는 문이다.
• route 명령어로 현재 시스템상 라우팅을 알 수 있다.
• 라우터가 있어야만 다른 광역대에서도 통신이 가능하다.
• 지정되지 않은 식별자의 주소는 기본 라우터로 통하게 해서 접속하게 한다.
• 리눅스에서 패킷은 한 인터페이스에서 다음 인터페이스로 전달되지 않는다.

반응형