Tôi đang định cấu hình etcd để khởi động bằng cách sử dụng tính năng khám phá DNS nhưng nó báo rằng máy chủ bị định cấu hình sai và có vẻ như đang truy vấn sai cổng và các bản ghi SRV có vẻ không đúng.
Xin vui lòng bạn có thể xem lại dưới đây và xem câu hỏi của tôi ở dưới cùng của bài viết này?
thông số kỹ thuật
tên miền gốc: vvd.ksone
bản ghi SRV máy chủ:
_etcd-server-ssl._tcp.etcd.ksone SRV Đơn giản -
0 0 2380 vvd2.ksone
0 0 2380 vvd1.ksone
bản ghi SRV của khách hàng:
_etcd-client-ssl._tcp.etcd.ksone SRV Đơn giản -
0 0 2379 vvd2.ksone
0 0 2379 vvd1.ksone
sử dụng TLS: Thật
hệ điều hành:
[fedora@ip-10-0-0-245 ~]$ uname
Linux
[fedora@ip-10-0-0-245 ~]$ cat /etc/os-release
TÊN=Fedora
VERSION="24 (Hai mươi bốn)"
ID = mũ phớt
VERSION_ID=24
PRETTY_NAME="Fedora 24 (Hai mươi bốn)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:24"
HOME_URL="https://fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=24
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=24
PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy
phiên bản vvdctl
[fedora@ip-10-0-0-245 ~]$ etcdctl --version
v.v.dctl phiên bản 2.2.5
Danh sách thành viên
Tôi cố gắng liệt kê các thành viên bằng lệnh bên dưới và gặp lỗi sau:
bash-4.3# etcdctl --ca-file /etc/etcd/ca.pem --key-file /etc/etcd/kubernetes-key.pem --cert-file /etc/etcd/kubernetes.pem --Discovery- srv etcd.ksone --debug danh sách thành viên
bắt đầu đồng bộ cụm bằng điểm cuối(https://etcd1.ksone.:2380,https://etcd2.ksone.:2380)
Lệnh cURL: curl -X GET https://etcd1.ksone.:2380/v2/members
có điểm cuối() sau khi đồng bộ hóa
Cụm-Điểm cuối:
Lệnh cURL: curl -X NHẬN /v2/thành viên
máy khách: cụm etcd không khả dụng hoặc bị định cấu hình sai
Sức khỏe cụm
Tương tự, tôi có thể truy vấn tình trạng cụm bằng lệnh và đầu ra sau:
bash-4.3# etcdctl --ca-file /etc/etcd/ca.pem --key-file /etc/etcd/kubernetes-key.pem --cert-file /etc/etcd/kubernetes.pem --Discovery- srv etcd.ksone --debug cluster-sức khỏe
Điểm cuối cụm: https://etcd1.ksone.:2380, https://etcd2.ksone.:2380
===> LƯU Ý: NÓ THỬ (KHÔNG CHÍNH XÁC?) TRÊN CỔNG 2380 ( MÁY CHỦ) Lệnh cURL: curl -X GET https://etcd1.ksone.:2380/v2/members
cụm có thể không lành mạnh: không thể liệt kê các thành viên
Lỗi: mã trạng thái không mong muốn 404
kỷ lục CHXHCNVN
Tôi đã cấu hình các bản ghi SRV như sau
- liệt kê SRV cho tên miền gốc, tức là "etcd.ksone" (kết quả dự kiến -> sẽ hiển thị toàn bộ bản ghi SRV nhưng không trả về gì?):
đào +noall +trả lời SRV vvd.ksone
==> <bảng điều khiển không hiển thị đầu ra - trống!>
- liệt kê rõ ràng SRV cho máy chủ:
# đào +noall +trả lời SRV _etcd-server-ssl._tcp.etcd.ksone
_etcd-server-ssl._tcp.etcd.ksone. 33 TRONG CHXHCNVN 0 0 2380 etcd2.ksone.
_etcd-server-ssl._tcp.etcd.ksone. 33 TRONG CHXHCNVN 0 0 2380 etcd1.ksone.
- liệt kê rõ ràng SRV cho khách hàng:
/ # đào +noall +trả lời SRV _etcd-client-ssl._tcp.etcd.ksone
_etcd-client-ssl._tcp.etcd.ksone. 300 TRONG CHXHCNVN 0 0 2379 etcd1.ksone.
_etcd-client-ssl._tcp.etcd.ksone. 300 TRONG CHXHCNVN 0 0 2379 etcd2.ksone.
Hãy thử điểm cuối Máy khách một cách rõ ràng (THÀNH CÔNG, nhưng không thực sự sử dụng khám phá dns!)
bash-4.3# etcdctl --ca-file /etc/etcd/ca.pem --key-file /etc/etcd/kubernetes-key.pem --cert-file /etc/etcd/kubernetes.pem --debug - -điểm cuối https://etcd1.ksone:2379 sức khỏe cụm
Điểm cuối cụm: https://etcd1.ksone:2379
Lệnh cURL: curl -X GET https://etcd1.ksone:2379/v2/members
thành viên 499073e22ac73562 khỏe mạnh: nhận được kết quả khỏe mạnh từ https://etcd1.ksone:2379
thành viên b98d4fc780a787fe khỏe mạnh: nhận được kết quả khỏe mạnh từ https://etcd2.ksone:2379
cụm khỏe mạnh
etcd Cài đặt dịch vụ
trạng thái systemctl, v.v.
_ etcd.service - etcd
Đã tải: đã tải (/etc/systemd/system/etcd.service; đã bật; giá trị đặt sẵn của nhà cung cấp: đã tắt)
Hoạt động: hoạt động (đang chạy) kể từ Chủ Nhật 2021-08-01 07:17:39 UTC; 1 giờ 23 phút trước
Tài liệu: https://github.com/coreos
PID chính: 2363 (etcd)
Nhiệm vụ: 7 (giới hạn: 512)
Nhóm C: /system.slice/etcd.service
__2363 /usr/bin/etcd --name etcd1.ksone --Discovery-srv=etcd.ksone --initial-advertise-peer-urls https://etcd1.ksone:2380 --initial-cluster-token etcd-cluster -0 --initial-cluster-state new --advertise-client-urls https://etcd1.ksone:2379 --listen-client-urls https://etcd1.ksone:2379,http://127.0.0.1 :2379 --listen-peer-urls https://etcd1.ksone:2380 --data-dir=/var/lib/etcd/data --cert-file=/etc/etcd/kubernetes.pem --key- tệp=/etc/etcd/kubernetes-key.pem --peer-cert-file=/etc/etcd/kubernetes.pem --peer-key-file=/etc/etcd/kubernetes-key.pem --trusted- ca-file=/etc/etcd/ca.pem --peer-trusted-ca-file=/etc/etcd/ca.pem
01 tháng 8 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 trở thành ứng cử viên ở nhiệm kỳ 41
Ngày 01 tháng 8 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 đã nhận được phiếu bầu từ 499073e22ac73562 ở nhiệm kỳ 41
Ngày 01 tháng 8 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 [logterm: 1, index: 2] đã gửi yêu cầu bỏ phiếu tới b98d4fc780a787fe tại nhiệm kỳ 41
Ngày 01 tháng 8 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 đã nhận được phiếu bầu từ b98d4fc780a787fe ở kỳ 41
Ngày 01 tháng 8 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 [q:2] đã nhận được 2 phiếu bầu và 0 phiếu từ chối
Ngày 01 tháng 8 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 trở thành lãnh đạo ở nhiệm kỳ 41
Ngày 01 tháng 8 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: bè.node: 499073e22ac73562 được bầu làm lãnh đạo 499073e22ac73562 tại nhiệm kỳ 41
Ngày 01 tháng 8 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: đã xuất bản {Name:etcd1.ksone ClientURLs:[https://etcd1.ksone:2379 ]} đến cụm 1c370848b4697ef2
01 tháng 8 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: thiết lập phiên bản cụm ban đầu thành 2.2
01 tháng 8 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: đặt phiên bản cụm ban đầu thành 2.2
Tóm tắt các quan sát
- Cơ chế khám phá trên ứng dụng khách etcd dường như không hoạt động, bằng chứng là lỗi ở trên, tức là
cụm không khả dụng hoặc bị định cấu hình sai hoặc ``Lỗi: mã trạng thái không mong muốn 404```.
- Nhật ký gỡ lỗi dường như chỉ ra rằng nó đang cố kết nối với cổng ngang hàng, tức là 2380 thay vì cổng máy khách, tức là 2379.
- Tôi chỉ có thể làm cho nó hoạt động bằng cách đặt rõ ràng công tắc điểm cuối thành cổng 2379
- Truy vấn SRV trên miền gốc dường như không hoạt động chính xác, tức là nó trả về kết quả trống (không có đầu ra)
trạng thái systemctl, v.v. dường như chỉ ra rằng điểm cuối đã được cấu hình đúng cho lệnh khởi động etcd.
câu hỏi
- Làm cách nào để truy vấn chính xác các bản ghi và vấn đề có thể xảy ra (nếu có) với cấu hình dns SRV là gì?
- Tại sao là vvdctl
--Discovery-srv chuyển đổi không hoạt động - Tôi hy vọng nó sẽ khám phá đúng cổng, tức là 2379 và không báo cáo bất kỳ lỗi nào.
- Có phải etcd được cho là cân bằng tải không? Có một điểm cuối duy nhất mà tôi có thể truy vấn không? [Tại sao] khách hàng có quyền chọn điểm cuối không? Tôi có nên định cấu hình bộ cân bằng tải trên giàn khoan etcd của mình không?
Cảm ơn nhiều!
