Study

이번에는 쿠버네티스에서 데이터를 저장하는 Volume을 정리해보도록 한다. Volume 컨테이너가 데이터를 저장하고 공유하는 방식을 제공하는 객체, 기존 컨테이너에서의 Volume과 유사하나 더 유연하게 사용할 수 있다. 이전의 Service를 정리했을때에 알아보았듯이 컨테이너는 일시적인 특성을 가져 일반적으로 컨테이너가 삭제되면 컨테이너에 저장된 내용들이 휘발되는 점이 존재한다. 특히나 데이터베이스와 같은 리소스는 파드나 컨테이너가 삭제되더라도 내부의 데이터를 보존을 해주어야하는데, 여기서 Volume을 사용하게 된다. 쿠버네티스에서 제공하는 Volume의 종류는 아래와 같다. emptyDir hostPath PV/PVC emptyDir 파드 내에서만 지속되는 컨테이너의 임시적인 데이터를 저장하기 위한..

Service 파드 집합에서 실행중인 Application을 네트워크 서비스로 노출시키는 방법, 네트워크 추상화를 제공해 동적으로 할당된 파드에 접근할 수 있는 리소스이다. Service의 목적 왜 이런 리소스가 필요할까? 서비스 리소스가 필요한 이유를 일반적인 상황을 통해서 알아볼 수 있다. 웹 Application을 구동시키는 클러스터를 운영하고 있다고 가정해보자. 그리고 이 Application이 Deployment나 StatefulSet을 통해 여러 파드로 분산되어 실행되고 있다고 할 때, 일부 파드가 재생성되는 상황을 생각해보자. 파드가 영구적이지 않은 특성(일회성)을 가짐에 따라, 클러스터의 상황에 따라 언제든지 다른 노드들로 옮겨질 가능성이 존재한다. 이렇게 다른 노드로 옮겨져 생성되면, 매..

쿠버네티스의 리소스 오브젝트를 생성하는 방법에는 kubectl CLI 커맨드로 생성하는 방법과 Manifest 파일을 적용해 생성하는 방법 2가지가 존재한다. 이번에는 Manifest 파일과 이를 통해 리소스 오브젝트를 생성하는 방법을 알아보도록 한다. Manifest 파일 Manifest 파일은 YAML / JSON 포맷으로 작성되는 쿠버네티스 리소스 오브젝트의 구성을 정의하는 파일이다. 생성하고자하는 쿠버네티스 오브젝트를 파일에 정의한 후, kubectl apply를 통해 클러스터에 Manifest 파일을 적용한다. kubectl apply -f ./deployment.yml apply 명령어로 마스터 노드에 있는 쿠버네티스 API 서버에 Manifest 파일 내용을 전달하고, 파일의 유효성을 검사한..

앞서 쿠버네티스의 전체적인 아키텍처와 클러스터, 노드, 파드를 알아보았다. 이번에는 쿠버네티스의 워크로드 리소스들을 정리해보고자한다. 먼저 쿠버네티스에서 워크로드는 클러스터에서 실행되는 Application을 의미하며, 이러한 하나의 워크로드는 파드 집합으로 구성된다. 주요 워크로드 리소스에는 ReplicaSet(레플리카셋), Deployment(디플로이먼트), StatefulSet(스테이트풀셋), DaemonSet(데몬셋)이 존재한다. ReplicaSet 레플리카셋은 파드의 수를 일정하게 유지시키는 데에 목적을 둔 워크로드 리소스이다. 그렇기 때문에 파드에 대한 가용성(Avability)을 보장한다고 볼 수 있다. 다음은 레플리카셋을 정의하는 매니페스트 파일이다. apiVersion: apps/v1 k..

그동안 참 많이도 들었던 쿠버네티스, 이제서야 공부를 시작하게 되었다. 쿠버네티스는 단어나 개념 정리할 것들이 많은 편이다. 가장 큰 개념부터 하나하나씩 알아가보도록 한다. 쿠버네티스란? 쿠버네티스는 컨테이너 오케스트레이션 도구로 여러대의 서버에 컨테이너화된 Application을 배포 / 관리 / 확장할 수 있는 기능을 제공한다. 쿠버네티스는 구글이 개발한 borg라는 도구에서 발전된 형태로, 2015년 출시 이후 CNCF 재단에 오픈소스로써 제공했다고 한다. 쿠버네티스와 도커? 컨테이너를 관리하는 도구라는 점에서 쿠버네티스와 도커는 유사하다고 볼 수 있다. 다만 서로 주요 목적과 역할이 다를 뿐이라는 점을 확인해야한다. 도커는 단일 호스트 환경에서 컨테이너를 빠르고 간편하게 실행하는데에 주된 목적이 ..

가상화에는 하이퍼바이저 가상화와 컨테이너 가상화, 2가지 유형이 존재한다. 이번 글에서는 컨테이너 가상화에 대해 알아보도록 한다. 컨테이너 하드웨어에 설치된 커널 하나에 격리된 컨테이너 프로세스를 돌리는 구조로 OS 수준의 가상화를 제공한다. 무겁고 느린 hypervisor 가상화 방식의 단점을 해결하기위해 등장했다. 컨테이너는 애플리케이션과 그에 종속되는 것들을 패키지화하고 실행환경을 격리하는데에 목적을 둔다. 각 컨테이너들을 호스트 OS의 리소스를 공유하며, 필요한 라이브러리와 실행 파일만을 포함하고 있어 하이퍼바이저 가상화의 가상머신(VM)보다 가볍게 구동될 수 있다. 컨테이너 가상화의 특징으로는 아래와 같다. 특징 설명 성능과 자원 효율성 가상머신(VM)에 비해 낮은 오버헤드와 빠른 부팅 시간 이..

ALB나 cloudfront를 이용하다 보면 HTTP/2를 지원하는 것을 확인할 수 있다. HTTP/2는 HTTP/1.1에 비해 빠르다는 것 정도만 알고 있다. 이 두 버전을 비교해보며 HTTP/2에서는 정확히 어떤 것들이 개선되었는 지를 비교해본다. HTTP/1.1 1997년에 릴리스된 프로토콜로 클라이언트와 웹 서버간의 정보를 교환하는 Layer 7의 프로토콜이다. HTTP/1.1에서는 기존 1.0과 비교해 아래 2가지 특징을 가진다. Persist Connection 기존 1.0 버전에서는 TCP 3way hand-shaking을 거쳐 HTTP Connection이 이루어졌다. 즉, 매 Connection을 생성할때마다 hand-shaking이 이루어지고, 큰 overhead로 작용되었다. (RTT..

방화벽은 설정한 Rule에 따라 진입되는 패킷을 Pass할 것인지, Drop할 것인지 필터링해주는 유해한 트래픽을 차단하기위한 하드웨어 내지 서비스이다. 대부분의 방화벽은 정책 기반으로 트래픽을 필터링한다. 방화벽의 발전 과정이나 구조별 유형 등의 설명거리가 있지만, 여기서는 크게 다루지 않는다. 이번에 정리할 개념은 방화벽에서의 Stateful과 Stateless 유형이다. 이 둘을 각각 예시와 함께 비교하며 알아본다. Stateful / Stateless 외부 네트워크(클라이언트)에서 내부 네트워크(서버)로 접속하는 트래픽을 가정해보자. 클라이언트가 서버로 요청을 날리는 Request와 해당 Request에 대한 클라이언트로 날라가는 Response가 존재할 것이다. 웹 서버로 들어오는 트래픽이 방화..