Kubernetes 용어 완전 쉽게 이해하기

요즘 프로젝트 멘토링에서 K8S 수업을 하고 있는데, 다들 용어 습득에 매우 어려움을 겪으시더라… 그래서 아주 완전 쉽게 이해하실 수 있도록 준비해본게 나름 괜찮은 것 같아서 ^_^ 블로그 글로 한 번 남겨본다.

모든 개념이 들어있진 않으니 참고하세요

1. Node 노드

여러분들 앞에 10년도 더 된, 사용하지 않는 고물 노트북이 있다고 가정해보자.

이거를 여러분들의 홈서버로 설정하여 프로그램을 돌리거나 gdrive같은 파일저장시스템을 만든다고 하자. 그리고 여러분들은 가족들 모두가 이용할 수 있도록 설정을 세분화 하고 싶다고 하자.

이 때 여러분들이 K8S로 시스템을 관리한다고 하면, node는 실제 물리적 공간 = 노트북이 된다.

그 중에서도

• Master Node: 직접 일은 안하고 명령만 내리는 일종의 두뇌 (예시에서는 노트북이 두뇌 역할을 겸하는 중)
• Worker Node: 쫄따구(Pod)가 실제로 거주하며 일하는 물리적 공간을 의미한다.

2. Namespace 네임스페이스

Namespace는 가상 구역을 나눌 때 사용한다. 즉 Node를 가상으로 N등분 한거라고 이해하면 된다.

노트북에서 A, B, C라는 Namespace(=구역)을 나누면 가족 1, 가족 2, 가족 3이 각각의 영역을 사용하면 된다는 얘기다.

분명 서버 테스트를 한다고 이것저것 돌려보면 오류가 날 가능성이 있다. 이 때 namespace를 기준으로 세팅을 하면 서로의 영역을 터치하지 않기 때문에 다른 쪽에서 에러가 났다한들 다른 프로그램은 잘 돌아가는걸 볼 수 있다.

3. Pod 파드

실제 이 체계에서 가장 쫄따구 / 노예 계급이라고 생각하면 된다. 얘가 실무 처리를 다 한다.

여기서 시스템 서버 돌리기 등이 일어난다.

만약 서비스에 사람들이 많이 들어온다? 그러면 일이 바쁘단 얘기가 되는 것이며, 그럼 노예를 더 뽑아서 일을 시켜야 한다는 의미가 되므로 Pod들이 우후죽순 여러 개가 생겨난다고 보면 된다.

반대로 서비스에 사람들이 줄어들었다, 그러면 필요없는 Pod들이 삭제된다.

즉, Pod들은 추가되거나 삭제되는 것에서 매우 자유롭다고 생각하면 된다. 마치 회사 인원감축 때 가장 잘리기 쉬운 말단사원처럼……

4. Service 서비스

현실세계에서 다른 집으로 이사를 갔다고 쳐보자. 집 주소는 바뀌겠지만 자신의 핸드폰 번호는 번호 변경 서비스 신청을 하지 않는 이상 그대로일 것이다.

앞서 Pod는 추가/삭제에 매우 자유롭다고 말했는데, 이 얘기는 바로 노예의 정보가 자주 바뀐다는 의미 = 주소가 고정되어 있지 않다는 뜻이 된다.

우리 입장에서는 이 Pod에서 원하는 서버를 돌리는건데, 이걸 못찾는다? 그러면 이걸 매번 어디있는지 찾아서 돌아가라! 라고 명령을 내려야 하는게 여간 귀찮은 일이 아니다. 이 때 나오는 개념이 바로 Service이다.

Service를 사용하면 주소를 고정함으로써 Pod의 내용물이 바뀌더라도 알아서 변경 주소로 매핑이 되어 우리가 편하게 이용할 수 있다.

5. Port 포트

보통의 회사같은 경우 마케팅 / IT / HR / 경영 부서가 각각 있을 것이다. 회사다보니 사람들이 이직 또는 퇴사를 하면서 인원변동이 있을 것이지만, 부서 자체는 사라지는 일이 거의 없다.

여기 k8s에서도 마찬가지다. 어쨌든간에 관리직이든 노예든 모두가 일을 할텐데, 현실세계에서 우리가 이직이나 퇴사를 하는 것처럼 얘들이 평생을 바쳐 일을 하지 않는다. 자원이 변경될 수 있다. 하지만 자원들이 속한 공간은 변경되지 않는다.

그래서 Port는 실제 일하는 공간의 주소라고 생각하면 된다.

• targetPort: Pod들이 실제로 머무는 주소 - 101동 101호같은 주소에서 101호를 의미
• port: 서비스의 주소 - 여러 개의 서비스가 있으니 “A 서비스는 80번”, “B 서비스는 81번” 식으로 이름을 붙여줌
• nodePort: 외부에서 노트북(Node) IP를 치고 들어올 때 쓰는 일종의 정문 번호

6. Deployment / ReplicaSet

위에서 pod들이 실질적인 일을 한다고 했는데, 여기서 deployment와 replicaSet은 그 pod들의 상사 역할이라고 생각하면 된다.

즉 Deployment > ReplicaSet > Pod 순이며,

• Deployment가 “새 버전 업데이트”, “롤백” 같은 전체적인 전략을 짜면
• ReplicaSet이 Deployment의 명령을 받고 오직 Pod의 숫자 관리에 집중을 한다. 예를 들면 “지금 바빠 죽겠는데 pod가 하나네? 더 만들자” 이런식으로 된다.
• 그리고 실질적으로 Pod가 그 일을 한다고 생각하면 된다.

그래서 실제로 명령어를 쳐보면,

• Deployment: my-web
• ReplicaSet: my-web-123abc
• Pod: my-web-random-123abc-def456

이런식으로 종속되어 있는 형태로 이름이 지어지는 것을 알 수 있다.

7. Ingress / Egress

위에서 우리는 port라는 것을 설명했는데, port는 쉽게 “주소”를 얘기한다고 했다.

만약에 노트북을 홈서버로 만들었다고 하면, 보통은 공부 목적으로 프로젝트를 만들어 배포 연습도 할 것이다.

근데 그런 프로젝트가 한 두개여도 포트 번호를 외우는데 귀찮은데, 이게 20개 30개가 넘는다고 하자. 이걸 언제 다 외우겠는가??

이 때 필요한게 바로 Ingress이다. Ingress는 포트 번호를 외우기 싫을 때, 도메인에 연결해서 쉽게 우리의 포트와 매핑을 해주는 것이라고 생각하면 된다.

그럼 Egress는 무엇이냐, 일단 Ingress는 영단어만 보면 “들어온다”는 뜻이다. 즉 Egress는 그 반대로 “밖으로 나가는 것”에 대한 것이 된다.

그럼 데이터가 밖으로 나가는 경우가 무엇이 있을까? 보통은 사용자가 서버에서 데이터를 다운로드받을 때를 생각하겠지만, 여러 관점에서 생각해볼 때 해킹당했을 때 데이터가 밖으로 나갈 것도 고려해야 한다.

그래서 Egress는 데이터를 밖으로 꺼낼 때 얼마나 차단할지를 설정해서, 해킹 방지용에 많이 사용한다고 생각하면 된다.

8. Volume

지금까지는 프로그램에 대한 얘기를 했다. pod를 통해 실질적으로 프로그램을 돌린다고 했는데, pod는 결국 노예이기 때문에 필요 없으면 바로 컷을 당하는 불쌍한 아이다.

그러면 이 얘기는 즉슨, pod가 사라지면 기존에 pod 안에 있던 데이터는 전부 하늘나라로 날아가게 된다는 얘기다. 우리의 데이터는 그럼 영원한 이별을 맞이하게 된다는 그런 슬픈 이야기가….

그럼 데이터를 안날아가게 하는 방법이 있냐? 당연히 있다. 이 때 나오는 개념이 바로 Volume이다.

Volume을 사용하면 하드디스크에 데이터를 안전하게 저장해서 영구 보관을 할 수 있다.

노트북으로 서버를 만들었다면, 이 노트북의 하드디스크게 데이터를 저장하게 될 것이다.

우리는 이것을 PV(Persistent Volume) 이라고 부르며, 파일을 저장하고 관리하는 경험을 하고 싶을 때 PVC(Persistent Volume Claim) 이라는 저장소 요청소를 만들어서 k8s에 제출하면 파일을 업로드할 수 있다.