Kind란?

Kind는 도커 컨테이너 “노드”를 사용하여 로컬 쿠버네티스 클러스터를 실행하기 위한 도구이다.

kind는 주로 쿠버네티스 자체를 테스트 하기 위해 설계 되었지만 로컬 개발이나 CI에 사용할 수 있다.

Docker 설치

Install Docker Engine on Ubuntu

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the repository to Apt sources:
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Docker desktop WSL 통합

GoLang 설치

공식 Go 웹사이트에서 설치 파일 다운로드

Go 언어의 공식 웹사이트(go.dev)에서 다운로드 페이지로 이동합니다. 원하는 운영체제 버전에 맞는 설치 파일을 다운로드합니다.

wget https://go.dev/dl/go1.20.8.linux-amd64.tar.gz

압축해제

tar -C /usr/local -xzf go1.20.8.linux-amd64.tar.gz

환경 변수 설정 및 go 환경 변수 등록

export PATH=$PATH:/usr/local/go/bin

source ~/.bashrc

vim /etc/profile.d/go.sh

----------------------------------------------------
#!/bin/bash

export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
---------------------------------------------------

source /etc/profile.d/go.sh

Kind 설치

go의 버전이 1.16 이상이고 도커 혹은 podman이 설치 되어 있는 경우 아래의 명령어로 간편하게 설치할 수 있습니다.

go install sigs.k8s.io/kind@v0.20.0 

kubectl 설치

리눅스에 kubectl 설치 및 설정

snap install kubectl --classic
kubectl version --client

쿠버네티스

클러스터 생성 및 삭제

kind create cluster --name kubernetes
kind delete cluster --name kubernetes

클러스터 정보

kubectl cluster-info

클러스터 상세 정보 확인

kubectl config view

노드 확인

kubectl get node

한개의 마스터 노드와 두 개의 워커 노드로 구성된 클러스터를 생성

vim cluster-3nodes.yaml
----------------------------------
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker

kind create cluster --name kubernetes --config ./cluster-3nodes.yaml

kubectl get nodes

docker container ls

브랜치에서 작업한 부분은 merge를 통해서 기존의 브랜치에 merge(병합)할 수 있다.

인텔리제이에서 브랜치를 생성하여 협업 해보자

1. 브랜치 생성하기

   깃창에서 새 브랜치를 클릭하고 새 브랜치의 이름을 정하여 브랜치를 생성한다.

2. Commit 하고 → Push 하기

   

3. 깃허브, 깃티에서 해당 내용 확인하기 a. 또는 인텔리제이의 하단 Git에서 확인할 수 있다.

기존의 동기식 소켓 서버에는 일반적으로 각 클라이언트의 연결에 전용 스레드가 할당이 되는데 이러한 모델, 방식은 동시에 수천 개의 스레드를 실행하게 되면 운영체제의 부하를 증가시키므로 성능과 확장성이 제한이되기 때문에 서비스의 규모와 용량이 커짐에 따라 연결이 많은 경우 비효율적이다

반면에 비동기 프레임워크는 메커니즘을 사용하여 차단 없이 I/O 작업을 수행한다.

Vert.x는 어떤 API 호출 스레드를 차단하지 않는다. 결과를 즉시 제공할 수 있으면 즉시 반환하고, 그렇지 않으면 일반적으로 이벤트를 수신하는 핸들러를 통해 처리한다.

스레드를 차단하지 않기 때문에 적은 수의 스레드로 많은 동시성을 처리할 수 있다.

Reactor 와 Multi-Reactor

Vert.x의 API는 대부분 이벤트 기반으로 이루어져 있다. 사용자가 관심 있는 일이 Vert.x에서 발생하면 Vert.x가 사용자에게 이벤트를 전송하여 호출합니다.

위의 말은 즉 이벤트가 사용 가능할 때 핸들러에 이벤트를 전달하는 event driven(이벤트 중심)이고 이벤트가 사용 가능할 때 핸들러에 이벤트를 전달한다.

Vert.x는 event loop라는 스레드를 사용하여 핸들러를 호출한다.

이러한 event loop는 이벤트가 도착하면 핸들러에 연속적으로 이벤트를 전달하게 된다.

Vert.x는 차단한는 것이 없기 때문에 이벤트 루프는짧은 시간 내에 엄청난 양의 이벤트를 전달할 수 있는데 단일 event loop는 수천개의 HTTP 요청을 처리할 수 있다.

이러한 event loop를 Vert.x에서는 Reactor Pattern이라고 부른다.

Reactor Pattern은 하나 이상의 입력에 의해 서비스 핸들러에 동시에 전달되는 서비스 요청을 처리하기 위한 이벤트 처리 패턴을 말합니다.

대표적으로 Reactor Pattern으로 구현되는 예시가 Node.js라고 할 수 있다.

이러한 event loop는 단일 스레드인데 문제점은 단일 코어에서만 한 번에 실행할 수 있기 때문에 단일 스레드인 Reactor application 즉 node.js 기반의 application을 멀티코어 서버로 확장하려면 다양한 프로세스를 시작하고 관리 해야한다는 문제점이 있다.

하지만 Vert.x는 다르게 동작하는데 Vert.x는 event loop대신에 각 Vert.x 인스턴스는 여러개의 event loop를 유지하여 사용 가능한 코어 수에 따라 개수를 선택할 수 있다.

정리 하자면 Node.js와 달리 단일 Vert.x 프로세스가 서버 전체에서 확장될 수 있다.

Reactor Pattern과 구분하기 위해서 이 패턴을 Multi Reactor Pattern이라고 부른다.

Vert.x Instance

Vert.x Object와 소통해야 Vert.x에서 많은 것들을 할 수 있다.

Vertx의 객체와 통신하고 싶다면 아래의 방법으로 인스턴스를 생성해서 사용할 수 있다.

Vertx vertx = Vertx.vertx();

인스턴스는 Vert.x의 제어 센터이며 클라이언트와 서버 생성, 이벤트 버스에 대한 참조 가져오기, 타이머 설정 등 거의 모든 작업을 수행하는 방법이다.

대부분의 응용 프로그램은 단일 Vert.x 인스턴스만 필요하지만, 예를 들어 이벤트 버스 또는 다른 그룹의 서버와 클라이언트 간의 분리가 필요한 경우 여러 Vert.x 인스턴스를 생성할 수 있습니다.

Verticle

Verticle이란 Vert.x에서 돌아가는 하나의 어플리케이션의 일부 혹은 하나의 프로그램이라고 이해하면 된다.

예시를 들어서 이해 해보자 하나의 서버가 있고 서버의 기능 단위로 프로그램을 자를 수 있다

서버로 오는 요청을 받는 프로그램 혹은 DB와 소통하는 프로그램 등 이러한 예시를 들 수 있다.

Verticle은 단일 스레드(Single Thread)이어서 한번에 하나의 작업을 처리하지만은 여러 인스턴스를 배포하여 코어와 머신에 걸쳐 확장할 수 있습니다.

Worker Verticle

일반 Verticle과 다르게 Multi Thread로 동작하게 된다. 기본적으로 Vert.x는 일반 Verticle을 사용하지만 선택사항에 따라서 다른 Verticle을 사용할 수 있다.

Vert.x에서 Event Loop와 Verticle

위의 설명으로 해당간의 관계가 이해가지 않을 수 있다. 추가적인 예시를 들어서 확실하게 이해 해보자

Event Loop는 단일 스레드로 이루어져있고 Vert.x에서는 여러개의 Event Loop를 다룰 수 있다.

맥도날드의 예시를 들어보자

Vert.x는 맥도날드 가게이고 여러개의 카운터를 가지고 있다고 생각 해보자

이 각 카운터는 Event Loop 라고 생각할 수 있는데 손님이 계속 반복되서 한명씩 오면은 손님의 주문에 따라서 지속적으로 고객에게 서비스를 제공하게 된다.

Verticle은 음식을 만드는 직원이라고 생각 할 수 있는데 카운터의 주문이 들어 올 때 햄버거를 담당하는 직원은 햄버거를 만들고 감자튀김을 담당하는 직원은 감자를 튀기게 될 것 입니다.

중요한 것은 이러한 Verticle 직원은 카운터(Event Loop)와 상호 작용하여 업무를 진행하게 되고 특정 Verticle Instance는 항상 한명의 카운터(Event Loop)와 작동한다는 점을 알아야 한다.

Event Bus

Event

이벤트는 특정한 일이 발생했음을 나타내는 알림 또는 신호이다.

발생한 일을 알리기 위해 버스로 전송하는 메시지 혹은 데이터를 Event라고 할 수 있다.

Bus

일반적으로 Bus는 컴퓨터 내부의 구성 요소간 또는 컴퓨터 간에 데이터를 전송하는 통신시스템을 지칭하는데 주로 사용한다.

Bus는 데이터(이벤트)를 전달할 수 있는 채널 또는 통로라고 할 수 있다.

Bus를 사용하면 소프트웨어의 여러 부분이 직접 연결되거나 서로를 인식하지 않고도 통신할 수 있다.

Handler

EventBus를 통해서 메시지를 보내면 결국 해당 특정 이벤트를 수신하는 핸들러에 도착하게 된다.

도착하게 되는 이유는 보통 handler에 이벤트를 받는 주소를 설정하기 때문이다.

이러한 핸들러에서는 발생한 일에 대한 메시지를 받게되고 핸들러에서 상황에 맞는 코드를 작성함으로써 발생한 일에 대해서 적절한 행동을 하게 된다.

간단한 요약

이벤트가 버스에 게시되고 해당 이벤트와 관련된 주소를 수신하는 핸들러가 이를 처리하게 됩니다.

결과적으로 이벤트 버스를 사용하면 애플리케이션 내의 컴포넌트나 모듈이 느슨하게 결합된 상태를 유지할 수 있으므로 보다 모듈화되고 확장 가능하며 유지 관리가 용이한 소프트웨어를 만들 수 있다.

Vert.x EventBus

모든 Vert.x 인스턴스에는 하나의 이벤트 버스 인스턴스가 있으며, 이벤트 버스는 eventBus 메소드를 사용하여 얻을 수 있다

Verticle 간에 통신이나, Vert.x Instance간의 통신이 가능하게 한다.

특징

1. 여러 서버 노드와 여러 브라우저에 걸친 분산형 P2P 메시징 시스템을 형성합니다.
2. 게시/구독, 지점 간, 요청-응답 메시징을 지원합니다.
3. API는 매우 간단한데 기본적으로 핸들러 등록, 핸들러 등록 취소, 메시지 전송 및 게시가 포함됩니다.

Vert.x 정리

Reactive(반응형): Vert.x의 핵심은 reactive framework입니다. 즉, 비동기식 비차단 개발 모델을 장려합니다. Vert.x로 빌드된 애플리케이션은 최소한의 스레드로 많은 수의 동시 연결을 처리할 수 있으므로 확장성이 뛰어납니다.

Polyglot: Vert.x는 Java로 작성되었지만 다양한 언어를 지원하므로 Java, JavaScript, Groovy, Ruby, Kotlin 등 다양한 언어를 사용하여 Vert.x 애플리케이션을 작성할 수 있습니다.

Event-Driven(이벤트 중심): Vert.x는 이벤트 중심입니다. Vert.x의 모든 기능은 비차단 방식이므로 적은 수의 스레드로 많은 동시성을 처리할 수 있습니다. 이를 위해 Vert.x는 Java NIO(논 블로킹 IO) 라이브러리를 사용합니다.

Verticles: Vert.x의 기본 배포 단위로, 병렬로 실행되는 애플리케이션의 일부로 생각할 수 있습니다. 각 Verticles 인스턴스는 단일 스레드이지만 여러 인스턴스를 배포하여 코어와 머신에 걸쳐 확장할 수 있습니다.

이벤트 버스: Vert.x의 뛰어난 기능 중 하나는 분산 이벤트 버스입니다. 이를 통해 버티클은 위치에 관계없이 서로 통신할 수 있어 느슨하게 결합된 아키텍처를 촉진합니다. 이벤트 버스는 브라우저에서 실행되는 클라이언트 측 자바스크립트까지 확장됩니다.

확장성: Vert.x는 모듈식이며 커뮤니티에서 다양한 모듈(인증, 데이터베이스 액세스 등)을 제공합니다. 필요한 모듈이 없는 경우 직접 작성할 수도 있습니다.

역할 기반 접근 제어는 컴퓨터 시스템에서 권한이 있는 사용자들에게 시스템 접근을 통제하는 방법 중 하나 입니다.

권한을 사용자나, 사용자가 속한 그룹에다 역할을 할당하여 접근을 제어하는 방식을 말하는데 즉 사용자가 해당하는 역할에 따라서 자원에 대한 접근을 제어한다.

임의적 접근 제어(DAC)와 강제적 접근 제어(MAC)의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다.

예를 들어서 사용자에게 admin 역할을 할당 해주게 되면 해당 사용자는 관리자의 권한을 가지게되어서 관리자가 할 수 있는 모든 행동이 가능하게 됩니다.

반대로 viewer라는 역할을 사용자에게 할당 해주게 된다면 해당 사용자는 단순히 볼 수 있는 행동만 가능하게 됩니다.

장점

역할이라는 것은 정의한다면 해당 역할이 어떠한 권한을 가져야 하는지 누구나 쉽고 빠르게 알 수 있다. 필요한 담당자를 정의하면 해당 담당자는 해야할 일과 가져야하는 권한을 함께 정의할 수 있게 된다.

역할은 어떤 사람을 지칭하는 것이 아니기 때문에 역할을 부여하거나 변경하는 것만으로도 유연하고 효율적으로 권한을 부여하거나 회수할 수 있다.

그렇기 때문에 역할 기반 접근제어는 유연하고 직관적이며 효율적으로 통제 할 수 있고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어들게 된다.

사용자와 역할 사이의 관계는 보통 다대다(N:M)관계이기 때문에 한 사용자는 여러개의 역할을 부여 받을 수 있습니다.

단점

역할에 따른 권한 정책을 정의하기 때문에 정책이 현실과 딱 맞아 떨어지지 않는 경우도 생길 수 있고 여러 역할에 따라 중복되는 권한이 있을 수 있고 비슷한 일이지만 약간의 다른일을 해야 한다면 별도의 역할을 또 만들어야 한다는 단점

이런식으로 역할을 지정하는 권한에 대해서 세밀하게 관리하기 어렵고 반대로 너무 큰 단위로 설계하게 되면은 보안에서는 최소한의 권한이 가장 중요한데

필요 이상의 많은 권한을 가지게 되어 보안이 취약해지게 된다.

앞에서 말한 다양한 권한에 대해서 고려하다 보면 권한의 요소, 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있기 때문에 역할을 적절히 유지하는 것도 중요하다

ABAC(Attribute-Based Access Control)

속성 기반 접근 제어는 속성을 기반으로 권한을 정의하는 권한 부여 전략입니다.

객체에 접근하기 위해 속성에 대해 정의하고 그 객체에 접근 하려는 주체가 그 속성을 가지고 있는지를 검사하고 접근 제어를 수행합니다.

속성은 주체의 이름, 자원에 대한 유형 등 다양하게 있으며 지원하는 종류는 서비스 혹은 플랫폼에 따라 다릅니다.

장점

세분화된 권한을 사용할 수 있고 시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋다

단점

큰 규모의 시스템에서 일일히 속성을 적용하게 되면 많은 시간이 걸리게 되고 복잡한 속성 조건을 계산 해야하기 때문에 성능이 다소 느릴 수 있다.

RBAC과 ABAC을 AWS에서 쉽게 접해볼 수 있고 사용해 볼 수 있다.

IAM을 통해서 다양한 직무에 따라서 서로 다른 정책을 생성하여서 RBAC을 구현하고 IAM 사용자, 사용자 그룹에 연결하여 사용한다.

이런 기존 RBAC 모델을 사용하게 되면 직원이 새 리소스를 추가할 때마다 해당 리소스에 액세스할 수 있도록 정책을 업데이트 해야한다는 문제점이 단점이 있다.

AWS에서는 ABAC을 태그를 이용해서 이용하게 되면은 앞서 말한 RBAC 보다 다양한 이점등을 제공한다.

권한은 혁신적으로 확장할 수 있고 필요한 정책 수가 적어진다.

팀은 빠르게 변화하고 성장할 수 있게 되며, 세분화된 권한을 사용할 수 있다.