Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

네트워킹 개요

OpenShift Container Platform 4.20

OpenShift Container Platform의 기본 네트워킹 개념 및 일반 작업 이해

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform 내의 핵심 네트워킹 개념, 기본 아키텍처 및 일반 네트워킹 작업을 소개합니다.

1장. 네트워킹 이해
링크 복사

OpenShift Container Platform에서 탄력적이고 안전하며 확장 가능한 애플리케이션을 빌드하는 데 네트워킹을 이해하는 것이 중요합니다. 기본 pod-to-pod 통신에서 복잡한 트래픽 라우팅 및 보안 규칙에 이르기까지 애플리케이션의 모든 구성 요소는 네트워크를 기반으로 올바르게 작동합니다.

1.1. 핵심 네트워크 계층 및 구성 요소
링크 복사

Red Hat OpenShift Networking은 포드 네트워크와 서비스 네트워크 라는 두 가지 기본 계층을 기반으로 합니다. Pod 네트워크는 애플리케이션이 있는 위치입니다. 서비스 네트워크를 사용하면 애플리케이션에 안정적으로 액세스할 수 있습니다.

1.1.1. Pod 네트워크
링크 복사

pod 네트워크는 클러스터의 모든 pod가 고유한 IP 주소를 수신하는 플랫 네트워크 공간입니다. 이 네트워크는 CNI(Container Network Interface) 플러그인에서 관리합니다. CNI 플러그인은 각 pod를 클러스터 네트워크로 연결합니다.

이 설계를 사용하면 실행 중인 노드에 관계없이 포드가 IP 주소를 사용하여 서로 직접 통신할 수 있습니다. 그러나 이러한 Pod IP는 임시입니다. 즉, Pod가 삭제될 때 IP가 삭제되고 새 Pod가 생성될 때 새 IP 주소가 할당됩니다. 이로 인해 장기 통신을 위해 Pod IP 주소에 직접 의존해서는 안 됩니다.

1.1.2. 서비스 네트워크
링크 복사

서비스는 ClusterIP라는 단일 안정적인 가상 IP 주소와 Pod 논리 그룹에 대한 DNS 이름을 제공하는 네트워킹 오브젝트입니다.

요청이 서비스의 ClusterIP로 전송되면 OpenShift Container Platform은 해당 서비스를 지원하는 정상 pod 중 하나로 트래픽을 자동으로 로드 밸런싱합니다. Kubernetes 레이블과 선택기를 사용하여 어떤 Pod가 어떤 서비스에 속하는지 추적합니다. 이 추상화를 사용하면 애플리케이션에 도달하려는 애플리케이션에 영향을 주지 않고 개별 Pod를 생성하거나 삭제할 수 있기 때문에 애플리케이션의 복원력을 높일 수 있습니다.

1.2. 클러스터 내에서 트래픽 관리
링크 복사

애플리케이션은 클러스터 내에서 서로 통신해야 합니다. OpenShift Container Platform은 내부 트래픽을 위한 두 가지 기본 메커니즘을 제공합니다. 안정적인 연결을 위한 간단한 교환 및 강력한 서비스 검색을 위한 직접 pod-to-pod 통신입니다.

1.2.1. pod-to-pod 통신
링크 복사

Pod는 Pod 네트워크에서 할당한 고유 IP 주소를 사용하여 직접 통신합니다. 한 노드의 Pod는 NAT(네트워크 주소 변환) 없이 트래픽을 다른 노드의 Pod로 직접 보낼 수 있습니다. 이러한 직접 통신 모델은 데이터를 신속하게 교환해야 하는 서비스에 효율적입니다. 애플리케이션은 다른 Pod의 IP 주소를 대상으로 지정하여 연결을 설정할 수 있습니다.

1.2.2. DNS를 사용한 서비스 검색
링크 복사

Pod IP 주소는 임시이므로 Pod에 안정적인 방법이 필요합니다. OpenShift Container Platform은 기본 제공 DNS 서버인 CoreDNS 를 사용하여 이 서비스 검색을 제공합니다.

생성하는 모든 서비스는 안정적인 DNS 이름을 자동으로 수신합니다. 포드는 이 DNS 이름을 사용하여 서비스에 연결할 수 있습니다. DNS 시스템은 이름을 서비스의 안정적인 ClusterIP 주소로 확인합니다. 이 프로세스는 개별 Pod IP가 변경되는 경우에도 안정적인 통신을 보장합니다.

1.3. 클러스터로 들어오고 나가는 트래픽 관리
링크 복사

외부 사용자가 애플리케이션에 액세스하고 애플리케이션이 외부 서비스에 안전하게 액세스할 수 있는 방법이 필요합니다. OpenShift Container Platform에서는 이러한 트래픽 흐름을 클러스터 내외로 관리하는 몇 가지 툴을 제공합니다.

1.3.1. Ingress 및 Route 오브젝트를 사용하여 애플리케이션 노출
링크 복사

외부 트래픽이 클러스터 내부의 서비스에 도달하도록 허용하려면 Ingress 컨트롤러를 사용합니다. 이 구성 요소는 들어오는 요청을 올바른 애플리케이션으로 보내는 프런트문 역할을 합니다. 두 개의 기본 리소스 중 하나를 사용하여 트래픽 규칙을 정의합니다.

  • Ingress: 일반적으로 HTTP 및 HTTPS 트래픽용 서비스에 대한 외부 액세스를 관리하기 위한 표준 Kubernetes 리소스입니다.
  • 경로 오브젝트: Ingress와 동일한 기능을 제공하지만 고급 TLS 종료 옵션 및 트래픽 분할과 같은 추가 기능을 포함하는 리소스입니다. Route 오브젝트는 OpenShift Container Platform에 고유합니다.

1.3.2. 로드 밸런서를 사용하여 트래픽 분산
링크 복사

로드 밸런서는 트래픽을 클러스터로 전달하기 위한 고가용성 단일 IP 주소를 제공합니다. 일반적으로 클라우드 공급자의 클러스터 외부에서 실행되거나 베어 메탈 인프라에서 MetalLB를 사용하여 Ingress 컨트롤러를 실행하는 여러 노드에 수신되는 요청을 배포합니다.

이렇게 하면 단일 노드가 병목 현상이 발생하거나 오류가 발생하여 애플리케이션에 계속 액세스할 수 있습니다.

1.3.3. Egress 트래픽 제어
링크 복사

egress는 클러스터 내부의 Pod에서 발생되고 외부 시스템을 대상으로 하는 아웃바운드 트래픽을 나타냅니다. OpenShift Container Platform은 이를 관리하기 위한 몇 가지 메커니즘을 제공합니다.

  • EgressIP: 지정된 프로젝트의 모든 아웃바운드 트래픽에 예측 가능한 특정 소스 IP 주소를 할당할 수 있습니다. 이 기능은 특정 소스 IP를 허용해야 하는 방화벽이 있는 데이터베이스와 같은 외부 서비스에 액세스해야 하는 경우에 유용합니다.
  • 송신 라우터: 아웃바운드 트래픽의 게이트웨이 역할을 하는 전용 포드입니다. 제어되는 단일 종료 지점을 통해 연결을 라우팅할 수 있습니다.
  • 송신 방화벽: 모든 아웃바운드 트래픽에 대한 클러스터 수준 방화벽 역할을 합니다. Pod의 연결을 특정 외부 대상으로 명시적으로 허용하거나 거부하는 규칙을 생성할 수 있으므로 보안 상태가 향상됩니다.

1.4. 네트워크 트래픽 보안
링크 복사

OpenShift Container Platform은 통신할 수 있는 구성 요소를 제어하는 규칙을 생성하여 네트워크를 보호하는 툴을 제공합니다. 이는 주로 네트워크 정책 및 관리 네트워크 정책의 두 가지 유형의 정책 리소스를 통해 관리됩니다.

1.4.1. 네트워크 정책
링크 복사

네트워크 정책은 IP 주소 또는 포트 수준에서 트래픽 흐름을 제어할 수 있는 리소스입니다. 이러한 정책은 네임스페이스(프로젝트) 수준에서 작동합니다. 즉, 일반적으로 개발자 또는 프로젝트 관리자가 특정 애플리케이션을 보호하도록 관리합니다.

기본적으로 프로젝트의 모든 pod는 서로 자유롭게 통신할 수 있습니다. 그러나 NetworkPolicy 를 Pod에 적용하면 "default-deny" stance가 적용됩니다. 즉, 정책 규칙에서 명시적으로 허용하지 않는 모든 연결을 거부합니다. 레이블과 선택기를 사용하여 정책이 적용되는 Pod와 수신 및 송신 트래픽이 허용되는 포드를 정의합니다.

1.4.2. 관리 네트워크 정책
링크 복사

AdminNetworkPolicy 오브젝트는 더 강력한 클러스터 범위 버전의 NetworkPolicy 오브젝트입니다. 클러스터 관리자만 생성하고 관리할 수 있습니다.

관리 네트워크 정책은 표준 NetworkPolicy 오브젝트보다 우선 순위가 높습니다. 이를 통해 관리자는 자체 프로젝트의 사용자가 재정의할 수 없는 클러스터 전체 보안 규칙을 적용할 수 있습니다. 예를 들어 관리자는 AdminNetworkPolicy 를 사용하여 개발 네임스페이스와 프로덕션 네임스페이스 간의 모든 트래픽을 차단하거나 전체 클러스터에 대한 기본 보안 규칙을 적용할 수 있습니다.

2장. 호스트에 액세스
링크 복사

배스천 호스트(Bastion Host)를 생성하여 OpenShift Container Platform 인스턴스에 액세스하고 SSH(Secure Shell) 액세스 권한으로 컨트롤 플레인 노드에 액세스하는 방법을 알아봅니다.

OpenShift Container Platform 설치 관리자는 OpenShift Container Platform 클러스터에 프로비저닝된 Amazon EC2(Amazon Elastic Compute Cloud) 인스턴스에 대한 퍼블릭 IP 주소를 생성하지 않습니다. OpenShift Container Platform 호스트에 SSH를 사용하려면 다음 절차를 따라야 합니다.

프로세스

  1. openshift-install 명령으로 생성된 가상 프라이빗 클라우드(VPC)에 SSH로 액세스할 수 있는 보안 그룹을 만듭니다.
  2. 설치 관리자가 생성한 퍼블릭 서브넷 중 하나에 Amazon EC2 인스턴스를 생성합니다.

  3. 생성한 Amazon EC2 인스턴스와 퍼블릭 IP 주소를 연결합니다.

    OpenShift Container Platform 설치와는 달리, 생성한 Amazon EC2 인스턴스를 SSH 키 쌍과 연결해야 합니다. 이 인스턴스에서 사용되는 운영 체제는 중요하지 않습니다. 그저 인터넷을 OpenShift Container Platform 클러스터의 VPC에 연결하는 SSH 베스천의 역할을 수행하기 때문입니다. 사용하는 AMI(Amazon 머신 이미지)는 중요합니다. 예를 들어 RHCOS(Red Hat Enterprise Linux CoreOS)를 사용하면 설치 프로그램과 같이 Ignition을 통해 키를 제공할 수 있습니다.

  4. Amazon EC2 인스턴스를 프로비저닝한 후 SSH로 연결할 수 있는 경우 OpenShift Container Platform 설치와 연결된 SSH 키를 추가해야 합니다. 이 키는 베스천 인스턴스의 키와 다를 수 있지만 반드시 달라야 하는 것은 아닙니다.

    참고

    SSH 직접 액세스는 재해 복구 시에만 권장됩니다. Kubernetes API가 응답할 때는 권한 있는 Pod를 대신 실행합니다.

  5. oc get nodes를 실행하고 출력을 확인한 후 마스터 노드 중 하나를 선택합니다. 호스트 이름은 ip-10-0-1-163.ec2.internal과 유사합니다.

  6. Amazon EC2에 수동으로 배포한 베스천 SSH 호스트에서 해당 컨트롤 플레인 호스트에 SSH로 연결합니다. 설치 중 지정한 것과 동일한 SSH 키를 사용해야 합니다. 

    $ ssh -i <ssh-key-path> core@<master-hostname>
    Copy to Clipboard Toggle word wrap

3장. 네트워킹 대시보드
링크 복사

네트워킹 메트릭은 OpenShift Container Platform 웹 콘솔의 모니터링 → 대시보드의 대시보드에서 볼 수 있습니다.

3.1. Network Observability Operator
링크 복사

Network Observability Operator가 설치된 경우 Dashboards 드롭다운 목록에서 Netobserv 대시보드를 선택하여 네트워크 트래픽 지표 대시보드를 볼 수 있습니다. 이 대시보드에서 사용할 수 있는 메트릭에 대한 자세한 내용은 Network Observability 지표 대시보드를 참조하십시오.

3.2. 네트워킹 및 OVN-Kubernetes 대시보드
링크 복사

대시보드에서 일반 네트워킹 메트릭과 OVN-Kubernetes 지표를 모두 볼 수 있습니다.

일반 네트워킹 메트릭을 보려면 대시보드 드롭다운 목록에서 네트워킹/Linux Cryostat 통계 를 선택합니다. 대시보드에서 Network Utilization , Network Saturation , Network Saturation ) 의 다음 네트워킹 메트릭을 볼 수 있습니다.

OVN-Kubernetes 지표를 보려면 대시보드 드롭다운 목록에서 네트워킹/인프라 를 선택합니다. 네트워킹 구성,TCP Latency Probes,컨트롤 플레인 리소스, 작업자 리소스 등 OVN-Kuberenetes 메트릭을 볼 수 있습니다.

3.3. Ingress Operator 대시보드
링크 복사

대시보드에서 Ingress Operator가 처리하는 네트워킹 메트릭을 볼 수 있습니다. 여기에는 다음과 같은 메트릭이 포함됩니다.

  • 들어오고 나가는 대역폭
  • HTTP 오류율
  • HTTP 서버 응답 대기 시간

이러한 Ingress 지표를 보려면 대시보드 드롭다운 목록에서 네트워킹/Ingress 를 선택합니다. 다음 카테고리에 대한 Ingress 메트릭을 볼 수 있습니다. 경로당 상위 10 개,네임스페이스당 상위 10 개, 하드 당 상위 10개.

4장. CIDR 범위 정의
링크 복사

클러스터에서 OVN-Kubernetes를 사용하는 경우 CIDR(Classless Inter-Domain Routing) 서브넷에 대해 겹치지 않는 범위를 지정해야 합니다.

중요

OpenShift Container Platform 4.17 이상 버전의 경우 클러스터는 IPv4에 169.254.0.0/17 을 사용하고 IPv6의 경우 fd69::/112 를 기본 masquerade 서브넷으로 사용합니다. 사용자는 이러한 범위를 피해야 합니다. 업그레이드된 클러스터의 경우 기본 masquerade 서브넷이 변경되지 않습니다.

작은 정보

Red Hat OpenShift Network 계산기 를 사용하여 클러스터 생성 중에 CIDR 범위를 설정하기 전에 네트워킹 요구 사항을 결정할 수 있습니다.

계산기를 사용하려면 Red Hat 계정이 있어야 합니다.

다음 서브넷 유형 및 OVN-Kubernetes를 사용하는 클러스터에는 필수입니다.

  • join: 조인 스위치를 사용하여 게이트웨이 라우터를 분산 라우터에 연결합니다. 조인 스위치는 분산 라우터의 IP 주소 수를 줄입니다. OVN-Kubernetes 플러그인을 사용하는 클러스터의 경우 전용 서브넷의 IP 주소가 조인 스위치에 연결된 논리 포트에 할당됩니다.
  • masquerade: 로드 밸런서가 라우팅 결정을 내린 후 노드에서 hairpin 트래픽이 동일한 노드로 전송되는 동일한 소스 및 대상 IP 주소에 대한 충돌을 방지합니다.
  • 전송 스위치는 클러스터의 모든 노드에 걸쳐 있는 분산 스위치 유형입니다. 전송 스위치는 다른 영역 간에 트래픽을 라우팅합니다. OVN-Kubernetes 플러그인을 사용하는 클러스터의 경우 전용 서브넷의 IP 주소가 전송 스위치에 연결된 논리 포트에 할당됩니다.
참고

설치 후 작업으로 클러스터의 조인, 마스커레이드 및 전송 CIDR 범위를 변경할 수 있습니다.

OpenShift Container Platform 4.14 이상 버전의 기본 네트워크 공급자인 OVN-Kubernetes는 내부적으로 다음 IP 주소 서브넷 범위를 사용합니다.

  • V4JoinSubnet: 100.64.0.0/16
  • V6JoinSubnet: fd98::/64
  • V4TransitSwitchSubnet: 100.88.0.0/16
  • V6TransitSwitchSubnet: fd97::/64
  • defaultV4MasqueradeSubnet: 169.254.0.0/17
  • defaultV6MasqueradeSubnet: fd69::/112
중요

이전 목록에는 조인, 전송, 마스커레이드 IPv4 및 IPv6 주소 서브넷이 포함됩니다. 클러스터에서 OVN-Kubernetes를 사용하는 경우 클러스터 또는 인프라의 다른 CIDR 정의에 이러한 IP 주소 서브넷 범위를 포함하지 마십시오.

4.1. 머신 CIDR
링크 복사

CIDR(Machine classless inter-domain routing) 필드에서 시스템 또는 클러스터 노드의 IP 주소 범위를 지정해야 합니다.

참고

클러스터를 생성한 후에는 머신 CIDR 범위를 변경할 수 없습니다.

기본값은 10.0.0.0/16 입니다. 이 범위는 연결된 네트워크와 충돌해서는 안 됩니다.

4.2. 서비스 CIDR
링크 복사

Service CIDR 필드에서 서비스의 IP 주소 범위를 지정해야 합니다. 범위는 워크로드를 수용할 수 있을 만큼 커야 합니다. 주소 블록은 클러스터 내에서 액세스한 외부 서비스와 겹치지 않아야 합니다. 기본값은 172.30.0.0/16입니다.

4.3. Pod CIDR
링크 복사

Pod CIDR 필드에서 Pod의 IP 주소 범위를 지정해야 합니다.

Pod CIDR은 clusterNetwork CIDR 및 클러스터 CIDR과 동일합니다. 범위는 워크로드를 수용할 수 있을 만큼 커야 합니다. 주소 블록은 클러스터 내에서 액세스한 외부 서비스와 겹치지 않아야 합니다. 기본값은 10.128.0.0/14 입니다. 클러스터 설치 후 범위를 확장할 수 있습니다.

4.4. 호스트 접두사
링크 복사

hostPrefix 매개변수에서는 개별 머신에 예약된 Pod에 할당된 서브넷 접두사 길이를 지정해야 합니다. 호스트 접두사는 각 시스템의 Pod IP 주소 풀을 결정합니다.

예를 들어 호스트 접두사가 /23 으로 설정된 경우 각 시스템에는 Pod CIDR 주소 범위의 /23 서브넷이 할당됩니다. 기본값은 /23 으로, 노드당 510 클러스터 노드 및 510 Pod IP 주소를 허용합니다.

clusterNetwork.cidr 매개변수를 10.128.0.0/16 으로 설정하는 다른 예를 살펴보겠습니다. 클러스터의 전체 주소 공간을 정의합니다. 이렇게 하면 클러스터에 65536 IP 주소 풀이 할당됩니다. 그런 다음 hostPrefix 매개변수를 /23 로 설정하면 클러스터의 각 노드에 서브넷 슬라이스를 정의합니다. 여기서 /23 슬라이스는 /16 서브넷 네트워크의 서브넷이 됩니다. 이렇게 하면 각 노드에 512 IP 주소를 할당합니다. 여기서 네트워킹 및 브로드캐스트 목적으로 2개의 IP 주소가 예약되어 있습니다. 다음 예제 계산에서는 이러한 IP 주소 수를 사용하여 클러스터에 대해 생성할 수 있는 최대 노드 수를 결정합니다. 

65536 / 512 = 128
Copy to Clipboard Toggle word wrap

Red Hat OpenShift Network 계산기 를 사용하여 클러스터의 최대 노드 수를 계산할 수 있습니다.

4.5. 호스팅된 컨트롤 플레인의 CIDR 범위
링크 복사

OpenShift Container Platform에 호스팅되는 컨트롤 플레인을 배포하려면 다음과 같은 필수 Classless Inter-Domain Routing (CIDR) 서브넷 범위를 사용합니다.

  • v4InternalSubnet: 100.65.0.0/16 (OVN-Kubernetes)
  • clusterNetwork: 10.132.0.0/14 (pod 네트워크)
  • serviceNetwork: 172.31.0.0/16

OpenShift Container Platform CIDR 범위 정의에 대한 자세한 내용은 "CIDR 범위 정의"를 참조하십시오.

Legal Notice
링크 복사

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat