다음을 통해 공유

Azure Red Hat OpenShift에 대한 네트워크 토폴로지 및 연결 고려 사항

  • 아티클

Azure Red Hat OpenShift 랜딩 존 가속기를 사용하는 경우 네트워크 토폴로지 및 연결에 대한 디자인 고려 사항 및 권장 사항을 검토합니다.

디자인 고려 사항

  • Azure Red Hat OpenShift에는 기본 서브넷 및 보조 서브넷이 필요합니다.

    • 기본 서브넷을 사용하여 클러스터의 마스터 노드를 배포합니다.
    • 보조 서브넷을 사용하여 클러스터의 작업자 노드를 배포합니다.
    • 보조 서브넷과 주 서브넷은 모두 최소 /27 경로여야 합니다.
    • 클러스터를 배포한 후에는 보조 서브넷 또는 주 서브넷을 변경할 수 없습니다.
    • 주 서브넷과 보조 서브넷에는 연결된 네트워크 보안 그룹이 있을 수 없습니다. Azure Red Hat OpenShift 클러스터는 네트워크 보안 그룹을 자동으로 만들고 관리합니다.
    • 보조 서브넷 및 기본 서브넷은 온-프레미스 네트워크 또는 Azure의 다른 네트워크와 겹칠 수 없습니다.

  • 클러스터 크기 조정을 지원하기 위해 IP 주소와 가상 네트워크 서브넷의 크기를 신중하게 계획합니다. 노드를 추가해야 할 수도 있습니다.

  • 공용 또는 내부 부하 분산 장치를 사용하여 Azure Red Hat OpenShift 서비스 및 경로를 노출할 수 있습니다. 보조 노드와 동일한 서브넷에 내부 부하 분산 장치를 설정합니다. 제한된 송신 클러스터에서는 비대칭 라우팅으로 인해 공용 부하 분산 장치를 사용할 수 없습니다.

  • Azure Red Hat OpenShift는 CoreDNS를 사용하여 클러스터에서 실행되는 Pod에 이름 확인을 제공합니다.

    • CoreDNS 는 클러스터 내부 도메인을 직접 확인합니다.
    • Azure Red Hat OpenShift는 가상 네트워크의 사용자 지정 DNS 서버도 지원합니다.
    • 다른 도메인은 Azure Virtual Network에서 구성하는 DNS 서버로 전달됩니다. DNS 서버는 기본 Azure DNS 확인자 또는 가상 네트워크 수준에서 구성하는 사용자 지정 DNS 서버가 됩니다.
    • Azure Red Hat OpenShift CoreDNS에서 DNS 전달을 사용자 지정할 수 있습니다.
    • 가상 네트워크에 사용자 지정 DNS 서버가 구성되지 않은 경우 Azure Red Hat OpenShift는 기본 Azure DNS 확인자를 사용합니다.

    DNS에 대한 자세한 내용은 Azure 프라이빗 엔드포인트 DNS 구성을 참조하세요.

  • Azure Firewall 또는 네트워크 가상 어플라이언스 클러스터를 통해 아웃바운드(송신) 네트워크 트래픽을 보낼 수 있습니다.

  • 기본적으로 Azure Red Hat OpenShift 클러스터의 모든 Pod는 제한 없이 트래픽을 보내고 받을 수 있습니다. 프로젝트의 모든 Pod는 다른 Pod 및 네트워크 엔드포인트에서 액세스할 수 있습니다. 프로젝트에서 하나 이상의 Pod를 격리하려면 프로젝트에서 허용되는 들어오는 연결을 나타내는 개체를 만들 NetworkPolicy 수 있습니다. Red Hat OpenShift SDN(소프트웨어 정의 네트워킹)은 기본 네트워크 격리 모드에서 네트워크 정책 사용을 지원합니다.

  • 서비스 메시는 트래픽 관리, 복원력, 정책, 보안, 강력한 ID, 관찰 가능성 등의 기능을 제공합니다. Red Hat OpenShift Service Mesh에 대한 자세한 내용은 서비스 메시 및 Istio 차이점을 참조 하세요.

  • Azure Traffic Manager 및 Azure Front Door와 같은 글로벌 부하 분산 메커니즘은 여러 클러스터에서 잠재적으로 다른 Azure 지역에서 트래픽을 라우팅하여 복원력을 높입니다.

프라이빗 클러스터

Azure Red Hat OpenShift API 클러스터 IP 주소는 공용 또는 프라이빗 주소일 수 있습니다. 프라이빗 클러스터는 프라이빗 IP 주소를 통해 Azure Red Hat OpenShift API를 노출하지만 퍼블릭 주소를 통해 노출하지 않습니다. Azure Red Hat OpenShift API는 IP 주소를 통해 액세스해서는 안 됩니다. 대신 FQDN(정규화된 도메인 이름)을 통해 Azure Red Hat OpenShift API에 액세스합니다. Azure DNS는 Azure Red Hat OpenShift API FQDN을 해당 IP 주소로 확인합니다.

입증된 Azure 랜딩 존 검증 사례에 따라 Azure 워크로드에 대한 DNS 확인은 연결 구독에 배포된 중앙 집중식 DNS 서버에서 제공됩니다. Azure DNS 서버는 허브 가상 네트워크 또는 Azure Virtual WAN 인스턴스에 연결된 공유 서비스 가상 네트워크에 있습니다. DNS 서버는 Azure DNS(IP 주소 168.63.129.16)를 사용하여 Azure 특정 및 공용 이름을 조건부로 확인합니다. 서버는 회사 DNS 서버를 사용하여 개인 이름을 확인합니다. 이 연결 모델은 일반적이며 프라이빗 엔드포인트를 사용하는 경우 다른 Azure 리소스에 대한 프라이빗 액세스를 허용하는 것이 중요합니다.

프라이빗 클러스터의 네트워크를 보여 주는 다이어그램.

애플리케이션 사용자에서 클러스터로 트래픽

들어오는(수신) 컨트롤러를 사용하여 Azure Red Hat OpenShift 클러스터에서 실행되는 애플리케이션을 노출합니다.

  • 수신 컨트롤러는 복잡성이 약간 증가하는 애플리케이션 수준 라우팅을 제공합니다.
  • Azure Red Hat OpenShift는 클러스터의 노출된 애플리케이션에 대한 액세스를 간소화하는 일반 DNS 항목을 만듭니다. DNS 항목의 예는 다음과 같습니다 *.apps.<cluster-ID>.<region>.aroapp.io. 프라이빗 클러스터가 애플리케이션에 대한 트래픽을 라우팅하는 데 유용합니다.
  • Azure Red Hat OpenShift는 기본 제공 수신 컨트롤러 및 경로를 제공합니다.
  • Azure Front Door에서 Azure Red Hat OpenShift 수신을 사용할 수 있습니다.
  • 비대칭 라우팅을 방지하려면 송신 필터링 디자인에 구성을 정렬합니다. UDR은 잠재적으로 비대칭 라우팅을 일으킬 수 있습니다.
  • 시나리오에 TLS 종료가 필요한 경우 TLS 인증서를 관리하는 방법을 고려합니다.

Important

Azure Firewall을 사용하여 송신 트래픽을 제한하고 모든 송신 트래픽을 강제 적용하는 UDR을 만드는 경우 수신 트래픽을 올바르게 허용하도록 Azure Firewall에 적절한 DNAT(대상 네트워크 주소 변환) 규칙을 만들어야 합니다. UDR과 함께 Azure Firewall을 사용하면 비대칭 라우팅으로 인해 수신 설정이 손상됩니다. 이 문제는 Azure Red Hat OpenShift 서브넷에 방화벽의 개인 IP 주소로 가는 기본 경로가 있지만 공용 부하 분산 장치(수신 또는 형식 Load Balancer의 Kubernetes 서비스)를 사용하는 경우에 발생합니다. 이 경우 들어오는 부하 분산 장치 트래픽은 해당 공용 IP 주소를 통해 수신되지만 반환 경로는 방화벽의 개인 IP 주소를 거칩니다. 방화벽은 상태 저장이므로 방화벽이 설정된 세션을 검색하지 않으므로 반환되는 패킷을 삭제합니다. Azure Firewall을 수신 또는 서비스 부하 분산 장치와 통합하는 방법을 알아보려면 Azure Firewall을 Azure 표준 Load Balancer와 통합을 참조하세요.

다음 단계에서는 Azure Red Hat OpenShift 프라이빗 클러스터 및 수신 컨트롤러에서 Azure Front Door를 사용하는 경우의 흐름을 설명합니다.

  1. 공용 인터넷의 클라이언트는 Azure Front Door를 가리키는 애플리케이션의 DNS 이름을 확인합니다.
  2. Azure Front Door는 Azure Private Link 서비스를 사용하여 Azure 내부 네트워크 부하 분산 장치의 개인 IP 주소에 액세스하고 Azure Red Hat OpenShift 수신 컨트롤러의 애플리케이션에 액세스합니다.

다음 단계에서는 Azure Red Hat OpenShift 프라이빗 클러스터에 액세스하는 비 웹 애플리케이션의 흐름을 설명합니다.

  1. 공용 인터넷의 클라이언트는 Azure Firewall 또는 네트워크 가상 어플라이언스의 공용 IP 주소를 가리키는 애플리케이션의 DNS 이름을 확인합니다.
  2. Azure Firewall 또는 네트워크 가상 어플라이언스는 Azure 내부 네트워크 부하 분산 장치의 개인 IP 주소를 사용하여 Azure Red Hat OpenShift 수신 컨트롤러의 애플리케이션에 액세스하여 트래픽(DNAT)을 Azure Red Hat OpenShift 프라이빗 클러스터로 전달합니다.

Azure Red Hat OpenShift Pod에서 백 엔드 서비스로 트래픽

Azure Red Hat OpenShift 클러스터 내에서 실행되는 Pod는 Azure Storage, Azure Key Vault, Azure SQL Database 및 Azure Cosmos DB와 같은 백 엔드 서비스에 액세스해야 할 수 있습니다. 가상 네트워크 서비스 엔드포인트 및 Azure Private Link를 사용하여 이러한 Azure 관리형 서비스에 대한 연결을 보호할 수 있습니다.

백 엔드 트래픽에 Azure 프라이빗 엔드포인트를 사용하는 경우 Azure 서비스에 대한 DNS 확인을 위해 Azure 프라이빗 DNS 영역을 사용할 수 있습니다. 전체 환경에 대한 DNS 확인자는 허브 가상 네트워크(또는 가상 WAN 연결 모델을 사용하는 경우 공유 서비스 가상 네트워크)에 있으므로 연결 구독에서 이러한 프라이빗 영역을 만듭니다. 프라이빗 서비스의 FQDN을 확인하는 데 필요한 A 레코드를 만들려면 연결 구독의 프라이빗 DNS 영역을 애플리케이션 구독의 프라이빗 엔드포인트와 연결할 수 있습니다. 이 작업을 수행하려면 해당 구독에 특정 권한이 필요합니다.

A-레코드를 수동으로 만들 수 있지만 프라이빗 DNS 영역을 프라이빗 엔드포인트와 연결하면 구성이 잘못되기 쉬운 설정이 발생합니다.

프라이빗 엔드포인트를 통해 노출되는 Azure PaaS(Platform as a Service) 서비스에 대한 Azure Red Hat OpenShift Pod의 백 엔드 연결은 다음 시퀀스를 따릅니다.

  1. Azure Red Hat OpenShift Pod는 Azure Red Hat OpenShift 가상 네트워크에서 사용자 지정 DNS 서버로 정의된 연결 구독의 중앙 DNS 서버를 사용하여 Azure PaaS의 FQDN을 확인합니다.
  2. 확인된 IP 주소는 Azure Red Hat OpenShift Pod에서 직접 액세스되는 프라이빗 엔드포인트의 개인 IP 주소입니다.

Azure Red Hat OpenShift 클러스터가 Azure Firewall을 사용하여 송신 필터링하도록 구성된 경우에도 Azure Red Hat OpenShift Pod와 프라이빗 엔드포인트 간의 트래픽은 기본적으로 허브 가상 네트워크(또는 Virtual WAN을 사용하는 경우 보안 가상 허브)의 Azure Firewall 인스턴스를 통과하지 않습니다. 프라이빗 엔드포인트는 Azure Red Hat OpenShift가 배포되는 애플리케이션 가상 네트워크의 서브넷에 경로를 만듭니다 /32 .

디자인 권장 사항

  • 보안 정책에서 Azure Red Hat OpenShift API 에 대한 개인 IP 주소를 사용해야 하는 경우 프라이빗 Azure Red Hat OpenShift 클러스터를 배포합니다.
  • 중앙 집중식 구독에서 Azure Firewall 또는 웹 애플리케이션 방화벽을 사용하지 않는 한 Azure DDoS Protection을 사용하여 Azure Red Hat OpenShift 클러스터에 사용하는 가상 네트워크를 보호합니다.
  • Azure Virtual WAN 또는 허브 및 스포크 아키텍처, Azure DNS 영역 및 자체 DNS 인프라를 사용하여 전체 네트워크 설정에 연결된 DNS 구성을 사용합니다.
  • Azure Private Link를 사용하여 네트워크 연결을 보호하고 Azure Storage, Azure Container Registry, Azure SQL Database 및 Azure Key Vault와 같은 Private Link를 지원하는 다른 관리되는 Azure 서비스에 대한 프라이빗 IP 기반 연결을 사용합니다.
  • 수신 컨트롤러를 사용하여 고급 HTTP 라우팅 및 보안을 제공하고 애플리케이션에 단일 엔드포인트를 제공합니다.
  • 수신을 사용하도록 구성하는 모든 웹 애플리케이션은 TLS 암호화를 사용해야 하며 암호화되지 않은 HTTP에 대한 액세스를 허용해서는 안 됩니다.
  • 웹 애플리케이션 방화벽과 함께 Azure Front Door를 사용하여 Azure Red Hat OpenShift 애플리케이션을 인터넷에 안전하게 게시합니다.
  • 보안 정책에서 Azure Red Hat OpenShift 클러스터에서 생성된 모든 아웃바운드 인터넷 트래픽을 검사해야 하는 경우 Azure Firewall 또는 관리되는 허브 가상 네트워크에 배포된 타사 네트워크 가상 어플라이언스를 사용하여 송신 네트워크 트래픽을 보호합니다. 자세한 내용은 Azure Red Hat OpenShift 클러스터에 대한 송신 트래픽 제어를 참조 하세요.
  • 비 웹 애플리케이션에 대한 기본 계층 대신 Azure Load Balancer 표준 계층을 사용합니다.

다음 단계