컨테이너 통합 도구.

클라우드(서버) 인프라스트럭처로서 물리적인 문제를 해결가능.

하나 이상의 Docker 컨테이너를 호스팅함.


머신을 쿠버네티스에서는 노드라고 한다.

노드는 또한, 하나의 미니언이라고 부를수도 있다.

Master 는 다른 Node(미니언) 일정을 조정하는 특별한 SW를 실행 하며 클러스터를 지원한다.

컬렉션 마스터 및 노드의 클러스터를 클러스터라고 한다.



Master 및 Node 는 실행되는 소프트웨어 구성 요소에 의해 정의된다.

Master 로부터의 주요 항목 3가지.

  1. API 서버 - 마스터와 노드의 거의 모든 구성 요소는 API 호출을 통해 각각의 작업을 수행 마스터에서 실행되는 API 서버에 의해 처리
  2. Etcd-Etcd는 클러스터의 현재 구성 및 실행 상태를 보존하고 복제하는 작업, 경량 분산 키 - 값 저장소로 구현되며 CoreOS 프로젝트 내에서 개발됨.
  3. 스케줄러 및 컨트롤러 관리자 -프로세스는 컨테이너 (실제로는 포드 (pod) - 나중에는 대상 노드)를 대상 노드에 스케줄링 또한 정확한 숫자가 항상 실행되고 있는지 확인한다.

Node 로부터의 주요 프로세스 3가지.

  1. Kubelet - 특수 배경 프로세스 (마스터의 명령에 응답하여 해당 호스트에서 컨테이너를 작성, 삭제 및 모니터하는 작업을 수행하는 각 노드에서 실행되는 데몬).
  2. Proxy - 이것은 대상 컨테이너의 IP 주소와 그것이 제공하는 서비스의 이름을 구분하는 데 사용되는 간단한 네트워크 프록시.
  3. cAdvisor (선택 사항) - 실행중인 컨테이너에 대한 정보를 수집, 수집 및 처리하고 내보내는 특수 데몬, 정확히는 자원 격리, 내역 사용 및 주요 네트워크 통계.


이러한 각 요소들은 다른 시스템에 분산되거나 단순성을 위해 동일한 호스트에서 모두 실행이 가능하다.

Master 와 Node 사이의 주요 트러블슈팅 및 어떤 프로세스 집합등을 실행하고 있는지 오케스트레이션이 가능하다.

■ Kubernetes 아키텍처


■ Pod

공통 자원 (파일 시스템 또는 IP 주소)을 공유하고,

번들과 함께 사용되는 또는 예약 된 컨테이너 및 볼륨의 집합을 말한다.

또한 파드는 컨테이너들의 그룹으로 같이 배포되고 스케줄링 된다.


표준 Docker 구성에서 각 컨테이너는 자체 IP 주소를 가지고 있다.

Kubernetes는 공유 IP 주소를 포드에 할당하여이 체계를 단순화하며,

모든 컨테이너는 동일한 주소를 공유하고 호스트를 통해 서로 통신 한다.

이렇게하면 기본적으로 포드를 컨테이너와 같은 호스트로 에뮬레이트하므로

대략적으로 VM과 비슷하다 할 수 있다.


Kubernetes는 컨테이너 레벨이 아닌 포드 레벨에서 작업을 계획하고 조정한다.

즉, 동일한 컨테이너에서 여러 컨테이너를 실행중인 경우 함께 관리해야 하며,

공유 되는 모든 클러스터링 시스템의 핵심이다.

1. 관리 투명성 - 컨테이너에서 둘 이상의 프로세스를 실행하는 경우 각 사용자가 사용하는 리소스를 모니터링하고 관리한다. 

오작동 한 프로세스가 컨테이너 내 다른 프로세스를 죽일 수있는 가능성이 완전히 있으며,

이를 감지하고 수정하는 것은 전적으로 관리자의 역할이다.

반면, 논리 작업 단위를 별도의 컨테이너로 분리하면 Kubernetes가이를 관리하여보다 쉽게 디버그하고 수정할 수 있다.


2. 배포 및 유지 관리 - 소프트웨어를 변경할 때마다 개별 컨테이너를 재구성하고 다시 배포 할 수 있다.

배포 종속성을 분리하면 개발 및 테스트가 더 빨라지며, 장애가 발생할 경우 롤백이 빠르고 쉽다.


3. Kubernetes가 프로세스 및 자원 관리하는 경우 컨테이너는 매우 가벼워 지고, 오버헤드 대신 코드에 집중할 수 있다.


마스터 스케줄러는 수시로 (클러스터의 전반적인 상태가 요구됨에 따라) 호스트에서 pod를 제거하도록 설정할 수 있다.

즉, Pod를 삭제하고 다른 노드에서 새 복사본을 가져올 수 있다.

비 상태 유지 방식으로 상태를 메모리에 저장하는 대신 Redis, Memcached, Cassandra 등과 같은 공유 데이터 저장소를 사용하는 방법을 고려할 수 있다.



■ Volumes

Kubernetes도 볼륨을 가지고 있지만 다르게 작동한다.

Kubernetes 볼륨은 컨테이너 레벨이 아닌 pod 레벨에서 정의된다.

1. 내구성 - 컨테이너는 죽고 항상 다시 생성됨.

볼륨이 컨테이너에 연결되어 있으면 컨테이너가 종료 될 때 볼륨도 사라짐 ( docker 와 같은 방식)

볼륨이 창에 바인딩 된 경우, 자료는 그 포드에있는 어떤 콘테이너의 종료 후에도 재생성 된다. 

2. 통신 - 포드 레벨에는 볼륨이 있으므로 포드의 모든 컨테이너를보고 사용할 수 있다. 즉, 컨테이너간에 임시 데이터를 쉽게 이동할 수 있다.

쿠버네티스에서 볼륨을 사용하는 다음의 세 가지 방법은 가장 많이 사용되는 유형이다.

비어있는 디렉토리

가장 일반적으로 사용되는 유형은 EmptyDir 이며, 일반적으로 항시 바인딩되며 처음 생성 될 때 항상 비어 있다.

볼륨이 포드에 바인딩되어 있기 때문에 포드의 수명 동안 만 볼륨이 존재.

포드가 제거되면 볼륨의 내용이 손실된다.

포드의 수명을 위해 포드의 모든 컨테이너는이 볼륨을 읽고 쓸 수 있으므로 임시 데이터를 쉽게 공유 할 수 있다.

일반적으로 이러한 유형의 저장소는 임시 저장소로 알려져 있으며, 내용물이 호스트의 수명에서 살아남은 저장소를 영구 저장소라고 부름.

네트워크 파일 시스템 (NFS)

최근 Kubernetes는 포드 수준에서 NFS 볼륨을 마운트 할 수있는 기능을 추가 되었다.

이는 용기가 포드의 수명을 초월한 NFS 볼륨이 존재하기 때문에 컨테이너가 중요한 파일 기반 데이터 (예 : 로그)를 쉽고

영구적으로 저장하고 검색 할 수 있다는 것을 의미.

GCEPersistentDisk (PD)

Google Cloud Platform (GCP)에는 관리되는 Kubernetes 오퍼링 인 GKE가 있다.

GKE를 통해 Kubernetes를 사용하는 경우 포드 (pod)에 볼륨으로 마운트 할 수있는 영구 디스크 (PD)라는 내구성있는 네트워크 연결 저장 볼륨을 만들 수 있다.





  • No labels