Tác giả: Ryan Niksch và Mayur Shetty
Ngày đăng: 02/01/2026
Danh mục: Containers, Hybrid Cloud Management

Telco Network Cloud (TNC) là một kiến trúc tham chiếu của Red Hat, được các nhà khai thác viễn thông sử dụng để triển khai các chức năng mạng viễn thông trên nền tảng Red Hat OpenShift Platform. Kiến trúc tham chiếu này cung cấp một OpenShift cluster trung tâm để quản lý các OpenShift cluster khác được triển khai trên toàn mạng, phục vụ việc lưu trữ các chức năng mạng 4G / 5G Core và RAN khác nhau. Hình dưới đây minh họa kiến trúc TNC ở mức tổng quan:

TNC Architecture

Tổng quan giải pháp:

Phần bên trái của hình minh họa management cluster, được sử dụng để triển khai các workload cluster khác nhau bằng cách tiếp cận Zero Touch Provisioning (ZTP) dựa trên GitOps, đồng thời quản lý vận hành (day 2 operations) và vòng đời của các workload cluster này. Các workload cluster được hiển thị ở phía bên phải hình bao gồm:

• TNC Core WorkLoad (CWL) ClustersOpenShift cluster dùng để lưu trữ các chức năng mạng 5G core
• TNC RAN WorkLoad (RWL) ClustersOpenShift cluster dùng để lưu trữ các chức năng mạng Radio Access Network (RAN)
• TNC RHOSO ClustersCác cluster Red Hat OpenStack Service on OpenShift (RHOSO) để chạy các chức năng mạng 4G được ảo hóa
• TNC Virtualization Enabled WorkLoad (VEWL) ClustersOpenShift cluster dùng để lưu trữ các workload ảo hóa thông qua OpenShift virtualization
• TNC Artificial Intelligence WorkLoad (AIWL) ClustersOpenShift cluster phục vụ huấn luyện, tinh chỉnh và triển khai (serving) các mô hình AI

Các TNC cluster hỗ trợ mô hình hybrid cloud, cho phép khách hàng triển khai on-premises, trên bare metal servers, hoặc trên cloud. Tài liệu này mô tả chi tiết việc triển khai TNC Management cluster trên Amazon Web Services (AWS), như minh họa trong hình dưới đây:

TNC on AWS

TNC Management cluster có thể được triển khai trên AWS bằng cách sử dụng Red Hat OpenShift Service on AWS (ROSA), một dịch vụ fully managed cung cấp các Red Hat OpenShift cluster trên AWS. Dịch vụ này được Red Hat và AWS cùng hỗ trợ, trong đó Red Hat chịu trách nhiệm vận hành nền tảng. Việc sử dụng ROSA để triển khai management cluster trên public cloud giúp đảm bảo cùng một nền tảng OpenShift được sử dụng cả on-premises lẫn public cloud, từ đó đơn giản hóa vận hành xuyên suốt hybrid cloud. Điều này cũng mang lại sự linh hoạt cho các nhà khai thác trong việc triển khai instance chính của management cluster trên cloud, hoặc triển khai on-premises và sử dụng public cloud cho các kịch bản disaster recovery.

TNC Management Cluster

TNC Management (MGMT) cluster cung cấp các khả năng MANagement & Orchestration (MANO) để triển khai các workload cluster (nơi các thành phần 4G, 5G core hoặc RAN được triển khai), giám sát chúng và quản lý vòng đời của các cluster này. MGMT cluster được triển khai trên Red Hat OpenShift Container Platform (either on-premises hoặc public cloud) và lưu trữ các công cụ do Red Hat cung cấp để quản lý các workload cluster từ xa. Các công cụ quản lý của bên thứ ba cũng có thể được cài đặt trên management cluster nhằm mở rộng khả năng tự động hóa hoặc quản lý các workload được triển khai trên toàn mạng.

Hình dưới đây minh họa các ứng dụng / công cụ cấu thành MGMT cluster khi được triển khai trên ROSA:

TNC MGMT on ROSA

Mục tiêu là bắt đầu với một ROSA cluster và cài đặt các ứng dụng / công cụ cần thiết để cluster này có thể triển khai, giám sát và vận hành các workload cluster trên toàn bộ môi trường hybrid. Như minh họa ở trên, MGMT cluster bao gồm các thành phần sau:

• Red Hat Advanced Cluster Management for Kubernetes (RHACM)Cung cấp khả năng triển khai ứng dụng và kiểm soát policy trên nhiều OpenShift cluster, cho phép quản lý ở quy mô lớnRHACM, kết hợp với OpenShift GitOps và Topology Aware Lifecycle Manager (TALM) operators, được sử dụng để thực hiện Zero Touch Provisioning (ZTP) dựa trên GitOps cho các workload cluster on-premises
• Red Hat Ansible Automation Platform (AAP)Ansible Automation Platform hỗ trợ quản lý các triển khai phức tạp bằng cách bổ sung khả năng kiểm soát, tri thức và phân quyền cho các môi trường sử dụng Ansible. Nền tảng này cung cấp một điểm vào (entry point) thông qua API để các bên thứ ba tương tác với môi trườngAAP trên MGMT cluster có thể được sử dụng để tự động hóa các tác vụ cấu hình cho các cluster on-premises
• Red Hat QuayRed Hat Quay là một private container registry dùng để lưu trữ, build và triển khai container imagesQuay trên MGMT cluster được sử dụng làm kho container image riêng để triển khai các cluster on-premises trong môi trường air-gapped / disconnected
• ACM ObservabilityRHACM có thể được sử dụng để tổng hợp metrics / events từ tất cả các workload cluster on-premises, cung cấp một giao diện giám sát tập trung (single pane of glass) cho đội vận hành
• Vault Secrets Operator (VSO)VSO được sử dụng để lấy credentials từ vault server và cung cấp các credentials này cho các workload đang chạy trong OpenShift cluster. Do Git được sử dụng để lưu trữ định nghĩa cluster và cấu hình cho quy trình ZTP dựa trên GitOps, nên không mong muốn việc công bố credentials trong repository Git. VSO giúp đảm bảo quy trình GitOps mà không cần lưu trữ credentials trong Git
• Vault ServerVault server có thể (tùy chọn) được triển khai trực tiếp trên TNC MGMT cluster. Dù vault server được cài đặt cục bộ hay bên ngoài ROSA cluster, VSO vẫn có thể truy xuất credentials từ vault server đó và tạo secrets trong ROSA cluster cục bộ
• StorageCác ứng dụng được triển khai trên MGMT cluster cần persistent storage. ROSA cluster sử dụng AWS EBS để cung cấp block storage cho các workload trong cluster. Dịch vụ AWS S3 được sử dụng để cung cấp object storage.

Thiết kế / Cấu hình ROSA Cluster

Các phần bên dưới giải thích thiết kế ROSA để lưu trữ TNC Management cluster, phục vụ việc triển khai, quản lý và giám sát các OpenShift cluster on-premises dạng disconnected / air-gapped thông qua Zero Touch Provisioning (ZTP) dựa trên GitOps.

Hosted Control Plane so với Classic Architecture

Dịch vụ ROSA có thể được thiết lập theo một trong hai kiến trúc sau:

• ROSA với Hosted Control Plane (HCP)Control plane được lưu trữ trong một service account và được Red Hat quản lý, trong khi các worker node được triển khai trong AWS account của khách hàng
• ROSA Classic ArchitectureCả control plane và worker node đều được triển khai trong AWS account của khách hàng và hỗ trợ baremetal (metal3) operator

Mặc dù ưu tiên sử dụng ROSA với HCP để triển khai TNC MGMT cluster, tuy nhiên tại thời điểm hiện tại ROSA với HCP chưa hỗ trợ baremetal (metal3) operator cho OpenShift. Baremetal operator là thành phần bắt buộc cho quy trình RHACM ZTP, do đó ROSA với HCP không thể được sử dụng để lưu trữ TNC MGMT cluster.

LƯU Ý: Hỗ trợ baremetal operator trên ROSA với HCP dự kiến sẽ có trong nửa đầu năm 2026.

ROSA Public Cluster so với Private Cluster

Một ROSA cluster có thể được triển khai dưới dạng public cluster như minh họa trong hình dưới đây:

ROSA public cluster

Trong cấu hình này, các ROSA node có thể truy cập internet thông qua NAT gateway và internet gateway. Lưu lượng ingress từ internet cũng có thể đi vào ROSA cluster thông qua các external load balancer do ROSA cung cấp cho API endpoint và application ingress routers.

Mặc dù ROSA public cluster cung cấp khả năng bảo vệ trước các cuộc tấn công bằng cách sử dụng security group để lọc lưu lượng ingress, một ROSA private cluster sẽ loại bỏ hoàn toàn ingress từ internet bằng cách loại bỏ external load balancer và thay thế bằng các internal / private load balancer, như minh họa trong hình dưới đây:

ROSA Private Cluster

Với ROSA private cluster, các ROSA node vẫn có thể truy cập internet thông qua NAT gateway, tuy nhiên việc truy cập ingress vào OpenShift API và ingress routers chỉ khả dụng thông qua internal load balancer. Các internal load balancer này có thể được truy cập từ bên trong VPC, thông qua VPC peering, hoặc thông qua các kết nối VPN vào VPC.

Do các TNC workload cluster (on-premises) được thiết kế theo mô hình disconnected / air-gapped, ROSA cluster dùng để lưu trữ TNC MGMT cluster cũng được thiết kế dưới dạng private ROSA cluster. Hình dưới đây minh họa thiết kế hybrid cloud của TNC, trong đó AWS site-to-site VPN được sử dụng để kết nối private ROSA cluster với các OpenShift cluster on-premises:

TNC to on prem connectivity

Kết nối ROSA với On-Premises

Có nhiều lựa chọn để kết nối ROSA cluster với các cluster on-premises. Trong thiết kế này, AWS site-to-site VPN được lựa chọn để đảm bảo kết nối. Cả hai đầu của site-to-site VPN cần quảng bá (advertise) các route phù hợp để cung cấp kết nối hai chiều:

• Quảng bá các subnet on-premises vào VPC route table, với AWS VPN gateway làm next hop
• Quảng bá các subnet private của AWS VPC vào mạng on-premises, với on-prem customer gateway router làm next hop

VPN này sẽ được sử dụng để truyền tải các loại lưu lượng sau:

• Từ ROSA sang on-prem
  • Truy cập vào on-prem BMC IP
  • Truy cập vào on-prem DNS server IP
  • Truy cập vào on-prem machineNet subnet(s)
• Từ on-prem sang ROSA
  • Truy cập vào ROSA machineNet
  • Truy cập vào ROSA private subnets

Custom Security Group

Quá trình cài đặt ROSA sẽ tạo ra các security group khác nhau để cho phép lưu lượng control plane và data plane của OpenShift. Tuy nhiên, các security group mặc định này không bao gồm các port cần thiết để RHACM thực hiện Zero Touch Provisioning cho các OpenShift cluster on-premises. Để RHACM ZTP hoạt động, các port sau cần được mở trong các security group áp dụng cho các ROSA node:

• TCP 6385 – metal3-ironic-api
• TCP 6183 – Mount virtual ISO
• TCP 9999 – ironic-python-agent

Do ROSA là một managed cluster, việc cập nhật các security group mặc định (được tạo bởi ROSA installer) là không được phép. Vì vậy, cần tạo một custom security group trước khi cài đặt ROSA và cung cấp security group này làm input cho lệnh cài đặt ROSA, để mở các port ZTP nêu trên.

Ví dụ sau minh họa việc chọn custom security group khi truyền tham số cho lệnh cài đặt ROSA dạng interactive:

? Additional ‘Compute’ Security Group IDs (optional): sg-0e5b0d0981d4adf80 (‘custom-sg-node’)

? Additional ‘Infra’ Security Group IDs (optional): sg-0e5b0d0981d4adf80 (‘custom-sg-node’)

? Additional ‘Control Plane’ Security Group IDs (optional): sg-0e5b0d0981d4adf80 (‘custom-sg-node’)

LƯU Ý: Custom security group cần được áp dụng cho các node ngay trong quá trình cài đặt ROSA. Không thể áp dụng security group cho node sau khi cluster đã được cài đặt xong.

Storage

Các ứng dụng chạy trên ROSA cluster cần truy cập vào persistent storage. Block storage được cung cấp thông qua Amazon Elastic Block Service (EBS). Trong quá trình cài đặt ROSA cluster, các CSI driver phù hợp sẽ được cấu hình và các storage class được tạo để cho phép tạo Persistent Volume Claim (PVC) phục vụ block storage lâu dài.

Có hai ứng dụng trong TNC MGMT cluster yêu cầu object storage:

• Red Hat QuaySử dụng object storage để lưu trữ container image cho private registry
• RHACM ObservabilityTổng hợp metrics và events từ các OpenShift cluster on-premises, sử dụng object storage để lưu trữ dữ liệu observability

Thiết kế này sử dụng Amazon Simple Storage Service (S3) để cung cấp object storage cho các ứng dụng trên. Các cấu hình sau cần được bổ sung ngoài cấu hình ROSA tiêu chuẩn để cung cấp quyền truy cập vào S3 bucket:

• Tạo một S3 interface endpoint nội bộ, sử dụng private subnets
• Tạo S3 bucket
• Tạo IAM user với quyền đọc / ghi dữ liệu S3 phù hợp
  • Tạo access token cho IAM user này
• Sử dụng access token đó để tạo secrets cho các dịch vụ / ứng dụng OpenShift cần truy cập S3

Cấu hình DNS

Giao tiếp hai chiều giữa MGMT (hub) cluster và các workload (spoke) cluster yêu cầu khả năng phân giải DNS chính xác cho các FQDN liên quan đến ROSA cluster cũng như các workload cluster on-premises. Điều này đòi hỏi cấu hình DNS ở cả hai phía của site-to-site VPN.

Cấu hình DNS phía ROSA

Các dịch vụ / ứng dụng trong ROSA cluster cần có khả năng phân giải các FQDN của các cluster on-premises. Ví dụ, RHACM trong MGMT cluster cần truy cập API endpoint của các workload cluster on-premises.

CoreDNS service trong ROSA cluster sẽ được cấu hình để sử dụng on-prem DNS server làm DNS forwarder / upstream server, cho phép phân giải các FQDN của on-prem clusters. Custom resource sau có thể được sử dụng để cấu hình CoreDNS trên ROSA cluster:

apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
  annotations:
    argocd.argoproj.io/sync-wave: "10"
spec:
  servers:
  - name: tse-lab
    zones:
    - npss.bos2.lab        # Domain of the on-prem OpenShift cluster(s)
    forwardPlugin:
      upstreams:
      - 192.168.22.4       # IP address of on-prem DNS server

Cấu hình DNS phía On-Premises

Các OpenShift cluster on-premises cần truy cập vào các dịch vụ / endpoint khác nhau trong ROSA cluster. Các bản ghi DNS sau cần được tạo trên on-prem DNS server để phân giải các FQDN liên quan đến ROSA:

• Truy cập ROSA Cluster API
  • Xác định địa chỉ IP tương ứng với DNS record của internal API load balancer
  • Cấu hình on-prem DNS server ánh xạ tất cả truy vấn api..domain tới IP của internal API load balancer
• Truy cập ROSA Cluster Applications
  • Xác định địa chỉ IP của internal Application load balancer
  • Cấu hình on-prem DNS server ánh xạ tất cả truy vấn .apps..domain tới IP của internal Application load balancer
• Truy cập AWS S3
  • Xác định các địa chỉ IP tương ứng với private S3 endpoint
  • Cấu hình on-prem DNS server ánh xạ mọi truy vấn s3..amazonaws.com tới IP của private S3 endpoint

Kết luận

Với cấu hình phù hợp cho cả môi trường ROSA và on-premises, TNC Management cluster có thể được triển khai an toàn trên AWS để quản lý vòng đời của các TNC workload cluster on-premises. Hình dưới đây minh họa một managed cluster được triển khai thành công on-premises từ management cluster chạy trên ROSA thông qua ZTP. Sau khi cluster on-premises được triển khai, nó có thể được giám sát thông qua dịch vụ RHACM observability. Cách tiếp cận hybrid cloud này mang lại cho các nhà khai thác sự linh hoạt trong việc lựa chọn môi trường phù hợp để vận hành OpenShift cluster, سواء là trên public cloud hay on-premises.

Tác giả

Ryan Niksch
Ryan Niksch là Partner Solutions Architect, tập trung vào các nền tảng ứng dụng, giải pháp hybrid application và hiện đại hóa hệ thống. Ryan đã đảm nhiệm nhiều vai trò khác nhau trong sự nghiệp và có niềm đam mê với việc mày mò công nghệ, cùng mong muốn cải thiện mọi thứ tốt hơn so với khi anh bắt đầu.

Mayur Shetty
Mayur Shetty là Senior Solution Architect thuộc bộ phận Global Partners and Alliances của Red Hat. Anh đã làm việc tại Red Hat trong bốn năm và từng là thành viên của OpenStack Tiger Team. Trước đó, Mayur từng giữ vai trò Senior Solutions Architect tại Seagate Technology, dẫn dắt các giải pháp sử dụng OpenStack Swift, Ceph và các phần mềm Object Storage khác. Anh cũng từng lãnh đạo ISV Engineering tại IBM, xây dựng các giải pháp xoay quanh Oracle database, IBM Systems và Storage. Mayur có gần 20 năm kinh nghiệm trong ngành và từng làm việc với Sun Cluster software cũng như các đội ISV engineering tại Sun Microsystems.