쿠버네티스(Kubernetes) 총정리

1. 쿠버네티스(Kubernetes)의 개념

쿠버네티스는 컨테이너 배포, 컨테이너 스케일링, 디스크 스케일링 및 컨테이너 로드 밸런싱을 자동화하는 오픈 소스 컨테이너 관리 도구다. 컨테이너의 자동 배포 및 확장과 함께 실패한 컨테이너를 자동으로 다시 시작하고, 호스트가 사망하면 다시 일정을 조정하여 회복을 제공한다. 쿠버네티스는 N개의 컨테이너를 쉽게 관리하고, 그것을 배포하기 위해 하나의 논리적 단위로 그룹화할 수 있다. 퍼블릭이건, 하이브리드건, 모든 클라우드 업체와 훌륭하게 작동하기에 각광을 받고 있다. 기업은 쿠버네티스를 통해 애플리케이션의 가용성을 향상할 수 있다.

2. 쿠버네티스 사용의 이점

① 자동화된 구축 및 관리
애플리케이션을 배포하는 데 쿠버네티스를 사용하는 경우 수동으로 개입할 필요가 없으므로 애플리케이션 배포 자동화, 확장 및 컨테이너화와 같은 모든 것을 처리할 수 있다. 본래 인간이라면 결국 업무상 실수를 할 수밖에 없는데, 쿠버네티스를 통하면 그런 오류를 줄여 배포를 더 효과적으로 만들 것이다.

② 확장성
쿠버네티스가 제공하는 들어오는 트래픽에 따라 애플리케이션 컨테이너를 확장할 수 있다. 수평 Pod 확장은 로드에 따라 자동으로 확장된다.

 

③ 고가용성
앞서 말했듯, 쿠버네티스의 도움으로 애플리케이션의 고가용성을 달성할 수 있으며, 최종 사용자의 레이턴시 문제를 줄일 수 있다.

 

④ 가성비
불필요한 인프라 사용이 있는 경우, 비용이 증가하여 자원 활용률을 줄이고 인프라의 과도한 프로비저닝을 제어하는 데 도움이 된다.

⑤ 개발자 생산성 향상
개발자는 개발 부분인 쿠버네티스에 더 집중할 수 있어 애플리케이션을 배포하는 노력을 줄일 수 있다.

3. 쿠버네티스를 통한 컨테이너형 애플리케이션 구축 및 관리

아래의 단계에 따라 컨테이너 형태로 애플리케이션을 배포한다.

1단계: 쿠버네티스를 설치하고, 쿠버네티스 클러스터도 설치한다. 그리고 최소 1개의 마스터 노드와 2개의 작업자 노드가 있어야 한다. 쿠버네티스를 서비스로 제공하는 모든 클라우드에서 쿠버네티스 클러스터를 설정할 수 있을 것이다.

2단계: 배포 매니페스트 파일을 만든다. 필요한 Pod 수를 정확히 지정할 수 있고 매니페스트 파일 작성이 완료된 후 컨테이너 이미지와 필요한 리소스 유형을 지정할 수 있다. 그리고 kubectl 명령을 사용하여 파일을 적용한다.

3단계: Pod를 만든 후 서비스 유형, 포트 및 선택기가 포함된 매니페스트 파일을 하나 더 생성한다.

4. 쿠버네티스와 다른 컨테이너 플랫폼 대조

	배포	확장성	네트워킹	스토리지
쿠버네티스	Kubectl CLI를 사용하여 컨테이너를 배포했으며, 컨테이너에 필요한 모든 구성은 매니페스트에 존재한다.	여러 노드에 걸쳐 Pod를 확장하여 대량의 들어오는 트래픽을 관리할 수 있다.	다양한 유형의 플러그인을 사용하여 유연성을 높일 수 있다.	기존 볼륨 클레임과 같은 여러 스토리지 옵션을 지원하며, 클라우드 기반 스토리지를 연결할 수도 있다.
도커 스웜	컨테이너는 컨테이너 추가에 필요한 모든 구성을 포함하는 도커 생성 파일을 사용하여 배포된다.	컨테이너를 확장할 수 있지만, 쿠버네티스보다 효율적이지는 않다.	사용법이 간단해서 쿠버네츠보다 더 수월하다.	로컬 스토리지를 보다 유연하게 사용할 수 있다.
구글 시프트	매니페스트 또는 오픈 시프트 CLI를 사용하여 컨테이너를 배포할 수 있다.	컨테이너를 확장할 수 있지만, 쿠버네티스보다 효율적이지는 않다.	네트워킹 모델이 특히나 발전한 형태다.	로컬 및 클라우드 스토리지를 지원한다.
노마드	컨테이너를 배포하기 위해서는 HCL 구성 파일이 필요하다.	컨테이너를 확장할 수 있지만, 쿠버네티스보다 효율적이지는 않다.	원하는 플러그인 번호를 통합할 수 있다.	로컬 및 클라우드 스토리지를 지원한다.

 

5. 쿠버네티스의 미래

당장 오늘도 제니퍼소프트가 쿠버네티스 모니터링 솔루션 출시 예고를 한 것에 대한 기사를 봤다. 쿠버네티스는 오픈 당시부터 큰 반향을 일으킨 것으로 기억한다. 지속적으로 업그레이드가 이어지고 있는 도구이기도 하기에 이 상태가 그대로 유지된다면 미래에는 더욱 중요한 역할을 하지 않을까 싶다. 

 

인공지능 기반 자동화 및 자동화 머신러닝, 엣지 컴퓨팅 및 하이브리드 클라우드 환경, 데이터 패브릭 및 데이터 거버넌스, 멀티 클라우드 및 클라우드 네이티브 애플리케이션, 보안 및 컴플리언스 준수, 지속가능성 및 자원최적화 등에 있어 쿠버네티스는 여러 활약을 할 수 있을 것이다.

6. 쿠버네티스의 특징

① 자동화된 스케줄링: 클러스터 노드에서 컨테이너를 시작할 수 있는 고급 스케줄러를 제공한다. 그리고 이를 통해 리소스 최적화를 수행한다.
② 자체 회복 기능:  작동하지 않는 컨테이너의 일정 변경, 교체 및 재시작 기능을 제공한다.
③ 자동화된 롤아웃 및 롤백: 컨테이너화된 애플리케이션의 원하는 상태에 맞게 롤아웃 및 롤백을 지원한다.
④ 수평적 스케일링 및 로드 밸런싱: 요구 사항에 따라 애플리케이션을 확장하고 축소할 수 있다.
⑤ 리소스 활용: 리소스 활용 모니터링 및 최적화를 제공하여 컨테이너가 리소스를 효율적으로 사용할 수 있도록 보장한다.
⑥ 여러 클라우드 및 하이브리드 클라우드 지원: 다양한 클라우드 플랫폼에 구축할 수 있으며 여러 클라우드에서 컨테이너화된 애플리케이션을 실행할 수 있다. 내가 굳이 쿠버네티스를 애플리케이션 항목이 아닌 클라우드 항목에 넣은 것도 이런 이유인 것이다.
⑦ 확장성: 확장성이 매우 뛰어나며 사용자 지정 플러그인 및 컨트롤러로 확장할 수 있다.
⑧ 커뮤니티 지원: 업데이트, 버그 수정 및 새로운 기능이 추가가 활발하며, 매우 크고 활성화된 커뮤니티를 가지고 있다.

7. 쿠버네티스 구성

쿠버네티스는 클라이언트-서버 아키텍처를 따르는데, 여기서 마스터는 하나의 머신에, 노드는 별도의 리눅스 머신에 설치되어 있다. 여기서 마스터를 사용하여 여러 쿠버네티스 노드에 걸쳐 도커 컨테이너를 관리하는 마스터-슬레이브 모델을 따른다. 마스터와 그 제어되는 노드들(작업자 노드)은 쿠버네티스 클러스터를 구성한다. 개발자는 쿠버네티스 마스터의 도움을 받아 도커 컨테이너에 애플리케이션을 배포할 수 있다.

8. 쿠버네티스의 주요 구성요소 - 마스터 노도 구성요소

쿠버네티스 마스터는 전체 클러스터를 관리하고, 클러스터 내부의 모든 활동을 조정하며, 작업자 노드와 통신하여 쿠버네티스와 애플리케이션을 계속 실행한다. 이것이 모든 관리 작업의 시작점이다. 시스템에 쿠버네티스를 설치하면 쿠버네시트의 4가지 주요 구성 요소가 설치된다. 그 구성 요소는 다음과 같다.

① API 서버
API 서버는 클러스터를 제어하는 데 사용되는 모든 REST 명령의 진입점이다. 모든 관리 작업은 마스터 노드 내의 API 서버에서 수행된다. 쿠버네티스 개체를 생성, 삭제, 업데이트 또는 표시하려면 이 API 서버를 거쳐야 한다. API 서버는 포트, 서비스, 복제, 컨트롤러, 배포 등 API 개체를 확인하고 구성하며 모든 작업에 대한 API 노출을 담당한다. 우리는 Kubectl이라는 도구를 사용하여 이러한 API와 상호 작용할 수 있다. Kubectl은 매우 작은 Go 언어 바이너리로, 명령줄에서 발행하는 모든 작업을 수행하기 위해 기본적으로 API 서버와 대화한다. Kubectl은 쿠버네티스 클러스터에 대해 명령을 실행하기 위한 명령줄 인터페이스라고도 할 수 있다.

② 스케줄러
업무량 분배를 담당하는 마스터의 서비스다. 각 작업자 노드의 작업 부하 활용도를 추적한 다음 자원이 가용하고 작업량을 수용할 수 있는 작업량을 배치하는 역할을 한다. 스케줄러는 구성 파일에서 언급한 제약 조건에 따라 사용 가능한 노드에 걸쳐 포드를 스케줄링하고 그에 따라 이러한 포드를 스케줄링한다. 스케줄러는 작업량 활용과 새로운 노드에 포드를 할당하는 역할을 담당한다.

③ 컨트롤러 관리자
그냥 관리자 떼고 컨트롤러라고도 한다. 비종료 루프에서 실행되는 데몬으로 API 서버로 정보를 수집하고 전송하는 역할을 한다. 네임스페이스 생성 및 라이프사이클 이벤트 가비지 컬렉션, 종료 포드 가비지 컬렉션, 삭제된 가비지 컬렉션 캐스케이드, 노드 가비지 컬렉션 등의 라이프스타일 기능을 수행하여 쿠버네티스 클러스터를 조절한다. 기본적으로 클러스터의 현재 상태가 원하는 상태에 부합하지 않을 경우 컨트롤러가 원하는 클러스터의 상태를 감시한 다음 제어 루프가 수정 단계를 수행하여 현재 상태가 원하는 상태와 동일한지 확인한다. 핵심 컨트롤러는 복제 컨트롤러, 엔드포인트 컨트롤러, 네임스페이스 컨트롤러, 서비스 계정 컨트롤러다. 따라서 이러한 방식으로 컨트롤러는 노드가 항상 가동되고 실행되며 사양 파일에 언급된 대로 올바른 포드가 실행되는지 확인하여, 전체 클러스터의 전반적인 상태를 책임진다.

④ etcd

분산형 키-값 경량 데이터베이스다다. 쿠버네티스에서는 어느 시점에서든 현재 클러스터 상태를 저장하는 중앙 데이터베이스가 존재하며, 이는 서브넷, 구성 지도 등의 구성 세부 정보를 저장하는 데에도 사용된다. 마찬가지로 Go 프로그래밍 언어로 작성된다.

8.1 쿠버네티스 주요 구성요소 - 워크 노드 구성요소

쿠버네티스 워크 노드에는 컨테이너 간의 네트워킹을 관리하고, 마스터 노드와 통신하며 예약된 컨테이너에 리소스를 할당하는 데 필요한 모든 서비스가 포함되어 있다. 쿠버네티스 워크 노드의 구성 요소는 다음과 같다.

① 쿠블릿(Kubelet)
이것은 마스터 노드와 통신하고 클러스터 내의 각 작업자 노드에서 실행되는 기본 노드 에이전트다. API 서버를 통해 포드 사양을 얻고 포드와 관련된 컨테이너를 실행하며 포드에 설명된 컨테이너가 실행되고 정상적으로 실행되는지 확인한다. 만약 쿠베렛이 작업자 노드에서 실행되는 포드에 문제가 있음을 발견하면, 동일한 노드에서 포드를 다시 시작하는 것을 시도한다. 만약 작업자 노드 자체에 문제가 있는 경우, 쿠베네티스 마스터 노드는 노드 장애를 감지하고 다른 정상 노드에서 포드를 다시 만들기로 결정한다.

② Kube-Proxy
쿠버네티스 클러스터 내부의 핵심 네트워킹 구성 요소다. 이는 전체 네트워크 구성을 유지하는 역할을 한다. Kube-Proxy는 모든 노드, 파드, 컨테이너에 걸쳐 분산된 네트워크를 유지하고 외부 세계에 서비스를 노출한다. 단일 작업자 노드에서 서비스를 위한 네트워크 프록시 및 로드 밸런서 역할을 하며, TCP 및 UDP 패킷에 대한 네트워크 라우팅을 관리한다. 서비스 엔드포인트 생성 및 삭제 시마다 API 서버를 청취하여 도달할 수 있도록 경로를 설정한다.

③ 파드(Pods)
파드는 동일한 호스트에 함께 배치된 컨테이너 그룹이다. 파드의 도움으로 여러 종속 컨테이너를 함께 배치할 수 있으므로 이러한 컨테이너 주변에서 포장지 역할을 하여, 주로 파드를 통해 이러한 컨테이너를 상호 작용하고 관리할 수 있다.

④ 도커(Docker)
도커는 개발, 테스트 또는 운영과 같은 모든 환경에서 애플리케이션이 원활하게 작동하도록 하기 위해 애플리케이션과 모든 종속성을 컨테이너 형태로 패키지화하는 데 사용되는 컨테이너화 플랫폼이다. 도커는 컨테이너를 사용하여 애플리케이션을 쉽게 만들고 배포하고 실행할 수 있도록 설계된 도구다. 도커는 세계 최고의 소프트웨어 컨테이너 플랫폼이다. 역시나 Go 언어로 작성되어 있다. 도커가 출시된 지 이제 고작 10년이 좀 지났지만 커뮤니티는 이미 VM에서 도커로 전환한지 오래다. 도커는 개발자와 시스템 관리자 모두에게 도움이 되도록 설계되어, 많은 데브옵스(DevOps) 툴체인의 일부가 되었다. 따라서 개발자는 테스트 및 운영 환경에 대한 걱정 없이 코드를 작성할 수 있다. 도커는 시스템 수를 쉽게 확장하고 축소할 수 있으므로 시스템 관리자는 인프라에 대해 걱정할 필요가 없다. 도커는 소프트웨어 개발 주기의 배포 단계에서 작동한다.