Tungsten Fabric vRouter Phần 3: Lab Đầu Tiên — Dựng OpenSDN All-in-One
Phần 3/18 trong loạt Tungsten Fabric vRouter. Từ bài này, series bắt đầu tay làm thật — dùng lại kiến trúc Agent/Forwarder đã đào sâu ở Bài 2. Người đọc không cần biết trước Kubernetes/kolla-ansible chi tiết, chỉ cần khái niệm container orchestration cơ bản.
Mục tiêu bài học: sau bài này bạn biết chính xác có bao nhiêu con đường chính thức để dựng một cụm OpenSDN all-in-one (AIO — viết tắt chính OpenSDN dùng), yêu cầu tài nguyên thật của từng con đường (đã verify qua README, không suy đoán), registry container hiện tại dùng tên gì — và quan trọng không kém: bạn có đủ dữ liệu để tự đánh giá một máy bất kỳ (kể cả máy đang đọc bài này) có đủ điều kiện chạy lab thật hay không.
Một lưu ý minh bạch trước khi đọc tiếp: bài này được viết trên một môi trường không đủ tài nguyên để tự dựng AIO thật (chi tiết và con số cụ thể ở Mục 5) — nên đây là một walkthrough từng bước đã verify kỹ qua nguồn chính thức, dùng được thật nếu bạn chạy trên một máy đủ điều kiện, chứ không phải output lab đã chạy thật trong lúc viết bài. Bài 4 trở đi phụ thuộc vào việc bạn (người đọc) tự dựng cluster này trên máy của mình.
Ba câu hỏi mà bài này trả lời:
- OpenSDN hiện có bao nhiêu công cụ dựng lab all-in-one, khác nhau ở đâu, và tài liệu chính thức có mâu thuẫn nhau không?
- Registry container thật hiện tại là gì, và image có còn được build đều đặn không?
- Với đúng tài nguyên đang có trong tay, bạn nên chọn công cụ nào và chạy theo đúng những bước gì?
Mục lục
- 1. Điểm xuất phát: từ kiến trúc tới lab thật
- 2. Ba con đường chính thức dựng OpenSDN AIO
- 3. Bảng so sánh tài nguyên và đặc điểm
- 4. Một mâu thuẫn thật giữa hai nguồn docs — bài học verify
- 5. Registry container hiện tại, và vì sao bài này không chạy lab thật
- 6. Walkthrough: dựng AIO bằng tf-devstack/k8s_manifests
- 7. Cấu trúc container bên trong 1 node AIO
- 8. Verify cluster sống, và bước tiếp theo
- Bài tập cuối bài
- Nguồn tham khảo
1. Điểm xuất phát: từ kiến trúc tới lab thật
Bài 1 và Bài 2 đã dừng ở đúng chỗ lý thuyết cho phép: kiến trúc Agent/Forwarder, 4 kỹ thuật liên quan (kernel, DPDK, SR-IOV, SmartNIC offload), packet walk byte-level — tất cả dựa trên docs và source, chưa có một cụm nào chạy thật để soi. Mọi bài từ Bài 4 trở đi (CLI introspect, XMPP, Config API, BGP EVPN, encapsulation...) đều cần một cụm OpenSDN sống. Bài này là bước bản lề: chọn đúng công cụ, verify đúng yêu cầu tài nguyên, và đưa ra một quy trình chạy được thật — trước khi bất kỳ bài nào sau đó giả định "cluster đã có sẵn".
Outline nội bộ của series này để ngỏ ba cái tên chưa biết cái nào đúng: tf-devstack, tf-dev-env, tf-ansible-deployer. Mục 2 verify cả ba qua chính README của chúng trên github.com/opensdn-io.
2. Ba con đường chính thức dựng OpenSDN AIO
2.1 Phân biệt trước: dev suite vs deployment tool
tf-dev-env không phải công cụ để "dựng lab" theo nghĩa bài này cần — nó là môi trường để build OpenSDN từ source (dựng container build, fetch source contrail/controller, contrail/vrouter...). README của tf-devstack mô tả rõ quan hệ ba repo:
"Full TF dev suite consists of: tf-dev-env (develop and build TF), tf-devstack (deploy TF), tf-dev-test (test deployed TF). Each of these tools can be used separately or in conjunction with the other two."
Vì series này chỉ cần triển khai từ container đã publish sẵn (không sửa source, không tự build), tf-dev-env không cần dùng ở bài này — chỉ cần biết nó tồn tại, để không nhầm lẫn khi đọc README tf-devstack (có nhắc tới trong "Developer's scenario"). Công cụ cần là tf-devstack — tên đúng như dự đoán ban đầu trong outline.
2.2 tf-devstack: một wrapper, ba phương án deploy bên trong
README tf-devstack xác nhận:
"tf-devstack is a tool for deployment of OpenSDN from published containers or building and deploying from sources... allows bringing up OpenSDN along with Kubernetes or OpenStack cloud on an all-in-one single node deployment."
Bên trong, có ba thư mục deploy độc lập, mỗi thư mục một run.sh/cleanup.sh riêng:
k8s_manifests/— deploy trực tiếp bằng k8s manifest (kubespray dựng Kubernetes, rồi OpenSDN được cài như CNI qua một manifest YAML render sẵn). Đây là phương án nhẹ nhất trong ba, và README ghi rõ đây là "quick start".ansible/— gọi tới repo riêngtf-ansible-deployer(Mục 2.3) để deploy, hỗ trợ cả Kubernetes lẫn OpenStack làm orchestrator, có sẵn kịch bản multi-node (CONTROLLER_NODES/AGENT_NODES) nếu sau này cần mở rộng khỏi AIO.juju/— dùng Juju charms, chỉ hỗ trợ Ubuntu, đích nhắm rõ ràng là production-like (yêu cầu tài nguyên cao nhất trong ba, xem Mục 3).
Hai thuật ngữ mới ở dòng đầu tiên đáng dừng lại giải thích trước khi đi tiếp, vì sẽ còn gặp lại nhiều lần từ đây tới hết bài:
- CNI (Container Network Interface) — chuẩn plugin Kubernetes dùng để giao việc cấp phát network cho Pod (IP, route, policy) cho một bên thứ ba thay vì Kubernetes tự làm. Khi README nói "OpenSDN được cài như CNI", nghĩa là chính vRouter Agent (đã học ở Bài 2) đóng vai trò plugin đó — mỗi Pod tạo ra sẽ được vRouter cấp interface/IP/route theo đúng cơ chế nó đã dùng cho VM ở kiến trúc OpenStack.
- kubespray — bộ Ansible playbook chính thức của dự án Kubernetes, dùng để tự dựng cluster K8s (kể cả single-node) trên hạ tầng riêng, thay vì dùng managed service như EKS/GKE.
k8s_manifests/run.shgọi kubespray làm bước nền trước khi OpenSDN được cài lên trên.
2.3 tf-ansible-deployer: lớp bên dưới tf-devstack/ansible
Đây là repo độc lập (github.com/opensdn-io/tf-ansible-deployer), README ghi thẳng dòng đầu tiên:
"This set of commands will configure the instance and install AIO opensdn with k8s on the instance"
— xác nhận "AIO" là chữ viết tắt chính thức OpenSDN dùng (không phải cách gọi tự đặt trong outline series này), và quy trình "impatient" chỉ cần 3 lệnh ansible-playbook chạy tuần tự trên một instance CentOS 7 duy nhất:
ansible-playbook -i inventory/ -e orchestrator=kubernetes \
-e '{"instances":{"bms1":{"ip":"192.168.1.100","provider":"bms"}}}' \
playbooks/configure_instances.yml
ansible-playbook -i inventory/ -e orchestrator=kubernetes \
-e '{"instances":{"bms1":{"ip":"192.168.1.100","provider":"bms"}}}' \
playbooks/opensdn.yml
ansible-playbook -i inventory/ -e orchestrator=kubernetes \
-e '{"instances":{"bms1":{"ip":"192.168.1.100","provider":"bms"}}}' \
playbooks/install_k8s.yml
Ba playbook đúng ba việc: configure_instances.yml cài prerequisite (Docker, docker-compose...) lên instance đích; opensdn.yml pull và cấu hình container OpenSDN; install_k8s.yml dựng Kubernetes single-node làm CNI substrate. tf-devstack/ansible/run.sh (Mục 2.2) chỉ là một lớp bọc ngoài gọi đúng ba playbook này với biến môi trường thay vì tham số -e thủ công.
3. Bảng so sánh tài nguyên và đặc điểm
Số liệu dưới đây trích nguyên văn từ README từng công cụ (docs.opensdn.io không có trang riêng cho sizing AIO — xem Mục 4), tất cả cùng verify ngày 02-03/09/2026:
| Công cụ | CPU tối thiểu | RAM tối thiểu | Disk tối thiểu | OS | Orchestrator | Thời gian ước tính |
|---|---|---|---|---|---|---|
tf-devstack/k8s_manifests | 2 vCPU | 10 GB | 120 GB | Ubuntu 18.04 / CentOS 7.x | Kubernetes (mặc định, duy nhất) | không ghi rõ trong README |
tf-devstack/ansible (K8s) | 2 vCPU | 8 GB | 30 GB | CentOS 7 / Ubuntu 18.04, 20.04 | Kubernetes (mặc định) | 30-60 phút |
tf-devstack/ansible (OpenStack) | 2 vCPU | 10 GB | 30 GB | như trên | OpenStack (train) | 30-60 phút |
tf-devstack/juju | 8 vCPU | 16 GB (K8s) / 32 GB (OpenStack) | 120 GB | Ubuntu 18.04 | Kubernetes hoặc OpenStack | 30-60 phút |
| (đối chiếu) Install Guide chính thức, production | 4 vCPU mỗi server | 64 GB mỗi server | 300 GB mỗi server | RHEL/CentOS 7.5+ | đa dạng | không ghi rõ |
Ba phương án đầu là "đủ dùng để chạy", không phải "chuẩn production" — README tf-devstack/ansible nói thẳng khuyến nghị AWS 4 vCPU/16GB cho trải nghiệm mượt hơn, còn mức "Minimal" trong bảng là ngưỡng chạy được, không phải ngưỡng thoải mái. Dòng cuối bảng (Mục 4 giải thích rõ hơn) là một tài liệu khác hẳn về mục đích — mỗi server 4 vCPU/64GB/300GB là sizing cho triển khai multi-node thật, không phải ngưỡng tối thiểu cho một lab AIO cá nhân.
Khuyến nghị cho người đọc lần đầu: tf-devstack/k8s_manifests — nhẹ nhất, ít tham số nhất, đúng nghĩa "quick start" (một lệnh run.sh duy nhất). Mục 6 viết walkthrough theo phương án này.
4. Một mâu thuẫn thật giữa hai nguồn docs — bài học verify
Đây không phải tình huống giả định để minh họa — nó xảy ra thật trong lúc research bài này, và đúng là loại rủi ro mà phần "Cảnh báo rủi ro" trong nghiên cứu nội bộ trước khi thiết kế series này đã lường trước: "docs.opensdn.io mirror lại phần lớn nội dung cũ dưới namespace release/releases/rX.Y/... không có xác nhận nào từ phía OpenSDN hiện tại".
Trang "Getting Started with OpenSDN and Ansible Deployer" trên docs.opensdn.io (thuộc nhánh tài liệu "master", không đóng dấu version cũ) mô tả:
- Target node: 4 CPU / 64 GB RAM / 300 GB — trùng khớp với dòng "Install Guide production" ở bảng Mục 3, không phải sizing AIO nhẹ.
- Container registry:
tungstenfabric(biếnCONTAINER_REGISTRY). - Clone repo
contrail-ansible-deployer, nhánh R5.0.
Trong khi đó, chính README hiện tại của tf-ansible-deployer/tf-devstack trên github.com/opensdn-io (Mục 2, verify cùng ngày) lại dùng registry opensdn, repo tên tf-ansible-deployer (không phải contrail-ansible-deployer), và không hề đặt ngưỡng "64GB mỗi server" làm mặc định cho kịch bản AIO.
Hai nguồn này không sai lẫn nhau một cách ngẫu nhiên — trang "Getting Started" nhiều khả năng là nội dung mirror gần như nguyên vẹn từ tài liệu Tungsten Fabric R5.0 cũ (tên registry tungstenfabric, tên repo contrail-ansible-deployer đều là danh xưng trước khi fork sang OpenSDN), chưa được cập nhật lại để khớp với registry/repo đã đổi tên trên opensdn-io. Đây chính là lý do bài này ưu tiên GitHub README của opensdn-io (Mục 2, 3) làm nguồn chính cho mọi con số, chỉ dùng docs.opensdn.io cho phần khái niệm/kiến trúc không đổi theo tên registry.
💡 Hình dung như thế này: giống việc cầm hai tấm bản đồ cùng một thành phố, một tấm in trước đợt thành phố đổi tên hàng loạt con đường, một tấm cập nhật sau đó. Cả hai đều là bản đồ "thật", không tấm nào giả — nhưng nếu bạn lái xe theo tên đường trên tấm cũ, bạn sẽ đến một địa chỉ không còn tồn tại nữa. Không hỏi "tấm nào đúng" mà phải hỏi "tấm nào được cập nhật gần thời điểm mình đang đi nhất" — chính là lý do Mục 2-3 bài này ưu tiên đọc GitHub README (được sửa cùng nhịp với code) thay vì trang tổng hợp tĩnh trên docs site.
⚠️ Không suy ra thêm gì ngoài phạm vi đã verify: chưa xác nhận được toàn bộ trang "Getting Started" có lỗi thời hay chỉ riêng phần registry/repo name — phần bước cấu hình
instances.yaml, playbookconfigure_instances.yml/install_openstack.yml/install_contrail.ymlcó thể vẫn đúng cấu trúc (tương tự cấu trúc 3 playbook đã thấy ởtf-ansible-deployerhiện tại, dù khác tên file cụ thể). Nếu bạn tự triển khai theo trang đó, luôn overrideCONTAINER_REGISTRY=opensdnthay vì dùng mặc địnhtungstenfabric— registry đó rất có thể không còn được publish image mới (chưa verify riêng, nhưng nhất quán với việc toàn bộ image hiện hành đã chuyển sangopensdn— xem Mục 5).
5. Registry container hiện tại, và vì sao bài này không chạy lab thật
5.1 Registry: Docker Hub, tổ chức opensdn
Không cần suy đoán — GitHub README (CONTAINER_REGISTRY mặc định opensdn) khớp trực tiếp với dữ liệu thật từ Docker Hub API: tổ chức opensdn trên Docker Hub có 165 repository image, bao gồm cả cặp tên cũ/mới song song cho gần như mọi component — ví dụ contrail-vrouter-agent và tf-vrouter-agent, contrail-tools và tf-tools, contrail-status và tf-status cùng tồn tại. Cả hai cặp tên có kích thước image khác nhau đôi chút (không phải cùng 1 build gắn 2 tag) — nghĩa là pipeline build hiện tại cố tình tạo cả hai tên cho từng thành phần, nhiều khả năng để không phá vỡ tương thích ngược cho ai còn dùng convention contrail-* cũ.
Điểm cần verify thêm ở Bài 4-5 khi có lab thật: contrail-tools và tf-tools bên trong có phải cùng chứa vif/flow/rt/nh/mpls (đã học ở Contrail Part 3) hay có khác biệt nào — README các repo không mô tả nội dung image chi tiết tới mức đó.
5.2 Cảnh báo staleness: image không rebuild từ 05/06/2025
Đây là phát hiện đáng chú ý nhất khi tra cứu tag: mọi image kiểm tra được (tf-vrouter-agent, contrail-tools, tf-tools, contrail-status, tf-status...) đều có tag mới nhất (latest và tag ngày 2025-06-05) dừng lại đúng cùng một thời điểm — không có build nào mới hơn tính tới lúc viết bài (03/09/2026), tức khoảng 15 tháng không rebuild image publish. Điều này tương phản trực tiếp với phần verify hiện trạng dự án ở outline series (repo source tf-vrouter, tf-controller trên opensdn-io có commit gần nhất 07-08/2026) — nói cách khác: source code vẫn đang phát triển, nhưng pipeline publish image lên Docker Hub đã ngừng chạy đều đặn hơn một năm nay.
Hệ quả thực tế cho bất kỳ ai tự dựng lab theo bài này: image latest/master-latest kéo về không phản ánh code mới nhất trên opensdn-io — chỉ là snapshot từ giữa 2025. Riêng biến CONTRAIL_CONTAINER_TAG=master-latest (mặc định của tf-devstack/k8s_manifests, Mục 2.2) có một vấn đề cụ thể hơn: tra toàn bộ tag hiện có của tf-vrouter-agent trên Docker Hub (161 tag, chỉ gồm latest và các tag đóng dấu ngày) không tag nào tên master-latest — nghĩa là chạy đúng mặc định trong README rất có thể lỗi "tag không tồn tại" khi pull image. Khuyến nghị khi tự chạy walkthrough Mục 6: đặt tường minh CONTRAIL_CONTAINER_TAG=latest thay vì để mặc định.
5.3 Vì sao bài này không chạy lab thật ngay trong lúc viết
Đối chiếu bảng Mục 3 (ngưỡng nhẹ nhất: 2 vCPU / 8-10 GB RAM / 30-120 GB disk) với máy đang dùng để viết bài này:
| Yêu cầu tối thiểu (nhẹ nhất) | Máy viết bài này | |
|---|---|---|
| CPU | 2 vCPU | 1 vCPU |
| RAM | 8-10 GB | 6.3 GB tổng (không phải RAM rảnh) |
| Disk trống | 30-120 GB | 16 GB |
| Ảo hóa lồng (nested KVM) | không bắt buộc với k8s_manifests, nhưng OpenStack/QEMU cần | /dev/kvm không tồn tại |
Thiếu cả CPU lẫn RAM lẫn disk so với ngưỡng thấp nhất đã verify — và tf-devstack/k8s_manifests tự nó còn dựng thêm cả một cụm Kubernetes qua kubespray bên trong máy đó, việc này đặt thêm yêu cầu ngầm về quyền hệ thống (systemd, kernel module) mà một sandbox chạy container không đảm bảo có đủ. Kết luận nhất quán với quy ước Mục 11 của outline series: đây là bài walkthrough lý thuyết dựa trên docs chính thức, các bước ở Mục 6 chính xác theo README đã verify, nhưng chưa có output thật đi kèm — không giả vờ đã lab.
6. Walkthrough: dựng AIO bằng tf-devstack/k8s_manifests
Các bước dưới đây dành cho người đọc muốn tự chạy trên máy/VM đủ điều kiện (VD: một VM cloud 2-4 vCPU, 16GB RAM, 120GB disk, Ubuntu 20.04 hoặc CentOS 7.x, có /dev/kvm nếu định thử thêm OpenStack sau này dù k8s_manifests không bắt buộc).
Bước 1 — Chuẩn bị máy
# CentOS 7.x
sudo yum install -y git
# Ubuntu 18.04/20.04
sudo apt update && sudo apt install -y git
Docker cần có sẵn trên máy (README ansible/ yêu cầu Docker ≥ 18.06.1-ce; k8s_manifests/ không nói lại con số này nhưng dùng chung cơ chế build container qua tf-dev-env, nên áp cùng yêu cầu). Cài theo hướng dẫn chính thức Docker Engine cho distro tương ứng trước khi qua bước 2.
Bước 2 — Clone tf-devstack
git clone http://github.com/opensdn-io/tf-devstack
Bước 3 — Đặt biến môi trường (khuyến nghị, không phải bắt buộc theo README)
export CONTAINER_REGISTRY=opensdn # đã là mặc định, đặt tường minh cho chắc
export CONTRAIL_CONTAINER_TAG=latest # override "master-latest" — xem Mục 5.2, tag đó chưa xác nhận tồn tại
Bước 4 — Chạy triển khai
tf-devstack/k8s_manifests/run.sh
Theo README, lệnh này chạy tuần tự 4 giai đoạn (có thể chạy tách rời bằng target, ví dụ run.sh build):
build— containertf-dev-envđược fetch, dùng làm base để "build" (thực chất chủ yếu là kéo container theo tag đã cấu hình khi không sửa source) và đẩy vào registry local.k8s— Kubernetes single-node được dựng bằng kubespray.manifest— filetf.yamlđược render từ template, điền registry/tag/subnet đã cấu hình.tf— manifest được apply, OpenSDN được cài làm CNI cho cluster K8s vừa dựng.wait— script tự pollcontrail-statustới khi mọi component báo active.
Thời gian không được README này nêu rõ; đối chiếu 2 phương án còn lại (Mục 3, cùng quy mô công việc: dựng K8s + cài OpenSDN) đều ghi 30-60 phút — dùng con số này làm ước lượng tham khảo, chưa verify riêng cho k8s_manifests.
Bước 5 — Nếu muốn build từ nhánh master thay vì tag cố định
tf-devstack/k8s_manifests/run.sh master
README ghi chú lệnh này dùng "most recent sources from master" — phù hợp nếu bạn muốn test đúng code mới nhất trên opensdn-io thay vì image đã cũ 15 tháng (Mục 5.2), nhưng sẽ tốn thời gian build từ source thay vì chỉ pull image — cân nhắc thời gian/tài nguyên trước khi chọn.
7. Cấu trúc container bên trong 1 node AIO
README tf-ansible-deployer có sẵn một sơ đồ ASCII chính thức mô tả cách các container được nhóm lại theo service (tương tự khái niệm Pod trong Kubernetes) — hữu ích để hình dung "1 node AIO" thực chất gồm bao nhiêu nhóm tiến trình chạy song song, dù cả cluster chỉ là 1 máy vật lý/VM duy nhất. Sơ đồ dưới đây vẽ lại đúng cấu trúc đó (đã gộp cả nhóm analytics và các sub-group tùy chọn của nó vào một khối cho gọn):
💡 Hình dung như thế này: kiến trúc multi-node production giống một nhà hàng đủ biên chế — một người đứng bếp chính, một người sơ chế, một người phục vụ, mỗi người một việc, phục vụ được nhiều bàn cùng lúc. AIO giống đúng một đầu bếp duy nhất tự tay làm hết cả sáu việc đó trong một gian bếp nhỏ — nấu ra được đúng món, đúng công thức, nhưng chỉ phục vụ nổi một bàn tại một thời điểm. Bài này dựng gian bếp một người đó không phải để mở nhà hàng, mà để học đúng công thức trước khi nghĩ tới việc tuyển thêm người.
Đối chiếu nhanh với kiến trúc đã học: nhóm config + control + webui + configdb chính là ba loại node Controller (Config/Control/Analytics) đã học ở Contrail Part 2 — cộng thêm nhóm hạ tầng dùng chung (rabbitmq/zookeeper/cassandra) mà Contrail Part 2 gọi chung là "Cassandra + Zookeeper + RabbitMQ" phía sau Config Node. Nhóm vrouter là đúng Agent + Forwarding Plane đã đào sâu ở Bài 2 — trong AIO, nhóm này chạy trên cùng node với Controller thay vì trên compute node riêng như production, một khác biệt cần nhớ khi đọc output CLI ở Bài 4 (đừng ngạc nhiên nếu thấy control-plane và data-plane container cùng nằm trên 1 docker ps/kubectl get pods).
8. Verify cluster sống, và bước tiếp theo
8.1 Lệnh verify: contrail-status
Cả k8s_manifests (target wait) lẫn Install Guide chính thức đều dùng contrail-status làm lệnh verify chuẩn — chạy bên trong container/pod tương ứng, liệt kê từng service con và trạng thái (active/inactive/initializing), gom nhóm theo đúng cấu trúc 6 nhóm đã vẽ ở Mục 7. Đây là lệnh đã được nhắc tên ở Bài 1 nhưng chưa có output thật:
contrail-status
== Contrail vRouter ==
supervisor-vrouter: active
contrail-vrouter-agent active
contrail-vrouter-nodemgr active
== Contrail Control ==
supervisor-control: active
contrail-control active
contrail-dns active
contrail-named active
contrail-control-nodemgr active
== Contrail Config ==
supervisor-config: active
contrail-api:0 active
contrail-schema active
contrail-svc-monitor active
contrail-device-manager active
contrail-config-nodemgr active
== Contrail Analytics ==
supervisor-analytics: active
contrail-collector active
contrail-analytics-api active
contrail-analytics-nodemgr active
(Output minh họa — cấu trúc == <nhóm> == + tên service + trạng thái đúng theo lệnh thật đã dẫn ở Contrail Part 9, số lượng/tên service cụ thể chỉ mang tính minh họa — chưa chạy trên cluster thật. Nếu mọi dòng đều active, cluster AIO đã sẵn sàng cho Bài 4; bất kỳ dòng nào initializing kéo dài hoặc inactive là dấu hiệu cần xem log container tương ứng trước khi đi tiếp.)
Bài 4 sẽ chạy lệnh này (và các lệnh introspect khác) trên cluster do chính bạn dựng theo Mục 6, với output thật thay vì minh họa.
⚠️ Điểm chưa nhất quán, cần verify tiếp khi có lab thật: README
tf-devstack/ansible(Mục 2.2) viết targets bao gồm bước "wait - wait until opensdn-status verifies that all components are active" — khác tên vớicontrail-statusdùng ởk8s_manifestsvà Install Guide. Chưa xác định được đây là (a) một binary mới thật sự tênopensdn-statusđã tồn tại song song (giống cặpcontrail-tools/tf-toolsở Mục 5.1), hay (b) chỉ là lỗi đánh máy trong README khi mô tả hành vi (thực thi vẫn gọicontrail-statusbên trong). Không suy đoán thêm — Bài 4 sẽ kiểm tradocker exec/kubectl execvào container thật để xác nhận binary nào tồn tại.
8.2 Bước tiếp theo
Sau khi contrail-status báo mọi component active, bước cuối theo outline gốc là tạo một Virtual Network đầu tiên để có dữ liệu soi ở Bài 4. Vì bài này không có cluster thật để tạo VN và lấy output thật (Mục 5.3), bước đó dời sang đúng lúc có lab: đọc lại Mục 6 khi bạn đã dựng xong cluster trên máy riêng, dùng contrail-status xác nhận sống, rồi tiếp tục sang Bài 4 (CLI introspect vif/rt/nh/mpls/flow trên chính cluster đó).
Bài tập cuối bài
- Tự đánh giá một máy bạn đang có quyền truy cập (máy cá nhân, VM cloud, hay máy cơ quan) theo đúng bảng Mục 3 — CPU/RAM/disk/OS có đạt ngưỡng "Minimal" của
tf-devstack/k8s_manifestskhông? Nếu không đạt, máy đó thiếu chính xác gì (giống cách Mục 5.3 phân tích máy viết bài này)? - Không xem lại Mục 4, tự trả lời: nếu bạn tình cờ tìm thấy trang "Getting Started with OpenSDN and Ansible Deployer" trên
docs.opensdn.iotrước khi đọc bài này, bạn có định dùngCONTAINER_REGISTRY=tungstenfabrictheo đúng trang đó không? Giải thích bằng 1-2 câu tại sao nên nghi ngờ một con số/tên gọi trong docs nếu nó không khớp với repo GitHub đang hoạt động, dựa trên bằng chứng cụ thể đã thấy ở Mục 4 (không phải nguyên tắc chung chung). - (Chỉ làm nếu có máy đủ điều kiện) Chạy walkthrough Mục 6 thật, chụp lại output
contrail-statusđầy đủ — đây sẽ là input trực tiếp cho Bài 4.
Nguồn tham khảo
- "Full TF dev suite consists of: tf-dev-env..., tf-devstack..., tf-dev-test...", mô tả 3 phương án deploy (
k8s_manifests/ansible/juju) và yêu cầu tài nguyên từng phương án — README, github.com/opensdn-io/tf-devstack, truy cập 02-03/09/2026. - Yêu cầu tài nguyên + biến môi trường (
CONTAINER_REGISTRY,CONTRAIL_CONTAINER_TAG) cho phương ánk8s_manifests— README, k8s_manifests, truy cập 03/09/2026. - Yêu cầu tài nguyên, targets, biến môi trường cho phương án
ansible(bao gồm dòng "wait until opensdn-status verifies...") — README, ansible, truy cập 03/09/2026. - Yêu cầu tài nguyên phương án
juju— README, juju, truy cập 03/09/2026. - Nguyên văn "install AIO opensdn with k8s", 3 lệnh
ansible-playbookquick-start, sơ đồ ASCII container grouping theo service (configdb/config/control/webui/vrouter/analytics) — README, github.com/opensdn-io/tf-ansible-deployer, truy cập 03/09/2026. - Yêu cầu 4 CPU/64GB RAM/300GB disk mỗi server, registry
tungstenfabric, repocontrail-ansible-deployernhánh R5.0 — Getting Started with OpenSDN and Ansible Deployer, docs.opensdn.io, truy cập 03/09/2026. Đối chiếu Mục 4: registry/tên repo không khớp vớiopensdn-iohiện tại, nghi vấn nội dung mirror chưa cập nhật. - Yêu cầu phần cứng "mỗi server" (4 CPU/64GB/300GB), thuộc nhánh docs "master" — Server Requirements and Supported Platforms, docs.opensdn.io, truy cập 03/09/2026.
- Danh sách 165 repository trong tổ chức Docker Hub
opensdn, xác nhận cặp têncontrail-*/tf-*song song (contrail-tools/tf-tools,contrail-vrouter-agent/tf-vrouter-agent,contrail-status/tf-status...) — Docker Hub APIhub.docker.com/v2/repositories/opensdn/, truy vấn trực tiếp 03/09/2026. - Tag mới nhất của các image kiểm tra (
tf-vrouter-agent,contrail-tools,tf-tools,contrail-status,tf-status) đều dừng ở2025-06-05; toàn bộ 161 tag củatf-vrouter-agentkhông có tagmaster-latest— Docker Hub APIhub.docker.com/v2/repositories/opensdn/<image>/tags, truy vấn trực tiếp 03/09/2026. - Danh sách repo tổ chức
opensdn-io(xác nhận tồn tạitf-devstack,tf-dev-env,tf-ansible-deployer,tf-dev-test) — GitHub APIapi.github.com/orgs/opensdn-io/repos, truy vấn trực tiếp 03/09/2026. - Ba loại node Controller (Config/Control/Analytics), hạ tầng Cassandra/Zookeeper/RabbitMQ — Contrail Architecture Part 2.
- Kiến trúc Agent/Forwarding Plane — Bài 2 series này.
- Package
contrail-tools, lệnhcontrail-status— đã dẫn nguồn ở Bài 1, Nguồn tham khảo.
Tiếp theo: Bài 4 — Cấu trúc forwarder sâu: VRF, flow table, MPLS/VXLAN table + CLI introspect (chạy trên cluster bạn tự dựng theo Mục 6 bài này).