[kubernetes] 쿠버네티스의 오브젝트와 볼륨 (주로 볼륨의 관점에서)

vinca·2023년 10월 31일
0

☸️ kubernetes

목록 보기
5/35
post-thumbnail

쿠버네티스의 오브젝트

요소들이 상태를 가지고 있는 것을 오브젝트라고 한다.

사실 여기서 kubelet은 상태를 가지고 있다고 볼 수 없다.

상태란?

오브젝트는 추구하는(원하는) 상태를 기술해 둔 것이다.
상태란 이러한 오브젝트가 추구하는 상황이 된다.

오브젝트가 추구하는 상태는 어떻게 되어있을까? 코드로 다음과 같이 기술되어있다.

추구하는 상태

이처럼 추구하는 상태의 코드가 이렇다면, 현재 상태는 어떻게 코드로 기록되어 있을까?

현재 상태

현재 상태 또한, 추구하는 상태와 같은 상황이므로 같은 replicas의 값을 가지는 것을 알 수 있다.

spec(선언)과 status(상태)확인

현재 선언과 상태의 replicas값이 둘 다 9로 되어있는 것을 확인할 수 있다.
선언이 변경되면 현재 추구하는 상태가 변하게 되는지 확인해보도록 하자.

선언(spec)의 replicas값을 9 ➡ 3으로 변경한다.

선언이 변경됨으로써, 추구하는 상태로의 변경을 위해 현재 상태가 9개에서 3개로 줄어드는 것을 확인할 수 있다.

쿠버네티스의 기본 오브젝트

오브젝트란, 추구하는 선언과 현재 상태를 기술해 놓은 "요소"을 칭한다.

예를 들어 쿠버네티스의 서비스와 파드 모두 선언과 상태가 기술되어 있으므로 이를 오브젝트라고 칭할 수 있다.
(쿠버네티스 서비스 오브젝트, 쿠버네티스 파드 오브젝트 등..)

이제 어떤 기본 오브젝트가 있는지 살펴보자.
총 4개가 기본적으로 있다.

1. 파드

파드는추구하는 상태와 현재 상태를 가지고 있다.

2.서비스

서비스 또한 추구하는 상태와 현재 상태를 가지고 있다.

3.네임스페이스

default 네임스페이스, kube-system 네임스페이스 등
이 또한, 오브젝트이다.

4.볼륨

볼륨은 영속적인 데이터를 보존하기 위해서 존재한다.
영.속.적.인에 대해서 잘 기억하고 있자. (추후 나온다)

왜 이런 것이 필요할까?

쿠버네티스에서 취급하는 파드는 상황에 따라서 자유롭게 삭제되고, 생성되고, 이 과정에서 이동(삭제 후 다른 노드에서 생성)되게 된다.
(이를 비유할 때, 가축과 같다고 비유했었다.)

이처럼 파드가 계속 삭제, 생성, 이동 과정을 거치면 중요한 데이터가 계속 저장이 안되는 상황이 발생할 수 있다.
따라서 이러한 문제를 해결하기 위한 것이 바로 볼륨이다.

🎈 볼륨 실습

이러한 볼륨을 사용하기 위해서는, 현재의 워커노드 3개가 같이 바라볼 수 있는 공간이 필요하다.

이러한 공간을 제일 쉽게 구현 가능한 것은 NFS 서버이다.
NFS 서버란 네트워크-파일-시스템으로 모두 다 같이 쓸 수 있는 볼륨을 만들 수 있다.

미리짜둔 코드를 이용해서 NFS 시스템을 만들어보자.

워커노드 3개가 전부 바라볼 수 있는 192.168.1.0 번대로 모두가 들어올 수 있도록 nfs_shared가 생성되었다.

이제, 볼륨이 있는 파드를 생성해보자!
다음 yaml 생성 파일을 cat으로 뜯어서 확인해보자.

위와 파드를 생성할 때 파드에 볼륨이 함께 생성되도록 하고있다.
이를 통해 파드 내의 모든 컨테이너에서 해당 볼륨에 접근할 수 있다.

📰 소스코드 설명

먼저 volumes 섹션에서는 볼륨의 이름과 위치를 정의한다.

nfs-vol이라는 이름의 볼륨을 정의하고, NFS 서버의 위치(192.168.1.10)와 경로(/nfs_shared/log)를 통해서 볼륨 데이터를 가져올 수 있도록 하였다.

(NFS 서버에 볼륨이 있으니, NFS서버에서 볼륨 데이터를 가져오는 것이다.)

이후, 이를 컨테이너에서 접근하기 위해서 dpy-chk-log 컨테이너 내부의 /audit 내부 경로를 통해 nfs-vol이라는 이름의 볼륨과 연결(마운트)하여 데이터를 가져올 수 있도록 하였다.

😮 이로써 컨테이너는 해당 위치에에 있는 볼륨에 데이터를 읽고 쓸 수 있다!

⚙ 볼륨 실습 (접속기록 저장)

접속기록을 저장하는 파드를 이용해서 볼륨을 이용해보자!

dpy-chk-log.yaml

접속이 일어나면 /audit 경로. 즉, 볼륨과 마운트 된 경로에다가 저장하는 역할을 한다.
(로그파일을 마운트 된 볼륨에 저장되도록 하는 것!)

접속기록을 남겨보자.

curl 172.16.221.153
[결과] pod_n: dpy-chk-log-655668ffb8-5n4p5 | ip_dest: 172.16.221.153

이제 파드에 접속해서 확인해보자.

kubectl exec dpy-chk-log-655668ffb8-5n4p5 -it -- /bin/bash

cat audit/audit_dpy-chk-log-655668ffb8-5n4p5.log

/audit위치에 접속기록이 잘 생성되어 남아있는 것을 확인할 수 있다.

💎 볼륨의 영속성

볼륨은 영속적이라고 했다. 그럼 파드를 지우고 다시 만들어도 해당 로그가 계속 존재할까?

다음과 같이 깔끔하게 지우고,

다시 생성해보자.

그렇다. 지우고 다시 생성했으므로 파드의 이름은 완전히 달라졌지만, 파드에 접속해보면 여전히 audit 디렉토리가 있고, 로그파일이 남아있는 것을 확인할 수 있다!

이것이 바로 볼륨의 영속성이다.

⛳ 볼륨의 생성 위치

볼륨을 생성할 때, 가장 쉽게 생성할 수 있는 것이 바로 NFS라고 했다.
이렇게 생성된 볼륨은 "영속적"이므로 파드를 삭제하고, 다시 만들어도 여전히 해당 볼륨의 데이터에 접근할 수 있었다.

이처럼 파드의 외부에 생성한 볼륨을 파드 외부 볼륨이라고 한다.

외부 볼륨

외부 볼륨은 클러스터 내 또는 클러스터 외부의 네트워크 저장소에 생성된다.
ex. (NFS 서버, 클라우드 스토리지, 영구 디스크 등)

외부 볼륨은 파드 간에 데이터를 공유하거나 데이터를 보존하고 지속적으로 사용할 때 유용합니다.
따라서 파드가 종료되어도 볼륨의 데이터는 유지된다.

그럼 외부가 아닌, 파드안에 생성되는 내부 볼륨도 있을까?

그렇다. 파드 내부에 생성되는 파드 내부 볼륨이 있다.

파드 내부 볼륨

파드 내부 볼륨은 볼륨은 파드 내부에 생성되며 파드의 라이프사이클과 함께 동작한다.
즉, 파드가 종료되면 해당 볼륨도 함께 삭제된다.
파드 내부 볼륨은 파드 간에 데이터를 공유하지 않고 파드 내 여러 컨테이너가 있을 시 컨테이너끼리 데이터를 공유한다.

파드 내부 볼륨은 파드 내에서만 사용 가능한 볼륨으로, 일반적으로 파드 내부의 여러 컨테이너 간에 데이터를 공유하는 데 사용된다.
예를 들어, EmptyDir, ConfigMap, Secret, Downward API 등의 볼륨 유형이 파드 내부에서 사용될 수 있다.

  • RedHat의 공식문서를 보면 다음과 같이 볼륨에 대해 설명이 되어있는데, 포드(파드)와 수명이 같고, 파드 내의 컨테이너를 다시 시작해도 보존된다는 것이 나와있다.
    즉, 파드 내부 볼륨의 설명이라는 것을 알 수 있다.
profile
붉은 배 오색 딱다구리 개발자 🦃Cloud & DevOps

0개의 댓글