k8s 추가 |
잔글편집 요약 없음 |
||
| (같은 사용자의 중간 판 8개는 보이지 않습니다) | |||
| 2번째 줄: | 2번째 줄: | ||
[[분류: 클라우드 서비스]] | [[분류: 클라우드 서비스]] | ||
'''Kubenetes'''(쿠버네티스) 또는 k8s는 다수의 리눅스 컨테이너 이미지를 여러 개의 노드 서버에서 자동으로 분배하여 배포 및 실행할 수 있는 환경을 제공하는 오픈 소스 시스템이다. 현재는 리눅스 재단이 관리하고 있다. | '''Kubenetes'''(쿠버네티스) 또는 k8s는 다수의 리눅스 컨테이너 이미지를 여러 개의 노드 서버에서 자동으로 분배하여 배포 및 실행할 수 있는 환경을 제공하는 오픈 소스 클라우드 구축 시스템이다. 현재는 리눅스 재단이 관리하고 있다. | ||
== 개발 배경 및 쓰임 == | == 개발 배경 및 쓰임 == | ||
쿠버네티스는 구글이 자사의 수많은 서비스(지메일, 유튜브, 구글 드라이브 및 구글 독스, 구글 맵 및 기타)를 많은 서버에 적절히 분배하여 관리하기 위해 사내 엔지니어들이 만든 서비스 배포 시스템을 오픈 소스 프로젝트로 공개한 프로젝트다. 이후 수많은 대형 IT 회사들이 자사의 서비스들을 쉽게 관리하기 위한 사내 클라우드(On-premise Cloud) 시스템을 구축하기 위해 쿠버네티스를 채용하면서 2020년 이후 조금씩 파이가 커지고 있다. | 쿠버네티스는 구글이 자사의 수많은 서비스(지메일, 유튜브, 구글 드라이브 및 구글 독스, 구글 맵 및 기타)를 많은 서버에 적절히 분배하여 관리하기 위해 사내 엔지니어들이 만든 서비스 배포 시스템을 2014년 오픈 소스 프로젝트로 공개한 프로젝트다. 이후 수많은 대형 IT 회사들이 자사의 서비스들을 쉽게 관리하기 위한 사내 클라우드(On-premise Cloud) 시스템을 구축하기 위해 쿠버네티스를 채용하면서 2020년 이후 조금씩 파이가 커지고 있다. | ||
구글이 만든 프로젝트인 만큼 [[구글 클라우드 플랫폼]](GCP)에서는 GKE(Google Kubenetes Engine)이란 이름으로 자사 클라우드 서비스를 사용하는 회사들을 위해 각종 서비스들을 통합해서 관리하는 쿠버네티스 시스템 관리 서비스를 제공하고 있다. | 구글이 만든 프로젝트인 만큼 [[구글 클라우드 플랫폼]](GCP)에서는 GKE(Google Kubenetes Engine)이란 이름으로 자사 클라우드 서비스를 사용하는 회사들을 위해 각종 서비스들을 통합해서 관리하는 쿠버네티스 시스템 관리 서비스를 제공하고 있다. | ||
| 16번째 줄: | 16번째 줄: | ||
* 파드<br> | * 파드<br> | ||
컨테이너의 기본 작업 단위이다. 파드를 배포하기 위해 | 컨테이너의 기본 작업 단위이다. 파드를 배포하기 위해 배포 유형별로 정해진 양식의 [[YAML|yml]] 파일을 만들어 가져올 컨테이너 이미지를 설정하고, 볼륨과 환경변수, 실행 커맨드들을 설정한다는 개념 측면에서는 도커 컴포즈로 배포하는 상황이랑 비슷하나, 도커 컴포즈에서 설정할 법한 옵션들은 spec이란 키 안에 전부 잡아 넣고 그 외에도 훨씬 많은 옵션들을 설정한다. 그리고 이 옵션들이 k8s를 개인 및 소규모 회사 내 직원들이 공부하고 채용하기 어렵게 만드는 두 번째 원인이다(...) | ||
다행히도 파드 별로 저런 설정을 넣는 것이 아니라, 보통 다음에 소개할 스테이트풀 셋이나 디플로이먼트에서 설정한 옵션을 파드가 대부분 상속받는 | 아예 설정용 YAML 양식을 자기 업무용 컴퓨터에 미리 써 놓고 복붙하며 배포하는 게 편하긴 하다. 그것도 귀찮으면 ChatGPT가 만든 기본 양식을 적당히 맞게 수정하여 쓰는 일도 있는듯... | ||
다행히도 파드 별로 저런 설정을 넣는 것이 아니라, 보통 다음에 소개할 스테이트풀 셋이나 디플로이먼트에서 설정한 옵션을 파드가 대부분 상속받는 구조로 사용하게 설정된 것이 그나마 위안... | |||
* 데몬 셋, 리플리카 셋, 스테이트풀 셋<br> | * 데몬 셋, 리플리카 셋, 스테이트풀 셋<br> | ||
동일하게 복제된 여러 파드의 묶음인 작업 단위를 의미한다. 리플리카셋은 보통 후술할 디플로이먼트에 귀속된 경우가 많으며, 배포를 시작할 때 파드 배포 순서가 정해져 있지 않다. 스테이트풀 셋은 파드 배포 순서가 정해져 있으며, 보통 '(파드 배포 이름)-0'부터 뒤의 숫자가 올라가는 방식으로 파드 별 이름이 결정된다. 데몬 셋은 '반드시 모든 워커 노드에서 동일한 파드 하나씩' 실행하는 특수한 경우에 사용하는데, 보통 워커 노드들에 기능을 추가하는 쿠버네티스용 플러그인(예: Calico 같은 CNI, Longhorn 같은 볼륨 관련 플러그인)을 설치할 때 데몬셋 형태로 파드가 배포된다. | 동일하게 복제된 여러 파드의 묶음인 작업 단위를 의미한다. 리플리카셋은 보통 후술할 디플로이먼트에 귀속된 경우가 많으며, 배포를 시작할 때 파드 배포 순서가 정해져 있지 않다. 스테이트풀 셋은 파드 배포 순서가 정해져 있으며, 보통 '(파드 배포 이름)-0'부터 뒤의 숫자가 올라가는 방식으로 파드 별 이름이 결정된다. 데몬 셋은 '반드시 모든 워커 노드에서 동일한 파드 하나씩' 실행하는 특수한 경우에 사용하는데, 보통 워커 노드들에 기능을 추가하는 쿠버네티스용 플러그인(예: Calico 같은 CNI, Longhorn 같은 볼륨 관련 플러그인)을 설치할 때 데몬셋 형태로 파드가 배포된다. | ||
DBMS를 굳이 k8s로 배포하겠다고 하겠다면 스테이트풀 셋이 적당하다. 리플리케이션 순서를 정하게 하기 쉽다. 그러나 보통 DBMS는 k8s로 배포하는 경우가 많지 않는데, 어쩌다 워커 노드가 하나 맛이 갔는데 그 안에 DBMS 파드가 들어있었다면 데이터 동기화가 개판이 되기 때문. 특히 시스템의 규모가 클 수록 그 피해의 크기는 상상을 초월한다... | DBMS를 굳이 k8s로 배포하겠다고 하겠다면 스테이트풀 셋이 적당하다. 리플리케이션 순서를 정하게 하기 쉽다. 그러나 보통 DBMS는 k8s로 배포하는 경우가 많지 않는데, 어쩌다 워커 노드가 하나 맛이 갔는데 그 안에 DBMS 파드가 들어있었다면 데이터 동기화가 개판이 되기 때문. 특히 시스템의 규모가 클 수록 그 피해의 크기는 상상을 초월한다... 그래서 k8s 클러스터에서 DBMS는 보통 따로 분리해 별도의 물리 컴퓨터들에 설치하는 편이다. | ||
* 디플로이먼트<br> | * 디플로이먼트<br> | ||
| 30번째 줄: | 32번째 줄: | ||
* 서비스<br> | * 서비스<br> | ||
어쨌든 k8s는 컴퓨터들의 클러스터에서 여러 프로젝트들이 돌아가는 구조이므로, 최소한의 네트워크 통신으로 파드로 올려진 컨테이너 간의 네트워크 통신이 필요하다. k8s는 이런 파드 간 네트워크 통신 관련 정보를 배포할 때에 '서비스'라는 단위로 배포한다. 서비스에서는 네트워크 통신을 위한 포트 설정이 필수적이다. 기본적으로 Kubenet이라는 내장 플러그인이 있긴 하나, 기능이 턱없이 부족해 Flannel, Calico 같은 서드 파티 CNI 플러그인이 많이 사용된다. | 어쨌든 k8s는 컴퓨터들의 클러스터에서 여러 프로젝트들이 돌아가는 구조이므로, 최소한의 네트워크 통신으로 파드로 올려진 컨테이너 간의 네트워크 통신이 필요하다. k8s는 이런 파드 간 네트워크 통신 관련 정보를 배포할 때에 '서비스'라는 단위로 배포한다. 서비스에서는 네트워크 통신을 위한 포트 설정이 필수적이다. 기본적으로 Kubenet이라는 내장 플러그인이 있긴 하나, 기능이 턱없이 부족해 Flannel, Calico 같은 서드 파티 CNI 플러그인이 많이 사용된다. | ||
:* ClusterIP, NodePort, LoadBalancer: 보통 대형 IT 프로젝트가 k8s를 사용한다면 대부분의 서비스, 특히 백엔드 서비스는 보안을 위해 외부에 노출시키지 않는다. 그래서 보통 서비스들은 ClusterIP 타입으로 내부망에서 서비스 이름으로만 통신하도록 되어 있다. 그러나 이렇게만 하면 디버깅도 어렵고, 프론트엔드 서버처럼 외부 네트워크에 노출시켜야 하는 서버가 있을 것이다. 보통 서비스의 작동 여부를 확인할 때에는 NodePort 타입의 서비스를 설정하며, 영구적으로 외부에 노출시킬 때에는 CNI 플러그인을 설치해서 LoadBalancer 타입으로 적절한 파드(또는 복수의 파드)가 노출되도록 한다. | |||
* 퍼시스턴트 볼륨 및 퍼시스턴트 볼륨 클레임<br> | * 퍼시스턴트 볼륨 및 퍼시스턴트 볼륨 클레임<br> | ||
| 40번째 줄: | 42번째 줄: | ||
이렇게 복잡한 k8s 배포 구조 때문에 종종 디플로이먼트/스테이트풀셋 등을 배포할 때 이름이 겹치거나 혼동하기 쉬운 이름들을 가진 여러 서비스들이 생길 수 있다. 이를 완화하기 위해 모든 k8s 작업 단위에는 메타데이터가 있으며, 그 안에서 작업 단위의 타입(예: frontend, backend)를 임의로 지정하거나 네임스페이스라는 단위로 아예 특정 서비스들을 위한 여러 작업 단위를 한꺼번에 분리할 수 있다. | 이렇게 복잡한 k8s 배포 구조 때문에 종종 디플로이먼트/스테이트풀셋 등을 배포할 때 이름이 겹치거나 혼동하기 쉬운 이름들을 가진 여러 서비스들이 생길 수 있다. 이를 완화하기 위해 모든 k8s 작업 단위에는 메타데이터가 있으며, 그 안에서 작업 단위의 타입(예: frontend, backend)를 임의로 지정하거나 네임스페이스라는 단위로 아예 특정 서비스들을 위한 여러 작업 단위를 한꺼번에 분리할 수 있다. | ||
k8s에 설치되는 플러그인들도 각기 네임스페이스로 격리되기 때문에, 운 나쁘게 배포한 디플로이먼트 내 파드 이름이 플러그인의 파드 이름과 겹쳐 배포가 실패하는 일은 일반적으로 없다. | k8s에 설치되는 플러그인들도 각기 네임스페이스로 격리되기 때문에, 운 나쁘게 배포한 디플로이먼트 내 파드 이름이 플러그인의 파드 이름과 겹쳐 배포가 실패하는 일은 일반적으로 없다. 기본적으로 k8s 클러스터 내에 생성되는 기본 네임스페이스의 이름은 'default'다. | ||
* 컨피그맵과 시크릿 | * 컨피그맵과 시크릿 | ||
| 58번째 줄: | 60번째 줄: | ||
심지어 쿠버네티스는 도커 엔진을 사용할 수 없다! 도커 사가 자꾸 자사만의 고유 규격을 추가한다고 쿠버네티스 1.20부터 도커 엔진 지원을 중단하였기 때문이다. 현재 k8s의 기본 컨테이너 엔진은 containerd인데, 한국에는 도커 엔진에 비해 많이 알려지지 않은 데다가 사용자가 대형 IT 회사 위주로 한정되어서, 소규모 회사들이 컨테이너 기술을 활용한다면 아직 도커 및 도커 엔진(+도커 컴포즈) 정도만 쓰고 있다. | 심지어 쿠버네티스는 도커 엔진을 사용할 수 없다! 도커 사가 자꾸 자사만의 고유 규격을 추가한다고 쿠버네티스 1.20부터 도커 엔진 지원을 중단하였기 때문이다. 현재 k8s의 기본 컨테이너 엔진은 containerd인데, 한국에는 도커 엔진에 비해 많이 알려지지 않은 데다가 사용자가 대형 IT 회사 위주로 한정되어서, 소규모 회사들이 컨테이너 기술을 활용한다면 아직 도커 및 도커 엔진(+도커 컴포즈) 정도만 쓰고 있다. | ||
한편 도커 사는 k8s에 대응하는 솔루션으로 도커 스웜(Docker swarm)을 보유하고 있다. | |||
== 같이 보기 == | == 같이 보기 == | ||
* [[도커]] | * [[도커]] | ||
* [[리눅스]] | * [[리눅스]] | ||