Kubernetes (K8S): 개요 2

자! 이전 시간에 이어서 계속 진행합니다.

 3.2. K8S Namespace

  3.2.1. 클러스터 안의 가상 클러스터 영역.

  3.2.2. 클러스터를 처음 구축하면 default, docker, kube-public, kube-system의 네임스페이스 4개가 이미 존재.

  3.2.3. kubectl get namespace 명령으로 현재 클러스터 안에 존재하는 네임스페이스의 목록을 확인.

  3.2.4. 전체 클러스터에서 리소스의 구분 용도.

  3.2.5. 즉 전체 클러스터에서 특정 이름으로 클러스터의 영역을 구분.

namespace

 3.3. K8S POD

POD

  3.3.1. 파드는 컨테이너가 모인 집합체의 단위로, 적어도 하나 이상의 컨테이너로 구성

  3.3.2. 여기서 말하는 컨테이너는 도커 컨테이너를 의미.

  3.3.3. 쿠버네티스를 도커와 함께 사용한다면 파드는 컨테이너 하나 혹은 컨테이너의 집합체

  3.3.4. 쿠버네티스에서는 결합이 강한 컨테이너를 파드로 묶어 일괄 배포.(ex spring web app + nginx)

  3.3.5. 또한 이러한 파드는 노드에 배치된다.

  3.3.6. 한 파드 안의 컨테이너는 모두 같은 노드에 배치. 파드 하나가 여러 노드에 걸쳐 배치될 수는 없다.

 

POD

  3.3.7.POD의 적절한 크기는 어느 정도인가'.

   3.3.7.1. 보통 리버스 프록시 역할을 할 Nginx와 그 뒤에 위치할 애플리케이션 컨테이너를 함께 파드로 묶는 구성

   3.3.7.2. 또한 예거와 같은 로그와 관련된 서버는 애플리케이션 컨테이너의 사이드카로 많이 파드를 구성

   3.3.7.3. 또 함께 배포해야 정합성을 유지할 수 있는 컨테이너 등에도 컨테이너를 같은 파드으로 묶어두는 전략이 유용

 

 3.4. K8S ReplicaSet 

  3.4.1. 파드를 정의한 매니페스트 파일로는 파드를 하나밖에 생성할 수 있음.

  3.4.2. 어느 정도 규모가 되는 애플리케이션을 구축하려면 같은 파드를 여러 개 실행해 가용성을 확보

  3.4.3. 레플리카세트는 똑같은 정의를 갖는 파드 여러개를 생성하고 관리하기 위한 리소스.

   3.4.3.1. apiVersion은 리소스 유형마다 조금씩 다름. 왜냐 각 리소스마다 호출하는 api path가 다르기 때문.

   3.4.3.2. kind는 ReplicaSet

   3.4.3.3. metadata에는 이름 등을 정의.

   3.4.3.4. ReplicaSet의 spec 부분

   3.4.3.5. Pod의 매니페스트와는 조금 다르게 replicas와 selector가 존재.

   3.4.3.6. replicas는 몇개의 복제본을 만들것 인가를 정의

   3.4.3.7. selector는 어떠한 Pod을 대상으로 ReplicaSet을 만들것 인가를 지정한다.

   3.4.3.8. matchLabels의 값으로 template 밑의 라벨 값이 선택.

   3.4.3.9. emplate 밑의 설정들은 Pod의 설정과 동일,

   3.4.3.10. selector 속성으로 복제할 Pod의 설정을 참조

 

 3.5. K8S Deployment

  3.5.1. 레플리카셋보다 상위에 해당하는 리소스로 디플로이먼트 존재.

  3.5.2. 보통 디플로이먼트가 애플리케이션 배포의 기본 단위가 되는 리소스.

  3.5.3. 레플리카셋은 똑같은 파드의 레플리카를 관리 및 제어하는 리소스인데 반해,

  3.5.4. 디플로이먼트는 레플리카셋을 관리하고 다루기 위한 리소스이다