cloud engineer 취준일기

permission

sunchan — Tue, 1 Oct 2024 23:56:13 +0900

리눅스에서 생성하는 파일들에 대한 접근 권한 설정

권한 구분

drwx rwx rwx

1 리소스 종류
2~4 소유자 권한
5~7 그룹 권한
8~10 기타사용자 권한
-는 접근 불가능 나타냄

권한파일디렉토리

읽기 (r)	사용자가 파일의 내용을 볼 수 있음	사용자가 디렉토리 내 파일 목록을 볼 수 있음
쓰기 (w)	사용자가 파일을 변경할 수 있음	사용자가 디렉토리 내 파일과 디렉토리를 생성 및 삭제할 수 있음
실행 (x)	사용자가 실행 파일을 실행할 수 있음	사용자가 디렉토리 이동 및 디렉토리를 생성할 수 있음

chown 명령

chown [-옵션] 새소유자명 파일명or디렉토리명

옵션설명

-c	변경된 파일들에 대해 자세한 메시지 보여줌
-R	파일과 하위 디렉토리까지 변경
-v	작업 진행 상태를 자세하게 보여줌
새소유자명	파일에 대한 새 소유자의 이름 지정
파일명	변경할 파일 지정
디렉토리명	변경할 디렉토리 지정

chgrp 명령

chgrp 그룹명 파일명or디렉토리명

groups 명령 --groupadd, groupdel

사용자가 속한 그룹명 알고싶은 경우 사용 groups
#groupadd –g GID(그룹 번호) 신규그룹디렉토리명 : 새로운 그룹명 만들기
#groupdel 삭제할 그룹명 :　그룹명 삭제하기
#gpasswd [옵션] 그룹명 : 기존 그룹에 가입 및 탈퇴 –a옵션으로 추가, -d로 삭제

파일/디렉토리의 접근허가 권한 의미

Unix의 파일과 디렉토리는 소유자, 소유자 속한 그룹 기타 사용자별 읽기, 쓰기, 실행의 접근허가 권한을 갖는다.

chmod(CHange MODe)명령

chmod명령을 사용하면 파일, 디렉토리의 접근 허가 권한을 변경할 수 있다. 기호모드와 8진수 모 드를 이용해 파일의 접근 허기를 변경하며 보통 8진수 모드가 널리 사용된다.

기호모드

chmod [ugoa] [+or-] [rwx] 파일명or디렉토리명

기호의미

u	사용자
g	사용자가 속한 그룹
o	기타 사용자
a	ugo 모두를 의미
+	사용권한 부여
-	사용권한 삭제
r	읽기 사용권한 허가
w	쓰기 사용권한 허가
x	실행 사용권한 허가

8진수 모드

chmod 8진수허가모드 파일명or디렉토리명

허가상태2진수8진수설명

rwx	111	7	read, write, execute 허가
rw-	110	6	read, write 허가
r-x	101	5	read, execute 허가
r--	100	4	read 허가
-wx	011	3	write, execute 허가
-w-	010	2	write 허가
--x	001	1	execute 허가
---	000	0	접근 금지로 사용 불가

umask 명령

파일과 디렉토리 생성시 자동적으로 접근 권한 모드를 설정하는 명령

umask [마스크] : 파일은 666 디렉토리는 777이 기본 접근 권한

Vi 편집기

sunchan — Tue, 1 Oct 2024 23:53:55 +0900

기본적으로 제공되는 vi편집기는 파일에 데이터를 입력하는 등 편집에 사용된다. vi편집기는 다양한 편집 기능과 명령을 제공하며, 강력한 검색 및 치환기능, 자동 들여쓰기, 줄번호 표시 등의 사용자 정의기능을 갖추고 있다. 초기에는 사용하기 다소 어렵지만 익숙해지면 높은 생산성을 제공하는 강 력한 편집기다.

vi편집기의 3가지 편집모드

직접 명령모드 : ‘vi 파일명‘ 명령으로 편집기 접근 시 초기 화면으로 이때 입력되는 모든 문자는 명령으로 해석된다.

a : 현재 커서 위치 다음부터 새로운 문자를 입력
i : 현재 커서 위치 dkvdp 새로운 문자를 입력
o : 현재 커서 위치 다음라인에 새 라인 추가하고 문자를 입력
O : 현재 커서 위치 위 라인에 새 라인 추가하고 문자를 입력
x : 현재 커서 위치 문자 삭제
dd : 현재 커서 위치 라인 삭제
a, i, o, O : 입력 시 데이터 입력모드 진입

데이터 명령모드 : 직접 명령모드에서 a, i, o, O 입력하여 진입
데이터 명령모드에서 입력되는 문자는 작업 버퍼에 저장되고 디스크에 저장을 위해 ESC키를 쳐 직접 명령모드로 나간 후 :w!명령으로 저장
간접 명령모드 : 직접 명령모드에서 콜론(:)입력하여 마지막줄에 콜론이 찍히며 진입.w! : 저장
q! : 종료
wq! : 기존 존재파일 점검없이 쓰고나옴(입력한 작업버퍼내용 파일로 저장)

vi편집명령

텍스트 입력(입력모드 전환)

	i : 현재커서 앞에 문자입력, I : 현재 줄의 앞에 문자입력
	a : 현재커서 뒤에 문자입력, A : 현재 줄의 끝에 문자입력
	o : 현재 줄의 아래에 입력. O : 현재 줄의 위에 입력

커서 이동

글자 단위
h : 한 칸 왼쪽
j : 한 줄 아래
k : 한 줄 위
l : 한 칸 오른쪽
단어 단위
b : 이전 단어의 첫 문자로 이동
w : 다음 단어의 첫 문자로 이동
e : 단어의 끝으로 이동, 커서 위치가 단어의 끄,x이라면 다음 단어의 끝으로 이동
텍스트 삭제(직접 명령모드)
x : 커서 위치 한 개의 문자 삭제
X : 커서 위치 앞의 한 문자 삭제
d0 : 커서위치 라인의 선두까지 문자 삭제
d$, D : 커서 위치 라인의 마지막까지 모든 문자 삭제
dw : 커서 위치 한 단어 삭제
dd : 커서 위치 한 라인 삭제
D : 커서 위치 줄의 끝까지 삭제

문자열 검색

	순방향 : /문자열/, /문자열
	역방향 : ?문자열?, ?문자열

복사, 붙이기, 이동

범주명령어설명

복사	yw	한 단어 복사하기
	nyw	여러 단어 복사하기
	yy, Y	한 줄 복사하기
	nyy, nY	여러 줄 복사하기
--------	----------	----------------------------------
붙이기	p	커서 우측/아래 줄에 붙이기

텍스트 바꾸기

범주명령어설명

문자	r	커서 위치한 곳 문자 한 개를 다른 한 개의 문자로 변경
문자	R	커서 위치한 곳부터 문자를 입력하면 덮어 씌워지며 ESC 키로 해제
단어	cw	커서가 위치한 한 단어를 다른 단어로 바꾸는 명령
한 줄 내용	c	현재 커서 위치한 왼쪽 텍스트는 바꾸지 않고 오른쪽으로만 변경

파일 편집 기타 기능들

명령어설명

:r	현재 파일의 커서 위치 다음에 다른 파일의 내용 삽입
:!	파일 편집 중 vi 상태에서 Linux 명령어 실행
:sh	잠시 쉘 상태로 들어가는 명령, exit에 의해 다시 vi 상태로 돌아감

vi환경옵션

vi에디터의 여백, 라인번호, 화면크기, 들여쓰기 등의 사전 설정은 .vimrc에서 옵션을 수정하여 저장 할 수 있다.

옵션의 종류

옵션(약어)기능

set autoindent (set ai)	자동으로 들여쓰기를 한다.
set cindent	C 프로그램에서 자동으로 들여쓰기를 한다.
set smartindent	향상된 자동 들여쓰기
set autowrite (set aw)	다른 파일로 이동하는 명령 실행 전에 현재 파일 강제 저장
set backspace	1로 설정 시 백스페이스로 문자 삭제 제한, 2로 설정 시 가능하게 지정
set backspace=indent, eol, smart	줄 끝, 시작, 들여쓰기에서 백스페이스 사용 시 이전 줄과 연결
set backupext=.bak	백업 파일 확장자 지정
set encoding=cp949	확장완성형 한글 인코딩 cp949 사용
set history=	명령어 기록 기억 개수 지정, :후 화살표 키 누르면 이전 명령 보여줌
set hlsearch	문자열 검색할 때 하이라이트

리눅스 cheatsheet

sunchan — Tue, 1 Oct 2024 23:52:06 +0900

1. 시스템 정보 수집

리눅스 버전, 커널, 기타 관련 정보 수집

1-1 cat /etc/*-release

CentOS Stream 8 버전

운영체제의 이름 = “CentOS Stream”

CentOS Stream 의 버전 8

운영 체제의 고유 식별자는 "centos"

이 운영 체제는 Red Hat Enterprise Linux 및 Fedora 와 유사하다

CentOS Stream 의 버전 ID 는 8

플랫폼 ID 는 "platform:el8"

보기 좋은 이름 "CentOS Stream 8"

ANSI 색상 코드는 "0;31"

Common Platform Enumeration (CPE) 이름은 "cpe:/o:centos:centos:8"

CentOS 의 홈페이지 URL 은 https://centos.org/

버그 보고 URL 은 https://bugzilla.redhat.com/

Red Hat 지원 제품은 "Red Hat Enterprise Linux 8"

Red Hat 지원 제품의 버전은 "CentOS Stream"

1-2 cat /proc/version

리눅스 시스템에서 현재 커널의 버전 및 빌드 정보를 출력하는 명령어

Linux version 4.18.0-305.3.1.el8_4.x86_64 : 현재 사용중인 리눅스 커널의 버전

(mockbuild@mockbuild@x86-05.stream.rdu2.radhat.com) : 커널이 빌드된 호스트의 정보.

(gcc version 8.5.0 20210514 (Red Hat 8.5.0-21) (GCC)) : 사용된 GCC (GNU Compiler Collection) 버전 및 빌드
정보.

#1 SMP 날짜정보: 커널이 빌드된 시간 및 날짜

1-3 uname -a

Linux : 현재 운영 체제
localhost.localdomain: 호스트 이름.
4.18.0-529.el8.x86_64: 현재 사용 중인 Linux 커널의 버전
#1 SMP Wed Dec 6 01:03:46 UTC 2023: 커널이 빌드된 SMP (Symmetric Multiprocessing) 커널이며, 빌드된
시간 및 날짜
x86_64 x86_64 x86_64: 시스템 아키텍처. x86_64 아키텍처를 사용
GNU/Linux: 시스템의 운영 체제 유형. GNU/Linux 사용

1-4 dmidecode -t bios (관리자 권한 실행)

시스템 BIOS 에서 하드웨어 정보를 가져옴
Handle 0x0000, DMI type 0, 24 bytes: 일반적인 BIOS 정보를 제공.
BIOS 정보
Vender : 제조사
Version : BIOS 버전
Release Date : BIOS 버전 릴리즈된 날짜
Address : BIOS 메모리 주소
Runtime Size : 메모리 실행 중인 영역 크기
Rom size : BIOS 사용되는 read only memory 크기
특성(Characteristics)
BIOS 의 다양한 특성에 대한 정보로 ISA, PCI, PC Card (PCMCIA), PNP (Plug and Play), APM
(Advanced Power Management), 업그레이드 가능 여부, BIOS 셰도잉, ESCD 지원, 부팅 옵션 정보
BIOS Revision 번호, Firmware Revision 번호 포함

1-5 Free -ht

전체 주 메모리와 Swap 사용량 확인
-h 옵션으로 읽기 쉬운 숫자 표현(Gi. Mi 등), -t 옵션으로 총 합계(Total) 표시
Total : 시스템에 설치된 총 메모리 양
total: 시스템에 설치된 총 메모리 양
used: 현재 사용 중인 메모리 양
free: 사용 가능한 메모리 양
shared: 공유 메모리의 양
buff/cache: 버퍼 및 캐시로 사용 중인 메모리 양
available: 프로그램이 추가 메모리를 사용하기 위해 사용할 수 있는 메모리 양
Swap: 스왑 영역에 대한 정보로, 스왑은 메모리 부족 시 사용되는 가상 메모리 공간
Total: 총 메모리 및 스왑의 합계

1-6 ulimit -n

프로세서가 가질 수 있는 파일 디스크립터(시스템이 열 수 있는 파일이나 소켓과 같은 I/O 리소스) 수가
1024 개인 상태
ulimit -n 명령어가 아무런 결과를 보여주지 않거나 0 이라면, 제한이 설정되어 있지 않음을 의미

2. 사용자와 프로세스 작업

2-1 Who, w

현재 로그인한 사용자 뿐만 아니라 활동에 대한 정보 나열, w 명령으로 더 자세한 정보까지 출력
Who : 사용자의 로그인명, 터미널, 로그인 시간, 원격호스트 출력 /var/run/utmp 파일에서 가져온 정보
W : 사용자 로그인 정보와 현재 작업 내용을 출력, 현재 접속된 사용자와 그 프로세스에 대한 정보를 표시
헤더에는 현재 시간, 시스템 실행 시간, 현재 로그인한 사용자 수 및 지난 1, 5, 15분 동안의 시스템 로드 평균을
순서에 따라 표시.
각 사용자들에 대해 로그인 이름, tty 이름, 원격 호스트, 로그인 시간, 유휴 시간, JCPU, PCPU 및 현재 프로세스의
명령줄과 같은 항목들이 표시된다.

W 옵션

옵션설명

-h	헤더를 출력하지 않음 (--no-header)
-u	현재 프로세스와 CPU 시간 파악 시 사용자 이름 무시
-s	로그인 시간, JCPU, PCPU 시간을 제외한 짧은 형식으로 출력
-f	FROM 필드의 값 (접속 IP주소 정보) 생략하여 출력 (--from)
-i	FROM 필드에 호스트 이름 대신 IP 주소 표시
-v	버전 정보를 출력
-o	1분 미만의 유휴 시간 동안 빈 공간을 출력
user	구체적인 사용자의 정보만 출력

2-2 top -U SOMEUSER

특정 사용자(여기선 student)에 대해 프로세스별로 시스템 메트릭(cpu, 메모리 등)을 표시
표시 내용
시스템 정보 : 현재시간, 동작시간 로그인 사용자 수, 1, 5, 15 분 평균부하
작업정보 : 시스템 전체 작업(프로세스) 수, 현재 실행 중인 작업 수, 현재 대기 중인 작업 수, 정지된
작업 수, 좀비 상태인 작업 수
CPU 사용량

프로세스 목록

항목설명

PID	프로세스 ID
USER	사용자 이름
PR	프로세스의 우선순위
NI	nice 값 (우선순위 수정 값)
VIRT	가상 메모리 크기
RES	실제 사용 중인 메모리 크기
SHR	공유 메모리 크기
S	프로세스 상태 (S는 실행 중인 것을 나타냄)
%CPU	CPU 사용량 비율
%MEM	메모리 사용량 비율
TIME+	프로세스가 실행된 총 시간
COMMAND	실행 중인 명령어 또는 프로그램

2-3 ps faux

세부 정보와 함께 모든 프로세스(모든 사용자)를 트리 형식으로 나열

항목설명

USER	프로세스를 실행한 사용자의 이름
PID	프로세스 ID
%CPU	CPU 사용량의 백분율
%MEM	메모리 사용량의 백분율
VSZ	가상 메모리 크기 (킬로바이트)
RSS	실제 사용 중인 메모리 크기 (킬로바이트)
TTY	터미널 연결 또는 "?"로 나타남
STAT	프로세스 상태 (S: Sleeping, R: Running, Z: Zombie 등)
START	프로세스가 시작된 시간
TIME	CPU를 사용한 총 시간
COMMAND	실행된 명령어 또는 프로그램

2-4 ps -e | grep python

특정 프로세스를 찾음 여기서는 shell

shell이라는 문자열을 포함하는 프로세스를 찾아내 출력
(shell 이라는 문자열이 포함된 모든 프로세스가 나열)

PID (프로세스 ID), TTY (터미널 연결), TIME (프로세스가 실행된 시간) 등이 표시

2-5 kill PID

PID 를 알고있을 때 프로세스 종료
Yes 명령을 실행하고 PID 14473 을 kill 해 Terminated

3. 파일 정보 수집

3-1 stat somefile

파일이나 디렉토리의 상세한 정보를 보여주는 명령

항목설명

File	파일의 이름 ("sample")
Size	파일 크기 (바이트)
Blocks	파일이 차지하는 블록 수
IO Block	파일 시스템의 I/O 블록 크기
Device	파일이 위치한 디바이스
Inode	파일의 Inode 번호
Links	파일을 가리키는 하드 링크의 수
Access	파일의 권한 정보 (0664/-rw-rw-r--)
Uid	파일 소유자의 사용자 ID (UID)
Gid	파일의 그룹 소유자의 그룹 ID (GID)
Context	SELinux의 보안 컨텍스트 정보
Access	파일에 마지막으로 접근한 시간
Modify	파일을 마지막으로 수정한 시간
Change	파일 속성을 마지막으로 변경한 시간
Birth	파일이 생성된 시간 (생성 시간이 기록되지 않은 경우 "-"로 표시됨)

3-2 type somecommand

명령어의 형태 확인

Ls 명령어는 색상을 사용하여 디렉토리, 파일 등을 구분하도록 하는 옵션 적용된 상태

3-3 which somebinary

명령어의 위치를 찾아내 Alias, 현재 위치 출력

4. 파일과 디렉토리 작업

4-1 cat afile

파일의 내용을 표시하는 명령
123 이 입력된 cattest 파일을 생성하고 cat 명령으로 내용확인

4-2 ls -l /etc | wc -l

ls 명령으로 디렉토리의 내용 나열 후, 디렉토리의 파일 수 계산

4-3 find /etc -name “*.conf”

/etc 디렉토리에서 .conf 로 끝나는 파일 탐색

4-4 find . -type f -exec grep -H FINDME {} \;

Grep 명령어로 현재 및 하위 디렉토리에서 sample 문자열이 포함된 라인 탐색

4-5 diff -u somefile anotherfile

파일간의 차이점 보여주는 명령

3 줄의 문자열이 담긴 Sample 과 1234 가 담긴 sample2 비교

4-6 echo ‘Com_Acme_library’ | tr ‘_A-Z’ ‘.a-z’

글자를 바꾸는 명령
tr 명령으로 ComAcme_library 문자열의 대문자를 모두 .소문자로 바꿈

4-7 sed 명령

파일의 문자열 일부를 교체
Sample 파일에 저장된 문자열 중 welcome 을 to 로 변환

4-8 dd if=/dev/zero of=output.dat bs=1024 count=1000

0 으로채워진 output.dat 이름을 가진 1MB 크기 파일 생성

5. 재지정과 파이프 작업

5-1 command 1> file

Ls -l 의 표준 출력을 파일로 재지정

5-2 command 2> file

Ls -l 의 표준에러를 파일로 재지정
3 이라는 명령은 없기 때문에 에러발생

5-3 command &> file

존재하지 않는 디렉토리를 조회해 발생한 오류를 output.txt 에 저장

5-4 command >file 2>&1

위 명령들을 조합해 표준 출력과 에러를 동시에 저장

5-5 command > /dev/null

5-6 command < file

파일을 명령에 입력
Shell 문자열이 입력된 input.txt 파일을 grep 의 표준입력으로 재지정하여 실행

출력을 /dev/null 로 재지정하여 폐기

5-7 cmd1 | cmd2 | cmd3

|파이프를 명령어 사이에 두어 한 프로세스의 표준 출력을 다른 프로세스의 표준입력에 연결

여기서는 디렉토리 내 파일의 크기를 확인하고, 크기를 기준으로 내림차순으로 정렬한 후 상위 5 개 파일을 출력

5-8 echo ${PIPESTATUS[@]}

파이프 각 명령의 종료 코드 0 은 정상종료, 141 은 시그널 오류

6. 시간과 날짜 작업

6-1 timedatectl status

로컬시간, utc 시간, 동기화 상태와 같은 시간 관련 정보 출력

6-2 date +”%Y-%m-%d”

날짜를 출력하는 date 명령에 포맷을 YYYY-MM-DD 형식 지정하여 출력

6-3 date +%s

Date 명령에 유닉스 에포크 타임스탬프 생성

6-4 date -u +”%Y-%m-%dT%H:%M:%SZ”

ISO 8601 형식 UTC 타임스탬프를 생성

6-5 date +%FT%TZ

date -u +”%Y-%m-%dT%H:%M:%SZ” 타임스탬프 형식의 로컬시간

7. 깃 작업

7-1 git clone

깃허브에 생성되어있는 깃 저장소를 복제

7-2 git status

로컬에서 변경된 사항 확인

7-3 git add --all && git commit -m "adds a super cool feature"

모든 로컬 변경사항 추가 및 커밋

7-4 git rev-parse HEAD

현재 커밋의 커밋 ID

7-5 git tag ATAG HASH

ID HASH 커밋에 ATAG 태그 지정

7-6 git log

커밋 기록 확인

8. 시스템 성능

8-1 yes | tr \n x | head -c 450m | grep z

Y 를 끊임없이 출력하는 yes 명령을 tr 명령으로 yx 연속 스트림으로 변환했으며 head 명령은 약 450MB 에
잘라낸다.

Grep 은 존재하지 않는 z 에 대해 결과인 yx 블록을 사용해 터미널에 출력은 없지만 여전히 부하를 생성하며 다른
터미널에서 htop 명령에서 시스템 성능을 체크해 부하를 감지했다.

8-2 du -h /home

Home 디렉토리 기준으로 디렉토리의 자세한 디스크 사용량을 확인

8-3 df -h

사용 가능한 디스크 공간(전역 공간 기준) 나열

8-4 dd if=/dev/zero of=/home/some/file bs=1G count=1 oflag=direct

디스크의 로드를 테스트하고 I/O 처리량 측정

/dev/zero 에서 1GB 의 데이터를 읽어와 /home/student/input.txt 에 씀
특정 디스크의 쓰기 성능 테스트나 큰 파일을 빠르게 만들기 용이

참고도서

모던 리눅스 교과서, Michael Hausenblas 저

Chaos Engineering(chaos mesh)

sunchan — Thu, 26 Sep 2024 02:10:07 +0900

MSA 환경에서는 네트워크 장애, 리소스 부족, Pod 실패와 같은 다양한 오류가 일어났을 시에 원인 지점을 빠르게 찾아내는 기술력이 필수적이다.

의도적인 장애나 혼란을 주입해 시스템의 취약점을 찾아내고, 장애가 발생하더라도 안정적으로 동작할 수 있도록 개선할 수 있는 Chaos engineering 오픈 소스 중 Chaos mesh에 대해 다룬다.

Chaos Mesh

chaos mesh는, 마치 스위스 군용 칼처럼 다양한 장애 상황을 제어된 방식으로 미리 시뮬레이션할 수 있다. Kubernetes 기반 MSA 환경에서 복잡한 장애 상황을 손쉽게 재현하며, 클러스터에서 안정적으로 실험을 수행한다. Kubernetes와의 완벽한 통합 덕분에 실시간으로 다양한 장애를 주입하고 분석할 수 있다. 다양한 장애 유형(네트워크, 리소스, 시스템 수준의 문제)을 주입해 시스템의 취약점을 사전에 발견하고, 복구 및 개선 작업을 위한 데이터를 제공한다. 또한, 오픈소스 특성상 비용 효율적이고, 다양한 오픈소스 커뮤니티의 지원을 받을 수 있다는 점에서도 강점이 있다. 이러한 이유로 Chaos Mesh를 선정했다.

Chaos Mesh 구성과 동작 방식

Chaos Mesh는 Kubernetes CRD 기반의 Chaos Engineering 도구로, 시스템에 제어된 방식으로 다양한 장애를 시뮬레이션하여 복원력을 테스트하는 역할을 수행하며, Chaos Dashboard, Chaos Controller Manager, Chaos Daemon 세 가지 핵심 구성 요소로 이루어져 있다.

Chaos Mesh구성

Chaos Dashboard: 사용자에게 시각적 인터페이스를 제공하며, Chaos 실험을 설정하고 모니터링할 수 있는 웹 대시보드. RBAC(Role-Based Access Control)에 기반한 권한 관리가 가능하다.
Chaos Controller Manager: Chaos Mesh의 핵심 제어 컴포넌트로, 다양한 실험을 스케줄링하고 관리한다. Kubernetes API 서버와 통신하여 이벤트를 수신하고, CRD(사용자 정의 리소스)를 기반으로 실험을 실행한다.
Chaos Daemon: 장애 실험을 실제로 실행하는 구성 요소로, DaemonSet 방식으로 배포되며, 노드의 리소스 및 네임스페이스를 제어한다. 이를 통해 특정 네트워크 장치나 CPU, 메모리 등의 자원을 혼란시키는 방식으로 실험을 수행한다.

docs를 참조하여 임의로 그려본 구성도입니다. 혹시 잘못된 부분이 있다면 지적해주시면 감사하겠습니다.

Chaos Mesh의 아키텍처는 3 부분으로 나눌 수 있으며 역할에 따라 임의로 이름을 붙여주었다.

user input Layer : 사용자는 kubectl cli, client.apply(), dashboard ui 3가지 방식으로 input을 줄 수 있다. 3가지 방식 모두 chaos mesh의 Controller Manager와 직접적으로 상호작용하는 것이 아니라 Network Chaos, Stress Chaos 등 쿠버네티스의 리소스를 변경한다
experiments Layer : 쿠버네티스의 api server가 리소스의 변경사항을 모니터링하고 스케쥴링하는 레이어이다. api server는 input Layer에서 입력된 리소스 변경을 감지하고 Chaos Controller Manager로 변경 사항을 전달한다.
Injection fault Layer : 본격적으로 장애를 주입하는 레이어이다. Chaos Daemon은 Chaos Controller Management의 명령을 수락하고 대상(pod, node 등)을 해킹하여 오류를 주입한다. 특정 오류에는 CPU 스트레스, 네트워크 지연, 특정 pod 접근 차단이나 실패처리 등 다양한 기능이 있으며, 예를 들면 CPU 또는 메모리 리소스를 선점하기 위해 stress-ng 프로세스를 실행하는것이 있다.

설치 및 테스트

Helm사용하여 Chaos Mesh 설치

코드를 활용한 gitops에 유리하도록 Helm을 이용해 설치했다.

# add chaos-mesh chart
$ helm repo add chaos-mesh https://charts.chaos-mesh.org

# create namespace chaos-mesh
$ kubectl create ns chaos-mesh

# install choas-mesh version-2.6.3
$ helm install chaos-mesh chaos-mesh/chaos-mesh -n=chaos-mesh --version 2.6.3

# check resource
$ kubectl get deployments.apps -n chaos-mesh
NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
chaos-controller-manager   3/3     3            3           39h
chaos-dashboard            1/1     1            1           39h
chaos-dns-server           1/1     1            1           39h

Dashboard 접근

port-forward, ingress 등의 방식으로 dashboard에 접근하면 ui 방식으로 Chaos-mesh를 사용할 수 있다.

최초 접속 시 RBAC 기반의 token 값을 입력해야 접속이 가능하다.

Click here to generate 버튼을 클릭하면 manifest 파일 예시문을 작성해준다.

cluster scoped 버튼을 클릭하면 클러스터 전체에서 통하는 clusterrole 생성 manifest 파일을 작성해준다.

Cluster scoped

kind: ServiceAccount
apiVersion: v1
metadata:
  namespace: default
  name: account-cluster-viewer-ucken

---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: role-cluster-viewer-<랜덤 값>
rules:
- apiGroups: [""]
  resources: ["pods", "namespaces"]
  verbs: ["get", "watch", "list"]
- apiGroups: ["chaos-mesh.org"]
  resources: [ "*" ]
  verbs: ["get", "list", "watch"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bind-cluster-viewer-<랜덤 값>
subjects:
- kind: ServiceAccount
  name: account-cluster-viewer-<랜덤 값>
  namespace: default
roleRef:
  kind: ClusterRole
  name: role-cluster-viewer-ucken
  apiGroup: rbac.authorization.k8s.io

cluster scoped 버튼을 해제하면 특정 네임스페이스에 대한 role 리소스에 대한 manifest 파일을 작성해준다.

kind: ServiceAccount
apiVersion: v1
metadata:
  namespace: chaos-mesh
  name: account-chaos-mesh-manager-<랜덤 값>

---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: chaos-mesh
  name: role-chaos-mesh-manager-<랜덤 값>
rules:
- apiGroups: [""]
  resources: ["pods", "namespaces"]
  verbs: ["get", "watch", "list"]
- apiGroups: ["chaos-mesh.org"]
  resources: [ "*" ]
  verbs: ["get", "list", "watch", "create", "delete", "patch", "update"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-chaos-mesh-manager-<랜덤 값>
  namespace: chaos-mesh
subjects:
- kind: ServiceAccount
  name: account-chaos-mesh-manager-<랜덤 값>
  namespace: chaos-mesh
roleRef:
  kind: Role
  name: role-chaos-mesh-manager-<랜덤 값>
  apiGroup: rbac.authorization.k8s.io

파일을 작성하고, 쿠버네티스에 apply하면 토큰 생성을 위한 각 리소스가 배포된다.

$ kubectl apply -f rbac.yaml

$ kubectl create token account-chaos-mesh-manager-<랜덤 값>

UI 소개

Dashboard 메인 페이지

kubectl create token 명령으로 ServiceAccount에 대한 token 값을 생성 후 dashboard에 입력해서 로그인해준다.
메인 페이지에는 왼쪽부터 각 서비스로 연결되는 버튼이 있으며, 현재 생성된 Experiments, Schedules, Workflows 수와 더불어 최근 이벤트를 확인할 수 있다.

Experiments

Experiments 탭에서는 쿠버네티스, 호스트에 개별적으로 장애를 주입할 수 있는 시나리오를 버튼과 텍스트 필드 형식으로 손쉽게 작성할 수 있다.
기본적으로 제공하는 장애 주입 방법은 다음과 같다
kubernetes

AWS/GCP Fault
- Stop EC2/node : 인스턴스 중지
- Restart EC2 / Reset node : 인스턴스 재시작
- Detach volume / Loss disk : 인스턴스에서 스토리지 볼륨을 제거
Block Fault
- delay : 블록 장치의 대기 시간 delay
DNS Fault
- random : 작성한 도메인에 대한 접속 시 임의의 IP 반환
- errer : 작성한 도메인에 대한 접속시 오류 반환
IO Injection
- latency : 파일 시스템 호출을 지연
- fault : 파일 시스템 호출에 대한 오류를 반환
- attrOverride : 파일 속성을 수정
HTTP Fault
- abort : 연결을 중단
- delay : 요청이나 응답에 지연 시간을 주입
- replace : HTTP 요청 또는 응답 메시지의 일부 내용을 대체
- patch : HTTP 요청 또는 응답 메시지에 추가 콘텐츠를 추가
Kernel Fault
- KernelChaos를 사용하여 Linux 커널 오류를 시뮬레이션 지정된 커널 경로에 I/O 기반 또는 메모리 기반 오류를 주입
- 주입 대상을 하나 이상의 Pod로 설정할 수 있지만, 모든 Pod가 동일한 커널을 공유하기 때문에 호스트의 다른 Pod 성능에 영향
- 기본적으로 비활성화 되는 기능이며 프로덕션 환경에서 사용은 위험
Network Attack
- Partition: 네트워크 연결 해제 및 분할
- Net Emulation: 높은 지연, 높은 패킷 손실률, 패킷 재정렬
- Bandwidth: 노드 간 통신 대역폭을 제한
Pod Fault
- Pod Failure : Pod에 오류를 주입하여 일정 시간 동안 Pod를 사용할 수 없게 만듦
- Pod Kill : Pod 종료, Pod를 성공적으로 다시 시작할 수 있도록 하려면 ReplicaSet 등을 사전에 구성
- Container Kill : 대상 Pod에 있는 지정된 컨테이너를 종료
Stress Test
- CPU, Memory 등에 대한 Stress Test
Clock Skew
- 시간 오프셋 시나리오를 시뮬레이션
JVM Fault
- 사용자 정의 예외 발생
- 가비지 수집 트리거
- 메서드 대기 시간 증가
- 메서드의 반환 값 수정
- Byteman 구성 파일을 설정하여 오류 트리거
- JVM 압력 증가

장애 주입 시

특정 워커노드에 CPU Stress를 준 시나리오이다.

Dashboard에서 장애 주입시 위와 같이 이벤트가 실행중인 task, 실제 쿠버네티스 환경에서 사용 가능한
manifest 코드도 확인할 수 있다.

Schedules

Schedules 탭에서는 다양한 장애 주입 시나리오를 버튼과 텍스트 필드를 확인할 수 있으며, cronjob 형식(분 시 일 월 요일)으로 일정을 관리할 수 있다.

Events

지금까지 실행되었던 이벤트들의 UUID, Namespace, name, Kind, 시작시간, Message를 확인할 수 있다.

Settings

Dashboard 상에서 Experiments, Workflows에 대해 몇가지 설정을 할 수 있는 탭이다.

Experiments

Debug mode : 실험을 생성해도 실제 HTTP 요청은 전송되지 않지만 콘솔에 관련 정보가 인쇄
Allow kube-system namespace : 실험 시 kube-system 네임스페이스 선택 가능
Use new PhysicalMachine CRD : PhysicalMachineChaos를 생성할 때 주소 필드를 제공하는 대신 사용 가능한 PhysicalMachines를 검색

Workflows

Use the next generation of workflow interface
- 리팩토링 된 Workflows 인터페이스 사용가능

Workflows 적용 후 마치 블록 코딩 서비스 처럼 인터페이스가 바뀜

장애 주입 테스트

chaos mesh 대시보드와 k8s 환경에서 각각 테스트 해보았다.

Dashboard

우리 서비스가 배포중인 bookshop namespace에 랜덤하게 20%의 Pod Kill을 주입했다.

Namespace : bookshop
Mode : Fixed Percent
Name : pod kill 20%

bookshop namesapce의 8개 Pod 중 order-service와 dispatcher-service가 Terminating되었지만 Deployment 형태로 배포중이었기에 바로 복구되었다.

실제 프로덕션 환경이라면 위 테스트처럼 장애가 발생했을 때 사용자는 책 주문 서비스를 이용할 수 없었을 것이다.

Kubernetes

k8s 환경에서 yaml파일을 작성해 장애 주입 테스트

StressChaos

apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: stress-cpu-80
  namespace: chaos-mesh
spec:
  mode: one           
  selector:
    nodeSelectors:
      kubernetes.io/hostname: <대상 노드> 
  stressors:
    cpu:
      workers: 2      
      load: 50          
  duration: "180s"

쿠버네티스에 CPU에 Stress를 주입하는 manifest 파일이다.
작성한 파일을 배포하면, StressChaos 리소스가 생성되며 Stress Test가 시작된다.

apply 명령 후 Stresschaos 리소스가 생성되고, 26초 뒤 CPU가 62%로 상승하였다.

NetworkChaos

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-denie
  namespace: chaos-mesh
spec:
  action: partition
  mode: all
  selector:
    namespaces:
      - bookshop
    labelSelectors:
      'app': 'edge-service'
  direction: to
  target:
    mode: all
    selector:
      namespaces:
        - bookshop
      labelSelectors:
        'app': 'polar-ui'

사용자가 full-accel.com이라는 도메인으로 접속할 시에 연결되는 edge-service와 polar-ui간의 접속을 NetworkChaos 리소스를 통해 차단했다.

웹 브라우저에서 서비스 접속 시 Error Page를 반환한다.

kiali Dashoard에서 polar-ui로의 접속이 차단된 것을 시각적으로도 확인했다.

Chaos engineering 플랫폼 중 하나인 Chaos mesh를 사용한 장애 주입 테스트를 진행했다. 테스트 환경에서는 Pod가 바로 재시작되고, Chaos 리소스 삭제 시 서비스가 바로 정상으로 돌아왔다.

의도된 장애 주입이기에 빠른 추적이 가능했지만, 프로덕션 환경에서는 Pod가 바로 생성된다는 보장이 없고, 서비스에 따라 완전한 복구까지의 소요 시간이 상이할 수 있다. 바로 생성된다고해도 running상태까지의 소요 시간도 서비스별로 상이하다. 이를 고려하여 Manifest 파일에서 여러 개의 replica를 설정해 각각 여러 노드에 분산 배포하는 등 안정성을 높이는 것이 중요하다.

Chaos Mesh 시뮬레이션을 활용한 분석

테스트 결과, 복잡한 MSA 환경에서 네트워크 장애나 서비스 장애가 발생할 때 빠르게 대응하는 것이 매우 중요함을 알 수 있었다. Chaos Mesh를 통해 이러한 장애 상황을 미리 시뮬레이션하여 문제를 사전에 파악할 수 있다는 점은 큰 장점이다. 또한, 장애 발생 시 빠른 추적을 가능하게 하기 위해 Observability(관찰성) 도구들을 미리 구축하는 것이 효과적이었다. Prometheus, Grafana, Jaeger, kiali와 같은 오픈소스 도구를 사용하여 실시간으로 시스템 상태를 모니터링하고 장애 원인을 추적함으로써, 문제를 빠르게 진단하고 대응할 수 있는 준비가 되어 있음을 확인했다.
결국, Chaos Mesh와 같은 도구를 활용한 사전 테스트는 시스템의 복원력과 신뢰성을 강화하는 데 필수적이며, 이를 통해 장애 발생 시 대응 시간을 최소화하고 프로덕션 환경에서의 안정성을 높일 수 있다.

참고 문서

Chaos mesh docs

Azure의 AKS에서 karpenter 사용

sunchan — Fri, 20 Sep 2024 02:19:22 +0900

Karpenter는 쿠버네티스 클러스터 자동 확장에 정말 유용한 도구로 많이 알려져 있지만 Azure 환경에서의 정보는 거의 없는 것 같습니다.

저 또한 공식 문서에도 자세한 내용이 없어서 막막했습니다.

그래서 이번 글에서는 AKS에서 Karpenter를 구성하고 활용하는 방법에 대해 공유해 보려고 합니다.

1. 사전 설정

소프트웨어 버전

WSL Ubuntu	Ubuntu 22.04.3 LTS
Azure CLI	2.64.0
Helm	v3.15.4
AKS	1.29.7

Azure vm vCPU(수량) 메모리(GB)

Standard_D2_v4

제한 사항 및 지원되지 않는 기능 (Azure docs참고)

제한 사항

허용되는 유일한 네트워크 구성은 Cilium 제공 Azure CNI 오버레이입니다.
노드 풀에 클러스터 자동 크기 조정기가 사용하도록 설정된 클러스터에서는 사용하도록 설정할 수 없습니다.

지원되지 않는 기능

Windows 노드 풀
노드 kubelet에 사용자 지정 구성 적용
IPv6 클러스터
서비스 주체시스템이 할당한 관리 ID 또는 사용자가 할당한 관리 ID를 사용할 수 있습니다.
참고
디스크 암호화 집합
CustomCATrustCertificates
시작 중지 모드
HTTP 프록시
OutboundType 변형입니다. 모든 OutboundType은 지원되지만 만든 후에는 변경할 수 없습니다.

2. AKS 상에서 작업

# 명령에 사용될 변수 값 지정
export CLUSTER_NAME=karpenter
export RG=karpenter
export LOCATION='koreacentral'
export KARPENTER_NAMESPACE=kube-system

# 리소스 그룹 생성
$ az group create --name ${RG} --location ${LOCATION}
{
  "id": "/subscriptions/<Subscription ID>/resourceGroups/karpenter",
  "location": "koreacentral",
  "managedBy": null,
  "name": "karpenter",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

# karpentermsi이름으로 Managed Identity 생성
$ KMSI_JSON=$(az identity create --name karpentermsi --resource-group "${RG}" --location "${LOCATION}")

# Microsoft.ContainerService 제공자를 등록
$ az provider register --namespace Microsoft.ContainerService

# aks 생성
$ AKS_JSON=$(az aks create \
  --name "${CLUSTER_NAME}" --resource-group "${RG}" \
  --node-count 2 --generate-ssh-keys \
  --network-plugin azure --network-plugin-mode overlay --network-dataplane cilium \
  --enable-managed-identity \
  --enable-oidc-issuer --enable-workload-identity)
  
# aks에서 작업할 수 있도록 자격증명 등록 역할 할당
$ az aks get-credentials --name "${CLUSTER_NAME}" --resource-group "${RG}" --overwrite-existing
Merged "karpenter" as current context in /home/ubuntu/.kube/config

# 인증 사용을 위해 karpenter 서비스 계정에 연결된 연합 자격 증명 생성.
$ az identity federated-credential create \
  --name KARPENTER_FID --identity-name karpentermsi --resource-group "${RG}"  \
  --issuer "$(jq -r ".oidcIssuerProfile.issuerUrl" <<< "$AKS_JSON")"  \
   --subject system:serviceaccount:${KARPENTER_NAMESPACE}:karpenter-sa \ 
   --audience api://AzureADTokenExchange
{
  "audiences": [
    "api://AzureADTokenExchange"
  ],
  "id": "/subscriptions/<구독 id>/resourcegroups/karpenter/providers/Microsoft.ManagedIdentity/userAssignedIdentities/karpentermsi/federatedIdentityCredentials/KARPENTER_FID",
  "issuer": "https://koreacentral.oic.prod-aks.azure.com/2c667446-26d0-430d-8fe5-373c81417422/87e6b018-64f9-4531-9b73-ead801527cb4/",
  "name": "KARPENTER_FID",
  "resourceGroup": "karpenter",
  "subject": "system:serviceaccount:kube-system:karpenter-sa",
  "systemData": null,
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials"
}

# karpenter가 vm, 네트워크 리소스를 관리할 수 있도록 역할 할당
$ KARPENTER_USER_ASSIGNED_CLIENT_ID=$(jq -r '.principalId' <<< "$KMSI_JSON")
RG_MC=$(jq -r ".nodeResourceGroup" <<< "$AKS_JSON")
RG_MC_RES=$(az group show --name "${RG_MC}" --query "id" -otsv)
for role in "Virtual Machine Contributor" "Network Contributor" "Managed Identity Operator"; do
  az role assignment create --assignee "${KARPENTER_USER_ASSIGNED_CLIENT_ID}" --scope "${RG_MC_RES}" --role "$role"
done

3. helm install

curl -sO <https://raw.githubusercontent.com/Azure/karpenter-provider-azure/main/hack/deploy/configure-values.sh>
chmod +x ./configure-values.sh && ./configure-values.sh ${CLUSTER_NAME} ${RG} karpenter-sa karpentermsi

configure-values.sh의 마지막줄 yq 대신 envsubst < karpenter-values-template.yaml > karpenter-values.yaml로 수정

$ export KARPENTER_VERSION=0.5.1

$ helm upgrade --install karpenter oci://mcr.microsoft.com/aks/karpenter/karpenter \\
  --version "${KARPENTER_VERSION}" \\
  --namespace "${KARPENTER_NAMESPACE}" --create-namespace \\
  --values karpenter-values.yaml \\
  --set controller.resources.requests.cpu=1 \\
  --set controller.resources.requests.memory=1Gi \\
  --set controller.resources.limits.cpu=1 \\
  --set controller.resources.limits.memory=1Gi \\
  --wait
  
$ k get po -n kube-system | grep karpenter
karpenter-5cf5cc5d5b-k5f9q  1/1  Running   0   2m10s

4. NodePool, AKSNodeClass 생성

nodeclass 생성 시 imageVersion을 명시하지 않으면 node를 감지하지 못해 aks 노드그룹에 추가되지 않는 오류 발생

$ cat <<EOF | kubectl apply -f -
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: general-purpose
  annotations:
    kubernetes.io/description: "General purpose NodePool for generic workloads"
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: karpenter.azure.com/sku-family
          operator: In
          values: [D]
      nodeClassRef:
        name: default
  limits:
    cpu: 100
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: Never
---
apiVersion: karpenter.azure.com/v1alpha2
kind: AKSNodeClass
metadata:
  name: default
  annotations:
    kubernetes.io/description: "General purpose AKSNodeClass for running Ubuntu2204 nodes"
spec:
  imageFamily: Ubuntu2204
  imageVersion: 202408.21.0 
EOF
nodepool.karpenter.sh/general-purpose created
aksnodeclass.karpenter.azure.com/default created

$ k get nodepools.karpenter.sh 
NAME              NODECLASS
general-purpose   default
$ k get aksnodeclasses.karpenter.azure.com 
NAME      AGE
default   14s

아래와 같은 로그 발생하며 vm이 생성됨

{"level":"DEBUG","time":"2024-09-17T16:16:40.560Z","logger":"controller.nodeclaim.lifecycle","message":"Created virtual machine /subscriptions/356ce9af-1ab0-44d1-bfb6-2295e4f0175c/resourceGroups/MC_karpenter_karpenter_koreacentral/providers/Microsoft.Compute/virtualMachines/aks-general-purpose-j7m94","commit":"46b4276","nodeclaim":"general-purpose-j7m94"}
{"level":"DEBUG","time":"2024-09-17T16:16:40.560Z","logger":"controller.nodeclaim.lifecycle","message":"Creating virtual machine AKS identifying extension for aks-general-purpose-j7m94","commit":"46b4276","nodeclaim":"general-purpose-j7m94"}

karpenter로 인해 추가된 가상머신

5. 스케일링 테스트

cpu requests 가 1인 pod를 생성해서 스케일링 테스트

$ cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 0
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      terminationGracePeriodSeconds: 0
      containers:
        - name: inflate
          image: mcr.microsoft.com/oss/kubernetes/pause:3.6
          resources:
            requests:
              cpu: 1
EOF

$ kubectl scale deployment inflate --replicas 2

# 로그 확인 명령
$ kubectl logs -f -n "${KARPENTER_NAMESPACE}" -l app.kubernetes.io/name=karpenter -c controller

aks 상에 추가된 노드 확인

오류해결

subscription ID not set 오류로 karpenter pod crash 발생

values 파일의 34번째 줄에 구독 id 추가

AKSNodeClass에 이미지 버전 명시하지 않으면 아래의 로그가 계속해서 발생하고, vm만 생성되며 이를 감지하지 못해 클러스터에 포함되지 않는 문제 발생

apiVersion: karpenter.azure.com/v1alpha2
kind: AKSNodeClass
metadata:
  name: default
  annotations:
    kubernetes.io/description: "General purpose AKSNodeClass for running Ubuntu2204 nodes"
spec:
  imageFamily: Ubuntu2204
  imageVersion: 202408.21.0

{"level":"DEBUG","time":"2024-09-17T16:33:38.359Z","logger":"controller.disruption","message":"waiting on cluster sync","commit":"46b4276"} {"level":"DEBUG","time":"2024-09-17T16:33:39.360Z","logger":"controller.disruption","message":"waiting on cluster sync","commit":"46b4276"}

참고문서

github https://github.com/Azure/karpenter-provider-azure

Azure docs 노드 자동 프로비전(미리 보기) - Azure Kubernetes Service

karpenter docs Getting Started with Karpenter

Naver cloud 대학생 모임 후기 (3) 번외) 리소스 정리 및 주의 사항

sunchan — Sun, 1 Sep 2024 00:53:54 +0900

네이버 클라우드 콘솔 환경에서 초심자가 실수하기 쉬운 부분과, 주의 사항 등을 정리해보고자 합니다.

클라우드 서비스를 처음 다루시는 분들이 작업 도중 주로 막히는 부분이 있습니다.

리소스 정리

콘솔에서 리소스를 만드는 것은 너무나도 간단합니다.
리소스 삭제 시에는 구성 시의 순서(종속성)등을 고려하여 차근차근 삭제해야 합니다.

서비스 활용

단순히 서비스를 띄워보기만 하는 것은 의미가 없습니다. 직접 사용해봐야 원리가 오래 기억됩니다.
CSP사마다 비슷하지만 조금 씩 다른 서비스 접속 방법 등이 있습니다.

1. 리소스 정리

생성한 리소스를 정리하려고하면 매번 이런 오류메시지들을 만나게 됩니다.

Naver cloud 대학생 모임 후기 (ncloud에서 표준 아키텍쳐를 구상 및 구축해보자!)

Naver cloud 대학생 모임 후기 (2) - ncloud NKS 구축 해보기

위 링크를 따라 리소스를 생성하셨다면 리소스들을 모두 지워주셔야 추가 비용이 발생하지 않습니다.

저 또한 매번 헷갈리는 부분인 리소스 삭제 순서에 대해 정리해보겠습니다.

1. NAT Gateway / Route Table 설정 삭제

NAT Gateway를 삭제할 때는 Route Table 설정을 먼저 삭제해야하며, 공인 ip도 반드시 반납해주셔야합니다.

2. LB (LoadBalancer) / Tg (Target Group)삭제

LoadBalancer를 삭제하기 위해서는 기존에 연결해둔 Target Group을 삭제해야합니다.

3. Subnet / VPC 삭제

위 리소스들을 모두 제거한 후 Subnet과 VPC를 삭제해줍니다.

4. 잔여 리소스

생성했던 서버는 반드시 반납 버튼을 눌러 제거해주시고, 사용한 공인 ip를 반납했는지 다시 한 번 확인하시길 바랍니다.

모든 리소스를 정리하고도 불안하실 때에는 회원 탈퇴창을 확인해보시면 아직 남아있는 리소스가 있는지 확인할 수 있습니다.(실제로 탈퇴하시면 안됩니다.)

2. 서비스 사용

네이버 클라우드에서 생성한 서버에 접속하는 방법입니다.

다른 클라우드 서비스와 다르게 키 파일 만으로는 서버에 접속할 수 없습니다.

서버 생성 탭

서버 관리 및 설정 변경 > 관리자 비밀번호 확인 > 서버 생성시 등록한 키파일 업로드

위 순서대로 접근하시면 아래 관리자 비밀번호를 알아낼 수 있습니다.

관리자 패스워드와 키 파일을 동시에 인증하여 서버에 접속된 화면과, Mysql DB에 접속한 화면입니다.

서버 접속 방법

ssh -i <키파일 경로> root@<관리자 비밀번호>

DB 접속 방법

mysql -p -u <생성한 관리자명> -h <DB 주소>

[NCUC] 제 3회 NCUC 연사자 참여 후기 (Naver Cloud User Community)

sunchan — Sun, 1 Sep 2024 00:29:23 +0900

역삼역 Ncloud Space에서 진행된 제 3회 네이버 클라우드 유저 커뮤니티 밋업에 감사하게도 연사자로 참여하게 되었습니다.

발표 내용은 네이버 클라우드 마스터로 활동중이신 서태호님의 스터디 내용을 기반으로 자료를 구성했습니다.

이번에 발표한 자료는 Naver Cloud 대학생 모임 후기 시리즈의 일부로, 다음과 같은 주제를 다뤘습니다:

Naver cloud 대학생 모임 후기 (1) ncloud에서 표준 아키텍쳐를 구상 및 구축해보자

Naver cloud 대학생 모임 후기 (2) - ncloud NKS 구축 해보기

다른 CSP사의 클라우드 서비스를 처음 접했을 때의 경험을 되새기며, 네이버 클라우드를 처음 사용해보는 분들에게 도움이 될 만한 자료를 만들어보자는 생각으로 접근했습니다.

밋업에 많은 현직자 분들이 참석해 네트워킹할 수 있는 자리가 마련되었고, 네이버 클라우드에서 다양한 굿즈까지 준비해 주셔서 참석자분들이 더욱 만족하셨을 것 같습니다.

참고로, 기존의 NCUC 판교 소모임은 4회차부터 '수도권 남부 소모임'이라는 이름으로 더 많은 지역의 참여자분들과 소통할 수 있도록 진행된다고 합니다.

이미 훌륭한 분들이 많이 참여하고 계시고, 기회와 즐거움이 넘치는 모임이지만, 더 많은 분들이 함께 네트워킹할 수 있는 자리가 되었으면 좋겠습니다.

이번 행사에서 많은 것을 배울 수 있었고, 현직자의 시각에서 더욱 많은 인사이트를 얻고 싶다는 생각이 들었습니다. 앞으로도 꼭 다시 참여하고 싶은 소중한 경험이었습니다. 행사 준비와 진행을 도와주신 운영진 분들께 감사드립니다.

Naver cloud 대학생 모임 후기 (2) - ncloud NKS 구축 해보기 2024.08.18

sunchan — Tue, 27 Aug 2024 23:57:29 +0900

https://sunchan.tistory.com/4

Naver cloud 대학생 모임 후기 (ncloud에서 표준 아키텍쳐를 구상 및 구축해보자!) 2024.08.10

클라우드 엔지니어 취업 준비를 함에 있어 평소 많은 정보를 얻고 있었던 cloud 전문가 카페에서 감사하게도 클라우드를 공부하는 대학생을 위한 모임을 개설해주셔서 참석하게 되었습니다. 장

sunchan.tistory.com

이전 글에 이어서 이번에는 멀티zone의 ncloud 아키텍처를 구성해봤습니다.

NKS, DB 등을 제외한 리소스 들은 이전 글에 포스팅한 방식으로 생성했습니다.(이름은 상이하지만 생성 방식은 같습니다)

이번 글에서는 NKS, DB까지 아키텍처를 완성하고, 리소스 정리까지 해보도록 하겠습니다.

최종적으로 완성된 아키텍처

1. NAT gateway 생성

쿠버네티스의 아웃바운트 트래픽을 위한 nat를 생성해줍니다.

기존에 생성한 VPC와 NAT 전용 서브넷을 연결하여 NAT Gateway를 생성해줍니다.

2. Route Table 수정

쿠버네티스에서 NAT Gateway로 아웃바운드 트래픽을 전송하도록 Route Table의 목적지를 설정해줍니다.

3. NKS(ncloud kubernetes service) 생성

ncloud의 kubernetes 생성을 위해서는 VPC, NAT Gateway와 kubernetes를 배치할 서브넷, LB public/private까지 3개의 서브넷이 있어야 다음으로 넘어갈 수 있습니다.

초기에 서브넷 생성 시 서브넷의 용도를 잘 설정해주어야 합니다.

kubernetes cluster의 노드풀을 생성해줍니다. 서버 타입과 노드 수 등을 선택한 후 등록해줍니다.

4. 데이터 베이스 생성

Cloud DB for MySQL을 이용하여 데이터베이스 계층을 구성해주었습니다.

DB의 버전 등을 선택해주고 클릭 한 번으로 간단히 멀티 zone의 stanby DB server 까지 구축할 수 있었습니다.

서브넷은 DB를 위해 미리 생성한 Private 서브넷을 선택해주었습니다.

DB 접속에 필요한 USER_ID, 암호 등의 정보를 입력해줍니다.

간단한 테스트만을 위해 HOST는 모든 IP를 열어주었습니다.

최종적으로 완성된 아키텍처입니다. 기본적이지만 탄탄한 3tier 아키텍처를 구축해 고가용성을 유지,

DB는 active / stanby를 구성해 데이터 손실을 방지했습니다.

쿠버네티스 사용

https://cli.ncloud-docs.com/docs/guide-clichange

CLI 다운로드

cli.ncloud-docs.com

생성한 server를 명령용으로 사용했습니다.

네이버 클라우드 cli
- 네이버 클라우드의 cli를 설치하여 계정 인증 등의 작업을 명령서버에서 진행할 수 있습니다.
- 위 링크에서 다운받은 파일을 직접 실행하거나 아래의 코드처럼 리눅스 명령줄로 다운 받을 수 있습니다.

# cli 파일 다운로드
wget https://www.ncloud.com/api/support/download/files/cli/CLI_1.1.20_20240620.zip

# 압축 해제
unzip CLI_1.1.20_20240620.zip

# 디렉토리 접근
cd CLI_1.1.20_20240620/
cd cli_linux/

# bin 디렉토리의 파일은 명령어로 사용가능합니다(파일명을 입력 시 내부의 명령을 실행)
cp ncloud /usr/bin/

# 정상 설치 확인
ncloud help

ncp-iam-authenticator
- IAM 기능을 활용하기 위해 설치해줍니다.

# ncp-iam-authenticator 설치
curl -o ncp-iam-authenticator -L https://github.com/NaverCloudPlatform/ncp-iam-authenticator/releases/latest/download/ncp-iam-authenticator_linux_amd64

# 실행 권한 추가
chmod +x ./ncp-iam-authenticator

# cli 처럼 bin 디렉토리로 파일을 배치하고 환경 변수까지 지정
mkdir -p $HOME/bin && cp ./ncp-iam-authenticator $HOME/bin/ncp-iam-authenticator && export PATH=$PATH:$HOME/bin

# 추후 재로그인 시에도 환경변수 유지
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bash_profile

# 정상 설치 확인
ncp-iam-authenticator help

# kr 리전의 클러스터 uuid를 복사해서 입력해주어 인증 정보를 생성합니다.
ncp-iam-authenticator create-kubeconfig --region KR --clusterUuid  <clusterUuid> --output kubeconfig.yaml

인증 정보를 등록하기 위해 ncloud configure 명령으로 Access Key / Secret Access Key를 등록해줍니다.

인증 키는 계정관리에서 발급받으실 수 있습니다.

kubectl 설치
- 명령서버에서 kubectl 명령을 사용하기 위해 설치해줍니다.

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

이제 명령서버의 준비가 모두 끝났습니다.

2048 게임의 이미지를 사용하여 테스트 해봤습니다.

2048 deployment / service 생성 yaml 파일

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-2048
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: app-2048
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app-2048
    spec:
      containers:
      - name: app-2048
        image: alexwhen/docker-2048
        ports:
        - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: deployment-2048
spec:
  selector:
    app.kubernetes.io/name: app-2048
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: LoadBalancer

LoadBalancer를 type으로 지정해 외부에서 접근 가능하도록 했습니다.

Naver cloud 대학생 모임 후기 (ncloud에서 표준 아키텍쳐를 구상 및 구축해보자!) 2024.08.10

sunchan — Thu, 15 Aug 2024 14:46:39 +0900

클라우드 엔지니어 취업 준비를 함에 있어 평소 많은 정보를 얻고 있었던 cloud 전문가 카페에서 감사하게도 클라우드를 공부하는 대학생을 위한 모임을 개설해주셔서 참석하게 되었습니다.

장소 : 역삼역 한국타이어 ncp 교육장
참여 목적 : 클라우드 엔지니어 취업을 위한 공부 / 같은 목적을 가지고 취업준비 하시는 분들과의 정보 공유, 네트워킹

스터디 진행 사항

https://brunch.co.kr/@topasvga/3806

1. 네이버 클라우드 네트워크 -시작-2024-07

왜 오셨을까요? 설명중 해당 부분에 대해 더 설명 드리려 문의 드립니다. 이 자리에서 이해하고 가시기 바랍니다 저 역시 집에가면 다시 안보게 됩니다~ 목표 서비스 > 네트워크 > 서버 > 애플리

brunch.co.kr

먼저 취업을 위한 운영자분의 경험과 지인분들의 의견, 기업 JD 등을 자세하게 설명해주셔서 취업에 관한 생각을 한 번 정리할 수 있었습니다.

현재 클라우드 엔지니어는 3년차 이상의 경력 혹은 그에 준하는 인력을 원한다.
채용자의 입장에서 회사보다 큰 트래픽, 규모 등의 경험자를 원하기 때문에 그에 맞는 회사에서 경력을 쌓는 것이 중요하다.
벤더사의 파트너사의 경우 자격증은 필수적으로 취득하는것이 좋다.

이 외에도 클라우드와 연관된 각 분야의 전문가들에 대한 로드맵 등 커리어 패스에 도움되는 이야기를 많이 해주셨습니다.

학습 진행 사항

이론을 먼저 학습한 후 콘솔에서 실습하는 방식으로 진행되었고, 6시간동안 진행되었습니다.

네이버 클라우드로 가상의 표준 아키텍쳐를 구성해보자

클라우드 아키텍쳐 구성 전 회사의 상황에 맞는 네트워크 설계 및 구축을 탄탄히 해 두어야 한다.

상황 예시

k8s 환경에서 500개의 pod를 올리기 위한 환경을 구축 한다면 네트워크를 어떻게 설정할 것인가.

10.0.0.0/20의 vpc를 생성한다.
CIDR를 23으로 할당하여 두개의 서브넷을 사용, 약 천개이상의 ip를 할당한다.

필요한 pod 수의 두배를 할당하는 이유는 k8s 서버에서 무중단 배포를 위한 Blue-Green Deployment를 적용한다면 pod는 구버전 + 신버전이 동시에 실행되어 배포할 pod의 ip가 2배 필요하다.

네트워크 계획

vpc : 10.0.0.0/20

zone	subnet	name
KR-1	10.0.0.0/23	pri-was1
	10.0.2.0/24	pub-web1
	10.0.3.0/24	pri-db1
	10.0.4.0/24	pub-nat1
	10.0.5.0/24	pub-lb1
	10.0.6.0/24	pub-lb1
	10.0.7.0/24	예비
KR-2	10.0.8.0/23	pri-was2
	10.0.10.0/24	pub-web2
	10.0.11.0/24	pri-db2
	10.0.12.0/24	pub-nat2
	10.0.13.0/24	pub-lb2
	10.0.14.0/24	pub-lb2
	10.0.15.0/24	예비

1회차 수업 내용까지 아키텍쳐를 직접 그려보았습니다.

콘솔 작업

1. vpc 생성

먼저 클라우드 환경에서 가상으로 사용할 vpc를 생성해줍니다.

ip 주소범위는 10.0.0.0/20 으로 설정하였습니다.

2. subnet 생성

기존에 생성한 vpc를 기반으로 각 서브넷을 용도와 조건에 맞게 생성해줍니다.
위의 상황 예시에 따라 cidr를 23으로 주었지만 이번 학습에서는 아직 k8s를 구축하지 않았습니다.
ncloud 는 lb를 위한 서브넷을 별도로 만들어주어야합니다.

3. private subnet 에 위치한 서버가 외부와 통신하기 위한 nat gateway 생성.

4. route table 생성 및 설정

연관된 subnet 간의 연결을 위해 route table을 생성해줍니다.

이 때 DB는 외부와의 통신을 막기위해 연관 subnet을 확인하고, local로 연결된 route table을 연결해줍니다.

5. 서버 생성

접속하여 확인할 서버를 생성합니다.

서버 이미지 설정 사항

이미지 타입 : Rocky linux
서버 이미지 이름 : Rocky Linux 8.6

subnet은 서버를 설치하기 위한 private subnet으로 지정

서버 설정은 비용을 최소화하기 위해 서버타입을 가장 작은 것으로 설정합니다.

ncloud는 network interface에서 추가버튼을 반드시 눌러줘야 적용됩니다.

웹 서버를 띄울 init script를 미리 생성해둘 수 있습니다.

추후 서버 환경에 접근하기 위한 인증키를 생성하거나 보유하고 있는 인증키 를 선택할 수 있습니다.

오늘 학습에서는 다중 존을 사용하기 위해서 같은 사양의 서버를 kr1, 2 두개의 zone에 생성해줍니다.

기존에 생성한 server image 기능을 사용하면 서버를 원하는대로 여러대 생성할 수 있습니다.

6. Loadbalancer 생성

접속을 분산시키기 위한 loadbalancer를 생성합니다.

먼저 로드 밸런서가 네트워크 트래픽을 분산할 대상 서버 그룹인 target group을 생성합니다.

세부 설정은 기존에 생성한 vpc에 80/tcp로 지정해주었습니다.

target group에 포함시킬 대상을 target으로 추가해줍니다.

vpc와 subnet을 선택하여 로드밸런서를 생성합니다.

생성 시 zone을 모두 선택하여 생성이 가능합니다.

생성된 loadbalancer의 dns로 접속 시 initscript로 만들어진 웹서버를 확인할 수 있습니다.

1회차 수업 내용까지 아키텍쳐를 직접 그려보았습니다.

실습 관련 내용 뿐만 아니라 현직자의 입장에서 들려주시는 직무관련 이야기를 들을 수 있는 아주 좋은 기회였으며, 6시간동안 진행되었지만 시간이 부족했고, 앞으로의 일정 전에 예습을 충분히 해야겠다는 생각이 들었습니다.