CLOUD/K8s

[K8s] 쿠버네티스 2 개념이해 1

지수쓰 2021. 2. 23. 17:30
반응형

bcho.tistory.com/1256?category=731548보고 정리

 

마스터와 노드

마스터 : 클러스터 전체를 관리하는 컨트롤러

노드 : 컨테이너가 배포되는 머신( 가상 머신이나 물리적인 서버머신)

 

오브젝트 ★ 중요

가장 기본적인 구성단위가 되는 기본 오브젝트 (Basic Object)

이 기본 오브젝트를 생성,관리하는 기능을 가진 컨트롤러(Controller)

이러한 오브젝트의 스펙(설정) 이외 추가 정보인 메타정보들로 구성됨.

 

오브젝트 스펙(object spec)

커맨드라인을 통해서 오브젝트 생성시 인자로 전달하여 정의를 하거나 yaml이나 json파일로 스펙 정의.

 

기본 오브젝트(basic object)

쿠버네티스에 의해서 배포 및 관리되는 가장 기본적인 오브젝트 

컨테이너화 되어 배포되는 애플리케이션의 워크로드를 기술하는 오브젝트

종류 : Pod(컨테이너화 된 애플리케이션), Volume(디스크) , Service(로드밸런서), Namespace(패키지)

 

Pod

  • 쿠버네티스에서 가장 기본적인 배포 단위로 , 컨테이너를 포함하는 단위
  • 하나 이상의 컨테이너를 포함하는 Pod단위로 배포

< Pod을 정의한 오브젝트 스펙 >

apiVersion: v1  // 이 스크립트를 실행하기 위한 쿠버네티스 API 버전 (보통v1 사용)

kind: Pod  // 리소스 종류 정의

metadata: // 이 리소스의 각종 메타데이터를 넣음. 라벨이나 리소스 이름 등

name : nginx

spec: // 리소스의 상세한 스펙 정의

containers:  * // Pod는 컨테이너를 가지고 있기 때문에 컨테이너를 정의

- name: nginx

image : nginx:1.7.9

ports:

- containerPort :8090

 

여러개의 컨테이너를 Pod 단위로 묶는 이유? *특징

  • Pod 내의 컨테이너는 IP와 Port를 공유한다.

 : 같은 Pod 내의 컨테이너는 localhost를 통해서 통신이 가능함

  • Pod 내에 배포된 컨테이너간에는 디스크 볼륨을 공유할 수 있다.

: 애플리케이션을 실행할 때 Reverse Proxy, 로그 수집기 등 다양한 주변 솔루션도 같이 배포 됨.

 

일반적인 경우 다른 컨테이너로 배포할 경우 파일 시스템이 분리되어 로그수집기가 애플리케이션의 로그파일을 못 읽는데 

쿠버네티스 Pod 내에서는 볼륨을 공유하므로 다른 컨테이너의 파일을 읽어올 수 있다.

**애플리케이션, 애플리케이션에서 사용하는 주변 프로그램을 같이 배포하는 패턴을 MSA에서 사이드카 패턴이라고 함.

 

Volume

 

  • Pod가 기동할 때 컨테이너마다 로컬디스크(영구X)를 생성 

→ 컨테이너 리스타트, 새로 배포할 때 마다 로컬 디스크는 Pod 설정에 따라 새롭게 정의돼서 배포되기 때문에 디스크 내용 유실됨.

→ DB처럼 영구적으로 파일 저장해야하는 경우 영속적으로 저장하는 형태 스토리지가 볼륨. 

→ 컨테이너의 외장 디스크느낌으로 Pod가 기동할 때 마운트. Volume은 Pod 내 컨테이너간 공유 가능

 

 

 

→ 볼륨 마운트해서 사용 → 

 

「 웹 서버를 배포하는 Pod 」 ⊃

「 웹 서비스 서비스하는 Web server | 컨텐츠 내용(/htdocs) 업데이트하고 관리하는 Content mgmt | 로그 메세지 관리하는 Logger 컨테이너」

  • Web Server 컨테이너 : htdocs 디렉토리의 컨테이너를 서비스, /logs 디렉토리에 웹 억세스 정보 기록
  • Content 컨테이너 : htdocs 디렉토리의 컨텐트 업데이트 및 관리
  • Logger 컨테이너 : logs 디렉토리의 로그 수집

 

이때

｛ htdocs 컨텐츠 디렉토리 - webserver, content 컨테이너 공유 필요       ｝   → 이런 시나리오에서 "볼륨" 사용 . 마운트해서 공유 

｛ logs 디렉토리 - Web server, logger 컨테이너 공유 필요                       ｝

 

** 쿠버네티스는 다양한 외장 디스크 추상화된 형태로 제공함.

** iSCI, NFS (온프렘 기반), AWS EBS, Google Pd( 클라우드 외장 스토리지), github, glusterfs(오픈소스 기반 스토리지 서비스 ) 등 

 

Service

일반적으로 여러개의 Pod을 서비스하면서 로드밸런서를 이용해서 하나의 IP와 포트로 묶어 서비스를 제공함.

Pod는 동적으로 생성되고 장애가 생겼을때 리스타트되며 IP가 바뀌므로 로드밸런서에서 Pod을 지정할 때 IP주소를 이용하기는 어려움.

또한 오토스케일링으로 Pod가 동적으로 추가/삭제될 때 Pod목록을 로드밸런서가 유연하게 선택해주어야함.

→ 라벨(label)과 라벨 셀렉터(label selector) 사용

 

라벨셀렉터

: 서비스를 정의할 때 어떤 Pod를 서비스로 묶을것인지 정의하는 것

: Pod생성 메타데이터 정보 부분에 라벨을 정의. 

: 서비스는 라벨 셀렉터에서 특정 라벨을 가지고있는 Pod만 선택하여 서비스에 묶게 됨.

 

<정의한 스펙 >

kind : Service

apiVersion : v1

metadata : 

name : my-service

spec:

selector:

app : myapp

ports:

-protocol : TCP

port : 80   // 포트는 TCP이용. 서비스포트는 80포트로 서비스. 

targetPort: 9376 // 서비스 80포트의 요청을 컨테이너의 9376포트로 연결해서 서비스 제공

Namespace

  • 한 쿠버네티스 클러스터내의 논리적인 분리단위 
  • Pod, service는 네임스페이스별로 생성이나관리 될 수 있고 사용자의 권한도 네임스페이스 별로 나눠서 부여
  • ex) 하나의 클러스터 내에 개발/운영/테스트 환경이 있다면 클러스터를 개발,운영, 테스트 3개의 네임스페이스로 나눠 운영

 

네임스페이스로 할 수 있는 것

  • 사용자별로 네임스페이스 별 접근권한 다르게 운영
  • 네임스페이스 별로 리소스의 쿼타(할당량)지정 — 개발 계에는 CPU 100/ 운영계에는 CPU 400, 100 ..등
  • 네임스페이스 별로 리소스 나눠 관리 가능 (Pod, service등)

 

** 네임스페이스는 논리적 분리단위. 물리적, 기타 장치 분리가 된것이 아니라서 Pod간 통신은 가능하다.

** 네트워크 정책을 이용해 네임스페이스간 통신을 막는것 보단 높은 수준의 분리 정책을 위해서는 클러스터 자체 분리를 권장

 

 

 

라벨

  • 쿠버네티스의 리소스를 선택하는데 사용 됨
  • 각 리소스는 라벨을 가질 수 있고 라벨 검색 조건에 따라서 특정 라벨을 가지고 있는 리소스만을 선택할 수 있음.
  • 특정 라벨에 해당하는 리소스만 배포하거나, 업데이트하거나, service에 연결하거나, 네트워크 접근권한을 부여할 수 있음.
  • metadat 섹션에 키/값 쌍으로 정의. 여러 라벨을 동시에 적용 가능

"metadata":{

"labels":{

"key1":"value1",

"key2":"value2"

}

}

라벨 셀렉터

  • 오브젝트 스펙에서 selector 정의하고 라벨 조건을 적음
  • Equality based selector (같냐, 다르냐와 같은 조건을 이용해 리소스 선택)
    • environment = dev, tier!=frontend 등 등가조건에 따라 선택
  • set based selector( 집합의 개념 사용)
    • environment in (production, qa) 
    • tier notin (frontend, backend) 백도, 프론트도 아닌 리소스 선택

컨트롤러

앞에서 소개한 기본 오브젝트로 애플리케이션을 설정하고 배포하는 것을 조금 더 편리하게 관리하기 위해 컨트롤러를 사용

컨트롤러는 기본 오브젝트들을 생성하고 이를 관리하는 역할을 해준다.

종류 : Replication Controller, Replication Set, DaemonSet, Job, StatefulSet, Deployment

 

Replication Controller

  • 지정된 숫자로 Pod를 기동시키고 관리하는 역할
  • RC는 크게 3가지 파트로 구성. Replica의 수, Pod Selector, Pod Template 
    • Selector : 라벨을 기반으로 하여 RC가 관리한 Pod를 가지고 오는데 사용
    • Replica의 수 : RC에 의해 관리되는 Pod의 수 . 그 숫자만큼 유지하도록 함.
    • Pod Template : Pod를 추가로 가동할 때 어떻게 만들지에 대한 정보 (도커 이미지, 포트, 라벨) 정의


**주의 이미 돌고있는 Pod가 있는 상태에서 RC 리소스를 생성할 때, 그 Pod의 라벨과 RC의 라벨이 일치하면 새롭게 생성된 RC의 컨트롤을 받음. RC의 템플릿과 맞지 않더라도 기존거를 삭제하고 replica수를 맞추지 않고 기존거를 반영해서 추가적인것만 생성,삭제 

Replication Set

  • RC의 새버전
  • Set기반 Selector이용하는 RC ( ↔ RC는 Equality기반)

 

Deployment

  • RC와 Replica set의 좀 더 상위 추상화 개념. 실제로는 디플로이먼트를 더 많이 사용

 

Deployment 없는 배포 방식 → 블루/그린 배포 or 롤링 업그레이드

블루/그린 배포 - 새로운 RC와 새로운 템플릿으로 Pod생성후에 서비스 변경해줌

롤링업그레이드 - 새로운 RC만들어 replica수를 기존것과 새로운RC에서 +-1씩 해주면서 추가해줌. →수동컨트롤이 필요