본 내용은 2022년 10월 진행한 Google Cloud StudyJab에서 제공하는 Coursera의

• Architecting with Google Kubernetes Engine: Foundations
• Architecting with Google Kubernetes Engine: Workload
• Architecting with Google Kubernetes Engine: Productions

내용을 정리하였음

Foundation

Cloud Computing and Google Cloud

클라우드의 5가지 fundamental

• On-demand and self-service: No human intervention needed to get resources
  주문형, 셀프 서비스. 별도 사람의 개입 없이 자동화된 인터페이스를 사용하여 리소스(컴퓨트, 스토리지, 네트워크 등)를 바로바로 사용할 수 있음
• Broad network access: Access from anywhere
  인터넷만 연결되있다면 접속이 가능함
• Resource pooling: Provider shares resources to customers
  Rapid elasticity: Get more resourcees quickly as needed
  Measured service: Pay only for what you consume
  항장 준비되어있고, 언제든지 고객의 필요에 따라 사용할 수 있는 거대한 리소스 풀을 제공하며, 고객은 물리적 리소스에 대한 걱정을 할 필요가 없음. 언제든지 확장 가능하며 사용하거나 예약한 만큼만 비용을 지불하고, 필요없어진다면 언제든지 삭제하고 비용지불을 멈출 수 있음.

일반적으로 잘 알려진 Virtual machine 부터 Kubernetes 까지 다양한 managed service를 이용할 수 있다.

• Compute Engine : GCP에서 제공하는 On demand Virtual Machine 서비스.
• GKE, Google Ckubernetes Engine : GCP에서 제공하는 Managed Kubernetes.
• App Engine : GCP에서 제공하는 Fully Managed Platform as a Service Framework. 코드만 업로드 하면 인프라 걱정없이 바로 구동시킬 수 있다.
• Cloud Functions : Serverless execution environment, Functions as a Service. 함수로써 동작할 코드만 넣으면 동작시킬 수 있으며 실행 횟수에 따라 비용을 지불한다.

GKE는 Compute Engine 기반으로 설계되었다. GCP에서 데이터베이스를 이용하려면 Compute Engine으로 VM을 만들어서 직접 database를 설치하거나 또는 GKE에서 데이터베이스 컨테이너를 구동시킬 수 있다.

이 방법 외에도 GCP 제공하는 fully managed database와 storage service를 이용하는 방법도 있다. 이런 방법은 직접 서버, 데이터베이스를 구성하는 수고를 줄여주며 relational 또는 non-relational database를 포함한 다양한 형태의 데이터베이스, 서비스들을 이용할 수 있다.

또한 빅데이터, 머신러닝을 위한 다양한 서비스를 GCP에서 제공하며, 이런 서비스를 이용해 다양한 루틴 작업들을 줄일 수 있다.

Resource Management

GCP에서 사용하는 다양한 서비스의 물리 장치(서버, 하드드라이버 등)는 전 세계의 구글 데이터센터에 펼쳐져있다. GCP는 multi-region, region, zone에 있는 리소스들을 제공한다.

• multi-region : 3개로 나누어진 GCP 영역. America, Europe, Asia Pacific 으로 나뉜다.
• region : 같은 대륙에서 지역적으로 나누어져있는 지역. 왕복 네트워크시간 95%가 ms 미만. ex) europe-west2
• zone : region 안에서 한 지역에 있는 장소. 한곳에 있는 데이터센터들이라고 볼 수 있음. ex) europe-west2-a/b/c

GCP의 compute engine의 인스턴스는 특정 zone에 배치된다. 만약 해당 zone의 상태가 unavailable 상태가 되면 compute engine도 같이 unavailable 상태가 되며, compute engine을 기반으로하는 GKE도 똑같이 영향을 받는다. 이런 리소스를들을 배포할 때 여러 zone에 배치를 한다면 예상치 못한 사고에 내결함성을 가질 수 있게 된다. 전세계의 40%의 인터넷 트래픽을 담당(추정)하는 구글 네트워크는 전세계에 배치된 데이터센터간에 매우 빠른 속도와 짧은 지연시간을 지원하고, 구글의 edge caching network는 이러한 네트워크망을 기반으로 GCP의 서비스들을 매우 빠르게 서비스한다.

대부분의 GCP 서비스들은 Zonal resources(기본적으로 single zone에 배치되는)이다. zonal level, regional level, multi-regional level이 있다. GKE의 node는 zonal resource이며 GKE는 regional level이다. multi-regional level로는 HTTP load balancer, Virtual Private Cloud 등이 있다.

리소스들은 반드시 project에 속한다. project는 GCP에서 조직 구성의 기본 단위이며 리소스, 서비스, 빌링, API, 권한을 설정할 수 있다. 프로젝트들은 변경이 불가능한 고유의 아이디와 넘버를 가진다. 사용자가 지정한 라벨을 통해 프로젝트를 필터링할 수 있다.

프로젝트들은 folder에 속할 수 있으며 폴더는 또 다른 폴더로 들어갈 수 있다. 최상위 grouping 단계는 organization이다. 고유의 변경불가능한 id 값을 가지며 만약 기업이라면 기업의 전체 GCP의 policy를 설정하는 등을 할 수 있다. 이러한 정책들은 하이라키 구조로 하위 레벨 구성에 상속된다.

빌링은 프로젝트 레벨에서 측정될 수 있다.

Billing

빌링은 프로젝트 단위로 누적되며, 프로젝트 설정 시 billing account를 설정해야 한다. 빌링 계정은 결제 정보등 결제와 관련된 모든 정보를 담고있다. 하나 또는 다수의 프로젝트를 빌링 계정에 연결할 수 있다. 매달 또는 임계치에 다다를 때마다 자동으로 청구된다. subaccount를 만들어서 프로젝트별로 결제를 담당할 수 있다. 예를들어 GCP의 리소스를 만들어서 다른 여러 회사들에 판매할 때 활용될 수 있다.

빌링 사고를 방지하기 위해 3가지 무료 빌링 서비스를 사용할 수 있다.

• Budgets and alerts
  프로젝트 또는 빌링 계정 단위로 budget을 설정하고 설정한 budget에 대한 알람을 설정할 수 있다.
  예를들어 100원의 예산을 설정하고 90%에 대한 알람을 설정하면 90원이 되었을 때 메일로 알람이 오도록 설정할 수 있으며 webhook을 설정해 resource를 삭제하는 등의 트리거도 설정할 수있다.
• Billing export
  세부 사항을 출력할 수 있으며 big query 등을 설정할 수 있다.
• Reports
  프로젝트 또는 서비스별 빌링 상황을 시각화하여 볼 수 있다.

Quotas(할당량)으로 제어할 수 도 있다. 할당량의 종류는 아래와 같은 타입이 있다.

• Rate Quota
  GKE API : 100초당 1000번의 리퀘스트만 받음
• Allocation Quota
  프로젝트당 5개의 private network 만 허용
• 각각의 서비스별로 다양한 quota를 설정할 수 있음

Interacting with Google Cloud

• Google Cloud Console
  Web-based GUI 제공. 프로젝트와 리소스들을 시각화하고 마우스 클릭으로 작업들을 실행할 수 있음
• Cloud SDK
  gcloud, kubectl, gsutil, bq 등 툴을 포함하고있는 cloud sdk를 머신에 설치해서 사용가능. 스크립트로 이런 명령어를 사용해서 자동화할 수 있음.
• Cloud Shell
  브라우저에서 gcp resource에 CLI 기반으로 접근 가능한 쉘 제공. Cloud SDK가 이미 설치되어 있어 사용 가능. 임시 VM을 사용한다. 이 임시 VM은 유저별로 하나씩 제공되긴 하지만 쉘을 멈추면 VM도 멈추고 쉘을 시작하면 VM도 다시 시작되므로 프로덕션용으로 사용할 수 없다. 또한 5GB의 persistence storage를 가질 수 있다. 또한 editor 도 있어 간편하게 사용할 수 있다.
• Cloud Console mobile app
• REST-based API

Containers and Container Images

• Dedicated server
  기본적으로 애플리케이션을 배포하기 위해선 적절한 물리적인 장소를 찾고, 파워, 쿨링, 네트워크 등 하드웨어 장비를 준비해서 Kernel, Dependencies, Application Code를 set up하는 과정을 진행했어야 했음.
  만약 애플리케이션을 운영하면서 확장이 필요할 경우 똑같은 과정을 반복하면됨. 이러한 과정은 시간, 비용이 많이 소요됨. 애플리케이션은 OS나 하드웨어에 종속적이였음.
• Virtual machine
  virtualization 기술의 Hypervisor는 물리적인 서버들의 하드웨어를 가상화해 여러 가상 서버를 실행할 수 있게 하여 애플리케이션을 하드웨어 종속성으로부터 독립시킴. KVM은 대표적인 하이퍼바이저 중 하나임. 서버가 필요할 경우 하이퍼바이저에서 가상서버를 생성하기만 하면 되어 이전 방식보다 획기적으로 비용, 시간이 감소됨. 또한 가상머신 이미지등을 사용해서 쉽고 빠르게 복제본을 생성할 수 있게됨. 이 방식의 단점은 애플리케이션은 여전히 OS의 종속성을 가지고있었고, 서비스 시작을 위해선 가상머신의 boot time이 필요했음. 또한 하나의 머신에 여러 서비스를 구동할 경우 종속성의 문제가 있을 수 있으며 하나의 애플리케이션 문제가 머신에 영향을 미치면 다른 애플리케이션도 영향을 받게 되었음.

더 나은 방식으로, 애플리케이션, dependency 레벨에서 추상화를 구현하여, 이전 방식 처럼 전체 하드웨어, 운영체제를 가상화할 필요 없이 user space만 가상화하면 됨. user space는 커널 위에 있으며 애플리케이션 코드와 dependency가 위치한 공간이며 이것이 container임. 컨테이너는 하드웨어, OS를 가상화하지 않기 때문에 가벼우며 boot time이 없음. 또한 컨테이너간 별도의 user space를 가지기 때문에 서로 독립적이며 같은 kernel 위에서 portable함. 시스템 환경/라이브러리 등 여러 환경에 독립적으로 동작할 수 있음.

리눅스 커널이라면 랩탑, 서버, 가상머신 등의 환경에 영향을 받지않고 언제든 실행을 보장할 수 있음.

애플리케이션 코드와 dependency의 묶음을 image라고하고 컨테이너는 이미지를 running한 인스턴스이다. 개발자는 애플리케이션 코드를 이미지로 빌드해서 portable package를 만들 수 있다. 이미지를 빌드하고 컨테이너를 구동하기 위해선 tool이 필요한데, 오픈소스 프로젝트인 docker가 이 두가지를 모두 제공한다. 하지만 쿠버넷이 하는 것 처럼 컨테이너들을 orchestration하진 않음

컨테이너는 여러 리눅스 기술을 활용해 구성됨.

• Processes : 리눅스 프로세스는 다른 프로세스와 분리된 각각의 virtual memory address space를 가지며, 빠르게 create/destory 됨
• namespace : process id number, directory tree, ip 등을 사용하기 위해 사용
• cgroups : 컨테이너의 자원(cpu, mem 등)을 컨트롤하기 위해 사용
• union file system : code, dependecy로 layer를 구성하기 위해 사용

이미지는 layer로 구성되어있고 이미지 빌드 도구는 이미지를 빌드하기 위해 container manifest를 참조하는데, docker의 경우 Docker file 이다. Docker file은 이미지의 레이어 정보를 가지고 있는데, 이 레이어들은 read-only이며 컨테이너가 구동되면 맨 마지막에 w/r이 가능한 ephemeral layer가 생성된다.

예제 도커파일의 FROM, COPY, RUN, CMD 명령어는 실행되면서 각각 하나의 layer를 차례차례 만들며 각 레이어는 이전 레이어에서의 변경사항만 가지고 있다. 도커파일을 작성할 때 변동성이 가장 낮은 레이어를 맨 아래(맨 처음)에 두고 차례차례 두는 것이 더 효율적이다.
이미지가 컨테이너로써 실행되면 conatiner layer가 생성되어 해당 레이어는 컨테이너 러닝동안 R/W가 가능하며 컨테이너가 종료되면 사라진다. 즉 컨테이너에서 작업한 데이터를 보존하기 위해선 다른 persistence storage를 찾아야 한다.

위 구조에서 하나의 이미지를 사용하는 여러 컨테이너들은 개별 container layer를 가지고 있으면서 그 아래에 동일한 base image layer를 가지고 있으므로 효율적으로 활용될 수 있음.

새로운 컨테이너를 빌드할 때, 전체 이미지를 복사하는 것이 아니라 변경점이 있는 레이어부터 만든다. 위 그림을 보면 여러개의 컨테이너가 같은 base image(read only)인 ubuntu:18.04 이미지를 공유 하면서, 그 위에 각각의 R/W layer를 가지고 있는 것을 볼 수 있다. 이것이 VM보다 더 빠르게 동작할 수 있는 이유 중 하나이다.

GCP에선 image 관련 환경으로 container registyr인 gcr.io와 이미지 빌드 자동화 도구인 Cloud Build를 제공한다.

Introduction to Kubernetes

쿠버넷은 on-premise 또는 Cloud에서 컨테이너를 컨트롤할 수 있는 오픈소스 플랫폼이다.

• open source : 벤더에 종속적이지 않은 Cloud Native Computing Foundation 재단의 오픈소스 프로젝트
• Automation :  deployment, scaling, load balancing, logging, monitoring 등 다양한 management features를 자동화
• Declarative configuration : 관리자는 복잡한 설정을 이해할 필요 없이 desired state를 정의하고 kuberentes가 이를 달성하기 위한 동작을 수행
• Imperative configuration : 명령형 설정도 지원함

1. stateless, stateful application 뿐만 아니라 batched job, deamon tasks 등 다양한 application workload를 지원
2. 애플리케이션의 사용량에 따라 auto scale in-out을 지원
3. 리소스의 사용량을 제어할 수 있음
4. 다양한 플러그인, 확장을 지원함
5. 오픈소스이기때문에 vendor lock in 없이 다양한 환경에 자유롭게 배포, 이동이 가능함

Introduction to Google Kubernetes Engine

GCP에선 관리형(fully managed) 쿠버넷 서비스로 GKE를 서비스함.

• GKE 장점
  • GKE에서 fully managed를 해줌. 노드를 생성하기 위해 vm을 provision 하거나 등의 작업들을 자동화된 프로세스로 지원함
  • 컨테이너에 최적화된 OS로 GKE를 구동하여 쉽게 확장 가능
  • 자동으로 버전을 업그레이드할 수 있게 해줌
  • 노드가 탈락되었을 때 자동으로 복구해주는 등을 해줌
  • 클러스터를 자동화된 프로세스로 scale in-out 할수 있음
  • GCP의 다른 container 관련 서비스(registry, Cloud Build) 등과 통합되어 있음
  • GCP의 IAM과 통합 가능
  • GCP의 로깅&모니터링 서비스와 통합 가능
  • 기존 GCP의 네트워크와 통합 가능

Computing Options Detail

GCP에서 compute workload를 구동하기 위해 제공되는 서비스와 특징

• Compute Engine
  GCP에서 제공하는 virtual machine service
  - infrastructure, OS에 대한 customizing을 원할 때 사용
  - 운영체제를 섞어서 애플리케이션을 구동시키고 싶을 때 사용
  
  • Fully customizable virtual machines : GCP에서 제공하는 가상머신 서비스. 자유롭게 설정한 가상머신을 제공받음. 현재 160 vCPUs, 3 TB memory 이상을 신청할 수 있음.
  • Persistenct disks and optional local SSDs : persistence storage를 위한 두 가지 옵션 제공. 64TB 이상의 network storage를 제공하며 스냅샷 등 기능 이용 가능. 빠른 I/O를 위한 local SSD도 사용 가능.
  • Glocal load balancing and autoscaling : managed instance group 설정을 통해 global load balancer를 활용하여 auto-scaling을 설정할 수 있음
  • Per-second billing : 배치잡 등에 유용하게 활용할 수 있도록 초당 청구됨. preemptible vm으로 매우 저렴한 가격에 서비스를 이용할 수도 있음.
• App Engine
  fully managed application platform. 별도의 서버 설정, 배포 설정 없이 코드만으로 서비스를 구동
  - 서버, 배포에 대한 걱정없이 코드만 작성해서 배포하고싶을 때 사용
  - mobile app, web, gaming backend, RESTful API 등에 활용
  
  • provides a fully managed, code-first platform
  • Streamlines application deployment and scalability
  • Provides support for popular programming languages and application runtimes
  • Supports integrated monitoring, logging, and diagnostics
  • Simplifies version control, canary testing, and rollback
• GKE
  • Fully managed Kubernetes platform
  • Supports cluster scaling, persistence disks, automated upgrades and auto node repairs
  • Built-in integration with Google Cloud Service
  • Portability across multiple environment(Hibrid computing, Multi cloud computing)
• Cloud Run
  managed compute platform
  - 특정 이벤트가 발생했을 때 stateless container를 실행하고 싶을 때
  
  • Enables stateless containers
  • Abstract away infrastructure management
  • Automatically scales up and down
  • Open API and runtime environment
• Cloud Functions
  for simple, single-purpose functions
  python, go, javscript로 쓰여진 코드만 업로드하면 scaling, HA, fault-tolerant를 자동으로 구성할 수 있음
  
  • Event-driven, serverless conmpute service
  • Automatic scaling with highly available and fault-tolerant design
  • Charges apply only when your code runs
  • Triggered based on events in Google Cloud services, HTTP endpoints, and Firebase

Kubernetes Concepts

쿠버넷의 두 가지 중요한 메인 컨셉은 object model과 declarative management임.

사용자는 object model의 attribute를 수정해서 state를 변경시킬 수 있음. 이 변경은 declarative 방식으로 되는데 사용자는 쿠버넷이 달성하길 원하는 오브젝트와 오브젝트의 상태를 정의하고 쿠버넷은 사용자가 정의한 상태를 달성하기 위해 동작함. 

쿠버넷에서의 오브젝트는 두 가지 상태를 가지고있음. 사용자가 정의한 상태(desired state), 실제로 클러스터에 구동중인 현재 오브젝트의 상태(current state). object spec은 사용자가 정의한 desired state가 기록된 element이고, object status는 쿠버넷의 control plane이 기록하는 현재 오브젝트의 상태를 기록하는 element.

여기서 controle plane이란 쿠버넷 클러스터의 프로세싱을 담당하는 쿠버넷 구성요소 중 하나.

쿠버넷의 basic building block, smallest deployable object. 컨테이너는 쿠버넷에서 pod으로 구동됨. 하나의 팟은 여러개의 컨테이너로 구성되어있으며 쿠버넷은 pod에게 고유의 ip를 부여하고 pod의 내부 컨테이너는 127.0.0.1로 통신함. 팟의 컨테이너들은 network, storage를 공유함. 

nginx 컨테이너를 3개 구동시키고 싶다면, 사용자는 nginx 컨테이너에 대한 object 정보를 기입하면 쿠버넷은 사용자가 작성한 disire state를 current state로 만들기 위해 작업한다.

 사용자가 입력한 desired state와 current state를 비교해서 쿠버넷 컨트롤 플레인이 desired state가 current state와 일치할 때 까지 반복적으로 계속 시도한다. 이런 쿠버넷의 행위를 watch loop라고 한다. 이런 작업은 첫 생성 이후부터 endless로 계속 모니터링되며 desired state와 current state를 일치시키기 위해 동작한다.

The Kubernetes Control Plane

쿠버넷 클러스터를 구성하기 위해선 컴퓨터가 필요하다. 클라우드를 포함한 대부분의 쿠버넷 클러스터들은 가상머신을 노드로 사용한다. 클러스터 중 하나의 컴퓨터를 controle plane이라고 부르고 나머지를 nodes라고 부른다.  nodes는 pod의 실행을 담당하고, 컨트롤 플레인은 클러스터의 coordinate를 담당한다. 클러스테에서 중요한 부분을 담당하는 컴포넌트들은 컨트롤 플레인에 배치된다.

• kube-API server : 클러스터를 컨트롤할 수 있는 기능들을 API로 제공하며 클러스터를 조회하거나 변경하는 모든 쿼리들이 api server를 통해야 한다. 대표적으로 kubectl이 api server를 통해 클러스터와 통신한다.
• etcd : 쿠버넷 클러스터에 대한 정보 저장소이다. 현재 클러스터/노드 구성 정보, 팟이 어느 노드에서 구동중인지 등의 클러스터 정보를 저장한다. etcd를 direct로 사용해선 절대 안되며 api server로 접근해야 한다.
• kube-scheduler : 팟의 스케쥴링을 담당한다. 설정 정보를 읽어 팟을 적절한 노드에 배정한다.
• kube-controller-manager : kube-api-server를 통해 클러스터를 모니터링하며 desired state와 current state를 맞추는 역할을 수행한다.
• kube-cloud-manager : 쿠버넷 클러스터와 클라우드 프로바이더와 통신하며 여러가지 필요 서비스를 제공하기 위해 사용된다.
• kubelet : 쿠버넷 클러스터가 각 노드에 설치하는 agent. container runtime을 가지고 있으면서 pod을 구동하고 라이프사이클을 모니터링하면서 api server와 통신한다. 쿠버넷은 여러 컨테이너 런타임을 지원하지만 GKE는 containerd를 사용한다.
• kube-proxy : 노드들에 구동중인 팟들의 네트워크를 제어하기 위한 컴포넌트. 오픈소스 쿠버넷은 iptables의 firewall을 사용해 해당 기능을 제공한다.

온프로미스 환경의 쿠버넷에서 서비스를 사용할 때 LoadBalancer(이하 LB)는 사용할 수 없다. 쿠버넷은 서비스의 LB 기능을 외부의 역할로 두었고 퍼블릭 클라우드 환경에서는 각 클라우드 벤더사들이 자체적으로 제공하는 LB가 있지만 온프로미스 설정을 위해 별도로 공개하진 않았다.

CNCF Landscape의 Orchestration & Management - Service Proxy 항목을 보면 온프로미스에서 설치가능한 오픈소스 프로젝트 2개가 있는데 MetalLB와 PorterLB 이다. 둘다 쿠버넷의 Service에 필요한 LB 를 제공해주는데 git star를 보면 알겠지만 MetalLB가 사용자가 더 인기가 많아?보인다.

MetalLB와 PorterLB의 설정 문서를 대충 훑어봤는데 LB로써의 설정 관련된 네트워크 지식은 뼈대가 거의 같은것 같아서 한쪽먼저 설치하고 개념을 익혀두면 다른 하나는 쉽게 접근이 가능할 것 같아서 인기가많아서 레퍼런스가 좀 더 있을 것 같은 MetalLB 컨셉이해와 설치를 하기로 했다.

Basic Concept

MetalLB의 주요기능은 쿠버넷에서 서비스에 사용가능한 외부 LoadBalancer가 되는 것이다. LB가 되기위해서 크게 두가지 기능을 제공한다.

• Address Allocation : 외부와 연결가능한 아이피를 서비스와 연결한다. MetalLB가 자체적으로 아이피를 생성하는 것은 아니며 사용자가 설정한 ip pool에서 사용가능한 아이피를 할당한다. 이 아이피는 public, private 모두 가능하다.
• External Annocement : 사용할 아이피를 서비스와 연결하고, ARP, NDP, BGP 프로토콜을 사용해 외부와 통신할 수 있도록 네트워크를 구성한다.

Preparation

설치 요구사항은 몇개 없다.

• load-balancing 기능이 없는 1.13.0 버전 이상의 Kubernetse
• 지원하는 CNI(** 이슈가 있음) : Calica, Canal, Ciliium, Flannel, Kube-router, Romana, Weave Net**
• kube-proxy의 IPVS mode에서 작동은 하지만 이슈가 약간 있음
• MetalLB에서 제공해줄 아이피 셋
• BGP 모드를 사용할 경우 BGP 기능을 지원하는 하나 이상의 라우터
• MetalLB와 통신하기 위해 모든 클러스터상의 노드가 TCP/UDP 7946가 오픈이 되어있어야 함
• 대부분의 public cloud platform에선 동작하지 않음(metallb.universe.tf/installation/clouds/)

Install

# namespace 생성
$ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/namespace.yaml

# MetalLB 오프젝트 생성
$ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/metallb.yaml

위 스크립트 과정을 완료하면 metallb-system 네임스페이스에 생성된 controller, speaker 팟을 확인할 수 있다.

controller는 deployment로 동작하며 LoadBalancer을 타입으로 사용하는 Service를 감지하고 보유중인 아이피 풀에서 아이피를 Service에 배정하는 역할을 한다. 쿠버넷 클러스터의 노드마다 하나씩 배포되는 Speaker는 daemonset 형태로 배포되며, 실제로 외부 트래픽과 서비스를 연결해 네트워크 통신이 가능하도록 구성하는 역할을 담당한다.

Configuration

MetalLB의 설정은 ConfigMap으로 배포된 my-release-metallb-config를 수정하여 설정할 수 있다. service 생성 시 spec.loadBalancerIP의 값을 통해 아이피를 지정하거나 ip pool을 하나이상 지정해서 그 중 하나를 사용하도록 설정이 가능하다. MetalLB가 네트워크를 구성하는 방식은 크게 Layer2, BGP 방식이 있으며 data.config.address-pools.[].protocol에서 설정이 가능하다.

Layer2

제일 간단하게 설정할 수 있는 방법이다. 별다른 설정 없이 MetalLB가 서비스에 할당할 아이피 풀만 지정하면 된다.

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.240-192.168.1.250

Layer2 방식은 클러스터를 구성하고 있는 여러 노드 중 하나의 노드가 사용할 IP 하나를 담당해서 모든 트래픽을 하나의 노드로 집중하는 방식이다. 하나의 노드가 ARP 프로토콜 관련 작업을 수행하며 모든 네트워크 트래픽을 담당하기 때문에 노드레벨에서의 로드밸런싱이 되지않아 최대 네트워크 bandwidth는 해당 아이피를 담당하는 노드의 네트워크 bandwidth와 동일하다.

세부 traffic policy를 설정할 수 있는데 Cluster로 설정할 경우 ip를 담당하는 노드의 kube-proxy가 서비스의 모든 노드로 트래픽을 분배, 균일하게 로드밸런싱하는 방법이며 pod의 네트워크 관련 트래픽을 관찰하면 source가 ip를 담당하기로한 node의 아이피로 나오는 것을 볼 수 있다. Local policy의 경우 ip를 담당하기로 한 노드에 있는 pod에만 트래픽을 보낸다. 이 방식은 Cluster 방식과는 달리 kube-proxy가 다른 노드로 트래픽을 보낼 필요가 없기 때문에 pod에 들어오는 네트워크 소스는 원래 출발지를 가르킨다. Cluster 방식의 경우 다른 노드의 pod은 트래픽을 수신하지 않으며 트래픽을 받는 노드의 replica로서 failover를 방지하기 위한 용도로 사용된다.

BGP

istio는 제공하는 다양한 기능을 시각화하기 위해 여러가지 툴을 제공한다. 대표적으로 네트워크 시각화 - Kiali, 트래픽 트레이싱(추적) - jaeger, 리소스 모니터링 - Prometheus/Grafana 이 있다.

Kiali

kiali는 service mesh의 전체 네트워크 토폴로지와 서비스 인스턴스 상태, 서비스간의 네트워크 트래픽을 시각화한다. kiali를 사용해서 현재 어떤 서비스에 문제가 발생했고, 어떻게 라우팅 되고있는지 시각화하여 확인할 수 있다.

kiali 또한 bookinfo 예제와 동일하게 쉽게 구성할 수 있도록 yaml파일로 배포하고 있다.

$ kubectl -f samples/addons/kiali.yaml

$ kubectl -n istio-system get all -l app=kiali
NAME                        READY   STATUS    RESTARTS   AGE
pod/kiali-dc84967d9-jg25k   1/1     Running   0          5d13h

NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)              AGE
service/kiali   ClusterIP   10.98.115.47   <none>        20001/TCP,9090/TCP   5d13h

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/kiali   1/1     1            1           5d13h

NAME                              DESIRED   CURRENT   READY   AGE
replicaset.apps/kiali-dc84967d9   1         1         1       5d13h

Istio 설치 패키지는 Bookinfo 예제와 같이 제공된다. Bookinfo는 4개의 서비스로 이루어진 MSA 예제이다. Istio의 여러가지 기능들을 테스트할 수 있도록 폴리글랏 구조로 버저닝되어있는 4가지 서비스를 제공한다.

• productpage : python project. 제품 설명 페이지를 완성하기 위해 details, reviews 서비스를 호출하는 서비스
• details : ruby project. 책 정보 제공 서비스
• reviews : java. 책 리뷰 제공 서비스. rating 서비스를 호출한다.
• ratings : nodejs. 책의 ranking 정보를 제공한다. 버저닝 관련된 테스틑 할 수 있도록 v1, v2, v3가 제공된다.
  • v1 : ratings 서비스를 호출하지 않는 버전
  • v2 : ratings 서비스를 호출, black start를 사용하여 rating
  • v3 : ratings 서비스를 호출, red start를 사용하여 rating

Install on Kubernetes

istioctl install

Istio의 거의 대부분의 작업은 istioctl 명령어를 사용해서 진행한다. 아래의 스크립트를 사용하여 istioctl을 다운로드받을 수 있다.

# 가장 최신 배포 버전 다운로드
$curl -L https://istio.io/downloadIstio | sh -

# 특정 버전을 다운받을 경우
$curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.6.8 TARGET_ARCH=x86_64 sh -

# 패키지 설치
$update-alternatives --install /usr/bin/istioctl istioctl /opt/istio/bin/istioctl 0

# 확인
$istioctl version

client version: 1.9.1
control plane version: 1.9.1
data plane version: 1.9.1 (2 proxies


# install istio on k8s
$istioctl install --set profile=demo -y

✔ Istio core installed
✔ Istiod installed
✔ Egress gateways installed
✔ Ingress gateways installed
✔ Installation complete

위의 과정이 정상적으로 완료되면 istioctl은 istio-system 네임스페이스를 생성하고 해당 네임스페이스의 pod 오브젝트를 확인하면 istio architecture에서 나왔던, istio service mesh의 traffic in/out을 담당하는 istio-ingressgateway, istio-egressgateway, 메인 코어 컴포넌트인 Pilot, Citadel, Galley를 담당하는 istiod가 생성되어 있는것을 확인할 수 있다.

$ kubectl -n istio-system get pod

NAME                                    READY   STATUS    RESTARTS   AGE
istio-egressgateway-bd477794-rwrhp      1/1     Running   0          16d
istio-ingressgateway-79df7c789f-qnmxs   1/1     Running   0          16d
istiod-6dc55bbdd-sgjrj                  1/1     Running   0          16d
...

추가로 istio-ingressgateway, istio-egressgateway의 yaml파일을 보면 envoy를 사용하고 있다.

Deploy BookInfo

demo profile로 설치를 진행하였을 때 istiod는 네임스페이스의 라벨들 중 istio-injection 라벨이 있고 값이 enabled이며, webhook이 enabled되어 있으면 그 내부의 pod들은 자동으로 sidecar를 구성(injection)한다.

# 라벨링
$kubectl label namespace istio istio-injection=enabled

# 서비스 배포. yaml 내부의 모든 k8s 오브젝트의 네임스페이스를 istio로 설정하는 것을 추천
$kubectl -n istio apply -f samples/bookinfo/platform/kube/bookinfo.yaml

위의 세팅이 정상적으로 완료되면 아래와 같이 pod, service를 확인할 수 있다.

$kubectl -n istio get pods
NAME                              READY   STATUS    RESTARTS   AGE
details-v1-79f774bdb9-kx5jp       2/2     Running   0          2d13h
productpage-v1-6b746f74dc-2gbft   2/2     Running   0          2d13h
ratings-v1-b6994bb9-l7j6z         2/2     Running   0          2d13h
reviews-v1-545db77b95-b8qsm       2/2     Running   0          2d13h
reviews-v2-7bf8c9648f-g6kqd       2/2     Running   0          2d13h
reviews-v3-84779c7bbc-jx45l       2/2     Running   0          2d13h


$kubectl -n istio get services
NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
details       ClusterIP   10.111.13.195   <none>        9080/TCP   2d13h
productpage   ClusterIP   10.102.13.107   <none>        9080/TCP   2d13h
ratings       ClusterIP   10.97.219.116   <none>        9080/TCP   2d13h
reviews       ClusterIP   10.108.93.152   <none>        9080/TCP   2d13h
webservice    ClusterIP   10.111.77.236   <none>        80/TCP     4d23h


$kubectl exec "$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')" -c ratings -- curl -sS productpage:9080/productpage | grep -o "<title>.*</title>"

<title>Simple Bookstore App</title>

Set Gateway

위의 과정에서, 현재 모든 서비스는 클러스터 내부의 호스트들에서만 접속가능한 ClusterIP 형태로 설정되어있다. 외부 연결을 위해서 쿠버넷에서는 serivce 오브젝트가 제공하는 NodePort, LoadBalancer 등과 Ingress 오브젝트를 이용할 수 있지만 istio에서는 훨씬더 넓은 범위에서 네트워크 in/out 트래픽을 처리하기 위해 gateway를 제공한다.

gateway에서는 애플리케이션(예제에서 bookinfo의 모든 애플리케이션)과 독립적으로, 별도의 애플리케이션 코드 추가, 수정 없이 Layer 4~6와 관련된 정보를 컨트롤하며 Load Balancing, TLS 등을 구성할 수있는 설정을 제공한다.

예제에서 제공하는 gateway를 아래 명령어로 배포할 수 있다.

$kubectl -n istio apply -f samples/bookinfo/networking/bookinfo-gateway.yaml 

# check
$kubectl -n istio get gateway
NAME               AGE
bookinfo-gateway   2d12h

아래 명령을 통해 gateway를 등록함으로써 istio가 정상적으로 ingress를 설정하였는지 테스트해보자.

# 현재 ingress 호스트의 주소, 포트를 확인(Load Balancer 형태)
$ export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')

# 서비스 확인
$ export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT
$ curl -s "http://${GATEWAY_URL}/productpage" | grep -o "<title>.*</title>"

<title>Simple Bookstore App</title>

bookinfo-gateway.yaml 파일 구성을 보면 생성했던 서비스들을 외부로 노출시키기 위한 Gateway와 VirtualService의 yaml 파일을 볼 수 있다. 아래는 Gateway의 yaml 부분이다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  namespace: istio
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  # http 프로토콜의 80번 포트로 오는 모든 호스트(url)에 대한 gateway를 생성)
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

위의 요청은 단순히 http 프로토콜, 80번 포트로 오는 모든 호스트 요청에 대한 게이트웨이만 생성했을 뿐이다. 해당 gateway를 생성하더라도 해당 gateway를 통해 식별된 트래픽이 어떤 서비스로 라우팅되어야 하는지 설정되어있지 않기 때문이다.

어떤 서비스를 연결할 지에 대해선 VirtualService를 생성하여야한다. 아래는 bookinfo-gateway.yaml 파일에 있는 VirtualService 설정 부분이다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  namespace: istio
  name: bookinfo
spec:
  hosts:
  - "*"
  # 바인딩 할 gateway를 설정
  gateways:
  - bookinfo-gateway
  http:
  - match:
    - uri:
        exact: /productpage
    - uri:
        prefix: /static
    - uri:
        exact: /login
    - uri:
        exact: /logout
    - uri:
        prefix: /api/v1/products
    route:
    - destination:
        host: productpage
        port:
          number: 9080

bookinfo-gateway라는 이름을 가진 gateway에 바인딩하고 http로 들어오는 요청 중 match 조건에 맞는 url을 route 항목의 룰에따라 라우팅한다. route에 있는 host는 위에서 사용했던 host의 의미와는 다르게 kubernetes에 생성한 service의 이름을 의미한다. 위 룰은 /productpage. /static/**/. /login, /logout, /api/v1/products/**의 요청을 kubernetes에 생성된 productpage 서비스의 9080포트로 라우팅하는 설정이다.

위 설정이 정상적으로 완료되었다면 외부 시스템에서 Gateway, VirtualService를 통해 내부 서비스에 연결이 가능하다.

$ echo http://${GATEWAY_URL}/productpage

웹페이지에 접속하면 새로고침 할 때마다 Book Review 부분이 계속 바뀌는 것을 확인할 수 있다. 현재 ingress 방식이 기본 round-robin방식으로 되어있기 때문이다.

위는 istio의 Gateway, VirtualService가 제공하는 기능 중 기본적인 기능들만 설명하였고, TCP, TLS등의 설정을 포함하여 다양한 설정을 추가로 할 수 있다.

Service Mesh

기존 모놀리스 시스템을 도메인, 운영등의 여러 기준에 따라 분할해놓은 MSA(MicroService Architecture)는 비즈니스 서비스를 제공하기 위해 수많은 마이크로 서비스들이 내-외부간 네트워크 통신을 하게 된다.

수많은 서비스들간의 네트워크 통신을 관리하기위해 가시화하고 통신에 대한 보안, 추적, 장애방지 등을 관리하기 위해 나온것이 Service Mesh 개념이다. 위 그림에서 볼 수 있는 Amazon, Netflix의 서비스간 네트워크 연결을 보면 알수 있듯이 이러한 수많은 연결이 현재 어떻게 이루어져 있으며 어디서 문제가 발생했는지, 그 문제가 어디까지 전파되고 있는지 또는 서비스 인스턴스가 골고루 사용되고 있는지, 보안연결은 정상적으로 제공되고 있는지에 대한 문제를 Service Mesh의 챌린지이다.

Istio Concept

현재 Istio는 Service Mesh의 주요 기능을 구현한 오픈소스 프로젝트이다. Istio이 제공해주는 주요 기능은 아래와 같다.

• Service Discovery : 준비가 된 새로운 서비스 인스턴스를 목록에 추가하고 사용이 불가능해진 서비스 인스턴스를 삭제하는 등의 서비스 인스턴스 목록 관리하고 서비스의 요청을 어떤 인스턴스로 보낼지, 보내지 않을 지에 대해 결정한다.
•  Routing
  • Load Balancing : Round Robin, Weight, Random 등 다양한 방법으로 로드 밸런싱을 지원
  • Health Check : 노드의 가용성 및 서비스들의 상태를 지속적으로 확인
  • Automatic Deployment : 배포 유형에 따라 가중치를 적용해 트래픽을 새로운 노드로 유도
• Resilience : 애플리케이션과 독립적인 서비스 요청의 timeout, retry등을 제어
• Security : TLS 암호화 지원, 엑세스 제어
• Telemetry : 네트워크 추적, 메트릭 수집

Istio는 위와 같은 기능을 제공하기 위해 사이드카 패턴을 기반으로 개별 서비스 인스턴스를 제어하는데, 거의 대부분의 경우 Envoy를 사용해서 사이드카 패턴을 구현한다. 사이드카 패턴은 일종의 개념이고 이 개념의 기능을 수행하기 위한 구현체로써 Envoy를 사용하는 것이다.

Netflix에서 공개한 Spring Cloud Netflix, Google의 Stubby등 애플리케이션 레벨에서 구현한 몇몇 Service Mesh가 있음에도 Istio가 주목받는 이유는, 애플리케이션에서 이러한 주요 개념을 구현할 때 각각의 프레임워크마다 구현체가 달라 생기는 러닝커브, 비즈니스 로직에 Service Mesh관련 내용의 코드를 추가함으로써 생기는 복잡성등의 단점이 발생할 수 있다. 이와같은 단점을 보완하기 위해 Istio와 같이 Service Mesh를 위한 별개의 네트워크 레이어를 구성하여 애플리케이션과의 독립성을 보장하고 MSA의 폴리글랏 구조에서 다양한 프레임워크에 대응할 수 있도록 유연한 구조를 구축할 수 있게 된다.

Sidecar Pattern

실제 Sidecar처럼 서비스 인스턴스에 붙어 일종의 proxy 역할을 수행하며 네트워킹, 모니터링, 로깅과 같은 기능을 제공한다.

사이드카는 담당하는 서비스 인스턴스와 라이프 사이클을 공유하며, 인스턴스와 1:1관계로 단독으로 확장될 수 없는 구조를 가진다. 또한 인스턴스가 주고받는 모든 트래픽을 proxy한다. 이런 사이드카 패턴의 장점은 위 Primary Application에 해당하는 부분인 기존 서비스 로직부분에대한 변경 없이도 서비스 인스턴스가 외부와 주고받는 모든 네트워크를 컨트롤할 수 있다는 점이다. 이는 Istio를 써야하는 주요 중 하나를 뒷받침해준다.

Envoy

사이드카 패턴을 구현한 L7 Proxy, Communication bus 이다.

Envoy의 아키텍쳐 구성요소

• Port Listener : Envoy가 네트워크 트래픽을 리스닝(관리)하는 포트를 관리. TCP 기반의 리스너만 지원. 여러 리스너로 구성된 단일 인스턴스 실행을 권장
• Filter : 수신된 메세지를 라우팅, 프로토콜 변환, 통계 생성 등과 같은 다양한 작업을 수행할 수 있는 Filter Set을 구성. 각 리스너는 고유의 필터 세트를 구성하고 있음. 다양한 기본 필터 셋을 가지고 있으며 분류는 아래와 같음
  • Listener Filter : TLS 검사 또는 서비스 원격 대상 등을 담당. 원시 데이터에 엑세스 한 후 L4의 메타데이터를 조작
  • Network Filter : 애플리케이션 권한 부여, 속도 제한, TLS 인증 등 작업 수행. 통계 수집, 엑세스 제어등을 위한 Mysql, MongoDB와 같은 애플리케이션별 프로토콜에 관한 필터도 있음. 
  • HTTP Filter : 다양한 HTTP 필터 셋이 제공됨. gzip 압축, grpc -> json 변환 등 다양한 작업 수행 가능. Envoy Proxy가 받은 HTTP request를 조작
• Cluster : Envoy가 연결하는 논리적 호스트 그룹. 정적으로 구성하거나 내장된 Service Discovery를 사용해서 동적으로 생성할 수 있음

Envoy가 제공하는 서비스 목록

• EDS, Endpoint Discovery Service : 클러스터에 서비스를 추가/제거할 수 있는 서비스. DNS 역할을 하며 DNS 병목 현상을 해결하는데 활용
• CDS, Cluster Discovery Service : 라우팅에 사용되는 애플리케이션 클러스터를 동적으로 검색할 수 있는 서비스. 클러스터를 추가, 업데이트, 제거한다.
• RDS, Router Discovery Service : HTTP 필터 체인을 동적으로 동적으로 생성
• LDS, Listener Discovery Service :  HTTP 필터의 리스너 체인을 동적으로 생성
• SDS, Secret Discovery Service : TLS 인증서, Private Key와 같은 애플리케이션 Secret 검색. 공개 인증서 제공

Architecture

Data Plane

서비스와 사이드카로 배포된 Proxy(Envoy)로 구성되어있는 셋의 집합이다. 자기자신이 담당하는 서비스의 모든 network in/out 패킷을 변환, 전달, 모니터링한다.

Control Plane

Data Plane으로 부터 서비스의 상태를 전달받아 현재 가용 가능한 서비스 목록을 지속적으로 관리하며 전체 네트워크 트래픽을 제어한다. 또한 Circuit Breaker, 로드 밸런싱, timeout, security 등의 기본 구성 정보를 저장한다. Control Plane은 트래픽을 담당하는 Pilot, 암호화을 담당하는 Citadel, 환경 설정 저장/사용자 구성 검증 등의 기본적인 Control Plane 기능을 제공하는 Galley로 구성되어 있다.

• Pilot
  트래픽을 라우팅하며 Service Discovery, timeout, retry, Circuit Breaker 운영을 관리한다. Istio는 모든 팟의 사이드카로 Envoy Proxy를 사용하여 Service Mesh를 구성, 처리하는데 파일럿이 설정된 정보를 바탕으로 Envoy를 구성해 런타임 때 구성한 Envoy를 배포한다.

• Citadel
  Istio 내의 요청을 암호화하고 메시 내 서비스에 관한 RBAC(Role Based Access Control)을 제공한다. 이 구성은 Pilot에 의해 Envoy로 푸쉬된다.
• Galley
  기본 환경, 사용자 구성을 관리한다.

Feature

Istio가 제공하는 핵심 기능은 크게 3가지로 나누어진다. 

• Traffic Management : 네트워크 트래픽의 룰을 설정하여 트래픽을 컨트롤한다. Circuit Break 패턴을 사용해서 서비스 인스턴스간 장애 확산을 최소화하고 timeout, retry 등을 제어하며, 백분률기반의 트래픽 분할을 활용해 A/B 테스트, Canary rollout, staged rollout등이 가능하도록 설정할 수 있다.
• Secure : 메쉬 네트워크상에서 발생하는 네트워크 통신에 대한 보안 통신 채널을 제공하고 인증, 권한, 암호화를 관리한다. 애플리케이션에선 네트워크 통신 보안이슈를 Istio에 위임할 수 있다.
• Observability : 네트워크 추적, 모니터링, 로깅을 제공한다. 

Conclusion

기존 모놀리스 형식 프로그램에서 발생하던 도메인간 내부 라이브러리(코드) 호출이 마이크로서비스 아키텍쳐로 변하면서 수많은 서비스 인스턴스간 네트워크 API 호출로 변화되었다. 이전보다 더 복잡해진 네트워크 통신으로 인해 발생하는 다양한 문제점, 개념들을 Service Mesh라는 개념으로 묶고, 이를 해결하기위해 Istio에서 네트워크 가시성, 보안, 암호화, 트래픽 라우팅, 장애 확산 방지 등 다양한 Service Mesh 기능들을 제공한다.

Reference

Martin Fowler - CircuitBreaker

Envoy Document - What is Envoy

ProgrammerSought - Envoy architecture, terminology and basic configuration analysis

Istio.io - Architecture

Layer5.io - Service mesh Landscape

분산된 환경에서 서비스간의 네트워크 관리는 매우 중요하다. 네트워크에 대한 감시를 포함하여 특정 서비스가 문제가 발생했을 때 그 서비스를 사용하는 다른 서비스로의 오류 전파를 막고 피해를 최소화하도록 Infrastructure Layer이다.

서비스의 오류 전파, 확산를 막기 위해 회로 차단기가 모티브된 Circuit Breaker Pattern이 기본 개념으로 많이 사용된다.

• Closed : 오류 없이 정상적으로 동작하는 상태. 지속적으로 모니터링하며 특정 임계치를 초과할 경우 Open으로 상태를 변환
• Open : 오류가 발생해서 오류를 반환하는 상태
• Half-Open : 특정 시간이 지난 후 여전이 오류상태인지 확인하고 오류 여부에 따라 Open 또는 Closed로 변환하는 상태

Circuit Breaker Pattern을 개발 프레임워크 레벨에서 구현한 구현체로는 Spring Netflix OOS, Stubby, Finagle등이 있다. 하지만 이런 프레임워크 레벨의 구현체를 쓰면 애플리케이션이 인프라스트럭쳐와 결합도가 높아진다. 예를들어 특정 프레임워크가 필요한 기능을 지원하지 않는다면 대처할 방법이 없어 유연성이 낮아질 수 있고, 개발 프레임워크가 변경될 경우 해당 프레임워크가 구현해놓은 Circuit Breaker Pattern을 학습하기 위한 러닝커브가 발생할 수 있다.

인프라스트럭쳐에서 Circuit Breaker Pattern을 구현한 프로젝트로는 대표적으로 오픈소스 Istio가 있고, 몇몇 상용 클라우드 시장에선 대표적으로 GCP에서는 Anthos(이것도 istio 기반으로 보임)가 있다.

Service Mesh는 OSI 5 Layer인 Session Layer에서 동작하여 애플리케이션과 decoupling 상태에서 동작한다. Service Mesh의 주요 기능은 아래와 같다.

• 트래픽 제어 : 7 Layer(Application Layer)의 헤더를 조회하여 특정 인스턴스로 라우팅하는 등의 제어. 서비스 업데이트 등에 활용 가능
• 보안(Security) : 서비스의 인스턴스간 트래픽에 대한 보안 정책 적용, 속도제한 등
• 분석 : 서비스 인스턴스간 요청 로깅, 시각화, 메트릭 수집

docker는 호스트에서 server/client 구조로 구동됨. 모든 도커 CLI 명령어의 결과물은 호스트의 도커 서버와 API 통신 결과물을 반환함.

도커 서버와 클라이언트는 소켓으로 통신하는데 별도로 설정해주지 않으면 기본 unix socket을 사용해서 통신하기 때문에 일반적으로 사용하던 netstat, ss 옵션을 사용해서는 리스팅되지 않음. 아래 명령어를 사용해서 리스팅할 수 있음.

ss -x | grep containerd

network 통신을 위한 network port로 노출시키기 위해서 실행 스크립트를 변경해야 함.

vi /lib/systemd/system/docker.service

ExecStart=/usr/bin/dockerd -H fd:// -- containerd=/run/containerd/containerd.sock

# 위 내용을 아래로 변경
ExecStart=/usr/bin/dockerd -H fd:// -- containerd=/run/containerd/containerd.sock -H 0.0.0.0:2375


# 데몬 리로딩 및 도커 재식
systemctl daemon-reload
systemctl restart docker.service

위 과정을 거치면 외부에서 접속가능한 network port로 열린 모습을 확인할 수 있음.

ss -ntlup

Netid     State      Recv-Q     Send-Q         Local Address:Port          Peer Address:Port     Process                                        
......        
tcp       LISTEN     0          4096                       *:2375                     *:*         users:(("dockerd",pid=5981,fd=3))   
......

Ceph

여러 호스트의 여러 스토리지들을 클러스터링해서 오브젝트 스토리지, 파일 스토리지, 블록 스토리지 등의 형태로 제공할 수 있도록 해주는 클러스터링 도구이다.

Whether you want to provide Ceph Object Storage and/or Ceph Block Device services to Cloud Platforms, deploy a Ceph File System or use Ceph for another purpose, all Ceph Storage Cluster deployments begin with setting up each Ceph Node, your network, and the Ceph Storage Cluster.

크게 4개의 요소로 클러스터가 구성된다.

• Monitors(ceph-mon) : 클러스터의 정보를 담은 Map(이하 맵)관리함. 맵은 어떤 종류의 정보를 담고 있느냐에 따라 모니터 맵, OSD 맵, MDS 맵, CRUSH 맵등이 있음. 또한 클러스터-클라이언트 간 인증을 담당. HA 구성을 위해 최소 3개 권장.
• Managers(ceph-mgr) : 클러스터의 메트릭을 담당. 메트릭에는 스토리지 사용량 등의 성능 관련된 지표들이 있음. 이러한 성능 지표들을 관리, 제공하기 위해 파이썬 기반의 모듈이 있고 Dashboard, REST API를 제공함. HA 구성을 위해서 최소 2개 권장.
• Ceph OSDs(ceph-osd) : Object Storage Daemon. 데이터를 저장하고 복제 관리, 복구, 리밸런싱을 제공. Monitor와 Manager에게 OSD 관련된 모니터링 정보를 전달하는 역할. HA 구성을 위해 최소 3개 권장.
• MDSs(ceph-mds) : MetaData Server. Ceph File System의 메타데이터를 저장. 오브젝트 스토리지나 블록 디바이스는 사용하지 않음. ls, find등의 POSIX file system을 제공.

Rook

Rook는 kubernetes와 Rook에서 지원하는 다양한 Storage Provider간의 중간 추상화 레이어 역할을 함으로써 좀 더 간편하게 컨트롤할 수 있는 역할을 한다. Rook에서는 많지는 않지만 어느정도 다양한 Storage Provider를 제공하는데 Ceph만 stable 버전만 나와있고 나머지는 Alpha 버전으로 나와있다.

• Ceph : Stable / V1
• Cassandra : Alpha
• CockroachDB : Alpha
• EdgeFS : Deprecated
• NFS : Alpha
• YugabyteDB : Alpha

Prerequisites

• Kubernetes v1.11 이상
• Ceph storage cluster를 설정하기위한 local storage. Raw divces(no partition or formatted fileSystem) 또는 Raw partitions(no formatted filesystem) 또는 PVs availiable from a storage class block mode가 있어야 됨. 본인은 포맷하지 않고 attach만 해놓은 상태의 iscsi를 사용하였음. lsblk -f로 목록을 확인했을 때 FSTYPE 필드에 값이 없는 상태의 disk만 사용 가능.

Install

Rook를 깃 레포에서 다운받으면 실행만 하면 되는 yaml 파일들이 이미 내부에 있다. 또한 Rook에서는 친절하게 각 상황에 따른 예제를 대부분 만들어 놓았다. 또한 최소 3개를 구성한 프로덕션 환경의 클러스터, 테스트를 위한 단일 노드 클러스터 환경 배포 예제를 모드 작성해 놓았다. 아래 yaml 파일 중 cluster.yaml 부분에서 최소 3개이상 노드의 프로덕션 클러스터의 경우 cluster.yaml, 단일 클러스터 환경의 경우 cluster-test.yaml 파일을 사용해서 구축하면 된다.

git clone --single-branch --branch v1.5.7 https://github.com/rook/rook.git
cd rook/cluster/examples/kubernetes/ceph
kubectl create -f crds.yaml -f common.yaml -f operator.yaml
kubectl create -f cluster.yaml

위 구성이 에러없이 완료되면 현재 kubernetes cluster 위에 rook-ceph 클러스터가 구성이 되어 block, object, file 스토리지를 만들 수 있게 된다.

Reference

teamsmiley - kubernetes Rook Ceph