Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Docker Networking #4 – Macvlan cho dân DevOps/NetDevOps: “Container như một máy thật trên LAN”

    Docker Networking #4 – Macvlan cho dân DevOps/NetDevOps: “Container như một máy thật trên LAN”

    Anh em từng đau đầu vì NAT/port-mapping khi cần container xuất hiện như một host thật trong VLAN doanh nghiệp? Macvlan là “vũ khí” đúng bài: mỗi container nhận MAC riêngIP LAN thật, nhìn từ switch/router thì nó như một thiết bị vật lý độc lập.
    Macvlan là gì (và khác gì bridge/host/overlay)?
    • Macvlan gắn cho container một địa chỉ MAC riêngIP từ subnet vật lý. Không NAT, không port-mapping.
    • Từ LAN, container được thấy như một host khác cắm vào cùng switch/port với máy chủ Docker.
    • Khác bridge: bridge dùng NAT để ra ngoài; macvlan thì trực tiếp trên underlay.
    • Khác host mode: host dùng chung stack của máy chủ; macvlan tách biệt như máy riêng.
    • Khác overlay: overlay dùng VXLAN trải L2/L3 nhiều host; macvlan bám trực tiếp vào L2 cục bộ.

    Khi nào nên dùng macvlan?
    • Cần container có địa chỉ IP “thật” để tích hợp với hệ thống hiện hữu: DHCP/DNS/AD, giám sát (SNMP/NetFlow), legacy ACL, hoặc các ứng dụng không chấp nhận NAT.
    • Muốn bypass port-mapping và tránh xung đột cổng giữa nhiều container.
    • Lab/PoC cần tính hiện thực cao (container = node thật trên LAN).

    Lưu ý quan trọng (đọc kỹ trước khi triển khai)
    1. Host ↔ Container cùng host mặc định không nói chuyện qua macvlan (hạn chế lịch sử của macvlan). Cách khắc phục:
      • Tạo sub-interface macvlan trên host cùng parent để host có thể giao tiếp (xem phần cấu hình).
      • Hoặc cân nhắc ipvlan (L2/L3) nếu phù hợp.
    2. Port-security trên switch: một cổng uplink giờ sẽ thấy nhiều MAC (host + containers). Cần nới max-mac, tắt sticky, hoặc gắn trunk VLAN riêng.
    3. DHCP & ARP: nếu dùng DHCP, đảm bảo scope đủ và cho phép nhiều lease trên cùng port. ARP flood có thể tăng; giám sát phù hợp.
    4. Firewall/segmentation: container nằm thẳng trên LAN → không còn lớp NAT iptables của Docker che chắn. Hãy áp dụng ACL, micro-segmentation (VLAN/SGT/ISE), hoặc firewall North-South/East-West.
    5. Địa chỉ & Gateway: container dùng gateway của subnet vật lý (giống host).
    6. VLAN tagging: có thể gắn vào VLAN cụ thể bằng -o parent=ens160.<vlan_id> như ens160.100.

    Cấu hình nhanh (chuẩn, đã sửa cú pháp)
    Lưu ý: trong tài liệu gốc có nhầm --subnet=192.168.10.10/24. Đúng phải là 192.168.10.0/24.

    1) Tạo mạng macvlan
    # Nếu dùng VLAN 100 thì parent là ens160.100 (đã cấu hình 802.1Q trên host) docker network create -d macvlan \ --subnet=192.168.10.0/24 \ --gateway=192.168.10.1 \ -o parent=ens160 \ my_custom_macvlan
    (Tuỳ chọn) Giới hạn dải IP cấp cho container
    docker network create -d macvlan \ --subnet=192.168.10.0/24 \ --gateway=192.168.10.1 \ --ip-range=192.168.10.64/26 \ -o parent=ens160 \ macvlan_pool
    2) Chạy container với IP tĩnh trong LAN
    docker run -d --name web1 \ --network my_custom_macvlan \ --ip 192.168.10.50 \ nginx:stable
    3) Cho phép host nói chuyện với container (khắc phục hạn chế #1)
    # Tạo sub-interface macvlan trên host (mode bridge) sudo ip link add macvlan0 link ens160 type macvlan mode bridge sudo ip addr add 192.168.10.200/24 dev macvlan0 sudo ip link set macvlan0 up # Kiểm tra từ host ping -c 3 192.168.10.50
    Nếu dùng VLAN: thay ens160 bằng ens160.100.
    Route default vẫn đi qua NIC chính; macvlan0 chỉ dùng để reach các container trong cùng subnet.

    4) Kiểm tra & quan sát
    docker network inspect my_custom_macvlan arp -an | grep 192.168.10.50 ip neigh show dev macvlan0
    Best practices triển khai thực chiến
    • Tách VLAN riêng cho containers: giảm rủi ro bảo mật, dễ đặt policy.
    • Giới hạn IP-range cho Docker IPAM để tránh đụng IP tĩnh trên LAN.
    • Giám sát: bật NetFlow/sFlow trên switch, syslog/IDS để thấy lưu lượng containers.
    • Tài liệu hoá: sơ đồ L2/L3, gateway, dải IP, DHCP reservations (nếu cần).
    • Cân nhắc ipvlan khi switch không thích nhiều MAC (giảm áp lực CAM).
    • K8s: với Kubernetes, tham khảo macvlan CNI (hoặc Multus) để gán interface phụ có IP “thật” cho Pod.

    Ưu/nhược điểm tóm tắt nhanh
    • Ưu: IP thật, không NAT; tích hợp mượt với hạ tầng hiện có; performance tốt; cấu hình đơn giản.
    • Nhược: host↔container mặc định không giao tiếp; yêu cầu switch chấp nhận nhiều MAC; rủi ro bảo mật nếu không segment-hóa.

    Kết nối chuỗi bài


    Bài này nằm trong series Docker Networking (bridge → host → overlay → macvlan). Ở bài sau, mình sẽ đối chiếu macvlan vs ipvlan (L2/L3), chọn kịch bản tối ưu theo constraint L2, port-security, và nhu cầu micro-segmentation.

    Nếu anh em đang vận hành hạ tầng on-prem hoặc hybrid, macvlan là mảnh ghép “gọn” để container hoà nhập hoàn toàn vào LAN/DMZ. Dùng cẩn thận – nhưng đúng chỗ – sẽ tiết kiệm rất nhiều thời gian so với NAT/port-mapping truyền thống.
    Attached Files
    Đặng Quang Minh, CCIE#11897 (Enterprise Infrastructure, Wireless, Automation, AI), CCSI#31417

    Email : dangquangminh@vnpro.org
    https://www.facebook.com/groups/vietprofessional/
Working...
X