검색

2.3. Telco 코어 참조 설계 사양

download PDF

2.3.1. Telco RAN DU 4.15 참조 설계 개요

Telco 코어 참조 설계 사양(RDS)은 상용 하드웨어에서 실행되는 OpenShift Container Platform 클러스터를 구성하여 통신 핵심 워크로드를 호스팅합니다.

2.3.1.1. 통신 코어를 위한 OpenShift Container Platform 4.15 기능

OpenShift Container Platform 4.15에 포함되어 있고 telco core reference design specification (RDS)에 의해 활용되는 다음 기능이 추가되거나 업데이트되었습니다.

표 2.9. OpenShift Container Platform 4.15의 telco core를 위한 새로운 기능
기능설명

IPv6 네트워크에 대한 다중 네트워크 정책 지원

이제 IPv6 네트워크에 대한 다중 네트워크 정책을 생성할 수 있습니다. 자세한 내용은 IPv6 네트워크에서 다중 네트워크 정책 지원을 참조하십시오.

2.3.2. Telco 코어 4.15 사용 모델 개요

Telco 코어 참조 설계 사양(RDS)은 신호 및 집계와 같은 컨트롤 플레인 기능을 포함하여 대규모 통신 애플리케이션을 지원하는 플랫폼을 설명합니다. 또한 몇 가지 중앙 집중식 데이터 플레인 기능(예: 사용자 플레인 기능(UPF))이 포함되어 있습니다. 이러한 기능에는 일반적으로 확장성, 복잡한 네트워킹 지원, 탄력적 소프트웨어 정의 스토리지 및 RAN과 같은 대규모 배포보다 제한된 성능 요구 사항이 필요합니다.

Telco core 사용 모델 아키텍처

Use model architecture

통신 핵심 기능에 대한 네트워킹 사전 요구 사항은 다양하며 다양한 네트워킹 속성 및 성능 벤치마크를 포함합니다. IPv6는 필수이며 이중 스택 구성이 우선합니다. 특정 기능에는 최대 처리량 및 트랜잭션 속도가 필요하며 DPDK와 같은 사용자 플레인 네트워킹 지원이 필요합니다. 다른 기능은 기존의 클라우드 네이티브 패턴을 준수하고 OVN-K, 커널 네트워킹 및 로드 밸런싱과 같은 솔루션을 사용할 수 있습니다.

Telco 코어 클러스터는 RT(Non real-time) 커널로 구성된 작업자 노드가 있는 표준 3개의 컨트롤 플레인 클러스터로 구성됩니다. 다양한 네트워킹 및 성능 요구 사항이 있는 워크로드를 지원하기 위해 MachineConfigPool CR을 사용하여 작업자 노드를 분할합니다. 예를 들어, 이는 비사용자 데이터 플레인 노드를 높은 처리량 노드에서 분리하기 위해 수행됩니다. 필요한 통신 운영 기능을 지원하기 위해 클러스터에는 표준 OLM(Operator Lifecycle Manager) Day 2 Operator 세트가 설치되어 있습니다.

2.3.2.1. 공통 기준 모델

다음 구성 및 사용 모델 설명은 모든 통신 코어 사용 사례에 적용됩니다.

Cluster

클러스터는 다음 요구 사항을 준수합니다.

  • 고가용성 (3+ 감독 노드) 컨트롤 플레인
  • 예약할 수 없는 슈퍼바이저 노드
스토리지
코어 사용 사례에는 외부 OpenShift Data Foundation에서 제공하는 영구 스토리지가 필요합니다. 자세한 내용은 "참조 코어 설계 구성 요소"의 "스토리지" 섹션을 참조하십시오.
네트워킹

Telco 핵심 클러스터 네트워킹은 다음 요구 사항을 준수합니다.

  • 듀얼 스택 IPv4/IPv6
  • 완전히 연결이 끊긴: 클러스터는 라이프사이클의 어느 시점에서도 공용 네트워킹에 액세스할 수 없습니다.
  • 다중 네트워크: 세그먼트화된 네트워킹은 OAM, 신호 처리 및 스토리지 트래픽 간에 격리를 제공합니다.
  • 클러스터 네트워크 유형: IPv6 지원에 OVN-Kubernetes가 필요합니다.

코어 클러스터에는 기본 RHCOS, SR-IOV Operator, 로드 밸런서 및 다음 "네트워크" 섹션에 설명된 기타 구성 요소에서 지원되는 여러 네트워킹 계층이 있습니다. 높은 수준에서 이러한 계층은 다음과 같습니다.

  • 클러스터 네트워킹: 클러스터 네트워크 구성이 정의되고 설치 구성을 통해 적용됩니다. 구성 업데이트는 NMState Operator를 통해 2일 차에 수행할 수 있습니다. 초기 구성을 사용하여 다음을 설정할 수 있습니다.

    • 호스트 인터페이스 구성
    • A/A Bonding(LACP(Link Aggregation Control Protocol))
  • 보조 또는 추가 네트워크: OpenShift CNI는 네트워크 additionalNetworks 또는 NetworkAttachmentDefinition CR을 통해 구성됩니다.

    • MACVLAN
  • 애플리케이션 워크로드: 사용자 플레인 네트워킹이 클라우드 네이티브 네트워크 기능(CNF)에서 실행되고 있습니다.
서비스 메시
통신 CNF의 서비스 메시 사용은 매우 일반적입니다. 모든 코어 클러스터에는 Service Mesh 구현이 포함되어야 합니다. 서비스 메시 구현 및 구성은 이 사양의 범위를 벗어납니다.
2.3.2.1.1. 엔지니어링 고려 사항 일반적인 사용 모델

다음 엔지니어링 고려 사항은 일반적인 사용 모델과 관련이 있습니다.

작업자 노드
  • Intel 3세대 Xeon(IceLake) 프로세서 이상에서 작업자 노드가 실행됩니다. 또는 Skylake 또는 이전 프로세서를 사용하는 경우 Spectre와 같은 보안 취약점에 대한 완화 조치를 비활성화해야 합니다. 이렇게 하지 않으면 트랜잭션 성능이 40%를 크게 줄일 수 있습니다.
  • IRQ Balancing은 작업자 노드에서 활성화됩니다. PerformanceProfilegloballyDisableIrqLoadBalancing: false 를 설정합니다. 보장된 QoS Pod는 "참조 코어 설계 구성 요소" 섹션의 "CPU 파티셔닝 및 성능 튜닝" 섹션에 설명된 대로 격리를 보장하기 위해 주석이 지정됩니다.
모든 노드
  • Hyper-Threading은 모든 노드에서 사용 가능
  • CPU 아키텍처는 x86_64 전용입니다.
  • 노드가 주식 (RT가 아닌) 커널을 실행하고 있습니다.
  • 노드가 워크로드 파티셔닝을 위해 구성되지 않음

전원 관리와 최대 성능 간의 노드 구성의 균형은 클러스터 의 MachineConfigPool 에 따라 다릅니다. 이 구성은 MachineConfigPool 내의 모든 노드에 일관되게 유지됩니다.

CPU 파티셔닝
CPU 파티션은 PerformanceProfile을 사용하여 구성되며 MachineConfigPool 에 따라 적용됩니다. "참조 코어 설계 구성 요소"의 "CPU 파티셔닝 및 성능 튜닝" 섹션을 참조하십시오.
2.3.2.1.2. 애플리케이션 워크로드

핵심 클러스터에서 실행되는 애플리케이션 워크로드에는 고성능 네트워킹 CNF와 기존의 최적의 Pod 워크로드 또는 버스트 Pod 워크로드가 혼합되어 있을 수 있습니다.

보장된 QoS 예약은 성능 또는 보안 요구 사항으로 인해 CPU를 독점적 또는 전용으로 사용해야 하는 Pod에서 사용할 수 있습니다. 일반적으로 DPDK와 함께 사용자 플레인 네트워킹을 활용하는 고성능 및 대기 시간에 민감한 CNF(Cloud Native Functions)를 호스팅하는 Pod는 전체 CPU의 독점적인 사용률이 필요합니다. 이는 노드 튜닝 및 QoS(Quality of Service) 스케줄링을 통해 수행됩니다. CPU를 독점적으로 사용해야 하는 Pod의 경우 하이퍼 스레딩 시스템의 잠재적 영향을 인식하고 전체 코어 (2 하이퍼스레드)를 Pod에 할당해야 하는 경우 2 CPU의 배수를 요청하도록 구성합니다.

높은 처리량과 짧은 대기 시간 네트워킹이 필요하지 않은 네트워크 기능을 실행하는 Pod는 일반적으로 best-effort 또는 burstable QoS로 예약되며 전용 또는 분리된 CPU 코어가 필요하지 않습니다.

제한 설명
  • CNF 애플리케이션은 최신 버전의 Red Hat Best Practices for Kubernetes 가이드를 준수해야 합니다.
  • best-effort 및 burstable QoS Pod가 혼합된 경우

    • 보장된 QoS Pod를 사용할 수 있지만 PerformanceProfile 에서 예약 및 분리된 CPU의 올바른 구성이 필요합니다.
    • 보장된 QoS Pod에는 CPU를 완전히 분리하기 위한 주석이 포함되어야 합니다.
    • 최상의 작업 및 버스블 Pod는 CPU를 독점적으로 사용할 수 없습니다. 다른 워크로드, 운영 체제 데몬 또는 커널 작업에서 워크로드를 선점할 수 있습니다.
  • 실행 가능한 대안이 없는 한 exec 프로브를 피해야 합니다.

    • CNF에서 CPU 고정을 사용하는 경우 exec 프로브를 사용하지 마십시오.
    • 다른 프로브 구현(예: httpGet/tcpSocket )을 사용해야 합니다.
참고

시작 프로브에는 지속적인 상태 작업 중에 최소한의 리소스가 필요합니다. exec 프로브의 제한은 주로 liveness 및 readiness 프로브에 적용됩니다.

워크로드 신호
  • 신호 처리 워크로드는 일반적으로 SCTP, REST, gRPC 또는 유사한 TCP 또는 UDP 프로토콜을 사용합니다.
  • TPS(초당 트랜잭션)는 MACVLAN 또는 SR-IOV로 구성된 보조 CNI(multus)를 사용하여 수십만 개의 순서로 사용됩니다.
  • 전송 워크로드는 guaranteed 또는 burstable QoS가 있는 Pod에서 실행됩니다.

2.3.3. Telco 핵심 참조 설계 구성 요소

다음 섹션에서는 통신 핵심 워크로드를 실행하기 위해 클러스터를 구성하고 배포하는 데 사용하는 다양한 OpenShift Container Platform 구성 요소 및 구성에 대해 설명합니다.

2.3.3.1. CPU 파티셔닝 및 성능 튜닝

이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
CPU 파티셔닝을 사용하면 중요한 워크로드를 일반 목적, 보조 프로세스, 인터럽트 및 드라이버 작업 대기열과 분리하여 성능과 대기 시간을 개선할 수 있습니다. 이러한 보조 프로세스에 할당된 CPU를 다음 섹션에서 예약해야 합니다. 하이퍼 스레딩 시스템에서 CPU는 하나의 하이퍼스레드입니다.
제한 및 요구사항
  • 운영 체제에는 커널 네트워킹을 포함한 모든 지원 작업을 수행하려면 일정 양의 CPU가 필요합니다.

    • DPDK(사용자 플레인 네트워킹 애플리케이션)만 있는 시스템에는 운영 체제 및 인프라 구성 요소를 위해 예약된 코어(2개의 하이퍼 스레딩)가 하나 이상 필요합니다.
  • 하이퍼 스레딩이 활성화된 시스템은 항상 모든 코어 형제 스레드를 동일한 CPU 풀에 배치해야 합니다.
  • 예약 및 분리된 코어 세트에는 모든 CPU 코어가 포함되어야 합니다.
  • 각 NUMA 노드의 코어 0은 예약된 CPU 세트에 포함되어야 합니다.
  • 격리된 코어는 인터럽트의 영향을 받을 수 있습니다. 보장된 QoS Pod에 CPU를 완전히 사용해야 하는 경우 다음 주석을 Pod에 연결해야 합니다.

    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
    irq-load-balancing.crio.io: "disable"
  • PerformanceProfile.workloadHints.perPodPowerManagement 를 사용하여 Pod별 전원 관리를 활성화하면 보장된 QoS Pod에 CPU를 완전히 사용해야 하는 경우 다음 주석도 Pod에 연결해야 합니다.

    cpu-c-states.crio.io: "disable"
    cpu-freq-governor.crio.io: "performance"
엔지니어링 고려 사항
  • 필요한 최소 예약 용량(systemReserved) 은 "OpenShift 4 노드에서 시스템을 예약하는 데 어느 정도의 CPU 및 메모리 양을 예약하는 것이 좋습니다.
  • 실제 필수 예약된 CPU 용량은 클러스터 구성 및 워크로드 특성에 따라 다릅니다.
  • 이 예약된 CPU 값은 전체 코어(2하이퍼 스레드) 정렬으로 반올림해야 합니다.
  • CPU 파티셔닝을 변경하면 MCP의 노드를 드레이닝하고 재부팅합니다.
  • 예약된 CPU는 OpenShift 노드의 할당 가능한 용량에서 제거되므로 예약된 CPU는 Pod 밀도를 줄입니다.
  • 워크로드를 실시간으로 사용할 수 있는 경우 실시간 워크로드 힌트를 활성화해야 합니다.
  • IIRQ(Interrupt Request) 선호도 지원이 없는 하드웨어는 분리된 CPU에 영향을 미칩니다. 보장된 CPU QoS가 있는 Pod에서 할당된 CPU를 완전히 사용하려면 서버의 모든 하드웨어가 IRQ 선호도를 지원해야 합니다.
  • OVS는 네트워크 트래픽 요구 사항에 맞게 cpuset 구성을 동적으로 관리합니다. 기본 CNI에서 높은 네트워크 처리량을 처리하기 위해 추가 CPU를 예약할 필요가 없습니다.

2.3.3.2. 서비스 메시

설명
통신 핵심 CNF에는 일반적으로 서비스 메시 구현이 필요합니다. 필요한 특정 기능 및 성능은 애플리케이션에 따라 다릅니다. 서비스 메시 구현 및 구성을 선택하는 것은 이 문서의 범위를 벗어납니다. Pod 네트워킹에 도입된 추가 대기 시간을 포함하여 클러스터 리소스 사용률 및 성능에 대한 서비스 메시의 영향은 전체 솔루션 엔지니어링에서 고려되어야 합니다.

2.3.3.3. 네트워킹

OpenShift Container Platform 네트워킹은 클러스터가 하나 이상의 하이브리드 클러스터의 네트워크 트래픽을 관리하는 데 필요한 고급 네트워킹 관련 기능을 사용하여 Kubernetes 네트워킹을 확장하는 기능, 플러그인 및 고급 네트워킹 기능으로 구성된 에코시스템입니다.

추가 리소스

2.3.3.3.1. CNO(Cluster Network Operator)
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

CNO는 OpenShift Container Platform 클러스터 설치 중에 기본 OVN-Kubernetes 네트워크 플러그인을 포함하여 클러스터 네트워크 구성 요소를 배포하고 관리합니다. 기본 인터페이스 MTU 설정, OVN 게이트웨이 모드를 구성하여 Pod 송신에 노드 라우팅 테이블 및 MACVLAN과 같은 추가 보조 네트워크를 사용할 수 있습니다.

네트워크 트래픽 분리를 지원하기 위해 여러 네트워크 인터페이스가 CNO를 통해 구성됩니다. 이러한 인터페이스로의 트래픽은 NMState Operator를 사용하여 적용되는 정적 경로를 통해 구성됩니다. Pod 트래픽이 올바르게 라우팅되도록 하려면 OVN-K는 routingViaHost 옵션을 활성화하여 구성됩니다. 이 설정은 Pod 송신 트래픽에 대해 OVN이 아닌 커널 라우팅 테이블 및 적용된 정적 경로를 사용합니다.

Whereabouts CNI 플러그인은 DHCP 서버를 사용하지 않고 추가 Pod 네트워크 인터페이스에 대한 동적 IPv4 및 IPv6 주소를 제공하는 데 사용됩니다.

제한 및 요구사항
  • IPv6 지원에는 OVN-Kubernetes가 필요합니다.
  • 대규모 MTU 클러스터 지원을 사용하려면 연결된 네트워크 장치를 동일하거나 더 큰 값으로 설정해야 합니다.
엔지니어링 고려 사항
  • Pod 송신 트래픽은 routingViaHost 옵션을 사용하여 커널 라우팅 테이블에 의해 처리됩니다. 적절한 정적 경로를 호스트에 구성해야 합니다.
2.3.3.3.2. 로드 밸런서
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

MetalLB는 표준 라우팅 프로토콜을 사용하여 베어 메탈 Kubernetes 클러스터에 대한 로드 밸런서 구현입니다. Kubernetes 서비스는 클러스터의 호스트 네트워크에도 추가된 외부 IP 주소를 가져올 수 있습니다.

일부 사용 사례에는 MetalLB에서 사용할 수 없는 기능(예: 상태 저장 로드 밸런싱)이 필요할 수 있습니다. 필요한 경우 외부 타사 로드 밸런서를 사용할 수 있습니다. 외부 로드 밸런서의 선택 및 구성은 이 사양의 범위를 벗어납니다. 외부 타사 로드 밸런서를 사용하는 경우 통합 작업에는 모든 성능 및 리소스 사용률 요구 사항이 충족되는지 확인하기에 충분한 분석이 포함되어야 합니다.

제한 및 요구사항
  • MetalLB에서 상태 저장 로드 밸런싱을 지원하지 않습니다. 워크로드 CNF에 대한 요구 사항인 경우 대체 로드 밸런서 구현을 사용해야 합니다.
  • 네트워킹 인프라는 클라이언트에서 클러스터의 호스트 네트워크로 외부 IP 주소를 라우팅할 수 있는지 확인해야 합니다.
엔지니어링 고려 사항
  • MetalLB는 코어 사용 사례 모델에만 BGP 모드에서 사용됩니다.
  • 코어 사용 모델의 경우 MetalLB는 로컬 게이트웨이 모드에서 사용되는 OVN-Kubernetes 네트워크 공급자에서만 지원됩니다. "Cluster Network Operator" 섹션의 routingViaHost 를 참조하십시오.
  • MetalLB의 BGP 구성은 네트워크 및 피어의 요구 사항에 따라 다릅니다.
  • 주소 풀은 필요에 따라 구성할 수 있으므로 주소, 집계 길이, 자동 할당 및 기타 관련 매개 변수의 변형을 허용합니다.
  • BFD(Bi-Directional Forwarding Detection) 프로파일의 매개 변수의 값은 기본값에 가깝게 유지되어야 합니다. 값이 더 짧은 경우 false 음수가 되고 성능에 영향을 미칠 수 있습니다.
2.3.3.3.3. SR-IOV
이번 릴리스의 새로운 기능
  • MultiNetworkPolicy 리소스를 SR-IOV 네트워크에 적용하여 네트워크 연결 가능 정책을 적용할 수 있습니다.
  • SR-IOV Network Operator에서 QinQ가 지원됩니다. 이는 기술 프리뷰 기능입니다.
  • SR-IOV VF는 CNI를 튜닝할 때 'allmulti' 플래그를 통해 모든 멀티 캐스트 트래픽을 수신할 수 있습니다. 이렇게 하면 Pod의 SCC(보안 컨텍스트 제약 조건)에 NET_ADMIN 기능을 추가하고 Pod의 잠재적인 취약점을 최소화하여 보안을 강화할 필요가 없습니다.

    설명
    SR-IOV를 사용하면 물리적 네트워크 인터페이스(PF)를 여러 VF(가상 기능)로 나눌 수 있습니다. 그러면 Pod를 분리한 상태로 유지하면서 더 높은 처리량 성능을 달성하기 위해 VFS를 여러 Pod에 할당할 수 있습니다. SR-IOV Network Operator는 SR-IOV CNI, 네트워크 장치 플러그인 및 SR-IOV 스택의 기타 구성 요소를 프로비저닝하고 관리합니다.
    제한 및 요구사항
  • 지원되는 네트워크 인터페이스 컨트롤러는 지원되는 장치에 나열되어 있습니다.
  • BIOS에서 SR-IOV 및 IOMMU 활성화: SR-IOV Network Operator는 커널 명령줄에서 IOMMU를 자동으로 활성화합니다.
  • SR-IOV VF는 PF에서 링크 상태 업데이트를 수신하지 않습니다. 링크 다운 탐지가 필요한 경우 프로토콜 수준에서 수행해야 합니다.
  • MultiNetworkPolicy CR은 netdevice 네트워크에만 적용할 수 있습니다. 구현에서 vfio 인터페이스를 관리할 수 없는 iptables 툴을 사용하기 때문입니다.

    엔지니어링 고려 사항
  • vfio 모드의 SR-IOV 인터페이스는 일반적으로 처리량 또는 짧은 대기 시간이 필요한 애플리케이션의 추가 보조 네트워크를 활성화하는 데 사용됩니다.
2.3.3.3.4. NMState Operator
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
NMState Operator는 클러스터 노드에서 네트워크 구성을 수행하기 위한 Kubernetes API를 제공합니다. 보조 인터페이스에서 네트워크 인터페이스 구성, 고정 IP 및 DNS, VLAN, 트렁크, 본딩, 정적 경로, MTU를 활성화하고 보조 인터페이스에서 무차별 모드를 활성화합니다. 클러스터 노드는 각 노드의 네트워크 인터페이스 상태를 API 서버에 정기적으로 보고합니다.
제한 및 요구사항
해당 없음
엔지니어링 고려 사항
  • 초기 네트워킹 구성은 설치 CR의 NMStateConfig 콘텐츠를 사용하여 적용됩니다. NMState Operator는 네트워크 업데이트에 필요한 경우에만 사용됩니다.
  • SR-IOV 가상 기능이 호스트 네트워킹에 사용되는 경우 NodeNetworkConfigurationPolicy 를 사용하는 NMState Operator는 해당 VF 인터페이스(예: VLAN 및 MTU)를 구성하는 데 사용됩니다.

2.3.3.4. 로깅

이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
Cluster Logging Operator를 사용하면 원격 아카이브 및 분석을 위해 노드에서 로그를 수집하고 제공할 수 있습니다. 참조 구성은 Kafka를 사용하여 원격 아카이브에 감사 및 인프라 로그를 제공합니다.
제한 및 요구사항
해당 없음
엔지니어링 고려 사항
  • 클러스터 CPU 사용 영향은 생성된 로그 수 또는 크기와 구성된 로그 필터링 양을 기반으로 합니다.
  • 참조 구성에는 애플리케이션 로그 전달이 포함되어 있지 않습니다. 구성에 애플리케이션 로그를 포함하려면 애플리케이션 로깅 속도를 평가하고 예약된 세트에 할당된 추가 CPU 리소스를 평가해야 합니다.

추가 리소스

2.3.3.5. 전원 관리

이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

성능 프로필 을 사용하여 고가용성, 저출력 또는 혼합 모드로 클러스터를 구성할 수 있습니다. 전원 모드를 선택하는 것은 클러스터에서 실행되는 워크로드의 특성, 특히 대기 시간에 얼마나 민감한지에 따라 달라집니다. Pod별 전원 관리 C-states 기능을 사용하여 대기 시간이 짧은 Pod의 최대 대기 시간을 구성합니다.

자세한 내용은 노드의 전원 저장 구성을 참조하십시오.

제한 및 요구사항
  • 전원 구성은 적절한 BIOS 구성을 사용합니다(예: C 상태 및 P-상태 활성화). 구성은 하드웨어 벤더마다 다릅니다.
엔지니어링 고려 사항
  • 대기 시간: 대기 시간에 민감한 워크로드가 요구 사항을 충족하도록 하려면 고급 구성 또는 Pod별 전원 관리 구성이 필요합니다. Pod별 전원 관리는 전용 고정 CPU가 있는 QoS Pod에서만 사용할 수 있습니다.

2.3.3.6. 스토리지

개요

클라우드 네이티브 스토리지 서비스는 Red Hat 또는 타사의 OpenShift Data Foundation을 비롯한 여러 솔루션에서 제공할 수 있습니다.

OpenShift Data Foundation은 컨테이너용 Ceph 기반 소프트웨어 정의 스토리지 솔루션입니다. 영구 및 비영구 데이터 요구 사항에 대해 동적으로 프로비저닝할 수 있는 블록 스토리지, 파일 시스템 스토리지 및 온-프레미스 개체 스토리지를 제공합니다. 통신 핵심 애플리케이션에는 영구 스토리지가 필요합니다.

참고

모든 스토리지 데이터가 이동 중에 암호화되지 않을 수 있습니다. 위험을 줄이려면 스토리지 네트워크를 다른 클러스터 네트워크와 분리합니다. 다른 클러스터 네트워크에서 스토리지 네트워크에 연결할 수 없거나 라우팅할 수 없어야 합니다. 스토리지 네트워크에 직접 연결된 노드만 액세스할 수 있어야 합니다.

2.3.3.6.1. OpenShift Data Foundation
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
Red Hat OpenShift Data Foundation은 컨테이너용 소프트웨어 정의 스토리지 서비스입니다. Telco 핵심 클러스터의 경우 애플리케이션 워크로드 클러스터 외부에서 실행되는 OpenShift Data Foundation 스토리지 서비스에서 스토리지 지원을 제공합니다. OpenShift Data Foundation은 보조 CNI 네트워크를 사용하여 스토리지 트래픽 분리를 지원합니다.
제한 및 요구사항
엔지니어링 고려 사항
  • OpenShift Data Foundation 네트워크 트래픽은 예를 들어 VLAN 격리를 사용하여 전용 네트워크의 다른 트래픽과 격리해야 합니다.
2.3.3.6.2. 기타 스토리지

기타 스토리지 솔루션을 사용하여 코어 클러스터에 영구 스토리지를 제공할 수 있습니다. 이러한 솔루션의 구성 및 통합은 통신 코어 RDS의 범위를 벗어납니다. 스토리지 솔루션을 코어 클러스터에 통합하려면 스토리지가 전체 성능 및 리소스 사용률 요구 사항을 충족하는지 확인하기 위해 올바른 크기 조정 및 성능 분석을 포함해야 합니다.

2.3.3.7. 모니터링

이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

CCMO(Cluster Monitoring Operator)는 기본적으로 모든 OpenShift 클러스터에 포함되어 있으며 플랫폼 구성 요소와 사용자 프로젝트에 대한 모니터링(metrics, 대시보드, 경고)도 제공합니다.

모니터링 Operator를 구성하면 다음을 포함하여 사용자 정의할 수 있습니다.

  • 기본 보존 기간
  • 사용자 정의 경고 규칙

Pod CPU 및 메모리 메트릭의 기본 처리는 업스트림 Kubernetes cAdvisor 를 기반으로 하며 메트릭 정확도에 비해 오래된 데이터를 처리하는 것을 선호하는 절충 역할을 합니다. 이로 인해 사용자 지정 임계값에 대해 잘못된 경고 트리거를 생성하는 spiky 데이터가 생성됩니다. OpenShift는 spiky 동작으로 영향을 받지 않는 추가 Pod CPU 및 메모리 메트릭 세트를 생성하는 옵트인 전용 서비스 모니터 기능을 지원합니다. 자세한 내용은 이 솔루션 가이드를 참조하십시오.

기본 구성 외에도 telco 코어 클러스터에 대해 다음 메트릭을 구성해야 합니다.

  • 사용자 워크로드에 대한 Pod CPU 및 메모리 메트릭 및 경고
제한 및 요구사항
  • 모니터링 구성에서 Pod 메트릭을 정확하게 표시하려면 전용 서비스 모니터 기능을 활성화해야 합니다.
엔지니어링 고려 사항
  • Prometheus 보존 기간은 사용자가 지정합니다. 사용된 값은 CPU 및 스토리지 리소스에 대해 클러스터의 기록 데이터를 유지 관리하기 위한 운영 요구 사항 간의 절충입니다. 보존 기간이 길어지면 스토리지의 필요성이 증가하고 데이터 인덱싱을 관리하기 위해 추가 CPU가 필요합니다.

추가 리소스

2.3.3.8. 스케줄링

이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
  • 스케줄러는 지정된 워크로드에 적합한 노드를 선택하는 클러스터 전체 구성 요소입니다. 이는 플랫폼의 핵심 부분이며 일반적인 배포 시나리오에서 특정 구성이 필요하지 않습니다. 그러나 다음 섹션에서 설명하는 몇 가지 특정 사용 사례가 있습니다. NUMA 리소스 Operator를 통해 NUMA 인식 스케줄링을 활성화할 수 있습니다. 자세한 내용은 NUMA 인식 워크로드 예약을 참조하십시오.
제한 및 요구사항
  • 기본 스케줄러는 워크로드의 NUMA 현지성을 인식하지 못합니다. 작업자 노드에서 사용 가능한 모든 리소스의 합계만 알고 있습니다. 이로 인해 토폴로지 관리자 정책이 single-numa-node 또는 restricted 로 설정된 노드에 예약할 때 워크로드가 거부될 수 있습니다.

    • 예를 들어 Pod에서 6개의 CPU를 요청하고 NUMA 노드당 CPU가 4개인 빈 노드로 예약되는 것이 좋습니다. 노드의 총 할당 가능 용량은 8개의 CPU이며 스케줄러는 Pod를 배치합니다. 노드 로컬 승인은 실패하지만 각 NUMA 노드에서 사용할 수 있는 CPU는 4개뿐입니다.
    • NUMA 노드가 있는 모든 클러스터는 NUMA 리소스 Operator 를 사용해야 합니다. NUMA 리소스 Operator의 machineConfigPoolSelector 는 NUMA 정렬 스케줄링이 필요한 모든 노드를 선택해야 합니다.
  • 모든 머신 구성 풀에는 일관된 하드웨어 구성이 있어야 합니다. 예를 들어 모든 노드에는 동일한 NUMA 영역 수가 있어야 합니다.
엔지니어링 고려 사항
  • Pod에 올바른 스케줄링 및 격리를 위한 주석이 필요할 수 있습니다. 주석에 대한 자세한 내용은 CPU 파티셔닝 및 성능 튜닝 을 참조하십시오.
  • SriovNetworkNodePolicy CR에서 excludeTopology 필드를 사용하여 예약 중에 무시하도록 SR-IOV 가상 함수 NUMA 선호도를 구성할 수 있습니다.

2.3.3.9. 설치

이번 릴리스의 새로운 기능, 설명

Telco 코어 클러스터는 ABI(agent Based Installer)를 사용하여 설치할 수 있습니다. 이 방법을 사용하면 설치를 관리하기 위해 추가 서버 또는 VM 없이도 베어 메탈 서버에 OpenShift Container Platform을 설치할 수 있습니다. ABI 설치 프로그램은 예를 들어 ISO 설치 이미지를 생성하는 랩탑과 같은 시스템에서 실행할 수 있습니다. 이 ISO는 클러스터 감독 노드의 설치 미디어로 사용됩니다. 감독 노드의 API 인터페이스에 대한 네트워크 연결이 있는 모든 시스템에서 ABI 툴을 사용하여 진행 상황을 모니터링할 수 있습니다.

  • 선언적 CR에서 설치
  • 설치를 지원하기 위해 추가 서버가 필요하지 않음
  • 연결이 끊긴 환경에서 설치 지원
제한 및 요구사항
  • 연결이 끊긴 설치에는 필요한 모든 콘텐츠가 미러링된 연결 가능한 레지스트리가 필요합니다.
엔지니어링 고려 사항
  • 네트워킹 구성은 NMState Operator를 사용하여 2일차 구성에 우선하여 설치 중에 NMState 구성으로 적용해야 합니다.

2.3.3.10. 보안

이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

통신 운영자는 보안에 대해 자심하고 있으며 여러 공격 벡터에 대해 클러스터를 강화해야 합니다. OpenShift Container Platform에는 클러스터 보안을 담당하는 단일 구성 요소 또는 기능이 없습니다. 이 섹션에서는 이 사양에서 다루는 사용 모델에 대한 보안 지향 기능 및 구성에 대한 세부 정보를 제공합니다.

  • SecurityContextConstraints: 모든 워크로드 Pod는 restricted-v2 또는 restricted SCC를 사용하여 실행해야 합니다.
  • seccomp: 모든 Pod는 RuntimeDefault (또는 더 강력한) seccomp 프로필을 사용하여 실행해야 합니다.
  • rootless DPDK Pod: 많은 DPDK(사용자 플레인 네트워킹) CNF는 root 권한으로 Pod를 실행해야 합니다. 이 기능을 사용하면 root 권한 없이도 준수 DPDK Pod를 실행할 수 있습니다. rootless DPDK Pod는 DPDK 애플리케이션에서 커널로 트래픽을 삽입하는 rootless Pod에 탭 장치를 생성합니다.
  • 스토리지: 스토리지 네트워크를 다른 클러스터 네트워크로 분리하고 라우팅할 수 없어야 합니다. 자세한 내용은 "스토리지" 섹션을 참조하십시오.
제한 및 요구사항
  • rootless DPDK Pod에는 다음과 같은 추가 구성 단계가 필요합니다.

    • container_t SELinux 컨텍스트를 사용하여 Cryostat 플러그인을 구성합니다.
    • 호스트에서 container_use_devices SELinux 부울을 활성화합니다.
엔지니어링 고려 사항
  • rootless DPDK Pod를 지원하려면 Cryostat 장치를 생성하려면 호스트에서 SELinux 부울 container_use_devices 를 활성화해야 합니다. 이로 인해 단기간에 사용 가능한 보안 위험이 발생합니다. 다른 해결책도 살펴볼 것입니다.

2.3.3.11. 확장성

이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

클러스터는 limits 및 requirements 섹션에 나열된 크기 조정으로 확장됩니다.

워크로드 스케일링은 사용 모델 섹션에 설명되어 있습니다.

제한 및 요구사항
  • 클러스터는 최소 120개의 노드로 확장 가능
엔지니어링 고려 사항
해당 없음

2.3.3.12. 추가 구성

2.3.3.12.1. 연결이 끊긴 환경
설명

통신 핵심 클러스터는 인터넷에 직접 액세스하지 않고 네트워크에 설치해야 합니다. 클러스터를 설치, 구성, Operator에 필요한 모든 컨테이너 이미지는 연결이 끊긴 레지스트리에서 사용할 수 있어야 합니다. 여기에는 OpenShift Container Platform 이미지, day-2 Operator Lifecycle Manager(OLM) Operator 이미지, 애플리케이션 워크로드 이미지가 포함됩니다. 연결이 끊긴 환경을 사용하면 다음과 같은 여러 이점이 있습니다.

  • 보안을 위해 클러스터에 대한 액세스 제한
  • 선별된 콘텐츠: 클러스터의 큐레이션 및 승인된 업데이트를 기반으로 레지스트리가 채워집니다.
제한 및 요구사항
  • 모든 사용자 정의 CatalogSources에는 고유한 이름이 필요합니다. 기본 카탈로그 이름을 재사용하지 마십시오.
  • 유효한 시간 소스는 클러스터 설치의 일부로 구성해야 합니다.
엔지니어링 고려 사항
해당 없음
2.3.3.12.2. 커널
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

사용자는 MachineConfig 를 사용하여 확장된 커널 기능을 CNFs에 제공하여 다음 커널 모듈을 설치할 수 있습니다.

  • sctp
  • ip_gre
  • ip6_tables
  • ip6t_REJECT
  • ip6table_filter
  • ip6table_mangle
  • iptable_filter
  • iptable_mangle
  • iptable_nat
  • xt_multiport
  • xt_owner
  • xt_REDIRECT
  • xt_statistic
  • xt_TCPMSS
제한 및 요구사항
  • 이러한 커널 모듈을 통해 사용할 수 있는 기능의 사용은 CPU 부하, 시스템 성능 및 KPI 유지 기능에 미치는 영향을 확인하려면 사용자가 분석해야 합니다.
참고

트리 부족 드라이버는 지원되지 않습니다.

엔지니어링 고려 사항
해당 없음

2.3.4. Telco core 4.15 참조 구성 CR

다음 CR(사용자 정의 리소스)을 사용하여 telco core 프로필로 OpenShift Container Platform 클러스터를 구성하고 배포합니다. 달리 표시되지 않는 한 모든 특정 사용 모델에 사용되는 공통 기준을 형성하려면 CR을 사용합니다.

2.3.4.1. 리소스 튜닝 참조 CR

표 2.10. 리소스 튜닝 CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

시스템 예약 용량

control-plane-system-reserved.yaml

제공됨

없음

시스템 예약 용량

pid-limits-cr.yaml

제공됨

없음

2.3.4.2. 스토리지 참조 CR

표 2.11. 스토리지 CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

외부 Red Hat OpenShift Data Foundation 구성

01-rook-ceph-external-cluster-details.secret.yaml

없음

제공됨

외부 OpenShift Data Foundation 구성

02-ocs-external-storagecluster.yaml

없음

없음

외부 OpenShift Data Foundation 구성

odfNS.yaml

없음

없음

외부 OpenShift Data Foundation 구성

odfOperGroup.yaml

없음

없음

2.3.4.3. 네트워킹 참조 CR

표 2.12. Networking CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

기준

Network.yaml

없음

없음

기준

networkAttachmentDefinition.yaml

제공됨

제공됨

로드 밸런서

addr-pool.yaml

없음

없음

로드 밸런서

bfd-profile.yaml

없음

없음

로드 밸런서

bgp-advr.yaml

없음

없음

로드 밸런서

bgp-peer.yaml

없음

없음

로드 밸런서

metallb.yaml

없음

없음

로드 밸런서

metallbNS.yaml

제공됨

없음

로드 밸런서

metallbOperGroup.yaml

제공됨

없음

로드 밸런서

metallbSubscription.yaml

없음

없음

Multus - rootless DPDK Pod의 경우 Tap CNI

mc_rootless_pods_selinux.yaml

없음

없음

SR-IOV 네트워크 Operator

sriovNetwork.yaml

제공됨

없음

SR-IOV 네트워크 Operator

sriovNetworkNodePolicy.yaml

없음

제공됨

SR-IOV 네트워크 Operator

SriovOperatorConfig.yaml

없음

제공됨

SR-IOV 네트워크 Operator

SriovSubscription.yaml

없음

없음

SR-IOV 네트워크 Operator

SriovSubscriptionNS.yaml

없음

없음

SR-IOV 네트워크 Operator

SriovSubscriptionOperGroup.yaml

없음

없음

2.3.4.4. 참조 CR 예약

표 2.13. CR 예약
Component참조 CR선택 사항이번 릴리스의 새로운 기능

NUMA 인식 스케줄러

nrop.yaml

없음

없음

NUMA 인식 스케줄러

sched.yaml

없음

없음

2.3.4.5. 기타 참조 CR

표 2.14. 기타 CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

추가 커널 모듈

control-plane-load-kernel-modules.yaml

제공됨

없음

추가 커널 모듈

sctp_module_mc.yaml

제공됨

없음

추가 커널 모듈

worker-load-kernel-modules.yaml

제공됨

없음

클러스터 로깅

ClusterLogForwarder.yaml

없음

없음

클러스터 로깅

ClusterLogging.yaml

없음

없음

클러스터 로깅

ClusterLogNS.yaml

없음

없음

클러스터 로깅

ClusterLogOperGroup.yaml

없음

없음

클러스터 로깅

ClusterLogSubscription.yaml

없음

제공됨

연결이 끊긴 구성

catalog-source.yaml

없음

없음

연결이 끊긴 구성

icsp.yaml

없음

없음

연결이 끊긴 구성

operator-hub.yaml

없음

없음

모니터링 및 관찰 기능

monitoring-config-cm.yaml

제공됨

없음

전원 관리

PerformanceProfile.yaml

없음

없음

2.3.4.6. YAML 참조

2.3.4.6.1. 리소스 튜닝 참조 YAML

control-plane-system-reserved.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: autosizing-master
spec:
  autoSizingReserved: true
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/master: ""

pid-limits-cr.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
  name: 99-change-pidslimit-custom
spec:
  machineConfigPoolSelector:
    matchLabels:
      # Set to appropriate MCP
      pools.operator.machineconfiguration.openshift.io/master: ""
  containerRuntimeConfig:
    pidsLimit: $pidsLimit
    # Example:
    #pidsLimit: 4096

2.3.4.6.2. 스토리지 참조 YAML

01-rook-ceph-external-cluster-details.secret.yaml

# required
# count: 1
---
apiVersion: v1
kind: Secret
metadata:
  name: rook-ceph-external-cluster-details
  namespace: openshift-storage
type: Opaque
data:
  # encoded content has been made generic
  external_cluster_details: eyJuYW1lIjoicm9vay1jZXBoLW1vbi1lbmRwb2ludHMiLCJraW5kIjoiQ29uZmlnTWFwIiwiZGF0YSI6eyJkYXRhIjoiY2VwaHVzYTE9MS4yLjMuNDo2Nzg5IiwibWF4TW9uSWQiOiIwIiwibWFwcGluZyI6Int9In19LHsibmFtZSI6InJvb2stY2VwaC1tb24iLCJraW5kIjoiU2VjcmV0IiwiZGF0YSI6eyJhZG1pbi1zZWNyZXQiOiJhZG1pbi1zZWNyZXQiLCJmc2lkIjoiMTExMTExMTEtMTExMS0xMTExLTExMTEtMTExMTExMTExMTExIiwibW9uLXNlY3JldCI6Im1vbi1zZWNyZXQifX0seyJuYW1lIjoicm9vay1jZXBoLW9wZXJhdG9yLWNyZWRzIiwia2luZCI6IlNlY3JldCIsImRhdGEiOnsidXNlcklEIjoiY2xpZW50LmhlYWx0aGNoZWNrZXIiLCJ1c2VyS2V5IjoiYzJWamNtVjAifX0seyJuYW1lIjoibW9uaXRvcmluZy1lbmRwb2ludCIsImtpbmQiOiJDZXBoQ2x1c3RlciIsImRhdGEiOnsiTW9uaXRvcmluZ0VuZHBvaW50IjoiMS4yLjMuNCwxLjIuMy4zLDEuMi4zLjIiLCJNb25pdG9yaW5nUG9ydCI6IjkyODMifX0seyJuYW1lIjoiY2VwaC1yYmQiLCJraW5kIjoiU3RvcmFnZUNsYXNzIiwiZGF0YSI6eyJwb29sIjoib2RmX3Bvb2wifX0seyJuYW1lIjoicm9vay1jc2ktcmJkLW5vZGUiLCJraW5kIjoiU2VjcmV0IiwiZGF0YSI6eyJ1c2VySUQiOiJjc2ktcmJkLW5vZGUiLCJ1c2VyS2V5IjoiIn19LHsibmFtZSI6InJvb2stY3NpLXJiZC1wcm92aXNpb25lciIsImtpbmQiOiJTZWNyZXQiLCJkYXRhIjp7InVzZXJJRCI6ImNzaS1yYmQtcHJvdmlzaW9uZXIiLCJ1c2VyS2V5IjoiYzJWamNtVjAifX0seyJuYW1lIjoicm9vay1jc2ktY2VwaGZzLXByb3Zpc2lvbmVyIiwia2luZCI6IlNlY3JldCIsImRhdGEiOnsiYWRtaW5JRCI6ImNzaS1jZXBoZnMtcHJvdmlzaW9uZXIiLCJhZG1pbktleSI6IiJ9fSx7Im5hbWUiOiJyb29rLWNzaS1jZXBoZnMtbm9kZSIsImtpbmQiOiJTZWNyZXQiLCJkYXRhIjp7ImFkbWluSUQiOiJjc2ktY2VwaGZzLW5vZGUiLCJhZG1pbktleSI6ImMyVmpjbVYwIn19LHsibmFtZSI6ImNlcGhmcyIsImtpbmQiOiJTdG9yYWdlQ2xhc3MiLCJkYXRhIjp7ImZzTmFtZSI6ImNlcGhmcyIsInBvb2wiOiJtYW5pbGFfZGF0YSJ9fQ==

02-ocs-external-storagecluster.yaml

# required
# count: 1
---
apiVersion: ocs.openshift.io/v1
kind: StorageCluster
metadata:
  name: ocs-external-storagecluster
  namespace: openshift-storage
spec:
  externalStorage:
    enable: true
  labelSelector: {}

odfNS.yaml

# required: yes
# count: 1
---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-storage
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"

odfOperGroup.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-storage-operatorgroup
  namespace: openshift-storage
spec:
  targetNamespaces:
    - openshift-storage

2.3.4.6.3. 네트워킹 참조 YAML

Network.yaml

# required
# count: 1
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      gatewayConfig:
        routingViaHost: true
  # additional networks are optional and may alternatively be specified using NetworkAttachmentDefinition CRs
  additionalNetworks: [$additionalNetworks]
  # eg
  #- name: add-net-1
  #  namespace: app-ns-1
  #  rawCNIConfig: '{ "cniVersion": "0.3.1", "name": "add-net-1", "plugins": [{"type": "macvlan", "master": "bond1", "ipam": {}}] }'
  #  type: Raw
  #- name: add-net-2
  #  namespace: app-ns-1
  #  rawCNIConfig: '{ "cniVersion": "0.4.0", "name": "add-net-2", "plugins": [ {"type": "macvlan", "master": "bond1", "mode": "private" },{ "type": "tuning", "name": "tuning-arp" }] }'
  #  type: Raw

  # Enable to use MultiNetworkPolicy CRs
  useMultiNetworkPolicy: true

networkAttachmentDefinition.yaml

# optional
# copies: 0-N
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: $name
  namespace: $ns
spec:
  nodeSelector:
    kubernetes.io/hostname: $nodeName
  config: $config
  #eg
  #config: '{
  #  "cniVersion": "0.3.1",
  #  "name": "external-169",
  #  "type": "vlan",
  #  "master": "ens8f0",
  #  "mode": "bridge",
  #  "vlanid": 169,
  #  "ipam": {
  #    "type": "static",
  #  }
  #}'

addr-pool.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: $name # eg addresspool3
  namespace: metallb-system
  annotations:
    metallb.universe.tf/address-pool: $name # eg addresspool3
spec:
  ##############
  # Expected variation in this configuration
  addresses: [$pools]
  #- 3.3.3.0/24
  autoAssign: true
  ##############

bfd-profile.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: BFDProfile
metadata:
  name: bfdprofile
  namespace: metallb-system
spec:
  ################
  # These values may vary. Recommended values are included as default
  receiveInterval: 150 # default 300ms
  transmitInterval: 150 # default 300ms
  #echoInterval: 300 # default 50ms
  detectMultiplier: 10 # default 3
  echoMode: true
  passiveMode: true
  minimumTtl: 5 # default 254
  #
  ################

bgp-advr.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: $name # eg bgpadvertisement-1
  namespace: metallb-system
spec:
  ipAddressPools: [$pool]
  # eg:

  #  - addresspool3
  peers: [$peers]
  # eg:

  #    - peer-one
  communities: [$communities]
  # Note correlation with address pool.
  # eg:

  #    - 65535:65282
  aggregationLength: 32
  aggregationLengthV6: 128
  localPref: 100

bgp-peer.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: BGPPeer
metadata:
  name: $name
  namespace: metallb-system
spec:
  peerAddress: $ip # eg 192.168.1.2
  peerASN: $peerasn # eg 64501
  myASN: $myasn # eg 64500
  routerID: $id # eg 10.10.10.10
  bfdProfile: bfdprofile

metallb.yaml

# required
# count: 1
apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""

metallbNS.yaml

# required: yes
# count: 1
---
apiVersion: v1
kind: Namespace
metadata:
  name: metallb-system
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"

metallbOperGroup.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator
  namespace: metallb-system

metallbSubscription.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator-sub
  namespace: metallb-system
spec:
  channel: stable
  name: metallb-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic

mc_rootless_pods_selinux.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-worker-setsebool
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Set SELinux boolean for tap cni plugin
            Before=kubelet.service

            [Service]
            Type=oneshot
            ExecStart=/sbin/setsebool container_use_devices=on
            RemainAfterExit=true

            [Install]
            WantedBy=multi-user.target graphical.target
          enabled: true
          name: setsebool.service

sriovNetwork.yaml

# optional (though expected for all)
# count: 0-N
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: $name # eg sriov-network-abcd
  namespace: openshift-sriov-network-operator
spec:
  capabilities: "$capabilities" # eg '{"mac": true, "ips": true}'
  ipam: "$ipam" # eg '{ "type": "host-local", "subnet": "10.3.38.0/24" }'
  networkNamespace: $nns # eg cni-test
  resourceName: $resource # eg resourceTest

sriovNetworkNodePolicy.yaml

# optional (though expected in all deployments)
# count: 0-N
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: $name
  namespace: openshift-sriov-network-operator
spec: {} # $spec
# eg
#deviceType: netdevice
#nicSelector:
#  deviceID: "1593"
#  pfNames:
#  - ens8f0np0#0-9
#  rootDevices:
#  - 0000:d8:00.0
#  vendor: "8086"
#nodeSelector:
#  kubernetes.io/hostname: host.sample.lab
#numVfs: 20
#priority: 99
#excludeTopology: true
#resourceName: resourceNameABCD

SriovOperatorConfig.yaml

# required
# count: 1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    node-role.kubernetes.io/worker: ""
  enableInjector: true
  enableOperatorWebhook: true

SriovSubscription.yaml

# required: yes
# count: 1
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
spec:
  channel: "stable"
  name: sriov-network-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic

SriovSubscriptionNS.yaml

# required: yes
# count: 1
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management

SriovSubscriptionOperGroup.yaml

# required: yes
# count: 1
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
    - openshift-sriov-network-operator

2.3.4.6.4. 참조 YAML 예약

nrop.yaml

# Optional
# count: 1
apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesOperator
metadata:
  name: numaresourcesoperator
spec:
  nodeGroups:
    - config:
        # Periodic is the default setting
        infoRefreshMode: Periodic
      machineConfigPoolSelector:
        matchLabels:
          # This label must match the pool(s) you want to run NUMA-aligned workloads
          pools.operator.machineconfiguration.openshift.io/worker: ""

sched.yaml

# Optional
# count: 1
apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: numaresourcesscheduler
spec:
  #cacheResyncPeriod: "0"
  # Image spec should be the latest for the release
  imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.14.0"
  #logLevel: "Trace"
  schedulerName: topo-aware-scheduler

2.3.4.6.5. 기타 참조 YAML

control-plane-load-kernel-modules.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 40-load-kernel-modules-control-plane
spec:
  config:
    # Release info found in https://github.com/coreos/butane/releases
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:,
          mode: 420
          overwrite: true
          path: /etc/modprobe.d/kernel-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8;base64,aXBfZ3JlCmlwNl90YWJsZXMKaXA2dF9SRUpFQ1QKaXA2dGFibGVfZmlsdGVyCmlwNnRhYmxlX21hbmdsZQppcHRhYmxlX2ZpbHRlcgppcHRhYmxlX21hbmdsZQppcHRhYmxlX25hdAp4dF9tdWx0aXBvcnQKeHRfb3duZXIKeHRfUkVESVJFQ1QKeHRfc3RhdGlzdGljCnh0X1RDUE1TUwp4dF91MzI=
          mode: 420
          overwrite: true
          path: /etc/modules-load.d/kernel-load.conf

sctp_module_mc.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: load-sctp-module
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
        - contents:
            source: data:,
            verification: {}
          filesystem: root
          mode: 420
          path: /etc/modprobe.d/sctp-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8;base64,c2N0cA==
          filesystem: root
          mode: 420
          path: /etc/modules-load.d/sctp-load.conf

worker-load-kernel-modules.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 40-load-kernel-modules-worker
spec:
  config:
    # Release info found in https://github.com/coreos/butane/releases
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:,
          mode: 420
          overwrite: true
          path: /etc/modprobe.d/kernel-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8;base64,aXBfZ3JlCmlwNl90YWJsZXMKaXA2dF9SRUpFQ1QKaXA2dGFibGVfZmlsdGVyCmlwNnRhYmxlX21hbmdsZQppcHRhYmxlX2ZpbHRlcgppcHRhYmxlX21hbmdsZQppcHRhYmxlX25hdAp4dF9tdWx0aXBvcnQKeHRfb3duZXIKeHRfUkVESVJFQ1QKeHRfc3RhdGlzdGljCnh0X1RDUE1TUwp4dF91MzI=
          mode: 420
          overwrite: true
          path: /etc/modules-load.d/kernel-load.conf

ClusterLogForwarder.yaml

# required
# count: 1
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
    - type: "kafka"
      name: kafka-open
      url: tcp://10.11.12.13:9092/test
  pipelines:
    - inputRefs:
        - infrastructure
        #- application
        - audit
      labels:
        label1: test1
        label2: test2
        label3: test3
        label4: test4
        label5: test5
      name: all-to-default
      outputRefs:
        - kafka-open

ClusterLogging.yaml

# required
# count: 1
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    type: vector
  managementState: Managed

ClusterLogNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  annotations:
    workload.openshift.io/allowed: management

ClusterLogOperGroup.yaml

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  targetNamespaces:
    - openshift-logging

ClusterLogSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  channel: "stable"
  name: cluster-logging
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic

catalog-source.yaml

# required
# count: 1..N
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: redhat-operators-disconnected
  namespace: openshift-marketplace
spec:
  displayName: Red Hat Disconnected Operators Catalog
  image: $imageUrl
  publisher: Red Hat
  sourceType: grpc
#  updateStrategy:
#    registryPoll:
#      interval: 1h
#status:
#    connectionState:
#        lastObservedState: READY

icsp.yaml

# required
# count: 1
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: disconnected-internal-icsp
spec:
  repositoryDigestMirrors: []
#    - $mirrors

operator-hub.yaml

# required
# count: 1
apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true

monitoring-config-cm.yaml

# optional
# count: 1
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    k8sPrometheusAdapter:
      dedicatedServiceMonitors:
        enabled: true
    prometheusK8s:
      retention: 15d
      volumeClaimTemplate:
        spec:
          storageClassName: ocs-external-storagecluster-ceph-rbd
          resources:
            requests:
              storage: 100Gi
    alertmanagerMain:
      volumeClaimTemplate:
        spec:
          storageClassName: ocs-external-storagecluster-ceph-rbd
          resources:
            requests:
              storage: 20Gi

PerformanceProfile.yaml

# required
# count: 1
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: $name
  annotations:
    # Some pods want the kernel stack to ignore IPv6 router Advertisement.
    kubeletconfig.experimental: |
      {"allowedUnsafeSysctls":["net.ipv6.conf.all.accept_ra"]}
spec:
  cpu:
    # node0 CPUs: 0-17,36-53
    # node1 CPUs: 18-34,54-71
    # siblings: (0,36), (1,37)...
    # we want to reserve the first Core of each NUMA socket
    #
    # no CPU left behind! all-cpus == isolated + reserved
    isolated: $isolated # eg 1-17,19-35,37-53,55-71
    reserved: $reserved # eg 0,18,36,54
  # Guaranteed QoS pods will disable IRQ balancing for cores allocated to the pod.
  # default value of globallyDisableIrqLoadBalancing is false
  globallyDisableIrqLoadBalancing: false
  hugepages:
    defaultHugepagesSize: 1G
    pages:
      # 32GB per numa node
      - count: $count # eg 64
        size: 1G
  machineConfigPoolSelector:
    # For SNO: machineconfiguration.openshift.io/role: 'master'
    pools.operator.machineconfiguration.openshift.io/worker: ''
  nodeSelector:
    # For SNO: node-role.kubernetes.io/master: ""
    node-role.kubernetes.io/worker: ""
  workloadHints:
    realTime: false
    highPowerConsumption: false
    perPodPowerManagement: true
  realTimeKernel:
    enabled: false
  numa:
    # All guaranteed QoS containers get resources from a single NUMA node
    topologyPolicy: "single-numa-node"
  net:
    userLevelNetworking: false

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.