들어가며

이전 컨테이너 이론을 시리즈로 다루면서 시스템이 쿠버네티스까지 도달하는 과정에 대해 알아보았습니다.  해당 내용은 다음 페이지에서 알아볼 수 있으며, 이전에 쿠버네티스의 장점에 대한 내용을 간단하게 정리 했으니 오늘은 이를 자세하게 풀어나가는 시간이 되겠습니다.

쿠버네티스 장점

먼저 모든 서버에 쿠버네티스를 설치할 경우 운영 팀이 더 이상 애플리케이션 배포를 따로 처리할 필요가 없습니다. 컨테이너화된 애플리케이션은 이미 실행에 필요한 모든 것이 포함돼 있으므로 시스템 관리자는 애플리케이션을 배포하고 실행하기 위해 아무것도 설치할 필요가 없어집니다. 즉, 쿠버네티스가 배포된 모든 노드에서는 시스템 관리자의 도움 없이 즉시 애플리케이션을 실행할 수 있게 되는 것 입니다. 이외에도 여러 장점이 있는데 다음과 같습니다.

1. 애플리케이션 배포 단순화
   쿠버네티스는 모든 워커 노드를 하나의 배포 플랫폼으로 제공하기 때문에 애플리케이션 개발자는 자체적으로 애플리 케이션을 배포할 수 있으며 클러스터를 구성하는 서버에 관해 알 필요가 없어집니다.
   
   본질적으로 모든 노드는 이제 애플리케이션이 해당 노드를 사용하기를 기다리는 하나의 컴퓨팅 리스스입니다. 서버는 애플리케이션에 적절한 시스템 리소스를 제공할 수 있는 한 애플리케이션이 어느 서버에서 실행중인지 신경 쓸 필요가 없습니다.
   
   하지만 개발자가 애플리케이션을 특정 종류의 하드웨어에서 실행해야 하는 경우가 있습니다. 노드가 이기종인 경우 특정 기능이 있는 노드에서 애플리케이션을 실행하고 다른 애플리케이션은 다른 노드에서 실행하는 경우입니다.
   
   예를 들어 애플리케이션 중 하나가 HDD 대신 SSD가 있는 시스템에서 실행돼야 하고 다른 애플리케이션은 HDD에서 실행돼도 상관없을 경우 특정 애플리케이션이 항상 SSD가 있는 노드에 할당되도록 해야 합니다.
   
   이 경우 쿠버네티스를 사용하지 않는다면 시스템 관리자는 SSD가 있는 특정 노드를 하나 선택해 애플리케이션을 배포하게 됩니다. 그러나 쿠버네티스를 사용하는 경우 애플리케이션을 실행할 특정 노드를 선택하는 대신 쿠버네티스에 SSD가 있는 노드 중 하나만 선택하도록 지시해야 합니다.
   
   
2. 하드웨어 활용도 증가
   서버에 수동으로 애플리케이션을 실행하는 대신 쿠버네티스를 설정하고 애플리케이션을 실행함으로써, 인프라와 애플리케이션을 분리할 수 있습니다. 쿠버네티스에 애플리케이션을 실행하도록 지시하면 애플리케이션의 리소스 요구 사항에 대한 디스크립션과 각 노드에서 사용가능한 리소스에 따라 애플리케이션을 실행할 가장 적합한 노드를 선택할 수 있습니다.
   
   컨테이너를 사용하고 애플리케이션을 클러스터의 특정 노드로 지정하지 않으면 언제든지 애플리케이션이 클러스터 간에 자유롭게 이동할 수 있으므로 클러스터에서 실행되는 다른 애플리케이션 구성 요소를 혼합해 클러스터 노드에 배치할 수 있습니다. 노드의 하드웨어 리소스를 최대한 활용할 수 있게 되는 것입니다.
   
   쿠버네티스는 언제든지 클러스터 간에 애플리케이션이 이동할 수 있으므로, 수동으로 수행하는 것보다 훨씬 더 인프라를 잘 활용할 수 있습니다. 사람은 최적의 조합을 찾는데 능숙하지 않은데, 특히 애플리케이션 구성 요소가 많고 배포할 서버 노드가 많은 경우와 같이, 가능한 옵션의 수가 많을 때 컴퓨터는 이 작업을 사람보다 훨씬 더 빠르고 더 잘 수행할 수 있습니다.
   
   
3. 상태 확인과 자가 치유
   서버 장애 발생 시 언제든지 클러스터 간에 애플리케이션을 이동할 수 있는 시스템을 갖추는 것도 중요합니다. 클러스터 크기가 증가하면 컴퓨터 구성 요소의 고장을 더 자주 처리하게 됩니다.
   
   쿠버네티스는 애플리케이션 구성 요소와 이 애플리케이션이 구동 중인 노드를 모니터링하다가 노드 장애 발생 시 자동으로 애플리케이션을 다른 노드로 스케줄링합니다다. 이로써 운영 팀은 애플리케이션 구성 요소를 수동으로 마이그레이션할 필요가 없어지고, 애플리케이션을 재배치하는 대신 즉시 노드 자체를 수정해 사용 가능한 하드웨어 리소스 풀에 반환하는 데 집중할 수 있습니다.
   
   인프라에 장애가 발생한 노드가 없어도 정상적인 시스템 작동이 가능하도록 충분한 예비 자원이 있는 경우 운영 팀은 새벽에 일어난 장애에 즉시 대응할 필요가 없습니다. 규칙적인 근무 시간 동안 잠을 잘 수 있고, 정규 근무 시간에 장애가 발생한 노드를 처리할 수 있습니다.
   
   
4. 오토스케일링
   쿠버네티스를 사용해 배포된 애플리케이션을 관리한다는 것은 급격한 부하 급증에 대응하기 위해 개별 애플리케이션의 부하를 운영 팀이 지속적으로 모니터링할 필요가 없음을 의미합니다. 쿠버네티스는 각 애플리케이션에서 사용하는 리소스를 모니터링하고 각 애플리케이션의 실행 중인 인스턴스 수를 계속 조정하도록 지시할 수 있습니다.
   
   클라우드 인프라에서 쿠버네티스가 실행 중인 경우 클라우드 제공업체의 API로 쉽게 노드를 추가하면 배포된 어플리케이션의 부하에 따라 전체 클러스터 크기를 자동으로 확장하거나 축소할 수 있습니다.
   
   
5. 애플리케이션 단순화
   애플리케이션이 개발과 프로덕션 환경이 모두 동일한 환경에서 실행된다는 것을 생각하면 버그가 발견됐을 때 큰 효과를 발휘합니다. 버그를 빨리 발견할수록 버그를 수정하는 것이 쉽고, 수정에 더 적은 작업이 필요합니다. 쿠버네티스는 버그를 해결하는 개발자의 작업이 줄여줄 수 있습니다.
   
   또한, 개발자가 일반적으로 구현해야 하는 기능을 구현할 필요가 없어집니다. 여기에는 클러스터된 애플리케이션에서 서비스나 피어를 검색하는 기능도 포합됩니다. 쿠버네티스가 애플리케이션 대신 이 작업을 수행합니다. 일반적으로 애플리케이션은 특정 환경변수만 조회하거나 DNS 조회만 수행하면 됩니다. 충분하지 않다면 애플리케이션에서 쿠버네티스 API 서버를 직접 쿼리해 해당 정보나 혹은 다른 정보를 얻을 수 있습니다. 쿠버네티스 API 서버를 쿼리하면 개발자가 리더 선정같은 복잡한 메커니즘을 구현하지 않아도 됩니다.
   
   
6. 개발자들의 신뢰도 증가
   쿠버네티스의 마지막 장점은 새로운 버전의 애플리케이션을 출시할 때 쿠버네티스가 새로운 버전이 잘못됐는지 자동으로 감지하고 즉시 롤아웃을 중지한다는 것을 알고 있는 개발자들이 느끼는 신뢰성 증가를 들 수 있습니다. 이는 애플리케이션의 지속적인 전달을 가속화해 조직 전체에 도움이 됩니다.

사담, 개인적인 팁

이번 포스팅에서는 쿠버네티스의 장점에 대해 알아보았습니다. 다음 포스팅에서는 쿠버네티스의 구조와 몇몇 단어들을 설명하려고 생각중입니다. 클라우드 엔지니어가 되기 위해 네트워크, 리눅스를 거쳐 컨테이너, 앤서블을 지나는 중입니다. 이렇게 강의를 받다보면 이론이 정말 중요하지만 실습의 필요성을 절실히 느낍니다. 현재 강의에서는 실습 위주로 진행되고 있는데, 여기에 따로 공부하는 이론이 추가 되면 엄청난 학습 효율성이 생기게 됩니다.

물론 이 공부 방법은 저에게 잘 맞을 뿐이지 정답이라고는 할 수 없습니다. 이미 현업에 종사하시는 분들에게는 의미가 없을 수 있지만, 한 가지 팁을 드리자면 '오류를 두려워 하지말라'입니다. OS에 따라 다르겠지만 보통 오류가 떳을 때 어떤 이유로 오류가 났는지, 해결 방법은 어떤 것이 좋을 지 추천해줍니다. 설명하는 영어의 난이도가 그렇게 높지 않으니 한번 읽어보면 생각보다 금방 오류가 해결되는 것을 보실 수 있으리라 생각됩니다.

또 다른 것은 영어는 조금씩 공부해두는 것 입니다. 현 세계 공통어가 영어이고, OS들이 기본적인 언어들이 영어를 베이스로 하고 있습니다. 따라서 분석을 할 때 영어만한 조리 도구가 없다는 것 입니다. 번역을 거치는 과정에서 오류가 발생하고 의도가 틀어지기도 하니 말입니다.

정리하자면 영어를 공부하는 것과, 오류에 너무 겁먹지 말고 읽어보는 것이 되겠네요. 오늘도 읽어주시는 많은 분들에게 감사하며 다음에 더 좋은 포스팅으로 뵙도록 하겠습니다. 감사합니다.