앱이 이중화되어, 트래픽을 골고루 받는 상황
- yaml 설정
- minRelicas: 2 / maxReplias: 4 → 2~4개 노드 사용
- averageUtilization: 40 → CPU 평균 40%을 넘겨야 늘림
- nodePort에 포트를 지정해서 거기로 트래픽을 받음
- service는 알아서 트래픽을 나눠줌
- curl로 2초 간격으로 트래픽을 보내고 라우팅되는 것을 확인
- 파드가 죽어도 자동생성 (1~2초 걸림)
- 보통 메모리 증가로 죽으니까 메모리릭을 일부러 내보면
- 죽자마자 재시작됨 (재시작 카운트 올라감)
- 그라파나로 메모리도 보고 … 에러 로그도 확인하고
- CPU 올라간다 싶으면 파드도 늘려주고, 트래픽 분산
- 이미지 업데이트
- 그 동안에도 파드는 끊기지 않음 와웅!
- 운영에서 몬가 … 몬가 일어나서 잘못 업데이트 되면?
- 정상적으로 기동이 안되니까 계속 재시작
- 그래도 안되면 서비스 옮겨가지 않음
배포 시나리오 예시
기존 VM 환경
**대충 그림 **
- 수동 설정으로
- 각 OS에 App을 하나씩
- Web server로 트래픽은 라우팅 되어 들어오고
- 모니터링 시스템도 붙어있고
- 오픈 전날 이런 저런 테스트를 다 해보겠지만 현실은 늘 … 까봐야 아니까
- 여유 자원 확보를 위해, VM에 OS를 담당하는 사람이 수동으로 설정을 다 해둠
- 웹 담당자가 IP 세팅
- 작업하다 뻑나기도 하니까 앵간하면 야간에 작업함
- 모니터링 작업자는 이 세 개가 다 보이도록 config 수정
쿠버 환경
- 증설이 필요하면 쿠버네티스 엔지니어에게 파드 늘려달라고 요청
- 딸-깍. 완료!
- 이미 테스트 기간에 증설은 다 해봤음
- 휴먼 에러 날 일도 잘 없음
인프라 환경 관리의 코드화
- 도커에서 컨테이너 만들 때 다 코드로 남아있음
- 기존 환경에서는 작업 환경이 다 코드로 남지도 않고
- 문서로 남겨도 실제랑 다른 경우가 빈번
- 배포할려면 다 작업 이력이 남을 수 밖에 없음 → 인프라 히스토리 관리가 쉬워짐
- 자원 관리도 다 코드로 되고 작업자 이력도 다 남음
- 코드로 인프라 관리를 하다보니 환경별로 배포 파일을 나눌 수 있음
- 시간 있을 때 미리 구성할 수도 있음
- 과거에는 장비가 들어와야 직접 들어가서 이것저것 했음 ㅠㅠ
- 코드는 복사해서 만듬 → 휴먼 에러가 적음
- 새 인프라 깔 때도 경험이 녹아서 더 쉬워짐