DB Link 는 데이터베이스에서 네트워크상의 다른 데이터베이스에 접속하기 위하여 접속 설정을 정의하는 객체이다. 분산된 데이터를 다루기 편리하지만 실시간 트랜잭션이 많은 시스템에서는 장애가 발생할 수 있다. (Link를 통해 접속된 데이터베이스의 세션과 Lock 이 증가할 수 있으므로) Long Type, CLOB, BLOB 타입을 Link를 통해 DML 작업할 경우 오류가 발생할 가능성이 있다.

Tibero to Tibero

Tibero to Tibero는 접속하려고 하는 Tibero의 IP 주소, 포트 번호, DB Name 내용을 확인하고 DB Link를 설정할 Tibero의 네트워크 설정 파일 (tbdsn.tbr) 에 설정한다.

# DB Link를 생성할 Tibero 의 정보

tibero=(
    (INSTANCE=(HOST=localhost)
              (PORT=6829)
              (DB_NAME=tibero)
    )
)

# 접속할 Tibero 의 정보

tibero_a=(
    (INSTANCE=(HOST=Node IP)
              (PORT=설정할 PORT)
              (DB_NAME=tibero)
    )
)

대상 서버 연결 확인

접속하려는 Tibero(tibero_a)로 접속한 것을 확인한다.

tbsql sys/tibero@tibero_a

DB Link Object 생성

DB Link 를 생성할 계정의 sql 에 접속하여 DB Link Object를 생성한다.

create database link <DB LINK 명> connect to <접속 사용자 ID> identified by <접속 패스워드> using <접속에 사용할 alias>;

• DB LINK 명 : 생성할 DB Link Object 이름
• 접속 사용자 ID : 대상 DB 서버에 접속할 사용자 이름
• 접속 패스워드 : 대상 DB 서버에 접속할 패스워드
• 접속에 사용할 alias : Source DB의 tbdsn.tbr에 설정된 alias 이름

DB Link 생성 예시는 다음과 같다.

create database link T7Link connect to TEST_DB identified by 'TEST_DB' using 'tibero_a';

DB Link를 생성하기 위해서는 CREATE DATABASE LINK 또는 CREATE PUBLIC DATABASE LINK 권한이 필요하다.

SQL 실행

생성이 완료되면 < @Link명 > 을 붙여 사용한다.

select * from dual@T7Link

사용중인 Link 의 이름으로 알 수 없는 경우 다음과 같이 View 를 조회한다.

select * from user_db_links;

확인할 수 있는 이유

컨테이너는 linux의 cgroup 과 namespace 기능을 통해 격리된 환경이기 때문이다. cgroup은 프로세스 그룹별로 시스템 리소스를 제한하고 모니터링할 수 있게 한다. cgroup은 컨테이너별로 그룹의 리소스 사용량과 제한 정보를 파일 시스템 형태로 노출한다. 일반적으로 sys/fs/cgroup 디렉토리에서 확인할 수 있다 (컨테이너 안에서도).

cgroup 은 cgroup v1 과 cgroup v2 가 사용되고 있다. 이에 따라 경로와 파일 명칭이 다를 수 있다.

• cgroup v1 : /sys/fs/cgroup/memory/memory.usage_in_bytes
• cgroup v2 : /sys/fs/cgroup/memory.current

cgroup v1과 cgroup v2란? cgroup 은 버전에 따라 시스템 자원을 관리하는 방식과 구조에 차이가 있다. cgroup v1 은 각 자원 컨트롤러 (메모리, CPU) 등이 별도의 계층 구조를 가져 독립적으로 운영된다. 유연성을 제공하지만, 여러 자원을 동시에 관리할 때는 복잡성이 증가할 수 있다. cgroup v2는 모든 자원 컨트롤러가 하나의 계층 구조를 공유한다. 컨트롤러 간의 일관성이 보장되고 관리가 용이하지만, 호환성의 이슈가 있을 수 있다. 어떤 버전의 cgroup 을 사용하는지는, mount | grep cgroup2 을 통해 확인할 수 있다. 출력에 cgroup2가 있으면 cgroup v2를 사용하는 것이다.

컨테이너 런타임은 이 cgroup을 활용하여 컨테이너의 리소스 사용을 관리하므로, 해당 방법을 통해 컨테이너의 리소스를 정확하게 추적할 수 있다.

확인 방법

1. 컨테이너 안에서 확인 컨테이너에 안에 접속하여 /sys/fs/cgroup/memory 폴더의 memory.usage_in_bytes 파일을 확인한다.

# cgroup v1
cat /sys/fs/cgroup/memory/memory.usage_in_bytes

# cgroup v2
cat /sys/fs/cgroup/memory.current

2. 접속한 node에서 확인

1. kubernetes pod 혹은 container 가 위치한 node에 접속한다.
2. 컨테이너의 PID (Process ID) 를 확인한다. (docker 의 경우 docker inspect --format '{{.State.Pid}}' <컨테이너 ID> , containerd를 사용하는 경우 crictl inspect --output go-template --template '{{.info.pid}}' <컨테이너 ID>)
   • kubernetes의 경우 kubectl describe <pod> -n <namespace> 명령어를 사용하여 사용하는 컨테이너의 ID를 확인할 수 있다.
3. 컨테이너의 PID가 확인되었으면 해당 process 의 경로에서 PID의 cgroup을 찾는다. cat /proc/<PID>/cgroup
   • cgroup v1 : 각 컨트롤러 별로 경로가 표시된다.
   • cgroup v2 : 단일 계층 구조이므로 0::/ 형태로 경로가 표시된다.

     cat /proc/<PID>/cgroup # cgroup v1의 경우
     11:memory:/user.slice
     10:cpu,cpuacct:/user.slice
     9:cpuset:/
     8:blkio:/user.slice
     7:net_cls,net_prio:/
     6:freezer:/
     5:devices:/user.slice
     4:hugetlb:/
     3:perf_event:/
     2:pids:/user.slice
     1:name=systemd:/user.slice/user-1000.slice/session-2.scope
     

cat /proc/87357/cgroup # cgroup v2의 경우 0::/user.slice/user-1000.slice/session-2.scope

``` 4. /sys/fs/cgroup 에서 위에서 확인한 경로로 이동한다. 경로를 그대로 /sys/fs/cgroup 아래에 결합하여 사용한다. ( e.g. /sys/fs/cgroup/user.slice/user-1000.slice/session-2.scope 5. memory.usage 등의 파일을 사용하여 사용중인 메모리를 확인한다.

• cgroup v1 의 경우 : /sys/fs/cgroup/memory/<cgroup 경로>/memory.usage_in_bytes
• cgroup v2 의 경우 : /sys/fs/cgroup/<cgroup 경로>/memory.current

메모리 뿐만 아니라 CPU 사용량 (cpuacct.usage 혹은 cpu.stat) 역시 확인할 수 있다. 각 메모리 사용량 파일의 값은 바이트(Byte) 단위이다.

cgroup v1에서는 cpuacct.usage 파일에서 나노초 단위로 확인한다. cgroup v2 에서는 cpu.stat 파일에서 usage_usec 값을 통해 마이크로초 단위로 확인한다.

개요

Python에서 형 변환은 다양한 데이터 유형 간에 값을 변환하는 과정이다. 암시적 형변환과 명시적 형변환 두 가지 방식이 있다.

암시적 형 변환

Python 이 자동으로 데이터 유형을 변환한다. 이는 보통 데이터 손실이 없을 때 사용한다.

num_int = 123
num_float = 1.23

# num_int는 자동으로 float로 변환됨
result = num_int + num_float
print("Result:", result)
print("Type of result:", type(result))

명시적 형 변환

프로그래머가 직접 데이터 유형을 변환한다. Python은 다양한 형 변환 함수를 제공한다.

주요 형 변환 함수

• int(): 다른 데이터 타입을 정수형으로 변환
• float(): 다른 데이터 타입을 실수형으로 변환
• str(): 다른 데이터 타입을 문자열로 변환
• list(): 다른 데이터 타입을 리스트로 변환
• tuple(): 다른 데이터 타입을 튜플로 변환
• set(): 다른 데이터 타입을 집합으로 변환
• dict(): 키-값 쌍의 순차열을 사전으로 변환

num_str = "456"
num_int = int(num_str)
print("Converted to int:", num_int)
print("Type of num_int:", type(num_int))

float_str = "3.14"
num_float = float(float_str)
print("Converted to float:", num_float)
print("Type of num_float:", type(num_float))

# List to tuple
list_example = [1, 2, 3]
tuple_example = tuple(list_example)
print("Converted to tuple:", tuple_example)
print("Type of tuple_example:", type(tuple_example))

# Tuple to list
tuple_example = (1, 2, 3)
list_example = list(tuple_example)
print("Converted to list:", list_example)
print("Type of list_example:", type(list_example))

회고

python 재활 중이라는 마음가짐으로 하면 좋을 것 같다.

개요

#! /bin/bash 를 가장 맨 처음에 넣어 /bin/bash 쉘을 사용한다는 것을 알려준다.

변수를 선언할 때는 = 기호를 사용하며, 변수 이름과 = 사이에 공백이 없어야 한다.

변수를 사용할 때는 $ 기호를 앞에 붙여야 한다.

환경 변수를 설정하면 시스템 전체에서 변수를 사용할 수 있다. export 명령어를 사용해서 설정한다. env 명령어를 사용하면 환경 변수의 목록을 볼 수 있다.

문자열은 작은따옴표 혹은 큰따옴표를 이용해서 표현한다.

expr 명령어를 사용하거나 (( )) 구문을 사용하여 간단한 산술 연산을 수행할 수 있다.

배열은 이와 같이 설정한다. my_array=(array1, array2, array3 특정 요소로 접근하기 위해서는 ${array[index]} 구문을 사용한다.

비교 표현식

• -gt : greater. 크다
• -ge: greater or equal. 크거나 같다
• -eq: equal. 같다
• -ne: not equal. 같지 않다
• -le: little or equal. 작거나 같다
• -lt: little. 같다

조건문

if문

if [ $a -gt $b ]; then
    echo "$a is greater than $b"
elif [ $a -eq $b ]; then
    echo "$a is equal to $b"
else
    echo "$a is less than $b"
fi

case문

case $input in
    start)
        echo "Starting"
        ;;
    stop)
        echo "Stopping"
        ;;
    *)
        echo "Unknown command"
        ;;
esac

반복문

for문

for i in {1..5}; do
    echo "Welcome $i times"
done

while문 - executes the commands inside it as long as the condition is true

while [ $i -le 5 ]; do
    echo "Welcome $i times"
    i=$((i + 1))
done

until문 - executing the commands inside it until the condition becomes true

until [ $i -gt 5 ]; do
    echo "Welcome $i times"
    i=$((i + 1))
done

함수

쉘스크립트에서 반복되는 작업을 모듈화하고 코드의 재사용성을 높임

함수 정의

function_name() {
    # 함수의 내용
}

or

function function_name {
    # 함수의 내용
}

함수 호출 - 함수를 호출하려면 함수 이름을 사용하고, 필요한 경우 인자를 전달

function_name arg1 arg2

위치 매개변수와 특수 변수

함수 내에서, 인자는 위치 매개변수 ($1, $2, ...)를 통해 접근할 수 있다. $0은 스크립트의 이름을 나타내며, $#는 전달된 인자의 수를 나타낸다.

greet() {
    echo "Hello, $1!"
}

greet "World"

[root@localhost ~]# ./greet.sh
Hello, World!

greet 함수는 하나의 인자를 받아 인사말을 출력한다. $1은 함수에 전달된 첫 번째 인자를 나타낸다.

greet() {
        echo "Hello, $1! Nice to meet you, $3, $2!"
}

greet "World" "Min" "Sin"

[root@localhost ~]# ./greet.sh
Hello, World! Nice to meet you, Sin, Min!

쓸만한 명령어들 정리

• 삭제할 때
  • ls *.파일명 으로 실행하고 rm !$로 ls로 불러온 다른 파일들 삭제하기
• Crtl+R로 증분검색 해서 편하게 불러오기
• 명령어에서 오타난 부분 바꿀때는 그냥 ^오타^수정함으로 하면됨

[root@localhost ~]# lsa
-bash: lsa: command not found
[root@localhost ~]# ^lsa^ls
ls
BookNetwork_GKE  go                                            infra          minikube-linux-amd64
anaconda-ks.cfg  google-cloud-cli-461.0.0-linux-x86_64.tar.gz  kubectl        practice
cri-dockerd      google-cloud-sdk                              linux-amd64    shell_study
db.pem           helm-v3.11.1-linux-amd64.tar.gz               liveness.yaml

• 두 디렉터리를 오며가며 반복할 때는 cd - 를 사용

회고

피곤하당

개요

Python의 lambda 함수는 간단한 익명 함수(anonymous function)를 작성할 때 사용된다. lambda 함수는 단일 표현식을 가진 함수로, 일반적인 함수 정의보다 더 간결하게 작성할 수 있다.

lambda 인자1, 인자2, ... : 표현식

• lambda 키워드로 시작한다.
• 인자 리스트가 뒤따른다.
• 콜론 : 뒤에 표현식이 온다. 이 표현식의 결과가 함수의 반환값이 된다.

1. 기본 사용법

   add = lambda x, y: x + y
   print(add(2, 3))  # 출력: 5

2. 리스트에서 사용

   add = lambda x, y: x + y
   print(add(2, 3))  # 출력: 5

3. 고차 함수에서 사용

   def apply_function(f, value):
    return f(value)
   

result = apply_function(lambda x: x * 2, 5) print(result) # 출력: 10

4. **맵(map)과 필터(filter) 함수에서 사용**
```python
# map 사용 예제
numbers = [1, 2, 3, 4]
squared = map(lambda x: x ** 2, numbers)
print(list(squared))  # 출력: [1, 4, 9, 16]

# filter 사용 예제
even_numbers = filter(lambda x: x % 2 == 0, numbers)
print(list(even_numbers))  # 출력: [2, 4]

5. 리스트 컴프리헨션에서 조건으로 사용

   numbers = [1, 2, 3, 4, 5, 6]
   even_squares = [x ** 2 for x in numbers if (lambda x: x % 2 == 0)(x)]
   print(even_squares)  # 출력: [4, 16, 36]

6. 정렬의 키 함수로 사용

   points = [(1, 2), (3, 3), (1, -1)]
   points_sorted_by_y = sorted(points, key=lambda point: point[1])
   print(points_sorted_by_y)  # 출력: [(1, -1), (1, 2), (3, 3)]

7. 데이터 처리 파이프라인

   data = [1, 2, 3, 4, 5]
   processed_data = map(lambda x: x * 2, filter(lambda x: x % 2 == 0, data))
   print(list(processed_data))  # 출력: [4, 8]

회고

평범한 날이 계속됐으면 좋겠습니다...

그물을 뜻하는 Net와 Work의 합성어 분산되어 있는 컴퓨터를 통신망으로 연결한 것

네트워크 기본 개념

컴퓨터는 하드웨어 / 소프트웨어로 나뉨

소프트웨어는 OS 나 응용 프로그램 등으로 구성되어 있음 이런 네트워크를 이해하기 위해선 프로세스를 이해해야 함

운영체제 역할을 크게 두 가지로 구분하면

1. 하드웨어 자원의 할당
2. 프로세스의 관리

프로세스: 운영체제로부터 자원을 할당 받는 작업의 단위 스레드: 할당 받은 자원을 실제로 이용하는 실행의 단위

프로세스 내에는 여러 스레드가 존재할 수 있다. 프로세스는 완전히 독립된 실행 객체임. 독립되어 있는 만큼 다른 프로세스의 영향을 받지 않지만, 별도의 방법 없이는 서로 통신이 불가능하다.

프로세스간 통신: IPC, 뮤텍스, 세마포어 등 메모리 공유 방법엔 여러가지가 있다.

네트워크에 기반을 둔 소켓

소켓: 두 개의 프로그램 간 양방향 통신의 하나의 엔드 포인트

소켓은 프로세스와 시스템의 가장 기초적인 부분. 프로세스 간의 통신을 가능하게 한다.

데이터 교환을 위해 양쪽 프로세스에서 임의의 포트를 정하고, 해당 포트간의 연결을 통해 데이터를 주고받는다.

이러한 소켓 통신은 네트워크의 기본이 된다.

• 서버와 클라이언트 서버: 서비스를 제공하는 컴퓨터 클라이언트: 서비스를 사용하는 컴퓨터

서버는 특정 포트가 바인딩된 소켓을 하나 가지고 있다. 이를 통해 listen() 을 하며 클라이언트의 연결을 기다린다.

클라이언트는 서버의 호스트이름과 리스닝하고 있는 포트를 통해 서버와의 연결을 시도한다. 또한 서버에 연결되어 있는 동안 서버에게 자신을 식별시키기 위해 로컬 포트에 바인딩이 된다. 이러한 포트 바인딩 작업은 OS에 의해 이루어진다.

클라이언트가 연결 요청을 하면 서버가 accept()을 한다. 서버는 동일한 로컬 포트에 바인딩된 새로운 소켓을 연다. 예를 들어 80번으로 웹 서버가 listen()을 하고 있으면, 새로운 클라이언트가 연결요청할 때 그 클라이언트와 통신하기 위해 새로운 포트로 소켓을 연다.

웹서버는 80번으로 계속 리스닝을 하고 있어야 하기 때문에 클라이언트와의 연결을 별도의 포트를 통해 바인딩 하는 것이다. 동시에 80번 포트는 지속적으로 연결 요청을 받는데 사용한다.

TCP / IP

초창기, 네트워크 장비는 서로 통일이 안 되어 호환이 되지 않았다. 이러한 장비들을 통일시키기 위해 네트워크를 7계층으로 나누어 통일시켰다 (OSI 7계층).

이러한 7계층의 흐름 (어떤 헤더가 붙고 떨어지는지) 등을 이해하는 것이 외우는 것보다 더 중요하다.

HTTP 프로토콜은 HTML과 같은 리소스를 가져올 수 있게 하는 프로토콜이다. 현대 웹에서 이루어지는 모든 데이터 교환의 기초이기도 하고 클라이언트-서버 프로토콜이다.

인터넷에서 클라이언트 서버 간의 연결을 가능하게 하는 통신 규약이 인터넷 프로토콜 스위트 (Internet Protocol Suite) 이다. 이는 인터넷(공용망) 상에서 컴퓨터들이 정보를 주고받는 데 쓰이는 프로토콜의 모음이다.

인터넷 프로토콜 스위트 중에서 TCP/IP가 가장 많이 쓰이므로 TCP/IP 프로토콜 스위트라고 부르기도 한다.

TCP/IP는 패킷 통신 방식의 인터넷 프로토콜인 IP와 전송 조절 프로토콜인 TCP로 이루어져 있다.

IP는 패킷 전달 여부를 보장하지 않는다. 패킷을 보낸 순서와 받는 순서가 다를 수도 있다. 그래서 TCP는 IP 위에서 동작하며 데이터 전달을 보장하고 보낸 순서대로 패킷을 받을 수 있게 하는 시퀀스를 보장하는 역할을 한다.

HTTP/FTP/SMTP 등 TCP를 기반으로 한 많은 어플리케이션 프로토콜이 IP 위에서 동작하므로 TCP/IP라고 부른다.

네트워크는 네트워크 호스트들로 구성이 되어 있다. 이러한 호스트들은 서로 통신이 가능하다. 이러한 통신에 사용하는 프로토콜이 IP이다. IP를 이용한 통신을 하기 위해서, 즉 한 호스트에서 다른 호스트로 패킷을 전달하기 위해서는 호스트의 주소 정보가 필요하다. 주소가 있어야지 패킷을 보낼 목적지를 설정할 수 있기 때문이다. 이런 주소값이 바로 IP Address 이다.

IP Address는 IP 프로토콜을 사용하는 호스트의 주소 정보이다. IP Address가 있어야 패킷이 어느 주소로 갈지 알 수 있다. 예를 들어, 노드들이 직접적으로 연결되어 있지 않은 경우에는 (가장 왼쪽의 노드와 가장 오른쪽의 노드) 다른 노드들을 통해 연결되어 있는 노드들의 정보를 전달해 주어야 한다. 이 경우, 목적지 값이 제대로 설정되어 있어야 해당 호스트에 전달이 가능하다.

TCP

IP는 패킷들의 관계 (순서, 전달 보장) 등을 이해하지는 못한다. IP는 목적지를 제대로 찾아가는 것에 중점을 둔 프로토콜이다. 이에 반해 TCP는 통신하고자 하는 양쪽 단말이 준비가 되었는지를 체크하고, 데이터가 제대로 전송되었는지, 변질되지는 않았는지, 수신자가 얼마나 데이터를 받았고 빠진 부분은 없는지를 점검하는 프로토콜이다.

이런 정보는 TCP 헤더에 담겨있고, TCP 헤더는 SYN, ACK, FIN, RESET 등 신뢰성 보장과 흐름 제어, 혼잡 제어에 관여할 수 있는 요소들로 구성되어 있다.

IP 헤더가 TCP 헤더를 제외한, TCP가 실을 수 있는 데이터 크기를 세그먼트라고 부른다.

TCP는 네트워크 장비 간의 논리적 연결을 성립시키기 위해 3 Way Handshake 라는 방법을 사용한다.

3 Way Handshake는 TCP/IP 프로토콜을 사용해서 통신을 할 때 응용프로그램이 데이터를 전송하기 전 정확한 전송을 보장하기 위해 상대방 컴퓨터가 커넥션을 맺을 수 있는 상태인지 체크하고 연결을 수립하는 과정이다.

1. 클라이언트가 서버에 접속을 요청하는 SYN 패킷을 보낸다. 클라이언트는 SYN 패킷을 보내고 SYN, ACK 응답을 기다린다. SYN sent 상태가 된다.

2. 서버가 클라이언트에게 요청을 수락한다는 뜻의 ACK 패킷을 보낸다. 이 때 SYN Flag가 설정된 패킷을 전송하고 다시 ACK 패킷을 받기를 기다린다. 이 때 SYN Received 상태가 된다.

3. 마지막으로 클라이언트가 서버에 ACK을 보내고 이 이후로 연결이 수립되고 데이터를 보낼 수 있는 상태가 된다. 연결 수립 상태가 된다.

3 Way Handshake 방식은 최초로 TCP 연결을 수립할 때 쓰인다. 4 Way Handshake 방식은 연결을 종료할 때 수행된다.

사설 네트워크와 네트워크 확장

네트워크를 다양한 관점에서 분류할 수 있다. 네트워크를 분류하는 기준은 이용자, 크기 등 다양하다.

서버가 클라이언트와 통신하기 위해서는 IP Address가 필요하다. 인터넷이 보편화되며 IP 주소가 빠르게 고갈되기 시작했다. 지금은 새로운 IPv4 주소의 할당은 중지된 상태이다.

ISP(Internet Service Provider) 회사에서는 일정량의 IP를 보유하고 있고 사용자에게 이를 제공해 준다.

ISP에 인터넷 사용 신청을 하고 공유기를 통해 하나의 공용 IP를 받았다고 가정해 보자. 공유기를 통해 인터넷을 사용하는 다양한 기기들이 있을 것이다. 이러한 공유기가 만들어주는 네트워크를 사설 네트워크라고 한다. 가정 뿐만 아니라 접속할 수 있는 사람이 제한되어 있는 네트워크를 사설 네트워크라고 한다.

사설 네트워크 내에서는 사설 IP가 이용된다. 사설 IP란 인터넷 상에서 사용되는 공용 IP가 아닌 독립된 네트워크 안에서 사용할 수 있는 IP이다.

주소를 가지고 있는 계층은 데이터 링크 계층과 네트워크 계층이다. 2계층은 MAC주소, 3계층은 IP 주소를 사용한다. IP 주소는 32비트 (IPv4), 64비트(IPv6) 이다.

IP 주소는 네트워크 주소와 호스트 주소로 나뉜다. 네트워크 주소는 호스트의 집합이다. 호스트 주소는 하나의 네트워크 내에 존재할 수 있는 호스트를 구분하기 위한 고유의 주소이다.

초기의 IP 주소 체계는 호스트 IP의 갯수에 따라 IP 네트워크의 크기를 다르게 할당할 수 있는 클래스 개념을 도입했었다. (A, B, C, D, E 그거...) 예를 들어 C클래스는 192.0.0.0~223.255.255.0 의 주소를 가지고 있다. 네트워크 주소는 3개의 옥텟, 호스트 주소는 한개의 옥텟이다. 따라서 네트워크 당 256개의 호스트를 가지고 있다. 여기서 네트워크와 브로드캐스트 주소를 빼고 254개의 주소를 사용할 수 있다.

이러한 클래스 기반의 IP 주소 체계는 IP 초창기에는 최적의 선택이었지만 인터넷이 상용화되고 호스트 수가 폭발적으로 증가하며 클래스 기반의 주소 체계는 증가하는 수요를 감당하기에는 부족했다. 또한 IPv4의 가장 큰 문제점은 IP 주소를 낭비하고 있다는 점이다. 예를 들어 A클래스의 경우 1677만 개의 주소를 가지게 되는데 일반적인 기업들이 모두 소비하기에는 너무 큰 숫자이다.

CIDR

이러한 상황을 해결하기 위해 나온 것이 CIDR(Classless Inter-Domain Routing) 이다. CIDR는 기존의 클래스 체계보다 더 유연하다.

CIDR는 슬래시 뒤의 숫자가 네트워크 주소를 의미한다. 즉 /16 이라면 32비트중 16비트를 네트워크 주소로 사용하겠다는 의미이다. 그 뒤의 16비트를 호스트 주소로 사용한다. 그리고 네트워크에서 첫번째 주소와 마지막 주 (192.168.x.x 라면 192.168.0.0 / 192.168.255.255) 는 네트워크 주소와 브로드캐스트 주소이므로 65534개의 IP를 사용할 수 있다. 클라우드라면 추가적으로 DNS나 관리의 용도로 일반적으로 3개의 IP가 더 예약 되어있다.

네트워크 확장

현대는 단일 네트워크 대역이 아닌 인터넷을 통한 광범위 대역의 네트워크를 기반으로 리소스를 사용하고 있다. 이 때 나오는 개념이 LAN, WAN 등의 개념이다.

• LAN(Local Network Area): 근거리 통신망. 라우터나 스위치같은 커넥터를 사용하여 물리적으로 서로 가까운 디바이스들을 연결해준다. 이를 통해 디바이스는 서로 데이터를 교환하고 소규모로 안전하게 통신할 수 있다. 하나의 건물 혹은 캠퍼스, 특정 지역이나 전세계까지 분산된 여러 위치도 포함하므로 이를 확장한 것이 광역 네트워크 (WAN) 이다.

허브로 묶여있는 PC들, 스위치로 묶여있는 PC들의 집합을 일반적으로 세그먼트라고 부른다. 세그먼트 범위 내의 컴퓨터들은 패킷을 교환할 필요 없이 직접 데이터를 송수신할 수 있다. 이 케이블 분배기의 역할을 하는 것이 허브와 스위치다. 허브와 스위치는 LAN 수준에서 사용한다. 외부 네트워크와 통신을 하게 되려면 IP가 필요하다. 허브와 스위치는 MAC 주소를 읽을 수 있을 뿐, IP 주소를 읽지를 못한다.

따라서 외부 네트워크, 즉 인터넷이 형성되려면 라우터가 필요하다. 라우터는 IP주소를 바탕으로 한 네트워크에서 다른 네트워크로 데이터를 라우팅하거나 전달할 때 사용하는 장치다. 라우터로 데이터 패킷이 수신되면 첫 번째로 자신이 갖고 있는 네트워크 용인지, 외부 네트워크 용인지를 판단하여 IP 주소를 검사한다.

전자의 경우에는 받고 후자의 경우에는 다른 라우터로 트래픽을 보낸다. 이처럼 라우터 간의 패킷 교환이 이루어지며 네트워크 대역이 점점 확장된다.

NAT (Network Address Translation)

인터넷 상의 클라이언트와 서버의 통신을 위해서는 각자의 고유한 IP 주소가 있어야 한다. 사설 네트워크는 인터넷과 독립적인 네트워크이다. 내부 장비는 사설 IP를 가지게 된다. 이러한 사설 IP로는 통신이 불가능하다.

이런 상황에서 사용되는 기술이 NAT 이다. 네트워크 주소인 IP를 변환한다는 뜻이다. NAT는 IPv4의 주소부족 문제를 해결하기 위한 방법으로 디자인되었다. 사설 네트워크 주소를 사용하는 망에서 외부 공인망과 통신하기 위해 네트워크 주소를 변환해 준다.

사설 IP의 사용자는 공용 인터넷 망을 통해 서버와 통신하기 위해서 공용 IP가 필요하다. 사용자의 트래픽이 NAT 디바이스를 거치게 될 때 NAT 디바이스의 공용 IP로 변환된다. 이런 NAT 디바이스의 공용 IP를 가지고 인터넷에 있는 서버와 통신한다.

클라우드 네트워크는 백본이 연결되어 있는데, 그 내에서 VPC 역할을 만들게 되면 VPC는 사용자 네트워크 안에서 격리된 네트워크 공간이다. 즉, 사설 네트워크이다. 이런 VPC에서 공용망 통신을 하려면 보통 NAT 게이트웨이를 통해 변환되어 나간다.

NAT는 Source를 바꾸는 SNAT와 Destination을 바꾸는 DNAT 두 종류가 있다. 일반적으로는 연결이 stateful 하므로 (방화벽이나 라우터가 연결 상태를 추적하여, 이로 인해 이슈가 발생하지 않도록 한다.) egress traffic이 변환이 되면 ingress traffic은 자동으로 처리되므로 DNAT는 어색할수도 있다.

DNS

호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행한다. 특정 컴퓨터의 주소를 찾거나 임의의 장치의 주소를 찾기 위해 사람이 이해하기 쉬운 도메인 이름을 IP 주소로 변환한다. 주 컴퓨터의 도메인 이름을 IP 주소로 변환하고 라우팅 정보를 제공하는 분산형 데이터베이스 시스템이다.

인터넷은 두 개의 주요 이름 공간을 관리한다. 하나는 도메인 네임 계층, 하나는 IP 주소 공간이다. 도메인 네임 시스템은 도메인 네임 계층을 관리하고 해당 네임 계층과 주소 공간간의 변환 서비스를 제공한다.

인터넷 네임 서버와 통신 프로토콜은 DNS의 네임 시스템을 구현하고 DNS 네임 서버는 도메인을 위한 DNS 레코드를 저장하는 서버이다. DNS는 데이터베이스에 대한 쿼리 응답 정보를 리턴해준다.

1. DNS recursor는 웹 브라우저와 같은 응용 프로그램에서 쿼리를 수신할 수 있도록 설계된 서버이다. 일반적으로 클라이언트의 DNS 쿼리 (ex. www.naver.com) 를 충족하기 위해 요청을 수행한다.
2. Root Name Server는 사람이 읽을 수 있는 호스트 이름을 IP 주소로 변환해주는 첫 번째 단계이다. 인덱스처럼 특정 위치에 대한 참조 역할을 한다.
3. TLD DNS Server는 루트 네임 서버 다음으로, 홉(.com, .net) 등을 해 해주는 역할을 한다.
4. AWS의 Route 53같은 인증된 DNS 서버들은 실제 엑세스해서 IP를 return해준다. 호스트 이름의 IP 주소를 초기 요청을 한 DNS recursor에게 반환해주는 역할을 한다.

사용자가 웹 브라우저에 주소를 입력하고 전송하면, 요청은 일반적으로는 가장 첫 번째로 케이블 인터넷 공급 업체, 광대역 공급 업체 혹은 기업 네트워크와 같은 인터넷 서비스 공급 업체가 관리하는 DNS 해석기로 라우팅된다.

보통 DNS 서버는 OS에 등록되어 있는 곳을 가리키는데 이 DNS 서버를 가기 전에 ISP에서 제공하는 서버를 탄다. 이 ISP에 등록되어 있는 도메인 해석기가 요청을 DNS Root name server로 보낸다. www.example.com 의 경우 .com으로 끝나므로 .com TLD 서버로 리턴한다.

.com TLD Name Server에서 네임 서버를 알려주고, 해당 네임 서버에서 실제 서버를 호스팅하고 있는 네임 서버를 찾아 IP주소를 리턴한다. 이 리턴된 IP 주소는 DNS resolver를 통해 전달되고 TCP/IP 연결을 수행한다.

이러한 과정을 매 연결마다 수행하지 않는다. 일반적으로는 브라우저 레벨에서 관리되는 DNS 캐시가 있다.

HTTPS와 SSL/TLS

HTTPS는 HTTP의 보안이 강화된 버전이다. HTTPS는 넷스케이프 웹 프로토콜이다. 거의 모든 웹 서비스에서 사용되고 있다. HTTPS는 소켓 통신에서 일반 텍스트를 사용하는 대신 SSL/TLS 등의 프로토콜을 사용해 세션 데이터를 암호화한다.

• SSL: 컴퓨터 네트워크를 통해 통신 보안을 제공하는 C 언어로 작성된 암호화 프로토콜. 암호화를 사용하여 데이터의 무결성과 기밀성을 보호
• TLS: 인터넷을 통한 보안 통신을 위한 표준. 클라이언트/서버 애플리케이션이 도청 및 정보 변조를 방지하도록 설계된 방식으로 네트워크를 통해 통신할 수 있도록 한다.

SSL이 초기 버전이고, SSL이 지원을 중단하자 나온 후속 버전이 TLS이다. 두 가지 모두 인터넷을 통한 안전한 인증과 데이터 전송을 제공한다. SSL와 TLS는 메세지 인증에 차이점이 있다. SSL은 메시지 인증을 위해 MAC을 사용한다. 전송 중에 메시지가 변조되지 않도록 한다. TLS는 보호를 위해 MAC을 사용하지 않고 암호화 알고리즘을 사용해 데이터의 변조를 방지한다.

TLS는 SSL의 직접적인 후속 버전이다. 현재는 SSL은 더 이상 사용되지 않고 TLS를 사용한다. 따라서 SSL 인증서는 지금은 TLS 동작 원리이다.

TLS 동작 원리

TLS는 대칭키 암호화 방식과 공개키 암호화 방식을 두 가지 모두 사용한다.

• 대칭키: 암복화에 사용하는 키가 동일하다. 해당 키가 아는 사람은 모두 문서를 복호화할 수 있다. 대표적인 알고리즘은 DES, 3DES, AES, SEED, ARIA 등이 있다. 공개키 암호화 방식에 비해 연산 속도가 빠르지만 키를 교환해야 하는 문제와 키를 교환하는 방법이 필요하다. 사용자마다 각각의 키가 필요하므로 관리해야 할 키가 많다.

• 공개키: 대칭키 암호화 방식보다 복잡한 연산을 거친다. 대표적인 알고리즘은 RSA, DSA, ECC가 있다. 대칭키 방식의 문제점을 해결하기 위해 만들어졌다. 공개키 방식의 키는 공개되어 있다. 따라서 키를 교환할 필요가 없어진다. 공개키는 모든 사람이 접근 가능한 키이고, 개인키는 각 사용자만이 가지고 있는 키가 된다.

수신자가 공개키와 개인키 페어를 만든다. 송신자가 접근 가능한 환경에 수신자의 공개키를 공개한다. 수신자의 개인키는 수신자만이 가지고 있다. 송신자는 수신자의 공개키를 받아 보낼 데이터를 수신자의 공개키로 암호화한다. 암호화된 데이터를 수신자에게 보낸다. 수신자는 암호화된 데이터를 자신이 가지고 있던 개인키로 복호화한다.

공개키 방식은 키가 공개되어 있으므로 따로 키교환이나 분배를 할 필요가 없다. 중간공격자가 개인키를 가지고 있다 해도 수신자만이 암호화한 데이터를 복호화할 수 있으므로 인증을 할 수 있는 환경을 제공한다.

인증서는 이러한 공개키 기반이다.

HTTPS에서 공개키로 사용되는 것이 인증서이다. 인증서에는 키나 소유자에 대한 정보, 인증사 발급자의 디지털 사인 등이 포함되어 있다. 루트 인증서는 최상위 기관인 루트 인증 기관에서 발급된 인증서를 뜻한다. TLS 루트 인증서는 기관에서 직접 발급한 인증서이다. 다른 인증서와는 달리 루트 인증서는 발급 기관에서 자체 서명을 하게 된다. 루트 인증서의 개인키는 TLS 인증서 계층 구조의 다른 인증서의 서명을 하는데 사용된다.

이러한 루트 인증서는 매우 엄격하게 발급되므로 보통 OS나 브라우저에 이미 설치되어 있다. 일반적으로 공개가 되어 있고 다른 루트 인증서를 사용하고자 하는 경우에는 브라우저나 OS에 등록하면 된다.

루트 인증서를 보호하기 위해 중간 인증서를 두는 경우가 많다. 실제 서비스를 제공하는 웹서버들은 루트 인증서가 아닌 중간 기관을 통해 인증서를 발급하는 경우가 많다.

TLS 인증서는 인증서를 발급한 기관의 정보, 서비스를 제공하는 도메인 등의 정보, 즉 서버의 공개키가 포함되어 있다. 이 내용은 인증 기관에 의해 암호화된다. 이 때 공개키 암호화 기법이 사용된다. 이 때는 특이하게 인증 기관의 개인키로 암호화가 진행된다.

브라우저에는 인증기관의 공개키가 깔려있으므로 공개키에 의해 복호화가 가능해진다. 이 서버를 보증하는 것을 인증 회사가 갖고 있는 개인키로 암호화하면 브라우저에 깔려 있는 공개키를 통해 해당 인증 기관에서 만들어진 인증서가 맞다는 것을 인정한다. 이것이 HTTPS 인증서의 핵심이다.

즉, 브라우저가 보유하고 있는 인증 기관의 공개키로 복호화가 가능하다는 것은 해당 공개키와 쌍을 이루는 개인키로 암호화되었다는 것을 보증하는 것이다. 해당 데이터가 인증 기관으로 왔음이 증명되는 것이다.

클라이언트가 공개키를 가지고 보안성 검증이 완료되면 사이트를 신뢰할 수 있으므로 해당 공개키를 활용해 서버와 소통하며 대칭키인 세션키를 가지고 소통할 수 있게 된다.

TLS Handshake

인증 기관의 비공개키로 암호화된 인증서가 브라우저가 가지고 있는 공개키로 복호화를 진행하면 공개키를 활용하여 세션키를 만든다. 이 세션키를 통해 통신을 시작한다. 이러한 HTTPS 연결을 하는 과정을 TLS Handshake 라고 한다.

1. 클라이언트가 서버에게 hello를 보내며 handshake를 시작한다. 여기서 사용하고자 하는 TLS의 버전, 암호 제품군 등의 내용을 실어 보낸다.

2. hello 메시지를 받은 서버는 서버가 가지고 있는 서버의 TLS 인증서, 서버에서 사용하는 암호 제품군 (알고리즘) 을 보낸다.

3. 클라이언트는 인증기관을 통해 서버 인증서를 검증한다. 확인이 완료되면 랜덤한 시퀀스를 서버의 공개키로 암호화하고 보낸다.

4. 여기서 서버가 클라이언트에게 인증서를 요구한다면 서버 인증서와 같은 방식으로 암호화를 해 전송한다. 서버가 클라이언트로부터 서버의 공개키로 받은 문자열을 자신의 개인키로 해독한다.

5. 클라이언트가 아까 보낸 암호화된 시퀀스를 대칭키로 활용할 세션키로 만든다. 그 후 finish를 서버에 보낸다.

6. 서버가 클라이언트가 보낸 랜덤 시퀀스를 개인키로 복호화하고 그 동일한 랜덤 문자열을 세션키로 만든다. 그러면 대칭키가 되므로 똑같이 finish를 보내 연결을 수립하고 HTTPS 통신을 수행한다.

이러한 HTTPS 통신은 엔드포인트 단에서 수행하고, 내부에서의 통신은 offloading 시키고 HTTP로 수행하는 경우가 많다 (지만 사실은 다 HTTPS 를 써야 하는 것이 맞긴하다)...

데이터 지속성(어플리케이션 데이터가 영구적으로 저장되어 프로세스나 서버의 재시작 후에도 유지되는 성질) 은 모든 애플리케이션의 핵심 구성 요소 중 하나이며, Kubernetes로 조정되는 컨테이너화된 어플리케이션의 경우, Persistent Volumes (PV) 와 Persistent Volume Claims (PVC) 를 이해하는 것은 필수적입니다. 이 글은 PVCs가 무엇인지 쉽게 이해할 수 있도록 하고, 어떻게 PVs와 다른지, 어째서 그들이 Kubernetes 환경에서 필수적인지에 대해 초점을 맞추고 있습니다. 당신이 DevOps Engineer인지, Kubernetes 초보자인지, 아니면 숙련된 개발자인지 여부에 관계없이 PVC에 대해 알아야 할 모든 정보를 제공하는 종합 가이드입니다.

Kubernetes에서 Persistent Volume Claims (PVC) 란 무엇일까요?

Kubernetes에서, Persistent Volume Claims (이하 PVC) 는 Persistent Volume (이하 PV) 이 처리할 수 있는 스토리지에 대한 사용자의 요청입니다. 특정한 스토리지 리소스에 액세스 하기 위한 “티켓” 이라고 생각하시면 됩니다. 사용자가 PVC를 생성할 때, Kubernetes는 이를 바인딩할 적절한 PV를 찾아서, PVC에 지정된 스토리지 요구사항이 충족되는지 확인합니다. 일치하는 PV를 찾는다면, PVC는 해당 PV에 바인딩되어, 애플리케이션이 스토리지에 액세스 할 수 있게 됩니다.

Persistent Volume (PV) vs Persistent Volume Claims (PVC)

Persistent Volume (PV)

• 시스템 관리자에 의해 프로비저닝됨: 일반적으로 시스템 관리자가 프로비저닝합니다.
• 클러스터 리소스: 클러스터 레벨 리소스이므로, 클러스터의 어느 노드에서나 액세스할 수 있습니다.
• Storage Backend: NFS, iSCSI, local disk, 그 외가 될 수 있습니다.
• 네임스페이스가 지정되지 않음: PVs 는 특정한 네임스페이스에 묶여 있지 않습니다.

Persistent Volume Claims (PVC)

• 유저에 의해 요청됨: 유저에 의해 생성되거나, 경우에 따라, 쿠버네티스가 자동으로 생성합니다.
• 네임스페이스 범위: PVCs 는 네임스페이스에 한정되므로, 같은 네임스페이스에 있는 파드에서만 액세스할 수 있습니다.
• 요구 사항 정의: 스토리지 크기, 액세스 모드 등을 지정합니다.
• 라이프사이클: 일반적으로 이 PVC를 사용하는 파드와 동일한 생명 주기를 갖습니다.

간단하게 비유하면: PV가 주차장이라면, PVC는 그 주차장에 한 자리를 차지할 수 있는 주차권입니다.

코드 예시: PV와 PVC 생성하기

PV를 생성한 다음 PVC를 생성하여 해당 볼륨에서 스토리지를 요청하는 예를 살펴 보겠습니다.

PV 만들기

다음은 로컬 스토리지를 사용하여 간단한 PV를 정의하는 YAML 파일입니다:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  storageClassName: local-storage
  local:
    path: /mnt/data
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - my-node

PV를 만들기 위해, 해당 YAML 파일을 실행합니다:

kubectl apply -f my-pv.yaml

PVC 만들기

PVC를 정의하는 YAML 파일입니다:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  storageClassName: local-storage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

PVC를 만들기 위해, 해당 YAML 파일을 실행합니다:

kubectl apply -f my-pvc.yaml

PVC를 생성한 후, 쿠버네티스는 요구 사항을 충족하는 사용 가능한 PV에 자동으로 바인딩합니다. 스테이터스를 다음 명령어로 확인할 수 있습니다:

kubectl get pvc my-pvc

그리고 당신은 우리가 이미 만들어 놓은 PV에 PVC가 바인딩되었다는 것을 확인할 수 있을 것입니다.

왜 PVC가 중요한가요?

• 추상화: PVC는 기본 스토리지 인프라를 추상화하여 개발자들이 스토리지 백엔드의 세부 사항을 알 필요 없이 스토리지를 요청할 수 있는 방법을 제공합니다.
• 이식성: PVC는 네임스페이스 범위를 가지고 스토리지 요구 사항을 정의하기 때문에, 다른 쿠버네티스 클러스터 간에 애플리케이션을 이동하기가 더 쉬워집니다.
• 확장성: PVC는 필요에 따라 쿠버네티스가 새로운 볼륨을 자동으로 프로비저닝할 수 있게 하여, 애플리케이션을 확장하기가 더 쉬워집니다.
• 데이터 지속성: PVC를 사용하면 파드가 종료되어도 데이터가 손실되지 않으며, 장기 스토리지 솔루션을 제공합니다.

쿠버네티스를 사용할 때, 특히 데이터 지속성과 스토리지 효율성을 보장하기 위해서는 PV 와 PVC 를 이해하는 것이 중요합니다. PV는 실제 스토리지 인프라를 제공하는 반면, PVC는 사용자 애플리케이션과 이러한 스토리지 리소스 간의 다리 역할을 하여, 더욱 유연하고 효율적이며 확장 가능한 스토리지 솔루션을 가능하게 합니다.

프라이빗 컨테이너 레지스트리를 사용하기 위해서는 시크릿을 사용하는 파드를 사용한다. 실습에서는, Docker Hub를 사용해서 구축한다.

• Docker Hub 로그인
  • docker login 명령어를 사용하여 Docker Hub에 로그인한다. 다른 프라이빗 레지스트리를 사용한다면, 해당 레지스트리에 대한 명령줄 정보가 필요하다.
  • cat ~/.docker/config.json 명령어를 사용하여 자격 증명을 확인한다. 하단과 비슷한 정보가 나오는지 확인한다.

[developer@localhost root]$ cat ~/.docker/config.json
{
        "auths": {
                "https://index.docker.io/v1/": {
                        "auth": "어쩌고"
                }
        }

• 쿠버네티스 클러스터는 프라이빗 레지스트리에 인증할 때 kubernetes.io/dockerconfigjson 타입의 시크릿을 사용한다. docker login이 되어 있는 상태라면 자격 증명을 클러스터에 복사할 수 있다. 해당 명령어를 사용한다.

k create secret generic regcred \
--from-file=.dockerconfigjson=/home/developer/.docker/config.json \
--type=kubernetes.io/dockerconfigjson 

secret/regcred created

---

k get secret
NAME      TYPE                             DATA   AGE
regcred   kubernetes.io/dockerconfigjson   1      78s

• 로그인 하지 않은 경우에는 CLI에서 자격 증명을 통하여 시크릿을 생성할 수 있다.

kubectl create secret docker-registry regcred \
--docker-server=<your-registry-server> \
--docker-username=<your-name> --docker-password=<your-pword> \
--docker-email=<your-email>

• 방금 생성한 regcred 시크릿의 정보를 확인해 보자.

k get secret regcred -o yaml

apiVersion: v1
data:
  .dockerconfigjson: ~/.docker/config.json을 base64로 인코딩한 내용
kind: Secret
metadata:
  creationTimestamp: "2024-02-02T07:23:36Z"
  name: regcred
  namespace: default
  resourceVersion: "77283"
  uid: 8e7edf7e-0499-43f7-aa85-e53e93f4949d
type: kubernetes.io/dockerconfigjson

• .dockerconfigjson 필드 값을 확인하기 위해, 시크릿 데이터를 읽을 수 있는 형식으로 변형해 본다.

kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode

{
        "auths": {
                "https://index.docker.io/v1/": {
                        "auth": "아까 결과와 같음"
                }
        }
}

• 이를 통해 regcred 라는 시크릿으로 클러스터 내에서 도커 자격 증명을 생성한 것을 확인할 수 있다.
• 생성한 시크릿을 사용하는 파드를 만든다.
  • 도커에 이미지를 넣기 전에, tag를 꼭 변경해 주자…

    docker tag busybox:latest <myusername>/busybox:latest

    ---

    docker tag busybox:latest your_id/busybox:latest
    docker push your_id/busybox:latest
    The push refers to repository [docker.io/your_id/busybox]
    2e112031b4b9: Mounted from library/busybox
    latest: digest: sha256:어쩌고~... size: 527
    ---
    vi pod.yaml 

    apiVersion: v1
    kind: Pod
    metadata:
      name: private-reg
    spec:
      containers:
      - name: private-reg-container
        image: your_id/busybox:latest
      imagePullSecrets:
      - name: regcred

• 프라이빗 저장소에서 이미지를 받아오기 위하여, 쿠버네티스에서 자격 증명이 필요하다. 구성 파일의 imagePullSecrets 필드를 통해 쿠버네티스가 regcred 라는 시크릿으로부터 자격 증명을 가져올 수 있다.
• 파드를 생성했을 때 파드가 생성되면 ok

k get po
NAME                                READY   STATUS    RESTARTS      AGE
nginx-deployment-6d6565499c-fdzhn   1/1     Running   0             22m
private-reg                         1/1     Running   9 (75s ago)   7m32s

containerStatuses:
    - containerID: docker://1ae39d854c8cb35cbe974208587ebf5de7cec69f1cbb8c1149734ab60b407de8
      image: your_id/nginx:latest
      imageID: docker-pullable://your_id/nginx@sha256:6a9af2366105c104e353d16998458d6a15aa5d6db0861ad9ce98538890391950

HTTPS는 HTTP의 요청과 응답을 암호화하여 전달하기 위해 사용한다. HTTP는 암호화 되어 있지 않으므로, 데이터가 중간에 가로채지거나 변조될 수 있는 취약점을 해결하기 위해 도입되었다. 또한 사용자간의 인증을 위해서도 사용한다. HTTPS는 공개 키 기반 구조(PKI)를 사용하여 신원을 확인하고 데이터를 암호화한다.

웹 사이트에 접속했을 때, 웹 사이트가 개인 키를 가지고 있으며, 브라우저는 해당 웹 사이트의 공개 키가 포함된 인증서를 검증한다. 인증서는 신뢰할 수 있는 인증 기관(CA)에 의해 발급된다. 브라우저는 인증서를 사용하여 웹 서버의 신원을 확인한다.

브라우저에 "등록"된 것은 실제로 인증서의 유효성을 확인하기 위한 루트 인증서 목록이다. 웹 서버의 인증서가 이 루트 인증서들 중 하나에 의해 서명되었다면, 브라우저는 그 인증서를 신뢰한다.

HTTPS는 HTTP 프로토콜 상위에 TLS 암호화를 구현한 것이라고 할 수 있다. TLS는 응용 계층과 전송 계층 사이에서 작동하여 안전한 보안 채널을 형성해 주는 역할을 한다.

HTTPS는 다음과 같이 동작한다:

1. 핸드셰이크: 클라이언트가 서버에 접속하면, 서버는 자신의 공개 키를 포함한 인증서를 클라이언트에게 제공한다.
2. 인증서 검증: 클라이언트는 인증서가 신뢰할 수 있는 CA(Certificate Authority)에 의해 발급되었는지 확인한다.
3. 대칭 키 생성: 클라이언트는 대칭 키를 생성하고, 서버의 공개 키를 사용하여 이를 암호화하여 서버에게 보낸다.
4. 암호화된 세션 시작: 서버는 개인 키를 사용해 대칭 키를 복호화하고, 이후의 통신은 이 대칭 키를 사용하여 암호화된다.

HTTPS의 장점은 다음과 같다.

• 데이터 보안: 중간자 공격으로부터 사용자 데이터를 보호한다.
• 데이터 무결성: 전송 중인 데이터가 변경되거나 손상되지 않았음을 보장한다.
• 인증: 사용자가 실제로 의도한 서버와 통신하고 있음을 보증한다.

HTTP의 성능 향상을 목적으로 설계된 새로운 프로토콜인 HTTP/2는 대부분의 상황에서 HTTPS 연결을 전제로 한다. 이를 통해 웹 페이지 속도를 빠르게 하고, 다수의 리소스를 효율적으로 전송할 수 있도록 해 준다.

SSL / TLS

TLS는 넷스케이프의 SSL을 기반으로 한 보안 프로토콜이다. SSL과 TLS는 사실상 같은 것을 의미한다고 보면 된다. 주로 HTTP를 암호화할 때 사용한다. 인증서를 통해 상호가 적당한 사용자인지 검증하고, 암호화 알고리즘을 통해 암호화된 키를 교환한 후 암호화 통신을 진행한다.

TLS는 세 가지 역할을 한다.

• 암호화: 제 3자로부터 전송되는 데이터를 숨긴다.
• 인증: 정보를 교환하는 당사자가 요청된 당사자임을 보장한다.
• 무결성: 데이터가 위조되거나 변조되지 않았는지 확인한다.

TLS는 공개키를 사용하여 암호화를 진행한다. (공개키 암호화) 공개 키는 서버의 인증서를 통해 클라이언트 장치와 공유된다. 인증서는 CA(인증 기관) 에 의해 암호화되어 서명되며, 브라우저에는 신뢰하는 CA의 목록이 있다. 이 CA의 목록에 저장되지 않은 곳에서 인증서가 발급되었다면, https가 신뢰되지 않는다고 뜬다. (그 빨간색 그거)

서버와 클라이언트는 교환된 공개 키와 개인 키를 통해 세션 키라는 새로운 키에 동의하여 통신을 암호화한다. 세션 키는 이 하나의 통신 세션만을 위해 존재하는 일회용 대칭 키이다.

TLS 프로토콜은 여러 버전(예: TLS 1.0, 1.1, 1.2, 1.3 등)이 있으며, 각각의 버전은 보안 강도와 호환성 측면에서 차이가 있다.

• TLS 1.0
  • SSL의 직접적인 후속 버전이다. SSL의 보안 취약점을 많이 해결했지만, 현대의 기준으로는 여전히 취약점이 많다고 여겨진다.
• TLS 1.1
  • TLS 1.0에 비해 몇 가지 보안 개선 사항을 도입했지만, 초기 버전의 취약점을 완전히 해결하지는 못했다.
• TLS 1.2
  • SHA-256과 같은 강력한 해시 알고리즘을 지원하며, 안전하지 않은 암호화 알고리즘(예: RC4)의 사용을 피함. 현재까지도 널리 사용되고 있는 버전이다.
• TLS 1.3
  • TLS 프로토콜의 최신 버전. TLS 1.2보다 더 빠르고, 더 안전하다. TLS 핸드셰이크의 작동 방식을 업데이트하여, 두 번이 아니라 한 번의 왕복만 하면 되도록 했다. 또한, 클라이언트가 이전의 웹 사이트에 접속한 적이 있는 경우 왕복 횟수를 0으로 해 HTTPS의 연결 속도가 빨라지도록 했다. 이를 통해 대기 시간이 대폭 단축되고 전반적인 사용자 경험이 개선되도록 했다.

TLS Handshake

TLS를 사용하는 통신 프로세스를 TLS Handshake 라고 한다. 서버와 클라이언트가 서로를 인식하고, 검증하고, 안전하게 통신할 수 있도록 하는 과정이다.

1. ClientHello

   Handshake 프로세스는 클라이언트가 서버에게 Hello 메시지를 보내면서 시작된다. 이 때 메시지에는 클라이언트가 지원하는 TLS 버전, 클라이언트가 지원하는 암호화 방식, 세션을 재개하기 위한 ID(이전 연결에서 사용됨), 그리고 무작위 난수가 포함되어 있다.

2. ServerHello

   서버는 ClientHello에 대해 ServerHello 메시지로 응답한다. 이 때 메시지에는 선택된 TLS 버전, 서버에서 선택한 암호화 방식, 세션 ID, 그리고 서버에서 생성한 무작위 난수가 포함되어 있다.

3. Certificate

   서버는 자신의 인증서를 클라이언트에게 보내 클라이언트가 서버의 신뢰성을 검증할 수 있도록 한다. 인증서에는 서버의 공개 키와 인증서 발급 기관(CA)의 서명이 포함되어 있다. 클라이언트는 자신의 웹 브라우저에 등록된 “신뢰할 수 있는 인증서” 목록에 있는 공개 키로 인증서 해시 값을 비교하여 서버를 신뢰할 수 있는지 검증한다.

4. ServerHelloDone

   서버가 인증서와 필요한 모든 메시지를 보낸 후, 서버는 ServerHelloDone 메시지를 클라이언트에게 전송하여 서버가 클라이언트에게 보낼 메시지를 모두 보냈다고 한다.

5. ClientKeyExchange

   인증서의 무결성이 검증되었다면, 클라이언트는 클라이언트의 난수와 서버의 난수를 조합하여 대칭 키(세션 키)를 생성한다. 그리고 대칭 키를 서버의 공개 키로 암호화하고, 암호화된 키를 서버에 전송한다. 이를 통해 양측은 통신에 사용할 공유된 비밀을 가지게 된다.

   자세히 설명하자면, 클라이언트는 키 교환에 필요한 정보를 서버에 제공한다. 이 정보를 사전 마스터 시크릿(pre-master secret) 이라고 하며, 절대로 노출이 되어서는 안 된다. 이 값을 클라이언트가 서버의 공개 키로 암호화 하여 전송한다. 그러면 서버는 개인 키로 복호화하고, 이렇게 되면 서로가 사전 마스터 시크릿을 공유한다. 이 값을 사용해서 세션에 사용할 키를 만드는 것이다.

6. ChangeCipherSpec

   양측은 이후의 메시지가 협상된 암호화 설정을 사용하여 전송될 것임을 알린다.

7. Finished

   핸드셰이크 과정 동안 교환된 모든 메시지의 무결성을 검증하며, 이 시점부터 양측은 안전한 통신을 시작한다.

TLS Termination

클라이언트-인터넷망-서비스-파드로 연결된 구조에서, 클라이언트부터 파드까지 end-to-end로 https 암호화가 걸린다. 문제는 서버 입장에서 end-to-end 암호화는 전혀 안전하지 않다. https는 클라이언트가 서버를 인증하는 과정인데, 서버 입장에서는 클라이언트를 확인하지 못한다(인증을 할 수 없다). 따라서 서버 입장에서는 클라이언트의 요청을 수행할 수 밖에 없는데, 악성 요청도 그대로 수행하게 된다.

이를 방지하기 위해서 쓰이는 것이 WAF지만, 결국 암호화 된 데이터를 중간에서 풀어볼 수 없어 공격인지 아닌지 확인할 수 없다. 이를 위해서 사용하는 것이 TLS Termination Proxy이다. 클라이언트와 프록시 서버 간에 HTTPS 연결을 종료하고, 프록시 서버와 내부 서비스 간에는 HTTP 또는 새로운 HTTPS 연결을 사용하는 방식이다. 프록시 서버에서 암호화를 해제하여 요청을 검사할 수 있으며, 내부 네트워크에서는 HTTPS가 필요하지 않거나, 필요한 경우 새로운 HTTPS 세션을 시작할 수 있다.

클라이언트와 서버 사이에 프록시 서버가 있다. 프라이빗 네트워크 안에서는 사실 접근 제어만 잘 된다는 가정 하에 https로 통신할 필요가 없다. 프록시 서버에서 tls 종료 프록시를 통해 https를 종료시키고, 내부에서는 http를 종료한 상태에서 통신한다. 내부적으로 https 통신을 한다고 해도, tls 통신 프록시를 통해 한 번 종료시키고 다시 https로 통신한다.

쿠버네티스 환경에서는 ingress를 사용하여 쉽게 TLS Termination Proxy를 구현할 수 있다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ing-tls-term
spec:
  tls:
  # - hosts:
    # - myapp.example.com #실습할 때는 없애는 것이 편함
    secretName: myapp-tls-secret #이곳의 인증서와 키를 가져온다.
  rules:
  # - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend: 
          service:
            name: myapp-svc-np
            port: 
              number: 80

예시는 클라이언트와 Ingress 간의 HTTPS 연결을 종료하고, Ingress와 내부 서비스 간에는 HTTP를 사용하도록 설정하는 방법을 보여준다. 이 설정을 통해 Ingress에서 TLS 인증서를 관리하며, 내부 파드는 HTTPS 관련 설정이나 키를 관리할 필요가 없게 된다. 암호화 통신은 클라이언트와 인그레스 사이에서만 하기 때문에 파드의 nginx는 암호를 위한 설정과 인증키가 필요 없기 때문이다. 따라서 사용자가 훨씬 유연하게 사용할 수 있다.

PKI

PKI는 공개 키 기반 구조(Public Key Infrastructure)를 의미한다. PKI는 디지털 인증서와 공개 키 암호화를 활용하여 인터넷 상에서 사용자, 서버 및 조직의 신원을 안전하게 인증하고, 데이터의 무결성 및 기밀성을 보장한다.

기존의 암호화는 대칭 키(암호화 키와 복호화 키가 같음) 알고리즘을 사용하여 정보를 교환했다. 대칭 키 암호화는 구현이 빠르고 속도가 빠르다는 장점이 있지만, 키를 스니핑(패킷을 엿보는 행위)나 스푸핑(속여서 공격) 등의 해킹 기법에 당하기 쉽다는 단점이 있었다. 이를 해결하기 위해 암호화 키와 복호화 키를 따로 가져가는 기술이 등장했고, 이에 사용하는 것이 PKI 이다.

PKI를 이용한 정보 교환은 두 가지 상황을 가정할 수 있다:

• 공개 키를 사용해 암호화
  • 공개 키를 사용하여 암호화하면 공개 키에 매칭되는 개인 키를 가지고 있는 상대방만 개인 키를 사용해 복호화 할 수 있다.
• 개인 키를 사용해 암호화
  • 개인 키를 사용해 암호화하면 공개 키를 이용해 누구나 복호화할 수 있다. 이는 자신의 자격을 증명하는 데에 주로 사용된다.

공개 키의 경우에는 공개되어 있기 때문에, 해당 키가 신뢰할 수 있는 키인지 확인하기 어렵다. 이 때 사용되는 것이 바로 인증 기관(CA) 이다. CA는 인증서를 발행하고 관리하는 공개 키에 대한 공신력 있는 기관이다. 인증 정책을 수립하고 사용자의 공개 키와 신원 정보를 결합하여 인증서를 발급하며, 이를 통해 사용자의 신원을 보증한다.

• RA(등록 기관) 이라는 것도 있다. 등록 기관은 CA의 일 중 공개 키의 등록과 본인에 대한 인증을 대행한다.
• 인증서를 보존해 두고, PKI의 이용자가 인증서를 입수할 수 있도록 한 데이터베이스를 저장소라고 한다. 전화번호부와 같은 역할을 한다고 볼 수 있다.

CA는 개인 키와 공개 키 쌍을 만들고, 개인 키에 대한 인증서를 발급한다. 이러한 인증서들의 표준 규칙이 X.509 형식이다. 이 때 인증서의 최상위에 존재하는, 일반적으로 웹 브라우저에 내장되어 있는 ‘누구나 신용할 만한’ 인증서 발급 기관에서 발급한 인증서들을 Root CA라고 한다.

Chain of Trust

인증서는 트리 구조를 가진다. 예를 들어, 네이버의 인증서 구조를 보자.

네이버는 Root CA인 DigiCert로 부터 인증받은 하위 인증서인 DigiCert TLSCA1 으로부터 인증을 받았다. 보통은 이처럼 3계층 구조로 이루어진다. DigiCert가 Root CA이고, DigiCert TLSCA1 역시 인증기관이다. 이것을 중간 인증 기관(Intermidiate CA) 라고 부른다. 이 ICA에 대한 신뢰를 입증하기 위해 다음과 같은 구성을 한다.

1. 회사가 Root CA에 인증서 발급 요청을 하면, 인증서의 해시 값을 Root CA의 비밀 키로 암호화한다.
2. 이러면 회사의 인증서 값은 Root CA의 공개 키로 복호화 할 수 있다. 복호화한 값이 Root CA 인증서의 값과 다르다면 인증서의 내용이 변조되었음을 의미한다.
3. 클라이언트는 제공된 최종 인증서부터 시작하여, 각 중간 인증서를 거슬러 올라가면서 루트 인증서에 도달할 때까지 각 인증서의 유효성을 검증한다. 각 인증서는 바로 상위 인증서에 의해 서명되어 있어야 하며, 상위 인증서의 공개 키로 하위 인증서의 서명을 검증할 수 있다.
4. 마지막 단계에서는 루트 인증서가 클라이언트 소프트웨어에 사전 설치된 신뢰할 수 있는 루트 인증서 목록 중 하나와 일치하는지 확인한다.
5. 상위기관의 공개키로 하위기관의 인증서 해시값을 복호화함으로써 쉽게 변조 유무를 확인할 수 있으므로, 하위 기관을 신뢰할 수 있다고 간주한다.

이처럼, X.509 인증서는 신뢰 체인을 구성할 수 있다. 최상위의 루트 CA가 중간 CA의 인증서에 서명하고, 이 중간 CA는 다시 사용자 또는 서버의 인증서에 서명한다. 이 체인을 통해 최종 사용자의 인증서가 루트 CA에 의해 간접적으로 신뢰된다. 이것을 Chain of Trust라고 부른다.

X.509

X.509는 ITU-T에서 책정한 표준 형식이다. X.509는 매우 엄격한 수직 구조를 띄고 있어, 하나의 인증 기관(Root CA)를 정점으로 하는 트리 구조를 띄고 있다.

X.509 규격의 인증서는 공개되어 있고, OpenSSL 등을 통해 누구나 만들 수 있다. 이러면 인증서에 대한 신뢰의 문제가 발생한다. 이래서 등장한 것이 바로 CA라고 볼 수 있다.

X.509 인증서는 다음과 같은 주요 구성 요소를 포함한다:

• Version 인증서의 버전. v3 가 가장 널리 사용되는 버전이다
• Serial Number 인증서를 식별하기 위한 고유 번호
• Algorithm Identifier 알고리즘 식별자
• Signature 서명
• Issuer 인증서를 발급한 CA의 이름
• Validity 인증서의 유효 기간
  • Not Before 유효 기간이 시작하는 날짜
  • Not After 유효 기간이 끝나는 날짜
• Subject 인증서를 소유하고 있는 개인, 조직, 장치 등의 이름
• Subject Public Key Info 소유자 공개 키 정보. 공개 키 알고리즘과 공개 키를 포함한다
• Issuer Unique Identifier (Optional) 증서의 발급자를 고유하게 식별하는 데 사용된다
• Subject Unique Identifier (Optional) 인증서의 주체를 고유하게 식별하는 데 사용된다
• Extensions (Optional) 키 사용법, 인증서 정책, 대체 이름 등 추가적인 정보를 제공한다.

OpenSSL로 인증서 설정해 보기

HAProxy가 설치되어 있다는 것을 전제로 한다.

인증서의 경로는 /etc/haproxy/tls 에 있다.

openssl genrsa -out test.com.key 2048
openssl req -new -key test.com.key -out test.com.csr
openssl x509 -req -days 365 -in test.com.csr -signkey test.com.key -out test.com.crt

를 통해 crt 파일을 생성한다.

openssl rsa -in test.com.key -text > key.pem
openssl x509 -inform PEM -in test.com.crt > crt.pem
openssl pkcs12 -export -in test.com.crt -inkey test.com.key -out cert.p12
openssl pkcs12 -in cert.p12 -nodes -out cert.pem

.pem 파일로 만든다.

vi /etc/haproxy/haporxy.cfg

global
ssl-default-bind-options no-sslv3
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
ssl-default-server-options no-sslv3
ssl-default-server-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
tune.ssl.cachesize 100000
tune.ssl.lifetime 600
tune.ssl.default-dh-param 2048

frontend https
bind *:443 ssl crt /etc/haproxy/tls/cert.pem
default_backend https_test
option forwardfor

backend https_test
balance roundrobin
server app1 192.168.0.26:80 check
server app2 192.168.0.36:80 check

정상적으로 설정되었는지 확인한다.

haproxy -f /etc/haproxy/haproxy.cfg -c

configure valid ok가 나오면 완료.

1. 시작하기 전

시작하기 전에, 해당 사항들을 충족하는지 확인한다.

1. GCP Account
2. Google Cloud SDK (gcloud) 설치: GKE CLI를 제공한다.
3. GKE Cluster API 활성화: 프로젝트에 GKE Cluster API를 활성화한다. 콘솔이나 해당 명령어를 통해 gcloud에서 활성화할 수 있다. gcloud services enable container.googleapis.com --project=PROJECT_ID
4. 인증 및 자격 증명: Terraform이 GCP 계정에 액세스할 수 있도록 적절한 인증을 구성한다. Application Default Credentials (ADC) 또는 Service Account 키 파일을 사용할 수 있다. 참고
5. Terraform과 kubectl을 로컬 머신에 설치해야 한다.

gcloud config list 명령어를 통해 현재 구성 정보를 확인할 수 있다.

2. GCP 계정에서 새로운 프로젝트 생성하기

GCP 콘솔에서 새 프로젝트 버튼을 눌러 새로운 프로젝트를 생성한다.

3. API 활성화

Compute Engine API와 Kubernetes Engine API를 활성화한다. 콘솔에서 활성화하거나, 해당 명령어를 통해 gcloud에서 활성화할 수 있다.

gcloud services enable container.googleapis.com # Kubernetes Engine
gcloud services enable compute.googleapis.com # Compute Engine

4. 서비스 계정 생성

서비스마다 별도의 서비스 계정을 만드는 것이 좋다. Terraform 전용 서비스 계정을 생성하면, 적절하게 격리 및 권한 제어를 할 수 있다.

• GCP 콘솔에서 서비스 계정 페이지로 이동한다. (IAM 및 관리자 -> 서비스 계정)
• 서비스 계정 생성 버튼을 클릭하고 새로운 서비스 어카운트를 생성한다.
• 서비스 계정에 액세스 권한을 부여하고 생성 버튼을 누른다.
• 서비스 계정이 JSON 형태로 컴퓨터에 저장된다. 이 파일에는 서비스 계정의 자격 증명이 포함되어 있다. (서비스 계정 -> 작업 -> 키 관리 -> 키 추가 -> 새 키 만들기 -> JSON)

5. gcloud SDK 설치 및 초기화, kubectl, Terraform 설치

GCP에서 Terraform 작업을 실행하고 GKE 클러스터를 생성하려면 Google Cloud SDK (gcloud) 를 설치해야 한다. 설치

설치한 후에는, gcloud init 명령어를 사용하여 초기화한다.

gcloud auth login을 통해 당신의 구글 계정을 gcloud SDK와 연동할 수 있다.

gcloud auth list
gcloud auth application-default login
gcloud config set account 'ACCOUNT'
gcloud config set project 'PROJECT_ID'

쿠버네티스를 활용하기 위해서는 kubectl을 설치해야 한다. 설치

Terraform도 설치해 주자. 설치

6. Terraform 파일 생성

생성한 폴더 내에 Terraform 파일을 생성해 준다. kubernetes-engine 과 network 모듈을 사용할 것이다.

terraform {
  # provider 파일을 통해 Terraform은 클라우드 공급자, SaaS 공급자 및 기타 API와 상호작용할 수 있다. 
  # Terraform이 프로젝트에서 사용할 특정 프로바이더와 그들의 버전을 정의하여, 구성의 일관성과 호환성을 보장한다.

  required_version = ">= 1.6" # 최소 Terraform 버전을 1.6.0 이상으로 지정
  required_providers {
    google = {
      source  = "hashicorp/google" # Google 프로바이더의 출처를 HashiCorp 레지스트리에서 "hashicorp/google"으로 지정
      version = "~> 5.7.0"         # Google 프로바이더의 버전을 5.7.0으로 지정하며, 호환 가능한 마이너 업데이트는 허용
    }
    local = {
      source  = "hashicorp/local"
      version = "2.4.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "2.24.0"
    }
  }
}

# backend.tf를 통해 Terraform의 state를 원격 저장소에 저장하도록 설정할 수 있다.
# GCP를 사용할 것이므로, GCS(Google Cloud Storage) 버킷으로 설정해 준다. 혹은 Terraform Cloud를 사용할 수도 있다.

terraform {
  backend "gcs" {
    bucket = "k8s-standard-bucket-tfstate"
    prefix = "terraform/state"
  }
}

backend.tf에 사용할 GCS 생성을 위하여 bash 스크립트를 작성하였다.

#!/bin/bash

BUCKET_NAME="BUCKET_NAME"
PROJECT_ID="PROJECT_ID"
LOCATION="ASIA-NORTHEAST3"

# GCS 버킷 생성

if gsutil ls -p $PROJECT_ID gs://$BUCKET_NAME 2>&1 | grep -q 'NotFound'; then
    echo "Creating bucket $BUCKET_NAME"
    gsutil mb -p $PROJECT_ID -l $LOCATION gs://$BUCKET_NAME
    gsutil versioning set on gs://$BUCKET_NAME
else
    echo "Bucket $BUCKET_NAME already exists."
fi

# vpc-network.tf
# VPC와 서브넷을 프로비저닝한다.
module "vpc" {
  source       = "terraform-google-modules/network/google"
  version      = "~> 8.0"
  project_id   = var.project_id
  network_name = "${var.network}-${var.env_name}"
  routing_mode = "GLOBAL"
  subnets = [
    {
      subnet_name           = "subnet-01"
      subnet_ip             = "10.10.20.0/24"
      subnet_region         = var.region
      subnet_private_access = "true"
      subnet_flow_logs      = true
      description           = "For private subnet"
    }
  ]
  # 클러스터 내부의 Pods와 Services에 IP 주소를 할당하기 위한 추가적인 IP 범위
  secondary_ranges = {
    subnet-01 = [
      {
        range_name    = var.ip_range_pods_name
        ip_cidr_range = "10.20.0.0/16"
      },
      {
        range_name    = var.ip_range_services_name
        ip_cidr_range = "10.21.0.0/16"
      }
    ]
  }
}

# main.tf
# GKE 클러스터와, 별도로 관리되는 노드 풀을 생성한다.
data "google_client_config" "default" {}

provider "kubernetes" {
  host                   = "https://${module.gke.endpoint}"
  token                  = data.google_client_config.default.access_token
  cluster_ca_certificate = base64decode(module.gke.ca_certificate)
}

resource "google_service_account" "default" {
  # google_service_account 리소스의 account_id에는 서비스 계정의
  # 전체 이메일 주소가 아니라 고유 ID 부분만 포함해야 한다.
  account_id   = "k8s-standard-architecture"
  project      = var.project_id
  display_name = "K8s Standard Architecture Service Account"
  description  = "Service account for K8s standard architecture"
}

module "gke" {
  source                     = "terraform-google-modules/kubernetes-engine/google//modules/private-cluster"
  project_id                 = var.project_id
  name                       = var.cluster_name
  region                     = var.region
  zones                      = var.zones
  network                    = module.vpc.network_name
  subnetwork                 = module.vpc.subnets_names[0]
  ip_range_pods              = var.ip_range_pods_name
  ip_range_services          = var.ip_range_services_name
  http_load_balancing        = true
  network_policy             = true
  private_cluster_config     = true
  horizontal_pod_autoscaling = true
  filestore_csi_driver       = false
  enable_private_endpoint    = false
  enable_private_nodes       = true
  master_ipv4_cidr_block     = "10.0.0.0/28"
  deletion_protection        = false 
  # Terraform 등 다른 방법으로 클러스터가 삭제되는 것을 허용하지 않는다면 true로 설정

  node_pools = [
    {
      name            = "default-node-pool"
      machine_type    = "e2-standard-4"
      node_locations  = "asia-northeast3-b,asia-northeast3-c"
      min_count       = 2
      max_count       = 5
      disk_size_gb    = 30
      spot            = false
      image_type      = "COS_CONTAINERD"
      disk_type       = "pd-standard"
      logging_variant = "DEFAULT"
      auto_repair     = true
      auto_upgrade    = true
      service_account = "k8s-standard-architecture@${var.project_id}.iam.gserviceaccount.com"
    }
  ]

  node_pools_oauth_scopes = {
    all = [
      "https://www.googleapis.com/auth/logging.write",
      "https://www.googleapis.com/auth/monitoring",
      "https://www.googleapis.com/auth/trace.append",
      "https://www.googleapis.com/auth/service.management.readonly",
      "https://www.googleapis.com/auth/devstorage.read_only",
      "https://www.googleapis.com/auth/servicecontrol"
    ]
  }

  node_pools_labels = {
    all = {}
    default-node-pool = {
      default-node-pool = true
    }
  }

  node_pools_metadata = {
    all = {}
    default-node-pool = {
      #노드가 종료될 때, kubectl drain 명령어를 사용하여 
      # 파드를 안전하게 제거하고 필요하다면 다른 노드로 재스케줄링 되도록 하는 스크립트를 실행한다.
      shutdown-script                 = "kubectl --kubeconfig=/var/lib/kubelet/kubeconfig drain --force=true --ignore-daemonsets=true --delete-local-data \"$HOSTNAME\""
      node-pool-metadata-custom-value = "default-node-pool"
    }
  }

  node_pools_taints = {
    all = []

    default-node-pool = [
      {
        key    = "default-node-pool"
        value  = true
        effect = "PREFER_NO_SCHEDULE"
      }
    ]
  }

  node_pools_tags = {
    all = []

    default-node-pool = [
      "default-node-pool",
    ]
  }

  depends_on = [module.vpc, google_service_account.default]
}

# auth.tf
# GKE 클러스터에 대한 인증을 구성한다.

module "gke_auth" {
  source               = "terraform-google-modules/kubernetes-engine/google//modules/auth"
  version              = "29.0.0"
  project_id           = var.project_id
  location             = module.gke.location
  cluster_name         = module.gke.name
  use_private_endpoint = true
  depends_on           = [module.gke] 
  # module.gke에 의존한다. 즉 gke에 설정된 클러스터가 생성된 후 인증 정보가 설정된다.
}

# kubeconfig를 로컬 시스템에 저장하여, 쿠버네티스 클러스터에 접근할 수 있도록 한다.

resource "local_file" "kubeconfig" {
  content  = module.gke_auth.kubeconfig_raw
  filename = "kubeconfig-${var.env_name}"
}

# variables.tf
# 변수를 정의한다.

# Common variables

variable "project_id" {
  type        = string
  description = "project id"
  default     = ""

  validation {
    condition     = length(var.project_id) > 0
    error_message = "The project_id must not be empty."
  }
}

variable "region" {
  type        = string
  description = "cluster region"
  default     = ""

  validation {
    condition     = can(regex("^asia-northeast3", var.region))
    error_message = "The region must start with 'asia-northeast3'."
  }
}

variable "env_name" {
  type        = string
  description = "The environment for the GKE cluster"
  default     = "dev"
}

# Cluster variables


variable "cluster_name" {
  type        = string
  description = "name of cluster"
  default     = ""
}

variable "network" {
  type        = string
  description = "The VPC network"
  default     = "gke-network"
}

variable "zones" {
  type        = list(string)
  description = "to host cluster in"
  default     = ["asia-northeast3-a", "asia-northeast3-b", "asia-northeast3-c"]

  validation {
    condition     = length(var.zones) > 0
    error_message = "At least one zone must be specified."
  }
}

variable "ip_range_pods_name" {
  type        = string
  description = "The secondary ip ranges for pods"
  default     = "subnet-01-pods"
}

variable "ip_range_services_name" {
  type        = string
  description = "The secondary ip ranges for services"
  default     = "subnet-01-services"
}

# 변수를 정의한다. 정의한 변수에 값을 주입하기 위해서는 terraform.tfvars 파일을 이용한다.

# terraform.tfvars
project_id   = "spry-framework-406704"
cluster_name = "k8s-standard-architecture"
region       = "asia-northeast3"

# variables.tf 파일에 정의된 변수에 값을 주입한다. 보통 Variables = Value 형태로 정의한다.

# output.tf
# 리소스에서 생성된 데이터를 출력하는데 사용된다. output을 사용하면 원하는 정보를 개발환경에서도 바로 확인할 수 있다.

output "cluster_id" {
  description = "cluster id"
  value       = module.gke.cluster_id
}

output "cluster_name" {
  description = "cluster name"
  value       = module.gke.name
}

output "ca_certificate" {
  sensitive   = true
  description = "Cluster ca certificate (base64 encoded)"
  value       = module.gke.ca_certificate
}

output "cluster_type" {
  description = "cluster type (regional / zonal)"
  value       = module.gke.type
}

output "cluster_location" {
  description = "Cluster location (region if regional cluster, zone if zonal cluster)"
  value       = module.gke.location
}

output "horizontal_pod_autoscaling_enabled" {
  description = "Whether horizontal pod autoscaling enabled"
  value       = module.gke.horizontal_pod_autoscaling_enabled
}

output "http_load_balancing_enabled" {
  description = "Whether http load balancing enabled"
  value       = module.gke.http_load_balancing_enabled
}

output "master_authorized_networks_config" {
  description = "Networks from which access to master is permitted"
  value       = module.gke.master_authorized_networks_config
}

output "cluster_region" {
  description = "Cluster region"
  value       = module.gke.region
}

output "cluster_zones" {
  description = "List of zones in which the cluster resides"
  value       = module.gke.zones
}

output "cluster_endpoint" {
  sensitive   = true
  description = "Cluster endpoint"
  value       = module.gke.endpoint
}

output "min_master_version" {
  description = "Minimum master kubernetes version"
  value       = module.gke.min_master_version
}

output "logging_service" {
  description = "Logging service used"
  value       = module.gke.logging_service
}

output "monitoring_service" {
  description = "Monitoring service used"
  value       = module.gke.monitoring_service
}

output "master_version" {
  description = "Current master kubernetes version"
  value       = module.gke.master_version
}

output "network_policy_enabled" {
  description = "Whether network policy enabled"
  value       = module.gke.network_policy_enabled
}

output "node_pools_names" {
  description = "List of node pools names"
  value       = module.gke.node_pools_names
}

output "node_pools_versions" {
  description = "Node pool versions by node pool name"
  value       = module.gke.node_pools_versions
}

output "service_account" {
  description = "The service account to default running nodes as if not overridden in node_pools."
  value       = module.gke.service_account
}

7. GKE Cluster 프로비전

파일을 모두 저장한 후, Terraform workspace를 초기화한다. terraform init 명령어를 이용하여 필요한 provider와 plugins를 다운로드한다.

terraform init

terraform plan 명령어를 실행하여 실행 계획을 생성한다.

terraform plan

만들어진 plan이 적절한 것 같아 보이면 계획을 적용한다

terraform apply -auto-approve

생성이 완료되었다! GCP 콘솔을 통해 만들어진 클러스터를 확인한다.

8. kubectl 명령어를 사용하여 클러스터에 접속하기

gcloud 명령어를 사용하여 kubectl이 GKE 클러스터에 접속할 수 있도록 kubectl을 구성한다.

gcloud container clusters get-credentials 클러스터 이름 --region 리전 

오류가 발생하는 경우, Google Kubernetes Engine(GKE) 클러스터에 kubectl을 사용하여 인증하는 데 필요한 gke-gcloud-auth-plugin이 설치되지 않았다는 것이다. 해당 플러그인을 설치하기 위해서는 cmd를 관리자 권한으로 실행한 후 커맨드를 입력한다.

gcloud components install gke-gcloud-auth-plugin
gcloud components list # 설치 확인

kubectl 커맨드를 사용하여 설정이 잘 되었는지 확인한다.

❯ k get node
NAME                                                  STATUS   ROLES    AGE   VERSION
gke-k8s-standard-arc-default-node-poo-c689d9fc-1bcq   Ready    <none>   31m   v1.27.3-gke.100
gke-k8s-standard-arc-default-node-poo-c689d9fc-l8vr   Ready    <none>   31m   v1.27.3-gke.100
gke-k8s-standard-arc-default-node-poo-f4dbcfa0-79g2   Ready    <none>   31m   v1.27.3-gke.100
gke-k8s-standard-arc-default-node-poo-f4dbcfa0-qrwh   Ready    <none>   31m   v1.27.3-gke.100

9. 클러스터 삭제

더 이상 클러스터가 필요하지 않다면, 크레딧을 줄이기 위해 클러스터를 삭제한다.

terraform destroy -auto-approve

10. 오류 정리

클러스터를 생성 및 삭제하면서 경험한 오류 및 참고사항을 정리한다.

1. 서비스 어카운트 미생성 오류

서비스 어카운트를 생성하지 않아서 생긴 오류다....

resource "google_service_account" "default" {
  # google_service_account 리소스의 account_id에는 서비스 계정의 전체 이메일 주소가 아니라 고유 ID 부분만 포함해야 한다.
  account_id   = "k8s-standard-architecture"
  project      = var.project_id
  display_name = "K8s Standard Architecture Service Account"
  description  = "Service account for K8s standard architecture"
}

main.tf에 해당 블럭을 추가하고

  depends_on = [module.vpc, google_service_account.default]

service account에 대한 종속성을 추가하면 해결된다.

2. enable_private_endpoint를 true로 설정했을 때의 오류

enable_private_endpoint = true는 private endpoint를 설정하는 것이 아니라 private_endpoint "만" 접속할 수 있도록 만드는 변수이다. 퍼블릭 엔드포인트도 생성하기 위해서는 enable_private_endpoint를 true가 아니라 false로 설정해야 한다. true로 설정하면 퍼블릭 IP로 접속 자체가 되지 않는다.

enable_private_endpoint (Optional) - When true, the cluster's private endpoint is used as the cluster endpoint and access through the public endpoint is disabled. When false, either endpoint can be used. This field only applies to private clusters, when enable_private_nodes is true.

프라이빗 엔드포인트의 활성화 자체는 private_cluster_config에 의해 관리된다. 이 설정은 클러스터가 프라이빗 모드로 작동할 것인지를 결정한다. private_cluster_config를 true로 설정하면, 클러스터는 프라이빗 네트워크 내에서만 접근 가능한 상태가 된다. 이 설정은 프라이빗 엔드포인트의 사용을 가능하게 하지만, enable_private_endpoint 설정에 따라 퍼블릭 엔드포인트의 사용 여부가 결정된다. enable_private_endpoint는 클러스터가 퍼블릭 엔드포인트를 통한 접근을 허용할지를 결정한다.

1. enable_private_endpoint = true: 이 설정은 클러스터가 프라이빗 엔드포인트를 사용하도록 하며, 퍼블릭 엔드포인트를 통한 접근을 비활성화한다. 즉, 외부 인터넷에서의 직접 접근이 차단된다.

2. enable_private_endpoint = false: 이 설정은 클러스터가 프라이빗 엔드포인트와 퍼블릭 엔드포인트 모두를 사용할 수 있도록 한다. 이 경우, 클러스터는 내부 네트워크와 외부 인터넷 양쪽에서 접근 가능하다.

프라이빗 엔드포인트만으로 접속하게 하고 싶다면, 이와 같이 설정하면 된다.

  # 프라이빗 네트워크를 설정하기 위해서는 마스터 인증 네트워크도 설정해야 한다
  master_authorized_networks = [
    {
      # 쿠버네티스 마스터 엔드포인트에 액세스할 수 있도록 허용하는 cidr block. 
      # 보안을 위해 필요한 곳만 허용하도록 설정하는 것이 좋다.(일반적으로 조직의 네트워크 또는 클러스터를 관리하는 특정 머신의 IP 주소).
      # 예를 들어, 조직 네트워크의 IP 범위가 192.168.0.0/16인 경우, cidr_block = "192.168.0.0/16" 로 변경할 수 있다.
      # 이렇게 하면 192.168.0.0~192.168.255.255 범위의 IP 주소를 가진 머신만 쿠버네티스 마스터 엔드포인트에 액세스할 수 있다. 
      cidr_block   = "0.0.0.0/0"
      display_name = "Allow from everywhere"
    },
  ]

참고 링크

medium GCP 공식 문서 Terraform Registry

코드

backend

name: CI

on:
  push:
    branches:
      - main
env:
  AWS_REGION: ap-northeast-2
  REGISTRY: <id>.dkr.ecr.ap-northeast-2.amazonaws.com
  REPOSITORY: <repo_name>
  IMAGE_TAG: back
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-region: ${{ env.AWS_REGION }}
          aws-access-key-id: ${{ env.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ env.AWS_SECRET_ACCESS_KEY }}

      - name: login to ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build, tag and push docker image to Amazon
        id: build-image
        env:
          ECR_REGISTY: ${{ steps.login-ecr.outputs.registry }}
        run: |
          docker build -t ${{ env.REGISTRY }}/${{env.REPOSITORY}}:${{env.IMAGE_TAG}} .
          docker push ${{ env.REGISTRY}}/${{env.REPOSITORY}}:${{env.IMAGE_TAG}}

frontend

name: CI

on:
  push:
    branches:
      - master
env:
  AWS_REGION: ap-northeast-2
  REGISTRY: <id>.dkr.ecr.ap-northeast-2.amazonaws.com
  REPOSITORY: <repo_name>
  IMAGE_TAG: front
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-region: ${{ env.AWS_REGION }}
          aws-access-key-id: ${{ env.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ env.AWS_SECRET_ACCESS_KEY }}

      - name: login to ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build, tag and push docker image to Amazon
        id: build-image
        env:
          ECR_REGISTY: ${{ steps.login-ecr.outputs.registry }}
        run: |
          docker build -t ${{ env.REGISTRY }}/${{env.REPOSITORY}}:${{env.IMAGE_TAG}} .
          docker push ${{ env.REGISTRY}}/${{env.REPOSITORY}}:${{env.IMAGE_TAG}}

회고

이후 push가 되었는데도 웹페이지에 제대로 반영이 되어있지 않아 살펴보았다. Deployment.yaml의 imagePullPolicy가 제대로 작동하지 않는 문제였다. 공식문서를 살펴보면, tag가 latest일때만 imagePullPolicy가 default로 설정되고, 다른 태그일 경우에는 따로 imagePullPolicy를 always로 설정해 줘야 한다. 설정한 후 웹 페이지에 push된 최근 이미지가 잘 반영되는 것을 확인하였다.

또한, aws의 secret key를 그대로 github의 secret에 저장하면 보안 문제가 발생할 수 있다는 것을 알게 되었는데, 이는 RBAC로 해결 가능한 부분이라고 한다. 나중에 시간이 되면 RBAC를 적용해 볼 예정이다.

그리고 ECR에서 자꾸 untagged가 늘어나 좀 더러워지는 것 같은 면이 있는데, 이것은 버전을 자동으로 바꾸게 하는 것으로 해결 할 수 있는 것으로 보인다. 하지만 태그를 유지하면서 자동으로 이전 버전을 삭제하게는 못 하는 건가? 이 쪽은 더 찾아봐야 할 것 같다.

1. Vagrant를 이용한 가상머신 배포

먼저, Vagrant를 이용하여 가상머신을 생성한다.

Vagrant.configure("2") do |config|
  config.vm.define "control-plane" do |config|
    config.vm.box = "ubuntu/focal64"
      config.vm.provider "virtualbox" do |vb|
        vb.name = "control-plane"
        vb.memory = "2048"
        vb.cpus = 2
      end
      config.vm.hostname = "control-plane"
      config.vm.network "private_network", ip: "192.168.56.11"
  end

  config.vm.define "worker1" do |config|
    config.vm.box = "ubuntu/focal64"
      config.vm.provider "virtualbox" do |vb|
        vb.name = "worker1"
        vb.memory = "1536"
        vb.cpus = 1
      end
      config.vm.hostname = "worker1"
      config.vm.network "private_network", ip: "192.168.56.21"
  end

  config.hostmanager.enabled = true
  config.hostmanager.manage_guest = true

  config.vm.provision "shell", inline: <<-SHELL
    sed -i 's/archive.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list
    sed -i 's/security.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list
    sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config
    systemctl restart ssh
  SHELL

end

컴퓨터의 사양 문제로 worker node를 한 개만 생성하였으므로, worker node의 갯수를 추가하고 싶으면 worker1 아래에 추가하면 된다. 작성한 Vagrantfile을

vagrant up

명령어를 통해 배포하면, VirtualBox에 Master와 Worker Node가 배포되어 있는 것을 확인할 수 있다.

2. control-plane 설정과 kubespray 설치

control-plane에 ssh를 통해 접속하여, key 기반의 인증을 control-plane과 모든 worker node에 설정해줘야 한다.

그 전에, /etc/hosts에서 각각의 ip를 등록해 주자.

vi /etc/hosts

127.0.0.1 localhost
127.0.1.1 worker2
192.168.56.11 control-plane
192.168.56.21 worker1

ssh-keygen
ssh-copy-id worker1 #worker node는 worker node에서 실행해야 한다.

이후 git과 python을 설치해 준다.

sudo apt-get update
sudo apt install python3 python3-pip
sudo apt install git

kubespray를 git clone으로 설치하고, pip로 패키지를 설치한다.

git clone --single-branch --branch=release-2.19 https://github.com/kubernetes-sigs/kubespray.git
cd kubespray
sudo pip3 install -r requirements.txt

3. Ansible 설정

먼저, mycluster 폴더를 수정해서 사용한다.

cp -rfp inventory/sample/ inventory/mycluster
vi inventory/mycluster/inventory.ini

[all]
worker1 ansible_host=192.168.56.21  ip=192.168.56.21 ansible_sudo_pass='vagrant'
control-plane ansible_host=192.168.56.11  ip=192.168.56.11

[all:vars]
ansible_python_interpreter=/usr/bin/python3

[kube_control_plane]
control-plane

[etcd]
control-plane

[kube_node]
worker1

[calico_rr]

[k8s_cluster:children]
kube_control_plane
kube_node
calico_rr

이후, addons.yaml 파일을 수정해 준다.

root@control-plane:~/kubespray/inventory/mycluster/group_vars/k8s_cluster# ls
addons.yml          k8s-net-canal.yml    k8s-net-kube-ovn.yml     k8s-net-weave.yml
k8s-cluster.yml     k8s-net-cilium.yml   k8s-net-kube-router.yml
k8s-net-calico.yml  k8s-net-flannel.yml  k8s-net-macvlan.yml

ingress_nginx_enabled: true
metrics_server_enabled: true
metallb_enabled: true
metallb_ip_range:
  - "192.168.56.50-192.168.56.99"
metallb_protocol: "layer2"

k8s-cluster.yml 에서 해당 줄을 수정한다.

kube_proxy_strict_arp: true

마지막으로 쿠버네티스 클러스터를 배포(오랜 시간이 걸린다) 하고, vagrant 사용자에 kubectl 권한을 부여한다.

ansible-playbook -i inventory/mycluster/inventory.ini -b cluster.yml -v
mkdir ~/.kube
sudo cp /etc/kubernetes/admin.conf ~/.kube/config
sudo chown $USER:$USER ~/.kube/config

오류

Vagrant 설치 과정에서 문제가 있었는지, IP가 잡히지 않아 쿠버네티스 배포 과정에서 문제가 있었다. 이는 수동으로 IP를 설정해서 해결하였다. (ubuntu 20.04 기준)

/etc/netplan/의 yaml 파일을 dhcp에서 고정 IP로 변경해 준다.

network:
  ethernets:
    enp0s8:
      addresses:
        - 192.168.56.21/24
      gateway4: 192.168.0.1
      nameservers:
        addresses:
            - 8.8.8.8
  version: 2

1. docker build

docker build . -t <id>.dkr.ecr.<region>.amazonaws.com/<ecr repository name>:<tag>

ID에는 aws 12자짜리 account id(aws sts get-caller-identity의 account) region에는 region(한국이니까 보통 ap-northeast-2) ecr repository name에는 콘솔에서 생성한 repository name tag에는 달고싶은 tag를 달면 된다.

2. ecr 로그인

aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin <id>.dkr.ecr.ap-northeast-2.amazonaws.com

aws configure로 로그인 되어 있으면 안 해도 되는줄 알고 하지 않았었는데 오류가 떴다. 그래서 이걸 적용해보고 다시 해봤더니 오류가 발생하지 않았다 ㅎ.. 암튼?? 로그인에 성공하면 login succeed라고 나온다.

3. docker push

docker push <id>.dkr.ecr.<region>.amazonaws.com/<ecr repository name>:<tag>

성공적으로 실행되면

0987654321ba: Pushed
1234567890ab: Pushed
...

이런식으로 뜬다. 떨어질 때 까지 기다리면 ECR 콘솔에서 확인할 수 있다.

containers:
      - name: name
        image: <id>.dkr.ecr.<region>.amazonaws.com/<ecr repository name>:<tag>

deployment.yaml에는 이렇게 작성하면 된다.

Front

import React, { useState, useEffect } from "react";

function App() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetch("/users")
      .then((response) => response.json())
      .then((data) => setUsers(data));
  }, []);

  return (
    <div>
      <h1>Users</h1>
      <ul>
        {users.map((user) => (
          <li key={user.id}>{user.name}</li>
        ))}
      </ul>
    </div>
  );
}

export default App;

Back

from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware
import mysql.connector
import os

app = FastAPI()

origins = [
    "http://localhost"
    "http://localhost:3000"
]

app.add_middleware(
    CORSMiddleware,
    allow_origins=origins,
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

db_address = os.environ['DB_ADDRESS']
db_port = os.environ['DB_PORT']
db_name = os.environ['DB_NAME']
db_password = os.environ['DB_PASSWORD']
db_dbname = os.environ['DB_DBNAME']


@app.get("/")
def read_root():
    return {"Hello": "World"}


@app.get("/users")
def read_users():
    mydb = mysql.connector.connect(
        host=db_address,
        port=db_port,
        user=db_name,
        password=db_password,
        database=db_dbname
    )

    cursor = mydb.cursor()
    cursor.excute("SELECT * FROM users")
    result = cursor.fetchall()
    return result

FROM python:3.9-slim-buster

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

CMD uvicorn --host=0.0.0.0 --port 8080 main:app

apiVersion: apps/v1
kind: Deployment
metadata:
  name: book-deploy
spec:
  selector:
    matchLabels:
      tier: back
  replicas: 2
  template:
    metadata:
      labels:
        tier: back
    spec:
      containers:
      - name: book-back
        image: <Image>
        resources:
          requests:
            memory: "128Mi"
            cpu: "500m"            
          limits:
            memory: "128Mi"
            cpu: "500m"
        ports:
        - containerPort: 8080
        env:
          - name: DB_ADDRESS
            valueFrom:
              secretKeyRef:
                name: web-rds-secret
                key: address
          - name: DB_PORT
            valueFrom:
              secretKeyRef:
                name: web-rds-secret
                key: port
          - name: DB_NAME
            valueFrom:
              secretKeyRef:
                name: web-rds-secret
                key: name
          - name: DB_PASSWORD
            valueFrom:
              secretKeyRef:
                name: web-rds-secret
                key: password
          - name: DB_DBNAME
            valueFrom:
              secretKeyRef:
                name: web-rds-secret
                key: dbname
        volumeMounts:
          - mountPath: /book_db
            name: efs-volume
            resources:
              requests:
                cpu: "250m"
                memory: "64Mi"
              limits:
                cpu: "250m"
                memory: "64Mi"
        volumes:
          - name: efs-volume
            persistentVolumeClaim:
              claimName: efs-pvc

그리고 EFS 를 설정하였다. EFS가 Multi AZ를 지원하기 때문이다. 처음에 EBS로 하지 말고 클러스터를 만들 때 부터 EFS로 하는게 맞았겠지만, 그 때는 이 차이점을 몰랐어서.. 따로 세팅해 주었다.

공식 문서 를 참고해서 진행하였다.

curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/docs/iam-policy-example.json

aws iam create-policy \
    --policy-name AmazonEKS_EFS_CSI_Driver_Policy \
    --policy-document file://iam-policy-example.json

eksctl create iamserviceaccount \
    --cluster my-cluster \
    --namespace kube-system \
    --name efs-csi-controller-sa \
    --attach-policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_EFS_CSI_Driver_Policy \
    --approve \
    --region region-code


helm repo add aws-efs-csi-driver https://kubernetes-sigs.github.io/aws-efs-csi-driver/
helm repo update

helm upgrade -i aws-efs-csi-driver aws-efs-csi-driver/aws-efs-csi-driver \
    --namespace kube-system \
    --set image.repository=602401143452.dkr.ecr.region-code.amazonaws.com/eks/aws-efs-csi-driver \
    --set controller.serviceAccount.create=false \
    --set controller.serviceAccount.name=efs-csi-controller-sa

image.repository의 컨테이너 주소는 링크되어있는 문서를 통해 바꿨다. 나는 ap-northeast-2를 사용하고 있으니 602401143452.dkr.ecr.ap-northeast-2.amazonaws.com 로 사용하면 된다.

vpc_id=$(aws eks describe-cluster \
    --name my-cluster \
    --query "cluster.resourcesVpcConfig.vpcId" \
    --output text)

cidr_range=$(aws ec2 describe-vpcs \
    --vpc-ids $vpc_id \
    --query "Vpcs[].CidrBlock" \
    --output text \
    --region region-code)

security_group_id=$(aws ec2 create-security-group \
    --group-name MyEfsSecurityGroup \
    --description "My EFS security group" \
    --vpc-id $vpc_id \
    --output text)

aws ec2 authorize-security-group-ingress \
    --group-id $security_group_id \
    --protocol tcp \
    --port 2049 \
    --cidr $cidr_range

file_system_id=$(aws efs create-file-system \
    --region region-code \
    --performance-mode generalPurpose \
    --query 'FileSystemId' \
    --output text)

kubectl get nodes

k get nodes를 통해 노드의 주소를 얻었다면,

aws ec2 describe-subnets \
    --filters "Name=vpc-id,Values=$vpc_id" \
    --query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
    --output table

해당 명령어를 사용하여 노드의 IP주소가 속해 있는 서브넷 아이디를

aws efs create-mount-target \
    --file-system-id $file_system_id \
    --subnet-id subnet-EXAMPLEe2ba886490 \
    --security-groups $security_group_id

의 subnet-id 부분에 넣으면 된다. 나는 노드가 두 개이므로 두 번 진행하였다.

그리고 스토리지클래스와 PVC도 작성을 완료하였다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-pvc
spec:
  resources:
    requests:
      storage: 1Gi
  accessModes:
    - ReadWriteMany
  storageClassName: efs-sc

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-046fc26e91f93b2c1
  directoryPerms: "700"

내일은 오전에 테스트 웹 코드 작성을 완료하고, github actions를 이용한 CI까지 해볼 예정이다. 물론 웹과 RDS의 연동이 잘.. 된다면의 말이지만...

이 것 외에도 테스트용 프론트엔드와 백엔드 파일의 제작을 시작하였다. 간단하게 DB를 사용할 수 있는 정도로만 만들어서, DB와 연결이 잘 되어 있는지, 접속은 잘 할 수 있는지를 확인해 볼 것이다. 또한 ArgoCD를 이용한 배포와 Github Workflows를 이용한 CI 작업 역시 시작해야 한다.

웹 페이지가 완성되기 전에 인프라를 완료해서 완성되면 배포만 하면 할 수 있도록 하고 싶은데, 경험상 이 배포할 때 오류가 정말 많이 터지기 때문에... 그것을 수정할 시간을 벌기 위해서라도 최대한 빨리 인프라 작업을 끝내야 할 것 같다. 그리고 logging쪽에도 따로 하고 싶은게 있으니 그것을 위해서라도 내가 맡은 인프라 구축 작업을 최대한 빠르게 끝내는 것이 중요하다!

AWSTemplateFormatVersion: 2010-09-09

Resources:
  PrivateSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: vpc-049fd765256442cd7
      CidrBlock: 192.168.192.0/19
      AvailabilityZone: ap-northeast-2a

  PrivateSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: vpc-049fd765256442cd7
      CidrBlock: 192.168.230.0/19
      AvailabilityZone: ap-northeast-2b

  DBSubnetGroup:
    Type: AWS::RDS::DBSubnetGroup
    Properties:
      DBSubnetGroupDescription: subnet group for rds
      DBSubnetGroupName: web-db-subnet-group
      SubnetIds:
        - !Ref PrivateSubnet1
        - !Ref PrivateSubnet2

  DBInstance:
    Type: AWS::RDS::DBInstance
    DependsOn: DBSubnetGroup
    Properties:
      DBName: webDB
      DBInstanceIdentifier: web-db
      AllocatedStorage: 20
      DBInstanceClass: db.t3.medium
      Engine: mysql
      MasterUsername: root
      MasterUserPassword: rootpassword1
      VPCSecurityGroups:
        - sg-0910431509fba56a0
        - sg-0c8c916ce0943aa26
        - sg-0bc951ad09afb9df3
      DBSubnetGroupName: !Ref DBSubnetGroup
      MultiAZ: true
      PubliclyAccessible: true
      StorageType: gp3

이 간단한 걸 구성하는데 오류가 얼마나 터진 건지..

오류 목록은 다음과 같았다.

1. Error parsing parameter '--template-body':
   Unable to load paramfile (CreateRDS.yaml), text contents could not be decoded.
   If this is a binary file, please use the fileb:// prefix instead of the file:// prefix.

이건.. 잘 모르겠다...? parsing할 수 없어서 생긴 에러라고 하는데, 좀 있다가 다시 하니까 에러가 뜨지 않았다. 저걸 생성했을 때 팀원분이 잠깐 eks 클러스터를 지우셨어서 오류가 뜬 것 같기도 하다.

aws cloudformation validate-template --template-body file://test.yml

찾아보니까 이렇게 template의 오류를 체크할 수 있는 것 같다.

2. Properties validation failed for resource DBInstance with message: #
   /DBName: failed validation constraint for keyword [pattern]

DBName이 patterns에 부합하지 않아서 생긴 문제이다. 찾아보니 DBName은

        "DBName": {
            "Default": "mydb",
            "Description": "My database",
            "Type": "String",
            "MinLength": "1",
            "MaxLength": "64",
            "AllowedPattern": "[a-zA-Z][a-zA-Z0-9]*",
            "ConstraintDescription": "Must begin with a letter and contain onlyalphanumeric characters."
        },

으로 정의되어 있어서 AllowedPattern대로 다시 이름을 바꾸어 오류를 해결했다.

3.

Resource handler returned message: "DBSubnetGroup 'web-db-subnet-group' not found.
(Service: Rds, Status Code: 404, Request ID: 75f008d5-014c-4d8d-a858-fb42fe181c67)"
(RequestToken: a50db435-d8c4-5b33-74eb-383e386f1c5d, HandlerErrorCode: NotFound)

DBInstance가 생성될 때 DBSubnetGroup이 생성되지 않아서 생긴 문제이다. yaml파일에 입력되어 있는 순서대로 생성되는 줄 알았는데, 역시 완벽하지는 않은 것 같다. 이미 subnetgroup은 subnet에 종속되어 있어서 마지막에 생기기도 하고.. 그래서 DBInstance를 DBSubnetGroup에 종속시키려고 시도해보았다.

4.

Properties validation failed for resource DBInstance with message:#
: extraneous key [DependsOn] is not permitted

시도의 결과로 오류가 났는데, properties 안에 들어가는게 아니라 dbinstance 바로 아래에 들어가야 하는 것이었다. properties 밖으로 빼 줘서 오류를 해결했다. + 종속도 확인했다.

5.

Resource handler returned message: "Invalid storage size for
engine name mysql and storage type gp2: 1
(Service: Rds, Status Code: 400, Request ID: 05ac5cc6-6854-4321-8f9b-f9bc16beda25)"
(RequestToken: df385daa-3347-c849-f7d3-4cccb5c536d8, HandlerErrorCode: InvalidRequest)

gp2타입의 MySQL 용량은 최소 5GiB여야 한다고 한다. 근데 생각해보니 gp3가 더 나을 것 같아서 gp3로 변경했다. 그랬더니 다시 오류가 떴고, 찾아보니 gp3의 경우 최소 용량이 GiB라고 한다. 그걸로 수정해서 오류를 해결하였다.

6.

Resource handler returned message: "The DB subnet group doesn't
meet Availability Zone (AZ) coverage requirement.
Current AZ coverage: ap-northeast-2b. Add subnets to cover at least 2 AZs. 
(Service: Rds, Status Code: 400, Request ID: 3b3903e0-0617-4e57-984a-aedbf7d656e6)" 
(RequestToken: 71b86e8e-bd79-5159-3d96-08053892da99, HandlerErrorCode: InvalidRequest)

MultiAZ를 true 로 설정했을 때, 서브넷이 AZ의 범위 요구 사항을 충족하지 않는다는 에러이다. 여기서 오늘 시간이 끝나서 클러스터가 내려가 멈춰 있는 상태인데, 내일 서브넷의 IP를 바꿔가면서 확인해 볼 예정이다.

aws ec2 describe-subnets --filters "Name=vpc-id,Values=<VPC-ID>"

명령어를 사용하면 확인해 볼 수 있다고 하므로, 해당 명령어를 사용해볼 것이다.

오늘 만난 오류의 목록은 다음과 같았다. 솔직히 다음엔 무슨 오류가 뜰 지 모르겠다.. 하지만 열심히 찾아보다 보면 다 해결책이 있어서 다행인 것 같다. 내일 RDS와 EKS 연동까지 마무리되면 좋겠다.

내일은 RDS 스택을 일단 마무리하고, Fast API와 React를 이용해 테스트 웹 코드를 만들고 Deploy해 봐야겠다. 또, 여럿이서 작업을 하다 보니 폴더가 충돌하는 경우가 생겨서 폴더 트리를 만들어 봐야할 것 같다. 예전에는 이 트리를 굳이 만들어야 하나 생각했는데, 안 만들고 작업하니까 꼭 있어야 할 것 같다..

aws eks update-kubeconfig --region <region> --name <cluster name>

rds cloudformation stack을 만들었다. clusterconfig가 아니라 cloudformation이라서 많이 고민 했었는데, 여러가지를 보고 생각해본 결과로는 이렇게 만들면 될 것 같았다.

AWSTemplateFormatVersion: 2010-09-09

Resources:
  PrivateSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: <VPC ID>
      CidrBlock: <Private Subnet 1 CIDR>

  PrivateSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: <VPC ID>
      CidrBlock: <Private Subnet 2 CIDR>

  DBSubnetGroup:
    Type: AWS::RDS::DBSubnetGroup
    Properties:
      DBSubnetGroupDescription: subnet group for rds
      DBSubnetGroupName: web-db-subnet-group
      SubnetIds:
        - !Ref PrivateSubnet1 #원래오류남
        - !Ref PrivateSubnet2

  DBInstance:
    Type: AWS::RDS::DBInstance
    Properties:
      DBName: web-db
      DBInstanceIdentifier: web-db
      AvailabilityZone: ap-northeast-2
      AllocatedStorage: 1
      DBInstanceClass: db.t3.medium
      Engine: mysql
      MasterUsername: 
      MasterUserPassword:
      VPCSecurityGroups:
        - vpc-sg-id #eks 클러스터와 같은 값을 입력하면 EKS클러스터가 속해있는 보안그룹과 같은 곳에 속한다.
      DBSubnetGroupName: web-db-subnet-group
      MultiAZ: true

VSCode의 yaml파일에서는 !Ref 부분이 오류가 있다고 나왔지만, 공식 문서를 살펴 보니 저렇게 쓰는게 맞고 yaml 파일 형식이라서 VSCode에서 오류가 나는 것 같다. 다음주에는 rds를 올리고 팀원 분들에게 액세스 가능한지를 물어봐야 할 것 같다. + 지금 생각해 보니 웹 개발 하시는 분들이 rds를 사용하셔야 하는데 아마 퍼블릭 액세스를 허용해두어야 할 듯 싶다..? 퍼블릭 서브넷을 하나 만들고 개발 완료하면 없애던가 배스천 호스트를 구현하던가 할 듯...

그것 말고도 전에 만들어두었던 HPA나 PVC같은 yaml 파일들을 미리 github에 push해 두었다.

별거 없음.. 착수보고 완성하고 eks yaml 파일 만들었다. 끝!!

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: book-network
  region: ap-northeast-2
  version: "1.24" #쿠버네티스의 버전

# AZ(가용 영역), 설정하지 않으면 3개의 가용 영역에서 랜덤으로 생성된다
availabilityZones: ["ap-northeast-2a", "ap-northeast-2b",  "ap-northeast-2c"]

# IAM OIDC & Service Account
iam: #AWS IAM
  withOIDC: true #Open ID Connection
  serviceAccounts: #미리 생성할 서비스 어카운트
    - metadata: #인그레스용
        name: aws-load-balancer-controller #계정
        namespace: kube-system #네임스페이스
      wellKnownPolicies: #AWS Role, SA에 역할을 붙인다
        awsLoadBalancerController: true
    - metadata: #볼륨용
        name: ebs-csi-controller-sa
        namespace: kube-system
      wellKnownPolicies: #AWS Role, SA에 역할을 붙인다
        ebsCSIController: true
    - metadata: #클러스터 오토스케일러용
        name: cluster-autoscaler
        namespace: kube-system
      wellKnownPolicies: #AWS , SA에 역할을 붙인다
        autoScaler: true

# Managed Node Groups, EKS는 관리형이므로 컨트롤플레인을 AWS에서 관리해 준다.
managedNodeGroups:
  # On-Demand Instance
  - name: mynodes-t3
    instanceType: t3.medium #인스턴스 타입
    minSize: 1 #최소 용량
    desiredCapacity: 2 #기본 용량
    maxSize: 3 #최대 용량
    privateNetworking: true #프라이빗 네트워크로 구성
    #ssh:
      #allow: true
      #publicKeyPath: ./keypair/myeks.pub #프라이빗 네트워크에 있으므로 굳이?
    availabilityZones: ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c"] #가용 영역
    iam: #역할들을 ec2 인스턴스에도 세팅해준다.
      withAddonPolicies:
        autoScaler: true
        albIngress: true
        cloudWatch: true
        ebs: true 
        imageBuilder: true
        externalDNS: true
        certManager: true

# CloudWatch Logging
cloudWatch: #컨트롤플레인 로깅
  clusterLogging:
    enableTypes: ["*"] #모든 로그를 cloudwatch에 담는다.

생각해보니 SQL용 role도 부여해야 할 것 같다,, 참고 아침에 일어나서 수정하기로.. 다시 보니까 수정할거 많은 듯

aws eks describe-cluster --name book-network --region ap-northeast-2 --query cluster.resourcesVpcConfig

내일 할 것

생각해보니 aws sql을 인프라쪽에서 파일을 만들어서 웹 쪽에 넘겨줘야 하는 것 같아서... 그거 말하고 DB부터 만들 예정. 그러면 순서는 이렇게 되는 것 같다.

0. cluster 파일 수정하기
1. DB yaml 파일 만들기
2. CI / CD 파이프라인 생성
3. 로깅 생성
4. 파이프라인 생성