5. Managing Resources

 

인스턴스를 어느 사이즈로 고를까? 디스크 사이즈는 어떻게 할까? 내가 골라준 인스턴스, 리소스들을 쿠버네티스를 어떻게 다룰까? 노드당 pod 비율을 어떻게 할까?

 

이런 전반적인 Resource에 대해서 다룬 chapter이다.

 

쿠버네티스는 pod의 limit을 정해둘 수가 있고,(yaml 파일의 resources 항목을 채우면 된다.) 스케줄러는 pod의 크기와, 클러스터의 여유공간을 비교해, 적절한 위치에 pod를 배치시킨다.

 

이런 클러스터 조율이라는게 늘 그렇듯이 저자 또한 자신의 Rule of thumb을 설파한다.

 

- Container를 작게 유지해라

- 노드당 pod limit이 있기 때문에 너무 큰 인스턴스는 자원낭비이며, 동시에 너무 작은 인스턴스는 os 크기 등의 overhead가 있다.

- pod가 너무 적으면 자원낭비고, 너무 크면 fault가 발생한다.

 

pod의 resoure limit은 어떻게 정할까? => 뒤의 모니터링에서 다룬다고 하는 걸 보니 프로메테우스를 이용해서 프로비저닝을 하는 것 같다.

 

liveness probes : health checking을 수행한다.

 

- TCP Connection에 대한 Probes

- gRPC probes (gRPC가 구글에서 만든 프로토콜이라고 한다. blackbox exporter에서 이름만 들어봤지 뭔지는 몰랐다.)

-readiness probe : 서비스를 하다가 네트워크 등의 문제로 일시적으로health checking이 안될때가 있다. LB라던지 일반적인 경우는 이럴 경우 일정 기간 내내 응답이 없는지를 체크 한 후, disable 시키는데, 이건 health check 가 안되는 pod는 일단 로드밸런싱에서 제거해두고, 나중에 응답이 돌아오면 그때 다시 연결한다. <= 고객에게 fault를 만날 확률을 최대한 줄여준다.

 

강의에서는 name space를 서비스 이름으로 두고 deployment를 마이크로 서비스로 뒀는데, 여기서는 그냥

spot instance, affinity  등의 팁도 짤막하게 전했다.

 

신기했던 포인트는 pod를 중간중간  shuffle해주지 않으면 특정 노드에 pod가 몰려버려 fault가 failure로 발전할 수 있다는 점이었다. 이 상황에서 deploy를 하면 그대로 모든 인스턴스가 다른 노드로 또 몰려버린다.

=> 솔직히, pod의 갯수가 많을 수 밖에 없는 웹서버의 경우에는 pod의 숫자가 node의 숫자를 넘겨서 node에 자동으로 골고루 배치되겠지만, 작은 마이크로 서비스의 경우에는 분명히 이런 문제가 발생 할 수 있을것이다.

 

이때 이들을 섞는 역할을 하는것이 Descheduler라고 한다. (처음 들어봤다.)