Điểm:1

các nhóm trong kubernetes không thể giao tiếp với các nhóm khác và máy chủ cụm bên ngoài

lá cờ vn

Tôi có 2 nút chính và 3 nút công nhân và một proxy HA cho controlePlan, Tôi có nhiều java microservice giao tiếp với nhau và giao tiếp với DB hoặc KAFKA bên ngoài cụm kubernetes. truy cập mạng là bất kỳ đối với bất kỳ mở nào trong tất cả các máy chủ. Tôi tạo triển khai cho mọi dịch vụ siêu nhỏ. Nhưng khi tôi thực hiện vùng chứa, tôi không có kết nối tcp trên các cổng giữa các nhóm và DB hoặc KAFKA bên ngoài cụm kubernetes.

từ các máy chủ, tôi có telnet đến DB hoặc KAFKA Nhưng trong các nhóm chứa, tôi không truy cập được.

từ máy chủ:

[root@master1 ~]# telnet oracle.local 1521
Đang thử 192.198.10.30...
Đã kết nối với oracle.local.
Ký tự thoát là '^]'.
^C^CKết nối bị đóng bởi máy chủ nước ngoài.
[root@master1 ~]#

từ nhóm chẳng hạn busybux :

[root@master1 ~]# kubectl run -i --tty busybox --image=busybox --restart=Never -- sh
Nếu bạn không thấy dấu nhắc lệnh, hãy thử nhấn enter.
/ # điện thoại 192.168.10.30 1521
telnet: không thể kết nối với máy chủ từ xa (192.168.10.30): Đã hết thời gian kết nối

trạng thái cụm:

[root@master1 ~]# kubectl get node -o wide
TÊN TRẠNG THÁI VAI TRÒ TUỔI PHIÊN BẢN INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-PHIÊN BẢN CONTAINER-RUNTIME
master1.project.co Mặt phẳng điều khiển sẵn sàng,master 11d v1.22.2 192.168.10.1 <none> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
master2.project.co Mặt phẳng điều khiển sẵn sàng,master 11d v1.22.2 192.168.10.2 <none> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker1.project.co Sẵn sàng <none> 11d v1.22.2 192.168.10.3 <none> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker2.project.co Sẵn sàng <none> 11d v1.22.2 192.168.10.4 <none> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker3.project.co Sẵn sàng <none> 11d v1.22.2 192.168.10.5 <none> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9

mô tả pod busybox:

[root@master1 ~]# kubectl description pod busybox
Tên: busybox
Không gian tên: mặc định
Ưu tiên: 0
Nút: worker3.project.co/192.168.10.5
Thời gian bắt đầu: Sat, 02 Oct 2021 10:27:05 +0330
Nhãn: run=busybox
Chú thích: cni.projectcalico.org/containerID: 75d7222e8f402c68d9161a7b399df2de6b45e7194b2bb3b0b2730adbdac680c4
              cni.projectcalico.org/podIP: 192.168.205.76/32
              cni.projectcalico.org/podIPs: 192.168.205.76/32
Tình trạng: Đang chờ
địa chỉ IP:
IP: <không có>
Hộp đựng:
  hộp bận rộn:
    Mã vùng chứa:
    Hình ảnh: busybox
    Mã hình ảnh:
    Cổng: <không có>
    Cổng máy chủ: <none>
    lập luận:
      sh
    Trạng thái: Chờ đợi
      Lý do: Tạo vùng chứa
    Sẵn sàng: Sai
    Số lần khởi động lại: 0
    Môi trường: <không>
    gắn kết:
      /var/run/secrets/kubernetes.io/serviceaccount từ kube-api-access-69snv (ro)
Điều kiện:
  Loại Trạng thái
  Khởi tạo đúng
  Sẵn sàng Sai
  ContainerSẵn sàng Sai
  PodScheduled True
tập:
  kube-api-access-69snv:
    Loại: Dự kiến ​​(ổ chứa dữ liệu được đưa vào từ nhiều nguồn)
    Số giây hết hạn mã thông báo: 3607
    ConfigMapName: kube-root-ca.crt
    ConfigMapOptional: <nil>
    API hướng xuống: đúng
Lớp QoS: BestEffort
Bộ chọn nút: <none>
Dung sai: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Tồn tại trong 300 giây
Sự kiện:
  Nhập Lý do Tuổi từ Tin nhắn
  ---- ------ ---- ---- -------
  Bình thường Trình lập lịch trình mặc định của những năm 21 đã lên lịch Đã gán thành công mặc định/hộp bận cho worker3.project.co
  Kéo bình thường 20s kubelet Kéo hình ảnh "busybox"
Điểm:1
lá cờ de

Một số lý do có thể là nguyên nhân của điều đó. Tuy nhiên, nếu không có thông tin chi tiết phù hợp về cấu trúc mạng và cụm của bạn thì vấn đề này sẽ không được giải quyết, tuy nhiên, đây là một số ý tưởng:

  1. Kiểm tra nếu có bất kỳ Chính sách mạng áp dụng bằng cách thực hiện kubectl -n <không gian tên> nhận netpol. NetworkPolicies có thể hạn chế giao tiếp bên trong và bên ngoài cụm.
  2. Để một Pod chạy với máy chủ lưu trữ: đúng Tùy chọn (không phải được thực hiện trong sản xuất, giống như một thử nghiệm) và thử lại một số thử nghiệm kết nối (theo cả hai hướng).
  3. Kiểm tra xem mạng của cụm của bạn có được định cấu hình đúng không bằng cách theo dõi cuộc gọi mạng. Các bộ định tuyến có được cấu hình đúng cách và có thể được sử dụng bởi các ứng dụng trong cụm không?
  4. kiểm tra xem của bạn truy cập mạng là bất kỳ đối với bất kỳ mở nào trong tất cả các máy chủ tuyên bố là đúng, nó có thể là một vấn đề với cấu hình tường lửa.

Thưởng: Bạn dường như chỉ có 2 nút chính không có ý nghĩa gì cả nếu etcd đang chạy trong cụm Kubernetes (kubectl -n kube-system lấy nhóm | grep, v.v. sẽ hiển thị 2 nhóm nếu đúng như vậy). Có 2 thành viên etcd cung cấp cho bạn khả năng chịu lỗi chính xác giống như cụm 1 nút nhưng bạn đã lãng phí tài nguyên khi có một máy ảo khác chiếm bộ nhớ, cpu, v.v.. Cân nhắc tăng các nút chính của bạn lên 3 để có khả năng chịu lỗi là một nút. Luôn luôn phải có đa số của cụm etcd đang chạy. Hãy nhớ rằng phần lớn của 2 vẫn là 2.

Jcyber1 avatar
lá cờ vn
1-[root@master1 ~]# kubectl get netpol --all-namespaces Không tìm thấy tài nguyên nào 2-khi tôi sử dụng hostNetwork: đúng là sự cố đã được giải quyết, Nhưng telnet tới worker thành công, Telnet ra khỏi cụm thành công, cách telnet với tên máy chủ vì lịch trình là tự động Tôi không biết vùng chứa được triển khai trên máy chủ nào 4 - selinux và tường lửa bị vô hiệu hóa
F1ko avatar
lá cờ de
Nó xuất hiện như nó là số 3 sau đó. Mạng cụm của bạn dường như không sử dụng các cổng của bạn. Bạn có thể sử dụng số 2 như một giải pháp thay thế **tạm thời**. Bạn có thể sử dụng tính năng `nodeName` hoặc `nodeSelector` để quyết định nhóm sẽ chạy trên nút nào: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodename Cùng với đó, bạn có thể kết nối với nhóm bằng cách sử dụng tên máy chủ của nút mà nó đang chạy trên đó.
Jcyber1 avatar
lá cờ vn
với mạng máy chủ và sự cố nodeSelector đã được giải quyết, nhưng tôi không biết tại sao không có mạng máy chủ, tôi không thể nhìn thấy ngoài cụm. máy chủ không gặp sự cố nhưng nhóm không thể kết nối với các máy chủ khác

Đă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.