Cấu hình cụm ETCD cho Kubernetes: Cái nào nên được xem xét?

Tôi muốn biết cách triển khai cụm ETCD cho Kubernetes. Có vẻ như có hai tài liệu khác nhau và tôi không biết tài liệu nào phải được xem xét hoặc tác động của từng tài liệu.

Từ Tài liệu Kubernetes đối với một etcd nhiều cụm, nên bắt đầu nó như thế này

v.v. --listen-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$ IP5:2379 --advertise-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http:/ /$IP5:2379

đây --listen-client-urls-- có danh sách tất cả các điểm cuối ETCD và điều tương tự cho --advertise-client-urls và từ tài liệu Kubernetes, lệnh đó chỉ được chạy một lần.

Từ tài liệu ETCD lệnh đó phải được chạy trong mỗi nút

$ etcd --name infra0 --initial-advertise-peer-urls https://10.0.1.10:2380 \
  --listen-peer-urls https://10.0.1.10:2380 \
  --listen-client-urls https://10.0.1.10:2379,https://127.0.0.1:2379 \
  --advertise-client-urls https://10.0.1.10:2379 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-cluster infra0=https://10.0.1.10:2380,infra1=https://10.0.1.11:2380,infra2=https://10.0.1.12:2380 \
  --initial-cluster-state mới \
  --client-cert-auth --trusted-ca-file=/path/to/ca-client.crt \
  --cert-file=/path/to/infra0-client.crt --key-file=/path/to/infra0-client.key \
  --peer-client-cert-auth --peer-trusted-ca-file=ca-peer.crt \
  --peer-cert-file=/path/to/infra0-peer.crt --peer-key-file=/path/to/infra0-peer.key

và chúng ta có thể nhận thấy rằng --listen-client-urls-- chỉ chứa địa chỉ IP của nút hiện tại và các tham số khác không có trong tài liệu Kubernetes.

Tại sao chúng lại khác nhau như vậy? Bạn có thể giúp tôi hiểu được không? Cái nào là cái tốt? Khi nào mỗi người trong số họ phải được sử dụng?

Nói một cách ngắn gọn, tôi đề nghị làm theo v.v. tài liệu về thiết lập v.v. cụm.

Nói cách khác, trước tiên chúng ta hãy xem ý nghĩa của những lá cờ này.

--listen-client-urls - đây là một hội viêncờ của (có liên quan đến cấp độ của nút):

Danh sách các URL để theo dõi lưu lượng truy cập của khách hàng. Lá cờ này báo cho etcd để chấp nhận các yêu cầu đến từ khách hàng trên quy định lược đồ: // IP: kết hợp cổng. Lược đồ có thể là http hoặc https. Nếu 0.0.0.0 được chỉ định làm IP, etcd lắng nghe cổng đã cho trên tất cả các giao diện. Nếu một địa chỉ IP được cung cấp cũng như một cổng, etcd sẽ lắng nghe trên cổng và giao diện đã cho. Nhiều URL có thể được sử dụng để chỉ định một số địa chỉ và cổng để nghe. vvd sẽ đáp ứng các yêu cầu từ bất kỳ địa chỉ và cổng nào được liệt kê.

etcd - nghe url khách hàng

--advertise-client-url - đây là một cụm cờ có phạm vi (nó tự nói):

Danh sách các URL khách hàng của thành viên này để quảng cáo cho phần còn lại của cụm. Các URL này có thể chứa tên miền.

etcd - quảng cáo-ứng dụng khách-url

Ngoài ra xin vui lòng tìm thấy một làm rõ ngắn trong Hỏi & Đáp - sự khác biệt giữa các cờ

Đối với tài liệu kubernetes bạn đã chia sẻ, điều này có vẻ không logic bởi vì v.v. lệnh sẽ chạy trên từng nút, tuy nhiên trong ví dụ này không rõ các nút khác sẽ nhận thông tin này như thế nào.

Ngoài ra, một tùy chọn khác là để đơn giản và bắt đầu nhanh, họ đã cung cấp cấu hình như vậy và v.v. nên bỏ qua các IP không được sử dụng (ví dụ: IP của các nút khác trên cổng cục bộ để lắng nghe lưu lượng của máy khách). Và nó không phải là xấu nếu tất cả v.v. các nút có thể quảng cáo IP của tất cả các nút.

Tuy nhiên v.v. tài liệu nêu rõ ràng để bắt đầu v.v. với chỉ địa chỉ cục bộ trên mỗi nút - Tôi cho rằng đó là cách chính xác.

Tôi đề nghị đề cập đến thiết lập cụm. Tài liệu này bao gồm cách thiết lập cụm HA bằng cách sử dụng kubeadm (có lẽ không phải là cách thuận tiện nhất, tuy nhiên tôi đã có thể thiết lập và hoàn thành công việc). Như bạn có thể thấy trong ví dụ này chỉ v.v. IP của nút được trình bày trong cấu hình phù hợp với v.v. tài liệu.

Liên kết hữu ích:

• etcd - cờ cấu hình
• vvd - khả năng chịu lỗi