티스토리 뷰

devOps

리눅스 컨테이너와 쿠버네티스

집사킴 2024. 8. 18. 00:51
728x90

쿠버네티스 등장 이유

  • 모놀리식 애플리케이션에서 마이크로서비스로의 전환하며 구성요소가 쪼개지기 시작
  • 배포 가능한 구성 요소의 수와 데이터센터 규모의 증가로 전체 시스템을 원활히 구성하고 유지, 관리하는 것이 어려워짐
  • 하드웨어 비용을 낮추고 효율적 리소스 활용을 위해 각 구성요소를 어디에 배치했는지 파악하는 것이 어려워짐
  • 서버의 구성 요소의 스케쥴링, 구성, 감독 및 오류처리의 자동화가 필요해졌음

⇒ 쿠버네티스는 리눅스 컨테이너 기술을 사용해 실행중인 애플리케이션을 격리한다.

 


 

 

가상머신 vs 리눅스 컨테이너

https://product.kyobobook.co.kr/detail/S000001804912

가상머신 컨테이너
프로세스마다 자체 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.

 

컨테이너마다 각각의 네임스페이스가 있음. (https://www.youtube.com/watch?v=EV4LyUJrw5E)

 

 

리눅스 컨트롤 그룹 (cgroup)

  • 프로세스 그룹의 리소스를 관리하고 제한
  • 리소스 제한 : CPU, 메모리, 디스크 I/O, 네트워크 대역폭 등 시스템 리소스를 프로세스 그룹에 대해 제한할 수 있음. ex) 특정 컨테이너가 사용할 수 있는 CPU 시간이나 메모리 양을 제한
  • 리소스 할당 : 프로세스 그룹에 대해 리소스를 할당하여 자원을 효율적으로 분배하고 특정 프로세스 그룹이 시스템 자원을 과도하게 소모하지 않도록 보장
  • 모니터링 : 리소스 사용 통계를 수집, 프로세스 그룹의 리소스 소비를 추적하는 등 사용량을 모니터링
  • 계층적 구조 : 상위그룹이 하위그룹을 포함할 수 있음. 이 계층구조를 통해 리소스 제한과 할당 세분화 가능
  •  

도커 컨테이너

컨테이너를 여러 컴퓨터에 쉽게 이식 가능하게 하는 최초의 컨테이너 시스템

  • 이미지: 애플리케이션과 환경을 패키지로 묶은 것. 애플리케이션에서 사용할 수 있는 파일 시스템과 이미지 실행 시 필요한 메타데이터가 들어있음
  • 레지스트리: 도커 이미지 공유 스토리지
  • 컨테이너: 도커 기반 이미지에서 생성된 리눅스 컨테이너. 프로세스는 리소스가 제한돼 있어 할당된 리소스(CPU, RAM 등)만 엑세스하고 사용 가능

여러 컨테이너 기술 중 도커가 유명해진 이유

  • 사용의 간편함: 복잡한 설정 없이 간단한 명령어로 빌드하고 실행할 수 있어 빠르게 인기를 끌어모음
  • 표준화된 이미지: 동일한 애플리케이션을 다른 환경(개발, 테스트, 프로덕션)에서 일관되게 실행할 수 있게되어 CI/CD 프로세스에 큰 이점을 주었음
    • 도커 이전의 기술들: LXC(이미지 공유 도구 부족. 각 환경에 맞는 스크립트 작성 필요) Solaris Zones, BSD Jails, OpenVZ (타 플래폼간의 호환성 낮음)
  • Docker Hub와 같은 이미지 레지스트리: 사용자들이 이미지를 쉽게 공유 및 검색 가능해짐. 다양한 패키지 발생
  • 멀티 플랫폼 지원: Linux 뿐 아니라 Windows, macOS도 지원

 

이미지 레이어

도커 기반 컨테이너 이미지와 가상머신 이미지와의 가장 큰 차이점은 컨테이너 이미지가 여러 레이어로 구성된다는 점이다


 

쿠버네티스

  • 쿠버네티스는 컨테이너 시스템상에서 컨테이너 애플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템
  • 컨테이너 오케스트레이션 뿐 아니라 클라우드 네이티브 애플리케이션이 관리, 자동화, 모니터링, 리소스 최적화 및 내결함성 등 다양한 기능을 제공하는 포괄적인 플랫폼
  • 도커, rkt 등 여러 컨테이너 런타임을 지원
  • 쿠버네티스를 사용하면 마치 모든 노드가 하나의 거대한 컴퓨터인 것처럼 사용 가능.
  • 기본 인프라를 추상화해 개발 및 운영팀의 개발, 배포, 관리를 단순화

 

쿠버네티스 클러스터 아키텍처

https://medium.com/devops-mojo/kubernetes-architecture-overview-introduction-to-k8s-architecture-and-understanding-k8s-cluster-components-90e11eb34ccd

  • 마스터 노드: 전체 쿠버네티스 시스템을 관리하고 통제하는 쿠버네티스 컨트롤 플레인을 관장
    • 클러스터 상태를 유지, 제어. 애플리케이션 실행 X
    • 컨트롤 플레인 구성요소
      • API 서버: 워커노드, 컨트롤러 매니저 등 다른 구성요소들과의 통신을 담당
      • 스케쥴러: 클러스터 자원 관리, Pod를 적절한 노드에 배치하여 애플리케이션이 올바르게 실행되도록 보장
      • 컨트롤 매니저: 구성 요소 복제, 워커 노드 추적, 노드 장애 처리 등 클러스터 상태 모니터링
      • etcd: 클러스터 구성을 지속적으로 저장하는 key value 분산 데이터 저장소
  • 워커 노드: 실제 배포하고자 하는 애플리케이션 실행을 담당
    • 물리적으로 분리되어있을 수도, 논리적으로 분리되어있을 수도 있음
    • 구성요소
      • 컨테이너 런타임: 컨테이너 실행 역할 (docker, rkt, …)
      • Kubelet: API 서버와 통신하고 노드에서 컨테이너를 관리
      • Kube-proxy: 애플리케이션 구성요소 간 네트워크 트래픽을 분산

 

쿠버네티스에서의 애플리케이션 실행 과정

 

쿠버네티스의 장점

  • 배포 단순화
  • HW 활용도 향상
  • 상태 확인 및 자가 치유
  • 오토스케일링
  • 애플리케이션 개발 단순화

 


참고

728x90
댓글
300x250
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/09   »
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
글 보관함