![]()
시나리오가비아로 구매한 도메인을 버셀로 배포된 프론트와 EC2에 배포된 백과 연결하려고 한다. 이때 프론트는 www.도메인.com의 서브 도메인일 때, 백은 api.도메인.com의 서브 도메인일 때 전달되어야 한다. 또한, 버셀에서는 http로 API 연결하는 게 불가능하므로 백은 https로 배포되어야 한다. 그림으로 따지자면 아래와 같은 상황이 된다.작업 0: 도메인 발급 및 배포가비아에서 도메인 구매, 버셀에서 프론트 배포, 그리고 EC2에 백 배포는 이미 되어 있다고 가정한다.작업 1: Route53 생성먼저 Route53을 생성해야 한다. Route53은 클라우드 도메인 이름 시스템(DNS) 서비스로, 도메인 이름을 AWS 내부/외부 서비스로 매핑하기 위해서 사용된다. Route53에서 호스팅 ..
Use kubectl to see a list of Pods in a cluster kubectl 명령어를 통해서 쿠버네티스를 관리하는 일련의 과정은 어떻게 이루어지는 것일까? 클러스터에 대한 권한을 가지고 있는 관리자가 kubectl 명령어를 치면, kubectl은 이를 command line 명령어에서 API call로 변경한다. 이는 HTTPS를 통해 쿠버네티스 제어 영역의 kube-apiserver로 보내진다. kube-apiserver는 해당 request를 etcd에 쿼리를 던짐으로서 처리한다. 처리된 결과는 다시 kube-apiserver를 통해서 다시 kubectl에게 전달되고, 이 결과가 관리자에게 command prompt를 통해 전달된다. Kubectl must be configure..
Kubernetes Object yaml 다음과 같은 yaml 파일이 있다고 가정해보자. 이때 yaml 파일의 각 구성요소 의미는 다음과 같다. apiVersion: apps/v1 kind: Pod metadata: name: nginx uid: 432432dkfdf-dflsf-sdfks-2erdsfnsdlk labels: app: nginx env: dev stack: frontend spec: containers: - name: nginx image: nginx:latest apiVersion: 어떤 쿠버네티스 api를 객체 생성에 사용할지를 결정한다. kind: 생성하고자 하는 객체를 명시한다. metadata: 쿠버네티스 객체를 구분할 수 있는 ID나 네임스페이스 등을 명시한다. uid: 쿠버네티..
There are two elements to Kubernetes objects 쿠버네티스에는 두 가지 중요한 컨셉이 있다. 객체의 스펙과 상태이다. 먼저 쿠버네티스의 객체란 무엇일까? 쿠버네티스에서 객체(Object)는 쿠버네티스 클러스터 내에서 관리되는 배포 가능한 엔터티를 나타낸다. 이러한 객체는 클러스터 내의 다양한 리소스를 정의하고 관리하는 데 사용된다. 쿠버네티스에서는 이렇게 사용할 객체의 ‘원하는 상태(desired status)’를 유지하는 것이 중요하다. 예를 들어, Pod이라는 객체가 있고, 이 객체가 3개 running 중인 상태를 유지해야 하는 상황이라고 하자. 이 상태를 유지하기 위해서는 사용자는 사용할 각 객체에 대한 스팩을 쿠버네티스에 제공해야 한다. 이 스팩을 통해 원하는 특..
The VM-centric way to solve this problem VM은 어떤 방식으로 동작할까? 가상 머신은 하이퍼바이저(Hypervisor)라는 소프트웨어 계층 위에서 동작한다. 하이퍼바이저는 호스트 시스템의 하드웨어 리소스를 가상화하고, 각 가상 머신은 독립된 운영 체제와 커널을 가지며, 이 운영 체제는 하이퍼바이저의 관리하에 실행된다. 커널 관점에서 가상 머신은 물리적인 하드웨어 리소스에 직접 접근하지 않는다. 가상 머신의 각 운영 체제는 가상화된 하드웨어에서 동작하며, 각 운영 체제는 자체 커널을 가지고 있다. 이러한 커널은 하이퍼바이저와의 상호 작용을 거쳐 하드웨어 자원에 액세스한다. 이런 원리로 운영되기 때문에 하이퍼바이저와 가상 머신 간에는 추가적인 오버헤드가 발생하게 된다. 그런데..
