WEBVTT

00:00:00.000 --> 00:00:04.240
오늘은 거의 모두가 드러낸 받지만 설명은 하기 어려운 것, 바로 쿠버네티스에 대해 이야기해보겠습니다.

00:00:04.520 --> 00:00:08.340
이것이 혼란스러운 이유는 대부분의 사람들이 직접 부딪히기 전까지는 알지 못하는 문제를 해결하기 때문입니다.

00:00:08.500 --> 00:00:11.940
모두가 중요하다는 건 알지만, 무엇을 하는지 물어보면 다들 멍하니 쳐다보기 일쑤죠.

00:00:12.120 --> 00:00:15.820
사람들이 흔히 추측하는 것처럼 도커를 대체하는 것이나 클라우드 운영체제는 아닙니다.

00:00:15.980 --> 00:00:20.420
쿠버네티스는 직면하기 전까지는 존재조차 모르는 문제를 해결하기 때문에 혼란스러울 수밖에 없습니다.

00:00:20.700 --> 00:00:24.480
이 도구는 관리해야 할 컨테이너가 몇 개를 넘어설 때 비로소 필수적인 존재가 됩니다.

00:00:24.480 --> 00:00:33.960
이번 에피소드를 끝낼 때쯤이면 여러분은 쿠버네티스가 정확히 무엇인지, 컨테이너와는 어떻게 조화를 이루는지, 그리고 왜 A저 키버넷 서비스가 밑바닥부터 모든 것을 구축하고 싶지 않은 팀에게 실용적인 선택지인지 이해하게 될 겁니다.

00:00:34.120 --> 00:00:36.540
커피 한 잔 준비하시고 본격적으로 시작해보죠.

00:00:36.680 --> 00:00:39.640
컨테이너 이전의 문제들, 그 문제로 다시 돌아가 보겠습니다.

00:00:39.960 --> 00:00:41.780
10년 전이 소프트웨어 회사를 떠올려 보세요.

00:00:42.060 --> 00:00:46.420
실행할 애플리케이션이 몇 개 있으면 서버를 사고, 운영체제를 설치하고, 모든 것을 수동으로 배포해야 했습니다.

00:00:46.680 --> 00:00:50.020
각 앱은 전용기기를 할당받았고, 그들 사이에 자원을 공유할 수는 없었습니다.

00:00:50.020 --> 00:00:54.900
한 앱은 많은 메모리가 필요하고, 다른 앱은 거의 사용하지 않아도, 어쨌든 각자 자신만의 서버를 가졌죠.

00:00:55.020 --> 00:00:56.120
낭비가 엄청났습니다.

00:00:56.380 --> 00:01:02.440
서버는 아마 20%의 용량만 사용하며 돌아갔지만, 애플리케이션 간 의존성 문제로 인해 서버를 통합할 수도 없었습니다.

00:01:02.720 --> 00:01:08.960
결국 서버실은 거의 일도 안 하면서 전력과 냉방비만 잡아먹는 서버들로 가득 찼고, 모두 끊임없는 유지보수가 필요했습니다.

00:01:09.260 --> 00:01:12.360
한 앱은 파이썬 3.7이 필요하고, 다른 앱은 파이썬 3.8이 필요합니다.

00:01:12.560 --> 00:01:15.040
하나는 이전 라이브러리가 필요하고, 다른 하나는 최신 버전이 필요하죠.

00:01:15.040 --> 00:01:20.360
무언가를 망가뜨리지 않고는 같은 기기에서 실행할 수 없었기에, 결국 서버를 더 구매하고 대부분 놀고 있는 하드웨어에 비용을 지불해야 했습니다.

00:01:20.580 --> 00:01:25.060
가상 머신은 물리적 서버를 더 작은 단위로 쪼개어 각각 OS를 실행하게 함으로써 조금 도움이 되었지만,

00:01:25.580 --> 00:01:30.040
각 VM은 전체 OS를 포함해 무겁고, 디스크 공간과 메모리를 차지하며 시작하는 데 몇 분씩 걸렸습니다.

00:01:30.720 --> 00:01:33.720
게다가 각각 따로 구성해야 했으니 정말 많은 일이 필요했죠.

00:01:33.860 --> 00:01:38.260
여전히 그 모든 운영체제를 관리하고, 패치하고, 업데이트하고, 보안을 유지해야 했습니다.

00:01:38.520 --> 00:01:41.180
팀들은 더 가볍고 이식성이 뛰어난 것이 필요했습니다.

00:01:41.180 --> 00:01:45.720
전체 가상 머신의 오버헤드 없이 애플리케이션을 실행해 필요한 모든 것과 함께 패키징하고,

00:01:46.160 --> 00:01:49.880
기기 간에 쉽게 이동할 수 있는 방법 이어, 거기에 컨테이너가 등장했습니다.

00:01:50.260 --> 00:01:51.500
컨테이너란 무엇인가?

00:01:51.740 --> 00:01:55.900
컨테이너는 애플리케이션과 실행해 필요한 모든 것을 포함하는 작은 패키지입니다.

00:01:56.120 --> 00:02:00.600
즉, 코드, 런타임, 라이브러리, 설정 파일이 하나의 단위로 묶여있다는 뜻이죠.

00:02:00.800 --> 00:02:03.400
소프트웨어를 위한 선박용 컨테이너라고 생각하시면 됩니다.

00:02:03.660 --> 00:02:08.360
해온 컨테이너는 트럭, 기차, 선박 어디에나 실을 수 있으며, 컨테이너 자체는 그대로 유지됩니다.

00:02:08.360 --> 00:02:10.900
소프트웨어 컨테이너도 같은 방식으로 작동합니다.

00:02:11.060 --> 00:02:15.620
한 번 빌드하면 노트북, 테스트 서버, 운영 환경 어디에 써든 동일하게 실행됩니다.

00:02:15.820 --> 00:02:18.940
컨테이너와 가상 머신의 핵심적인 차이는 효율성에 있습니다.

00:02:19.240 --> 00:02:21.360
가상 머신은 자체적인 전체 운영체제를 실행함으로,

00:02:21.720 --> 00:02:24.720
각 VM마다 고유 한 커널, 시스템 파일 등 모든 것을 갖추고 있습니다.

00:02:24.940 --> 00:02:27.160
반면 컨테이너는 호스트 운영체제를 공유합니다.

00:02:27.380 --> 00:02:30.360
컨테이너는 그저 자신만의 격리된 시각을 가진 프로세스일 뿐입니다.

00:02:30.560 --> 00:02:33.180
즉, 컨테이너는 몇 분이 아니라 몇 초 만에 시작됩니다.

00:02:33.180 --> 00:02:36.600
메모리를 적게 사용함으로 단일 장비에 더 많이 탑재할 수 있습니다.

00:02:36.820 --> 00:02:41.800
도커는 개발자가 단일 명령어로 컨테이너를 빌드하고 실행하는 간단한 방법을 제공하여 컨테이너를 대중화했습니다.

00:02:42.060 --> 00:02:45.500
갑자기, 내 컴퓨터에서는 잘 되는데, 라는 문제가 사라지기 시작했습니다.

00:02:45.760 --> 00:02:49.440
노트북에서 컨테이너로 실행되는 애플리케이션은 서버에서도 동일하게 실행됩니다.

00:02:49.640 --> 00:02:51.400
어디에서나 일관된 환경이 유지됩니다.

00:02:51.620 --> 00:02:54.540
하지만 컨테이너는 하나의 문제를 해결하는 동시에 다른 문제를 만들어냅니다.

00:02:54.740 --> 00:02:57.080
컨테이너가 몇 개일 때는 수동관리로도 충분합니다.

00:02:57.320 --> 00:02:59.900
직접 시작하고 중지하며 상태를 추적할 수 있기 때문입니다.

00:02:59.900 --> 00:03:02.240
하지만 수백 개의 컨테이너가 있다면 어떻게 될까요?

00:03:02.360 --> 00:03:07.880
어떤 서버에서 어떤 컨테이너를 실행할지 결정하고, 실패한 컨테이너를 재시작하고, 서로 연결하며 트래픽 급증 시 규모를 확장해야 합니다.

00:03:08.040 --> 00:03:11.060
그것은 새로운 도전 과제이며, 바로 이 지점에서 쿠버네티스가 등장합니다.

00:03:11.320 --> 00:03:12.820
오케스트레이션 문제라는 것이죠.

00:03:12.980 --> 00:03:17.060
컨테이너가 잘 작동하고 애플리케이션을 패키징했으며, 어디서나 일관되게 실행되니 모든 것이 순조롭습니다.

00:03:17.220 --> 00:03:18.600
하지만 그것도 잠시뿐입니다.

00:03:18.820 --> 00:03:21.360
10개에서 20개의 컨테이너라면 수동으로 관리할 수 있습니다.

00:03:21.360 --> 00:03:26.320
어떤 서버에 어떤 컨테이너가 있는지 알고, 충돌 시 재시작할 수 있으며, 이따금 업데이트도 가능하니까요.

00:03:26.440 --> 00:03:27.540
관리 가능한 수준입니다.

00:03:27.760 --> 00:03:29.680
하지만 애플리케이션이 커지면 상황이 달라집니다.

00:03:29.840 --> 00:03:31.340
마이크로 서비스로 전환하게 되죠.

00:03:31.500 --> 00:03:34.380
하나의 거대한 애플리케이션 대신 20개의 작은 애플리케이션을 갖게 됩니다.

00:03:34.600 --> 00:03:38.920
신뢰성을 위해 각 애플리케이션마다 여러 복제본이 필요해지면, 이제 200개의 컨테이너를 마주하게 됩니다.

00:03:39.140 --> 00:03:40.860
더 이상 수동 관리로는 불가능합니다.

00:03:41.120 --> 00:03:46.740
어떤 서버에서 각 컨테이너를 실행할지 결정하고, 실패시 재시작하며, 서로 통신할 수 있도록 연결해야 합니다.

00:03:46.740 --> 00:03:52.960
또한 할인 행사나 제품 출시 등으로 트래픽이 급증할 때 규모를 늘리고, 잠잠해지면 다시 줄여야 합니다.

00:03:53.100 --> 00:04:00.360
또한 중단 없이 업데이트를 배포해야 하는데, 이는 기존 컨테이너를 하나씩 조심스럽게 새 컨테이너로 교체하여 아무것도 깨뜨리지 않아야 함을 의미합니다.

00:04:00.540 --> 00:04:04.720
이러한 문제들이 바로 오케스트레이션 문제이며, 쿠버네티스는 이를 해결하기 위해 탄생했습니다.

00:04:04.920 --> 00:04:10.060
쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 플랫폼입니다.

00:04:10.260 --> 00:04:12.620
데이터 센터를 위한 운영체제라고 생각하면 됩니다.

00:04:12.620 --> 00:04:20.220
윈도우 나 리눅스가 단일 컴퓨터의 CPU, 메모리, 디스크 같은 자원을 관리하듯, 쿠버네티스는 모든 서버의 자원을 관리합니다.

00:04:20.400 --> 00:04:23.760
쿠버네티스는 모든 머신을 하나의 거대한 컴퓨팅 파워풀로 취급합니다.

00:04:23.960 --> 00:04:29.120
실행할 것을 알려주기만 하면, 어디에 배치할지, 어떻게 계속 실행할지, 어떻게 다른 것들과 연결할지를 알아서 처리합니다.

00:04:29.280 --> 00:04:32.220
핵심 개념, 파드, 핫, 노드, 노드, 그리고 클러스터, 클러스터.

00:04:32.360 --> 00:04:34.440
쿠버네티스가 실제로 어떻게 작동하는지 살펴보겠습니다.

00:04:34.860 --> 00:04:36.880
쿠버네티스에서 가장 작은 단위는 파드라고 불립니다.

00:04:36.880 --> 00:04:39.140
파드는 하나 이상의 컨테이너를 감싸는 역할을 합니다.

00:04:39.300 --> 00:04:43.480
같은 파드 내의 컨테이너들은 스토리지와 네트워크를 공유하므로 로컬고스트를 통해 서로 통신할 수 있습니다.

00:04:43.660 --> 00:04:45.660
파드를 단일 배포 단위로 생각할 수 있습니다.

00:04:45.980 --> 00:04:48.260
쿠버네티스에서는 컨테이너를 직접 배포하지 않습니다.

00:04:48.460 --> 00:04:49.540
대신 파드를 배포합니다.

00:04:49.800 --> 00:04:52.260
파드는 스스로 실행되지 않으며 노드 위에서 실행됩니다.

00:04:52.460 --> 00:04:56.080
노드는 쿠버네티스 클러스터의 일부인 물리적 또는 가상 서버를 의미합니다.

00:04:56.280 --> 00:05:00.380
각 노드는 파드를 실행하는 데 필요한 소프트웨어와 곧 설명할 몇 가지 다른 요소들을 실행합니다.

00:05:00.380 --> 00:05:03.920
클러스터는 하나의 통합된 시스템으로 관리되는 모든 노드의 집합입니다.

00:05:04.060 --> 00:05:09.240
간단히 말해 파드는 애플리케이션이고 노드는 그것이 실행되는 곳이며 클러스터는 전체 환경입니다.

00:05:09.380 --> 00:05:10.340
파드는 일시적입니다.

00:05:10.580 --> 00:05:12.700
파드는 언제든지 생성, 삭제 또는 이동될 수 있습니다.

00:05:12.920 --> 00:05:13.880
그것이 설계 위도입니다.

00:05:14.080 --> 00:05:16.320
노드에 문제가 생기면 쿠버네티스는 파드를 다른 노드로 옮깁니다.

00:05:16.480 --> 00:05:18.340
확장이 필요할 때는 새로운 파드를 생성합니다.

00:05:18.560 --> 00:05:20.640
그리고 파드가 중단되면 자동으로 교체됩니다.

00:05:20.880 --> 00:05:22.980
시스템 전체가 파드를 일시적인 것으로 취급합니다.

00:05:23.180 --> 00:05:25.780
하지만 파드가 계속 생성되고 사라진다면 그들과 통신할 방법이 필요합니다.

00:05:25.780 --> 00:05:28.680
파드와 직접 통신하는 대신 서비스, 서비스를 통해 통신합니다.

00:05:28.840 --> 00:05:32.960
서비스는 파드가 변경되더라도 적절한 파드로 트래픽을 라우팅하는 안정적인 네트워크 주소를 제공합니다.

00:05:33.100 --> 00:05:34.100
호텔을 상상해보세요.

00:05:34.380 --> 00:05:36.140
호텔의 전화번호가 바로 서비스입니다.

00:05:36.340 --> 00:05:39.080
객실 투숙객은 계속 바뀌지만 전화번호는 그대로 유지됩니다.

00:05:39.240 --> 00:05:41.780
프런트 데스크에 전화하면 그들이 적절한 방으로 연결해주는 것과 같습니다.

00:05:42.020 --> 00:05:44.220
쿠버네티스의 서비스가 하는 역할도 정확히 이와 같습니다.

00:05:44.560 --> 00:05:48.720
서비스는 현재 애플리케이션을 실행 중인 파드들로 항상 연결되는 고정된 주소를 제공합니다.

00:05:48.720 --> 00:05:53.500
컨트롤 플레인, 클러스터의 두뇌, 자, 이제 파드, 노드, 클러스터에 대해 알게 되었습니다.

00:05:53.700 --> 00:05:55.860
그렇다면 무엇이 어디서 실행될지 결정하는 주체는 누구일까요?

00:05:56.020 --> 00:05:57.460
그것이 바로 컨트롤 플레인의 역할입니다.

00:05:57.640 --> 00:06:00.760
모든 쿠버네티스 클러스터에는 컨트롤 플레인이 있으며 이것이 전체 운영의 두뇌 역할을 합니다.

00:06:00.960 --> 00:06:02.380
모든 결정은 여기서 이루어집니다.

00:06:02.540 --> 00:06:04.300
컨트롤 플레인에는 여러 구성 요소가 있습니다.

00:06:04.560 --> 00:06:07.420
첫 번째는 클러스터의 정문 역할을 하는 API 서버입니다.

00:06:07.660 --> 00:06:13.620
명령줄, 대시보드, 자동화된 스크립트 등 키버넷으로 보내는 모든 명령은 API 서버를 통과합니다.

00:06:13.620 --> 00:06:18.520
요청을 인증하고 허용된 작업인지 확인한 다음 적절한 곳으로 전달합니다.

00:06:18.700 --> 00:06:22.600
API 서버를 거치지 않고는 키버넷에서 아무 일도 일어나지 않습니다.

00:06:22.820 --> 00:06:25.800
다음은 각 파드를 실행할 노드를 결정하는 스케줄러입니다.

00:06:26.040 --> 00:06:28.060
이 애플리케이션을 실행하고 싶다, 고 말하면

00:06:28.060 --> 00:06:35.260
스케줄러는 사용 가능한 모든 노드를 살펴보고 CPU, 메모리, 디스크 공간 등 가용 자원을 확인하여 작업에 가장 적합한 노드를 선택합니다.

00:06:35.440 --> 00:06:38.640
마치 호텔 매니저가 투숙객에 필요에 따라 객실을 배정하는 것과 같습니다.

00:06:38.640 --> 00:06:43.880
짐이 많은 손님에게는 더 큰 방을 배정하고, 가벼운 애플리케이션은 여유 공간이 있는 작은 노드에 배치합니다.

00:06:44.060 --> 00:06:45.580
그 다음은 컨트롤러 매니저입니다.

00:06:45.820 --> 00:06:49.780
이 구성 요소는 클러스터를 감시하며 실제 상태가 사용자가 선언한 상태와 일치하는지 확인합니다.

00:06:49.940 --> 00:06:52.600
웹앱의 복제본 3개를 실행하겠다고 선언했다고 가정해봅시다.

00:06:52.760 --> 00:06:55.640
컨트롤러 매니저는 실제로 3개의 복제본이 실행 중인지 확인합니다.

00:06:55.820 --> 00:06:58.500
하나가 중단되면 이를 감지하고 대체 인스터스를 시작합니다.

00:06:58.720 --> 00:07:01.500
누군가 실수로 파드를 삭제하면 즉시 새로운 파드를 생성합니다.

00:07:01.720 --> 00:07:04.120
클러스터의 상태를 올바르게 유지해주는 구성 요소입니다.

00:07:04.120 --> 00:07:07.000
마지막으로 클러스터의 데이터베이스인 etcd가 있습니다.

00:07:07.300 --> 00:07:11.020
무엇이 실행 중인지, 어디에서 실행 중인지, 어떻게 구성되었는지 등 모든 것을 저장합니다.

00:07:11.180 --> 00:07:13.880
클러스터 전체의 진실의 원천, 소스 오브 트로스입니다.

00:07:14.100 --> 00:07:18.840
api 서버가 정문이라면 etcd는 모든 기록이 보관된 사무실 뒤편의 캐비닉과 같습니다.

00:07:19.160 --> 00:07:23.560
이 설계의 아름다움은 당신이 원하는 것을 설명하면 퀴버넷과 이를 구현하는 방법을 알아서 처리한다는 점입니다.

00:07:23.740 --> 00:07:27.180
어떻게 해야 하는지 지시하는 것이 아니라 최종 결과물이 어떠해야 하는지 알려주는 것입니다.

00:07:27.380 --> 00:07:31.080
이것이 선언적 모델이며 퀴버넷과 수행하는 모든 작업의 핵심 아이디어입니다.

00:07:31.080 --> 00:07:34.100
워크로드, 배포, 서비스, 그리고 스케일링입니다.

00:07:34.260 --> 00:07:37.340
이제 퀴버넷에서 애플리케이션을 실제로 어떻게 실행하는지 이야기해봅시다.

00:07:37.480 --> 00:07:39.060
파드를 직접 만들지는 않을 것입니다.

00:07:39.240 --> 00:07:42.240
대신 배포, 디플로이먼트라는 더 높은 수준의 객체를 사용하게 됩니다.

00:07:42.420 --> 00:07:46.300
배포는 퀴버넷에게 파드 복제본을 몇 개 실행할지, 어떤 컨테이너 이미지를 사용할지,

00:07:46.640 --> 00:07:49.500
새 버전이 나올 때 어떻게 업데이트할지 알려주는 관리자라고 생각하세요.

00:07:49.720 --> 00:07:52.800
상태 비저장, 스테이틀러스, 애플리케이션을 실행하는 표준 방식입니다.

00:07:52.800 --> 00:07:57.400
배포를 업데이트할 때, 즉 앱의 새 버전을 푸시하면 퀴버넷는 롤링 업데이트를 수행합니다.

00:07:57.560 --> 00:08:00.940
포드를 하나씩 교체하여 최소한 하나의 복제본은 항상 실행되도록 보장합니다.

00:08:01.140 --> 00:08:04.380
즉, 사용자에게 가동 중지 시간이나 갑작스러운 중단이 발생하지 않습니다.

00:08:04.580 --> 00:08:08.400
새 버전에 문제가 생기, 더라도 명령어 한 번으로 이전 버전으로 되돌릴 수 있습니다.

00:08:08.660 --> 00:08:10.140
매우 강력한 안전망인 셈이죠.

00:08:10.360 --> 00:08:12.320
하지만 포드는 여전히 연결 가능한 상태여야 합니다.

00:08:12.500 --> 00:08:14.300
바로 이때 서비스, 서비스가 필요합니다.

00:08:14.540 --> 00:08:17.880
서비스는 트래픽을 올바른 포드로 전달하는 안정적인 네트워크 주소를 제공합니다.

00:08:17.880 --> 00:08:22.160
또한 이러한 포드를 애플리케이션의 다른 부분이나 외부 세계에 노출할 수도 있습니다.

00:08:22.380 --> 00:08:24.940
서비스는 클러스터 내부에서만 접근 가능한 내부용이거나,

00:08:25.400 --> 00:08:29.080
사용자가 인터넷을 통해 접근할 수 있는 공용 IP 주소를 가진 외부용일 수 있습니다.

00:08:29.280 --> 00:08:31.060
이제 확장성에 대해 이야기해보겠습니다.

00:08:31.400 --> 00:08:34.940
쿠버네티스는 수요에 따라 애플리케이션을 자동으로 확장하거나 축소할 수 있습니다.

00:08:35.160 --> 00:08:37.600
예를 들어 CPU 사용률 70%를 목표로 설정하면,

00:08:38.000 --> 00:08:41.980
쿠버네티스는 사용량이 그 임계값을 초과할 때 포드를 추가하고, 낮아지면 제거합니다.

00:08:42.320 --> 00:08:46.240
애플리케이션은 트래픽이 급증할 때 확장되고, 트래픽이 줄어들면 다시 축소됩니다.

00:08:46.420 --> 00:08:47.880
수동 개입은 필요하지 않습니다.

00:08:48.120 --> 00:08:50.260
하지만 이 모든 강력한 기능에는 복잡함이 따릅니다.

00:08:50.480 --> 00:08:55.700
직접 쿠버네티스 클러스터를 운영한다는 것은 컨트롤 플레인, 업그레이드, 보안 패치, 백업을 직접 책임져야 함을 의미합니다.

00:08:55.860 --> 00:09:00.060
노드 장애, 네트워크 구성, 클러스터 확장을 처리하려면 깊은 전문 지식이 필요합니다.

00:09:00.260 --> 00:09:03.660
많은 팀이 애플리케이션을 구축하는 시간보다 클러스터를 관리하는 데 더 많은 시간을 보냅니다.

00:09:03.840 --> 00:09:05.940
바로 여기서 관리형 쿠버네티스가 등장합니다.

00:09:05.940 --> 00:09:08.480
직접 관리형과 관리형 쿠버네티스의 비교입니다.

00:09:08.640 --> 00:09:11.440
그럼 쿠버네티스를 직접 운영하는 현실에 대해 이야기해봅시다.

00:09:11.600 --> 00:09:17.400
직접 클러스터를 설정하면 컨트롤 플레인, 업그레이드, 보안 패치, ETCD 백업 등 모든 것을 책임져야 합니다.

00:09:17.600 --> 00:09:20.480
API 서버가 중단되면 그것은 여러분의 문제입니다.

00:09:20.680 --> 00:09:24.280
사용 중인 버전의 보안 취약점이 발견되면 직접 패치해야 합니다.

00:09:24.520 --> 00:09:27.060
ETCD가 손상되면 백업에서 복원해야 합니다.

00:09:27.320 --> 00:09:29.500
이 모든 과정에는 깊은 전문 지식이 필요합니다.

00:09:29.720 --> 00:09:32.480
노드가 어떻게 실패하는지, 클러스터 수준에서 네트워킹이 어떻게 작동하는지,

00:09:32.480 --> 00:09:34.880
그리고 시스템을 중단시키지 않고 어떻게 확장하는지 이해해야 합니다.

00:09:35.020 --> 00:09:36.560
많은 팀이 놀라는 사실이 있습니다.

00:09:36.840 --> 00:09:39.400
많은 조직이 클러스터에서 실행되는 애플리케이션을 구축하는 것보다

00:09:39.400 --> 00:09:41.940
쿠버네티스 클러스터를 관리하는데 더 많은 시간을 소비합니다.

00:09:42.140 --> 00:09:46.060
그들은 끊임없이 업그레이드와 실험하고 네트워크 문제를 해결하며 노드 장애를 처리합니다.

00:09:46.240 --> 00:09:48.220
클러스터 관리가 풀타임 업무가 되어버리는 것입니다.

00:09:48.420 --> 00:09:50.820
애초에 쿠버네티스를 도입한 이유는 그런 것이 아니었을 겁니다.

00:09:51.040 --> 00:09:53.320
이때 바로 관리형 쿠버네티스 서비스가 필요합니다.

00:09:53.320 --> 00:09:57.620
에이저 퀴버넷 서비스, AKS와 같은 서비스가 컨트롤 플레인을 대신 처리해줍니다.

00:09:57.760 --> 00:10:01.840
에이저는 API 서버, ETCD, 스케줄러, 컨트롤러 관리자를 직접 관리합니다.

00:10:02.020 --> 00:10:04.460
여러분은 패치나 운영 유지에 대해 걱정할 필요가 없습니다.

00:10:04.760 --> 00:10:08.260
실제 워크로드를 실행하는 가상 머신인 워커노드에 대해서만 비용을 지불하면 됩니다.

00:10:08.500 --> 00:10:09.980
제어 평면 자체는 무료입니다.

00:10:10.200 --> 00:10:11.820
이는 상황을 완전히 바꿔놓습니다.

00:10:12.100 --> 00:10:13.880
클러스터 유지 관리에 시간을 쏟는 대신,

00:10:14.300 --> 00:10:17.360
팀은 구축 중인 애플리케이션 등 더 중요한 일에 집중할 수 있습니다.

00:10:17.360 --> 00:10:21.580
대부분의 팀, 특히 이제 막 시작하는 팀에게는 관리형 쿠버네티스가 올바른 선택입니다.

00:10:21.720 --> 00:10:24.740
운영 부담 없이 쿠버네티스 위 모든 강력한 기능을 누릴 수 있습니다.

00:10:24.980 --> 00:10:27.540
AKS, 에이저에서 간편하게 구현하는 쿠버네티스.

00:10:27.680 --> 00:10:29.540
그렇다면 AKS란 정확히 무엇일까요?

00:10:29.720 --> 00:10:31.360
에이저 위 관리형 쿠버네티스 서비스로

00:10:31.360 --> 00:10:34.340
처음부터 구축할 필요 없이 모든 기능을 갖춘 클러스터를 제공합니다.

00:10:34.520 --> 00:10:36.400
앞서 언급했듯이 제어 평면은 무료임으로

00:10:36.400 --> 00:10:39.060
워크로드를 실행하는 가상 머신에 대해서만 비용을 지불합니다.

00:10:39.060 --> 00:10:43.220
즉, 작게 시작하여 비용을 최소화하고 필요에 따라 규모를 확장할 수 있습니다.

00:10:43.460 --> 00:10:45.560
에이저가 모든 복잡한 작업을 처리합니다.

00:10:45.780 --> 00:10:49.880
제어 평면에 대한 업그레이드, 패치, 상태 모니터링이 모두 자동으로 이루어집니다.

00:10:50.040 --> 00:10:53.800
시스템 운영을 위해 쿠버네티스 전문가로 구성된 전담팀이 필요하지 않습니다.

00:10:54.000 --> 00:10:56.380
또한 AKS는 에이저 생태계의 일부임으로

00:10:56.380 --> 00:10:59.160
이미 사용 중일 가능성이 높은 도구들과 통합됩니다.

00:10:59.360 --> 00:11:00.980
인증을 위한 에이저 액티브 디렉토리,

00:11:01.340 --> 00:11:03.080
로깅 및 매트릭을 위한 에이저 모니터,

00:11:03.420 --> 00:11:05.120
거버넌스를 위한 에이저 플리시 가 있습니다.

00:11:05.120 --> 00:11:07.520
이 모든 것이 기본적으로 함께 작동합니다.

00:11:07.680 --> 00:11:09.600
별도의 구성 요소를 덧붙일 필요가 없습니다.

00:11:09.900 --> 00:11:11.900
기터브 액션스 나이저 데북스를 통한 CI,

00:11:12.220 --> 00:11:14.200
CD 파이프 라인 설정은 몇 분이면 충분합니다.

00:11:14.380 --> 00:11:17.440
저장소의 변경 사항을 푸시하면 자동으로 새 컨테이너 이미지가 빌드되고,

00:11:17.780 --> 00:11:19.380
에이저 컨테이너 레지스트리 로 푸시되며,

00:11:19.680 --> 00:11:21.220
AKS 위 배포가 업데이트됩니다.

00:11:21.400 --> 00:11:24.020
수동 단계나 서버에 SSH로 접속할 필요가 없습니다.

00:11:24.320 --> 00:11:25.740
모든 과정이 자동화되어 있습니다.

00:11:26.040 --> 00:11:29.420
초보자를 위해 클러스터 구성에 관한 모든 결정을 내리기 원치 않는 팀을 위한

00:11:29.420 --> 00:11:31.240
AKS 자동 모드가 마련되어 있습니다.

00:11:31.240 --> 00:11:35.380
확장, 네트워킹, 보안 및 업그레이드를 위한 바로 사용할 수 있는 기본값을 제공합니다.

00:11:35.540 --> 00:11:38.000
시작하기 위해 쿠버네티스 전문가가 될 필요는 없습니다.

00:11:38.300 --> 00:11:41.040
애플리케이션을 설명하기만 하면 AKS가 나머지를 처리합니다.

00:11:41.240 --> 00:11:42.600
명령어 하나로 클러스터를 생성하고,

00:11:42.920 --> 00:11:44.900
매니페스트 파일 하나로 애플리케이션을 실행할 수 있습니다.

00:11:45.140 --> 00:11:47.580
AKS에서 익힌 기술은 표준 쿠버네티스를 기반으로 함으로,

00:11:47.720 --> 00:11:49.960
다른 어떤 쿠버네티스 환경에서도 그대로 활용 가능합니다.

00:11:50.100 --> 00:11:51.840
독점적인 시스템을 배우는 것이 아니라,

00:11:52.300 --> 00:11:55.680
에이저가 운영 복잡성을 처리하는 실제 쿠버네티스를 배우는 것입니다.

00:11:55.680 --> 00:11:57.720
이제 큰 그림을 이해하셨을 겁니다.

00:11:57.960 --> 00:12:01.520
컨테이너는 애플리케이션을 패키징하여 어디서나 일관되게 실행되도록 하며,

00:12:01.920 --> 00:12:07.180
쿠버네티스는 해당 컨테이너를 대규모로 오케스트레이션하여 배포, 확장, 복구를 자동으로 처리합니다.

00:12:07.380 --> 00:12:09.220
AKS는 제어 평면을 관리하고,

00:12:09.400 --> 00:12:13.300
이미 알고 있는 에이저 도구와 통합함으로써 이러한 오케스트레이션을 쉽게 만듭니다.

00:12:13.480 --> 00:12:14.440
핵심은 이것입니다.

00:12:14.680 --> 00:12:18.040
쿠버네티스는 거대한 엔지니어링 팀을 둔 대기업만을 위한 것이 아닙니다.

00:12:18.240 --> 00:12:21.680
AKS와 같은 관리형 서비스를 이용하면 어떤 팀이든 이를 활용할 수 있습니다.

00:12:21.940 --> 00:12:23.320
이번 주 숙제는 간단합니다.

00:12:23.320 --> 00:12:28.380
무료 에이저 계정을 만들고, AKS 클러스터를 시작한 뒤, 간단한 애플리케이션을 배포해보세요.

00:12:28.560 --> 00:12:31.540
몇 분이면 충분하며, 플랫폼이 얼마나 발전했는지 알게 되실 겁니다.

00:12:31.780 --> 00:12:33.280
더 깊이 알아볼 준비가 되셨나요?

00:12:33.500 --> 00:12:35.760
다음 에피소드에서는 첫 컨테이너 이미지를 빌드하고,

00:12:35.860 --> 00:12:38.460
에이저 컨테이너 레지스트리 FC하는 방법을 다룹니다.

00:12:38.640 --> 00:12:40.820
즐겨 사용하는 팟캐스트 플랫폼에서 구독하시고,

00:12:41.240 --> 00:12:43.920
쿠버네티스를 막 시작하려는 분들께의 영상을 공유해주세요.