컨테이너란?
- 하나의 호스트에서 컨테이너 이미지를 각각 격리된 별도의 프로세스로 실행시켜주는 경량 가상화 기술
- 컨테이너에 OS가 포함되어 있다.
- 작은 용량, 빠른 속도 (VM에 비해)
컨테이너 핵심 동작 원리
- LXC(Linux Container)
- LXC는 단일 컨트롤 호스트 상에서 여러 개의 격리된 리눅스 시스템(컨테이너)들을 실행하기 위한 OS레벨 가상화 방법
- 운영 체제로 보면 컨테이너 이미지는 실행파일, 컨테이너는 프로세스
- 리눅스 커널은
- cgroups를 통해 프로세스별 자원 할당을 관리(CPU, 메모리, 블록 I/O, 네트워크 등)
- namespace를 통해 장치를 격리해서 관리(프로레스 트리, 네트워크, 사용자 ID, 마운트된 파일 시스템 등)
도커란?
- 도커: Linux, MacOS, Windows에서 동일한 방법으로 컨테이너를 실행시키고 관리할 수 있는 방법을 제공
- 도커 파일(Dockerfile): 컨테이너 이미지를 자동으로 빌드할 수 있도록 지원하는 스크립트
- 도커 허브(Docker Hub): 컨테이너 이미지를 저장하는 깃헙과 같은 공개 저장소의 역할
컨테이너 오케스트레이터
- 서버 1대에서는 도커만으로 충분, 하지만 관리해야할 서버가 수천대라면 컨테이너 오케스트레이터가 필요하다.
- 대표적인 예가 쿠버네티스이다.
쿠버네티스의 주요 기능
- 대규모 분산 서버 환경에서 컨테이너 관리를 자동화하는 유연하고 확장성 있는 오픈소스 플랫폼
- 쿠버네티스란 명칭은 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어에서 유래
- 업데이트가 일어났을 때 서버중단없이 이전서버와 새로운 서버를 동시에 운영할 수 있다.
- 분산된 서버를 손쉽게 다룰 수 있다.
- k와 s 사이에 스펠링이 8개라서 k8s라고 불리기도 함
- 컨테이너 배포, 자동 복구, 확장 등 컨테이너화된 애플리케이션의 관리를 위한 오픈소스 시스템
- 컨테이너 오케스트레이터의 사실상의 표준 기술, 크고, 빠르게 성장하는 생태계를 가짐
- Google Cloud GKE(Google Kubernetes Engine)
- AWS Elastic Container Service(ECS) → EKS( Elastic Kubernetes Service)
- MS Azure Container Service(ACS) → AKS(Azure Kubernetes Service)
→ 쿠버네티스 애플리케이션은 노트북에서부터 전세계 클라우드에서도 그대로 동작 가능
쿠버네티스의 아키텍처
- Master & Slave 아키텍처 (젠킨스?)
마스터는 보통 3대나 5대로 운영
3대
- 1개의 장애까지 문제없이 운영
5대
- 2대의 장애까지 문제없이 운영
- 가용성이 필요한 서비스의 경우
- 1대의 장애시 1대는 장애 재현, 원인 분석, 1대는 서비스 운영
마스터노드에 설치되는 주요 컴포넌트
- kube-apiserver: 모든 요청을 받고, etcd에 저장
- kube-controller-manager: 실제 Resource 관리를 수행하는 컨트롤러들의 집합
- kubelet: Worker Node의 에이전트로서 Node와 Pod의 상태 파악과 실행, 보고
- ectd: 모든 오브젝트의 상태를 저장하는 key/value 저장소 (쿠버네티스의 DB)
- cube-scheduler: 새 pod의 생성을 관찰하여 스케줄링
워커노드에서 동작하는 컴포넌트
- Kubelet
- 워커 노드에 설치되는 에이전트
- kube-apiserver에 연결되어 마스터의 명령을 받아 컨테이너를 실행 및 관리
- kube-proxy: Service 트래픽을 Pod로 연결
- container-runtime: 컨테이너의 실행 환경 ex) docker, containerd
쿠버네티스의 아키텍처 및 동작원리
- Declarative API( 선언형 API) = Object와 Controller
- 위 사진은 쿠버네티스 리소스 오브젝트 yaml 파일
- api Version
- 오브젝트 스키마의 버전
- 컨트롤러는 버전별 호환성을 지원하기 위해 여러가지 버전을 처리해야 한다
- 이 때 이 정보를 참조하여 버전별로 알맞은 동작을 수행한다.
- kind
- 오브젝트 종류
- 개별 쿠버네티스 컨트롤러는 본인이 처리해야할 타입의 오브젝트의 변활를 항상 감시하고 있다.
- 예를 등어 Deployment 컨트롤러는 etcd에 저장된 데이터들 중에서 kind가 Deployment인 오브젝트의 업데이트에 대한 변화 이벤트만 항상 감시하고 있다가 적절한 동작을 실행한다.
- metadata
- 해당 리소스 오브젝트에 대한 메타데이터를 저장하는 필드이다.
- 해당 리소스에 대한 이름과 네임스페이스 정보 등이 관리되며 쿠버네티스에서 리소스 이름과 네임스페이스의 조합은 항상 유니크 하다.
- 따라서, 쿠버네티스 클러스터 내의 리소스를 구별할 때는 오브젝트의 종류와 이름, 네임스페이스의 조합을 통해 구별할 수 있다.
- spec
- 사용자가 원하는 리소스의 상태
- status
- 쿠버네티스가 조사한 현재 리소스의 실제 상태
쿠버네티스의 주요 오브젝트
- Pod: 쿠버네티스의 기본 배포 단위로 하나 이상의 컨테이너를 포함하는 컨테이너 그룹
- ReplicaSet: Pod의 복제본을 생성하고 관리
- Deployment: ReplicaSet을 관리하며, Pod의 롤링 업데이트나 롤백을 수행
- Service: Pod을 연결하고 서비스 디스커버리를 제공
- Ingress: 클러스터 외부에서 Service에 접근할 수 있도록 하는 API 오브젝트
- ConfigMap: 클러스터 외부에서 Service에 접근할 수 있도록 하는 API 오브젝트
- Secret: 애플리케이션의 보안 정보를 저장
- PersistentVolume: Pod에서 사용할 수 있는 스토리지를 관리
- StatefulSet: Pod를 개별적인 ID와 함께 관리
- DaemonSet: 모든 노드에 Pod을 실행하고 관리
- Cronjob: 스케줄링된 작업을 관리
- Job: 일회성 작업을 관리
파드(Pod)
- 파드는 언제나 노드상에서 동작(노드에서 실행되는 컨테이너로서 동작)
- 하나의 노드는 여러 개의 파드를 가질 수 있음
- Pod추상화를 통한 장점
- pause 컨테이너를 통해 namespace를 공유함으로서 Pod 내부의 컨테이너들은 Pod외부와 격리된 컨테이너의 장점을 유지하면서, Pod 내부에서는 네트워크와 스토리지 자원을 공유
- 단일 컨테이너를 단일 목적으로 분리하기 더 쉬워짐
디플로이먼트(Deployment)
- 애플리케이션 인스턴스를 생성하고 업데이트 하는 역할 담당
- 실제 배포할 때 사용
- 업데이트를 용이하게 관리
- 레플리카셋을 이용하여 중간계층을 두어 업데이트와 롤백을 쉽게 할 수 있다.
서비스(Service)
- pod는 언제든 죽을 수 있다 → pod IP를 그대로 사용하기 어려움
- 이런 짧은 생명 주기의 pod IP를 사용하지 않고, 고정된 단일 엔드 포인트를 제공하자 → Service
- 여러개의 pod를 하나의 엔드포인트 접근할 수 있도록 해줌
- 서비스의 4가지 타입
- ClusterIP(default): 디폴트 타입이다. ClusterIP는 클러스터 내부에서만 사용가능하며, 클러스터 냅 Pod나 Node에서만 접글할 수 있다.
- NodePort: 클러스터의 모든 노드에 특정 포트를 해당 서비스로의 연결로 노출시키는 방법이다. 예를 들어 NodePort를 선언하고 35000번 포트를 할당 받았다면 클러스터 내 모든 노드의 35000번 포트를 접근하면 연결된 Pod로 로드밸런싱해준다.
- LoadBalancer: 클라우드 서비스 제공업체의 로드밸런서를 이용하여 외부에서 접근할 수 있는 External IP를 부여받을 수 있다.
- External Name: External Name은 외부 도메인 주소를 쿠버네티스 클러스터 안에서 고정된 서비스의 네임으로 사용하기 위해서 사용
- 서비스의 I는 서비스의 Name이 자동으로 클러스터 DNS에 등록되므로 클러스터 내부에서는 서비스 Name만으로 고정된 엔드포인트의 통신이 가능함
- 서비스를 생성하면 생기는 단일 엔드포인트인 IP는 2가지로 나눌 수 있다.
- Cluster IP: 클러스터 내부에서만 사용 가능(pod/node 안에서만 가능)
- External IP: 클러스터 외부에서 사용 가능(LoadBalancer Type 서비스)
인그레스(Ingress)
- 인그레스는 클러스터 내부 서비스에 대한 외부 접글을 관리하는 오브젝트
- L7 Proxy를 쿠버네티스 네이티브한 리소스로 관리할 수 있게 하자 → Ingress
- 다양한 라우팅 룰 설정 가능
- SSL 인증서 적용
- Rate Limit
- …
- 반드시 “인그레스 컨트롤러”도 같이 배포해 주어야 동작함(ex. ingress nginx controller)
- 프록시별 여러가지 구현제가 있음(카카오 DKOS는 nginx ingress controller 사용)
카카오의 컨테이너 사용
- 카카오의 DevOps 조직 구성
- 개발팀 = 운영팀
- 짠 코드를 직접 운영한다.
- 모든 개발자가 Weekly On-call 참여
- 장점: 서비스 품질이 좋아진다, 코드 품질이 좋아진다. 온콜 때 살아남기 위해 운영을 고려한 코드 작성
- 빠른 대응: 온콜 담당자가 코드 레벨까지 이슈 추적, 빠른 패치
Automation First: 운영 업무의 발견(인지)에서 해결까지 이벤트 기반 자동화
카카오의 마이크로서비스(MSA)
- MSA가 최신 트렌드 아키텍처라고 항상 옳거나 모든 문제를 해결하는 만능키는 아님
- 서비스 별, 조직 별 특성을 반영하여 상황과 요구사항에 맞는 다양한 아키텍처 패턴 사용\
'I leaned > Etc' 카테고리의 다른 글
BDD 패턴(테스트 코드작성) (0) | 2023.07.10 |
---|---|
CSRF, XSS, CORS (1) | 2023.07.10 |
클라우드 네이티브 애플리케이션 개발 (0) | 2023.07.05 |
클라우드 서비스 (0) | 2023.07.05 |
Redis (0) | 2023.06.27 |