namespace
노드보다 큰 개념 클러스터다라고 얘기해도 별반 다르지 않다
storage volume이라는 저장공간을 pod에서 만들수 있고 node에서 만들수있고 클러스터에서 만들수있다
도커에서는 컨테이너에서 만들수있는데 그러지 않는다
빨간색 박스 3개 pod에 속해있다
pod안에 존재하는 스토리지 영역 = empty director
팟이 죽으면 사라진다
노드의 스토리지 볼륨 cache hostpath
pod이실행되곧있는host의 path
pod은 살다죽다 하는것
상시적인거 저장은 안되고
노드에 있는 스토리지 쓰는것도임시다
persistent volume claim항구적으로 존재하는 volume 저장공간
claim은 요구 pvc
claim이 있고 그냥 volume이 따로 있다
스토리지 타입 굉장히 다양하고 플러그인 추가함으로써 원하는 스토리지를 연결할수있다
nfs network file system
네트워크를 통해서저장공간을 접근해서 쓰는 시스템
스토리지는 별도로 아마존 등에서 제공하는걸 쓰고싶다면 public cloud provider가 제공하는 스토리지를 사용할수도 있다
쿠버네티스에 플러그인 추가하면 접속 가능하다
stateful한 항시적인 데이터베이스를 구현할건데 이를 실현하기 위해서 구글 등을 연결
emptyDir =pod의 lifecycle과 같이 되어있다
persistentvolume
첫번째 방향 physical한 스토리지가 별도로 존재
혹은 physical 스토리지 있고 원격접속하던지
physical한걸 쿠버네티스가 인식할수있도록 부착
항구적으로 쿠버네티스에 부착되어있는 상태 유지
pod은 주장한다 물리적인건 모르겠고 항구적인 스토리지가 필요하다고
persistent한 volume이 어느정도 필요하다고 claim
두개를 매치하는걸 쿠버네티스가 한다
admin이 쿠버네티스 설치하고 논리적인 하나로 묶고 유지관리하는 집단
유저는 클러스터링된 쿠버네티스 위에서 어플리키에션 쓰고싶은집단
개발팀과 쿠버네티스 운영팀. pod돌리고싶은 애들이 아래쪽
쿠버네티스 운영팀이 nfs기반으로 셋업했다
pod을 운영하는 사람의 desired state문서상으로
유저는 volume을 claim한다 필요하다고
pvc주장하는 유저의 pod아래 volume으로 쓴다
두개의 팀이 합쳐짐
구글이 mongodb돌리는 용도로 persistent volume만들어놨다
누군가가 pod을 가져와서 돌리고싶다 나는 몽고디비 pvc쓰고싶다 클레임 건다
volumne: mongodb되어있으면 네트워크든 뭐든 붙어있으면 상관없다
항구적인 정보가 필요하다면 pod이 늘고 주는거랑 상관없이
과금정보 게임 히스토리 정보 등을 해야하면 perisitent받아서 volume연결해서 쓴다 일종의 api같은것
pod을 개발하는 입장에서는 persistent volume claim해서 할당받으면 yaml파일에 매핑해서 쓰면 된다
스토리지가 근데 그렇게 만만하지가 않다
네이버 행사 deview 2021
cloud native storage
stateful 항시항구적 데이터를 네이버에서 쿠버네티스로 어떻게 운영하고있는가
stateful하다는것은 노드가 죽던말던 상관없이 항구적으로 존재하는 데이터를 가지고 구동하는 프로그램
cloud native application에서 bind-mount hostpath나 원격접속 등
노드안에 있는 정보는 노드장애시 데이터삭제
원격에다 두는거다 remote하게
원격에 항시항구 스토리지 두고 어플리케이션 짜는 사람은 편하게 claim하고 할당받으면 mount해서 쓰면 된다
원격에 있으면 서로다른 노드에서 접근하는데 여러개의 노드가 충돌을 일으킨다
worker 1과 worker2가 궁극적으로는 충돌한다 물리적인 디스크에 오로지 한놈만 쓸수있어야 함. 스케줄링을 할수밖에 없다!
스케줄링 어떻게? 본인 디스크에 쓴다면 운영체제는 stream이라는 컨셉 가지고 있어서 바이트를 강물같이 흘림. 어느정도 규모가 되면 운영체제가 디스크로 쓴다
일종의 메세지가 만들어짐 내 컴퓨터에서 떠나서 디스크 앞에가서 멈춘다 큐에들어간다
순서대로 뽑아서 디스크에 저장하는 과정
원격 스토리지에 대한 저장은 네트워킹 메세지 전송
phsical 한놈만 쓸수있으니 queue가 존재]
디스크가 여러갠거를 storage팀이 하나처럼 묶어준다
storage팀의 지향점??
스토리지팀은 쿠버네티스에 투입되어서 일할때
스토리지들을 논리적인 하나로 묶어준다
절대로 죽지 않는다. 근데 사실 죽는다.
single point failure로 모든 서비스 박살나지 않도록
resilient and survival
operation은 최소화한다
내가만든 앱을 잘 만들어서 쿠버네티스 위에서 돌리는데 개발자도 클라우드 네이티브 이해해서 그거에 맞는 개발을 해야한다
클라우드 네이티브가 가능하게 하는 팀이 있다. 스토리지를 담당하는 팀이 또있다
CNCF에 가서 본인관심 있는거 선정하기 시험
ceph
2007년에 박사과정 논문으로 만들어진 storage virtualizaton 2010년 오픈스택에서 디스크 가상화기술로 썼던거
openstack을 쓴다 virtual machin위해서가 아니라 필요한만큼 가상스토리지를 위해서
stateless app은 ceph쪽을 쓰고 stateful은 RBD
block storage, object storage
Thanos, Loki, Harbor? 완전히 다른 세상. 교수님도 잘 모름
이런게 있다
파일시스템 구현..
block cache
kafka 메세지 큐
스팸메일 등에서 시작했는데N곳에 동시다발적으로 정보 뿌린다
synology network attached storage
NAS 네트워크 통해서 접근하는 디스크
정보를 똑같이 옮긴다 빼고 꽂으면
디스크에서 안정성, 죽었을때 대비 위해서
페이스북 메타 이런데는 직접 디스크 네트워크 등을 직접 만든다
디스크 현재용량 등 데이터 프로메테우스에 모인다
