[MSA] 12. Kubernates 구조, AWS EC2

엔코아 플레이데이터(Encore Playdata) Backend 2기 백엔드 개발 부트캠프 (playdata.io)

백엔드 개발 부트캠프

---

1. Kubernates 구조

쿠버네티스란?

쿠버네티스는 Container Orchestration 도구로, 직접 명령어를 전부 작성하는 것 보단 yaml 파일을 사용해 여러 명령어를 실행할 수 있다. 

 

1. 구성

구성 요소

쿠버네티스의 master node 와 worker node를 합쳐 클러스터라고 하는데, 

master node는 따로 컨테이너를 실행하지 않고, 오직 클러스터를 관리하는 역할만 한다.  때문에 필요한 어플리케이션은 worker node에서 실행하게 된다.

# master node 구성요소
1. kube-apiserver 
외부와 통신하는 프로세스를 담당하고, kubectl 명령어를 통해 실행한다.

2. kube-controller-manager
쿠버네티스에서 컨트롤러는 클러스터의 상태를 관찰하여, 필요한 경우에 생성 및 변경을 요청한다.
kube-controller-manager는 이 컨트롤러를 통합, 관리, 실행하는 매니저이다.

3. kube-scheduler
pod를 worker node에 할당하는 역할을 담당한다.
이때, 어느 worker node에 pod가 생길지는 알 수가 없다.

4. etcd
클러스터 관련 정보를 관리하는 데이터베이스로, 리소스 단위로 작성되는 메니페스트 파일도 이곳에 저장된다.

# worker node 구성요소
1. kube-proxy
네트워크 통신의 라우터 매커니즘이다.

2. kube-let
master node에 있는 kube-scheduler와 연동해서 worker-node에 pod를 배치 및 실행한다.
실행중인 pod의 상태를 정기적으로 모니터링하여 결과를 kube-scheduler에 알려준다.

3. cluster
가상 네트워크 드라이버 (CNI)를 사용하여, 여러 컴퓨터를 묶는다.
이를 위해 Calico나, Flannel을 사용한다.

2. Manifest 파일

Manifest 파일

 

 

manifest 파일은 리소스 단위로 작성하고, 작성 후 etcd에 저장된다. manifest 파일의 구성 예시는 다음과 같다.

1. apiVersion
API 그룹 유형

2. kind
리소스 유형

3. metadata-name
리소스 이름

4. spec
리소스 내용

5. spec-containers
컨테이너 구성

6. spec-containers-name 
컨테이너 이름

7. spec-containers-image
이미지 이름

8. spec-containers-ports-containerPort 
포트설정

9. spec-containers-name / image / command / args 
컨테이너 실행 시 마지막에 실행되는 명령어

3. kubectl

kubectl은 쿠버네티스에 명령을 내리는 역할을 수행한다. 통상적으로 api 서버와 주로 통신을 하고, 해당 명령어를 마스터 노드에 구성한다.

kubectl

4. 서비스

쿠버네티스의 서비스는 pod를 모아놓은 것을 의미하고, 요청을 배분하는 로드밸런서 역할을 담당한다.

서비스

5. ReplicaSet

ReplicaSet

replica란, 레플리카 셋이 관리하는 동일한 구성의 파드를 의미한다. 이를 통해 replicaset은 파드의 수를 관리해준다.

즉, 레플리카셋이 파드의 수를 관리하기 때문에 중간에 실행중인 파드 (컨테이너)가 에러나서 다운되면 레플리카셋이 복제품을 갖다놔 시스템을 유지한다.

 

5. deployment

deployment

deployment는 레플리카셋을 관리한다. 즉, 파드를 생성 할 때 deployment로 감싸 생성한다면 해당 파드의 복제품을 만들 수 있게 된다.

 

6. pod

pod

쿠버네티스의 기본 철학은 pod 하나에 하나의 container를 실행하는 것을 원칙으로 한다. 

하지만 실제로 전부 원칙대로 하지는 않고, 상황에 따라 유동적으로 개발을 진행하는 편이다.

 

또한, pod는 Self-Healing이라는 자동 복구 기능을 통해 제대로 작동하지 않는 컨테이너를 다시 시작하거나 교체해 pod가 정상적으로 작동하게 한다.

 

7. 생성 명령어

1. create
명령 실행 가능
파일 실행 가능
변경 불가
실행 편의성 좋음
기능 유지 지원

2. run
명령 실행 제한적
파일 실행 불가
변경 불가
실행 편의성 좋은 편
기능 유지 제한적

3. apply
명령 실행 불가
파일 실행 가능
변경 가능
실행 편의성 좋음
기능 유지 다양하게 지원

---

2. deployment를 통한 파드 생성

# 파드 생성 시 deployment로 감싸서 생성
kubectl create deployment dpy-nginx --image=nginx

# dpy-nginx 파드의 복제품을 2개로 설정
kubectl scale deployment dpy-nginx --replicas=2

 # dpy-nginx 삭제, 생성 시 deployment로 감쌌기 때문에 deployment를 삭제하면 된다.
 kubectl delete deployment dpy-nginx

---

3. 외부 파일 설정정보를 통한 pod 실행

# scp 명령어를 통해 파일을 복사해온다.
scp k8s@192.168.56.10:/home/k8s/config/echo-hname.yaml ./

# scp ?
secure copy의 줄임말로 ssh를 이용하여 네트워크로 연결된 호스트간에 파일을 주고받는 명령어

원격지에 있는 파일과 디렉터리를 보내거나 가져올 때 사용하는 파일 전송 프로토콜로,
ssh와 동일한 22번 포트와 identity file을 사용해서 파일을 송수신하기 때문에 안정된 프로토콜이다.

# 가져온 파일을 통해 파드 생성
kubectl create -f ./echo-hname.yaml

외부 파일 복사해오기

# 현재 실행 중인 pod 확인
kubectl get pods -o wide

# w1-k8s 워커노드로 접속
ssh w1-k8s

# 실행중인 echo-hname 컨테이너 종료
docker stop [컨테이너 ID]

이렇게 종료시켜도 쿠버네티스에서 다시 컨테이너를 띄워준다.

# master node로 돌아오기
exit

# 현재 실행 중인 pod 재확인
kubectl get pods -o wide

재확인 시 pod의 restarts 수가 늘어있는 것을 확인할 수 있다.
왜냐하면, docker stop 으로 컨테이너를 종료를 시키긴했지만 쿠버네티스가 바로 다시 실행시켰기 때문이다.

echo-hname-7894b67f-fqqt9의 restarts가 2로 늘은 것을 확인할 수 있다.

---

4. AWS EC2 접속

# 인스턴스 실행

# ip 설정
AWS 인스턴스의 public ip를 작성한다.

# key 설정
1. SSH - Auth - Credentials
2. private key file for authentication 에 가지고 있는 key 파일 등록

# EC2 로그인
ec2-user

---

5. AWS 내 MariaDB 설치

# EC2 내에 MariaDB 설치
sudo dnf install mariadb105-server

# mariaDB를 데몬으로 등록, 매번 키지 않게 한다.
# 해당 설정을 하지 않으면 systemctl start mariadb 명령어를 통해 매번 켜야한다.
sudo systemctl enable --now mariadb

# mariaDB가 실행중인 것 확인
sudo systemctl status mariadb

# 권한 설정을 하기 위한 secure install
sudo mysql_secure_installation

# 방화벽 설정
보안 그룹 - 인바운드 규칙 편집

# mysql 환경설정 디렉토리 접근
cd /etc/my.cnf.d/

# mysql 접속 및 user 생성
mysql -uroot -p1234
create user 'root'@'%' identified by '1234'

# 권한 설정 및 적용
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
flush privileges;

# 한글을 쓰기 위한 encoding 설정
sudo vim mariadb-server.cnf

# 변경한 설정 저장을 위한 db 재시작
sudo systemctl restart mariadb

---

6. 59일차 후기

쿠버네티스는 컨테이너 관리를 최대한 자동화하기 위해 여러 기능을 제공한다.

실행중인 컨테이너가 모종의 이유로 에러가 생겼을 때, 클라이언트는 해당 서비스를 에러가 난 것을 몰라야한다.

즉, 에러가 난 컨테이너를 종료 후 다시 실행해 정상적으로 되돌리는 작업이 필요하다.

 

이를 과거 방식에선 개발자가 직접 컨테이너를 내렸다가 다시 기동하는 작업을 했지만, 쿠버네티스는 deployment 를 활용해 컨테이너의 복제품들을 만들어 기동중인 컨테이너에 에러가 생겼다면, 자동으로 해당 컨테이너의 복제품으로 대체해버린다.

이러한 기능들이 있기 때문에, 서비스 개발 이후 유지보수를 원활하게 하려면 쿠버네티스에 관해 좀 더 깊이 알면 많은 도움이 될 것 같다는 생각이 들었다.