티스토리 뷰
728x90
쿠버네티스 등장 이유
- 모놀리식 애플리케이션에서 마이크로서비스로의 전환하며 구성요소가 쪼개지기 시작
- 배포 가능한 구성 요소의 수와 데이터센터 규모의 증가로 전체 시스템을 원활히 구성하고 유지, 관리하는 것이 어려워짐
- 하드웨어 비용을 낮추고 효율적 리소스 활용을 위해 각 구성요소를 어디에 배치했는지 파악하는 것이 어려워짐
- 서버의 구성 요소의 스케쥴링, 구성, 감독 및 오류처리의 자동화가 필요해졌음
⇒ 쿠버네티스는 리눅스 컨테이너 기술을 사용해 실행중인 애플리케이션을 격리한다.
가상머신 vs 리눅스 컨테이너
가상머신 | 컨테이너 |
프로세스마다 자체 OS (=게스트 OS)가 있음 | 호스트 OS에서 동작하는 단일 커널. |
각 하드웨어가 자체 시스템 프로세스 집합을 실행해야 하기 때문에 자체 프로세스에서 소비되는 것 외에도 컴퓨팅 리소스가 필요 | 가벼움. 호스트 OS에서 실행하는 단일 격리된 프로세스 이상으로 리소스를 소비하지 않고 애플리케이션에서 사용하는 리소스만 사용. |
애플리케이션 단위가 작아지고 수가 많아질 수록 오버헤드 발생 | 오버헤드 발생 X |
게스트 OS의 커널에서 하이퍼바이저를 통해 시스템을 호출하여 호스트의 물리적 CPU에서 x86 명령어를 실행 | 단일 커널을 통해 호스트 CPU에서 x86 명령어를 수행 |
각 가상머신이 자체 리눅스 커널 위에서 실행되므로 완전한 분리환경 | 모두 동일한 커널 상에서 시스템을 호출하여 보안 위험의 염려가 있음. docker와 k8s에서는 네임스페이스 격리, cGroups, Pod Security Policies 등의 보안장치로 보안을 강화함. |
프로세스 실행 시 부팅 필요 | 자체 OS가 없으므로 부팅 X. 컨테이너 가동 시 프로세스 즉시 시작 |
컨테이너 격리 메커니즘
리눅스 네임스페이스 격리
- 네임스페이스에는 파일 시스템, 프로세스ID, 사용자ID, 네트워크 인터페이스 등의 시스템 자원이 속함
- 기본 리눅스 시스템은 단일 네임스페이스에 속하지만, 추가로 네임스페이스를 만들고 리소스를 구성할 수 있음
- 프로세스 실행 시 프로세스는 네임스페이스 중 하나에서 실행되고, 프로세스는 동일 네임스페이스 내의 리소스만 볼 수 있음 → 특정 자원 그룹이 분리됨
Docker uses a technology called namespaces to provide the isolated workspace called the container. When you run a container, Docker creates a set of namespaces for that container.
These namespaces provide a layer of isolation. Each aspect of a container runs in a separate namespace and its access is limited to that namespace.
리눅스 컨트롤 그룹 (cgroup)
- 프로세스 그룹의 리소스를 관리하고 제한
- 리소스 제한 : CPU, 메모리, 디스크 I/O, 네트워크 대역폭 등 시스템 리소스를 프로세스 그룹에 대해 제한할 수 있음. ex) 특정 컨테이너가 사용할 수 있는 CPU 시간이나 메모리 양을 제한
- 리소스 할당 : 프로세스 그룹에 대해 리소스를 할당하여 자원을 효율적으로 분배하고 특정 프로세스 그룹이 시스템 자원을 과도하게 소모하지 않도록 보장
- 모니터링 : 리소스 사용 통계를 수집, 프로세스 그룹의 리소스 소비를 추적하는 등 사용량을 모니터링
- 계층적 구조 : 상위그룹이 하위그룹을 포함할 수 있음. 이 계층구조를 통해 리소스 제한과 할당 세분화 가능
도커 컨테이너
컨테이너를 여러 컴퓨터에 쉽게 이식 가능하게 하는 최초의 컨테이너 시스템
- 이미지: 애플리케이션과 환경을 패키지로 묶은 것. 애플리케이션에서 사용할 수 있는 파일 시스템과 이미지 실행 시 필요한 메타데이터가 들어있음
- 레지스트리: 도커 이미지 공유 스토리지
- 컨테이너: 도커 기반 이미지에서 생성된 리눅스 컨테이너. 프로세스는 리소스가 제한돼 있어 할당된 리소스(CPU, RAM 등)만 엑세스하고 사용 가능
여러 컨테이너 기술 중 도커가 유명해진 이유
- 사용의 간편함: 복잡한 설정 없이 간단한 명령어로 빌드하고 실행할 수 있어 빠르게 인기를 끌어모음
- 표준화된 이미지: 동일한 애플리케이션을 다른 환경(개발, 테스트, 프로덕션)에서 일관되게 실행할 수 있게되어 CI/CD 프로세스에 큰 이점을 주었음
- 도커 이전의 기술들: LXC(이미지 공유 도구 부족. 각 환경에 맞는 스크립트 작성 필요) Solaris Zones, BSD Jails, OpenVZ (타 플래폼간의 호환성 낮음)
- Docker Hub와 같은 이미지 레지스트리: 사용자들이 이미지를 쉽게 공유 및 검색 가능해짐. 다양한 패키지 발생
- 멀티 플랫폼 지원: Linux 뿐 아니라 Windows, macOS도 지원
이미지 레이어
도커 기반 컨테이너 이미지와 가상머신 이미지와의 가장 큰 차이점은 컨테이너 이미지가 여러 레이어로 구성된다는 점이다
쿠버네티스
- 쿠버네티스는 컨테이너 시스템상에서 컨테이너 애플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템
- 컨테이너 오케스트레이션 뿐 아니라 클라우드 네이티브 애플리케이션이 관리, 자동화, 모니터링, 리소스 최적화 및 내결함성 등 다양한 기능을 제공하는 포괄적인 플랫폼
- 도커, rkt 등 여러 컨테이너 런타임을 지원
- 쿠버네티스를 사용하면 마치 모든 노드가 하나의 거대한 컴퓨터인 것처럼 사용 가능.
- 기본 인프라를 추상화해 개발 및 운영팀의 개발, 배포, 관리를 단순화
쿠버네티스 클러스터 아키텍처
- 마스터 노드: 전체 쿠버네티스 시스템을 관리하고 통제하는 쿠버네티스 컨트롤 플레인을 관장
- 클러스터 상태를 유지, 제어. 애플리케이션 실행 X
- 컨트롤 플레인 구성요소
- API 서버: 워커노드, 컨트롤러 매니저 등 다른 구성요소들과의 통신을 담당
- 스케쥴러: 클러스터 자원 관리, Pod를 적절한 노드에 배치하여 애플리케이션이 올바르게 실행되도록 보장
- 컨트롤 매니저: 구성 요소 복제, 워커 노드 추적, 노드 장애 처리 등 클러스터 상태 모니터링
- etcd: 클러스터 구성을 지속적으로 저장하는 key value 분산 데이터 저장소
- 워커 노드: 실제 배포하고자 하는 애플리케이션 실행을 담당
- 물리적으로 분리되어있을 수도, 논리적으로 분리되어있을 수도 있음
- 구성요소
- 컨테이너 런타임: 컨테이너 실행 역할 (docker, rkt, …)
- Kubelet: API 서버와 통신하고 노드에서 컨테이너를 관리
- Kube-proxy: 애플리케이션 구성요소 간 네트워크 트래픽을 분산
쿠버네티스에서의 애플리케이션 실행 과정
쿠버네티스의 장점
- 배포 단순화
- HW 활용도 향상
- 상태 확인 및 자가 치유
- 오토스케일링
- 애플리케이션 개발 단순화
참고
- https://product.kyobobook.co.kr/detail/S000001804912
- https://docs.docker.com/
- https://www.youtube.com/watch?v=EV4LyUJrw5E
- https://medium.com/devops-mojo/kubernetes-architecture-overview-introduction-to-k8s-architecture-and-understanding-k8s-cluster-components-90e11eb34ccd
- https://kubernetes.io/ko/docs/home/
728x90
'devOps' 카테고리의 다른 글
[쿠버네티스] 포드를 안정적으로 유지하기 위한 기술들 (5) | 2024.09.07 |
---|---|
[쿠버네티스] 라벨, 주석, 네임스페이스 (1) | 2024.09.04 |
[쿠버네티스] 포드 간 통신, 포드 분배, 멀티 컨테이너 패턴 (0) | 2024.09.01 |
[쿠버네티스] Pod, Replication Controller, Service (0) | 2024.08.25 |
댓글
300x250
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- redis
- k8s
- 분산처리
- phpUnit
- java
- laravel 테스트
- 라라벨
- Apache POI
- docker
- laravel 테스트코드
- 샤드
- NoSQL
- index
- php
- database
- 리눅스 컨테이너
- laravel
- mockery
- mongoDB
- 백엔드
- 쿠버네티스
- 도커
- 샤딩
- springboot
- 주니어개발자
- 대규모 데이터 처리
- MySQL
- pods
- 몽고디비
- kubernetes
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
글 보관함