강의 수강일자: 06.03(수)

강의 복습일자: 06.09(월)

결국엔 복습하는 날짜가 밀리게 되었다 😂

꾸준히 쿠버네티스를 배우고 복습하는 습관을 들이려고 했지만, 연휴에 여행을 다녀오니 조금 나태에 빠진 주말을 보내고, 제대로된 복습을 하지 못했다. 지금이라도 다시 바로잡고, 밀렸던 진도들을 잘 따라가봐야겠다.

PVC / PV

PVC와 PV는 App이 실제로 저장되어 Pod와 연결되는 스토리지, Volume Object 개념이다.

Pod는 예상치 못한 오류, 과도한 트래픽 등으로 언제든지 종료될 수 있는 존재이다.

그래서 Pod에서 운영되는 App들은 Volume에 저장이 되어야 하고, Pod가 생성되면 바로 연결이 되어야한다.

그래서 Volume에 대해서 깊게 들어가자면,

Block, Files, Object와 같은 Storage 개념을 알아야 하고,

PV가 플러그인 역할을 해 저장소 역할을 해주는 볼륨 솔류션도 배워야 한다.

이번 강의에선 이렇게 깊게 들어가지는 않을 것이고,

단순히 PV에서 local 속성으로 마스터 노드를 스토리지 볼륨으로 사용하는 방식을 사용해 배운다.

Pod들을 선언하는 Deployment 영역을 살펴보면, 전 시간에 배웠던 secret과 동일하게 volume을 통해 PVC를 연결하는 코드들이 나와있다.

name이 files인 PVC를 mountPath로 어디에 생성할 지 지정하고, claimName과 PVC 의 이름이 일치해야한다.

실제 PVC와 PV 코드를 살펴보면,

(1) PVC

(2) PV

PVC의 selector 부분과 PV의 labels를 일치시켜 서로가 연결되는 모습을 확인할 수 있다.

• local 속성

   

  local 속성을 쓰게 되면 해당 PV가 저장되는 스토리지는 쿠버네티스의 마스터노드에 저장이 되고, path 위에 생성된다.
  생성된 스토리지의 path는 Pod에서 volume mountPath와 연결되어 Pod가 생성되면 스토리지와 연결된다.

   

   

  Pod의 volume을 hostPath로 사용해서 PV를 local로 가리키는 것과 같이 사용할 수 있다.

  그러나 쿠버네티스에서 hostPath를 사용하는 경우 보안적인 문제가 있어 가급적 readOnly를 사용해 마운트하는걸 권장함.

  
  Loki를 사용해서 App이 동작하는 log기록들을 볼 수 있었는데, Loki가 스토리지에 접근할 때도 이 hostPath를 사용해 log기록들을 가져온다.

PVC는 PV의 인터페이스 역할을 맡는다. 그래서 스토리지 크기, 접근모드(ReadWriteMany) 등을 설정해 PV의 값을 설정한다.

PV가 저장되는 스토리지 저장공간이 어딘지, 어느 노드의 path를 설정할건지는 PV가 정한다.

Deployment

App의 업데이트가 필요할 때, 기존 파드들을 삭제하고, 새 파드를 배포하는 과정을 거친다.

이때 모든 파드들을 한번에 삭제하고, 새 파드를 올리는 것이 Recreate type,

새 파드들 일부분이 배포가 완료되면 기존파드를 삭제함으로 교체해나가는 것이 RollingUpdate type이다.

RollingUpdate

rollingupdate는 파드 일부분을 새 파드로 조금씩 바꿔나가는 유형의 업데이트다.

이렇기에 업데이트를 하는 과정 중에는 App의 두 버전이 동시에 호출이 되게 된다.

두 버전의 App이 동시호출이 되지않게 하려면 Blue/Green 기능을 사용해 동시호출을 막고, 자원 사용량을 200% 증가시키는 특징을 가진다. 이 기능은 별도 배포 솔루션에서 사용할 수 있는 방법이다.

• maxUnavailalbe : 파드가 종료될 수 있는 퍼센티지로, 기존 파드가 2개에 50%이면,
  서비스 이용불가한 파드 1개까지는 허용될 수 있다.

• maxSurge : replicas 로 유지되는 pod만큼 추가 생성할 수 있다. 단위는 %이고,

  
  기존 pod 2개에 100%일 경우 파드를 2개 추가로 생성할 수 있다.

Service

nodeport : service의 type 중 하나로, port 를 사용할 때 node에 포트를 연결하여,
외부에서 Pod로 들어오는 트래픽을 연결해주는 역할을 해준다.

이렇게 nodeport에 포트번호를 할당하고, 외부에서 파드로 트래픽을 연결해주는 것이 서비스 퍼블리싱 (Publishing)이다.

쿠버네티스 내부에 있는 오브젝트들 사이에서도 포트를 통해 API 호출이 가능하다.
service의 이름인 api-tester-1231을 DNS로 사용하여

내부 DNS를 통해 원하는 Pod에 API를 날릴 수 있게 하는 것을 서비스 디스커버리(Discovery) 라고 한다.

targetPort에는 http로 되어있는데, 이는 Pod를 생성할 때

이와같이 컨테이너 포트에 대한 정보를 할당했고, 포트번호가 아닌 name으로 service에 적어두면, 해당 name에 맞는 포트번호로 자동으로 할당하게 된다.

서비스마다 Pod들이 제거되고 등록되는 과정들을 거치게 되는데, 이런 과정들을 거칠 때마다 IP를 자동으로 등록해주고 관리하는 기능을 Service에서 다 해준다. 이를 서비스 레지스트리 라고 한다.

또한 서비스마다 트래픽을 연결해줄 때, 여러개의 Pod로 트래픽들을 분산시켜주는 로드 밸런싱도 지원해준다.

HPA

 HPA의 코드에 들어가는 각 속성 별로 구분해서 HPA와 관련지어 설명해보겠다.

• scaleTargetRef
  해당 속성은 Deployment에 연결되는 속성이다. Deployment를 가리키는 selector 역할이라 생각하면 된다.

• min / maxReplicas
  파드가 부하될 때나 안정되는 경우 해당 범위에서 파드 개수를 조정하게 된다.
  최소 유지되어야 하는 파드 수는 min 값, 부하로 인해 늘어날 수 있는 파드 최대 수는 max 값이다.

• metrics
  파드가 사용하는 자원의 수치를 결정하는 데 영향을 미치는 속성이다.
  CPU, Memory 같은 자원의 사용량에 따라 파드 수를 조정하게 되는데, 주로 CPU 사용량에 영향을 받는다.

  cpu의 평균 사용량이 60%가 넘어가는 경우 ScaleOut이 되어 파드 수를 늘리게 되고,
  이때 변경될 파드 수 = 현재 파드 수 * (평균 CPU / HPA 설정 CPU) 로 값을 반올림해서 판단한다.
  metrics에서 사용하는 값은 퍼센티지 기준이고, 실제 Pod가 사용하는 CPU의 사용량은 파드 설정의 request 값에 있다.

  
  cpu 값이 100m 일 경우 해당 값이 100%의 기준이 되고, 한 파드에 부하가 발생했을 때 limits 값 이상으로 늘어나지 않는다.

  
  
  반면에 Memory 의 경우 부하에 따른 증감의 대상이 아니다. 메모리는 App을 기동하게 되면, 내부적으로 메모리 최대 사용량을 설정하게 되고, 해당 설정량을 넘어서게 되면, 가비지 컬렉션을 통해 사용되지 않는 메모리를 정리하며 수치를 낮춘다.

• behavior
  잦은 ScaleOut을 막기위한 속성으로, ScaleUp에서 stabilizationWindowSeconds 값이 120인 경우,
  120초 동안 평균 퍼센티지 사용량(60%)을 유지하게 되면 scaleOut된다는 설정이다.
  반대로 부하가 줄어들어 안정된 상태에서 ScaleDown하는 상황에서도 seconds 값을 설정해,

  
  해당 시간(초) 동안 파드 수를 유지한 뒤 파드 수를 감소하는 설정도 있다.
  또한 해당 시간 이후 파드를 전부 한번에 삭제하는 것이 아닌, policies에서 파드를 몇개씩 몇초마다 삭제할 지도 설정가능!