Application 기능을 이해하기 PVC, PV / Deployment / HPA / Service

PVC, PV

• PVC와 PV의 용도는 영구적인 저장을 위한 스토리지 연결을 위해 사용
  • PVC가 인터페이스(자원 요청)와 같은 역할로 인프라 담당자가 PV를 수정해도 POD에 영향이 없게금 중간 다리 역할을 함
• PVC와 PV의 resource와 accessModes는 같아야함. (라벨 이외에도 이것이 같아야 연결 가능)
• PV에서 local을 쓰면 nodeAffinity 연결이 가능해지고 어느 Node에 Pod를 생성할건지 지정할 수 있음
  • 테스트 때만 사용하는 용도임
  • 한편 위와 같이 Pod에 직접 저장하는 방식은 hostPath와 nodeSelector를 이용해도 가능함.
    • 하지만 위 같은 경우 Pod는 언제든 죽을 수 있기에 운영 환경에서는 사용 X
    • 기본적으로 hostPath는 Loki와 같은 노드의 정보를 이용해야하는 기능의 App을 사용할 때 가능
• node에 데이터를 유지도 가능
  • Pod보단 덜 죽지만 node도 죽을 수 있고 그러면 수정을 해줘야 하기 때문에 추천하지 않음
• PVC와 PV 없이도 hostPath와 같은 것으로 연결이 가능하지만 PV는 인프라 담당자, PVC와 Pod는 개발자가 맡는 식으로 가지고 있는 역할을 분리할 수 있기 때문에 사용
  • 하지만 쿠버네티스를 모두 알고 있는 것이 아니기에 각 오브젝트마다 맡는 담당자가 위처럼 확정되지는 않음

Deployment - update

• Deployment update를 이용하여 Pod 변경 정책을 짤 수 있음
• Deployment를 수정하면 새로운 ReplicaSet이 만들어지고 그에 따른 Pod가 만들어짐. -> 기존에 있던 ReplicaSet의 replicas가 0이 되며 Pod가 삭제 되고 기존의 ReplicaSet은 남게됨 (rollback 용도)
• 기본적으로 변경 정책에는 Recreate와 RollingUpdate가 존재함
  • Recreate는 모두 삭제하고 생성하는 방식 -> 가동 시간 만큼 중단됨
  • RollingUpdate는 삭제하며 생성하는 방식 -> 업데이트 중 서비스 중단은 없지만 자원 사용량이 증가하며 두버전이 동시에 호출 될 수 있음
    • maxUnavailable은 서비스 불가능한 pod 수
    • maxSurge는 새로 추가될 수 있는 pod 수를 의미함.
    • 위 두개를 조정 시켜 각 Pod가 수정되는 방식을 조정 가능함

Service

• Service는 내부 Pod로 가는 트래픽을 통제
• 서비스 오브젝트에는 type이 존재
  • NodePort는 Node에 port를 놔두어서 외부 트래픽이 들어올 수 있게함
  • 기본 값은 ClusterIP로 쿠버네티스 내부 Pod만 들어올 수 있게함
• 기본적으로 Pod는 죽을 때마다 ip가 변경되기 때문에 Service를 사용함
  • 트래픽이 안으로 들어오면 targetPort를 따라 해당되는 Pod로 트래픽을 보냄
    • 포트로 나둘수도 있고 이름으로 놔둘 수도 있음
    • 포트로 놔두면 포트 대로 라우팅이 되고 이름으로 놔두면 상대 Pod의 ports의 name을 통해 들어가서 containerPort로 바뀌어서 수행이 됨
    • NodePort면 nodePort에서 targetPort로 ClusterIP면 port에서 targetPort로 바뀌며 트래픽이 들어감
  • 서비스도 죽으면 IP가 바뀜. DNS를 이용하여 도메인으로 트래픽을 받음
• 외부에서 Pod가 죽고 IP가 변하면 서비스에서 알아서 IP가 수정이 됨. 트래픽 로드 밸런싱도 가능
  • 해당 기능을 서비스 레지스트리라고 함

HPA

• HPA를 통해 메트릭 수치를 보고 스케일 아웃과 같은 기능도 가능
• 기본적으로 CPU를 통해 스케일 아웃을 진행
  • ram은 가능은 하나 부하에 따른 증감 대상이 아니기에 많이 사용은 안함
  • 다른 리소스들도 보려면 다른 툴을 연결해줘야함
• 100% 기준 값을 기준으로 위 그림의 수식에 따라 스케일 아웃을 진행
  • limit는 수치를 결정하는 데 영향도가 큼
    • limit를 못 넘어가기 때문에 pod 전체의 트래픽이 스케일 아웃의 임계치를 못 넘어가게 할 수도 있기 때문
• 현실적으로 해당 스케일 아웃 기능만으로는 완전히 중단 없이 트래픽 부하 막기 불가능
  • 완전히 막으려면 미리 pod 수를 늘리는 식으로 대응 해야함.

 

출처: https://inf.run/7dm3q