Tweet
Hiện nay, các CNI xử lý các mối quan tâm với lPAM, L2 và L3 và trông đợi vào container runtime để xử lý port-mapping (L4). Từ góc nhìn của Mesos, cách tiếp cận tối giản này đi kèm với một vài cảnh báo, một trong số đó là đặc tả CNI không chỉ định bất kỳ quy tắc ánh xạ port port nào được sử dụng cho một container; khả năng này có thể được xử lý bởi container runtime. Một cảnh báo thứ hai là trong khi các nhà khai thác nên được phép thay đổi cấu hình CNI, thì hành vi vận hành container khi cấu hình CNI được sửa đổi không được tính đến một cách cụ thể. Mesos đang giải quyết sự mơ hồ này bằng cách đảm bảo rằng, khi khởi động lại tác nhân CNI, họ sẽ kiểm tra cấu hình CNI khi nó được liên kết với phiên bản cụ thể của các container.
CNM và CNI
Trong nhiều khía cạnh, hai thông số kỹ thuật container networking này thực hiện chủ hóa việc lựa chọn loại mạng container nào có thể được sử dụng, trong đó cả hai đều là mô hình dựa trên driver mạng hoặc dựa trên plugin, để tạo và quản lý ngăn xếp mạng cho container. Mỗi cái cho phép nhiều driver mạng hoạt động và được sử dụng đồng thời, trong đó mỗi trình điều khiển cung cấp một ánh xạ mạng một đến một cho trình điều khiển mạng Network đó. Cả hai mô hình cho phép các container tham gia một hoặc nhiều mạng. Và mỗi cái cho phép bộ thực thi container khởi chạy mạng trong không gian tên riêng của nó, tách biệt logic ứng dụng / nghiệp vụ của việc kết nối container với network driver.
Cách tiếp cận trình điều khiển mô-đun này có thể tạo nên sự hấp dẫn hơn cho các nhà khai thác mạng so với các nhà phát triển ứng dụng, trong đó các nhà khai thác có khả năng linh hoạt để chọn một hoặc nhiều trình điều khiển đáp ứng nhu cầu cụ thể của họ và phù hợp với phương thức hoạt động hiện có của họ. Các nhà khai thác chịu trách nhiệm đảm bảo các thỏa thuận cấp dịch vụ (SLA) được đáp ứng và các chính sách bảo mật được thi hành.
Cả hai mô hình đều cung cấp các điểm mở rộng riêng biệt, còn gọi là giao diện plugin, cho driver mạng - để tạo, định cấu hình và kết nối mạng - và [PAM - để định cấu hình, khám phá và quản lý địa chỉ IP. Một điểm mở rộng cho mỗi chức năng khuyến khích khả năng kết hợp.
CNM không cung cấp cho trình điều khiển mạng quyền truy cập vào không gian tên mạng container Container. Lợi ích ở đây là libnetwork hoạt động như một nhà môi giới để giải quyết xung đột. Một ví dụ mâu thuẫn khi hai trình điều khiển mạng độc lập cung cấp cùng một Static Route, sử dụng cùng một Route Prefix, nhưng trỏ đến các địa chỉ IP next-hop khác nhau. CNI không cung cấp driver mạng để truy cập vào namespace container. CNI đang xem xét làm thế nào để nó có thể phân xử approach trong các kịch bản khác lại cần giải quyết xung đột như vậy trong tương lai.
CNI hỗ trợ tích hợp với IPAM của bên thứ ba và có thể được sử dụng với bất kỳ thời gian chạy container nào. CNM được thiết kế để chỉ hỗ trợ công cụ thời gian chạy Docker. Với cách tiếp cận đơn giản của CNl, nó đã được lập luận rằng nó có thể dễ dàng tạo ra một plugin CNI hơn một plugin CNM.
Những mô hình này thúc đẩy tính mô đun, khả năng kết hợp và lựa chọn bằng cách thúc đẩy một hệ sinh thái đổi mới của các nhà cung cấp bên thứ ba, những người cung cấp khả năng kết nối mạng tiên tiến. Việc phối hợp phân đoạn mạng có thể trở thành các lệnh gọi API đơn giản để đính kèm, tách và trao đổi mạng. Các Interface Container có thể thuộc về nhiều mạng và mỗi container có thể xuất bản các dịch vụ khác nhau trong các mạng khác nhau. Ý tưởng về các cấu trúc mạng khác nhau như các công dân hạng nhất được phản ánh trong khả năng tách dịch vụ mạng khỏi một container cũ và gắn nó vào một container mới.
Container Networking in OpenStack
Ban đầu tập trung vào tự động hóa cơ sở hạ tầng cho các máy ảo, OpenStack đã tập trung vào các nhu cầu của container. Kuryr và Magnum không phải là dự án liên quan đến container duy nhất của họ, nhưng chắc chắn đây chính là hai dự án liên quan đến mạng container.
Kuryr
Kuryr là một mạng container của dự án, hiện đang hoạt động như một remote driver cho libnetwork để cung cấp mạng cho Docker bằng cách sử dụng Neutron làm công cụ Backend Network. Hỗ trợ cho CNM đã được chuyển giao và lộ trình cho dự án này bao gồm hỗ trợ cho CNI.
Magnum
Magnum, một dự án cung cấp Container dưới dạng Dịch vụ (Container as a Service - CaaS) và tận dụng Nhiệt để khởi tạo các cụm chạy các công cụ điều phối container khác, hiện đang sử dụng các tùy chọn kết nối mạng không phải neutron cho các container.
Công việc đang được tiến hành để tích hợp Kuryr và Magnum. Quan niệm rằng các container có thể lồng ghép hay chạy đệ quy với các container khác để tạo ra một số thách thức cho các nhóm dự án cần phải vượt qua.
Networking with Intention
Mạng dựa trên ý định xác định nhu cầu của hành vi mạng và mạng trong các thuật ngữ bất khả tri về cơ sở hạ tầng bằng cách sử dụng chính sách. Với mật độ giao diện mạng tăng lên, khối lượng địa chỉ IP và độ phức tạp của giao tiếp giữa các container chạy các microservices phụ thuộc lẫn nhau, mạng sẽ được hưởng lợi từ các mô hình đã được xác định và tận dụng trong các hệ thống khác. Các thuộc tính của mạng dựa trên ý định rút ra từ những thành công của các khái niệm đã được thiết lập, đề cập đến chúng bằng các thuật ngữ bất biến, di động, có thể ghép lại, có thể mở rộng.
Ví dụ bất biến tương tự như khái niệm tiềm năng idem trong các hệ thống quản lý cấu hình. Mạng dựa trên ý định gọi điều này là bất biến, có nghĩa là ý định đó không thay đổi do chính sách ý định được áp dụng nhiều lần hoặc bằng cách sử dụng các thiết bị của nhà cung cấp khác nhau.
Một mục đích khác khái niệm dựa trên nền tảng là tính di động, một khái niệm được đặc trưng là môi trường hỗ trợ chính sách với thiết bị hoặc chính sách của nhà cung cấp không đồng nhất, tránh mọi ràng buộc cụ thể của nhà cung cấp. Mạng dựa trên ý định có thể kết hợp khi chính sách có thể đồng thời tận dụng các dịch vụ mạng khác nhau được cung cấp bởi các nhà cung cấp khác nhau về thiết bị hoặc giải pháp.
Chất lượng mạng có thể mở rộng dựa trên ý định là tự giải thích. nó cho phép mỗi nút hoặc máy chủ đưa ra quyết định kết nối mạng theo kiểu phân tán, với mỗi nút nhận thức được chính sách dựa trên ý định. Chúng tôi đã thấy được sức mạnh của các công trình, như nhãn, thẻ và chính sách, cải thiện đáng kể khả năng của các công nghệ mạng container.
Summary
Chúng tôi đã thảo luận về một số cân nhắc trước khi chọn loại mạng nào sẽ được sử dụng trong môi trường của bạn - rất có thể, bạn sẽ sử dụng kết hợp. Hiệu suất chắc chắn là một trong những cân nhắc đó và sẽ là chủ đề của nghiên cứu tiếp theo. Bên ngoài các loại kết nối và dịch vụ mạng khác nhau, một điều cần cân nhắc không được nhấn mạnh là hiểu mức độ bạn cần tích hợp với các hệ thống đương nhiệm trong môi trường của bạn. Ví dụ: trong trường hợp khối lượng công việc tại chỗ, bạn sẽ có một giải pháp IPAM hiện có. IPAM được cung cấp bởi hầu hết các nhà cung cấp driver mạng container, nhưng chỉ một số có tích hợp với nhà cung cấp PAM hàng đầu, như Cisco, lnfoblox, SolarWinds, v.v.
Khi các nhà cung cấp và dự án tiếp tục phát triển, bối cảnh mạng tiếp tục thay đổi. Một số dịch vụ đã được hợp nhất hoặc kết hợp, chẳng hạn như mua lại DockPlane của SocketPlane và chuyển đổi Flannel sang lgera - một công ty khởi nghiệp mới đã hình thành xung quanh Canal. Canal là một portmanteau của Calico và Flannel và là sự kết hợp của hai dự án đó. CoreOS sẽ cung cấp hỗ trợ liên tục cho Flannel như một dự án riêng lẻ và sẽ tích hợp Canal với Tectonic, giải pháp doanh nghiệp của họ cho Kubernetes. Những thay đổi khác đến trong các hình thức phát hành dự án mới. Docker 1.12 Phát hành các tính năng mạng, bao gồm cả Underlays và hỗ trợ cân bằng tải (Load-balancing), là một bước tiến không nhỏ đối với dự án.
Mặc dù có một số lượng lớn công nghệ mạng container và các cách tiếp cận riêng biệt, nhưng chúng tôi may mắn vì phần lớn hệ sinh thái container dường như đã hội tụ và xây dựng hỗ trợ xung quanh chỉ hai mô hình mạng. Ít nhất là cho đến nay, các nhà phát triển muốn loại bỏ việc cung cấp mạng thủ công trong môi trường container và cấm những ai có quan niệm sai lầm về sự không an toàn trong hệ thống mạng của họ, các kỹ sư mạng đã sẵn sàng để đối phó với các tình huống như vậy.
Giống như các tài nguyên khác, một bước trung gian để cung cấp tự động là cung cấp pre-provisioning, có nghĩa là các kỹ sư mạng sẽ phân bổ các mạng với các đặc điểm và dịch vụ được gán, như không gian địa chỉ lP, lPAM, định tuyến, QoS, v.v., và các nhà phát triển hoặc kỹ sư triển khai sẽ xác định và chọn từ một nhóm các mạng có sẵn để triển khai các ứng dụng của họ. Việc cung cấp trước cần phải trở thành quá khứ, vì tất cả chúng ta đã sẵn sàng để chuyển sang cung cấp tự động (automated provisioning).
CNM và CNI
Trong nhiều khía cạnh, hai thông số kỹ thuật container networking này thực hiện chủ hóa việc lựa chọn loại mạng container nào có thể được sử dụng, trong đó cả hai đều là mô hình dựa trên driver mạng hoặc dựa trên plugin, để tạo và quản lý ngăn xếp mạng cho container. Mỗi cái cho phép nhiều driver mạng hoạt động và được sử dụng đồng thời, trong đó mỗi trình điều khiển cung cấp một ánh xạ mạng một đến một cho trình điều khiển mạng Network đó. Cả hai mô hình cho phép các container tham gia một hoặc nhiều mạng. Và mỗi cái cho phép bộ thực thi container khởi chạy mạng trong không gian tên riêng của nó, tách biệt logic ứng dụng / nghiệp vụ của việc kết nối container với network driver.
Cách tiếp cận trình điều khiển mô-đun này có thể tạo nên sự hấp dẫn hơn cho các nhà khai thác mạng so với các nhà phát triển ứng dụng, trong đó các nhà khai thác có khả năng linh hoạt để chọn một hoặc nhiều trình điều khiển đáp ứng nhu cầu cụ thể của họ và phù hợp với phương thức hoạt động hiện có của họ. Các nhà khai thác chịu trách nhiệm đảm bảo các thỏa thuận cấp dịch vụ (SLA) được đáp ứng và các chính sách bảo mật được thi hành.
Cả hai mô hình đều cung cấp các điểm mở rộng riêng biệt, còn gọi là giao diện plugin, cho driver mạng - để tạo, định cấu hình và kết nối mạng - và [PAM - để định cấu hình, khám phá và quản lý địa chỉ IP. Một điểm mở rộng cho mỗi chức năng khuyến khích khả năng kết hợp.
CNM không cung cấp cho trình điều khiển mạng quyền truy cập vào không gian tên mạng container Container. Lợi ích ở đây là libnetwork hoạt động như một nhà môi giới để giải quyết xung đột. Một ví dụ mâu thuẫn khi hai trình điều khiển mạng độc lập cung cấp cùng một Static Route, sử dụng cùng một Route Prefix, nhưng trỏ đến các địa chỉ IP next-hop khác nhau. CNI không cung cấp driver mạng để truy cập vào namespace container. CNI đang xem xét làm thế nào để nó có thể phân xử approach trong các kịch bản khác lại cần giải quyết xung đột như vậy trong tương lai.
CNI hỗ trợ tích hợp với IPAM của bên thứ ba và có thể được sử dụng với bất kỳ thời gian chạy container nào. CNM được thiết kế để chỉ hỗ trợ công cụ thời gian chạy Docker. Với cách tiếp cận đơn giản của CNl, nó đã được lập luận rằng nó có thể dễ dàng tạo ra một plugin CNI hơn một plugin CNM.
Những mô hình này thúc đẩy tính mô đun, khả năng kết hợp và lựa chọn bằng cách thúc đẩy một hệ sinh thái đổi mới của các nhà cung cấp bên thứ ba, những người cung cấp khả năng kết nối mạng tiên tiến. Việc phối hợp phân đoạn mạng có thể trở thành các lệnh gọi API đơn giản để đính kèm, tách và trao đổi mạng. Các Interface Container có thể thuộc về nhiều mạng và mỗi container có thể xuất bản các dịch vụ khác nhau trong các mạng khác nhau. Ý tưởng về các cấu trúc mạng khác nhau như các công dân hạng nhất được phản ánh trong khả năng tách dịch vụ mạng khỏi một container cũ và gắn nó vào một container mới.
Container Networking in OpenStack
Ban đầu tập trung vào tự động hóa cơ sở hạ tầng cho các máy ảo, OpenStack đã tập trung vào các nhu cầu của container. Kuryr và Magnum không phải là dự án liên quan đến container duy nhất của họ, nhưng chắc chắn đây chính là hai dự án liên quan đến mạng container.
Kuryr
Kuryr là một mạng container của dự án, hiện đang hoạt động như một remote driver cho libnetwork để cung cấp mạng cho Docker bằng cách sử dụng Neutron làm công cụ Backend Network. Hỗ trợ cho CNM đã được chuyển giao và lộ trình cho dự án này bao gồm hỗ trợ cho CNI.
Magnum
Magnum, một dự án cung cấp Container dưới dạng Dịch vụ (Container as a Service - CaaS) và tận dụng Nhiệt để khởi tạo các cụm chạy các công cụ điều phối container khác, hiện đang sử dụng các tùy chọn kết nối mạng không phải neutron cho các container.
Công việc đang được tiến hành để tích hợp Kuryr và Magnum. Quan niệm rằng các container có thể lồng ghép hay chạy đệ quy với các container khác để tạo ra một số thách thức cho các nhóm dự án cần phải vượt qua.
Networking with Intention
Mạng dựa trên ý định xác định nhu cầu của hành vi mạng và mạng trong các thuật ngữ bất khả tri về cơ sở hạ tầng bằng cách sử dụng chính sách. Với mật độ giao diện mạng tăng lên, khối lượng địa chỉ IP và độ phức tạp của giao tiếp giữa các container chạy các microservices phụ thuộc lẫn nhau, mạng sẽ được hưởng lợi từ các mô hình đã được xác định và tận dụng trong các hệ thống khác. Các thuộc tính của mạng dựa trên ý định rút ra từ những thành công của các khái niệm đã được thiết lập, đề cập đến chúng bằng các thuật ngữ bất biến, di động, có thể ghép lại, có thể mở rộng.
Ví dụ bất biến tương tự như khái niệm tiềm năng idem trong các hệ thống quản lý cấu hình. Mạng dựa trên ý định gọi điều này là bất biến, có nghĩa là ý định đó không thay đổi do chính sách ý định được áp dụng nhiều lần hoặc bằng cách sử dụng các thiết bị của nhà cung cấp khác nhau.
Một mục đích khác khái niệm dựa trên nền tảng là tính di động, một khái niệm được đặc trưng là môi trường hỗ trợ chính sách với thiết bị hoặc chính sách của nhà cung cấp không đồng nhất, tránh mọi ràng buộc cụ thể của nhà cung cấp. Mạng dựa trên ý định có thể kết hợp khi chính sách có thể đồng thời tận dụng các dịch vụ mạng khác nhau được cung cấp bởi các nhà cung cấp khác nhau về thiết bị hoặc giải pháp.
Chất lượng mạng có thể mở rộng dựa trên ý định là tự giải thích. nó cho phép mỗi nút hoặc máy chủ đưa ra quyết định kết nối mạng theo kiểu phân tán, với mỗi nút nhận thức được chính sách dựa trên ý định. Chúng tôi đã thấy được sức mạnh của các công trình, như nhãn, thẻ và chính sách, cải thiện đáng kể khả năng của các công nghệ mạng container.
Summary
Chúng tôi đã thảo luận về một số cân nhắc trước khi chọn loại mạng nào sẽ được sử dụng trong môi trường của bạn - rất có thể, bạn sẽ sử dụng kết hợp. Hiệu suất chắc chắn là một trong những cân nhắc đó và sẽ là chủ đề của nghiên cứu tiếp theo. Bên ngoài các loại kết nối và dịch vụ mạng khác nhau, một điều cần cân nhắc không được nhấn mạnh là hiểu mức độ bạn cần tích hợp với các hệ thống đương nhiệm trong môi trường của bạn. Ví dụ: trong trường hợp khối lượng công việc tại chỗ, bạn sẽ có một giải pháp IPAM hiện có. IPAM được cung cấp bởi hầu hết các nhà cung cấp driver mạng container, nhưng chỉ một số có tích hợp với nhà cung cấp PAM hàng đầu, như Cisco, lnfoblox, SolarWinds, v.v.
Khi các nhà cung cấp và dự án tiếp tục phát triển, bối cảnh mạng tiếp tục thay đổi. Một số dịch vụ đã được hợp nhất hoặc kết hợp, chẳng hạn như mua lại DockPlane của SocketPlane và chuyển đổi Flannel sang lgera - một công ty khởi nghiệp mới đã hình thành xung quanh Canal. Canal là một portmanteau của Calico và Flannel và là sự kết hợp của hai dự án đó. CoreOS sẽ cung cấp hỗ trợ liên tục cho Flannel như một dự án riêng lẻ và sẽ tích hợp Canal với Tectonic, giải pháp doanh nghiệp của họ cho Kubernetes. Những thay đổi khác đến trong các hình thức phát hành dự án mới. Docker 1.12 Phát hành các tính năng mạng, bao gồm cả Underlays và hỗ trợ cân bằng tải (Load-balancing), là một bước tiến không nhỏ đối với dự án.
Mặc dù có một số lượng lớn công nghệ mạng container và các cách tiếp cận riêng biệt, nhưng chúng tôi may mắn vì phần lớn hệ sinh thái container dường như đã hội tụ và xây dựng hỗ trợ xung quanh chỉ hai mô hình mạng. Ít nhất là cho đến nay, các nhà phát triển muốn loại bỏ việc cung cấp mạng thủ công trong môi trường container và cấm những ai có quan niệm sai lầm về sự không an toàn trong hệ thống mạng của họ, các kỹ sư mạng đã sẵn sàng để đối phó với các tình huống như vậy.
Giống như các tài nguyên khác, một bước trung gian để cung cấp tự động là cung cấp pre-provisioning, có nghĩa là các kỹ sư mạng sẽ phân bổ các mạng với các đặc điểm và dịch vụ được gán, như không gian địa chỉ lP, lPAM, định tuyến, QoS, v.v., và các nhà phát triển hoặc kỹ sư triển khai sẽ xác định và chọn từ một nhóm các mạng có sẵn để triển khai các ứng dụng của họ. Việc cung cấp trước cần phải trở thành quá khứ, vì tất cả chúng ta đã sẵn sàng để chuyển sang cung cấp tự động (automated provisioning).
Tín Phan