[2] 쿠버네티스: 오브젝트, Pod, Replicas, NodePort, ClusterIP, LB, Ingress

https://www.youtube.com/watch?v=-gIyfII5eak 

 

쿠버네티스가 내부적으로 어떻게 작동하는지는 대충 알았어.

그럼 뭘 체크하는지 알면 쿠버네티스를 이해한다고 볼 수 있음.

 

쿠버네티스는 컨테이너를 직접 관리하지 않고 Pod이라는 것으로 감싸서 관리한다

Pod : 가장 작은 배포 단위

 

즉, 컨테이너를 배포하는 것이 아니라 Pod을 배포하는거야

Pod의 특징은 각 Pod마다 고유한 Ip를 부여받는다. 그래서 이 IP를 통해서 내부적으로 통신할 수도 있당

그리구 또 하나의 중요한 특징.

보통 하나의 Pod에 하나의 컨테이너만 존재하지만, 

두 개의 컨테이너가 하나의 Pod에 속할 수도 있다. (여러 개의 컨테이너두 가능)

예컨대, Container와 로그를 수집하는 컨테이너 이렇게 두 개가 떠있을 수도 있당

그리고 host에 있는 폴더를 공유할 수도 있다.

Container에서 log가 저장되는 폴더를 log를 수집하는 컨테이너와 공유할 수 있는거야!

 

그리고 특정 컨테이너가 만약 캐시가 필요하다면?

모든 컨테이너마다 캐시를 붙이고 싶다면?

 

하나의 Pod에 Container, Cache 두 개를 띄워놓구 Port를 localhost로 공유할 수 있다.

 

운영체제에서 Shared Memory나 IPC 네트워크 소켓과 비슷한 개념인듯?

 

ReplicaSet. 신규 Pod을 생성하거나 기존 Pod을 제거하여 원하는 수(Replicas)를 유지

replicas가 3이면, 3개의 pod을 관리하라는 뜻

 

이걸 만약에 4로 바꾸면, ReplicaSet이 "어? Desired State가 Replicas=4인데 지금 3이네?" 하고

Pod Template를 보고 하나를 더 띄워줌

 

Deployment

Replicas set을 감싼, 배포 버전을 관리하는 넘

내부적인 알고리즘을 쓰는게 아니라 ReplicaSet을 써서 버전을 관리하는거야

 

예를 들어서, ReplicaSet의 version을 v1에서 v2로 업데이트 하구 싶다고 하자.

근데 무중단으로 업데이트배포를 해야 되잖아.

그럼 어떻게 해야되겠어?

하나씩 바꾸는거야.

 

방법은?

순간적으로 replicas set을 2개를 만드는거야.

원래 3개의 Pod이 들어있던 ReplicaSet을 2개 1개로 쪼개.

 

그리고 v1 ReplicaSet의 replicas를 1로 낮추고, v2 ReplicaSet의 replicas를 2로 올려

그럼 v1 ReplicaSet의 replicas는 1이니까 pod의 갯수는 줄어들거고, v2 ReplicaSet의 replicas는 2니까 pod의 갯수는 늘어나겠지?

 

 

이렇게 말야.

마지막으로 v1 ReplicaSet의 replicas를 0으로, v2 ReplicaSet의 replicas를 3으로 하면

자연스럽게 version2 ReplicaSet의 Pod이 3개가 되겠지?

요렇게 말야.

 

이렇게 하면 순간적으로 Pod의 갯수가 늘어났다 줄어들었다 할 수는 있겠지만

무중단으로 자연스럽게 업데이트가 된거야.

 

다시.

그래서 Deployment는 어떻게 버전을 관리한다구?

내부적인 알고리즘을 쓰는게 아니라 ReplicaSet을 써서 버전을 관리한다.

 

쿠버네티스는 ReplicaSet 말고도 다양한 방식을 제공한당

 

 

Daemon Set은 모든 노드에 꼭 하나씩만 떠있기를 원하는 Pod을 만들고 싶을 때 사용한다

로그를 사용한다든가 모니터링을 할 때 적합

 

Stateful Sets. 순서대로 Pod을 실행하고 싶거나 같은 볼륨을 재활용하고 싶을 때 사용한다

Job. 한번 실행하고 죽는 Pod도 만들 수 있당

 

그래서 얘네들이 기본적으로 쿠버네티스에서 기본적으로 제공하는 Workload 방식들이다!

 

지금까지 네트워크 얘기를 안했는데

네트워크도 별도의 오브젝트로 관리한다

아까 Pod두 IP가 있다구 했자나?

Service 중에서도 Cluster IP가 뭐냐하면 저 Pod들을 LoadBalancing 하는 별도의 서비스야

ClusterIP로 요청을 보내면 자동으로 저 Pod중 하나로 요청이 가는거지

왜 이게 필요한데?

 

Deployment나 ReplicaSet을 보면, Pod을 Update할 때 ip를 유지하지 않고 그냥 Pod을 없애거나 만든단말야.

IP가 언제든지 사라졌다가 바뀌거나 하는게 자연스러워

그래서 요청을 보낼 때 Pod에 바로 보내는게 아니라, Service에 보내면 뒤에 Pod은 늘든 줄든 IP가 바뀌든 상관없이

정상적으로 원하는 Pod에 보낼 수 있는거야. ClusterIP가 알아서 처리해주는듯?

 

내부적으로는 이렇게 통신을 해.

웹서버에서 redis로 통신을 하고 싶다?

내부 DNS에서 redis라는 도메인이 생겨

도메인 redis에 요청을 보내면, 일차적으로 ClusterIP로 요청이 가고 그 요청이 다시 Pod으로 가는거야.

도메인 mysql에 요청을 보내면, 일차적으로 ClusterIP로 요청이 가고 그 요청이 다시 Pod으로 가는거야.

 

근데 애매한건, ClusterIP는 내부에서만 접근이 가능해.

그러니까 외부에서 브라우저를 이용해서 접근하는건 불가능하다는 소리야.

 

그럼 얼케???

외부에서 접근하기 위해서 NodePort라는 개념이 생겼어.

Node에 Port가 생기고, 거기로 접속을 하면, 그 요청이 다시 ClusterIP로 가고 그 요청이 다시 Pod으로 가.

만약 노드가 2개 있다구 하자.

Node Port를 만들면 1번 노드에도 생기고, 2번 노드에도 생긴다.

그래서 1번 노드로 요청을 보내도 원했던 ClusterIP로 요청이 가고,

2번 노드로 요청을 보내도 내부적으로 자동으로 ClusterIP를 찾아서 가.

 

그러니까 1번으로 요청을 보내나 2번으로 요청을 보내나 상관없어.

 

예를들어 노드가 10개면, 10개 중 아무데나 보내도 내부에 있는 네트워크를 잘 찾아간다.

 

근데 문제가 되는게 뭐냐하면...

1번 노드가 갑자기 죽을 수 있잖아.

그러면 만약 내가 원하는 서비스가 지금 잘 살아있는 2번 노드에 있다고 해도

"순간적으로" 접속이 안될거아냐? 1번 노드의 NodePort가 죽었으니까.

-> 이 말 뜻은, 조금 지나면 자동으로 2번 노드로 연결해준다는 뜻인가?

좀 이해가 안가는데? 1번 노드의 NodePort가 죽었는데 어떻게 연결해줌?

 

어쨌든 이걸 방지하기 위해서

앞에 LoadBalancer를 별도로 둔다.

 

사용자는 로드밸런서로 요청을 보내고 로드밸런서는 이 요청을 다시 NodePort로 보내고,

NodePort는 이 요청을 다시 ClusterIP로 보내고 ClusterIP는 이 요청을 다시 Pod으로 보내는 구조다

 

사용자의 요청 -> LB -> NodePort -> ClusterIP -> Pod

별거 아니네.

 

그리구 또 하나의 독특한 특징

Ingress라는 오브젝트가 있다.

아까전에 설명한 네트워크는 IP, Port로만 접속을 하는거라구 하면

Ingress는 도메인 이름, 도메인 뒤에 path에 따라서 내부에 있는 ClusterIP에 연결을 할 수 있어

 

example.com 

subicura.com/blog

subicura.com/help

 

이런 요청이 들어왔을 때, 이 3개를 전부 NodePort로 만들거나 LoadBalancer로 만들면 자원의 낭비가 돼

(? 와닿지가 않네)

 

Q)

이러면 자원을 더 효율적으로 사용할 수 있다는데, 좀 이해가 안가네.

Ingress에서 분기하는 것보다 LoadBalancer나 NodePort를 만드는게 오버헤드가 왜 더 큰가?

대충 삘은 오는데 정확하게 이유를 알고싶음 ㅋ

 

 

대신 Ingress 하나만 만들고, 내부적으로 서비스를 분기할 수 있어

Nginx, HAProxy, ALB 이런 기존에 존재하는 것들 재활용해서 쿠버네티스에 맞게 포장해서 사용한대

 

그래서 일반적인 구성을 할 때는

Pod을 바로 띄우는 경우는 없다.

 

보통 얼케하냐면...

Deployment를 생성한다. 그러면 Deployment가 자동으로 ReplicaSet을 생성하고,

ReplicaSet은 자동으로 Pod을 생성한다.

 

이렇게.

 

근데 얘를 외부에 노출할거자나.

그럼 서비스(ClusterIP)를 하나 붙여.

그 다음에 Ingress를 붙이는데, Ingress를 붙이면 LoadBalancer와 NodePort가 따라와.

 

실제 접속할 때는, 브라우저에서 www.subicura.com을  치면

LB -> NodePort -> ClusterIP -> Pod 으로 연결되는 과정을 거친다.

 

Q)

Ingress를 만들면 LoadBalancer와 NodePort가 자동으로 왜 생겨야 하는지 이유를 모르겠어.

아까 그림 보면 LB와 NodePort 없어도 연결 해주는거 아니었어?

심지어 LB와 NodePort를 만들면 오버헤드라서 Ingress 쓴다며?

근데 Ingress 만들 때, LB와 NodePort가 같이 만들어지면 어떡해?

 

그 외 기본 오브젝트

Volume - Storage (EBS, NFS, ...)

Namespace - 논리적인 리소스 구분 (내부적으로 리소스를 네임스페이스로 구분 가능)

ConfigMap/Secret - 설정

ServiceAccount - 권한 계정

Role/ClusterRole - 권한 설정 (get, list, watch, create, ...)

 

오브젝트가 수도 없이 많아. 다 추상화 해놔가지고.

그게 쿠버네티스의 어려운 점인데, 원리를 알면 그냥 어렵지 않게 이해할 수 있다.