[k8s] Application 기능으로 이해하기-PVC/PV, Deploym...

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다.

• 강의 링크 : https://inf.run/NzKy

쿠버네티스 어나더 클래스 (지상편) - Sprint1 강의 - 인프런

 

 

PVC, PV

• k8s 에서 각 파드별로 파일시스템이 존재한다. 파드 안에서 사용되는 파일 시스템은 보통 파드가 재시작 되면 이전 내용이 사라진다.
• 이러한 파일을 관리하려면 k8s 에서 제공하는 Volume 을 통해 각 파드의 내용을 저장하거나 공용으로 파일시스템을 사용할수 있게 해준다.
• 이중 사용되는 것이 PV와 PVC이다.
  • PV (Persistence Volume): k8s 에서 사용하는 Volume 자체를 말함.
  • PVC (Persistence Volume Claim) : 사용자가 PV 를 어떻게 사용할지 쓰는 설정값. (용량설정, 읽기/쓰기모드 설정)
• PV 구조

• PV 에서는 위에 말했던것 처럼 Volume 의 내용이 들어간다.
• local : 노드의 경로를 지정함.
• nodeAffinity 값이 필수로 있어야 한다. -> 어느 Node 에 파드를 생성할것인지 지정해줌.
• PV 의 local 속성에 설정한 경로값으로 파드가 생성시에 Master node 안에 해당 local 경로의 파일을 각 파드의 위치시켜 파일을 유지한다.
• 이와 유사하게 hostPath 를 각 파드에 주어 이와 유사하게 사용될수 있지만 k8s 공식문서에서는 해당 방법을 지양하는것이 좋다고 한다.
• hostPath 사용시에는 파일또는 디렉토리 범위만 지정하고 되도록 ReadOnly 옵션으로만 사용하길 권장한다. (공식문서link)

PV 를 사용하는 이유

• Volume 과 관련된 수많은 솔루션 들이 있음.
• 개발자(서비스개발자)가 해당 내용까지 다루기가 다소 신경쓸 것이 많음.
• 인프라 담당자는 각 솔루션에 맞게 PV 를 구성하고 개발자는 단순하게 PVC 를 통해 PV 를 이용하면 되는 구조로 보면된다.
• PVC 는 인터페이스 역할을 해주어 혹여나 PV 가 변경되더라도 파드의 구성을 변경하지 않도록 사용한다.

 

 

Deployment

• pod 의 내용이 수정되거나 배포가 필요할때 Deployment 오브젝트를 통해 pod 를 재배포 해주는 역할을 한다.
• Deployment 오브젝트 내부에서 template 내용이 하나라도 변경되면 pod update 가 진행된다.
• strategy 옵션을 통해 배포 방식이 달라진다.
  • Recreate : 기존 사용하던 pod 를 모두 종료시키고 새로운 pod 를 replicas 갯수만큼 생성한다. → 서비스 중단시점이 생긴다.
  • RollingUpdate : 기존 pod 는 그대로 유지한 상태로 새로운 pod 를 생성하고 새로 생성한 pod 들이 하나가 기동이 완료될때마다 기존 pod를 종료시킨다. → 자원사용량이 150%  증가한다. 서비스 중단은 없지만 이전/신규 버전이 혼용될수 있다.
  • Blue/Green : 이전 pod를 그대로 유지시킨채 새로운 pod를 기동한후 새로운 파드가 모두 기동이 완료되면 요청흐름을 새로 기동된 pod로 바꿔주면서 이전 pod를 종료시킨다. → 자원사용량이 200% 증가한다. 버전 혼용이 전혀 없다.
• RollingUpdate 시에 아래 옵션이 사용 가능하다.
  • maxUnvaliable : 업데이트 동안 최대 몇개의 pod 를 서비스 상태로 둘 것인지 설정. (default 25%)
  • maxSurge : 새로운 pod 를 최대 몇개까지 생성할것인지 설정. (default 25%)
  • 두 옵션을 100% 로 설정하면 Recreate 와 동일하게 동작함.
  • maxUnvaliable 을 어떻게 주느냐에 따라 서비스 중인 pod를 몇개를 유지시킬 것인지가 결정된다.
  • pod 기동이 빠르다면 Blue/Green 과 유사한 동작을 할수도 있다.

Service

• Service 의 기능
• 서비스 퍼블리싱 역할
  • NodePort type 의 경우 외부에서 들어오는 트래픽을 Pod 로 연결해 주는 역할을 한다.
  • 외부 포트의 정보와 내부 pod의 포트 정보를 연결하여 트래픽을 연결해 준다.
• type 을 지정하지 않으면 default type 은 ClusterIP 로 지정된다.
  • 내부 pod 트래픽 역할.
• 서비스 디스커버리 역할
  • 서비스의 이름으로 서비스를 호출할 수 있는 일종의 DNS 역할
  • 서비스 이름:포트 로 요청시 서비스를 통해 내부 포트로 트래픽을 연결해 주는 역할을 한다.
  • 자동으로 서비스 명으로 DNS 를 등록한다.
• DNS 역할
  • 서비스의 포트를 지정할때 특정 포트가 아닌 pod 에서 지정한 포트의 name 을 지정해 주어도 포워딩이 가능하다.
  • 해당 기능을 통해 Pod 의 내부 포트정보가 변경되더다로 동일한 이름의 name 을 계속 사용한다면 서비스에서는 포트 정보를 변경해 주지 않아도 된다.
• 서비스 레지스트리 역할
  • Deploment 를 통해 Pod 가 생성되고 삭제되었을 때 해당 파드로 요청되는 트래픽을 pod 에서는 신경쓰지 않아도 된다.
  • 서비스에 pod 가 연결되어야 트래픽이 해당 파드로 연결될수 있기 때문에 아직 기동중이거나 종료된 pod 에 트래픽이 전달되는 것은 신경쓰지 않아도 된다는 것.
• 로드밸런싱 역할
  • replica 로 지정한 수만큼 띄워진 pod 에 각 요청을 로드밸런싱 해주는 역할을 수행한다.

HPA

• HPA (Horizontal Pod Autoscaling)
• 이름 그대로 Pod 를 오토 스케일링 해주는 역할이다.
• 해당 pod의 부하 또는 자원 사용량에 따라 자동으로 pod 를 스케일 아웃 시켜준다.
  • 스케일 아웃 : 서버의 자원이 부족할 때 사용중인 서버와 동일하게 새로운 서버를 하나 더 실행시켜 부하를 더 받을수 있게 해주는 방법.
  • 스케일 업 : 서버의 자원이 부족할 때 해당 서버의 물리적 자원을 증가시켜 (메모리증가/디스크용량증가/cpu코어수증가 등) 부하를 더 받을수 있게 해주는 방법.
• 설정한 metrics 정보에 따라 부하가 어느정도 되었을 때 스케일 아웃할 것인지 결정된다.
• 잦은 스케일링을 방지하기 위해 behavior 설정을 통해 부하의 상태가 어느정도 유지될때 스케일 아웃을 진행하도록 설정할 수 있다.