레플리카

 

실제 제작에선 , POD를 직접적으로 사용하기보단

1. 레플리카를 사용하거나 2. 배포 방식을 활용한다. 

 

그 중, 레플리카 방식을 활용해보자 

 

POD는 NODE가 실패하면 POD가 같이 종료된다. 또한 CPU가 부족해도 POD가 종료될 수 있다.

 

즉 여태까지 했던 것처럼 YAML에 POD를 정의하고 KUBECTL APPLY를 진행하면,

포드가 사망하면 돌리기가 힘들다. 

 

 

이러한 예시를 생각해보자

 

EX) POD의 실행이 어떠한 이유로 종료되었다. 그렇다면 현재 SERVICE는 남아있지만, POD는 동작이 멈추었기 때문에 

웹사이트는 동작하지 않는다. 

 

그러므로 주로 POD를 그대로 배포하기보단 레플리카 SET를 배포한다.

 

레플리카 세트는 , K8S의 추가 구성에서 코어 기능으로 진화했다. 

포드 실행시 레플리카 몇개가 동시에 실행되는지를 설정할 수 있다.

만약 에 POD가 강제적으로 종료된다면,  레플리카는 이를 감지하고 자동으로 새로 생성하여준다.

 

레플리카.YAML은, 하나에 파일에 POD와 레플리카를 모두 포함한다. 

 

레플리카또한, SERVICE처럼 SELECTOR를 가지고 있다.  

 

<적용 예제>

 

일단, pod가 중복 생성될 위험이 있기 때문에 기존 pod들을 정리해주자.

 

 

 

해당 파일이, 래플리카의 yaml이다. 

version은 apps/v1으로 변경되었고, 그 종류가 replica임을 명시하였다.

 

약간 변경된 점들은 spec:selector:matchLabels:mapp을 통해 마치 service에 있던

elector처럼 key:value를 확인해주는 것이고, 

replicas로 레플리카가 몇개의 pod를 유지할지이다. 그리고 이후 내용은 동일하다. 

replicas의 수가 2이라면, 레플리카는 2개의 pod를 유지하려 노력한다.

 

 

달라진 점들을 확인할 수 있다.

POD와, 추가적인 SECTION이 있다. --> 실행 컨테이너 수가 CURRENT, READY는 대기 컨테이너 수이다.

또 POD의 이름은 CLUSTER- 이후 부는 자동으로 생성한다.

 

<포드 종료 가정>

 

이와 같이, 상황을 가정하여 강제적으로 포드를 종료시켰다.

 

 

그럼에도, 다시 생성된다. 레플리카가 본연의 역할을 잘 하고있다.

 

웹사이트는 , redirect시 다시 정상적으로 동작한다. 

 

이와 연관되어, 하나의 서비스에는 여러개의 port가 이 endpoint를 지나갈 수 있다

 

*주로 사용되는 분야 :

frontend에서 주로 2 replicas로 사용한다. 

frontend는, 적어도 매일 멈춰선 안된다.