2.3. Telco 코어 참조 설계 사양
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)에 의해 활용되는 다음 기능이 추가되거나 업데이트되었습니다.
기능 | 설명 |
---|---|
IPv6 네트워크에 대한 다중 네트워크 정책 지원 | 이제 IPv6 네트워크에 대한 다중 네트워크 정책을 생성할 수 있습니다. 자세한 내용은 IPv6 네트워크에서 다중 네트워크 정책 지원을 참조하십시오. |
2.3.2. Telco 코어 4.15 사용 모델 개요
Telco 코어 참조 설계 사양(RDS)은 신호 및 집계와 같은 컨트롤 플레인 기능을 포함하여 대규모 통신 애플리케이션을 지원하는 플랫폼을 설명합니다. 또한 몇 가지 중앙 집중식 데이터 플레인 기능(예: 사용자 플레인 기능(UPF))이 포함되어 있습니다. 이러한 기능에는 일반적으로 확장성, 복잡한 네트워킹 지원, 탄력적 소프트웨어 정의 스토리지 및 RAN과 같은 대규모 배포보다 제한된 성능 요구 사항이 필요합니다.
Telco core 사용 모델 아키텍처
통신 핵심 기능에 대한 네트워킹 사전 요구 사항은 다양하며 다양한 네트워킹 속성 및 성능 벤치마크를 포함합니다. 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은 작업자 노드에서 활성화됩니다.
PerformanceProfile
은globallyDisableIrqLoadBalancing: 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를 독점적으로 사용할 수 없습니다. 다른 워크로드, 운영 체제 데몬 또는 커널 작업에서 워크로드를 선점할 수 있습니다.
-
보장된 QoS Pod를 사용할 수 있지만
실행 가능한 대안이 없는 한 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
옵션을 사용하여 커널 라우팅 테이블에 의해 처리됩니다. 적절한 정적 경로를 호스트에 구성해야 합니다.
-
Pod 송신 트래픽은
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)를 구성하는 데 사용됩니다.
-
초기 네트워킹 구성은 설치 CR의
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에서만 사용할 수 있습니다.
-
대기 시간: 대기 시간에 민감한 워크로드가 요구 사항을 충족하도록 하려면 고급 구성 또는 Pod별 전원 관리 구성이 필요합니다. Pod별 전원 관리는 전용 고정 CPU가
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 네트워크를 사용하여 스토리지 트래픽 분리를 지원합니다.
- 제한 및 요구사항
- IPv4/IPv6 듀얼 스택 네트워킹 환경에서 OpenShift Data Foundation은 IPv4 주소를 사용합니다. 자세한 내용은 IPv4를 사용하는 OpenShift Data Foundation에서 OpenShift 듀얼 스택 지원을 참조하십시오.
- 엔지니어링 고려 사항
- 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
를 활성화해야 합니다. 이로 인해 단기간에 사용 가능한 보안 위험이 발생합니다. 다른 해결책도 살펴볼 것입니다.
-
rootless DPDK Pod를 지원하려면 Cryostat 장치를 생성하려면 호스트에서 SELinux 부울
추가 리소스
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
Component | 참조 CR | 선택 사항 | 이번 릴리스의 새로운 기능 |
---|---|---|---|
시스템 예약 용량 | 제공됨 | 없음 | |
시스템 예약 용량 | 제공됨 | 없음 |
2.3.4.2. 스토리지 참조 CR
Component | 참조 CR | 선택 사항 | 이번 릴리스의 새로운 기능 |
---|---|---|---|
외부 Red Hat OpenShift Data Foundation 구성 | 없음 | 제공됨 | |
외부 OpenShift Data Foundation 구성 | 없음 | 없음 | |
외부 OpenShift Data Foundation 구성 | 없음 | 없음 | |
외부 OpenShift Data Foundation 구성 | 없음 | 없음 |
2.3.4.3. 네트워킹 참조 CR
Component | 참조 CR | 선택 사항 | 이번 릴리스의 새로운 기능 |
---|---|---|---|
기준 | 없음 | 없음 | |
기준 | 제공됨 | 제공됨 | |
로드 밸런서 | 없음 | 없음 | |
로드 밸런서 | 없음 | 없음 | |
로드 밸런서 | 없음 | 없음 | |
로드 밸런서 | 없음 | 없음 | |
로드 밸런서 | 없음 | 없음 | |
로드 밸런서 | 제공됨 | 없음 | |
로드 밸런서 | 제공됨 | 없음 | |
로드 밸런서 | 없음 | 없음 | |
Multus - rootless DPDK Pod의 경우 Tap CNI | 없음 | 없음 | |
SR-IOV 네트워크 Operator | 제공됨 | 없음 | |
SR-IOV 네트워크 Operator | 없음 | 제공됨 | |
SR-IOV 네트워크 Operator | 없음 | 제공됨 | |
SR-IOV 네트워크 Operator | 없음 | 없음 | |
SR-IOV 네트워크 Operator | 없음 | 없음 | |
SR-IOV 네트워크 Operator | 없음 | 없음 |
2.3.4.4. 참조 CR 예약
Component | 참조 CR | 선택 사항 | 이번 릴리스의 새로운 기능 |
---|---|---|---|
NUMA 인식 스케줄러 | 없음 | 없음 | |
NUMA 인식 스케줄러 | 없음 | 없음 |
2.3.4.5. 기타 참조 CR
Component | 참조 CR | 선택 사항 | 이번 릴리스의 새로운 기능 |
---|---|---|---|
추가 커널 모듈 | 제공됨 | 없음 | |
추가 커널 모듈 | 제공됨 | 없음 | |
추가 커널 모듈 | 제공됨 | 없음 | |
클러스터 로깅 | 없음 | 없음 | |
클러스터 로깅 | 없음 | 없음 | |
클러스터 로깅 | 없음 | 없음 | |
클러스터 로깅 | 없음 | 없음 | |
클러스터 로깅 | 없음 | 제공됨 | |
연결이 끊긴 구성 | 없음 | 없음 | |
연결이 끊긴 구성 | 없음 | 없음 | |
연결이 끊긴 구성 | 없음 | 없음 | |
모니터링 및 관찰 기능 | 제공됨 | 없음 | |
전원 관리 | 없음 | 없음 |
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