Điểm:0

Kết nối `kubectl` với máy chủ bị từ chối

lá cờ cn

Tôi đã theo dõi Kelsey Hightower's Kubernetes theo cách khó khăn hướng dẫn bạn cách thiết lập cụm k8s theo cách thủ công.

Đây là không phải đang chạy trên minikube - nó đang chạy trên một VPS từ xa.

Tôi đang ở bước thiết lập máy bay điều khiển k8s.

Tuy nhiên, khi cố gắng chạy kiểm tra sức khỏe trên kube-apiserver Tôi nhận được như sau:

$ thông tin cụm kubectl --kubeconfig admin.kubeconfig

Để tiếp tục gỡ lỗi và chẩn đoán các vấn đề về cụm, hãy sử dụng 'kết xuất thông tin cụm kubectl'.
Kết nối với máy chủ 127.0.0.1:6443 bị từ chối - bạn đã chỉ định đúng máy chủ hoặc cổng chưa?

Tôi không chắc bắt đầu gỡ lỗi từ đâu ở đây.

Cấu hình

Tất cả 3 dịch vụ k8s đang chạy:

systemctl status kube-apiserver kube-controller-manager kube-scheduler etcd

# => Tất cả 4 trả về: "đang hoạt động (đang chạy)"

Các kube-apiserver được cấu hình để bắt đầu với hệ thống:

 $ mèo /etc/systemd/system/kube-apiserver.service
[Đơn vị]
Mô tả=Máy chủ API Kubernetes
Tài liệu=https://github.com/kubernetes/kubernetes

[Dịch vụ]
ExecStart=/usr/local/bin/kube-apiserver \
  --advertise-address=$INTERNAL_IP_REDACTED \
  --allow-đặc quyền=true \
  --apiserver-count=3 \
  --audit-log-maxage=30 \
  --audit-log-maxbackup=3 \
  --audit-log-maxsize=100 \
  --audit-log-path=/var/log/audit.log \
  --authorization-mode=Nút,RBAC \
  --bind-address=0.0.0.0 \
  --client-ca-file=/var/lib/kubernetes/ca.pem \
  --enable-admission-plugins=NamespaceLifecycle,NodeRestriction,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota \
  --etcd-cafile=/var/lib/kubernetes/ca.pem \
  --etcd-certfile=/var/lib/kubernetes/kubernetes.pem \
  --etcd-keyfile=/var/lib/kubernetes/kubernetes-key.pem \
  --etcd-servers=https://10.240.0.10:2379,https://10.240.0.11:2379,https://10.240.0.12:2379 \
  --event-ttl=1h \
  --encryption-provider-config=/var/lib/kubernetes/encryption-config.yaml \
  --kubelet-certificate-authority=/var/lib/kubernetes/ca.pem \
  --kubelet-client-certificate=/var/lib/kubernetes/kubernetes.pem \
  --kubelet-client-key=/var/lib/kubernetes/kubernetes-key.pem \
  --runtime-config='api/all=true' \
  --service-account-key-file=/var/lib/kubernetes/service-account.pem \
  --service-account-signing-key-file=/var/lib/kubernetes/service-account-key.pem \
  --service-account-issuer=https://$EXTERNAL_IP_REDACTED:6443 \
  --service-cluster-ip-range=10.32.0.0/24 \
  --service-node-port-range=30000-32767 \
  --tls-cert-file=/var/lib/kubernetes/kubernetes.pem \
  --tls-private-key-file=/var/lib/kubernetes/kubernetes-key.pem \
  --v=2
Khởi động lại = khi thất bại
Khởi động lạiSec=5

[Cài đặt]
WantedBy=multi-user.target

Các kube-apiserver chắc chắn đang chạy và nghe trên cổng :6443

 $ lsof -iTCP -sTCP:LISTEN -n -P | grep 6443
kube-apis 989442 gốc 7u IPv6 9345693 0t0 TCP *:6443 (LẮNG NGHE)

Đây là quản trị viên.kubeconfig tệp được định cấu hình để tìm kiếm cụm tại 127.0.0.1:6443

phiên bản api: v1
cụm:
- cụm:
    chứng chỉ-cơ quan-dữ liệu: LS0tL...
    máy chủ: https://127.0.0.1:6443
  tên: kubernetes-the-hard-way
bối cảnh:
- bối cảnh:
    cụm: kubernetes-the-hard-way
    người dùng: quản trị viên
  tên: mặc định
bối cảnh hiện tại: mặc định
loại: Cấu hình
sở thích: {}
người dùng:
- tên: quản lý
  người dùng:
    dữ liệu chứng chỉ ứng dụng khách: LS0tLS1CRU...
    dữ liệu khóa khách hàng: LS0tLS1C ....

Có chứng chỉ SSL được cung cấp (được tạo trước đó trong hướng dẫn Kubernetes)

$ ls -hlt /var/lib/kubernetes/ca*
-rw------- 1 gốc gốc 1,7K 18 tháng 12 00:56 /var/lib/kubernetes/ca-key.pem
-rw-r--r-- 1 root root 1,3K 18 tháng 12 00:56 /var/lib/kubernetes/ca.pem

Cuối cùng, NGINX cũng được cấu hình để chuyển hướng cổng 80 giao thông đến điểm cuối kiểm tra sức khỏe

$ cat /etc/nginx/sites-available/kubernetes.default.svc.cluster.local
người phục vụ {
  nghe 80;
  server_name kubernetes.default.svc.cluster.local;

  vị trí /healthz {
     proxy_pass https://127.0.0.1:6443/healthz;
     proxy_ssl_trusted_certificate /var/lib/kubernetes/ca.pem;
  }
}

Như đã đề cập ở trên, tôi không thực sự thấy điều gì sai và Tôi không biết nơi nào khác để bắt đầu điều tra.

Cảm ơn bạn!

lá cờ jp
Bạn có đang chạy `kubectl` trên cùng một máy chủ mà `kube-apiserver` đang chạy không?
abhchand avatar
lá cờ cn
@AlexD - đúng, tôi đang chạy nó trên cùng một Máy chủ.
lá cờ jp
kiểm tra đầu ra của `env |grep -i proxy`.
Rajesh Dutta avatar
lá cờ br
Giá trị của INTERNAL_IP_REDACTED là gì? Tôi hỏi điều này vì tôi muốn đảm bảo rằng bạn đang gửi yêu cầu đến đúng mục tiêu cũng được đưa vào danh sách cho phép trong chứng chỉ máy chủ.
abhchand avatar
lá cờ cn
@RajeshDutta rằng dòng được sắp xếp lại là `--advertise-address=10.132.0.5`. IP nội bộ được xác định từ `ifconfig`. Cảm ơn!
abhchand avatar
lá cờ cn
@AlexD không có đầu ra nào được trả về từ `env | grep -i proxy`. Cảm ơn!
Rajesh Dutta avatar
lá cờ br
@abhchand 10.132.0.5 là địa chỉ IP nội bộ và tôi nghĩ địa chỉ này được lấy từ phạm vi mạng POD. Cố gắng ping ip này từ nút mà bạn đang thử lệnh kubectl. Tôi nghi ngờ bạn sẽ nhận được một phản ứng. Nếu bạn muốn truy cập nút này bên ngoài nút chính thì bạn cần có bộ cân bằng tải giao diện người dùng hoặc bạn cần quảng cáo máy chủ kube-api bằng cách sử dụng IP nút (với điều kiện địa chỉ IP đó phải được đề cập trong chứng chỉ máy chủ).
Điểm:0
lá cờ cn

Tôi đã làm theo hướng dẫn tương tự từng bước để tạo lại quá trình triển khai.

Tôi thấy rằng bạn có thể đang chạy lệnh bên ngoài bộ điều khiển vm.

Vui lòng đưa ra lệnh sau để đăng nhập vào bộ điều khiển vm:

bộ điều khiển ssh tính toán gcloud-0

Sau đó, thử lại lệnh cluster-info

thông tin cụm kubectl --kubeconfig admin.kubeconfig

Đây là đầu ra của tôi khi làm bài kiểm tra.

Ví dụ từ bộ điều khiển-1 VM

LỆNH CHẠY BÊN TRONG CONTROLLER-1 VM

xxxxxxx_ayaladeltoro@controller-1:~$ kubectl cluster-info --kubeconfig admin.kubeconfig
Mặt phẳng điều khiển Kubernetes đang chạy tại https://127.0.0.1:6443
 
Để tiếp tục gỡ lỗi và chẩn đoán các vấn đề về cụm, hãy sử dụng 'kết xuất thông tin cụm kubectl'.
infosys_ayaladeltoro@controller-1:~$ curl -H "Máy chủ: kubernetes.default.svc.cluster.local" -i http://127.0.0.1/healthz
HTTP/1.1 200 OK
Máy chủ: nginx/1.18.0 (Ubuntu)
Ngày: Thứ Sáu, ngày 24 tháng 12 năm 2021 18:57:54 GMT
Loại nội dung: văn bản/đồng bằng; bộ ký tự = utf-8
Độ dài nội dung: 2
Kết nối: giữ nguyên
Kiểm soát bộ đệm: không có bộ đệm, riêng tư
X-Content-Type-Options: nosniff
X-Kubernetes-Pf-Flowschema-Uid: 88df1f3d-a43f-4f2d-b2b6-661e0cd190f2
X-Kubernetes-Pf-Prioritylevel-Uid: cd1dd298-6e5e-4091-aac6-baf7c816ba6b

BỘ ĐIỀU KHIỂN THOÁT-1 VM

xxxxxxx_ayaladeltoro@controller-1:~$ thoát
logoutKết nối với 34.83.87.134 đã đóng.

CHẠY LỆNH TỪ VM CLOUD SHELL

xxxxxxx_ayaladeltoro@cloudshell:~ (ayaladeltoro-training-project)$ kubectl cluster-info --kubeconfig admin.kubeconfig
Để tiếp tục gỡ lỗi và chẩn đoán các sự cố cụm, hãy sử dụng 'kết xuất thông tin cụm kubectl'. Kết nối với máy chủ 127.0.0.1:6443 đã bị từ chối - bạn đã chỉ định đúng máy chủ hoặc cổng chưa?

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.