🌌[쿠버네티스 아키텍처] 2. 오브젝트 (Objects)
쿠버네티스에서 Pod를 그냥 띄우는 경우는 사실 거의 없다. 실제로는 클라이언트가 도메인을 통해 접속을 하면, 로드밸런서를 거쳐서, 노드포트를 거쳐서, 클러스터IP를 거쳐서, Pod로 연결된다. ➡️ 진정한 마이크로서비스 아키텍처...
44BIT님의 [초보를 위한 쿠버네티스 안내서] 쿠버네티스 아키텍처 강의를 듣고 정리한 내용입니다.
1. 쿠버네티스의 일반적인 구성
위 이미지처럼 쿠버네티스의 일반적인 구성을 보면, 포드(pod)를 그냥 띄우는 경우는 거의 없다고 봐도 된다.
Deployment를 먼저 생성을 하고, 그러면 Deployment가ReplicaSet을 자동으로 생성하고, 그럼 ReplicaSet가pod를 자동으로 생성하는 구조를 갖는다.
그리고 이 오브젝트를 외부에 노출을 할 때는
Service(ClusterIP)를 하나 붙이고거기에
Ingress를 붙인다. Ingress를 붙이면NodePort와LoadBalancer가 자동으로 생성된다.
즉, 실제로는 클라이언트가 도메인을 통해 접속을 하면, 로드밸런서를 거쳐서, 노드포트를 거쳐서, 클러스터IP를 거쳐서 Pod로 연결되는, 이게 쿠버네티스의 일반적인 방법이라고 이해하면 된다. 하나씩 어떤 기능을 가진 오브젝트인지 살펴보자.
2. 일반적인 구성 속 오브젝트
1) pod
Pod(포드, 팟)은 쿠버네티스에서의 가장 작은 배포 단위이며, 각 Pod마다 고유한 IP를 할당받는다. 여러 개의 컨테이너가 하나의 Pod에 속할 수 있다.
2) ReplicaSet
리플리카셋은 여러 개의 Pod를 관리하며, replicas = 3 과 같은 식으로 몇 개의 Pod를 관리할 지 결정한다. 즉, 신규 Pod을 생성하거나 기존 Pod을 제거하여 원하는 수(Replicas)를 유지하는 역할을 한다.
3) Deployment
ReplicaSet을 감싸고 있는, 배포 버전을 관리하는 오브젝트이다. 내부적으로 ReplicaSet을 활용해 무중단 버전관리를 가능케 한다.
4) Service - ClusterIP
쿠버네티스는 네트워크도 Service라는 별도의 오브젝트로 관리한다. 서비스 중에서도 클러스터IP는 클러스터 내부에서 사용하는 프록시 서비스이다. 클러스터IP에 요청을 보내면 여러 개의 Pod 중 하나로 자동으로 요청이 가는 것이다.
이렇게 클러스터IP를 사용하는 이유는 Pod의 IP는 동적이기 때문이다. (Deployment를 통해 Pod이 업데이트될 때 IP를 유지한 상태로 업데이트 되는게 아니라 그냥 Pod이 죽고 새로운 Pod 생성되는 개념이다.) 따라서 Deployment 앞에 존재해 Pod의 IP와는 상관없이 액세스할 수 있도록하는, 고유 IP를 가진 Service가 필요한 것이다.
클러스터 내부에서 서비스 연결은 DNS를 이용한다.
5) Service - NodePort
다만 클러스터IP는 클러스터 내부에서만 통신할 수 있다. 그래서 외부 브라우저에서도 접근할 수 있도록, NodePort라는 개념이 생긴다. NodePort는 노드(host)에 노출되어 외부에서도 접근이 가능한 서비스 이다. 다만 노드/VM IP가 변경된 경우 처리를 해줘야하기 때문에 실 서비스에서 노드포트만으로 외부 클라이언트 노출하는 방식은 권장되지 않는다. 바로 다음에 나오는 로드 밸런싱을 사용한다.
노드포트에는 중요한 특징이 있는데, 노드가 여러 개일때 노드포트를 생성하면 모든 노드에 노드포트가 생성된다. 이때 어떤 노드에 요청을 보내도 내부의 원하는 클러스터IP로 자동으로 잘 연결되도록 작동한다. 아래 그림이 이해에 도움이 된다.
6) Service - LoadBalancer
모든 노드에 외부 접속 분산 요청을 처리하기 위해서는 NodePort 보다는 Load Balancer 사용이 적절하다.
게시물 제일 상단의 <일반적인 구성>을 보면, 노드포트 앞에 로드밸런서라는 또하나의 서비스가 붙어있는걸 볼 수 있다. 단 1개의 IP만을 외부에 노출하게 하며 해당 IP로 모든 트래픽을 부하 분산한다.
HTTP, TCP, UDP 등 대부분의 프로토콜과 통신할 수 있다.
ft_service 과제에서는 metallb 라는 로드밸런서를 사용한다.
7) Ingress
지금까지의 오브젝트들이 IP포트로만 접속하는 서비스였다면, Ingress는 도메인 이름, 도메인 패스에 따라 내부에 있는 클러스터IP에도 같은 이름으로 연결할 수 있도록 해준다. Ingress 하나만 만들어도 여러 개의 로드밸런서를 만들어 자원을 낭비하는 것을 방지할 수 있다.
다만 ft_serviece 과제에서는 잉그리스는 사용하지 않는다.
3. 그 외 기본 오브젝트
Volume : Storage(EBS, NFS, ...)
Namespace : 논리적인 리소스 구분
ConfigMap/Secret : 설정
ServiceAccount : 권한 계정
Role/ClusterRole : 권한 설정 (get, list, warch, create)
...
등등 훨씬 많은 오브젝트가 존재한다. 쿠버네티스의 어려운 점일 수도 있고, 그냥 이런게 있다는 것 정도만 알고 넘어가고 필요하면 내용을 추가하기로...
아무튼 쿠버네티스가 얼마나 잘 디자인된 마이크로서비스 아키텍처인지 알 수 있었던 강의. 처음에는 뭐가 이렇게 복잡하게 추상화 되어있고 연결되어있는지 했는데, 이것이 서버스를 안정적으로, 효과적으로, 또 가볍게 운영할 수 있는 비법이었다.
Last updated
