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..
👷♂️DevOps
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)라는 소프트웨어 계층 위에서 동작한다. 하이퍼바이저는 호스트 시스템의 하드웨어 리소스를 가상화하고, 각 가상 머신은 독립된 운영 체제와 커널을 가지며, 이 운영 체제는 하이퍼바이저의 관리하에 실행된다. 커널 관점에서 가상 머신은 물리적인 하드웨어 리소스에 직접 접근하지 않는다. 가상 머신의 각 운영 체제는 가상화된 하드웨어에서 동작하며, 각 운영 체제는 자체 커널을 가지고 있다. 이러한 커널은 하이퍼바이저와의 상호 작용을 거쳐 하드웨어 자원에 액세스한다. 이런 원리로 운영되기 때문에 하이퍼바이저와 가상 머신 간에는 추가적인 오버헤드가 발생하게 된다. 그런데..
Understanding regions and zones GCP에서 전세계에 가지고 있는 물리적인 데이터 센터는 3개의 단위로 나뉜다. 멀티 리전, 리전, 그리고 컴퓨팅 영역이 바로 그 단위이다. 우선 가장 크게는 멀티 리전(대륙 단위의 구분)으로 나뉘는데, 이는 유럽, 미국, 그리고 아시아 태평양이다. 이 멀티 리전 안에서 독립적인 지리적 위치로 구성되는 구분 단위를 리전이라고 한다. 이때 GCP가 실제로 가지고 있는 물리적인 데이터 센터와 내가 서비스를 호스팅하고 있는 지역이 가까울수록 네트워크 지연이 적기 때문에 리전을 가까운 곳으로 설정하는 것이 중요하다. 내가 한국에서 서비스를 제공하고 있다면, 당연히 Seoul 리전에 인프라를 구성해 놓아야 네트워크 지연이 적어질 것이다. GCP에서는 공식적으..
