Tweet
Underlays
Underlays Network Drivers hiển thị giao host interfaces (i.e., cổng mạng vật lý như eth0) trực tiếp đến các container hoặc VM chạy trên máy chủ. Hai trình điều khiển drivers như MACvlan (Media Access Control Virtual Local Area Network) và giao thức IPvlan (Internet protocol vlan), cách hoạt động và hành vi của trình điều khiển MACvlan và IPvlan rất quen thuộc với các kỹ sư mạng. Cả hai trình điều khiển mạng về mặt khái niệm đơn giản hơn mô hình mạng brigde, loại bỏ nhu cầu port-mapping và hiệu quả hơn. Hơn nữa, IPvlan có chế độ L3 thích hợp sử dụng cho nhiều mô hình mạng khác nhau. Do các hạn chế - hoặc thiếu khả năng - trong hầu hết các đám mây công cộng, nên Underlays network đặc biệt hữu ích khi bạn có khối lượng công việc tại chỗ, mối quan tâm về bảo mật, ưu tiên giao thông hoặc tuân thủ, khiến chúng trở nên lý tưởng cho việc sử dụng Brownfield. Thay vì cần một cầu nối cho mỗi Vlan, Underlays network cho phép sử dụng một Vlan cho mỗi giao diện con.
MACvlan
MACvlan cho phép tạo ra nhiều giao diện mạng ảo phía sau giao diện vật lý đơn của máy chủ. Mỗi giao diện ảo có các địa chỉ MAC và IP duy nhất được gán, với một hạn chế: các địa chỉ IP cần phải nằm trong cùng một miền quảng bá với giao diện vật lý. Trong khi nhiều kỹ sư mạng có thể quen thuộc hơn với thuật ngữ subinterface (không bị nhầm lẫn với Secondary interface), cách nói được sử dụng để mô tả MACvlan virtual interfaces thường là interfacfe trên hoặc dưới. Mạng MACvlan là một cách để loại bỏ sự cần thiết của cầu Linux, NAT và Port-mapping, cho phép bạn kết nối trực tiếp với giao diện vật lý.
MACvlan sử dụng một địa chỉ MAC duy nhất cho mỗi bộ chứa và điều này có thể gây ra sự cố với các bộ chuyển mạch mạng có chính sách bảo mật để ngăn chặn giả mạo MAC (vd: Port-security,..), bằng cách chỉ cho phép một địa chỉ MAC trên mỗi giao diện chuyển đổi vật lý.
Container traffic được lọc để có thể nói chuyện với Uderlying host, cách ly hoàn toàn máy chủ khỏi các container mà nó chạy. Các host không thể đạt được các container, các container được cô lập hoàn toàn so với host. Điều này hữu ích cho các nhà cung cấp dịch vụ hoặc sử dụng cho các kịch bản nhiều người thuê và có sự cô lập hơn so với mô hình brigde.
Chế độ Promiscous là cần thiết cho MACvlan; MACvlan có 4 chế độ hoạt động, chỉ có chế độ brigde được hỗ trợ trong Docker 1.12. Chế độ brigde MACvlan và chế độ L2 IPvlan về chức năng hoạt động thì tương đương. Cả hai chế độ cho phép phát sóng đơn hướng và phát đa hướng lưu lượng truy cập. Các giao thức lớp Underlays này được thiết kế với các trường hợp sử dụng tại chỗ. Số dặm đám mây công khai của bạn sẽ thay đổi vì hầu hết không hỗ trợ chế độ Promoscous trên các VM interface của họ.
IPvlan
IPvlan tương tự như MACvlan ở chỗ nó tạo ra các giao diện mạng ảo mới và gán cho mỗi địa chỉ IP duy nhất. Sự khác biệt là cùng một địa chỉ MAC được sử dụng cho tất cả các nhóm và vùng chứa trên 1 host và cùng địa chỉ MAC của physical interface. Sự cần thiết của hành vi này là vì chủ yếu được thúc đẩy bởi trong thực tế chúng ta sẽ thường sử dụng Port-Security với maximum mac-address sẽ là 1 nên chỉ cho phép duy nhất 1 địa chỉ MAC cho 1 công thôi, và các cổng không được sử dụng sẽ được chuyển sang vlan khác với native vlan và sẽ được shutdown đi để tránh các trường hợp ảnh hưởng đến vấn đề Security cho Layer 2 trong mô hình OSI.
Chạy tốt nhất trên nhân 4.2 hoặc mới hơn, IPvlan có thể hoạt động ở chế độ L2 hoặc L3. Giống như MACvlan, chế độ IPvlan L2 yêu cầu các địa chỉ IP được gán cho giao diện con phải nằm trong cùng mạng con với giao diện vật lý. Tuy nhiên, chế độ IPvlan L3 yêu cầu các mạng container và địa chỉ IP phải ở trên một mạng con khác với giao diện vật lý gốc.
Cấu hình 802.1q (thường gọi là dot1q) trên máy chủ Linux, khi được tạo bằng liên kết ip là phù hợp, vì vậy hầu hết các nhà khai thác sử dụng tập lệnh khởi động mạng để duy trì cấu hình. Với các công cụ chứa chạy trình điều khiển lớp lót và hiển thị API cho cấu hình Vlan lập trình, việc tự động hóa sẽ được cải thiện. Ví dụ, khi các Vlan mới được tạo trên đỉnh của công tắc rack, các Vlan này có thể được đẩy vào máy chủ Linux thông qua API công cụ chứa được hiển thị.
MACvlan và IPvlan
Khi chọn giữa hai loại Underlays này, hãy xem xét liệu bạn có cần mạng để có thể xem địa chỉ MAC của vùng chứa riêng lẻ hay không. Đối với giao thức phân giải địa chỉ (ARP) và broadcast traffic, các chế độ L2 của cả hai trình điều khiển lớp dưới hoạt động như một máy chủ được kết nối với một bộ chuyển mạch, bằng cách Flooding và Learning bằng cách sử dụng các gói 802.1D. trong chế độ IPvlan L3, tuy nhiên, ngăn xếp mạng được xử lý trong vùng chứa. Không cho phép lưu lượng phát đa hướng hoặc phát sóng. Theo nghĩa này, chế độ L3 của IPvlan hoạt động như bạn mong đợi một bộ định tuyến L3 hoạt động.
Lưu ý rằng các thiết bị định tuyến ở lớp Layer 3 (OSI model) phải hỗ trợ feature IPvlan. Quảng cáo mạng và phân phối lại vào mạng vẫn cần phải được thực hiện. Hiện nay, Docker đang thử nghiệm với Border Gateway Protocol (BGP). Trong khi các tuyến tĩnh có thể được tạo trên đỉnh của rack switch, các dự án như goBGP đã mọc lên như một hệ sinh thái container thân thiện để cung cấp chức năng route exchange và neighbor peering.
Mặc dù nhiều chế độ kết nối mạng được hỗ trợ trên một máy chủ nhất định, MACvlan và IPvlan có thể được sử dụng đồng thời trên cùng một giao diện vật lý. Nói tóm lại, nếu bạn sử dụng để chạy các thân cây xuống máy chủ, chế độ L2 là dành cho bạn. nếu quy mô là mối quan tâm chính, L3 có tiềm năng cho quy mô lớn.
Mô hình Container Network
Libnetwork là triển khai chính của đặc tả CNM. Libnetwork cung cấp giao diện giữa trình nền Docker và trình điều khiển mạng. Bộ điều khiển mạng chịu trách nhiệm ghép trình điều khiển với mạng. Mỗi trình điều khiển chịu trách nhiệm quản lý mạng mà nó sở hữu, bao gồm các dịch vụ được cung cấp cho mạng đó như IPAM. Với một trình điều khiển trên mỗi mạng, nhiều trình điều khiển có thể được sử dụng đồng thời với các container được kết nối với nhiều mạng. Trình điều khiển được định nghĩa là bản địa (tích hợp vào libnetwork hoặc Docker được hỗ trợ) hoặc từ xa (bên thứ ba bổ sung). Các trình điều khiển gốc là None, Brigde, Overlay và MACvlan. Trình điều khiển từ xa có thể mang lại bất kỳ số lượng khả năng. Trình điều khiển cũng được định nghĩa là có phạm vi cục bộ (máy chủ đơn) hoặc phạm vi toàn cầu (đa máy chủ).
Hình 2: Các container được kết nối thông qua một loạt các điểm cuối mạng.
Một tập hợp cấu trúc CNM linh hoạt cuối cùng là các tùy chọn và nhãn (cặp siêu dữ liệu khóa-giá trị). CNM hỗ trợ khái niệm nhãn do người dùng xác định (được xác định bằng cách sử dụng cờ của Waplabel), được chuyển dưới dạng siêu dữ liệu giữa libnetwork và trình điều khiển. Nhãn mạnh ở chỗ thời gian chạy có thể thông báo cho hành vi của trình điều khiển.
Container Network Interface
CNI được tạo ra như một đặc điểm kỹ thuật tối thiểu, được xây dựng cùng với một số kỹ sư của nhà cung cấp mạng để trở thành một hợp đồng đơn giản giữa thời gian chạy container và các plugin mạng. Một lược đồ JSON xác định đầu vào và đầu ra dự kiến từ các plugin mạng CNI.
CNI Flow
Về thời gian chạy Container trước tiên cần phân bổ một không gian tên mạng cho bộ chứa và gán cho nó một ID bộ chứa, sau đó chuyển một số tham số (cấu hình CNI) cho trình điều khiển mạng. Trình điều khiển mạng sau đó gắn container vào mạng và báo cáo địa chỉ IP được gán trở lại thời gian chạy của container thông qua JSON (JavaScript Object Notation).
Mesos là dự án mới nhất để thêm hỗ trợ CNI và đang triển khai Cloud Foundry. Trạng thái hiện tại của mạng Mesos sử dụng mạng máy chủ, trong đó container chia sẻ cùng địa chỉ IP với máy chủ. Mesos đang tìm cách cung cấp cho mỗi container một không gian tên mạng riêng và do đó, địa chỉ IP của chính nó. Dự án đang chuyển sang mô hình container lP-per, và làm như vậy, tìm cách dân chủ hóa mạng để các nhà khai thác có quyền tự do lựa chọn kiểu mạng phù hợp nhất với mục đích của họ.
Link phần 3: https://www.forum.vnpro.org/forum/c%...ph%E1%BA%A7n-3
Underlays Network Drivers hiển thị giao host interfaces (i.e., cổng mạng vật lý như eth0) trực tiếp đến các container hoặc VM chạy trên máy chủ. Hai trình điều khiển drivers như MACvlan (Media Access Control Virtual Local Area Network) và giao thức IPvlan (Internet protocol vlan), cách hoạt động và hành vi của trình điều khiển MACvlan và IPvlan rất quen thuộc với các kỹ sư mạng. Cả hai trình điều khiển mạng về mặt khái niệm đơn giản hơn mô hình mạng brigde, loại bỏ nhu cầu port-mapping và hiệu quả hơn. Hơn nữa, IPvlan có chế độ L3 thích hợp sử dụng cho nhiều mô hình mạng khác nhau. Do các hạn chế - hoặc thiếu khả năng - trong hầu hết các đám mây công cộng, nên Underlays network đặc biệt hữu ích khi bạn có khối lượng công việc tại chỗ, mối quan tâm về bảo mật, ưu tiên giao thông hoặc tuân thủ, khiến chúng trở nên lý tưởng cho việc sử dụng Brownfield. Thay vì cần một cầu nối cho mỗi Vlan, Underlays network cho phép sử dụng một Vlan cho mỗi giao diện con.
MACvlan
MACvlan cho phép tạo ra nhiều giao diện mạng ảo phía sau giao diện vật lý đơn của máy chủ. Mỗi giao diện ảo có các địa chỉ MAC và IP duy nhất được gán, với một hạn chế: các địa chỉ IP cần phải nằm trong cùng một miền quảng bá với giao diện vật lý. Trong khi nhiều kỹ sư mạng có thể quen thuộc hơn với thuật ngữ subinterface (không bị nhầm lẫn với Secondary interface), cách nói được sử dụng để mô tả MACvlan virtual interfaces thường là interfacfe trên hoặc dưới. Mạng MACvlan là một cách để loại bỏ sự cần thiết của cầu Linux, NAT và Port-mapping, cho phép bạn kết nối trực tiếp với giao diện vật lý.
MACvlan sử dụng một địa chỉ MAC duy nhất cho mỗi bộ chứa và điều này có thể gây ra sự cố với các bộ chuyển mạch mạng có chính sách bảo mật để ngăn chặn giả mạo MAC (vd: Port-security,..), bằng cách chỉ cho phép một địa chỉ MAC trên mỗi giao diện chuyển đổi vật lý.
Container traffic được lọc để có thể nói chuyện với Uderlying host, cách ly hoàn toàn máy chủ khỏi các container mà nó chạy. Các host không thể đạt được các container, các container được cô lập hoàn toàn so với host. Điều này hữu ích cho các nhà cung cấp dịch vụ hoặc sử dụng cho các kịch bản nhiều người thuê và có sự cô lập hơn so với mô hình brigde.
Chế độ Promiscous là cần thiết cho MACvlan; MACvlan có 4 chế độ hoạt động, chỉ có chế độ brigde được hỗ trợ trong Docker 1.12. Chế độ brigde MACvlan và chế độ L2 IPvlan về chức năng hoạt động thì tương đương. Cả hai chế độ cho phép phát sóng đơn hướng và phát đa hướng lưu lượng truy cập. Các giao thức lớp Underlays này được thiết kế với các trường hợp sử dụng tại chỗ. Số dặm đám mây công khai của bạn sẽ thay đổi vì hầu hết không hỗ trợ chế độ Promoscous trên các VM interface của họ.
IPvlan
IPvlan tương tự như MACvlan ở chỗ nó tạo ra các giao diện mạng ảo mới và gán cho mỗi địa chỉ IP duy nhất. Sự khác biệt là cùng một địa chỉ MAC được sử dụng cho tất cả các nhóm và vùng chứa trên 1 host và cùng địa chỉ MAC của physical interface. Sự cần thiết của hành vi này là vì chủ yếu được thúc đẩy bởi trong thực tế chúng ta sẽ thường sử dụng Port-Security với maximum mac-address sẽ là 1 nên chỉ cho phép duy nhất 1 địa chỉ MAC cho 1 công thôi, và các cổng không được sử dụng sẽ được chuyển sang vlan khác với native vlan và sẽ được shutdown đi để tránh các trường hợp ảnh hưởng đến vấn đề Security cho Layer 2 trong mô hình OSI.
Chạy tốt nhất trên nhân 4.2 hoặc mới hơn, IPvlan có thể hoạt động ở chế độ L2 hoặc L3. Giống như MACvlan, chế độ IPvlan L2 yêu cầu các địa chỉ IP được gán cho giao diện con phải nằm trong cùng mạng con với giao diện vật lý. Tuy nhiên, chế độ IPvlan L3 yêu cầu các mạng container và địa chỉ IP phải ở trên một mạng con khác với giao diện vật lý gốc.
Cấu hình 802.1q (thường gọi là dot1q) trên máy chủ Linux, khi được tạo bằng liên kết ip là phù hợp, vì vậy hầu hết các nhà khai thác sử dụng tập lệnh khởi động mạng để duy trì cấu hình. Với các công cụ chứa chạy trình điều khiển lớp lót và hiển thị API cho cấu hình Vlan lập trình, việc tự động hóa sẽ được cải thiện. Ví dụ, khi các Vlan mới được tạo trên đỉnh của công tắc rack, các Vlan này có thể được đẩy vào máy chủ Linux thông qua API công cụ chứa được hiển thị.
MACvlan và IPvlan
Khi chọn giữa hai loại Underlays này, hãy xem xét liệu bạn có cần mạng để có thể xem địa chỉ MAC của vùng chứa riêng lẻ hay không. Đối với giao thức phân giải địa chỉ (ARP) và broadcast traffic, các chế độ L2 của cả hai trình điều khiển lớp dưới hoạt động như một máy chủ được kết nối với một bộ chuyển mạch, bằng cách Flooding và Learning bằng cách sử dụng các gói 802.1D. trong chế độ IPvlan L3, tuy nhiên, ngăn xếp mạng được xử lý trong vùng chứa. Không cho phép lưu lượng phát đa hướng hoặc phát sóng. Theo nghĩa này, chế độ L3 của IPvlan hoạt động như bạn mong đợi một bộ định tuyến L3 hoạt động.
Lưu ý rằng các thiết bị định tuyến ở lớp Layer 3 (OSI model) phải hỗ trợ feature IPvlan. Quảng cáo mạng và phân phối lại vào mạng vẫn cần phải được thực hiện. Hiện nay, Docker đang thử nghiệm với Border Gateway Protocol (BGP). Trong khi các tuyến tĩnh có thể được tạo trên đỉnh của rack switch, các dự án như goBGP đã mọc lên như một hệ sinh thái container thân thiện để cung cấp chức năng route exchange và neighbor peering.
Mặc dù nhiều chế độ kết nối mạng được hỗ trợ trên một máy chủ nhất định, MACvlan và IPvlan có thể được sử dụng đồng thời trên cùng một giao diện vật lý. Nói tóm lại, nếu bạn sử dụng để chạy các thân cây xuống máy chủ, chế độ L2 là dành cho bạn. nếu quy mô là mối quan tâm chính, L3 có tiềm năng cho quy mô lớn.
Mô hình Container Network
Libnetwork là triển khai chính của đặc tả CNM. Libnetwork cung cấp giao diện giữa trình nền Docker và trình điều khiển mạng. Bộ điều khiển mạng chịu trách nhiệm ghép trình điều khiển với mạng. Mỗi trình điều khiển chịu trách nhiệm quản lý mạng mà nó sở hữu, bao gồm các dịch vụ được cung cấp cho mạng đó như IPAM. Với một trình điều khiển trên mỗi mạng, nhiều trình điều khiển có thể được sử dụng đồng thời với các container được kết nối với nhiều mạng. Trình điều khiển được định nghĩa là bản địa (tích hợp vào libnetwork hoặc Docker được hỗ trợ) hoặc từ xa (bên thứ ba bổ sung). Các trình điều khiển gốc là None, Brigde, Overlay và MACvlan. Trình điều khiển từ xa có thể mang lại bất kỳ số lượng khả năng. Trình điều khiển cũng được định nghĩa là có phạm vi cục bộ (máy chủ đơn) hoặc phạm vi toàn cầu (đa máy chủ).
Hình 1: Libnetwork cung cấp giao diện giữa trình nền Docker và trình điều khiển mạng.
Hình 2: Các container được kết nối thông qua một loạt các điểm cuối mạng.
- Network Sandbox: Về cơ bản là ngăn xếp mạng trong một container, nó là một môi trường biệt lập để chứa cấu hình mạng Container.
- Endpoint: Giao diện mạng thường đi theo cặp. Một đầu của cặp nằm trong network sandbox, còn đầu kia nằm trong một mạng được chỉ định. Điểm cuối tham gia chính xác một và nhiều điểm cuối có thể tồn tại trong một network sandbox.
- Network: Bao gồm 1 nhóm Endpoint có thể nhận dạng duy nhất có khả năng giao tiếp với nhau.
Một tập hợp cấu trúc CNM linh hoạt cuối cùng là các tùy chọn và nhãn (cặp siêu dữ liệu khóa-giá trị). CNM hỗ trợ khái niệm nhãn do người dùng xác định (được xác định bằng cách sử dụng cờ của Waplabel), được chuyển dưới dạng siêu dữ liệu giữa libnetwork và trình điều khiển. Nhãn mạnh ở chỗ thời gian chạy có thể thông báo cho hành vi của trình điều khiển.
Container Network Interface
CNI được tạo ra như một đặc điểm kỹ thuật tối thiểu, được xây dựng cùng với một số kỹ sư của nhà cung cấp mạng để trở thành một hợp đồng đơn giản giữa thời gian chạy container và các plugin mạng. Một lược đồ JSON xác định đầu vào và đầu ra dự kiến từ các plugin mạng CNI.
Hình 3: CNI là một đặc điểm kỹ thuật tối thiểu để thêm và xóa các thùng chứa vào mạng.
Nhiều plugin có thể được chạy cùng một lúc với các mạng liên kết được điều khiển bởi các plugin khác nhau. Mạng được mô tả trong các tệp cấu hình, ở định dạng JSON và được khởi tạo dưới dạng không gian tên mới khi các plugin CNI được gọi. Các plugin CNl hỗ trợ hai lệnh để thêm và xóa giao diện mạng container đến và khỏi mạng. Add được gọi bởi bộ thực thi container khi nó tạo một container. Delete được gọi bởi bộ thực thi container khi nó phá vỡ một thể hiện của container.CNI Flow
Về thời gian chạy Container trước tiên cần phân bổ một không gian tên mạng cho bộ chứa và gán cho nó một ID bộ chứa, sau đó chuyển một số tham số (cấu hình CNI) cho trình điều khiển mạng. Trình điều khiển mạng sau đó gắn container vào mạng và báo cáo địa chỉ IP được gán trở lại thời gian chạy của container thông qua JSON (JavaScript Object Notation).
Mesos là dự án mới nhất để thêm hỗ trợ CNI và đang triển khai Cloud Foundry. Trạng thái hiện tại của mạng Mesos sử dụng mạng máy chủ, trong đó container chia sẻ cùng địa chỉ IP với máy chủ. Mesos đang tìm cách cung cấp cho mỗi container một không gian tên mạng riêng và do đó, địa chỉ IP của chính nó. Dự án đang chuyển sang mô hình container lP-per, và làm như vậy, tìm cách dân chủ hóa mạng để các nhà khai thác có quyền tự do lựa chọn kiểu mạng phù hợp nhất với mục đích của họ.
Link phần 3: https://www.forum.vnpro.org/forum/c%...ph%E1%BA%A7n-3
Tín Phan