기존 환경은 하나의 OS에 앱을 하나씩 올리고 웹 서버를 통해서 트래픽이 라우팅 되는 구조였습니다.
하지만 Kubernetes 환경에서는 하나의 OS에 노드 위의 파드를 통해 2개의 애플리케이션 올리는 것이 가능하다.
실제 오픈 때 여유 자원을 할당해 놓고 늘릴 준비를 하게 되는데 두 환경 모두 여유 VM을 할당할 수 있고 파드도 늘릴 수 있는 자원이 충분하다고 가정해보겟습니다.
VM환경에서는 수동으로 이런 설정들을 미리 해놓고 증설을 합니다. 그리고 웹 서버 관리자가 IP를 설정해야 하는데 IP 설정이 작업자 입장에서는 단순한 작업이지만 운영 상황에서는 생각을 많이 해보아야 합니다.
그리고 이렇게 VM 담당자가 증설을 해도 모니터링 담당자에게는 증설한 것이 보이지 않기에 이를 알려줘야 알아차리는게 가능합니다.
하지만 Kubernetes 환경에서는 이러한 것들을 모두 자동화하는 것이 가능합니다.
그리고 Kubernetes 관리 환경의 코드화는 엄청난 이점을 가져다 줍니다.
도커파일을 보면 이렇게 컨테이너 빌드를 할 때 OpenJDK17버전 및 포트를 8080으로 오픈을 한다는 코드입니다.
이렇게 기록으로 인프라를 관리하면 히스토리 관리에 용이합니다.
그리고 누가 무슨 작업을 했는지도 추적이 가능합니다. 만약에 인프라에 이슈가 생겼을 때 혹시 누가 실수한 건 아닌지 의심하고 서버 로그를 뒤져보기도 합니다. 하지만 프로젝트를 하다 보면 어드민 아이디 도 막 돌려서 쓰기 때문에 찾기 힘듭니다. 쿠버네티스에서는 이게 확실하다.
코드로 인프라를 관리하면서 환경별로 배포파일을 나눠서 만들 수가 있는데 여기서 두 가지 엄청난 장점을 있다.
첫번째로 보통 개발,검증 운영 순으로 인프라를 구성하는데 실제 장비가 들어오고 네트워크 설정이나 보안 등 사전 작업이 다끝나야 내가 들어가서 환경 설정을 할 수 있습니다. 하지만 쿠버네티스 환경에서는 미리 구성이 가능하다.
두 번째로 코드이기 때문에 복붙이 가능해서 휴먼에러가 준다.
위 자료는 쿠버네티스 어나더 클래스(지상편) - Sprint1의 강의를 듣고 정리한 자료입니다.
https://www.inflearn.com/course/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%96%B4%EB%82%98%EB%8D%94-%ED%81%B4%EB%9E%98%EC%8A%A4-%EC%A7%80%EC%83%81%ED%8E%B8-sprint1/dashboard