interplanetary detour

Master Node와 Worker Node 생성 및 기본 설정

1. k8s-m 설치(ubuntu-20.04.2-live-server-amd64.iso)

2. k8s-m IP 주소 설정(netplan apply & shutdown) 및 스냅샷

3. k8s-m 클론떠서 k8s-w1, k8s-w2, k8s-w3 생성

4. 워커 노드 하나씩 접속하여 IP 주소 설정(netplan apply & shutdown) 및 스냅샷

* Master는 메모리 4GB, CPU 2개로 잡고 Worker는 메모리 2GB, CPU 1개로 잡는다.

kubeadm 으로 k8s 클러스터 생성 & CNI 설치

# 마스터 노드에서 클러스터 초기화 (K8s version v1.21.1)
kubeadm init --apiserver-advertise-address 192.168.79.200 --pod-network-cidr=172.16.0.0/16 --service-cidr 10.10.0.0/16

# 출력 내용 중 아래 2줄을 워커 노드에서 입력
kubeadm join 192.168.79.200:6443 --token t9fzfv.dxvtsz75l418ojf1 \
--discovery-token-ca-cert-hash sha256:055a3aef6fb8e930bff50da508007748fe97d3683c312c91c877069129930642

# k8s 관리를 위한 사용자(현재 root 사용자) 설정
echo $HOME
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

# CNI - calico install : Pod 대역 자동으로 인식 (명령어 한 줄씩)
curl -O https://docs.projectcalico.org/manifests/calico.yaml
sed -i 's/policy\/v1beta1/policy\/v1/g' calico.yaml
kubectl apply -f calico.yaml

# calicoctl install

curl -o kubectl-calico -O -L "https://github.com/projectcalico/calicoctl/releases/download/v3.19.1/calicoctl"

chmod +x kubectl-calico

mv kubectl-calico /usr/bin

# Source the completion script in your ~/.bashrc file
echo 'source <(kubectl completion bash)' >>~/.bashrc
echo 'source <(kubeadm completion bash)' >>~/.bashrc

# alias kubectl to k
echo 'alias k=kubectl' >> ~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc

* 본인 VMnet8(NAT)의 IP 대역대에 맞게 수정하여 적용

* 출력되는 해시값이 다 다르기 때문에 본인 커맨드 창에 뜬 명령어를 긁어야 함

노드 상태 확인 명령어들

watch -d -n 2 "kubectl get node"

kubectl get node
kubectl get node -w

kubectl-calico node status

kubectl describe node k8s-w1

kubectl get nodes -o wide

조금 시간이 지난 후 wide 명령어를 쳐서 STATUS가 전부 Ready 상태로 올라와 있으면 설정 성공.

이 4개의 서버는 calico라는 네트워크를 통해 하나의 클러스터로 묶여 있는 상태이다.

kubectl Commands Cheat Sheet

https://kubernetes.io/ko/docs/reference/kubectl/cheatsheet/

참조 사이트 (Official)

kubernetes.io

subicura.com/k8s/guide

Container Orchestration

Container Orchestration이란 복잡한 컨테이너 환경을 효과적으로 관리하는 것이라고 정의할 수 있고, 그것을 위해 여러가지의 툴이 만들어졌으나 그 중 거의 표준으로 쓰이고 있는 도구(Framework)가 바로 쿠버네티스이다.

아래에서 대표적인 기능 6가지를 알아본다.

1. Cluster

위와 같이 사양이 제각각인 여러 개의 노드(On-premise: 실제 서버, Cloud: VM Instance)가 있을 때 이를 논리적으로 하나인 것처럼 Clustering하여 관리하는 것이 Cluster이다. 이 역할을 수행하는 것이 Master(Control Plane)이고, 하나의 Cluster(Data Plane)로 묶이는 각 Node들은 Worker Node라고 한다.

그렇게 만들어진 Cluster는 Master가 지속적으로 Auto Scaling을 하며 관리한다.

2. State

replicas 값의 변화를 자동적으로 감지하고 그에 맞춰 Pod를 증감시킨다.

과거에 SLB(Server Load Balancer)가 수행하던 일이라고 한다.

위와 같이 3이 되었을 경우 Pod 하나가 생성될 것이고, Pod에 문제가 생겨 동작을 하고 있지 않다면 그 또한 조절한다.

3. Scheduling

하나의 클러스터로 묶여 있는 3개의 Node가 있고, 그 위에 이렇게 애플리케이션이 작동하고 있을 때, 새로운 애플리케이션 인스턴스가 추가되어야 한다면 자동적으로 리소스 낭비가 가장 적도록 할당하는 것이다.

위와 같은 경우 2번째 Node에 추가될 것이고, 같은 규모의 애플리케이션이 또 추가되어야 한다면 Node를 새로 생성하여 그 위에 올린다.

4. ROLLOUT / ROLLBACK

이미지의 배포 버전이 업, 다운됨에 따라 ROLLOUT, ROLLBACK을 자동적 그리고 일괄적으로 처리하여 버전 관리를 수행할 수 있다. 위 상황과 같이 버전이 업그레이드 되면 일괄적 ROLLOUT을, 만약 새 버전에 문제가 발생해서 복구해야 한다면 이전 버전으로 ROLLBACK한다.

5. SERVICE DISCOVERY

Service Discovery는 컨테이너 내부에서 실행되는 서비스(ex: Web Server)의 생성을 자동으로 감지하고 등록하여 프로세스를 재시작하게 하는 기능이다. 이를 통해 관리자가 별도로 설정을 해 줄 필요 없이 외부에서 바로 서비스에 접근할 수 있게 된다.

6. VOLUME

NFS(File Storage), EBS(Block Storage), PD(Block Storage) 등을 Node에 할당하고 연결시켜서 볼륨 스토리지 관리를 할 수 있게 한다.

먼저 Ubuntu Server의 iso 이미지를 다운로드 받아서 Oracle VirtualBox에 가상 머신을 만들었다.

설치 방법 및 기본 설정은 이전 게시글에 있으니 링크를 걸어둔다. 하지만 이번 실습에선 아래 글과 같이 하나하나 설정하지 않고 대부분 기본 설정으로 빠르게 만들었다. 또한 네트워크 인터페이스 카드도 NAT 하나만 설정했다.

https://yoonhoji.tistory.com/3?category=1042734 

Configure Ubuntu Server

먼저 인터넷 연결을 확인한다.

sudo apt update

NetworkManager를 설치한다.

sudo apt install -y network-manager

sudo systemctl status network-manager

포트 포워딩 적용을 위해 위에 첨부한 글을 참고해 설정해준다.

포트포워딩 & NAT Network 설정

시스템 설정 파일인 yaml 파일을 백업해둔다.

cd /etc/netplan

sudo cp 00-installer-config.yaml 00-installer-config.yaml.bak

sudo nano 00-installer-config.yaml

두 칸씩 들여쓰기에 주의하며 yaml 파일에 고정 IP 주소를 할당한다. 수정을 완료했다면 Ctrl+O로 덮어쓰고, Ctrl+X로 nano editor를 빠져나가면 된다.

sudo netplan try

(Enter)

sudo netplan apply

sudo systemctl stop network-manager

sudo systemctl start network-manager

sudo systemctl stop network-manager

sudo systemctl start network-manager

NetworkManager를 몇 번 재부팅 해 주고 난 뒤 인터넷 연결을 확인하기 위해 업데이트를 해본다.

sudo apt update

만약 여기서 인터넷 연결이 안 되었다고 나온다면 게이트웨이로 핑을 쳐 봐야 한다.

ping 10.0.2.1

ping 10.0.2.2

ping 10.0.2.3

이 정도로 확인해보면 첫 번째는 연결이 안 될 것이고 2번이나 3번에 핑이 닿는다면 아까 정적으로 IP 주소를 할당해 주었던 단계로 돌아가서 gateway4 부분을 수정해주고 이후의 과정을 수행하고 난 뒤 다시 업데이트를 해 본다.

sudo apt update

인터넷 연결이 정상적으로 되었다면 hostname을 수정한다.

cd $HOME

sudo nano /etc/hostname

위와 같이 설정하고 저장한다.

sudo nano /etc/hosts

위와 같이 두 번째 줄의 hostname을 변경하고 저장한다.

그리고 핑을 쳐서 호스트 네임이 정상적으로 인식되고 있는지 확인한다.

Client Tool로 접속하기 위해 SSH를 설치한다.

sudo apt install -y openssh-server

HOST를 잡아준다.

export HOST=docker-ubuntu

Firewall 설정은 생략했다.

그리고 클라이언트 툴(XShell, putty, SecureCRT 등)으로 접속한다.

127.0.0.1:105

Install Docker Engine

우분투 서버 환경 구성은 완료됐고 이제부터 Docker Engine을 설치한다.

Install Docker Engine on Ubuntu | Docker Documentation

아래 정리한 명령어들은 위의 문서에서 그대로 가져온 것이다.

복사, 붙여넣기로 진행하는 것을 추천.

sudo apt-get update 

sudo apt-get install ca-certificates curl gnupg lsb-release

echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt install docker-ce docker-ce-cli containerd.io

sudo systemctl status docker

sudo docker version

sudo docker run hello-world

Lab 1 - Ubuntu, Git in Docker Container

아래 이미지와 같이 Base Image로 Ubuntu Server를 Pull & Run하고 그 Ubuntu 위에 Git을 Install 한다.

sudo docker pull ubuntu

sudo docker image ls

Run 명령어로 Pull 까지 한 번에 한다.

sudo docker run -it --name git ubuntu:latest bash

(i : Interactive, t : Tty)

apt update

apt install -y git

git --version

exit (도커 프로세스 종료)

sudo docker ps -a

sudo docker commit git ubuntu:git

sudo docker images

sudo docker run -it --name git2 ubuntu:git bash

git --version

exit

sudo docker rm git2

sudo docker rm git

sudo docker rm 7e1 (CONTAINER ID의 앞 3자리)

Lab 2 - Nginx Web Server in Docker Container

(관리자 로그인)

su -

docker search nginx

docker pull nginx

이미지 레이어 확인하기

cd /var/lib/docker/overlay2

ls -l

Nginx는 총 6개의 레이어로 이루어져 있음을 알 수 있다 (l은 디폴트).

Nginx를 Run해서 메모리에 프로세스로 올려 Container로 만든다.

docker run -d --name webserver -p 80:80 nginx:latest

이제 실제 OS인 Windows에서 브라우저를 열고 192.168.56.100:80으로 접속하면 Nginx 웹 서버가 나온다.

Summary

Intelligent Storage System은 최적화된 I/O 처리 능력을 제공하는 다양한 기능을 갖춘 RAID array이다.

• 많은 양의 Cache와 여러 개의 I/O Path를 갖고 있으며, 고도화된 알고리즘을 사용해 성능이 중요한 애플리케이션의 요구 조건을 충족시킨다.
• 가상 스토리지 프로비저닝과 자동 스토리지 티어링 같은 최신 기술과 플래시 메모리를 지원함으로써 스토리지 시스템의 성능과 확장성, 가용성의 한계를 한 단계 높였다.

Advantages of Intelligent Storage System

• Increased capacity
• Improved performance
• Easier data management
• Improved data availability and protection
• Enhanced business continuity support
• Improved security and access control

Data Request/Response Process

Intelligent Storage System은 기본적으로 위와 같은 구성을 가져 간다. Host가 스토리지로부터 데이터를 요청해서 받아 오는 것을 예시로 그 과정을 살펴보면

Request

Host에서 FC SAN(Fibre Channel Storage Area Network)을 통해 Front End의 Controller에 있는 Port(일반적으로 Controller 당 2개씩 있다.)에 연결되고 Cache에서 Back End로, 그리고 Back End에서 물리적 디스크들(스토리지)로 접근하여 요청받은 데이터를 확인한다.

Response

그 데이터를 Back End를 통해서 Cache로 보내고, 그 데이터가 Cache를 거쳐 갈 때 Cache에 저장되면서 Front End, Host까지 도달하게 된다.

이렇게 Cache에 저장된 데이터는 나중에 같은 데이터의 요청을 받았을 경우 매우 빠른 속도로 불러올 수 있다. 그냥 보기엔 요청을 받아서 스토리지까지 가는 과정에서 Cache는 그냥 통로 역할만 하는 것 같지만 실제로는 Cache 위에 요청받은 데이터가 올라와 있는지 확인을 하고 있다면(Hit) 바로 응답, 없다면(Miss) 물리 디스크로부터 받아와서 응답을 하는 것이다.

Cache Data Protection

Cache는 휘발성 메모리이기 때문에 전력이 끊기거나 어떤 장애가 발생하면 디스크에 커밋(캐시의 데이터를 물리 디스크에 저장)하지 않은 데이터를 잃게 된다. 그러한 위험을 줄이기 위한 방법이 바로 Cache Mirroring과 Cache Vaulting이다.

• Cache Mirroring
  • 캐시 기록을 독립적인 2개의 메모리 주소에 저장한다.
  • 캐시 장애가 발생하더라도 쓰기 데이터는 미러에 보존되어 있어 디스크에 커밋할 수 있다.
  • 쓰기만 미러링하기 때문에 이 방법은 사용 가능한 캐시의 활용도를 높일 수 있다.
• Cache Vaulting
  • 정전으로부터 데이터를 보호한다.
  • AC 전력이 복구될 때까지 배터리를 사용해 메모리에 전원을 공급하거나 캐시 컨텐츠를 디스크에 기록할 수 있다.
  • 지능형 스토리지 시스템에서는 많은 양의 데이터를 여러 디스크에 기록해야 하기 때문에 배터리의 전력만으로는 부족하다.
    • 그래서 정전이 발생하면 커밋되지 않은 데이터는 볼트 드라이브라는 전용 드라이브 세트에 덤프된다.

Seoul

en
!
configure table
!
!
!--Phase 1
!
crypto isakmp policy 1
  authentication pre-share
  hash sha 512
  encryption aes 256
  group 5
  exit
!
crypto isakmp key P@ssw0rd address 172.16.23.2 255.255.255.252
!
!
!--Phase 2
!
crypto ipsec transform-set seoul_01 esp-aes 256 esp-sha512-hmac
  exit
!
access-list 101 permit ip 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255
!
crypto map VPN_to_Busan 10 ipsec-isakmp
  set peer 172.16.23.2
  match address 101
  set transform-set seoul_01
  exit
!
!
!--Apply on Interface
!
interface e0/0
  ip address 172.16.12.2 255.255.255.252
  crypto map VPN_to_Busan
  exit
!
ip route 192.168.30.0 255.255.255.0 172.16.23.2

Busan

en
!
configure table
!
!
!--Phase 1
!
crypto isakmp policy 1
  authentication pre-share
  hash sha 512
  encryption aes 256
  group 5
  exit
!
crypto isakmp key P@ssw0rd address 172.16.12.2 255.255.255.252
!
!
!--Phase 2
!
crypto ipsec transform-set busan_01 esp-aes 256 esp-sha512-hmac
  exit
!
access-list 101 permit ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255
!
crypto map VPN_to_Seoul 10 ipsec-isakmp
  set peer 172.16.12.2
  match address 101
  set transform-set busan_01
  exit
!
!
!--Apply on Interface
!
interface e0/0
  ip address 172.16.12.2 255.255.255.252
  crypto map VPN_to_Busan
  exit
!
ip route 192.168.30.0 255.255.255.0 172.16.23.2

EVE-NG 웹 클라이언트에서 Node를 통해 Capture를 실행할 때 Wireshark에서 "end of file on pipe magic during open"라고 오류가 뜨는 경우가 있다. 이 문제는 두 단계로 간단히 해결할 수 있다.

먼저 C:\Program Files\EVE-NG\wireshark_wrapper.bat 파일을 메모장(관리자 권한)으로 연다.

그리고 아래와 같이 PASSWORD 부분을 본인이 EVE-NG 가상 머신에 설정했던 값으로 바꿔 준다.

이것만으로 해결이 되는 경우도 있고, 만약 안 된다면 cmd를 열고 putty.exe (본인의 EVE-NG VM Username)@(본인의 EVE-NG IP 주소)를 입력한다. 그러면 putty가 실행되며 키 값을 저장하겠냐는 팝업이 뜨는데 확인을 하고 putty 상에서 EVE-NG 로그인을 한 번 한 뒤에 putty를 닫으면 끝이다. 다른 툴을 사용해도 상관없지만 putty가 무료로 배포되고 설치도 간편하기에 사용했다.

RAID 개요

RAID란 간단히 정리하면 여러 개의 디스크 드라이브를 모아서 하나의 호스트에 연결해 사용할 수 있게 하는 디스크 관리 솔루션이다.

RAID가 처음 등장하게 된 배경은 1980년대 후반에 비즈니스 환경에서의 컴퓨터 사용이 늘어나고 새로운 애플리케이션과 데이터베이스가 대거 등장하면서 스토리지 용량과 성능에 대한 수요가 빠르게 증가함에 따라 낮은 비용으로 고성능의 스토리지를 이용하기 위해서였다.

때문에 RAID의 논문이 처음 발표되었을 당시엔 Independent(독립적인)가 아닌 Inexpensive(저렴한)이었지만 스토리지 기술이 점차 발전하면서 RAID 기술의 목적이 변화하고 실질적 비용도 저렴하다고 할 수 없게 되어서 변경되었다.

RAID의 구현 방법

RAID를 구현하는 방법으로는 Software RAID와 Hardware RAID가 있는데, 소프트웨어 방식은 CPU와 메모리 자원을 부가적으로 사용하기 때문에 전체 시스템 성능에 영향을 끼치고 운영 체제에 따라 호환성의 문제가 있을 수 있어 잘 사용되지 않는다. 하드웨어 방식의 경우는 호스트나 어레이에 전용 하드웨어 컨트롤러를 사용하게 되며, 주로 이(하드웨어) 방식으로 RAID를 구현한다.

RAID의 레벨 (표준 : 0~6)

RAID 0 : Striped array with no fault tolerance(내결함성)

RAID 1 : Disk Mirroring

Nested RAID (1+0, 0+1, etc.)

RAID 3 : 전용 Parity Disk가 있는 Parallel access array

RAID 4 : 전용 독립 디스크 액세스를 사용하는 Parity Disk가 있는 Striped array

RAID 5 : 분산 독립 디스크 액세스를 사용하는 Parity가 있는 Striped array

RAID 6 : Dual 독립 디스크 액세스를 사용하는 분산 Parity가 있는 Striped array

• Even-Odd(짝수 오드) 또는 Reed-Solomon 알고리즘을 통해 패리티를 계산한다.

RAID 7 : 향상된 데이터 I/O 작업 및 데이터 캐싱을 위한 실시간 임베디드 운영 체제 및 프로세서를 포함한다.

RAID의 기본적인 기술 3가지 : Striping, Mirroring, Parity

Striping : RAID 0

Striping은 Host에서 입력된 데이터를 RAID Controller에서 디스크 드라이브 갯수만큼 쪼개고(Strip) 각 디스크에 그 데이터의 조각(Stripe)들을 저장해 두는 기술이다. 여러 개의 디스크를 통해 병렬적으로 I/O가 가능하기 때문에 성능적 측면에서 유리하지만, 디스크 중 하나가 사용할 수 없게 되면 원래 데이터의 일부를 그대로 유실하는 것이기 때문에 내결함성 측면에서의 단점을 가지고 있다.

Mirroring : RAID 1

Mirroring은 Host에서 입력된 데이터를 RAID Controller에서 복제 과정을 거쳐 두 개의 디스크 드라이브에 각각 저장하게 된다.

하나의 디스크에서 데이터의 변경이 일어나면 다른 쪽의 디스크에서도 똑같이 데이터가 변하기 때문에 정적인 상태를 저장해두는 백업의 개념과는 다르다. 미러링은 원래 운용하던 디스크가 고장났을 경우 다른 하나로 계속 운용할 수 있게 한다는 내결함성을 보장하기 위한 장치라고 볼 수 있다.

Striping과는 달리 내결함성을 충족하지만 복제 과정에서 시간이 소요되기 때문에 쓰기(Input)의 속도가 떨어진다.

Parity : RAID 3

Parity는 Host에서 입력된 데이터를 RAID Controller에서 Parity값을 구하는 계산을 수행한 후 Parity값만을 저장할 Parity Disk에 구한 Parity값을 입력하고, 나머지 디스크에 Striping과 같이 데이터들을 쪼개서 저장한다.

이 Parity값을 통해 고장난 다른 디스크의 정보를 복구할 수 있지만 2개 이상이 동시에 고장나거나 Parity Disk 자신이 고장난 경우에는 복구가 불가능하다는 특징이 있다.

Nested RAID & RAID 5

Nested RAID (1+0)

Nested RAID는 일종의 하이브리드 RAID 방식으로 주로 RAID 0 + RAID 1이나 RAID 1 + RAID 0 조합을 사용한다. 0+1의 경우는 스트라이핑이 미러링보다 앞서 이루어지기 때문에 디스크 손상 시 복구하는 과정이 1+0 대비 복잡하고 특별한 이점이 없어 잘 사용되지 않는다.

1+0의 경우는 위의 그림과 같이 미러링이 먼저 이루어진 후 스트라이핑을 통해 데이터를 분산 저장하는 방식인데, I/O 처리 속도와 가용성 두 가지를 전부 챙길 수 있기 때문에 효율적이다.

RAID 5

RAID 5는 패리티 비트 활용 방식인 RAID 3의 확장형이라고 할 수 있다. RAID 3의 단점은 2개 이상의 디스크가 고장나거나 Parity Disk가 고장나게 되면 복구가 불가능하다는 것이었는데, RAID 5에서는 계산된 패리티 비트를 2개의 디스크에 나누어 저장함으로써 RAID 3보다 뛰어난 가용성을 가지게 되었다.

애플리케이션 IOPS 계산

애플리케이션의 RAID 레벨 결정

RAID 1+0

• 소규모, 랜덤 및 쓰기 작업이 많은(일반적으로 30% 이상 쓰기) I/O 프로파일을 사용하는 애플리케이션에 적합
• ex) OLTP, RDBMS

RAID 3

• 대규모 환경에서 순차적으로 읽고 쓰기 작업이 많은 환경
• ex) data backup, Multimedia streaming

RAID 5 / 6

• 소규모, 랜덤 워크로드(일반적으로 30% 미만 쓰기)
• ex) email, RDBMS

RAID Comparison

아래 표를 통해 각 RAID 별 필요한 최소 디스크 개수, 스토리지 효율 등의 정보를 확인하고 비교할 수 있다.

Hot Spare

핫 스페어는 고장난 디스크를 잠시 대신하기 위한, RAID 어레이에 있는 여분의 드라이브를 말한다.

• 패리티 RAID를 사용하는 경우 : RAID 집합의 살아 있는 디스크 드라이브의 데이터와 패리티로부터 데이터를 복구해 핫 스페어에 저장한다.
• 미러링 RAID를 사용하는 경우 : 미러의 데이터를 핫 스페어에 복사한다.

새 디스크 드라이브를 시스템에 추가하면 핫 스페어의 데이터를 새 드라이브에 복사한다. 데이터의 복사가 완료되면 핫 스페어는 다시 대기 상태로 돌아가고 다음 고장 드라이브를 대처할 준비를 한다.