쿠버네티스가 무엇일까요?

쿠버네티스가 무엇일까요?

안녕하세요.
이번 주제는쿠버네티스입니다.
쿠버네티스에 대해서 알고 싶은데 잘 모르시는 분들도 많이 계실 것 같고요.
도커 컨테이너까지도 나는 모른다 라고 하면은 이전 영상이 있으니까 꼭 보고 오시기 바라겠습니다.
근데 도커 컨테이너를 이해했다고 하더라도 이게 도커도 관리를 한다라고 생각을 했는데 쿠버네티스도 관리를 한다라고 생각하고 또 컨테이너 기반으로 구동된다는 것도 비슷하다고 하니까 굉장히 헷갈려 하시는 경우들이 많습니다.
이번에 쿠버네티스가 정확하게 어떤 건지를 어떤 역사 라든지 이론적인 내용들 보다는 현실적으로 뭔지를 쉬운 말로 풀어서 한 번 설명을 좀 드려 볼 거고요.
그리고 또 그거를 명령어로  한 번 증명 해서 눈으로 한 번 보여드리도록 할게요.
자, 바로 가보도록 하겠습니다.
쿠버네티스라는 게 무엇이냐?
쿠버네티스를 이해할 때는 도커의 한계점을 먼저 이해를 해야 됩니다.

우리가 컨테이너 라는 게 뭐였죠?
윈도우 시스템 이라면 윈도우의 C 드라이브 들을 모든 프로세스가 공유하는 게 아니라 이 모든 프로세스 들이 각각이 각자 만의 C드라이브를 가졌죠.
리눅스에서는 리눅스 컨테이너는 리눅스의 C 드라이브가 사실상 루트 파일 시스템 이잖아요.
그래서 각자 만의 루트 파일 시스템을 갖고 각자 만의 설정 폴더, 각자 만의 라이브러리, 각자 만의 패키지 관리 이런 것들이 되는 게 컨테이너 라고 말씀드렸습니다.
도커는 결국엔 컨테이너 생성 도구예요 물론 관리하는 기능들이 있지만 조금 미시적인 관점에서의 관리라고 보는 게 맞습니다.
그냥 컨테이너를 생성하고 삭제하고 뭐 그 기타 등등의  소소한 작업들 인 거죠.
그런데 이 컨테이너가 뭐 몇백 개 이상이 되고, 또 몇 천 개까지 넘어가고 그거보다 더 이상인 수억 개까지 넘어가게 된다면 도커로는 관리하기가 굉장히 힘들어요. 그것 뿐만 아니라 서버 자체가 여러 대가 된다.
예를 들어서 AWS 의 EC2 라든지 혹은 물리 서버라고 하더라도 서버가 여러 대를 가지고 관리를 하게 되면 또 도커가 관리하기가 굉장히 힘들어져요.
스크립트를 어찌어찌 한다고 하더라도 도커는 결국에 컨테이너를 생성 하거나 삭제하는 그런 컨테이너 런 타임 도구에 불과하지 않기 때문에 결국에 한계점이 많이 보입니다.
그래서 이런 부분들을 극복할 수 있는 게 쿠버네티스 라고 말씀드릴 수가 있겠고요.
그럼 쿠버네티스는 뭐냐? 컨테이너를 단순하게 생성하는 도구가 아니에요.
이 컨테이너를 생성하는 도구는 따로 있죠.
컨테이너 D 라든지 혹은 도커 이런 컨테이너 런타임 도구를 활용합니다.
그러니까 이게 수단이라는 거죠.
그러면은 쿠버네티스의 도대체 그 목적이 뭐냐 수단은 컨테이너를 생성하는 거고, 목적이 뭐냐 목적은 서버 배포 운영 관리에 있습니다.
우리가 사실은 쿠버네티스가 없어도 서버를 관리하고 운영하고 또 서버에다가 여러 가지 웹 프로그램, 웹 서버 프로그램, 다양한 프로그램들을 배포하고 관리를 했었어요.
그래서 그 운영과 관리, 배포 들을 도와주고 더 정확하고 더 자동화 돼서 편리하게 할 수 있게끔 도와주는 게 쿠버네티스의 목적입니다.
그래서 쿠버네티스가 컨테이너 기반으로 구동되는 거는 맞지만, 사실상 목적은 서버 관리 서버 운영 서버 배포에 있다라는 거를 이해하는 게 굉장히 중요하게 있습니다.
자 도커는 뭐라고요?
컨테이너 생성 관리의 목적에 있다는 거고, 그런 거는 미시적인 관점에서의 관리라고 얘기를 해야 되고요.
조금 더 거시적 이죠.
쿠버네티스 같은 경우에는 서버 물리적인 서버가 여러 대가 있고, 또 컨테이너 도 여러 대가 있을 때 이 서버와 서버를 운영하거나 관리하는 거에 초점을 맞춘다는 거죠.
그러면 도대체 서버를 운영하고 관련되는 게 뭐냐, 왼쪽에 보이는 기능들을 뜻하게 됩니다.
그 여러 개의 서버 들을 통합 관리 한다던가 실행될 서버를 선택 한다던가 트래픽을 로드 밸런스 한다던가 스케일 인 아웃 여러 가지들이 있습니다.
장애를 복구 한다던가 이런 것들이 결국에 서버를 운영 관리한다 라는 건데요.
쿠버네티스가 없을 때에도 이런 것들을 다 했어요.
근데 그게 왜 불편하고 쿠버네티스가 있으면 뭐가 좋은지를 한 번 비교해서 설명을 좀 드려보도록 하겠습니다.

자, 첫 번째, 여러 개의 서버를 통합 관리하는 겁니다.
이거는요 전문 용어로는 클러스터 링 이라고 표현을 하게 되는데요.
여러 개의 서버를 통합 관리하는 부분은 우리가 쿠버네티스를 안 쓰더라도 필요하다라고 말씀을 드렸었죠.
우리가 서버가 뭐 한 대, 뭐 두 대, 세 대 뭐 여러 대가 될 수 있는데 그런 것들을 서버 관리자가 관리를 할 수 있습니다.
각각의 IP address가 각자 있을 수 있어요.
그러면은 실제 쿠버네티스 없으면 어떻게 하느냐.
내가 이  IP address를 기준으로 해서 저 서버에 접속해서 뭔가를 관리하고 이  IP address를 통해서 저 서버에 관리를 하고, 그러다 보면은 이게 서버가 몇 대 없을 땐 괜찮아요.
근데 서버가 더 많아 졌네. 그러면 어떻게 될까요?
관리하기 굉장히 불편해 집니다.
실제로 저 같은 경우도 현업에서 한 십년 넘게 개발 활동을 하면서 이 서버 관련돼서 배포가 되는 그 운영될 관리가 되는 배포 그 서버들이 한 백 대가 넘었습니다.
그러다 보니까 굉장히 헷갈렸어요.
그러니까 예를 들어서 제가 실수했던 게 부산에 있는 서버인데 제가 실수로 잘못 접속을 해가지고 그 부산에 있는 서버를 꺼 버린 거예요.
그래서 어쩔 수 없이 부산에 있는 서버 까지 가서 관리를 해야 될 수밖에 없는 상황이 벌어진 적도 있었습니다.
물론 잠깐 갔다가 올라온 거지만 이런 식으로 각각의  IP address를 엑셀 에다가 막 적어 가면서 각각 접속해 가지고 관리한다는 게 굉장히 불편한 일이거든요.
그리고 누군가가 새로 들어올 수도 있고 이직 되고 바뀌고 이러다 보면 관리하기가 굉장히 어렵습니다.
그러면 쿠버네티스를 쓰면 뭐가 좋은 거냐, 이 기능을  묶어서 관리할 수 있도록 도와줘요.
처음에는 좀 설정이 필요하죠.
왜냐하면 서버들도 서버들만의 특징이 있을 수 있는 거고요.
그리고 그 서버들이 늘어날 수도 있고 줄어들 수도 있기 때문에 그때마다 어느 정도 설정을 해 주긴 해야 됩니다.
하지만 쿠버네티스 에다가 어느 정도 설정 만 해 놓으면 그 설정 대로 묶어서 관리를 할 수 있겠고요.
이 클러스팅 이라는 게 사실상 논리적으로 여러 개의 물리 서버들이 하나의 풀로 관리가 되는 거예요.
하나의 큰 컴퓨터 한 대 처럼 관리가 됩니다.
그렇기 때문에 각각의 서버에 접속해서 볼 필요성이 없다라는 얘기를 할 수 있습니다.

자 두 번째입니다.
실행될 서버를 선택하는 거 계속 말씀드리지만 쿠버네티스가 없을 때에도 이런 것들은 계속 필요했어요.
실행될 서버를 선택한다 이게 뭔 말일까요.
그러니까 내가 실행 되려고 하는 프로세스들이 다양한 특징들을 가질 수 있습니다.
예를 들어서 GPU 에서 실행 돼야 되는 어떤 프로세스 있을 수도 있고요.
인공지능 관련된 프로세스도 있고 스토리지 중심적인 서버에 실행될 수도 있고 CPU 를 많이 써야 되는 프로세스 여서 이쪽에다가 배치가 돼야 될 수도 있어요. 근데 또 어떤 프로세스는 어디에 배치 되든 상관없어 라는 프로세스 들도 있고 있을 거고요.
어떤 프로세스는 꼭 GPU 에만 GPU 서버에만 실행 돼야 되는 프로세스가 있을 수도 있습니다.
되게 다양한 경우일 수가 있는데 그 규칙과 어떤 메뉴얼에 따라서 이제 서버 관리자가 배치를 한다라고 하지만 그리고 나름대로 스크립트를 만들어서 한다고는 하지만 서버가 굉장히 많아지고 그런 것들을 어쨌든 사람이 관리를 하기 때문에 1년 365일 항상 일정하게 관리한다는 게 쉽지가 않아요.
그리고 이런 실수가 발생할 수도 있죠.
어떤 특정 프로세스가 원래 구동 시켜야 되는 서버가 아니라 다른 서버의 구동이 될 수도 있고요.
그리고 무엇보다도 실수를 하지 않는다고 하더라도 서버에 대한 어떤 가동률이 라고 해야 되나 효율성 이런 부분들이 조금 떨어질 수 있습니다.
예를 들어 서 1년 365일 봤을 때 어떤 서버는 80%의 활용이 있었는데 어떤 서버 들은 50%에 지나지 않는다던가 40%에 지나지 않는다던가 이런 게 좀 효율적으로 관리가 안 되고 있는 거죠.
왜냐 서버 관리자가 모든 것들을 생각하면서 구동을 시켜야 되기 때문입니다.
자, 이런 부분들을 아무리 관리자에게 규칙과 어떤 메뉴얼 이런 것들을 철저하게 제공을 한다고 하더라도 이런 부분들이 사람이하기 때문에 한계가 있어요.
물론 스크립트를 한다고 하더라도 서버도 늘어날 수 있고 줄어들 수도 있고 프로세스 도 늘어날 수도 있고 줄어들 수도 있는 상황에서 이거를 그때 그때 항상 메뉴얼에 맞춰서 최적의 상황을 선택해서 한다라는 게 쉽지가 않습니다.
그러기 때문에 쿠버네티스를 쓸 수가 있는 거예요.
쿠버네티스를 쓰게 되면요 관리자가 일단 설정을 해야겠죠.
어떤 프로세스는 GPU 에 무조건 돌아야 돼.
어떤 프로세스는 GPU 에 돌 수는 있는데 안 되면 스토리지에 돌면 돼 어떤 프로세스는 택이 어디든 돌아도 돼 이런 식으로 여러 가지 조건들을 설정할 수도 있고요.
그런 것들을 보통 Affinity 라는 표현을 좀 쓸 수 있어요.
근데 그런 것들을 할 수도 있고, 뭐 아니면은 그냥 저절로 골고루 배치를 할 수가 있습니다.
그래서 이런 부분으로 설정을 어쨌든 해 두게 되면 실행될 서버를 선택을 할 수 있다라는 게 굉장히 큰 강점을 가지고 있어요.
이거를 전문용어로는 스케줄링 이라고 표현을 할 수 있습니다.

자 그 다음에 세 번째 로드 밸런스 입니다.
트래픽이 온다라는 거는 뭐냐면 우리가 www.naver.com, www.google.com 다양한 웹 사이트들이 있잖아요.
우리가 관리하는 웹사이트는 아니지만 이런 것들도 결국에 웹 서버가 있어요.
그리고 그 웹 서버에 이런 트래픽이 왔을 때 고객들이 접속을 했을 때 이게 적절하게 분배가 돼야 됩니다.
그러면 이 분배를 어떻게 시킬까요?
서버 관리자가 그러니까 시스템 엔지니어에 해당되는 부분 그 이제 역할을 하고 있는 엔지니어가 이 로드 밸런스에 대한 어떤 설정들을 할 수 있습니다.
그리고 그 설정들을 직접 지정을 해야겠죠.
근데 이때 문제가 뭐냐면요 이 프로세스들이 늘어날 수 있어요.
처리하는 프로세스들이 늘어날 수도 있고 웹 서버가 뭐 늘어날 수도 있고 또 로드가 늘어날 수도 있고요.
그러니까 서버가 늘어날 수도 있고요. 줄어들 수도 있고요.
이런 여러 가지 상황들이 발생할 수 있습니다.
그때마다 로드 밸런스 설정을 그 서버 관리자가 직접 계속 해야 되는 상황이 벌어질 수가 있죠.
만약에 그렇게 안 한다면 계속 비효율적인 상황으로 서버 관리가 될 수 밖에 없는 거를 우리가 또 이해할 수가 있습니다.
자, 그렇다면 쿠버네티스를 쓰면 뭐가 좋을까요?
쿠버네티스 쓰게 되면 기본적으로 일단 클러스터 링이 되어 있죠.
그래서 우리가 관리하고자 하는 서버가 만약에 세대 라면 그 세대가 다 묶여 져서 하나의 풀 처럼 관리가 되고요.
그래서 여기 보이는 파란색 들이 다 복제본 이라고 보시면 돼요.
여기에 빨간색 들이 다 복제본 이라고 보면 되는데 같은 프로세스를 지침에서 한 번 표현을 해 봤습니다.
근데 같은 프로세스 라고 하더라도 서버에 적절하게 나눠져서 지금 구동되는 있는 거를 보실 수가 있겠죠.
어느 서버에 구동 되고 있는지는 사실 크게 중요하지 않아요.
왜냐하면 쿠버네티스 입장에서는 이걸 다 묶어서 관리를 하는 거고 적절하게 분배를 할 뿐이기 때문에 그리고 어떤 규약에 있다면 규약을 지켜서 분배를 할 뿐이기 때문에 우리는 논리적으로 하나의 큰 서버가 있다 이런 식으로 관리할 수 있는 거죠.
그렇기 때문에 굉장히 쉽게 관리할 수 있습니다.
왜냐하면 서버가 늘어나도 되고 줄어들어 돼요.
쿠버네티스가 우리의 규약에 맞춰서 다 분배를 할 거기 때문에.
이런 식으로 일단 지정이 되어 있는 상태인데 이때 만약에 트래픽이 들어오면 이 트래픽 처리해야 되는 프로세스에게 적절하게 분배를 해 줍니다.
그거를 또 쿠버네티스가 자체적으로 할 수가 있겠고요.
그리고 이 분배가 예를 들어서 다른 컨테이너로 실행이 되는 이런 식으로 또 분배가 될 수 있겠죠.
그래서 이 컨테이너가 한 쪽 서버에 몰빵 돼 있는 게 아니라 컨테이너를 쿠버네티스가 적절하게 분배를 해놨기 때문에 서버들마다 나눠 가지고 로드를 밸런스 을 시킬 수가 있다라는 거를 이해할 수가 있어요.

그 다음에 스케일 아웃 인도 한 번 말씀드리도록 하겠습니다.
이거는 사실 아까 전에 명령어를 통해서 살짝 증명을 해 봤던 부분인데요.
자 보시게 되면은 쿠버네티스를 써서 스케일 아웃 하고 인을 한다는게 도대체 뭔 말이냐?
쿠버네티스를 쓴다라는 거는 계속 말씀드리고 있지만 우리가 서버 관리를 수작업으로 하는 게 아니라 쿠버네티스에 설정을 해두면 쿠버네티스로 자동화 돼서 좀 뭔가 한다는 겁니다. 설정 까지도 안 했는데 알아서 하는 건 아니에요.
설정을 해 놔야 돼요. 그래서 우리가 설정을 할 수 있어요.
어떤 프로세스들을 서버에 실행 시킬 거야.
근데 그런 그룹이 있을 수 있는 거고 그런 것들이 어느 서버에 구동 되는지는 사실 그렇게 중요한 게 아니죠.
왜?
왜냐하면 우리는 클러스터 링 돼서 하나의 큰 풀에다가 구동을 시킬 거고 그게 적절하게 분배 되는지는 쿠버네티스를 통해서 하기 때문에 우리가 일일이 하나의 IP address 씩 접근해 가면서 밸런스를 맞추거나 활용률을 맞출 필요는 없는 거죠.
그래서 어쨌든 이런 식으로 각각의 특성에 맞는 프로세스 들이 묶음으로 관리가 될 수가 있는데요.
이 친구들이 늘어날 수도 있고 줄어들 수도 있어요.
예를 들어서 늘어나게 되면은 스케일 아웃이라는 해서 여러 개의 컨테이너들을 쿠버네티스가 늘릴 수가 있고요.
그러면 어디나 늘릴 지 뭐 이런 것들에 대해서 일일이 생각할 필요가 없고 그 각각 서버 마다 IP address로 SC 에 접속해서 엑셀 보면서 여기 실수 안 하면서 그럴 필요가 없다라는 거예요.
그리고 그런 것들이 서버가 많으면 거의 밤새 해야 됩니다.
근데 이런 것들을 적절하게 주기 때문에 스케일 아웃 에 대한 부분들도 명쾌하게 관리가 될 수가 있겠고요.
그리고 다시 스케일 인을 통해서 제거를 하는 과정, 그러니까 줄이는 과정, 예를 들어서 수강 신청 서버라고 하면 수강 신청할 때는 굉장히 스케일 아웃이 필요할 수 있을 거고요.
수강 신청 기간이 끝났으면 이 노드를 줄일 수도 있지만 컨테이너를 줄인다고 했을 때 스킬 인 작업이 있을 수 있어요.
그러면 어느 서버에 무슨 프로세스를 좀 줄일 지에 대한 선택을 각각의 서버에 들어가서 하는 게 아니라 쿠버네티스를 통해서 하기 때문에 굉장히 편리하게 할 수 있다라는 게 굉장히 맹점이라고 말씀드릴 수 있습니다.

마지막으로 컨테이너 배포 랑 복구 한 번 말씀을 들으면 들어보도록 하겠습니다.
우리가 전문 용어로는 롤 아웃 이랑 롤 백이라는 용어를 또 쓰기도 하는데요.
이게 무슨 말이냐면
우리가 버전 1.0을 출시를 했다. 버전 1.1을 출시를 했다.
이럴 때마다 적절하게 컨테이너들이 분배가 돼서 배포가 될 수가 있어요.
어쨌든 묶음으로 관리가 되고, 어디에 배포가 될지를 지정을 해서 배포를 또 추가를 할 수도 있고 배포를 진행 할 수 있습니다.
그리고 잘못된 거는 다시 롤 백을 해서 1.1버전이 문제가 있어 그럼 다시 1.0버전으로 롤백 하는 부분들도 명령어 하나로 굉장히 쉽게 진행을 할 수 있기 때문에 관리를 하기가 좋죠.
만약에 그렇게 안 되면 계속 말씀드리지만 서버마다 또 들어가서 뭐가 진행 중이고 다시 그거를 전 버전으로 바꿔서 실행하고 굉장히 힘든 일이 벌어지는데 그런 것들을 쉽게 관리할 수 있도록 하는 거죠.
무엇보다도 구동 중이다, 문제가 생겼을 때를 말씀 드려보도록 할게요.
저 같은 경우도 서버 관리를 수작업으로 했던 사람으로서 문제가 생기면 자다가도 전화를 봐야 되는 받아야 되는 경우들도 있어요.
그리고 지하철을 가다가 이 핸드폰으로 터미널 접속해 가지고 문제 해결해야 되는게 도 많이 있었습니다.
굉장히 힘든데요. 이 쿠버네티스를 통하게 되면은 문제 상황이 발생을 했을 때 이거를 장애를 기본적으로 대응할 수 있어요.
물론 이 웹 서버 자체가 웹 개발자가 완전히 잘못해서 문제가 있는 거면 죽고 다시 살고 죽고 다시 살고 이게 반복 되기는 하겠지만 기본적으로 비정상적인 상황에서 예외적으로 죽은 거면은 쿠버네티스가 감지하고 있다가 다시 되살립니다.

자, 조금 디테일하게 설명도 조금 하나 하나 드려보고 실습 명령으로 한 번 말씀을 좀 드려 봤는데요.
더 많은 어떤 쿠버네티스에 대한 어떤 이제 교육이라든지 그런 자료들이 또 필요하시다면 리얼리눅스 안에 쿠버네티스교육이 또 따로 있고요.
그리고 네트워크 관련돼서 쿠버네티스를 또 많이 다루기도 해요
네트워크 완전정복 수업도 있기 때문에 혹시 관심 있으시면은 그런 내용도 함께 보셔도 좋을 것 같아요.
자 요렇게 해서 일단 쿠버네티스 관련된 설명을 한 번 마무리를 줘 봤습니다.
감사합니다.

도커/쿠버네티스 기초 :https://reallinux.co.kr/course/se_docker
도커/K8s/클라우드(AWS) 네트워크 완전 정복 : https://reallinux.co.kr/course/se_network