Hướng dẫn Cài đặt OpenShift Container Platform 4.17 trên VMware Workstation (Windows 11)

1. Giới thiệu: Cài đặt OCP 4.17 trên VMware Workstation

1.1. Mục tiêu

Báo cáo này nhằm mục đích cung cấp hướng dẫn toàn diện về quy trình cài đặt OpenShift Container Platform (OCP) phiên bản 4.17 trên VMware Workstation Pro, khi máy chủ lưu trữ (host) đang chạy hệ điều hành Microsoft Windows 11. Cần nhấn mạnh rằng việc cài đặt này chủ yếu dành cho mục đích phát triển, thử nghiệm hoặc học tập, không phải cho môi trường sản xuất (production).

1.2. Bối cảnh và Tuyên bố Miễn trừ Trách nhiệm

Điều quan trọng cần ghi nhận là VMware Workstation không phải là nền tảng được Red Hat hỗ trợ chính thức cho việc triển khai OCP trong môi trường production. Hỗ trợ chính thức tập trung vào các nền tảng như VMware vSphere, máy chủ vật lý (bare metal), và các nhà cung cấp đám mây công cộng.

Do đó, hướng dẫn này điều chỉnh các quy trình chủ yếu được ghi nhận cho phương pháp User-Provisioned Infrastructure (UPI) trên vSphere , Assisted Installer , hoặc UPI không phụ thuộc nền tảng (platform-agnostic) , đồng thời kết hợp các kinh nghiệm và giải pháp từ cộng đồng. Việc cài đặt theo cách này tiềm ẩn nhiều thách thức và đòi hỏi nỗ lực thủ công đáng kể hơn so với các phương pháp cài đặt được hỗ trợ chính thức.

1.3. Tổng quan về các Phương pháp được Đề cập

Báo cáo sẽ thảo luận chi tiết về các phương pháp cài đặt sau đây trong bối cảnh VMware Workstation:

• User-Provisioned Infrastructure (UPI)
• Assisted Installer
• Agent-based Installer
• OpenShift Local (trước đây là CodeReady Containers - CRC) như một giải pháp thay thế được khuyến nghị.

2. So sánh các Phương pháp Cài đặt cho VMware Workstation

Việc lựa chọn phương pháp cài đặt phù hợp là rất quan trọng khi làm việc trong môi trường không được hỗ trợ chính thức như VMware Workstation. Mỗi phương pháp có những ưu điểm và hạn chế riêng.

2.1. Installer-Provisioned Infrastructure (IPI)

Phương pháp IPI được thiết kế để tự động hóa hoàn toàn quá trình cấp phát và quản lý cơ sở hạ tầng cơ bản (như máy ảo, đĩa, mạng) cũng như các thành phần của OpenShift. Trình cài đặt sẽ đảm nhiệm việc tạo và cấu hình mọi thứ cần thiết.

Tuy nhiên, IPI không phù hợp và không thể sử dụng trên VMware Workstation. Lý do chính là IPI phụ thuộc rất nhiều vào các API đặc thù của nền tảng (ví dụ: API của vCenter cho vSphere) để thực hiện các tác vụ tự động hóa như tạo máy ảo, cấu hình mạng ảo phức tạp, và quản lý lưu trữ. VMware Workstation thiếu các API quản lý phong phú này, khiến trình cài đặt IPI không thể tương tác và kiểm soát cơ sở hạ tầng bên dưới. Do đó, từ góc độ của trình cài đặt OCP, VMware Workstation được xem như một nền tảng "generic" hoặc "none", tương tự như bare metal, đòi hỏi người dùng phải tự chuẩn bị cơ sở hạ tầng.

2.2. User-Provisioned Infrastructure (UPI)

Với phương pháp UPI, người dùng chịu trách nhiệm hoàn toàn trong việc cấp phát và quản lý toàn bộ cơ sở hạ tầng cần thiết trước khi chạy trình cài đặt OCP. Điều này bao gồm việc tạo máy ảo (VMs), cấu hình mạng, thiết lập cân bằng tải (load balancing), quản lý DNS, và cung cấp lưu trữ. Sau khi hạ tầng sẵn sàng, trình cài đặt UPI sẽ được sử dụng để cài đặt và cấu hình phần mềm OpenShift lên hạ tầng đó.

UPI là phương pháp khả thi về mặt lý thuyết trên VMware Workstation, vì người dùng có toàn quyền kiểm soát việc tạo và cấu hình VMs cũng như mạng ảo trong Workstation. Tuy nhiên, phương pháp này đòi hỏi nỗ lực thủ công rất lớn và kiến thức sâu về các yêu cầu của OCP. Người dùng phải tự mình "dịch" các yêu cầu hạ tầng của OCP thành các cấu hình cụ thể trong VMware Workstation, một quá trình phức tạp và dễ xảy ra lỗi. Mặc dù UPI trên Workstation cho phép mô phỏng một cụm OCP đầy đủ với độ trung thực cao nhất tại môi trường cục bộ, nó cũng đi kèm với gánh nặng cấu hình và khắc phục sự cố lớn nhất do thiếu sự tự động hóa và xác thực như trên các nền tảng được hỗ trợ.

2.3. Assisted Installer

Assisted Installer cung cấp một giao diện người dùng dựa trên web (thông qua Red Hat Hybrid Cloud Console) hoặc một dịch vụ cục bộ để hướng dẫn quá trình cài đặt. Nó sử dụng một Discovery ISO đặc biệt: người dùng tạo các máy ảo theo cách thủ công, sau đó khởi động chúng bằng Discovery ISO này. Các máy ảo sẽ tự đăng ký với dịch vụ Assisted Installer, sau đó quá trình cài đặt được quản lý thông qua giao diện web.

Phương pháp này có thể áp dụng cho VMware Workstation. Người dùng sẽ tự tạo các VM trong Workstation, khởi động chúng bằng Discovery ISO. Nếu các VM có thể kết nối mạng thành công đến dịch vụ Assisted Installer (trên cloud hoặc cục bộ) và được nhận dạng chính xác, quá trình cài đặt có thể tiến hành thông qua giao diện web. Điều này giúp đơn giản hóa một số khía cạnh so với UPI thuần túy, đặc biệt là giai đoạn cấu hình phần mềm OCP.

Tuy nhiên, vẫn còn những rào cản tiềm ẩn. Việc cấu hình mạng trong Workstation để đảm bảo các VM có thể "gọi về nhà" tới dịch vụ Assisted Installer (đặc biệt nếu dùng bản cloud, yêu cầu truy cập internet ) có thể phức tạp. Ngoài ra, có khả năng dịch vụ không tương thích hoàn toàn với cách Workstation báo cáo thông tin phần cứng ảo. Quan trọng nhất, việc chuẩn bị hạ tầng ban đầu (tạo VM, cấu hình mạng, DNS, VIPs) vẫn hoàn toàn thủ công, tương tự như UPI. Assisted Installer có thể được xem là một giải pháp trung gian, giảm độ phức tạp của giai đoạn cấu hình OCP nhưng vẫn đòi hỏi cùng một mức độ chuẩn bị hạ tầng thủ công trên Workstation.

2.4. Agent-based Installer

Agent-based Installer hoạt động tương tự như Assisted Installer nhưng được thiết kế đặc biệt cho các môi trường không kết nối internet (disconnected/air-gapped) hoặc cài đặt trên bare metal. Nó cũng sử dụng một ISO có khả năng khởi động chứa agent, nhưng điểm khác biệt chính là nó chạy dịch vụ Assisted Service cục bộ trên một trong các nút (nút điểm hẹn - rendezvous host), thay vì dựa vào dịch vụ trên cloud.

Đối với VMware Workstation, Agent-based Installer có tiềm năng áp dụng và các rào cản tương tự như Assisted Installer. Nó có thể là lựa chọn phù hợp hơn nếu việc đảm bảo kết nối internet từ các VM ra ngoài là một vấn đề. Tuy nhiên, nó vẫn yêu cầu người dùng phải tự tạo và cấu hình VM, mạng và DNS thủ công. Phương pháp này cung cấp một lộ trình tiềm năng cho các thiết lập OCP trên Workstation không có kết nối mạng, chia sẻ cùng gánh nặng chuẩn bị hạ tầng như UPI và Assisted Installer nhưng đóng gói dịch vụ cài đặt cục bộ.

2.5. OpenShift Local (trước đây là CodeReady Containers - CRC)

OpenShift Local là một công cụ được Red Hat hỗ trợ chính thức, được thiết kế đặc biệt để chạy một cụm OCP tối thiểu, một nút (single-node) trên máy tính cá nhân (laptop/desktop) cho mục đích phát triển và thử nghiệm.

Ưu điểm chính của OpenShift Local là sự đơn giản và tự động hóa. Quá trình cài đặt chỉ bao gồm vài lệnh đơn giản (crc setup, crc start). Công cụ này tự động quản lý máy ảo cơ bản và cấu hình mạng cần thiết, sử dụng các hypervisor gốc của hệ điều hành máy chủ (như Hyper-V trên Windows, QEMU/KVM trên Linux). Nó yêu cầu tài nguyên hệ thống thấp hơn đáng kể so với việc chạy một cụm OCP đa nút đầy đủ.

Tuy nhiên, OpenShift Local cũng có những hạn chế. Nó chỉ là một cụm đơn nút, không mô phỏng kiến trúc đa nút của môi trường production. Tài nguyên bị giới hạn và một số Operator có thể bị tắt theo mặc định để tiết kiệm tài nguyên.

OpenShift Local đại diện cho con đường ít phức tạp nhất và là phương pháp được Red Hat phê chuẩn để có được một môi trường giống OCP trên máy trạm. Nó đánh đổi sự phức tạp của kiến trúc đa nút để lấy sự dễ sử dụng và hiệu quả về tài nguyên, trở thành điểm khởi đầu lý tưởng trừ khi việc mô phỏng đa nút là yêu cầu bắt buộc.

2.6. Khuyến nghị

Dựa trên sự phức tạp, yêu cầu tài nguyên và tình trạng hỗ trợ, OpenShift Local (CRC) được khuyến nghị mạnh mẽ cho hầu hết các nhu cầu phát triển và thử nghiệm cục bộ trên Windows 11. Nó cung cấp trải nghiệm OCP cốt lõi với quy trình cài đặt đơn giản và được hỗ trợ.

Chỉ nên xem xét sử dụng UPI hoặc Assisted Installer/Agent-based Installer trên VMware Workstation nếu việc mô phỏng kiến trúc đa nút là một yêu cầu rõ ràng và không thể tránh khỏi. Người dùng cần nhận thức rõ về những thách thức đáng kể, yêu cầu tài nguyên lớn và nỗ lực cấu hình thủ công cần thiết.

2.7. Bảng so sánh các phương pháp cài đặt trên VMware Workstation

Bảng này cung cấp một cái nhìn tổng quan nhanh chóng về các lựa chọn, giúp người dùng hiểu rõ sự đánh đổi và chọn con đường phù hợp nhất trước khi đi sâu vào các yêu cầu và bước thực hiện chi tiết.

3. Yêu cầu Tiên quyết cho OCP 4.17 (UPI/Assisted) trên VMware Workstation/Windows 11

Để cài đặt thành công một cụm OCP 4.17 đầy đủ (sử dụng UPI hoặc Assisted Installer) trên VMware Workstation chạy trên Windows 11, cần đáp ứng các yêu cầu tiên quyết khắt khe về phần cứng, phần mềm và cấu hình mạng.

3.1. Hệ thống Máy chủ (Windows 11)

• Hệ điều hành: Windows 11 Pro hoặc Enterprise (64-bit). Mặc dù Workstation sử dụng hypervisor riêng, một số công cụ hoặc phương pháp thay thế như OpenShift Local có thể yêu cầu Hyper-V. Windows Subsystem for Linux (WSL2) rất hữu ích để chạy các công cụ dòng lệnh Linux như openshift-install và oc.
• CPU: Bộ xử lý đa lõi hiện đại (khuyến nghị tối thiểu 8 lõi vật lý) hỗ trợ ảo hóa phần cứng (Intel VT-x hoặc AMD-V) và tính năng này phải được bật trong BIOS/UEFI của máy.
• RAM: Yêu cầu dung lượng RAM rất lớn. Tối thiểu 32GB, nhưng khuyến nghị mạnh mẽ là 64GB trở lên. Việc chạy đồng thời nhiều máy ảo OCP (bootstrap, control plane, worker) tiêu tốn rất nhiều RAM. Ví dụ, một cụm tối thiểu (1 bootstrap + 3 control plane + 2 worker) có thể yêu cầu khoảng 80GB RAM chỉ riêng cho các VM OCP (16GB + 3*16GB + 2*8GB = 80GB), chưa kể đến RAM cho hệ điều hành Windows 11 và các ứng dụng khác.
• Ổ đĩa: Ổ SSD tốc độ cao (khuyến nghị NVMe) với dung lượng trống ít nhất 500GB, tốt nhất là 1TB trở lên. Mỗi máy ảo OCP cần khoảng 100-120GB dung lượng đĩa. Một cụm 6 nút có thể cần khoảng 720GB chỉ cho các VM, cộng thêm dung lượng cho HĐH chủ, phần mềm Workstation, file ISO, v.v.
• Lưu ý: Yêu cầu tài nguyên hệ thống chủ để chạy một cụm OCP đầy đủ trên Workstation là rất đáng kể, thường vượt quá cấu hình của các máy trạm phát triển thông thường. Đây là một hạn chế thực tế lớn, nhấn mạnh sự phức tạp và tính không thực tế của việc này đối với nhiều người dùng.

3.2. VMware Workstation Pro

• Phiên bản: Khuyến nghị sử dụng phiên bản mới nhất (ví dụ: Workstation Pro 17.x) để đảm bảo tương thích tốt nhất với Windows 11 và các tính năng ảo hóa mới nhất. Các phiên bản cũ hơn như 16.x có thể hoạt động nhưng có thể thiếu tính năng hoặc gặp vấn đề tương thích. Cần kiểm tra khả năng tương thích của Workstation với Windows 11.
• Giấy phép: Yêu cầu giấy phép VMware Workstation Pro trả phí.

3.3. Tài khoản Red Hat và Công cụ

• Tài khoản Red Hat: Cần có tài khoản Red Hat Developer (đăng ký miễn phí ) hoặc tài khoản trả phí để tải phần mềm và pull secret.
• Pull Secret: Tải về từ Red Hat Hybrid Cloud Console (console.redhat.com). Đây là thông tin xác thực cần thiết cho openshift-install và cụm OCP để tải các image container từ registry của Red Hat và các registry khác.
• OpenShift Installer (openshift-install): Tải về phiên bản cho Linux (để sử dụng trong WSL hoặc một VM Linux riêng) hoặc phiên bản cho Windows. Phiên bản phải khớp với OCP 4.17.
• OpenShift Client (oc): Tải về phiên bản cho Linux hoặc Windows. Phiên bản nên khớp với OCP 4.17.
• SSH Client và Cặp khóa (Key Pair): Cần thiết cho openshift-install để cấu hình truy cập SSH vào các nút và để người dùng truy cập các nút sau khi cài đặt. Tạo cặp khóa bằng lệnh ssh-keygen (có sẵn trong WSL, Git Bash, hoặc sử dụng PuTTYgen trên Windows).

3.4. Yêu cầu Tài nguyên Máy ảo OCP

Việc cấu hình đúng tài nguyên cho từng loại máy ảo OCP là cực kỳ quan trọng. Bảng dưới đây tóm tắt các yêu cầu tối thiểu cho OCP 4.17:

Lưu ý quan trọng:

• Các giá trị trên là tối thiểu và chưa bao gồm tài nguyên cho các ứng dụng người dùng (user workloads).
• Hệ điều hành yêu cầu là Red Hat Enterprise Linux CoreOS (RHCOS), trừ khi worker node được cấu hình để dùng RHEL (khi đó người dùng tự quản lý vòng đời HĐH).
• OCP 4.13 trở lên yêu cầu kiến trúc CPU x86-64-v2 hoặc cao hơn.
• Hiệu năng đĩa rất quan trọng, đặc biệt là độ trễ ghi (latency) cho etcd trên các control plane node. Nên sử dụng SSD NVMe cho máy chủ host để đảm bảo IOPS và độ trễ thấp.

3.5. Mạng ảo VMware Workstation

Cấu hình mạng ảo chính xác trong Workstation là một trong những phần phức tạp nhất và dễ gây lỗi nhất.

• VMnet Tùy chỉnh: Tạo một mạng ảo riêng biệt (ví dụ: VMnet2, VMnet3...) trong Virtual Network Editor của Workstation dành riêng cho cụm OCP. Tránh sử dụng các mạng mặc định như NAT (VMnet8) hoặc Host-Only (VMnet1) để có toàn quyền kiểm soát dải IP và tránh xung đột.
• Sơ đồ Địa chỉ IP: Xác định một dải địa chỉ IP riêng cho VMnet tùy chỉnh này (ví dụ: 192.168.100.0/24).
• DHCP hoặc IP Tĩnh:

• DHCP: Có thể sử dụng dịch vụ DHCP tích hợp của Workstation trên VMnet tùy chỉnh (cấu hình trong Virtual Network Editor). Tuy nhiên, cần đảm bảo các địa chỉ IP được cấp phát ổn định cho các node OCP (Workstation DHCP khá cơ bản, có thể cần cấu hình lease dài hạn hoặc đặt trước IP theo địa chỉ MAC nếu có thể). Ngay cả khi dùng DHCP cho các node, vẫn cần cấu hình địa chỉ IP tĩnh cho các Virtual IP (VIPs) của API và Ingress.
• IP Tĩnh: Cấu hình thủ công địa chỉ IP tĩnh cho từng máy ảo OCP trong dải IP đã chọn. Đây là phương pháp được khuyến nghị khi cài đặt UPI/Assisted trên Workstation để đảm bảo tính ổn định và dễ quản lý. Khi sử dụng IP tĩnh, cần tắt dịch vụ DHCP của Workstation trên VMnet đó.

• Kết nối Mạng:

• Các máy ảo OCP phải có khả năng giao tiếp với nhau trên cùng VMnet.
• Máy chủ Windows 11 cần có khả năng kết nối đến các máy ảo (để chạy openshift-install, oc, SSH).
• Cần có kết nối Internet trong quá trình cài đặt để tải các container image, trừ khi thực hiện cài đặt không kết nối (disconnected installation) với một mirror registry được chuẩn bị trước. Cấu hình NAT trên VMnet tùy chỉnh hoặc sử dụng chế độ Bridged một cách cẩn thận nếu cần truy cập Internet trực tiếp từ các VM.

• Lưu ý: Việc cấu hình mạng đúng cách trong Workstation đòi hỏi người dùng phải đóng vai trò quản trị viên mạng, tự thiết kế không gian địa chỉ, lựa chọn giữa DHCP và IP tĩnh, cấu hình VMnet và đảm bảo kết nối giữa các thành phần. Đây là điểm khác biệt lớn so với môi trường vSphere nơi các công cụ mạng ảo mạnh mẽ hơn và có thể được tự động hóa phần nào.

3.6. Yêu cầu Cổng Mạng OCP

Cần đảm bảo các cổng mạng cần thiết được phép lưu thông giữa các máy ảo OCP và giữa máy chủ host với các máy ảo. Điều này đặc biệt quan trọng nếu có tường lửa trên máy chủ Windows 11 hoặc cấu hình tường lửa bên trong VM (mặc dù tường lửa của RHCOS thường được OCP quản lý).

3.7. Chiến lược Xử lý DNS và VIP

Đây là một trong những thách thức lớn nhất khi cài đặt OCP trên Workstation, vì môi trường này thiếu các thành phần hạ tầng mạng chuyên dụng như máy chủ DNS quản lý tập trung và bộ cân bằng tải phần cứng/phần mềm thường thấy trong môi trường vSphere hoặc production.

• Thách thức: OCP yêu cầu phân giải DNS ổn định cho các bản ghi cụ thể (API, Ingress, etcd) và cần có địa chỉ IP ảo (VIPs) cho API và Ingress để đảm bảo tính sẵn sàng cao và truy cập dịch vụ.
• Các tùy chọn Chiến lược DNS:

• Sử dụng tệp hosts trên Windows 11: Chỉnh sửa tệp C:\Windows\System32\drivers\etc\hosts trên máy chủ Windows 11 để thêm các bản ghi cần thiết (ví dụ: api.<cluster>.<domain>, *.apps.<cluster>.<domain>) trỏ đến các địa chỉ IP phù hợp (VIPs hoặc IP node cụ thể). Đây là cách đơn giản nhất nhưng có nhiều hạn chế: không cung cấp DNS cho các node trong cụm tự phân giải lẫn nhau, khó quản lý, và phải cấu hình trên mọi máy khách cần truy cập cụm.
• Chạy Máy chủ DNS cục bộ trong VM: Tạo một máy ảo Linux nhỏ (ví dụ: CentOS/RHEL/Ubuntu) trên cùng VMnet, cài đặt và cấu hình một máy chủ DNS nhẹ như dnsmasq hoặc BIND. Cấu hình địa chỉ IP của VM này làm máy chủ DNS cho tất cả các máy ảo OCP khác (bootstrap, control plane, worker). Đây là phương pháp được khuyến nghị vì nó cung cấp khả năng phân giải DNS thực sự cho toàn bộ cụm và máy chủ host.
• Sử dụng DNS Công cộng: Không phù hợp cho môi trường Workstation cục bộ vì yêu cầu sở hữu tên miền công cộng và quản lý bản ghi DNS phức tạp.

• Các tùy chọn Chiến lược VIP:

• Sử dụng IP của Máy chủ Host: Gán các địa chỉ VIP (cho API và Ingress) bằng chính địa chỉ IP của máy chủ Windows 11 trên giao diện mạng VMnet tùy chỉnh. Cách này đơn giản nhưng phụ thuộc vào máy chủ host luôn hoạt động và có thể gây xung đột cổng.
• Sử dụng IP của một VM chuyên dụng (Load Balancer): Tạo một VM riêng (ví dụ: chạy HAProxy ) trên VMnet. Gán các địa chỉ VIP cho VM này. Cấu hình HAProxy để chuyển tiếp lưu lượng đến các cổng tương ứng (6443/22623 cho control plane, 80/443 cho worker). Cách này mô phỏng gần nhất với một bộ cân bằng tải thực sự nhưng đòi hỏi cấu hình phức tạp hơn.
• Sử dụng trực tiếp IP của Node: Trỏ bản ghi DNS api và api-int trực tiếp đến địa chỉ IP của control plane node đầu tiên. Trỏ bản ghi wildcard *.apps đến địa chỉ IP của một hoặc nhiều worker node (có thể dùng DNS round-robin nếu máy chủ DNS hỗ trợ). Cách này kém tin cậy nhất vì phụ thuộc vào trạng thái hoạt động của các node cụ thể và không cung cấp tính sẵn sàng cao thực sự.

• Bảng các Bản ghi DNS Yêu cầu (OCP 4.17):

• Lưu ý: Việc triển khai thành công DNS và VIP mà không có hạ tầng cân bằng tải và DNS chuyên dụng là một trở ngại lớn trên Workstation. Các giải pháp thay thế thủ công này ảnh hưởng đáng kể đến mức độ tương đồng của cụm với môi trường production và tính ổn định tổng thể của nó.

4. Hướng dẫn Cài đặt: OCP 4.17 UPI trên VMware Workstation

Phần này mô tả chi tiết quy trình cài đặt OCP 4.17 bằng phương pháp User-Provisioned Infrastructure (UPI), được điều chỉnh cho môi trường VMware Workstation, nhấn mạnh các bước thủ công cần thực hiện. Nên sử dụng WSL2 hoặc một máy ảo Linux riêng để chạy các lệnh openshift-install và oc.

4.1. Bước 1: Chuẩn bị Thư mục Cài đặt và Tệp Cấu hình

1. Tạo thư mục cài đặt: Trên máy tính sẽ chạy lệnh openshift-install (ví dụ: trong WSL), tạo một thư mục trống để chứa các tệp cài đặt (ví dụ: ~/ocp-install).
2. Tạo tệp install-config.yaml: Đây là tệp cấu hình chính cho trình cài đặt. Tạo tệp này trong thư mục cài đặt với nội dung tương tự như sau, điều chỉnh các giá trị cho phù hợp với môi trường của bạn :
   apiVersion: v1
   baseDomain: mydomain.local # Thay thế bằng base domain của bạn
   compute:
   - architecture: amd64
    hyperthreading: Enabled
    name: worker
    platform: {}
    replicas: 2 # Số lượng worker node mong muốn (tối thiểu 2 cho HA)
   controlPlane:
    architecture: amd64
    hyperthreading: Enabled
    name: master
    platform: {}
    replicas: 3 # Luôn là 3 cho control plane
   metadata:
    creationTimestamp: null
    name: myocpcluster # Tên cụm của bạn (tối đa 14 ký tự)
   networking:
    clusterNetwork:
    - cidr: 10.128.0.0/14 # Dải IP cho mạng Pod
      hostPrefix: 23
    machineNetwork:
    - cidr: 192.168.100.0/24 # Dải IP của VMnet tùy chỉnh trong Workstation
    networkType: OVNKubernetes # Hoặc OpenShiftSDN
    serviceNetwork:
    - 172.30.0.0/16 # Dải IP cho Services
   platform:
    none: {} # Quan trọng: Sử dụng platform: none cho Workstation [span_182](start_span)[span_182](end_span)[span_183](start_span)[span_183](end_span)
   fips: false # Đặt là true nếu cần chế độ FIPS
   pullSecret: '{"auths":...}' # Dán nội dung pull secret của bạn vào đây
   sshKey: 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAB...' # Dán nội dung public key SSH của bạn
   
3. (Tùy chọn) Cấu hình IP Tĩnh: Nếu bạn chọn sử dụng IP tĩnh (khuyến nghị), bạn cần thêm phần platform.none.hosts vào install-config.yaml. Điều này yêu cầu bạn phải biết trước địa chỉ MAC của từng card mạng ảo của các VM sẽ tạo.
   platform:
    none:
      hosts:
        # Bootstrap node
        - hostname: bootstrap-0.myocpcluster.mydomain.local
          role: bootstrap
          bootMACAddress: 00:50:56:XX:XX:00 # Thay bằng MAC của bootstrap VM
          networkConfig:
            interfaces:
              - name: ens192 # Tên interface trong RHCOS
                macAddress: 00:50:56:XX:XX:00 # Lặp lại MAC
                ipAddresses:
                  - 192.168.100.10/24 # IP tĩnh/CIDR
            dns:
              servers:
                - 192.168.100.2 # IP của DNS Server VM (hoặc DNS khác)
            routes:
              - destination: 0.0.0.0/0
                nextHop: 192.168.100.1 # Gateway của VMnet
        # Control plane nodes (lặp lại cho master-0, master-1, master-2)
        - hostname: master-0.myocpcluster.mydomain.local
          role: master
          bootMACAddress: 00:50:56:XX:XX:01 # Thay bằng MAC của master-0 VM
          networkConfig:
            interfaces:
              - name: ens192
                macAddress: 00:50:56:XX:XX:01
                ipAddresses:
                  - 192.168.100.11/24
            dns:
              servers:
                - 192.168.100.2
            routes:
              - destination: 0.0.0.0/0
                nextHop: 192.168.100.1
        #... (master-1, master-2)
        # Worker nodes (lặp lại cho worker-0, worker-1,...)
        - hostname: worker-0.myocpcluster.mydomain.local
          role: worker
          bootMACAddress: 00:50:56:XX:XX:10 # Thay bằng MAC của worker-0 VM
          networkConfig:
            interfaces:
              - name: ens192
                macAddress: 00:50:56:XX:XX:10
                ipAddresses:
                  - 192.168.100.20/24
            dns:
              servers:
                - 192.168.100.2
            routes:
              - destination: 0.0.0.0/0
                nextHop: 192.168.100.1
        #... (worker-1,...)
   

4.2. Bước 2: Tạo tệp Ignition

Sau khi install-config.yaml đã sẵn sàng, chạy lệnh sau trong thư mục cài đặt để tạo các tệp cấu hình Ignition cho từng loại node :

./openshift-install create ignition-configs --dir=.

Lệnh này sẽ tạo ra các tệp bootstrap.ign, master.ign, và worker.ign. Các tệp này chứa thông tin cấu hình ban đầu mà các máy ảo RHCOS sẽ sử dụng khi khởi động lần đầu, bao gồm cả cấu hình mạng nếu IP tĩnh được định nghĩa trong install-config.yaml.

4.3. Bước 3: Tạo Máy ảo RHCOS trong VMware Workstation

Đây là bước thủ công tốn nhiều công sức nhất.

1. Tải RHCOS: Tải xuống image Red Hat CoreOS (RHCOS) phù hợp với OCP 4.17 từ trang tải xuống của Red Hat. Tìm image dành cho nền tảng VMware (thường là định dạng OVA). Mặc dù OVA dễ dàng hơn cho vSphere, bạn có thể cần giải nén OVA để lấy file VMDK hoặc sử dụng ISO nếu Workstation không nhập OVA trực tiếp một cách trơn tru.
2. Tạo VMs: Trong VMware Workstation, tạo thủ công số lượng máy ảo cần thiết:

• 1 máy ảo Bootstrap
• 3 máy ảo Control Plane (Master)
• Ít nhất 2 máy ảo Worker (Compute)

3. Cấu hình VMs:

• Đặt tên VM rõ ràng (ví dụ: ocp-bootstrap, ocp-master-0, ocp-worker-1).
• Cấu hình tài nguyên (vCPU, RAM, Disk) cho mỗi VM theo bảng yêu cầu tối thiểu ở Phần 3.4.
• Chọn "Red Hat Enterprise Linux 8 (64-bit)" hoặc tương đương làm Guest OS type.
• Gắn ổ đĩa ảo (VMDK) từ file RHCOS đã tải về (hoặc sử dụng ISO để cài đặt nếu cần).
• Quan trọng: Gắn card mạng ảo của mỗi VM vào VMnet tùy chỉnh đã tạo ở Phần 3.5.
• Ghi lại địa chỉ MAC của card mạng ảo của từng VM. Địa chỉ MAC này là cần thiết nếu bạn cấu hình IP tĩnh thông qua install-config.yaml. Đảm bảo địa chỉ MAC trong cấu hình khớp với địa chỉ MAC thực tế của VM.
• Nếu không dùng IP tĩnh qua Ignition, bạn cần cấu hình IP tĩnh thủ công bên trong hệ điều hành RHCOS sau khi khởi động (ít được khuyến nghị hơn).

4.4. Bước 4: Triển khai Chiến lược DNS và VIP

Thực hiện cấu hình DNS và VIP đã chọn ở Phần 3.7.

• DNS: Nếu dùng VM DNS, hãy khởi động và cấu hình nó. Nếu dùng file hosts, hãy cập nhật file trên máy chủ Windows và các máy khách cần thiết. Đảm bảo tất cả các bản ghi DNS yêu cầu (Bảng ở Phần 3.7) được định nghĩa chính xác và trỏ đến các địa chỉ IP (VIPs hoặc node IPs) phù hợp.
• VIP: Nếu dùng VM HAProxy, hãy khởi động, cài đặt và cấu hình HAProxy để cân bằng tải cho các cổng API (6443, 22623) đến các control plane node và các cổng Ingress (80, 443) đến các worker node. Nếu dùng IP host hoặc IP node trực tiếp, đảm bảo các bản ghi DNS trỏ đúng địa chỉ.

4.5. Bước 5: Khởi động Máy ảo và Cung cấp Ignition

Đây là một bước phức tạp khác do Workstation không có cơ chế chuẩn để cung cấp dữ liệu Ignition như vSphere (GuestInfo).

1. Chuẩn bị phương thức cung cấp Ignition:

• Khuyến nghị: Máy chủ HTTP: Thiết lập một máy chủ web đơn giản (ví dụ: dùng Python http.server, Nginx, Apache) trên máy chủ Windows host hoặc trong một VM tiện ích trên cùng VMnet. Đặt các tệp bootstrap.ign, master.ign, worker.ign vào thư mục gốc của web server.
• Cách khác (Phức tạp): Chỉnh sửa ISO RHCOS để nhúng tệp Ignition hoặc cấu hình bootloader để tải Ignition từ URL.

2. Khởi động VMs:

• Bootstrap VM: Khởi động VM bootstrap. Nếu dùng máy chủ HTTP, bạn cần truy cập vào menu bootloader (thường là GRUB) của RHCOS khi khởi động (nhấn phím Tab hoặc 'e' tại màn hình boot). Thêm tham số kernel sau vào dòng lệnh khởi động Linux, thay URL bằng địa chỉ thực tế: coreos.inst.ignition_url=http://<địa_chỉ_IP_máy_chủ_HTTP>:8080/bootstrap.ign (Nếu cấu hình IP tĩnh qua Ignition, RHCOS sẽ tự áp dụng cấu hình mạng đó để tải file Ignition).
• Control Plane VMs: Khởi động lần lượt các VM control plane, cung cấp master.ign qua tham số kernel tương tự: coreos.inst.ignition_url=http://<địa_chỉ_IP_máy_chủ_HTTP>:8080/master.ign
• Worker VMs: Khởi động lần lượt các VM worker, cung cấp worker.ign: coreos.inst.ignition_url=http://<địa_chỉ_IP_máy_chủ_HTTP>:8080/worker.ign

4.6. Bước 6: Theo dõi Quá trình Bootstrap và Cài đặt

1. Theo dõi Bootstrap: Từ máy chạy openshift-install, chạy lệnh sau để theo dõi quá trình bootstrap hoàn tất :
   

./openshift-install wait-for bootstrap-complete --dir=. --log-level=info Quá trình này có thể mất một khoảng thời gian đáng kể (30-60 phút hoặc hơn) khi bootstrap node thiết lập một cụm etcd và control plane tạm thời. 2. **Tắt Bootstrap VM:** Sau khi lệnh `wait-for bootstrap-complete` báo thành công, các control plane node thực sự đã tiếp quản. Bạn có thể tắt và xóa máy ảo bootstrap để giải phóng tài nguyên.[span_201](start_span)[span_201](end_span)[span_202](start_span)[span_202](end_span)[span_203](start_span)[span_203](end_span) 3. **Theo dõi Cluster Operators:** Sử dụng `oc` (cần cấu hình KUBECONFIG, xem Bước 7) để theo dõi trạng thái của các Cluster Operator. Chờ cho đến khi tất cả các operator báo cáo trạng thái `Available=True`, `Progressing=False`, `Degraded=False`.bash export KUBECONFIG=auth/kubeconfig oc get clusteroperators ``` Quá trình này cũng có thể mất thêm 30-60 phút hoặc lâu hơn.

4.7. Bước 7: Truy cập Cụm sau Cài đặt

1. Cấu hình oc CLI:

• Đặt biến môi trường KUBECONFIG trỏ đến tệp cấu hình được tạo ra trong thư mục auth của thư mục cài đặt.

• Linux/WSL/macOS: export KUBECONFIG=~/ocp-install/auth/kubeconfig
• Windows CMD: set KUBECONFIG=%USERPROFILE%\ocp-install\auth\kubeconfig
• Windows PowerShell: $env:KUBECONFIG="$env:USERPROFILE\ocp-install\auth\kubeconfig"

2. Đăng nhập: Đăng nhập vào cụm bằng tài khoản kubeadmin. Mật khẩu được lưu trong tệp ~/ocp-install/auth/kubeadmin-password.
   oc login -u kubeadmin -p <mật_khẩu_từ_file> https://api.myocpcluster.mydomain.local:6443
   (Thay FQDN bằng API FQDN của bạn). Bạn có thể cần chấp nhận chứng chỉ tự ký nếu chưa cấu hình CA tin cậy.
3. Truy cập Web Console: Mở trình duyệt và truy cập vào địa chỉ web console : https://console-openshift-console.apps.myocpcluster.mydomain.local (Thay FQDN bằng wildcard apps FQDN của bạn). Đăng nhập bằng kubeadmin và mật khẩu tương ứng.

5. Hướng dẫn Cài đặt: OCP 4.17 Assisted Installer trên VMware Workstation

Phương pháp này sử dụng giao diện web Assisted Installer trên Red Hat Hybrid Cloud Console để hướng dẫn cài đặt, giả định các máy ảo có thể kết nối Internet.

5.1. Bước 1: Tạo Cụm trong Giao diện Assisted Installer

1. Truy cập: Đăng nhập vào console.redhat.com bằng tài khoản Red Hat của bạn và điều hướng đến phần OpenShift -> Create cluster -> Datacenter.
2. Chọn Nền tảng: Chọn "VMware vSphere" (mặc dù đang dùng Workstation, đây là lựa chọn gần nhất) hoặc "None" (Bare Metal) nếu tùy chọn vSphere gây ra vấn đề về yêu cầu không thể đáp ứng.
3. Cấu hình Cụm:

• Nhập Cluster name và Base domain.
• Chọn phiên bản OpenShift 4.17.
• Chọn "Install standard OpenShift cluster" (không phải SNO).
• Chọn phương thức cấp phát IP (DHCP hoặc Static). Nếu chọn Static, bạn sẽ cần nhập thông tin mạng chi tiết sau này.

4. Tiếp tục: Nhấn "Next" hoặc "Create".

5.2. Bước 2: Tạo Discovery ISO

1. Thêm SSH Key: Trong giao diện Assisted Installer, cung cấp public key SSH của bạn để có thể truy cập các node sau khi cài đặt.
2. Tạo ISO: Nhấn nút "Generate Discovery ISO" hoặc tương đương. Quá trình này có thể mất vài phút.
3. Tải ISO: Tải về tệp Discovery ISO được tạo ra.

5.3. Bước 3: Tạo Máy ảo trong VMware Workstation

1. Tạo VMs: Tương tự như UPI (Bước 3), tạo thủ công các máy ảo trong VMware Workstation theo yêu cầu tài nguyên (Phần 3.4) :

• 3 máy ảo Control Plane (Master)
• Ít nhất 2 máy ảo Worker (Compute)
• Không cần tạo máy ảo Bootstrap cho Assisted Installer.

2. Cấu hình Mạng: Gắn card mạng ảo của mỗi VM vào VMnet tùy chỉnh. Đảm bảo VMnet này được cấu hình để cho phép các VM truy cập Internet (ví dụ: sử dụng NAT của Workstation trên VMnet đó) để chúng có thể liên lạc với dịch vụ Assisted Installer trên cloud.

5.4. Bước 4: Triển khai Chiến lược DNS và VIP

Thực hiện cấu hình DNS và VIP thủ công giống hệt như đã mô tả cho UPI (Phần 3.7 và Bước 4 của Phần 4). Assisted Installer không tự động cấu hình các thành phần này trên Workstation; nó mong đợi chúng đã được thiết lập và hoạt động chính xác.

5.5. Bước 5: Khởi động Máy ảo bằng Discovery ISO

1. Gắn ISO: Trong cài đặt của từng máy ảo (control plane và worker) trong Workstation, gắn tệp Discovery ISO đã tải về vào ổ đĩa CD/DVD ảo.
2. Khởi động: Khởi động các máy ảo này. Đảm bảo chúng được cấu hình để khởi động từ CD/DVD. Các máy ảo sẽ khởi động vào môi trường RHCOS từ ISO và tự động chạy agent để đăng ký với dịch vụ Assisted Installer.

5.6. Bước 6: Khám phá Host và Cấu hình

1. Theo dõi UI: Quay lại giao diện Assisted Installer trên trình duyệt web.
2. Chờ đợi Hosts: Chờ đợi các máy ảo xuất hiện trong danh sách "Discovered hosts". Quá trình này có thể mất vài phút sau khi các VM khởi động xong.
3. Xác thực và Gán vai trò:

• Kiểm tra xem các host có đáp ứng yêu cầu tối thiểu về tài nguyên (CPU, RAM, Disk) hay không.
• Gán vai trò (Control plane / Worker) cho từng host nếu dịch vụ không tự động phát hiện chính xác.

4. Cấu hình Mạng:

• Chọn Subnet phù hợp từ danh sách các mạng được phát hiện trên các host (phải là mạng VMnet tùy chỉnh của bạn).
• Nhập địa chỉ API Virtual IP và Ingress Virtual IP. Các địa chỉ này phải khớp với những gì bạn đã cấu hình trong DNS và giải pháp VIP thủ công ở Bước 4.

5.7. Bước 7: Theo dõi Quá trình Cài đặt

1. Bắt đầu Cài đặt: Khi tất cả các host đã được khám phá, xác thực thành công và cấu hình mạng hoàn tất, nút "Install cluster" hoặc tương đương sẽ khả dụng. Nhấn vào đó để bắt đầu quá trình cài đặt.
2. Theo dõi: Theo dõi tiến trình cài đặt thông qua giao diện web. Giao diện sẽ hiển thị trạng thái của từng bước và các sự kiện của cụm. Quá trình này có thể mất từ 45 phút đến vài giờ.

5.8. Bước 8: Truy cập Cụm sau Cài đặt

1. Tải Thông tin: Sau khi cài đặt hoàn tất thành công, giao diện Assisted Installer sẽ cung cấp:

• Nút để tải về tệp kubeconfig.
• Mật khẩu cho người dùng kubeadmin.

2. Truy cập: Sử dụng tệp kubeconfig và mật khẩu đã tải về để truy cập cụm thông qua oc CLI và web console, tương tự như hướng dẫn ở Bước 7 của Phần 4.

Lưu ý: Mặc dù Assisted Installer đơn giản hóa việc triển khai phần mềm OCP bằng cách loại bỏ sự cần thiết của việc chạy openshift-install và quản lý tệp Ignition thủ công, thách thức cơ bản trên Workstation vẫn là việc tạo và cấu hình thủ công cơ sở hạ tầng VM, mạng, DNS và VIP. Trình cài đặt giả định rằng tất cả các yếu tố này đã được chuẩn bị chính xác trước khi quá trình khám phá host bắt đầu.

6. Thách thức Chính: OCP trên Workstation so với vSphere

Việc cài đặt và vận hành một cụm OCP đầy đủ trên VMware Workstation đặt ra nhiều thách thức đáng kể so với việc triển khai trên nền tảng được hỗ trợ như VMware vSphere:

• Thiếu Tự động hóa IPI: Đây là khác biệt lớn nhất. Không có khả năng tự động cấp phát VM, cấu hình mạng hoặc lưu trữ như IPI trên vSphere. Mọi bước chuẩn bị hạ tầng đều phải thực hiện thủ công.
• Quản lý Vòng đời Thủ công: Các tác vụ như mở rộng cụm (thêm/xóa node), nâng cấp phiên bản OCP, và quản lý tài nguyên VM đều yêu cầu can thiệp thủ công trong Workstation. Ngược lại, trên vSphere, IPI hoặc UPI thường tích hợp với Machine API để tự động hóa các quy trình này.
• Độ phức tạp Mạng: Việc thiết lập mạng, DNS và cân bằng tải (VIPs) một cách đáng tin cậy bằng cách sử dụng các công cụ cơ bản của Workstation (VMnets, file hosts, VM tiện ích) phức tạp và dễ bị lỗi hơn đáng kể so với việc sử dụng các tính năng mạng tích hợp mạnh mẽ của vSphere (vSwitches, Port Groups, NSX-T) và các bộ cân bằng tải chuyên dụng.
• Cấp phát Lưu trữ: OCP yêu cầu lưu trữ ổn định và hiệu năng cao. Trên vSphere, các trình điều khiển CSI (Container Storage Interface) tích hợp với datastores của vSphere để cấp phát động bộ nhớ lưu trữ. Trên Workstation, người dùng phải tự cấu hình lưu trữ, thường dựa vào các giải pháp như NFS shares (có thể chạy trên một VM khác) hoặc host-path volumes, vốn có những hạn chế về hiệu năng và độ tin cậy. Việc đạt được IOPS yêu cầu trên đĩa cứng của máy trạm có thể rất khó khăn.
• Hạn chế Tài nguyên và Hiệu năng: Chạy nhiều máy ảo cấp máy chủ trên một máy trạm duy nhất gây áp lực lớn lên tài nguyên của máy chủ host (CPU, RAM, Disk I/O). Hiệu năng tổng thể gần như chắc chắn sẽ thấp hơn đáng kể so với phần cứng chuyên dụng chạy vSphere. Tranh chấp I/O đĩa là một mối quan tâm lớn, đặc biệt đối với etcd.
• Thiếu Tích hợp vCenter: Mất đi khả năng quản lý tập trung, giám sát, tính sẵn sàng cao (HA), vMotion , quy tắc chống phân cụm DRS (DRS anti-affinity rules) , và các tính năng doanh nghiệp khác do vCenter cung cấp.
• Khắc phục sự cố: Việc chẩn đoán sự cố trở nên khó khăn hơn khi không có hệ thống ghi log và giám sát tích hợp của vSphere cũng như sự ổn định của một nền tảng được hỗ trợ. Sự cố có thể xuất phát từ cấu hình Workstation, hệ điều hành host, hoặc chính OCP.

Tóm lại, việc cài đặt OCP trên Workstation buộc người dùng phải tự tái tạo thủ công nhiều dịch vụ hạ tầng và tính năng tự động hóa vốn được coi là mặc định trong các môi trường vSphere được hỗ trợ. Điều này làm tăng đáng kể độ phức tạp, giảm độ tin cậy và làm cho cụm kết quả khác biệt đáng kể so với môi trường production.

7. Giải pháp Thay thế: Cài đặt OpenShift Local (CRC) trên Windows 11

Đối mặt với những thách thức của việc cài đặt cụm OCP đầy đủ trên Workstation, OpenShift Local (trước đây là CodeReady Containers - CRC) nổi lên như một giải pháp thay thế hấp dẫn và được khuyến nghị.

7.1. Tổng quan và Trường hợp Sử dụng

OpenShift Local là công cụ chính thức của Red Hat, được thiết kế để cung cấp một môi trường OpenShift đơn nút, tối thiểu, chạy cục bộ trên máy tính Windows, macOS hoặc Linux cho mục đích phát triển và thử nghiệm. Nó lý tưởng cho các nhà phát triển cần một môi trường giống OCP để xây dựng, kiểm thử ứng dụng, Operator hoặc cấu hình mà không cần đến sự phức tạp và tài nguyên của một cụm đa nút đầy đủ.

Quan trọng là, OpenShift Local không chạy bên trong VMware Workstation. Thay vào đó, nó sử dụng hypervisor gốc của hệ điều hành máy chủ để quản lý máy ảo của mình (Hyper-V trên Windows, HyperKit/QEMU trên macOS, KVM/QEMU trên Linux). Điều này giúp đơn giản hóa đáng kể việc cài đặt và tránh các vấn đề về ảo hóa lồng nhau (nested virtualization).

7.2. Yêu cầu Hệ thống

7.3. Các bước Cài đặt (Trực tiếp trên Windows 11 sử dụng Hyper-V)

1. Bật Hyper-V: Đảm bảo tính năng Hyper-V đã được kích hoạt trên Windows 11. Tìm kiếm "Turn Windows features on or off" và chọn Hyper-V. Khởi động lại máy nếu được yêu cầu. (Lưu ý: Mặc dù khả năng tương thích đã được cải thiện, Hyper-V và VMware Workstation đôi khi có thể xung đột. Đảm bảo Workstation không chạy khi cài đặt hoặc khởi động CRC nếu gặp sự cố).
2. Tải về:

• Truy cập console.redhat.com/openshift/create/local. Đăng nhập bằng tài khoản Red Hat.
• Tải về trình cài đặt crc cho Windows (thường là file .msi hoặc .zip).
• Tải về Pull Secret.

3. Cài đặt crc:

• Nếu tải file .msi, chạy trình cài đặt. Có thể cần chạy từ Command Prompt (Admin) nếu cài đặt qua giao diện đồ họa thất bại.
• Nếu tải file .zip, giải nén và thêm đường dẫn đến thư mục chứa crc.exe vào biến môi trường PATH của hệ thống.

4. Thiết lập (Setup): Mở Command Prompt hoặc PowerShell với quyền Administrator và chạy lệnh:
   crc setup
   Lệnh này sẽ tải về image máy ảo RHCOS cần thiết (kích thước lớn, ~10GB trở lên) và cấu hình các thiết lập hệ thống cần thiết. Nó sẽ tạo thư mục $HOME/.crc (ví dụ: C:\Users\<username>\.crc) để lưu trữ cache và cấu hình, yêu cầu khoảng 35GB dung lượng trống.
5. (Tùy chọn) Cấu hình Tài nguyên: Nếu máy chủ có đủ tài nguyên, bạn có thể tăng RAM và CPU cho máy ảo CRC (mặc định là 9GB RAM, 4 CPU) :
   crc config set memory 16384 # Cấu hình 16GB RAM
   crc config set cpus 8       # Cấu hình 8 CPU
   crc config view             # Xem lại cấu hình
   
6. Khởi động Cụm: Chạy lệnh sau, thay <đường_dẫn_đến_pull_secret> bằng đường dẫn thực tế đến tệp pull secret đã tải về:
   crc start -p <đường_dẫn_đến_pull_secret>
   Lệnh này sẽ tạo máy ảo Hyper-V (nếu chưa có), khởi động nó, và cài đặt OpenShift bên trong. Quá trình này mất vài phút đến vài chục phút.

7.4. Truy cập Cụm OpenShift Local

• Thông tin Đăng nhập: Khi crc start hoàn tất, nó sẽ hiển thị thông tin quan trọng :

• Địa chỉ Web Console (thường là https://console-openshift-console.apps-crc.testing)
• Mật khẩu cho người dùng kubeadmin.
• Thông tin đăng nhập cho người dùng developer (thường là developer/developer).
• Bạn cũng có thể lấy lại thông tin này sau bằng lệnh crc console --credentials.

• Truy cập CLI (oc):

• Để sử dụng lệnh oc với cụm CRC, cần cấu hình biến môi trường. Chạy lệnh sau trong PowerShell:
  crc oc-env | Invoke-Expression
  Hoặc trong Command Prompt:
  @FOR /f "tokens=*" %i IN ('crc oc-env') DO @%i
  (Trong WSL/bash: eval $(crc oc-env)).
• Đăng nhập bằng kubeadmin:
  oc login -u kubeadmin -p <mật_khẩu_kubeadmin> https://api.crc.testing:6443
  
• Hoặc đăng nhập bằng developer:
  oc login -u developer -p developer https://api.crc.testing:6443
  

.

• Truy cập Web Console: Mở trình duyệt và truy cập địa chỉ console đã được cung cấp (ví dụ: https://console-openshift-console.apps-crc.testing). Bạn sẽ cần chấp nhận cảnh báo về chứng chỉ tự ký. Đăng nhập bằng kubeadmin hoặc developer.

7.5. Quản lý Cụm OpenShift Local

• Dừng cụm: crc stop (Dừng máy ảo nhưng giữ lại cấu hình và đĩa).
• Xóa cụm: crc delete (Xóa máy ảo và các tệp cấu hình liên quan, giải phóng tài nguyên đĩa).
• Dọn dẹp cache: crc cleanup (Xóa các tệp cache đã tải về, ví dụ: image VM).

7.6. So sánh: OpenShift Local vs. OCP đầy đủ trên Workstation

OpenShift Local giải quyết trực tiếp nhu cầu của người dùng về một môi trường OCP cục bộ trên máy Windows với sự đơn giản tối đa, tận dụng hypervisor gốc của host thay vì yêu cầu ảo hóa lồng nhau phức tạp trong Workstation. Đây là giải pháp trực tiếp và được hỗ trợ nhất cho mục tiêu phát triển và thử nghiệm cục bộ.

8. Kết luận và Khuyến nghị

8.1. Tóm tắt Phát hiện

Báo cáo này đã phân tích tính khả thi và những thách thức của việc cài đặt OpenShift Container Platform 4.17 đầy đủ (sử dụng phương pháp UPI hoặc Assisted Installer) trên VMware Workstation chạy Windows 11. Kết quả cho thấy đây là một quy trình không được Red Hat hỗ trợ chính thức, phức tạp, đòi hỏi nỗ lực cấu hình thủ công đáng kể, đặc biệt là trong việc thiết lập mạng, DNS, VIP và quản lý tài nguyên. Yêu cầu về tài nguyên hệ thống máy chủ cũng rất cao, có thể vượt quá khả năng của nhiều máy trạm thông thường.

8.2. Tóm tắt về OpenShift Local

Ngược lại, OpenShift Local (CRC) được trình bày như một giải pháp thay thế được Red Hat hỗ trợ chính thức, đơn giản hơn đáng kể và hiệu quả hơn về tài nguyên. Nó được thiết kế đặc biệt để cung cấp một môi trường OCP đơn nút cho mục đích phát triển và thử nghiệm cục bộ trên máy tính cá nhân, sử dụng hypervisor gốc của hệ điều hành chủ (Hyper-V trên Windows).

8.3. Khuyến nghị Cuối cùng

Dựa trên các phân tích và so sánh, các khuyến nghị sau được đưa ra:

1. Đối với hầu hết người dùng (Nhà phát triển, Thử nghiệm, Học tập): Khuyến nghị mạnh mẽ nên bắt đầu với OpenShift Local (CRC) cài đặt trực tiếp trên Windows 11 (sử dụng Hyper-V). Đây là cách nhanh nhất, dễ dàng nhất và được hỗ trợ để có được trải nghiệm OCP cốt lõi trên máy trạm của bạn.
2. Đối với người dùng nâng cao cần mô phỏng đa nút: Nếu việc mô phỏng kiến trúc đa nút là một yêu cầu tuyệt đối không thể tránh khỏi và bạn chấp nhận sự phức tạp cũng như tình trạng không được hỗ trợ, phương pháp UPI là con đường khả thi nhất về mặt kỹ thuật. Tuy nhiên, cần chuẩn bị sẵn sàng đối mặt với việc cấp phát tài nguyên máy chủ lớn, cấu hình thủ công chi tiết và quy trình khắc phục sự cố phức tạp. Assisted Installer (hoặc Agent-based Installer) có thể giảm bớt một phần gánh nặng cấu hình phần mềm OCP so với UPI nếu việc khám phá host qua mạng hoạt động, nhưng những thách thức cơ bản về chuẩn bị hạ tầng thủ công trên Workstation vẫn còn nguyên vẹn.
3. Lưu ý quan trọng: Cần nhấn mạnh rằng cả UPI và Assisted Installer trên VMware Workstation đều không thể tái tạo hoàn toàn một môi trường production OCP do những hạn chế cố hữu của nền tảng và các giải pháp thay thế thủ công bắt buộc phải sử dụng. Chúng chỉ nên được xem xét cho các mục đích thử nghiệm kiến trúc hoặc học tập rất cụ thể.