728x90
- 컨테이너의 공동 배포된 그룹이며 쿠버네티스의 기본 빌딩 블록을 대표
- 쿠버네티스는 컨테이너를 개별적으로 배포하지 않고 컨테이너의 파드를 항상 배포하고 운영
- 일반적으로 파드는 단일 컨테이너만 포함하지만 다수의 컨테이너를 포함 할 수 있음
- 파드는 다수의 노드에 생성되지 않고 단일 노드에서만 실행
- 여러 프로세스를 실행하기 위해서는 컨테이너 당 단일 프로세스가 적합
- 다수의 프로세스를 제어하려면? → 다수의 컨테이너를 다룰 수 있는 그룹이 필요!
Pod 관리
두 가지 장점
- 파드는 밀접하게 연관된 프로세스를 함께 실행하고 마치 하나의 환경에서 동작하는 것처럼 보임
- 그러나 동일한 환경을 제공하면서 다소 격리된 상태로 유지
동일한 파드의 컨테이너 사이의 부분 격리
- 파드의 모든 컨테이너는 동일한 네트워크 및 UTS 네임스페이스에서 실행
- 같은 호스트 이름 및 네트워크 인터페이스를 공유 (포트 충돌 가능성 있음)
- 파드의 모든 컨테이너는 동일한 IPC 네임스페이스 아래에서 실행되며 IPC를 통해 통신 가능
- 최신 쿠버네티스 및 도커 버전에서는 동일한 PID 네임스페이스를 공유할 수 있지만 이 기능은 기본적으로 활성화돼 있지 않다
플랫 인터 파드 네트워크 구조
- 쿠버네티스 클러스터의 모든 파드는 공유된 단일 플랫, 네트워크 주소 공간에 위치
- 파드 사이에는 NAT 게이트웨이가 존재 하지 않음
컨테이너를 파드 전체에 적절하게 구성하는 방법
- 다수의 파드로 멀티티어 애플리케이션 분할하기
- 각각 스케일링이 가능한 파드로 분할하기
YAML로 파드 디스크립터 만들기
- kubectl 실행 명령으로 간단한 리소스 작성 방법도 가능하지만 일부 항목에 대해서만 가능하며 저장이 용의하지 않음
- 모든 쿠버네티스 객체를 YAML로 정의하면 버전 제어 시스템에 저장 가능
- 모든 API에 대한 내용은 http://kubernetes.io/docs/reference/ 참고
Reference
Production-Grade Container Orchestration
kubernetes.io
- apiVersion, kind, 메타 데이터, 스펙, 스테이터스 로 구성
- apiVersion: 쿠버네티스 api의 버전을 가리킴
- kind: 어떤 리소스 유형인지 결정(파드 레플리카컨트롤러, 서비스 등)
- 메타데이터: 파드와 관련된 이름, 네임스페이스, 레이블, 그 밖의 정보 존재
- 스펙: 컨테이너, 볼륨 등의 정보
- 상태: 파드의 상태, 각 컨테이너의 설명 및 상태, 파드 내부의 IP 및 그 밖의 기본 정보 등
728x90