---
description: >-
  쿠버네티스에서 Pod를 그냥 띄우는 경우는 사실 거의 없다. 실제로는 클라이언트가 도메인을 통해 접속을 하면, 로드밸런서를 거쳐서,
  노드포트를 거쳐서, 클러스터IP를 거쳐서, Pod로 연결된다. ➡️ 진정한 마이크로서비스 아키텍처...
---

# \[쿠버네티스 아키텍처] 2. 오브젝트 (Objects)

> 44BIT님의 [\[초보를 위한 쿠버네티스 안내서\] 쿠버네티스 아키텍처](https://youtu.be/-gIyfII5eak) 강의를 듣고 정리한 내용입니다.

## 1. 쿠버네티스의 일반적인 구성

위 이미지처럼 쿠버네티스의 일반적인 구성을 보면, 포드(pod)를 그냥 띄우는 경우는 거의 없다고 봐도 된다.

1. `Deployment`를 먼저 생성을 하고, 그러면 Deployment가&#x20;
2. `ReplicaSet`을 자동으로 생성하고, 그럼 ReplicaSet가
3. `pod`를 자동으로 생성하는 구조를 갖는다.

그리고 이 오브젝트를 외부에 노출을 할 때는

1. `Service(ClusterIP)`를 하나 붙이고
2. 거기에 `Ingress`를 붙인다. Ingress를 붙이면&#x20;
3. `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로 자동으로 잘 연결되도록 작동한다. 아래 그림이 이해에 도움이 된다.

![](https://github.com/hidaehyunlee/Fork-my-brain/tree/4f7d19f4487fe8d450e22a9b6451bbed865ce125/images/37580034-108089855-61fc8100-70bd-11eb-9647-d17fcb10ad4c.png)

### 6) Service - LoadBalancer

모든 노드에 외부 접속 분산 요청을 처리하기 위해서는 NodePort 보다는 Load Balancer 사용이 적절하다.

게시물 제일 상단의 <일반적인 구성>을 보면, 노드포트 앞에 로드밸런서라는 또하나의 서비스가 붙어있는걸 볼 수 있다. **단 1개의 IP만을 외부에 노출하게 하며 해당 IP로 모든 트래픽을 부하 분산**한다.

HTTP, TCP, UDP 등 대부분의 프로토콜과 통신할 수 있다.

ft\_service 과제에서는 `metallb` 라는 로드밸런서를 사용한다.

### 7) Ingress

![](https://github.com/hidaehyunlee/Fork-my-brain/tree/4f7d19f4487fe8d450e22a9b6451bbed865ce125/images/37580034-108092362-fd8ef100-70bf-11eb-9456-87633d977122.png)

지금까지의 오브젝트들이 IP포트로만 접속하는 서비스였다면, Ingress는 도메인 이름, 도메인 패스에 따라 내부에 있는 클러스터IP에도 같은 이름으로 연결할 수 있도록 해준다. Ingress 하나만 만들어도 여러 개의 로드밸런서를 만들어 자원을 낭비하는 것을 방지할 수 있다.

다만 ft\_serviece 과제에서는 잉그리스는 사용하지 않는다.

## 3. 그 외 기본 오브젝트

* Volume : Storage(EBS, NFS, ...)
* Namespace : 논리적인 리소스 구분
* ConfigMap/Secret : 설정
* ServiceAccount : 권한 계정
* Role/ClusterRole : 권한 설정 (get, list, warch, create)
* ...&#x20;

등등 훨씬 많은 오브젝트가 존재한다. 쿠버네티스의 어려운 점일 수도 있고, 그냥 이런게 있다는 것 정도만 알고 넘어가고 필요하면 내용을 추가하기로...

아무튼 쿠버네티스가 얼마나 잘 디자인된 **마이크로서비스 아키텍처**인지 알 수 있었던 강의. 처음에는 뭐가 이렇게 복잡하게 추상화 되어있고 연결되어있는지 했는데, 이것이 서버스를 안정적으로, 효과적으로, 또 가볍게 운영할 수 있는 비법이었다.
