Tham gia Đăng nhập
Điểm:0
avatar Server

Gói Kubernetes bằng Wireguard

lá cờ us
TRW

Tôi có một kịch bản với nhiều nút khác nhau. Một số có IPv4 công khai, một số có IPv6, một số là ngăn xếp kép. Vì vậy, tôi đã tạo một mạng bảo vệ dây (10.11.12.0/24), để bất kỳ đồng nghiệp nào cũng có thể tiếp cận bất kỳ mạng nào khác bên trong mạng riêng liên quan đến ngăn xếp IP và vị trí. Tôi muốn xây dựng một Kubernetes trên các mạng bảo vệ dây này.

Tôi đã xây dựng một cụm thử nghiệm nhỏ ...

nút ip công khai wireguard ip
vm1 192.168.10.10 10.11.12.10
vm2 192.168.10.11 10.11.12.11
vm3 192.168.10.12 10.11.12.12
...

... trong sân chơi địa phương của tôi với kubeadm 1.23.5 dựa trên docker.io (mặc định của debian):

vm01> kubeadm init --apiserver-advertise-address=10.11.12.10 --pod-network-cidr=10.20.0.0/16
vm01> áp dụng kubectl -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/k8s-manifests/kube-flannel-rbac.yml
vm01> áp dụng kubectl -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
...
tất cả các nút> kubeadm tham gia 10.11.12.10:6443 --token ... --Discovery-token-ca-cert-hash sha256:...
...
vm01> nâng cấp helm --install ingress-nginx ingress-nginx --repo https://kubernetes.github.io/ingress-nginx --namespace ingress-nginx --create-namespace

Khi tôi nhìn từ vm1 đến vm2 qua tcpdump -n máy chủ 192.168.10.11, Tôi chỉ có thể thấy lưu lượng thông qua các gói UDP bảo vệ dây. Khỏe...

Sau đó, tôi đã xác định Triển khai đơn giản, Dịch vụ, ClusterIP, Ingress và nó đã được triển khai

---
apiVersion: ứng dụng/v1
loại: Triển khai
metadata:
  tên: kubernetes-tutorial-triển khai
thông số kỹ thuật:
  bản sao: 2
  bộ chọn:
    trận đấuNhãn:
      ứng dụng: kubernetes-tutorial-triển khai
  mẫu:
    metadata:
      nhãn:
        ứng dụng: kubernetes-tutorial-triển khai
    thông số kỹ thuật:
      hộp đựng:
      - tên: kubernetes-tutorial-application
        hình ảnh: auth0blog/kubernetes-tutorial
        cổng:
          - Cảng container: 3000
---
phiên bản api: v1
loại: Dịch vụ
metadata:
  tên: kubernetes-tutorial-cluster-ip
thông số kỹ thuật:
  cổng:
  - cổng: 80
    giao thức: TCP
    cổng mục tiêu: 3000
  bộ chọn:
    ứng dụng: kubernetes-tutorial-triển khai
  loại: Cụm IP
---
apiVersion: mạng.k8s.io/v1
loại: Xâm nhập
metadata:
  tên: kubernetes-tutorial-ingress
thông số kỹ thuật:
  ingressClassName: nginx
  quy tắc:
  - máy chủ: test.example.com
    http:
      con đường:
      - con đường: /
        pathType: Tiền tố
        phụ trợ:
          dịch vụ:
            tên: kubernetes-tutorial-cluster-ip
            Hải cảng:
              số: 80

Khi tôi kiểm tra bằng trình duyệt, tôi nhận được phản hồi. Nhưng mà...

Phản hồi rất chậm (tôi có thể xác nhận thông qua một lần cuộn tròn đơn giản, phải mất 10-20 giây để dịch vụ phản hồi một yêu cầu - điều đó thật chậm đối với việc triển khai đơn giản như vậy.

Khi tôi xem qua tcpdump, tôi thấy lưu lượng truy cập bên ngoài mạng bảo vệ dây, điều này lạ hơn nhiều.

18:39:18.341836 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 128
18:39:18.344382 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 176
18:39:18.344563 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, chiều dài 1452
18:39:18.344571 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, chiều dài 1452
18:39:18.344572 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, chiều dài 1452
18:39:18.344573 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 96
18:39:18.344711 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:18.344711 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:18.344711 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:20.566833 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 128
18:39:20.566833 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 592
18:39:20.567003 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 96
18:39:20.570978 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 128
18:39:20.571309 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:20.572538 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 176
18:39:20.572566 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 592
18:39:20.572764 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:20.572764 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:23.540401 ARP, Yêu cầu ai có 192.168.10.11 cho 192.168.10.10, độ dài 28
18:39:23.540646 ARP, Trả lời 192.168.10.11 is-at 7a:1d:d9:fc:fa:eb, độ dài 28
18:39:23.608703 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.0.5.55222 > 10.20.4.2.3000: Flags [S], seq 3011291899, win 64860, tùy chọn [mss 1410,sackOK,TS val 2531657982 ecr 0,nop,wscale 7], độ dài 0
18:39:23.609071 IP 192.168.10.11.59205 > 192.168.10.10.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.4.2.3000 > 10.20.0.5.55222: Flags [S.], seq 1444377380, ack 3011291900, win 64308, tùy chọn [mss 1410,sackOK,TS val 2546470618 ecr 2531657982,nop,wscale 0 7]
18:39:23.609112 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.0.5.55222 > 10.20.4.2.3000: Flags [.], ack 1, win 507, tùy chọn [nop,nop,TS val 2531657983 ecr 2546470618], độ dài 0
18:39:23.609140 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.0.5.55222 > 10.20.4.2.3000: Flags [P.], seq 1:749, ack 1, win 507, tùy chọn [nop,nop,TS val 2531657983 ecr 2546470618], độ dài 748
18:39:23.609370 IP 192.168.10.11.59205 > 192.168.10.10.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.4.2.3000 > 10.20.0.5.55222: Flags [.], ack 749, win 501, tùy chọn [nop,nop,TS val 2546470618 ecr 2531657983], độ dài 0
18:39:23.610441 IP 192.168.10.11.36593 > 192.168.10.10.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.4.2.33592 > 10.20.0.2.53: 53349+ A? test.example.com.default.svc.cluster.local. (60)
18:39:23.610713 IP 192.168.10.10.58646 > 192.168.10.11.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.0.2.53 > 10.20.4.2.33592: 53349 NXDomain*- 0/1/0 (153)
18:39:23.611018 IP 192.168.10.11.32846 > 192.168.10.10.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.4.2.40077 > 10.20.0.2.53: 57710+ A? test.example.com.svc.cluster.local. (52)
18:39:23.611134 IP 192.168.10.10.41066 > 192.168.10.11.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.0.2.53 > 10.20.4.2.40077: 57710 NXDomain*- 0/1/0 (145)
18:39:23.611427 IP 192.168.10.11.51546 > 192.168.10.10.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.4.2.59046 > 10.20.0.3.53: 18849+ A? test.example.com.cluster.local. (48)
18:39:23.611567 IP 192.168.10.10.39789 > 192.168.10.11.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.0.3.53 > 10.20.4.2.59046: 18849 NXDomain*- 0/1/0 (141)
18:39:23.611831 IP 192.168.10.11.50067 > 192.168.10.10.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.4.2.34442 > 10.20.0.3.53: 49768+ A? kiểm tra.example.com.sol.system. (45)
18:39:25.329861 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 208
18:39:25.330138 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:25.613106 IP 192.168.10.10.52981 > 192.168.10.11.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.0.3.53 > 10.20.4.2.34442: 49768 ServFail- 0/0/0 (45)
18:39:25.613542 IP 192.168.10.11.33388 > 192.168.10.10.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.4.2.59146 > 10.20.0.3.53: 49768+ A? kiểm tra.example.com.sol.system. (45)
18:39:27.021478 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 224
18:39:27.021876 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:27.614533 IP 192.168.10.10.48157 > 192.168.10.11.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.0.3.53 > 10.20.4.2.59146: 49768 ServFail- 0/0/0 (45)
18:39:27.614906 IP 192.168.10.11.52721 > 192.168.10.10.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.4.2.33596 > 10.20.0.3.53: 32196+ A? kiểm tra.example.com. (34)
18:39:28.500696 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 128
18:39:28.503146 ​​IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 256
18:39:28.503158 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, chiều dài 1452
18:39:28.503159 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, chiều dài 1452
18:39:28.503161 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, chiều dài 1452
18:39:28.503162 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:28.627012 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 128
18:39:28.627292 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 128
18:39:28.627636 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:29.615282 IP 192.168.10.10.52590 > 192.168.10.11.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.0.3.53 > 10.20.4.2.33596: 32196 ServFail- 0/0/0 (34)
18:39:29.615672 IP 192.168.10.11.37175 > 192.168.10.10.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.4.2.50957 > 10.20.0.3.53: 32196+ A? kiểm tra.example.com. (34)
18:39:29.877400 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 192
18:39:29.877722 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:30.898243 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 128
18:39:30.898243 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 592
18:39:30.898330 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 96
18:39:30.902126 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 128
18:39:30.902362 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:30.903556 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 176
18:39:30.903696 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 592
18:39:30.904023 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:30.904023 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96
18:39:31.617136 IP 192.168.10.10.38253 > 192.168.10.11.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.0.3.53 > 10.20.4.2.50957: 32196 ServFail- 0/0/0 (34)
18:39:31.619778 IP 192.168.10.11.59205 > 192.168.10.10.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.4.2.3000 > 10.20.0.5.55222: Flags [P.], seq 1:114, ack 749, win 501, tùy chọn [nop,nop,TS val 2546478629 ecr 2531657983], độ dài 113
18:39:31.619911 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, cờ [I] (0x08), lớp phủ 0, phiên bản 1
IP 10.20.0.5.55222 > 10.20.4.2.3000: Flags [.], ack 114, win 507, tùy chọn [nop,nop,TS val 2531665993 ecr 2546478629], độ dài 0
18:39:33.434382 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 128
18:39:33.434488 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 96
18:39:33.434537 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, độ dài 128
18:39:33.434860 ​​IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, độ dài 96

Lý do có thể là gì, tại sao phản hồi quá chậm trong mạng LAN.Có phải do định tuyến sai đến IP "công khai" thay vì sử dụng IP bảo vệ dây không? Có thể định cấu hình Kubernetes để sử dụng địa chỉ bảo vệ dây cho cổng 8472 không?

60
0 + 0
Điểm:0
avatar Server
lá cờ us
TRW

Ok, tôi tìm thấy giải pháp.

  1. Tôi đã thử cài đặt cụm mà không có Wireguard. Và trong trường hợp đó ứng dụng auth0blog/kubernetes-tutorial cũng bị treo nhiều giây. Vì vậy, tôi đã chuyển sang một dịch vụ nginx http đơn giản và dịch vụ đó phản hồi trong thời gian dự kiến.
  2. Cổng 8472 được sử dụng bởi flannel. Có sự cố trên Github (từ năm 2018...) cho thấy rằng nó sử dụng giao diện mạng bên ngoài theo mặc định. Nó phải được cấu hình để sử dụng giao diện wireguard. Nhìn thấy https://github.com/rancher/rancher/issues/15133 và https://github.com/rancher/rancher/issues/14721#issuecomment-417913067

Vì vậy - thực sự đây ít nhiều là một bản sao của https://stackoverflow.com/questions/66449289/is-there-any-way-to-bind-k3s-flannel-to-another-interface

Và bởi vì tôi chưa quen với Kubernetes nên tôi đã tự hỏi làm thế nào để thay đổi giá trị đó trong các lệnh đã cho của mình (xem câu hỏi).Tài liệu chỉ nói về các tham số nhưng không nói cách thức và vị trí đặt nó. Tôi đã nhìn xung quanh và tìm thấy https://stackoverflow.com/questions/47845739/conforming-flannel-to-use-a-non-default-interface-in-kubernetes

Ở đó bạn có thể thấy rằng giải pháp là tải xuống flannel.yml và thêm tham số --iface=wg_k8s vào tập tin đó ở đúng vị trí. Ở phiên bản hiện tại (2022) nó ở dòng 200+.

0 + 0
lá cờ VietNam
Phan Văn Trường
Câu hỏi này là trong các ngôn ngữ 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.