잔글 →주요 개념 |
잔글편집 요약 없음 |
||
| (같은 사용자의 중간 판 5개는 보이지 않습니다) | |||
| 2번째 줄: | 2번째 줄: | ||
[[분류: 클라우드 서비스]] | [[분류: 클라우드 서비스]] | ||
'''Kubenetes'''(쿠버네티스) 또는 k8s는 다수의 리눅스 컨테이너 이미지를 여러 개의 노드 서버에서 자동으로 분배하여 배포 및 실행할 수 있는 환경을 제공하는 오픈 소스 시스템이다. 현재는 리눅스 재단이 관리하고 있다. | '''Kubenetes'''(쿠버네티스) 또는 k8s는 다수의 리눅스 컨테이너 이미지를 여러 개의 노드 서버에서 자동으로 분배하여 배포 및 실행할 수 있는 환경을 제공하는 오픈 소스 클라우드 구축 시스템이다. 현재는 리눅스 재단이 관리하고 있다. | ||
== 개발 배경 및 쓰임 == | == 개발 배경 및 쓰임 == | ||
| 16번째 줄: | 16번째 줄: | ||
* 파드<br> | * 파드<br> | ||
컨테이너의 기본 작업 단위이다. 파드를 배포하기 위해 | 컨테이너의 기본 작업 단위이다. 파드를 배포하기 위해 배포 유형별로 정해진 양식의 [[YAML|yml]] 파일을 만들어 가져올 컨테이너 이미지를 설정하고, 볼륨과 환경변수, 실행 커맨드들을 설정한다는 개념 측면에서는 도커 컴포즈로 배포하는 상황이랑 비슷하나, 도커 컴포즈에서 설정할 법한 옵션들은 spec이란 키 안에 전부 잡아 넣고 그 외에도 훨씬 많은 옵션들을 설정한다. 그리고 이 옵션들이 k8s를 개인 및 소규모 회사 내 직원들이 공부하고 채용하기 어렵게 만드는 두 번째 원인이다(...) | ||
다행히도 파드 별로 저런 설정을 넣는 것이 아니라, 보통 다음에 소개할 스테이트풀 셋이나 디플로이먼트에서 설정한 옵션을 파드가 대부분 상속받는 | 아예 설정용 YAML 양식을 자기 업무용 컴퓨터에 미리 써 놓고 복붙하며 배포하는 게 편하긴 하다. 그것도 귀찮으면 ChatGPT가 만든 기본 양식을 적당히 맞게 수정하여 쓰는 일도 있는듯... | ||
다행히도 파드 별로 저런 설정을 넣는 것이 아니라, 보통 다음에 소개할 스테이트풀 셋이나 디플로이먼트에서 설정한 옵션을 파드가 대부분 상속받는 구조로 사용하게 설정된 것이 그나마 위안... | |||
* 데몬 셋, 리플리카 셋, 스테이트풀 셋<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)을 보유하고 있다. | |||
== 같이 보기 == | == 같이 보기 == | ||
* [[도커]] | * [[도커]] | ||
* [[리눅스]] | * [[리눅스]] | ||