1.4. Pod 통신 방법
Pod는 IP 주소를 사용하여 통신하고 DNS(Dynamic Name System)를 사용하여 Pod 또는 서비스의 IP 주소를 검색합니다. 클러스터는 허용되는 통신을 제어하는 다양한 정책 유형을 사용합니다. Pod는 pod-to-pod 및 service-to-pod의 두 가지 방식으로 통신합니다.
1.4.1. pod-to-pod 통신 링크 복사링크가 클립보드에 복사되었습니다!
pod-to-pod 통신은 Pod가 클러스터 내에서 서로 통신할 수 있는 기능입니다. 이는 마이크로 서비스 및 분산 애플리케이션의 작동에 중요합니다.
클러스터의 각 pod에는 다른 Pod와 직접 통신하는 데 사용하는 고유한 IP 주소가 할당됩니다. pod-to-pod 통신은 Pod가 데이터를 교환하거나 작업을 공동으로 수행해야 하는 클러스터 내부 통신에 유용합니다. 예를 들어 Pod A는 Pod B의 IP 주소를 사용하여 Pod B에 직접 요청을 보낼 수 있습니다. Pod는 NAT(네트워크 주소 변환) 없이 플랫 네트워크를 통해 통신할 수 있습니다. 이를 통해 서로 다른 노드에서 pod 간 원활한 통신을 수행할 수 있습니다.
1.4.1.1. 예: pod-to-pod 통신 제어 링크 복사링크가 클립보드에 복사되었습니다!
여러 포드가 있는 마이크로 서비스 기반 애플리케이션에서 프런트 엔드 포드는 데이터를 검색하기 위해 백엔드 Pod와 통신해야 합니다. 직접 또는 서비스를 통해 pod-to-pod 통신을 사용하면 이러한 Pod는 정보를 효율적으로 교환할 수 있습니다.
pod-to-pod 통신을 제어하고 보안을 위해 네트워크 제어를 정의할 수 있습니다. 이러한 제어는 라벨 및 선택기에 따라 Pod가 서로 상호 작용하는 방식을 지정하여 보안 및 규정 준수 요구 사항을 적용합니다.
1.4.2. service-to-pod 통신 링크 복사링크가 클립보드에 복사되었습니다!
service-to-pod 통신을 사용하면 서비스가 트래픽을 적절한 Pod로 안정적으로 라우팅할 수 있습니다. 서비스는 Pod의 논리 세트를 정의하고 IP 주소 및 DNS 이름과 같은 안정적인 엔드포인트를 제공하는 오브젝트입니다. Pod IP 주소가 변경될 수 있습니다. 서비스는 IP 주소가 변경되는 경우에도 애플리케이션 구성 요소에 일관된 방식으로 액세스할 수 있도록 포드 IP 주소를 추상화합니다.
service-to-pod 통신의 주요 개념은 다음과 같습니다.
- 끝점: 엔드포인트는 서비스와 연결된 Pod의 IP 주소 및 포트를 정의합니다.
- 선택기: 선택기는 키-값 쌍과 같은 레이블을 사용하여 서비스에서 대상으로 해야 하는 오브젝트 세트를 선택하기 위한 기준을 정의합니다.
- 서비스: 서비스는 pod 세트에 대한 안정적인 IP 주소와 DNS 이름을 제공합니다. 이 추상화를 사용하면 다른 구성 요소가 개별 pod가 아닌 서비스와 통신할 수 있습니다.
- 서비스 검색: DNS를 사용하면 서비스를 검색할 수 있습니다. 서비스가 생성되면 DNS 이름이 할당됩니다. 다른 포드는 이 DNS 이름을 검색하고 이를 사용하여 서비스와 통신합니다.
서비스 유형: 서비스 유형은 클러스터 내부 또는 외부의 서비스가 노출되는 방법을 제어합니다.
- ClusterIP는 서비스를 내부 클러스터 IP에 노출합니다. 기본 서비스 유형이며 클러스터 내에서만 서비스에 연결할 수 있습니다.
- NodePort를 사용하면 정적 포트에서 각 노드의 IP에 서비스를 노출하여 외부 트래픽이 서비스에 액세스할 수 있습니다.
- LoadBalancer는 클라우드 공급자의 로드 밸런서를 사용하여 서비스를 외부에 노출합니다.
서비스에서는 선택기를 사용하여 트래픽을 수신해야 하는 Pod를 식별합니다. 선택기는 Pod의 레이블과 일치하여 서비스에 속하는 포드를 결정합니다. 예: 선택기 app: myapp
이 있는 서비스는 app: myapp
레이블이 있는 모든 Pod로 트래픽을 라우팅합니다.
서비스 선택기와 일치하는 Pod의 현재 IP 주소를 반영하도록 끝점이 동적으로 업데이트됩니다. {product-name}은 이러한 엔드포인트를 유지 관리하고 서비스가 트래픽을 올바른 Pod로 라우팅하도록 합니다.
통신 흐름은 Kubernetes의 서비스가 트래픽을 적절한 Pod로 라우팅할 때 발생하는 단계 및 상호 작용을 나타냅니다. 서비스 간 통신에 대한 일반적인 통신 흐름은 다음과 같습니다.
서비스 생성: 서비스를 생성할 때 서비스 유형, 서비스가 수신 대기하는 포트, 선택기 레이블을 정의합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
DNS 확인: 각 포드에는 다른 Pod에서 서비스와 통신하는 데 사용할 수 있는 DNS 이름이 있습니다. 예를 들어 서비스의 이름이
my-app
네임스페이스에서my-service
인 경우 해당 DNS 이름은my-service.my-app.svc.cluster.local
입니다. - 트래픽 라우팅: Pod가 서비스의 DNS 이름으로 요청을 보내면 OpenShift Container Platform에서 해당 이름을 서비스의 ClusterIP로 확인합니다. 그런 다음 서비스는 끝점을 사용하여 트래픽을 선택기와 일치하는 포드 중 하나로 라우팅합니다.
- 부하 분산: 서비스는 기본 부하 분산도 제공합니다. 선택기와 일치하는 모든 Pod에 수신되는 트래픽을 배포합니다. 이렇게 하면 단일 Pod가 너무 많은 트래픽으로 압도되지 않습니다.
1.4.2.1. 예: service-to-pod 통신 제어 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에서 프런트 엔드와 백엔드의 두 가지 구성 요소가 있는 마이크로 서비스 기반 애플리케이션을 실행하고 있습니다. 프런트 엔드는 데이터를 가져오기 위해 백엔드와 통신해야 합니다.
프로세스
백엔드 서비스를 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 백엔드 pod를 구성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 프론트 엔드 통신을 설정합니다.
이제 프런트 엔드 Pod에서 DNS 이름
backend.default.svc.cluster.local
을 사용하여 백엔드 서비스와 통신할 수 있습니다. 이 서비스를 사용하면 트래픽이 백엔드 포드 중 하나로 라우팅됩니다.
서비스 간 통신은 Pod IP 관리의 복잡성을 추상화하고 클러스터 내에서 안정적이고 효율적인 통신을 보장합니다.