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

kube-proxy not working for service cluster IPs

lá cờ es
derabbink

I installed a k8s 1.23.3 cluster on four raspberry pi's running raspberrypi OS 11 (bullseye) arm64; mostly by following this guide.
The gist of it is that the control plane was created using this command

kubeadm init --token={some_token} --kubernetes-version=v1.23.3 --pod-network-cidr=10.1.0.0/16 --service-cidr=10.11.0.0/16 --control-plane-endpoint=10.0.4.16 --node-name=rpi-1-1

I then created my own kube-verify namespace, put a deployment of the echo-server into it, and created a service for it.

However, I cannot reach the service's cluster IP from any of the nodes. Why? Requests simply time out, while requests to the pod's cluster IP work fine.
I suspect my kube-proxy is not working as it should. Below is what I investigated so far.

$ kubectl get services -n kube-verify -o=wide

NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE   SELECTOR
echo-server   ClusterIP   10.11.213.180   <none>        8080/TCP   24h   app=echo-server

$ kubectl get pods -n kube-system -o=wide

NAME                              READY   STATUS    RESTARTS      AGE   IP          NODE      NOMINATED NODE   READINESS GATES
coredns-64897985d-47gpr           1/1     Running   1 (69m ago)   41h   10.1.0.5    rpi-1-1   <none>           <none>
coredns-64897985d-nf55w           1/1     Running   1 (69m ago)   41h   10.1.0.4    rpi-1-1   <none>           <none>
etcd-rpi-1-1                      1/1     Running   2 (69m ago)   41h   10.0.4.16   rpi-1-1   <none>           <none>
kube-apiserver-rpi-1-1            1/1     Running   2 (69m ago)   41h   10.0.4.16   rpi-1-1   <none>           <none>
kube-controller-manager-rpi-1-1   1/1     Running   2 (69m ago)   41h   10.0.4.16   rpi-1-1   <none>           <none>
kube-flannel-ds-5467m             1/1     Running   1 (69m ago)   28h   10.0.4.17   rpi-1-2   <none>           <none>
kube-flannel-ds-7wpvz             1/1     Running   1 (69m ago)   28h   10.0.4.18   rpi-1-3   <none>           <none>
kube-flannel-ds-9chxk             1/1     Running   1 (69m ago)   28h   10.0.4.19   rpi-1-4   <none>           <none>
kube-flannel-ds-x5rvx             1/1     Running   1 (69m ago)   29h   10.0.4.16   rpi-1-1   <none>           <none>
kube-proxy-8bbjn                  1/1     Running   1 (69m ago)   28h   10.0.4.17   rpi-1-2   <none>           <none>
kube-proxy-dw45d                  1/1     Running   1 (69m ago)   28h   10.0.4.18   rpi-1-3   <none>           <none>
kube-proxy-gkkxq                  1/1     Running   2 (69m ago)   41h   10.0.4.16   rpi-1-1   <none>           <none>
kube-proxy-ntl5w                  1/1     Running   1 (69m ago)   28h   10.0.4.19   rpi-1-4   <none>           <none>
kube-scheduler-rpi-1-1            1/1     Running   2 (69m ago)   41h   10.0.4.16   rpi-1-1   <none>           <none>

$ kubectl logs kube-proxy-gkkxq -n kube-system

I0220 13:52:02.281289       1 node.go:163] Successfully retrieved node IP: 10.0.4.16
I0220 13:52:02.281535       1 server_others.go:138] "Detected node IP" address="10.0.4.16"
I0220 13:52:02.281610       1 server_others.go:561] "Unknown proxy mode, assuming iptables proxy" proxyMode=""
I0220 13:52:02.604880       1 server_others.go:206] "Using iptables Proxier"
I0220 13:52:02.604966       1 server_others.go:213] "kube-proxy running in dual-stack mode" ipFamily=IPv4
I0220 13:52:02.605026       1 server_others.go:214] "Creating dualStackProxier for iptables"
I0220 13:52:02.605151       1 server_others.go:491] "Detect-local-mode set to ClusterCIDR, but no IPv6 cluster CIDR defined, , defaulting to no-op detect-local for IPv6"
I0220 13:52:02.606905       1 server.go:656] "Version info" version="v1.23.3"
W0220 13:52:02.614777       1 sysinfo.go:203] Nodes topology is not available, providing CPU topology
I0220 13:52:02.619535       1 conntrack.go:52] "Setting nf_conntrack_max" nf_conntrack_max=131072
I0220 13:52:02.620869       1 conntrack.go:100] "Set sysctl" entry="net/netfilter/nf_conntrack_tcp_timeout_close_wait" value=3600
I0220 13:52:02.660947       1 config.go:317] "Starting service config controller"
I0220 13:52:02.661015       1 shared_informer.go:240] Waiting for caches to sync for service config
I0220 13:52:02.662669       1 config.go:226] "Starting endpoint slice config controller"
I0220 13:52:02.662726       1 shared_informer.go:240] Waiting for caches to sync for endpoint slice config
I0220 13:52:02.762734       1 shared_informer.go:247] Caches are synced for service config 
I0220 13:52:02.762834       1 shared_informer.go:247] Caches are synced for endpoint slice config

What I'm noticing here is that the Nodes topology is not available, so I dug into the kube-proxy config some more, but nothing stands out to me.
If there is indeed an issue with the nodes topology in my cluster, please direct me towards some resources on how to troubleshoot this, as I could not find anything meaningful based on this error message.

$ kubectl describe configmap kube-proxy -n kube-system

Name:         kube-proxy
Namespace:    kube-system
Labels:       app=kube-proxy
Annotations:  kubeadm.kubernetes.io/component-config.hash: sha256:edce433d45f2ed3a58ee400690184ad033594e8275fdbf52e9c8c852caa7124d

Data
====
config.conf:
----
apiVersion: kubeproxy.config.k8s.io/v1alpha1
bindAddress: 0.0.0.0
bindAddressHardFail: false
clientConnection:
  acceptContentTypes: ""
  burst: 0
  contentType: ""
  kubeconfig: /var/lib/kube-proxy/kubeconfig.conf
  qps: 0
clusterCIDR: 10.1.0.0/16
configSyncPeriod: 0s
conntrack:
  maxPerCore: null
  min: null
  tcpCloseWaitTimeout: null
  tcpEstablishedTimeout: null
detectLocalMode: ""
enableProfiling: false
healthzBindAddress: ""
hostnameOverride: ""
iptables:
  masqueradeAll: false
  masqueradeBit: null
  minSyncPeriod: 0s
  syncPeriod: 0s
ipvs:
  excludeCIDRs: null
  minSyncPeriod: 0s
  scheduler: ""
  strictARP: false
  syncPeriod: 0s
  tcpFinTimeout: 0s
  tcpTimeout: 0s
  udpTimeout: 0s
kind: KubeProxyConfiguration
metricsBindAddress: ""
mode: ""
nodePortAddresses: null
oomScoreAdj: null
portRange: ""
showHiddenMetricsForVersion: ""
udpIdleTimeout: 0s
winkernel:
  enableDSR: false
  networkName: ""
  sourceVip: ""
kubeconfig.conf:
----
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    server: https://10.0.4.16:6443
  name: default
contexts:
- context:
    cluster: default
    namespace: default
    user: default
  name: default
current-context: default
users:
- name: default
  user:
    tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token

BinaryData
====

Events:  <none>

$ kubectl -n kube-system exec kube-proxy-gkkxq cat /var/lib/kube-proxy/kubeconfig.conf

kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    server: https://10.0.4.16:6443
  name: default
contexts:
- context:
    cluster: default
    namespace: default
    user: default
  name: default
current-context: default
users:
- name: default
  user:
    tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token

The mode defaults to iptables, as the logs above confirm.
I also have IP forwarding enabled on all nodes.

$ sudo sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
455
0 + 0
moonkotte avatar
lá cờ in
moonkotte
Có vẻ như đã xảy ra sự cố với các mạng con: cidr mạng nhóm là `10.1.0.0/16` và điểm cuối của mặt phẳng điều khiển thực sự nằm trong cidr mạng nhóm (vì đó là `10.1.0.4`). Ngoài ra, bạn có thay đổi `pod network cidr` khi cài đặt `flannel` không? Theo mặc định, nó sử dụng một `cidr` khác.
0
Hồi đáp
lá cờ es
derabbink
Tôi đã cài đặt flannel như sau: `kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.16.3/Documentation/kube-flannel.yml`. Lệnh `kubeadm init` của tôi có các cờ `--pod-network-cidr=10.1.0.0/16` và `--control-plane-endpoint=10.0.4.16`
0
Hồi đáp
moonkotte avatar
lá cờ in
moonkotte
Bạn có thể kiểm tra những gì bên trong cấu hình yaml của flannel. Bạn sẽ thấy rằng `"Mạng": "10.244.0.0/16"` được đặt thành mạng con khác với cách bạn khởi tạo cụm với tùy chọn `--pod-network-cidr=10.1.0.0/16`. Bạn có 2 tùy chọn để khắc phục: bạn có thể thay đổi mạng con trong yaml của flannel thành giống như `--pod-network-cidr=10.1.0.0/16` hoặc bạn có thể hủy cụm của mình và bắt đầu với cùng mạng con như trong yaml của flannel `"Mạng": "10.244.0.0/16"`
0
Hồi đáp
lá cờ es
derabbink
Cảm ơn. Điều này đã làm các trick. Nếu bạn thích, bạn có thể tạo câu trả lời và tôi đảm bảo sẽ chấp nhận nó. Và sau đó tôi có thể đề xuất một chỉnh sửa bổ sung tập lệnh để tự động viết lại tệp YAML đó bằng cách sử dụng `yq` và `jq`
0
Hồi đáp
moonkotte avatar
lá cờ in
moonkotte
Chắc chắn rồi, cảm ơn bạn. Bạn tôi @radekw sẽ đăng câu trả lời cho tôi vì anh ấy cần một số danh tiếng + anh ấy đã cho tôi gợi ý đó. Vui lòng chấp nhận nó và đề xuất chỉnh sửa.
0
Hồi đáp
Điểm:1
RadekW avatar Server
lá cờ cn
RadekW

vải nỉ có thể được cài đặt bằng cách áp dụng tệp kê khai từ kho lưu trữ.

Flannel có thể được thêm vào bất kỳ cụm Kubernetes hiện có nào mặc dù cách đơn giản nhất là thêm vải nỉ trước khi bắt đầu bất kỳ nhóm nào sử dụng mạng nhóm. Đối với Kubernetes v1.17+ áp dụng kubectl -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

Như bạn có thể thấy trong này khoai mỡ tệp theo mạng con mạng mặc định được đặt thành 10.244.0.0/16

  net-conf.json: |
    {
      "Mạng": "10.244.0.0/16",
      "Phụ trợ": {
        "Loại": "vxlan"
      }

khởi tạo kubeadm là một chỉ huy để khởi tạo một cụm yêu cầu chỉ định mạng con cho mạng cụm và mạng này cần phải giống với mạng con trong CNI của bạn. Bạn có thể kiểm tra thêm tùy chọn.

--pod-mạng-cidr chuỗi Chỉ định phạm vi địa chỉ IP cho mạng nhóm. Nếu được đặt, mặt phẳng điều khiển sẽ tự động phân bổ CIDR cho mọi nút.

Bạn đã khởi tạo một cụm với --pod-network-cidr=10.1.0.0/16 và mạng con của cụm của bạn được đặt thành khác với mạng con trong tệp yaml của tệp kê khai flannel "10.244.0.0/16" và đó là lý do tại sao nó không hoạt động.

Có hai tùy chọn để sửa nó:
Đầu tiên - thay đổi mạng con trong yaml của cấu hình flannel giống như nó đã được áp dụng khi cụm được khởi tạo, trong trường hợp này là --pod-network-cidr=10.1.0.0/16 (xem kịch bản bên dưới)
HOẶC
Thứ hai - nếu cụm dành cho mục đích thử nghiệm và chỉ mới được khởi tạo, thì hãy hủy cụm và bắt đầu với cùng một mạng con như yaml của cấu hình flannel "Mạng": "10.244.0.0/16"

Để tự động sửa đổi kube-flannel.yml, tập lệnh sau đây dựa trên yq và jq lệnh có thể được sử dụng:

#!/bin/bash

đầu vào=$1
đầu ra = $2

echo "Đang chuyển $input thành $output"

netconf=$( yq '. | select(.kind == "ConfigMap") | select(.metadata.name == "kube-flannel-cfg") | .data."net-conf.json"' "$input " | jq 'fromjson | .Network="10.1.0.0/16"' | yq -R '.' )
kube_flannel_cfg=$( yq --yaml-output '. | select(.kind == "ConfigMap") | select(.metadata.name == "kube-flannel-cfg") | .data."net-conf.json "='"$netconf" "$input") )
Everything_else=$( yq --yaml-output '. | select(.kind != "ConfigMap") | select(.metadata.name != "kube-flannel-cfg")' "$input" )
echo "$kube_flannel_cfg" >> "$output"
tiếng vang '---' >> "$output"
tiếng vang "$everything_else" >> "$output"
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.