문홍의 공부장

Ingress Ingress HTTP(S) 기반의 L7 로드밸런싱 기능을 제공하는 컴포넌트. 외부로부터 서비스 호출(요청) 시, ingress 를 걸쳐 Service 로 접근하게 된다. url 라우팅 path 에 따라 service 에 맞추어 연결한다 Ingress Controller Ingress 에 정의된 규칙을 실제 동작하도록 하는 컨트롤러.

Statefulset Statefulset 은 Pod를 Scaling Up/Down 또는 Deploy 할 때, 각 파드의 기존 스펙을 유지시켜준다. 즉, Statefulset 은 sticky 값을 유지하고 생성할 때 기존 값을 사용하여 그대로 만들어준다. 안정적이고 고유한 네트워크 식별자 사용 안정적이고 지속적인 스토리지 사용 안정적인 파드 배치 및 확장, 자동 롤링 업데이트 설정 Statefulset app. web server: 모든 application 이 같은 역할을 함 (단순 복제), 하나의 볼륨에 모두 연결 가능 Statefulset app. database: 각 application 마다 다른 역할을 하며, 애플리케이션 특징에 맞게 트래픽이 분산됨. 애플리케이션마다 각각 다른 볼륨 사용 ap..

Service Headless Service 서비스는 접근을 위해 ClusterIP 또는 ExternalIP 를 지정받는다. 즉, 서비스를 통해 제공되는 기능들에 대한 엔드포인트를 쿠버네티스 서비스를 통해 통제하는 개념인데, MSA 에서는 기능 컴포넌트에 대한 엔드포인트를 찾는 기능을 Service Discovery 라 하고, 서비스의 위치를 등록해놓는 서비스 디스커버리 솔루션을 제공한다. (Etcd, consul 등) 이 경우, 쿠버네티스 서비스를 통해 컴포넌트를 관리하는 것이 아니라, 서비스 디스커버리 솔루션을 사용하기 때문에, 서비스에 대한 IP 주소가 필요없다. 이러한 시나리오를 지원하기 위한 쿠버네티스의 서비스를 Headless Service 라 한다. Headless Service 생성 시, ..

Pod Lifecycle 파드는 아래의 생명주기를 가진다. Pending 최초의 단계 Status는 Phase, Conditions, Reason 으로 구성됨 Phase: Pending, Running, Succeeded, Failed, Unknown Conditions: Initialized, ContainerReady, PodScheduled, Ready Reason: ContainersNotReady, PodCompleted 컨테이너를 초기화하고, 노드 스케쥴링을 설정 Running Pending 이후 파드가 실행되는 단계 Succeeded Job/CronJob 으로 생성된 파드의 경우, 일을 마치면 더이상 돌지(Running) 않고 Succeeded / Failed 상태로 전환 파드의 모든 컨테이..

k8s Architecture 쿠버네티스는 중앙(Master)에 API 서버와 상태 저장소를 두고, 각 서버(Node)의 에이전트(kubelet) 과 통신하는 구조. master: 전체 클러스터를 관리하는 서버 node: 컨테이너가 배포되는 서버 Master 구성 요소 API 서버 (kube-apiserver): 모든 요청을 처리하는 API 서버 분산 데이터 저장소 (etcd): key-value 저장소 스케쥴러, 컨트롤러 (kube-scheduler, kube-controller-manager, cloud-controller-manager) Node 구성 요소 kubelet: 노드에 할당된 파드의 생명주기 관리 kube-proxy: 파드로 연결된 네트워크 관리 추상화: 컨테이너(containerd, r..

kubernetes (k8s) 쿠버네티스 = 컨테이너 오케스트레이션 도구 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼 여러 개의 서버에 컨테이너를 배포/운영 가능 (한 번에 하나의 서비스만 배포 가능한 도커 대비 강점) MSA, Cloud platform 지향 WHY k8s? 작은 수의 컨테이너라면 수동으로 VM이나 하드웨어에 직접 배포하면 되지만, VM이나 하드웨어의 수가 많아지고 컨테이너의 수가 많아지면, 이 컨테이너를 어디에 배포해야 하는지에 대한 결정이 필요하다. 자원을 최대한 최적으로 사용하기 위해서 적절한 위치에 배포해야 하고, 애플리케이션 특성들에 따라서, 같은 물리 서버에 배포가 되어야 하거나 또는 가용성을 위해서 일부러 다른 물리서버에 배포되어야 하는 일이 있..

chapter04. 도커 컴포즈 4.1 도커 컴포즈 매번 run 명령어에 옵션을 더해 CLI로 컨테이너를 생성하기 보다는, 여러 개의 컨테이너를 하나의 서비스로 정의해 컨테이너 묶음으로 관리하는 것이 더욱 편리하다. 도커 컴포즈는 컨테이너를 이용한 서비스의 개발과 CI를 위해 여러 개의 컨테이너를 하나의 프로젝트로서 다룰 수 있는 작업 환경을 제공한다. 여러 개의 컨테이너의 옵션과 환경을 정의한 파일을 읽어 컨테이너를 순차적으로 생성한다 run 명령어의 옵션을 그대로 사용 가능하며, 컨테이너의 의존성, 네트워크, 볼륨 등을 함께 정의할 수 있다 스웜 모드와 유사하게, 컨테이너 수를 유동적으로 조절할 수 있으며, 디스커버리도 자동으로 설정 가능하다 4.2 도커 컴포즈의 활용 1. 설치 & 버전 확인 # c..

chapter03. 도커 스웜 1. 도커 스웜 도커 스웜 = 도커 서버의 확장. 도커 서버를 하나의 클러스터로 만들어 컨테이너를 생성, 기능을 제공한다. 또한, 스웜 클러스터에 등록된 서버의 컨테이너를 쉽게 관리할 수 있다. 2. 도커 스웜의 종류 스웜 클래식 (컨테이너로서의 스웜) 여러 대의 도커 서버를 하나의 지점에서 사용하도록 단일 접근점을 제공 일반적인 도커 명령어(docker run, docker ps 등)와 도커 API로 클러스터 서버를 제어하고 관리하는 기능을 제공 분산 코디네이터, 에이전트 등의 클러스터 툴이 별도로 실행되어야 함 스웜 모드 MSA 컨테이너를 다루기 위한 클러스터링 기능에 초점 같은 컨테이너를 동시에 여러 개 생성하여 유동적으로 컨테이너 수를 조절 컨테이너로의 연결을 분산하..