Ghi chú. bản dịch.: Bài viết này, được viết bởi một kỹ sư SRE từ LinkedIn, đi sâu vào chi tiết về phép thuật bên trong Kubernetes - chính xác hơn là sự tương tác của CRI, CNI và kube-apiserver - điều đó xảy ra khi nhóm tiếp theo cần được gán địa chỉ IP.
Một trong những yêu cầu cơ bản là mỗi nhóm phải có địa chỉ IP riêng và bất kỳ nhóm nào khác trong cụm phải có thể liên hệ với nó tại địa chỉ đó. Có rất nhiều “nhà cung cấp” mạng (Flannel, Calico, Canal, v.v.) giúp triển khai mô hình mạng này.
Khi tôi mới bắt đầu làm việc với Kubernetes, tôi không hoàn toàn rõ ràng về cách các nhóm lấy địa chỉ IP chính xác. Ngay cả khi hiểu được cách thức hoạt động của các thành phần riêng lẻ, thật khó để tưởng tượng chúng hoạt động cùng nhau. Ví dụ: tôi biết plugin CNI dùng để làm gì, nhưng tôi không biết chính xác chúng được gọi như thế nào. Vì vậy, tôi quyết định viết bài này để chia sẻ kiến thức về các thành phần mạng khác nhau và cách chúng hoạt động cùng nhau trong cụm Kubernetes, cho phép mỗi nhóm có được địa chỉ IP duy nhất của riêng mình.
Có nhiều cách khác nhau để tổ chức kết nối mạng trong Kubernetes, giống như có các tùy chọn thời gian chạy khác nhau cho vùng chứa. Ấn phẩm này sẽ sử dụng để tổ chức mạng theo cụm và như một môi trường thực thi - . Tôi cũng giả định rằng bạn biết cách kết nối mạng giữa các vùng chứa hoạt động, vì vậy tôi sẽ chỉ đề cập ngắn gọn về nó, chỉ để biết ngữ cảnh.
Một số khái niệm cơ bản
Vùng chứa và Mạng: Tổng quan ngắn gọn
Có rất nhiều ấn phẩm xuất sắc trên Internet giải thích cách các container giao tiếp với nhau qua mạng. Do đó, tôi sẽ chỉ đưa ra một cái nhìn tổng quan chung về các khái niệm cơ bản và giới hạn bản thân trong một cách tiếp cận, bao gồm việc tạo một cầu nối Linux và đóng gói các gói. Thông tin chi tiết bị bỏ qua vì bản thân chủ đề về mạng container xứng đáng có một bài viết riêng. Các liên kết đến một số ấn phẩm đặc biệt sâu sắc và mang tính giáo dục sẽ được cung cấp dưới đây.
Các thùng chứa trên một máy chủ
Một cách để tổ chức liên lạc qua địa chỉ IP giữa các container chạy trên cùng một máy chủ là tạo một cầu nối Linux. Với mục đích này, các thiết bị ảo được tạo trong Kubernetes (và Docker) . Một đầu của thiết bị veth kết nối với không gian tên mạng của container, đầu còn lại với trên mạng chủ.
Tất cả các container trên cùng một máy chủ đều có một đầu của veth được kết nối với một cầu nối để chúng có thể giao tiếp với nhau thông qua địa chỉ IP. Cầu Linux cũng có địa chỉ IP và hoạt động như một cổng cho lưu lượng truy cập đầu ra từ các nhóm dành cho các nút khác.
Vùng chứa trên các máy chủ khác nhau
Đóng gói gói là một phương pháp cho phép các thùng chứa trên các nút khác nhau giao tiếp với nhau bằng địa chỉ IP. Tại Flannel, công nghệ là nguyên nhân tạo ra cơ hội này. , "đóng gói" gói gốc thành gói UDP và sau đó gửi nó đến đích.
Trong cụm Kubernetes, Flannel tạo một thiết bị vxlan và cập nhật bảng lộ trình trên mỗi nút tương ứng. Mỗi gói dành cho một vùng chứa trên một máy chủ khác nhau sẽ đi qua thiết bị vxlan và được gói gọn trong gói UDP. Tại đích, gói lồng nhau được trích xuất và chuyển tiếp đến nhóm mong muốn.
Lưu ý: Đây chỉ là một cách để tổ chức giao tiếp mạng giữa các container.
CRI là gì?
là một plugin cho phép kubelet sử dụng các môi trường thời gian chạy vùng chứa khác nhau. API CRI được tích hợp vào nhiều thời gian chạy khác nhau, vì vậy người dùng có thể chọn thời gian chạy theo ý muốn.
CNI là gì?
là một để tổ chức một giải pháp mạng phổ quát cho các bộ chứa Linux. Ngoài ra, nó bao gồm , chịu trách nhiệm về các chức năng khác nhau khi thiết lập mạng nhóm. Plugin CNI là một tệp thực thi tuân thủ thông số kỹ thuật (chúng tôi sẽ thảo luận về một số plugin bên dưới).
Phân bổ mạng con cho các nút để gán địa chỉ IP cho nhóm
Vì mỗi nhóm trong một cụm phải có một địa chỉ IP nên điều quan trọng là phải đảm bảo rằng địa chỉ này là duy nhất. Điều này đạt được bằng cách gán cho mỗi nút một mạng con duy nhất, từ đó các nhóm trên nút đó sau đó được gán địa chỉ IP.
Bộ điều khiển nút IPAM
Khi nodeipam được truyền dưới dạng tham số cờ --controllers , nó phân bổ một mạng con riêng biệt (podCIDR) cho mỗi nút từ cụm CIDR (tức là dải địa chỉ IP cho mạng cụm). Vì các podCIDR này không trùng nhau nên mỗi nhóm có thể được cấp một địa chỉ IP duy nhất.
Nút Kubernetes được gán podCIDR khi nó được đăng ký lần đầu với cụm. Để thay đổi podCIDR của các nút, bạn cần hủy đăng ký chúng rồi đăng ký lại, thực hiện các thay đổi thích hợp đối với cấu hình lớp điều khiển Kubernetes ở giữa. Bạn có thể hiển thị podCIDR của một nút bằng lệnh sau:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, thời gian chạy container và plugin CNI: cách thức hoạt động của tất cả
Việc lập lịch cho một nhóm trên mỗi nút bao gồm rất nhiều bước chuẩn bị. Trong phần này, tôi sẽ chỉ tập trung vào những thứ liên quan trực tiếp đến việc thiết lập mạng nhóm.
Việc lập lịch nhóm đến một nút nhất định sẽ kích hoạt chuỗi sự kiện sau:
Thông tin khác: .
Tương tác giữa thời gian chạy vùng chứa và plugin CNI
Mỗi nhà cung cấp mạng có plugin CNI riêng. Thời gian chạy của vùng chứa sẽ chạy nó để định cấu hình mạng cho nhóm khi nó khởi động. Trong trường hợp containerd, plugin CNI được plugin khởi chạy .
Hơn nữa, mỗi nhà cung cấp đều có đại lý riêng. Nó được cài đặt trên tất cả các nút Kubernetes và chịu trách nhiệm về cấu hình mạng của các nhóm. Tác nhân này được bao gồm trong cấu hình CNI hoặc tạo nó một cách độc lập trên nút. Cấu hình giúp plugin CRI thiết lập plugin CNI nào sẽ gọi.
Vị trí của cấu hình CNI có thể được tùy chỉnh; theo mặc định nó ở trong /etc/cni/net.d/<config-file>. Quản trị viên cụm cũng chịu trách nhiệm cài đặt các plugin CNI trên mỗi nút cụm. Vị trí của họ cũng có thể tùy chỉnh; thư mục mặc định - /opt/cni/bin.
Khi sử dụng containerd, các đường dẫn cho cấu hình plugin và tệp nhị phân có thể được đặt trong phần [plugins.«io.containerd.grpc.v1.cri».cni] в .
Vì chúng tôi đang sử dụng Flannel làm nhà cung cấp mạng nên hãy nói một chút về cách thiết lập nó:
- Flanneld (daemon của Flannel) thường được cài đặt trong một cụm dưới dạng DaemonSet với
install-cninhư . Install-cnitạo ra (/etc/cni/net.d/10-flannel.conflist) trên mỗi nút.- Flanneld tạo một thiết bị vxlan, truy xuất siêu dữ liệu mạng từ máy chủ API và giám sát các bản cập nhật nhóm. Khi chúng được tạo, nó sẽ phân phối các tuyến đường đến tất cả các nhóm trong toàn cụm.
- Các tuyến này cho phép các nhóm giao tiếp với nhau thông qua địa chỉ IP.
Để biết thêm thông tin chi tiết về công việc của Flannel, tôi khuyên bạn nên sử dụng các liên kết ở cuối bài viết.
Dưới đây là sơ đồ về sự tương tác giữa plugin Containerd CRI và plugin CNI:
Như bạn có thể thấy ở trên, kubelet gọi plugin CRI Containerd để tạo nhóm, sau đó gọi plugin CNI để định cấu hình mạng của nhóm. Khi làm như vậy, plugin CNI của nhà cung cấp mạng sẽ gọi các plugin CNI cốt lõi khác để định cấu hình các khía cạnh khác nhau của mạng.
Tương tác giữa các plugin CNI
Có nhiều plugin CNI khác nhau có nhiệm vụ giúp thiết lập giao tiếp mạng giữa các vùng chứa trên máy chủ. Bài viết này sẽ thảo luận về ba trong số đó.
Flannel plugin CNI
Khi sử dụng Flannel làm nhà cung cấp mạng, thành phần Containerd CRI gọi sử dụng tệp cấu hình CNI /etc/cni/net.d/10-flannel.conflist.
$ cat /etc/cni/net.d/10-flannel.conflist
{
"name": "cni0",
"plugins": [
{
"type": "flannel",
"delegate": {
"ipMasq": false,
"hairpinMode": true,
"isDefaultGateway": true
}
}
]
}
Plugin Flannel CNI hoạt động cùng với Flanneld. Trong quá trình khởi động, Flanneld truy xuất podCIDR và các chi tiết khác liên quan đến mạng từ máy chủ API và lưu chúng vào một tệp /run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
Plugin Flannel CNI sử dụng dữ liệu từ /run/flannel/subnet.env để định cấu hình và gọi plugin cầu nối CNI.
Cầu nối plugin CNI
Plugin này được gọi với cấu hình sau:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Khi được gọi lần đầu tiên, nó sẽ tạo một cầu nối Linux với «name»: «cni0», được chỉ định trong config. Sau đó, một cặp veth được tạo cho mỗi nhóm. Một đầu của nó được kết nối với namespace mạng của container, đầu còn lại được đưa vào cầu Linux trên mạng máy chủ. kết nối tất cả các vùng chứa máy chủ với cầu nối Linux trên mạng máy chủ.
Sau khi thiết lập xong cặp veth, plugin Bridge gọi plugin IPAM CNI trên máy chủ cục bộ. Loại plugin IPAM có thể được định cấu hình trong cấu hình CNI mà plugin CRI sử dụng để gọi plugin Flannel CNI.
Các plugin IPAM CNI trên máy chủ cục bộ
Cầu nối cuộc gọi CNI với cấu hình sau:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Plugin IPAM trên máy chủ cục bộ (IP Address Mquản lý - quản lý địa chỉ IP) trả về địa chỉ IP cho vùng chứa từ mạng con và lưu trữ IP được phân bổ trên máy chủ trong thư mục được chỉ định trong phần dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Tệp này chứa ID của vùng chứa mà địa chỉ IP này được gán.
Khi gọi plugin IPAM trên máy chủ cục bộ, nó sẽ trả về dữ liệu sau:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Tóm tắt thông tin
Trình quản lý bộ điều khiển Kube chỉ định podCIDR cho mỗi nút. Các nhóm của mỗi nút nhận địa chỉ IP từ không gian địa chỉ trong phạm vi podCIDR được phân bổ. Vì podCIDR của các nút không trùng nhau nên tất cả các nhóm đều nhận được địa chỉ IP duy nhất.
Quản trị viên cụm Kubernetes định cấu hình và cài đặt kubelet, thời gian chạy vùng chứa, tác nhân nhà cung cấp mạng và sao chép các plugin CNI vào từng nút. Trong quá trình khởi động, tác nhân nhà cung cấp mạng tạo cấu hình CNI. Khi một nhóm được lên lịch cho một nút, kubelet sẽ gọi plugin CRI để tạo nó. Tiếp theo, nếu containerd được sử dụng, plugin CRI của Container sẽ gọi plugin CNI được chỉ định trong cấu hình CNI để định cấu hình mạng của nhóm. Kết quả là nhóm nhận được một địa chỉ IP.
Tôi phải mất một thời gian để hiểu tất cả sự tinh tế và sắc thái của tất cả những tương tác này. Tôi hy vọng trải nghiệm này sẽ giúp bạn hiểu rõ hơn về cách hoạt động của Kubernetes. Nếu tôi sai về bất cứ điều gì, xin vui lòng liên hệ với tôi tại hoặc tại địa chỉ . Vui lòng liên hệ nếu bạn muốn thảo luận về các khía cạnh của bài viết này hoặc bất cứ điều gì khác. Tôi rất muốn trò chuyện với bạn!
tài liệu tham khảo
Container và mạng
Flannel hoạt động như thế nào?
CRI và CNI
Tái bút từ người dịch
Đọc thêm trên blog của chúng tôi:
- «»;
- "Hướng dẫn minh họa về kết nối mạng trong Kubernetes": , ;
- «'.
Nguồn: www.habr.com