Docker & kubernetes

컨테이너란?

• 하나의 호스트에서 컨테이너 이미지를 각각 격리된 별도의 프로세스로 실행시켜주는 경량 가상화 기술
• 컨테이너에 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가 최신 트렌드 아키텍처라고 항상 옳거나 모든 문제를 해결하는 만능키는 아님
• 서비스 별, 조직 별 특성을 반영하여 상황과 요구사항에 맞는 다양한 아키텍처 패턴 사용\