Tìm hiểu về Docker Container Networking (Phần 1)

[Tín Phan]

Mạng là một thành phần vốn có cho bất kỳ ứng dụng phân tán nào và là một trong những công nghệ phức tạp và mở rộng nhất. Khi các nhà phát triển ứng dụng đang bận rộn áp dụng các công nghệ container, đã đến lúc các kỹ sư mạng phải chuẩn bị cho những thách thức độc đáo do các ứng dụng gốc trên đám mây mang lại.

Với việc phổ biến các Container và Microservice, các thách thức cho mạng lưới Data Center đã tăng lên về độ phức tạp. Mật độ mà các container được triển khai trên các máy chủ (Server) đưa ra những thách thức về mật độ giao diện mạng (Network Interface) tăng lên. Độ phức tạp hoạt động đã chuyển từ một vài giao diện mạng trên các máy chủ Metal hosts, sang một vài giao diện mạng trên mỗi máy ảo (VM) với hai mươi VM trên mỗi máy chủ, sang một vài giao diện trên mỗi container với hàng trăm container trên mỗi máy chủ.

Mặc dù mật độ tăng lên này, các yêu cầu và đo lường độ tin cậy của phần cứng mạng thông thường là các nhu cầu và mong đợi tương tự đối với mạng container. Có thể, các nhà khai thác sẽ so sánh hiệu suất của mạng máy ảo với hiệu suất của mạng container và mong đợi sự khác biệt nhỏ hay cải thiện hiệu suất khi container được chạy trực tiếp trên Metal hosts.

Bài viết này được chia thành hai lĩnh vực chính tập trung xung quanh 2 loại Container Networking và Container Networking Specifics. Phần một bắt đầu với nhiều cách khác nhau trong đó cung cấp kết nối giữa container và container với máy chủ.

Đầu tiên chúng ta sẽ cùng tìm hiểu (Breakdown) các loại Container Networking sau:

• None
• Brigde
• Overlays
• Underlays

Đối với nửa sau của bài viết này, có hai thông số kỹ thuật của Container networking đã tạo tiền đề cho các thành phần khác nhau của Container networking để chúng có thể kết hợp với nhau như thế nào để tạo ra Container networking.

Hai thông số kỹ thuật mà chúng ta sẽ tìm hiểu là:

• Container Network Model (CNM)
• Container Network Interface (CNI)

Các kỹ thuật này cung cấp một cơ chế cho khả năng tương tác và mở rộng khi các nhà cung cấp áp dụng chúng. Chúng ta sẽ khám phá những kỹ thuật này như là một sự hiểu biết về lý thuyết và cách hoạt động tự động hóa của chúng.

Các loại Container Networking:

Mặc dù nhiều người hướng đến Overlay Network như một cách tiếp cận phổ biến để giải quyết Container networking trên các máy chủ, các chức năng và loại Container networking khác nhau rất đáng để hiểu rõ hơn khi bạn xem xét loại phù hợp với môi trường của mình.

Một số loại là container engine-agnostic, và một số loại khác độc quyền vào một nhà cung cấp hoặc công nghệ cụ thể. Một số tập trung vào sự đơn giản, trong khi một số khác tập trung vào chức năng hoặc có khả năng thân thiện và đa phương tiện. Cái nào phù hợp với bạn tùy thuộc vào nhu cầu hoặc ứng dụng của bạn, yêu cầu về hiệu suất, vị trí khối lượng công việc (đám mây riêng hoặc công cộng), v.v. Hãy để xem lại các loại mạng container phổ biến hơn.

Các loại Container Networking cũ:

Cách tiếp cận mạng đã phát triển khi công nghệ container tiến bộ

Links and Ambassadors

có hỗ trợ và phối hợp mạng nhiều máy chủ với Swarm, Docker bắt đầu với kết nối mạng một máy chủ, tạo điều kiện kết nối mạng thông qua các liên kết như một cơ chế cho phép các container phát hiện lẫn nhau thông qua các biến môi trường hoặc / etc / máy chủ lưu trữ tệp, và chuyển thông tin giữa các container. Khả năng liên kết thường được kết hợp với Ambassadors để tạo điều kiện liên kết các container giữa các máy chủ và giảm độ giòn của các liên kết được mã hóa cứng. Vấn đề lớn nhất với cách tiếp cận này là nó quá tĩnh. Khi một container được tạo và các biến môi trường được xác định, nếu các container hoặc dịch vụ liên quan chuyển sang địa chỉ lP mới, thì không thể thay đổi giá trị của các biến đó.

Container-Mapped Networking

Trong chế độ kết nối mạng này, một container sử dụng lại (ánh xạ đến) không gian tên mạng của một container khác. Chế độ kết nối mạng này chỉ có thể được gọi khi chạy bộ chứa docker như sau:

net:container:some_container_name_or_id

Câu lệnh này báo cho Docker đặt các quá trình này vào vùng chứa của ngăn xếp mạng đã được tạo bên trong một vùng chứa khác. Mặc dù chia sẻ cùng một địa chỉ IP và MAC và số cổng như bộ chứa đầu tiên, các quy trình container mới của container vẫn bị giới hạn trong hệ thống tệp, danh sách quy trình và giới hạn tài nguyên của chính nó. Các quy trình trên hai container sẽ có thể kết nối với nhau qua loopback interfaces.

Kiểu mạng này rất hữu ích để thực hiện chẩn đoán trên một container đang chạy và container bị thiếu các công cụ chẩn đoán cần thiết (ví dụ: curl hoặc dig). Một container tạm thời với các công cụ chẩn đoán cần thiết có thể được tạo và gắn vào mạng container container đầu tiên.

Container-mapped networking có thể được sử dụng để mô phỏng mạng kiểu pod, trong đó nhiều container chia sẻ cùng một không gian tên mạng. Các lợi ích, chẳng hạn như chia sẻ giao tiếp localhost và chia sẻ cùng một địa chỉ IP, vốn có với khái niệm rằng các container chạy trong cùng một nhóm, đó là hành vi của các container rkt.

Các loại mạng container hiện tại

Các dòng phân định kết nối mạng xoay quanh IP container trên mỗi container so với các mô hình pod lP trên mỗi mô hình và yêu cầu dịch địa chỉ mạng (NAT) so với không cần phải translation.

None

Không có gì là đơn giản trong việc container nhận được một ngăn xếp mạng, nhưng thiếu giao diện mạng bên ngoài. Lúc này sẽ nhận được một Loopback Interfacfaces. Cả hai loại container là rkt và docker đều cung cấp hành vi tương tự khi không sử dụng mạng null hoặc none. Chế độ kết nối mạng container này có một số cách sử dụng bao gồm các container kiểm tra, sắp xếp một container cho kết nối mạng sau này và được gán cho các container không cần giao tiếp bên ngoài.

Brigde

Linux cung cấp một host-internal bên trong máy chủ lưu trữ trong đó các container trên cùng một máy chủ có thể giao tiếp, nhưng các địa chỉ IP được gán cho mỗi container không thể truy cập được từ bên ngoài máy chủ. Kết nối mạng Brigde cần iptables cho NAT và ánh xạ lên cổng, cung cấp kết nối mạng máy cho chủ đơn. Mạng Brigde là loại mạng Docker mặc định (nghĩa là dockero), trong đó một đầu của cặp giao diện mạng ảo được kết nối giữa cầu và container.

Dưới đây, một ví dụ về các hoạt động của Brigde:

1. Một Brigde được cung cấp trên máy chủ.
2. Một không gian tên cho mỗi container được cung cấp bên trong Brigde đó.
3. Containers’ ethX được ánh xạ tới các giao diện Brigde riêng.
4. Iptabies với NAT được sử dụng để ánh xạ giữa mỗi vùng chứa riêng và giao diện công cộng của máy chủ lưu trữ.

NAT (Network address translation) được sử dụng để cung cấp thông tin liên lạc ra ngoài máy chủ. Trong khi các mạng được Brigde để giải quyết các vấn đề xung đột trên cổng và cung cấp cách ly mạng cho các container chạy trên một máy chủ, thì có một chi phí hiệu năng liên quan đến việc sử dụng NAT.

Host

Theo cách tiếp cận này, một container mới được tạo sẽ chia sẻ không gian tên mạng của nó với máy chủ, cung cấp hiệu suất cao hơn - gần với tốc độ của Metal - và loại bỏ sự cần thiết của NAT; tuy nhiên, nó bị xung đột cổng. Mặc dù bộ chứa có quyền truy cập vào tất cả các giao diện mạng của máy chủ lưu trữ, trừ khi được triển khai ở chế độ đặc quyền. Bộ chứa có thể không cấu hình lại ngăn xếp mạng máy chủ lưu trữ.

Host networking là loại mặc định được sử dụng trong Mesos. Nói cách khác, nếu framework không chỉ định loại mạng, một không gian mạng mới sẽ không được liên kết với vùng chứa. Nhưng với Host network, Đôi khi được gọi là mạng riêng, mạng máy chủ là khái niệm đơn giản, giúp dễ hiểu, khắc phục sự cố và sử dụng.

Overlays

Overlays sử dụng các Tunnels để cung cấp thông tin liên lạc giữa các máy chủ. Điều này cho phép các container hoạt động như thể chúng ở trên cùng một máy bằng cách tạo các mạng con mạng từ máy chủ này sang máy chủ khác. Về bản chất, trải rộng một mạng trên nhiều máy chủ. Hiện nay có nhiều công nghệ Tunnels đang tồn tại và sử dụng rộng rãi, chẳng hạn như Virtual extensible local area network (VxLAN).

VxLAN đã trở thành công nghệ Tunnels được lựa chọn cho Docker libnetwork, mạng kết nối máy chủ đa mục nhập được nhập như một khả năng riêng trong bản phát hành l.9. Với việc giới thiệu khả năng này, Docker đã chọn sử dụng HashiCorp, Serf làm giao thức tin đồn, được chọn vì hiệu quả của nó trong thời gian trao đổi và hội tụ khá nhanh.

Đối với những người cần hỗ trợ cho các công nghệ đường hầm khác, Flannel có thể là con đường để đi. Nó hỗ trợ Udp, VxLAN, Host-gw, AWS-vPC hoặc Gce. Mỗi loại đám mây providertunnel tạo các tuyến trong bảng định tuyến của nhà cung cấp, chỉ dành cho tài khoản của bạn hoặc đám mây riêng ảo (VPC). Sự hỗ trợ cho các đám mây công cộng đặc biệt quan trọng đối với các trình điều khiển lớp phủ, trong số các trường hợp khác, các lớp phủ sử dụng tốt nhất cho các trường hợp sử dụng đám mây lai và cung cấp tỷ lệ và dự phòng mà không phải mở các Public cổng.

Multi-host networking yêu cầu các tham số bổ sung khi khởi chạy trình nền Docker daemon, cũng như lưu trữ khóa-giá trị. Một số lớp phủ dựa trên một kho lưu trữ khóa-giá trị phân tán. nếu bạn đang thực hiện việc sắp xếp container, bạn sẽ có một cửa hàng khóa-giá trị phân tán nằm xung quanh.

Overlays tập trung vào thử thách giao tiếp máy chủ chéo chéo. Các container trên cùng một máy chủ được kết nối với hai mạng lớp phủ khác nhau không thể liên lạc với nhau thông qua cầu nối cục bộ - chúng được phân đoạn với nhau.

Tín Phan

Link phần tiếp theo (Phần 2): https://www.forum.vnpro.org/forum/c%...ph%E1%BA%A7n-2