40일차 수정-1

Author: Minnnning

오토에버 클라우드 2기/_posts/2025-06-27-40일차.md

@@ -148,7 +148,7 @@ Pod는 언제든 사라지고 다시 생성될 수 있어 IP가 계속 바뀜 **
         KubeProxy2 -- "2 전체 Pod 목록 확인 후</br>가장 적절한 Pod 선택" --> PodA
     ```
 
-  - **노드포드를 사용해도 적절한 pod를 찾아가지만(kube-proxy) 실제 서비스에서 노드포트를 사용하지 않는 이유는 해당 워커노드가 죽으면 전달하지 못하고 노드가 스케줄링으로 줄어들어서 없어질수도 있기 때문에 실제 서비스에서 노드밸런서가 필요하다** 
+  - **노드포드를 사용해도 적절한 pod를 찾아가지만(kube-proxy) 실제 서비스에서 노드포트를 사용하지 않는 이유는 해당 워커노드가 죽으면 전달하지 못하고 노드가 스케줄링으로 줄어들어서 없어질수도 있기 때문에 실제 서비스에서 노드밸런서(서비스단에서)가 필요하다** 
 
   - 
 
@@ -163,35 +163,83 @@ Pod는 언제든 사라지고 다시 생성될 수 있어 IP가 계속 바뀜 **
 
   - ``` mermaid
     graph TD
-        User[👤 사용자] --> LB[🌐 외부 LoadBalancer]
+        %% --- 전체 사설망(VPC) 경계를 정의합니다 ---
+        subgraph "VPC (사설 네트워크)"
     
-        subgraph "쿠버네티스 클러스터"
-            subgraph "워커 노드 1"
-                KP1[kube-proxy] --> Pod1[Pod]
-            end
-            subgraph "워커 노드 2"
-                KP2[kube-proxy] --> Pod2[Pod]
+            %% --- 외부와 통신하는 Web Tier (Public Subnet) ---
+            subgraph "Web Tier (프론트엔드)"
+                direction LR
+                Web1[🌐 웹서버 Pod 1]
+                Web2[🌐 웹서버 Pod 2]
             end
-            subgraph "워커 노드 3 (장애 발생)"
-                style Node3 fill:#ff9999,stroke:#333,stroke-width:2px
-                KP3[kube-proxy]
+    
+            %% --- 내부 통신만 하는 App Tier (Private Subnet) ---
+            subgraph "Application Tier (백엔드)"
+                direction LR
+                ILB["<b>Internal Load Balancer</b><br/>(사설 IP만 가짐)"]
+                
+                App1[⚙️ 앱서버 Pod 1]
+                App2[⚙️ 앱서버 Pod 2]
+                App3[⚙️ 앱서버 Pod 3]
             end
             
-            Service[Service]
-            KP1 --> Service
-            KP2 --> Service
+            %% --- 통신 흐름을 정의합니다 ---
+            %% Web Tier의 Pod들이 내부 로드밸런서로 요청을 보냅니다.
+            Web1 -- "내부 API 요청" --> ILB
+            Web2 -- "내부 API 요청" --> ILB
+    
+            %% 내부 로드밸런서는 App Tier의 Pod들에게 트래픽을 분산합니다.
+            ILB -- "내부 로드 밸런싱" --> App1
+            ILB -- "내부 로드 밸런싱" --> App2
+            ILB -- "내부 로드 밸런싱" --> App3
+        end
+    
+        %% --- 외부 인터넷 사용자는 내부 로드밸런서에 직접 접근할 수 없음을 보여줍니다 ---
+        Internet[👤 외부 인터넷 사용자]
+        Internet -- "<font color=red>X 접근 불가 X</font>" --x ILB
+        Internet -- "접근 가능" --> Web1
+        Internet -- "접근 가능" --> Web2
+    ```
+
+- **Ingress**: `Service`가 L4(TCP/UDP) 레벨에서 동작하는 것과 달리, **Ingress**는 L7(HTTP/HTTPS) 레벨에서 동작. URL 경로, 호스트 이름에 따라 요청을 다른 서비스로 라우팅하는 규칙을 정의
+
+  - ``` mermaid
+    graph TD
+        User[👤 외부 사용자] --> DNS
+    
+        subgraph "클라우드 인프라"
+            DNS -- "shop.my-website.com" --> LB[🌐 외부 LoadBalancer]
         end
         
-        LB -- "1단계: 노드 간 로드 밸런싱<br/>(Health Check 통과한 노드1, 2로만 분산)" --> KP1
-        LB -- "1단계: 노드 간 로드 밸런싱<br/>(Health Check 통과한 노드1, 2로만 분산)" --> KP2
+        subgraph "쿠버네티스 클러스터"
+            subgraph "워커 노드"
+                Controller["<b>Ingress Controller Pod</b><br/>(NGINX 등)"]
+                
+                subgraph "쇼핑몰 서비스"
+                    ShopSvc[Service: shop-svc] --> ShopPod[Pod]
+                end
+                
+                subgraph "블로그 서비스"
+                    BlogSvc[Service: blog-svc] --> BlogPod[Pod]
+                end
+            end
+    
+            IngressRules[📜 Ingress 규칙]
+        end
         
-        Service -- "2단계: 파드 간 로드 밸런싱" --> Pod1
-        Service -- "2단계: 파드 간 로드 밸런싱" --> Pod2
+        %% --- 흐름 정의 ---
+        LB -- "1 트래픽 전달" --> Controller
+        Controller -- "2 Ingress 규칙 조회" --> IngressRules
+        Controller -- "3 'shop.my-website.com'<br/> 규칙에 따라<br/>shop-svc로 라우팅" --> ShopSvc
     ```
 
-  - 만약에 노드당 pod가 1개씩이라면 의미가 없어보일 수 있지만 pod가 업데이트 되거나 재실행되서 ip가 변경된다면 service를 통해서 변경된 pod에 요청을 제대로 보낼 수 있다
-
-- **Ingress**: `Service`가 L4(TCP/UDP) 레벨에서 동작하는 것과 달리, **Ingress**는 L7(HTTP/HTTPS) 레벨에서 동작. URL 경로, 호스트 이름에 따라 요청을 다른 서비스로 라우팅하는 규칙을 정의
+  - | 특징 (Feature)   | Ingress를 사용하지 않을 때 (비효율적)                        | Ingress를 사용할 때 (효율적, 권장)                           |
+    | ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+    | **외부 진입점**  | 각 서비스마다 **별개의 로드밸런서**가 필요                   | **단 하나의 로드밸런서**를 모든 서비스가 공유                |
+    | **비용**         | 서비스 개수만큼 클라우드 로드밸런서 비용이 발생하여 **고비용** 구조가 된다 | 로드밸런서 1개에 대한 비용만 발생하므로 **매우 비용 효율적** |
+    | **라우팅 방식**  | L4 (IP, Port 기반의 단순 전달)만 가능                        | L7 (Host, URL 경로 기반의 **지능적인 라우팅**)이 가능        |
+    | **관리 포인트**  | 여러 개의 IP와 로드밸런서 설정을 개별적으로 관리해야 해서 복잡 | 단일 진입점과 라우팅 규칙(`Ingress` YAML)을 **중앙에서 일관되게 관리**할 수 있다 |
+    | **SSL/TLS 인증** | 각 로드밸런서마다 개별적으로 SSL 인증서를 설정해야 한다      | **Ingress에서 SSL 인증서를 중앙 집중적으로 관리**하고 적용할 수 있다 |
 
 &nbsp;