Kubernetes mạng dưới mui xe

Giới thiệu

Kubernetes là một hệ thống dàn nhạc container mạnh mẽ có thể quản lý việc triển khai và vận hành các ứng dụng được chứa trong các cụm máy chủ. Ngoài việc điều phối tải công việc của container, Kubernetes cung cấp cơ sở hạ tầng và các công cụ cần thiết để duy trì kết nối mạng đáng tin cậy giữa các ứng dụng và dịch vụ của bạn.

Các Tài liệu mạng cụm Kubernetes nói rằng các yêu cầu cơ bản của mạng Kubernetes là:

• tất cả các thùng chứa có thể giao tiếp với tất cả các vùng chứa khác mà không có NAT
• tất cả các nút có thể giao tiếp với tất cả các vùng chứa (và ngược lại) mà không cần NAT
• IP mà một vùng chứa thấy chính nó giống như IP mà những người khác nhìn thấy

Trong bài viết này, chúng ta sẽ thảo luận về cách Kubernetes đáp ứng các yêu cầu mạng này trong một cụm: cách dữ liệu di chuyển bên trong một nhóm, giữa các nhóm và giữa các nút.

Chúng tôi cũng sẽ chỉ ra cách thức một Kubernetes Dịch vụ có thể cung cấp một địa chỉ IP tĩnh duy nhất và mục nhập DNS cho một ứng dụng, giúp giảm bớt giao tiếp với các dịch vụ có thể được phân phối giữa nhiều nhóm mở rộng và chuyển đổi liên tục.

Nếu bạn không quen thuộc với thuật ngữ của Kubernetes vỏ trái cây và nút hoặc các khái niệm cơ bản khác, bài viết của chúng tôi Giới thiệu về Kubernetes bao gồm kiến ​​trúc chung và các thành phần liên quan.

Trước tiên, hãy xem xét tình hình mạng trong một nhóm duy nhất.

Mạng Pod

Ở Kubernetes, vỏ trái cây là đơn vị tổ chức cơ bản nhất: một nhóm các thùng chứa được kết hợp chặt chẽ có liên quan chặt chẽ và thực hiện một chức năng hoặc dịch vụ duy nhất.

Về mặt mạng, Kubernetes xử lý các nhóm tương tự như một máy ảo truyền thống hoặc một máy chủ kim loại đơn: mỗi nhóm nhận một địa chỉ IP duy nhất và tất cả các vùng chứa trong nhóm chia sẻ địa chỉ và liên lạc với nhau qua lo giao diện loopback bằng cách sử dụng localhost tên máy chủ. Điều này đạt được bằng cách gán tất cả các vùng chứa của pod vào cùng một ngăn xếp mạng.

Tình huống này nên cảm thấy quen thuộc với bất kỳ ai đã triển khai nhiều dịch vụ trên một máy chủ lưu trữ duy nhất trước ngày lưu trữ. Tất cả các dịch vụ cần phải sử dụng một cổng duy nhất để lắng nghe, nhưng nếu không giao tiếp không biến chứng và có chi phí thấp.

Pod để Pod mạng

Hầu hết các cụm Kubernetes sẽ cần triển khai nhiều nhóm trên mỗi nút. Pod để pod thông tin liên lạc có thể xảy ra giữa hai quả trên cùng một nút, hoặc giữa hai nút khác nhau.

Pod để Pod truyền thông trên một nút

Trên một nút duy nhất, bạn có thể có nhiều nhóm cần giao tiếp trực tiếp với nhau. Trước khi chúng ta theo dõi lộ trình của một gói giữa các nhóm, chúng ta hãy kiểm tra thiết lập mạng của một nút. Sơ đồ sau đây cung cấp một cái nhìn tổng quan, mà chúng tôi sẽ đi qua chi tiết:

Mỗi nút có giao diện mạng - “ eth0 trong ví dụ này - được gắn vào mạng cụm Kubernetes. Giao diện này nằm trong nút của nguồn gốc không gian tên mạng. Đây là không gian tên mặc định cho các thiết bị mạng trên Linux.

Cũng giống như các không gian tên của quá trình cho phép các thùng chứa cách ly các ứng dụng đang chạy với nhau, các không gian tên mạng tách biệt các thiết bị mạng như giao diện và cầu nối. Mỗi nhóm trên một nút được gán một không gian tên mạng riêng biệt.

Các không gian tên Pod được kết nối trở lại nguồn gốc không gian tên với một cặp ethernet ảo, về cơ bản là một đường ống giữa hai không gian tên với một giao diện trên mỗi đầu (ở đây chúng tôi đang sử dụng veth1 bên trong nguồn gốc không gian tên và eth0 trong nhóm).

Cuối cùng, các pod được kết nối với nhau và đến nút eth0 giao diện thông qua một cây cầu, br0 (nút của bạn có thể sử dụng một cái gì đó như cbr0 hoặc là docker0). Một bridge cơ bản hoạt động giống như một switch ethernet vật lý, sử dụng ARP (giao thức phân giải địa chỉ) hoặc định tuyến dựa trên IP để tìm kiếm các giao diện cục bộ khác để hướng lưu lượng truy cập đến.

Hãy theo dõi một gói từ pod1 đến pod2 hiện nay:

• pod1 tạo một gói với pod2IP là đích đến của nó
• Gói đi qua cặp ethernet ảo đến không gian tên mạng gốc
• Gói tin tiếp tục đến cây cầu br0
• Vì pod đích nằm trên cùng một nút, bridge gửi gói tin đến pod2cặp ethernet ảo
• gói tin đi qua cặp ethernet ảo, vào pod2không gian tên mạng và của nhóm eth0 giao diện mạng

Bây giờ chúng tôi đã truy tìm một gói từ nhóm này sang nhóm khác trong một nút, chúng ta hãy xem lưu lượng truy cập pod di chuyển giữa các nút.

Pod để Pod truyền thông giữa hai nút

Bởi vì mỗi nhóm trong một cụm có một IP duy nhất và mỗi nhóm có thể giao tiếp trực tiếp với tất cả các nhóm khác, gói di chuyển giữa các nhóm trên hai nút khác nhau rất giống với kịch bản trước đó.

Hãy theo dõi một gói từ pod1 đến pod3, trên một nút khác:

• pod1 tạo một gói với pod3IP là đích đến của nó
• Gói đi qua cặp ethernet ảo đến không gian tên mạng gốc
• Gói tin tiếp tục đến cây cầu br0
• Cây cầu không tìm thấy giao diện cục bộ để định tuyến đến, vì vậy gói được gửi đi tuyến đường mặc định về phía eth0
• Không bắt buộc: nếu cụm của bạn yêu cầu lớp phủ mạng để định tuyến đúng gói đến các nút, gói có thể được đóng gói trong gói VXLAN (hoặc kỹ thuật ảo hóa mạng khác) trước khi chuyển đến mạng. Cách khác, bản thân mạng có thể được thiết lập với các tuyến tĩnh thích hợp, trong trường hợp đó gói tin chuyển sang eth0 và ra khỏi mạng không bị thay đổi.
• Gói tin đi vào mạng cụm và được định tuyến tới nút chính xác.
• Gói tin đi vào nút đích trên eth0
• Không bắt buộc: nếu gói của bạn được đóng gói, nó sẽ được bỏ gói tại thời điểm này
• Gói tin tiếp tục đến cây cầu br0
• Cây cầu chuyển gói dữ liệu đến cặp ethernet ảo của nhóm đích
• Gói tin chuyển qua cặp ethernet ảo tới nhóm eth0 giao diện

Bây giờ chúng ta đã quen thuộc với cách các gói tin được định tuyến thông qua các địa chỉ IP của pod, chúng ta hãy xem xét Kubernetes dịch vụ và cách họ xây dựng trên cơ sở hạ tầng này.

Pod vào mạng dịch vụ

Sẽ rất khó để gửi lưu lượng truy cập đến một ứng dụng cụ thể chỉ bằng các IP nhóm, vì bản chất động của cụm Kubernetes có nghĩa là các nhóm có thể được di chuyển, khởi động lại, nâng cấp hoặc thu nhỏ trong và ngoài sự tồn tại. Ngoài ra, một số dịch vụ sẽ có nhiều bản sao, vì vậy chúng tôi cần một số cách để cân bằng tải giữa chúng.

Kubernetes giải quyết vấn đề này với Dịch vụ. Dịch vụ là một đối tượng API ánh xạ một IP ảo (VIP) duy nhất tới một nhóm các IP nhóm. Ngoài ra, Kubernetes cung cấp một mục nhập DNS cho tên của từng dịch vụ và IP ảo, do đó các dịch vụ có thể dễ dàng được giải quyết theo tên.

Việc ánh xạ các IP ảo tới các IP nhóm trong cụm được điều phối bởi kube-proxy quá trình trên mỗi nút. Quá trình này thiết lập iptables hoặc IPVS để tự động dịch VIP thành các IP nhóm trước khi gửi gói ra mạng cụm. Các kết nối riêng lẻ được theo dõi để các gói có thể được dịch đúng khi chúng trở về. IPVS và iptables cả hai có thể thực hiện cân bằng tải của một IP ảo dịch vụ duy nhất thành nhiều IP nhóm, mặc dù IPVS có tính linh hoạt hơn nhiều trong các thuật toán cân bằng tải mà nó có thể sử dụng.

Chú thích: quá trình theo dõi bản dịch và kết nối này diễn ra hoàn toàn trong hạt nhân Linux. kube-proxy đọc từ Kubernetes API và cập nhật iptables ip IPVS, nhưng nó không nằm trong đường dẫn dữ liệu cho từng gói dữ liệu. Điều này hiệu quả hơn và hiệu suất cao hơn các phiên bản trước của kube-proxy, có chức năng như một proxy người dùng.

Hãy theo dõi tuyến đường mà gói tin lấy từ một nhóm, pod1 một lần nữa, với một dịch vụ, dịch vụ1:

• pod1 tạo một gói với dịch vụ1IP là đích đến của nó
• Gói đi qua cặp ethernet ảo đến không gian tên mạng gốc
• Gói tin tiếp tục đến cây cầu br0
• Cây cầu không tìm thấy giao diện cục bộ để định tuyến gói tin, vì vậy gói được gửi đi tuyến đường mặc định về phía eth0
• Iptables hoặc IPVS, được thiết lập bởi kube-proxy, khớp IP đích của gói và dịch từ IP ảo sang một trong các IP nhóm của dịch vụ, sử dụng bất kỳ thuật toán cân bằng tải nào khả dụng hoặc được chỉ định
• Không bắt buộc: gói của bạn có thể được đóng gói tại thời điểm này, như được thảo luận trong phần trước
• Gói tin đi vào mạng cụm và được định tuyến tới nút chính xác.
• Gói tin đi vào nút đích trên eth0
• Không bắt buộc: nếu gói của bạn được đóng gói, nó sẽ được bỏ gói tại thời điểm này
• Gói tin tiếp tục đến cây cầu br0
• Gói tin được gửi đến cặp ethernet ảo qua veth1
• Gói tin đi qua cặp ethernet ảo và đi vào không gian tên mạng pod thông qua eth0 giao diện mạng

Khi gói trả về nút1 bản dịch VIP sang pod IP sẽ được đảo ngược và gói sẽ quay lại qua cầu và giao diện ảo với nhóm chính xác.

Phần kết luận

Trong bài viết này, chúng tôi đã xem xét cơ sở hạ tầng mạng nội bộ của một cụm Kubernetes. Chúng tôi đã thảo luận về các khối xây dựng tạo nên mạng và chi tiết hành trình hop-by-hop của các gói trong các tình huống khác nhau.

Để biết thêm thông tin về Kubernetes, hãy xem thẻ hướng dẫn Kubernetes của chúng tôi và tài liệu chính thức của Kubernetes.