[K-PaaS] 2일차 2장, 3장 Container, Podman, K8S의 이해

정의
Container?

• SW서비스를 실행하는 데 필요한 특정 버전의 프로그래밍 언어 런타임 및 라이브러리와 같은 중속 항목과 애플리케이션 코드를 함께 포함하는 경량 패키지
• 애플리케이션의 코드를 관련 구성 파일, 라이브러리 및 앱 실행에 필요한 종속성과 함께 번들로 제공하는 SW패키지

Hypervisor 기술과 Container 기술

Container 특징

• 쉽고 효율적인 컨테이너 이미지 생성으로 애플리케이션을 기민하게 생성, 배포할 수 있음
• 안정적, 주기적으로 컨테이너 이미지를 빌드, 배포할 수 있기 때문에 지속적인 개발, 통합 및 배포 가능
• 빌드/릴리즈 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에 개발과 운영의 관심사 분리
• 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있어 가시성이 높음
• 랩탑, 클라우드에서 모두 동일하게 구동되므로 개발, 테스팅 및 운영 환경에 걸친 일관성 확보
• 주요 퍼블릭 클라우드와 어디에서든 구동되어 클라우드 및 OS 배포판 간 이식성이 높음
• 논리적 리소스를 사용하는 OS 중심으로 추상화 수준이 높아져 애플리케이션 중심 관리 가능
• 느슨하게 묶이고, 분산되고, 유연하며, 자유로운 마이크로 서비스 형태로 애플리케이션 배포, 관리
• 리소스가 격리되어 애플리케이션 성능을 예측할 수 있음
• 고휴율 고집적의 리소스 사용량

Container Engine & Container Runtime

• Container Engine

1. 컨테이너를 관리하기 위한 API나 CLI 도구를 제공하는 소프트웨어
2. 컨테이너 엔진은 사용자 입력을 받고, 컨테이너 이미지를 꺼내고, 컨테이너 실행 방법을 명시한 메타데이터를 만든 다음, 컨테이너 런타임에 이 정보들을 전달
3. 도커 엔진(docker0-ce), 레드햇의 파드맨, 로켓 컴퍼니의 rkt 등

• Container Runtime

1. 루트 파일시스템과 메타 데이터를 받아 컨테이너를 실행하는 도구
2. 가장 일반적으로 쓰이는 런타임 OCI를 준수하는 runC
3. 컨테이너-디(containerd), 크라이-오(cri-o) 등도 runC에 의존

Podman

리눅스 시스템에서 컨테이너 및 컨테이너 이미지를 실행, 관리, 배포 할 수 있도록 설계된 Daemonless 컨테이너 엔진

• Podman은 Pod Manager tool의 약자
• Rootless 컨테이너와 Pod를 위한 리소스를 실행하고 분리하여 더 손쉽게 액세스 할 수 있는 컨테이너 환경을 만드는 동시에 보안 리스크를 줄일 수 있음
• OCI(Open Container Initiative)를 준수하며 Docker와 거의 대부분의 CLI Command가 동일
• 컨테이너를 관리하기 위해 RESTful API를 배포
  ** Daemon - 서비스 요청에 대해 응답하기 위해 오랫동안 실행중인 백그라운드 프로세스

Docker와 Podman

Daemon 존재 여부

• Docker
  

• Podman
  

Kubernetes

• 쿠버네티스란?
  컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템
  컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼

• 특징

1. 서비스 디스커버리와 로드 밸런싱
2. 스토리지 오케스트레이션
3. 자동화된 롤아웃과 롤백
4. 자동호된 빈 패킹
5. 자동화된 복구
6. 시크릿과 구성관리

• 쿠버네티스 클러스터 구성요소
  

1. Cluster : 컨테이너화된 애플리케이션을 실행하기 위한 일련의 노드 머신의 집합
2. Master : 클러스터 전체를 컨트롤하며 내부에 있는 모든 노드를 관리하는 가상 머신
3. Worker : 마스터에 의해 명령을 받고 실제 컨테이너들이 생성되고 일을 하는 가상 머신

1. kube-api-server : 쿠버네티스의 모든 통신은 kube-api-server를 통해 통신
2. kube-controller-manager : 파드들을 관리하는 각각의 컨트롤러를 제어하는 역할
3. kube-scheduler : 리소스를 자원 할당이 가능한 노드에 할당하는 역할
4. etcd : 클러스터 내의 모든 세부적인 데이터를 저장하는 키-값 저장소
5. cloud-controll-manager : 컨트롤러들을 클라우드 서비스와 연결하여 관리
6. kubelet : 모든 노드에서 실행되며 컨테이너 실행 및 지속적인 헬스체크를 통해 마스터의 kube-api-server와 통신을 하는 에이전트
7. kube-proxy : 클러스터 내부의 가상 네트워크를 설정하여 관리

• Container Runtime Interface(CRI)
  컨테이너 런타임 인터페이스는 쿠버네티스에서 다양한 컨테이너 런타임을 사용할 수 있게 해주는 API

• Kubernetes 배포 도구
  

• Namespace
  

• Resource
  Namespace
  동일한 물리 클러스터 하나를 여러 개의 논리적인 단위로 나누는 리소스

• Service
  클러스터 외부에서 클러스터 내부 파드에 접근 할 수 있도록 IP를 제공하는 리소스

• Volume
  파드의 일부분으로 동일한 파드 내의 컨테이너끼리는 볼륨 공유가 가능하며 컨테이너의 데이터를 보관하여 유지시키는 역할

• Pod
  

1. 컨테이너가 직접 실행되는 장소
2. 컨테이너를 돌리는 최소한의 단위
3. 하나 이상의 컨테이너 그룹
4. 컨테이너를 직접 관리하지 않고 파드 단위로 관리

• Service
  

1. 클러스터 외부에서 클러스터 내부파드에 접근
2. 고정된 IP주소 할당
3. 파드 간의 로드 밸런싱 지원
4. 하나 또는 여러 개의 포트 지원

• Ingress
  

1. 서버 외부로부터 서버 내부로 들어오는 네트워크 트래픽을 로드밸런싱
2. L7 로드밸런싱 기능을 수행
3. Service에 외부 URL을 제공
4. 클러스터로 접근하는 URL 별로 다른 서비스에 트래픽을 분산
5. TLS/SSL 인증서 처리
6. 도메인 기반의 Virtual hosting을 지정

• ReplicaSet
  

1. 파드의 개수 유지 및 관리
2. 실행되는 파드를 안정적으로 유지
3. 파드 개수에 대한 가용성 보장

• Deployment
  

1. 상태가 없는 앱을 배포할 때 사용되는 가장 기본적인 컨트롤러
2. 레플리카셋을 관리
3. 앱의 배포를 세밀하게 관리
4. 파드 개수 유지
5. 배포 시 롤링 업데이트

• StatefulSet 소개
  

1. 동일한 컨테이너 스펙을 가진 파드들을 관리하며 각 파드들은 각각의 식별자를 가지기 때문에 독자성을 유지
2. 파드들의 순서 및 고유성을 보장
3. 식별자를 가지고 있어 재스케줄링 간에도 지속적인 유지
4. 내부 파드마다 고유한 pvc를 갖도록 설정이 가능하여, 스케일 확장시 PV를 유지 가능

• Deployment vs StatefulSet

• Job

1. 여러 파드를 지정하여 지정된 파드를 성공적으로 실행하도록 하는 설정
2. 배치작업, 임시작업 등 처음 한번 실행하고 종료되는 작업에 사용
3. 파드의 성공적인 완료를 보장
4. 단일잡, 다중잡, 병렬잡

• 크론잡

1. JOB을 실행하는데 스케줄러 역할
2. 데이터 백업, 이메일 송신 등 정해진 시간에 맞춰 반복적으로 JOB을 실행해야 할 때 사용
3. 리눅스의 crontab과 비슷

• 데몬셋

1. 클러스터 전체에 특정 파드를 실행할 때 사용하거나 특정 노드 또는 모든 노드에 항상 실행되어야 할 특정 파드들을 관리
2. 전체 노드에서 Pod가 한 개씩 실행되도록 보장
3. 로그 수집기, 모니터링 에이전트와 같이 모든 노드에 항상 실행시켜야 하는 특정 파드를 관리해야 할 때 사용

• 퍼시스턴트 볼륨

1. 특정 파드와 상관없이 별도의 생명주기를 가지는 독립적인 볼륨
2. 프로비저닝은 정적 방법, 동적 방법 두 가지 방법으로 생성
3. PVC로부터 요청이 들어오면 요청에 맞는 PV 할당
4. PV와 PVC 매핑은 1:1 관계로 바인딩

• 퍼시스턴트 볼륨 클레임

1. 사용자가 PV에 하는 요청
2. 파드와 PV를 연결
3. 요청 시 스토리지 용량, 접근방법, 셀럭터 등 설정 가능
4. PV와 PVC 매핑은 1:1 관계로 바인딩

• 스토리지 클래스

1. PV로 확보한 스토리지 종류를 정의 하는 리소스
2. PV의 동적 프로비저닝일 때 사용되며 동적 프로비저닝을 활성화 하려면
   하나 이상의 스토리지 클래스가 미리 생성 되어 있어야함
3. 스토리지 클래스를 미리 정의하면 그에 맞는 PV를 바로 생성할 수 있음

• PV, PVC 생명주기

1. Provisioning : 정적 방법과 동적 방법 두 가지가 있으며 PV를 생성하는 단계
2. Binding : PVC가 원하는 접근방법, 스토리지 용량 등을 요청하면 그에 맞는 PV가 연결되는 단계(맞는 PV가 없으면 대기)
3. Using : 파드가 유지되는 동안 파드에서 설정된 PVC가 계속해서 사용되고 있는 단계
4. Reclaiming : 사용이 끝난 PVC는 삭제되고 사용 중이던 PV는 초기화 되는 과정

• Volume 구조(정적 프로비저닝)
  

• Volume 구조(동적 프로비저닝)
  

• ConfigMap

1. 컨테이너와 분리해서 환경설정 제공
2. 키-값 형태의 설정 정보를 저장하는 일종의 저장소 역할
3. 간단한 문자부터 큰 설정 파일까지 값으로 가질 수 있음
4. 동일한 파드라도 여러 개의 컨피그맵을 사용할 수 있음

• 시크릿

1. 보안유지가 필요한 자격증명 및 개인 암호화 키 같은 정보를 저장 및 관리하는 역할
2. Base64 인코딩으로 생성
3. 키-값 형태의 설정 정보를 저장하는 일종의 저장소 역할
4. 메모리에 저장됨
5. 개별 시크릿의 최대 크기는 1MB까지 정의
6. 모든 파드에는 자동으로 연결된 시크릿 볼륨이 존재

ConfigMap, Secret 사용 방법 소개

쿠버네티스 리소스 관리

• yaml 파일 작성 방법

디폴로이먼트 예시

서비스예시

yaml 파일 통합

Container Platform 도구

• IaC(Infrastructure as Code)
  스크립트를 통해 인프라 및 구성 관리를 자동화 하는 방법론

1. 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝
2. 정보 관리를 위해 별도의 인프라 세트가 필요하지 않음(Masterless)

• Iac 장점

1. 물리적 환경에 대한 세부정보를 추상화 하여 중요한 코드에 집중 가능
2. 비용절감
3. 배포 속도 향상
4. 오류 감소
5. 인프라 일관성 향상
6. 구성 드리프트 제거

• Terraform
  HashiCorp에서 운영 중인 인프라를 손쉽게 구축하고 안전하게 변경하고,
  효율적으로 인프라의 형상을 관리할 수 있는 오픈 소스 도구

1. 플랫폼에 구애 받지 않음
   : 다양한 클라우드 서비스들을 프로바이더 방식으로 제공(AWS, GCP, Azure 등)
2. 변경 불가능 인프라
   : 환경에 대한 변경 사항이 적용될 때마다 현재 구성이 변경을 반영할 수 있는 새로운 구성으로 대체되고 인프라가 다시 프로비저닝됨

• Ansible
  Red Hat에서 개발 중인 프로비저닝, 구성 관리, 애플리케이션 배포, 오케스트레이션 등 여러 수동 IT 프로세스를 자동화하는 오픈소스 IT 자동화 툴

1. 플레이북에 실행할 구성을 선언해 놓으면, 필요시마다 자동 실행 가능
   즉, 웹서버의 구성과, DB서버의 구성을 선언해 놓으면 관리자들은 필요 할 때마다 그 구성대로 서버의 설정을 배포할 수 있음

• Vault
  HashiCorp에서 제공하는 크로스플랫폼 패스워드 및 인증 관리 시스템

1. UI, CLI, HTTP API 등의 인터페이스를 제공하고 있으며, 저장된 비밀 정보를 안전하게 사용할 수 있는 방법들을 제공
2. Vault의 storage backend는 암호화된 데이터를 저장하기 위한 스토리지를 담당하며, 스토리지의 종류, 가용성 등을 책임지지 않음

• Vault 구성요소 체계
  

• Vault 구조
  

• Ceph
  오픈소스 소프트웨어 스토리지 플랫폼

1. 단일 분산 컴퓨터 클러스터에 object 스토리지를 구현하고 object, block 및 file level의 스토리지 기능을 제공

2. Single point of failure이 없는 완전히 분산된 운영을 주소 목표로 하며 엑사바이트 수준으로 scale-out 가능