คลัสเตอร์ HA kubernetes: kubeadm รีเซ็ตโดยไม่ตั้งใจบนโหนดหลัก 1 โหนด การเชื่อมต่อถูกปฏิเสธเมื่อเข้าร่วมคลัสเตอร์อีกครั้ง

Question

Score:1

Server

คลัสเตอร์ HA kubernetes: kubeadm รีเซ็ตโดยไม่ตั้งใจบนโหนดหลัก 1 โหนด การเชื่อมต่อถูกปฏิเสธเมื่อเข้าร่วมคลัสเตอร์อีกครั้ง

Cecil

26/12/22 05:42

ฉันได้ตั้งค่าคลัสเตอร์ kubernetes ด้วยโหนดหลัก 2 โหนด (cp01 192.168.1.42, cp02 192.168.1.46) และโหนดผู้ปฏิบัติงาน 4 โหนดใช้งานกับ haproxy และ Keepalived ทำงานเป็นพ็อดสแตติกในคลัสเตอร์ คลัสเตอร์ etcd ภายในด้วยเหตุผลงี่เง่าบางอย่าง ฉันเผลอ kubeadm reset -f บน cp01 ตอนนี้ฉันกำลังพยายามเข้าร่วมคลัสเตอร์อีกครั้งโดยใช้คำสั่ง kubeadm join แต่ฉันยังคงได้รับ dial tcp 192.168.1.49:8443: connect: การเชื่อมต่อถูกปฏิเสธโดยที่ 192.168.1.49 คือ LoadBalancer IP กรุณาช่วย! ด้านล่างนี้คือการกำหนดค่าปัจจุบัน

/etc/haproxy/haproxy.cfg บน cp02

ค่าเริ่มต้น
    หมดเวลาเชื่อมต่อ 10 วินาที
    ไคลเอ็นต์หมดเวลา 30 วินาที
    เซิร์ฟเวอร์หมดเวลา 30 วินาที
apiserver ส่วนหน้า
    ผูก *.8443
    โหมด tcp
    ตัวเลือก tcplog
    default_backend apiserver
apiserver แบ็กเอนด์
    ตัวเลือก httpchk GET /healthz
    http- ตรวจสอบสถานะคาดหวัง 200
    โหมด tcp
    ตัวเลือก ssl-hello-chk
    วงเวียนสมดุล
        เซิร์ฟเวอร์เริ่มต้นระหว่าง 10s downinter 5s ขึ้น 2 ตก 2 เริ่มช้า 60s maxconn 250 maxqueue 256 น้ำหนัก 100
        #server master01 192.168.1.42:6443 กาเครื่องหมาย ***อันที่ฉันรีเซ็ตโดยไม่ตั้งใจ
        เซิร์ฟเวอร์ master02 192.168.1.46:6443 ตรวจสอบ

/etc/keepalived/keepalived.conf บน cp02

global_defs {
    router_id LVS_DEVEL
    รากของ script_user
    enable_script_security
    ไดนามิก_อินเทอร์เฟซ
}
vrrp_script check_apiserver {
    สคริปต์ "/etc/keepalived/check_apiserver.sh"
    ช่วง 3
    น้ำหนัก -2
    ตก 10
    เพิ่มขึ้น 2
}
vrrp_instance VI_l {
    รัฐสำรอง
    อินเทอร์เฟซ ens192
    virtual_router_id51
    ลำดับความสำคัญ 101
    การรับรองความถูกต้อง {
        auth_type ผ่าน
        auth_pass ***
    }
    virtual_ipaddress {
        192.168.1.49/24
    }
    track_script {
        ตรวจสอบ_apiserver
    }
}

คลัสเตอร์ kubeadm-config

api เวอร์ชัน: v1
ข้อมูล:
    การกำหนดค่าคลัสเตอร์: |
        apiเซิร์ฟเวอร์:
            อาร์กิวเมนต์พิเศษ:
                โหมดการให้สิทธิ์: โหนด RBAC
            หมดเวลาสำหรับการควบคุมเครื่องบิน: 4m0s
        apiVersion: kubeadm.k8s.io/v1beta2
        ใบรับรองDir: /etc/kubernetes/pki
        ชื่อคลัสเตอร์: kubernetes
        controlPlaneEndpoint: 192.168.1.49:8443
        ตัวจัดการตัวควบคุม: {}
        DNS:
            ชนิด: CoreDNS
        ฯลฯ :
            ท้องถิ่น:
                dataDir: /var/lib/etcd
        ที่เก็บรูปภาพ: k8s.gcr.io
        ประเภท: ClusterConfiguration
        เวอร์ชันของ Kubernetes: v1.19.2
        เครือข่าย:
            DNSDomain: cluster.local
            podSubnet: 10.244.0.0/16
            serviceSubnet: 10.96.0.0/12
        กำหนดการ: {}
    สถานะคลัสเตอร์: |
        จุดสิ้นสุด API:
            cp02:
                ที่อยู่โฆษณา: 192.168.1.46
                ผูกพอร์ต: 6443
        apiVersion: kubeadm.k8s.io/v1beta2
        ชนิด: ClusterStatus
...

ข้อมูลคลัสเตอร์ kubectl

Kubernetes master ทำงานอยู่ที่ https://192.168.1.49:8443
KubeDNS ทำงานอยู่ที่ https://192.168.1.49:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

ข้อมูลเพิ่มเติม

คลัสเตอร์เริ่มต้นด้วย --upload-certs บน cp01
ฉันระบายและลบ cp01 ออกจากคลัสเตอร์

kubeadm เข้าร่วม --token ... --discovery-token-ca-cert-hash ... --control-plane --certificate-key ... คำสั่งที่ส่งคืน:

ขั้นตอนการดำเนินการข้อผิดพลาด preflight: ไม่สามารถดึง kubeadm-config ConfigMap: ไม่สามารถรับแผนที่ config: รับ "https://192.168.1.49:8443/api/v1/namespaces/kube-system/configmaps/kubeadm-config?timeout= 10s": กด tcp 192.168.1.49:8443: เชื่อมต่อ: การเชื่อมต่อถูกปฏิเสธ

kubectl exec -n kube-system -it etcd-cp02 -- etcdctl --endpoints=https://192.168.1.46:2379 --key=/etc/kubernetes/pki/etcd/peer.key --cert=/etc /kubernetes/pki/etcd/peer.crt --cacert=/etc/kubernetes/pki/etcd/ca.crt รายชื่อสมาชิก คืน:
```
..., เริ่มแล้ว, cp02, https://192.168.1.46:2380, https://192.168.1.46:2379, เท็จ
```

kubectl อธิบาย pod/etcd-cp02 -n kube-system:

...
รหัสคอนเทนเนอร์: นักเทียบท่า://...
รูปภาพ: k8s.gcr.io/etcd:3.4.13-0
รหัสรูปภาพ: นักเทียบท่า://...
พอร์ต: <ไม่มี>
พอร์ตโฮสต์: <ไม่มี>
สั่งการ:
  ฯลฯ
  --advertise-client-urls=https://192.168.1.46:2379
  --cert-file=/etc/kubernetes/pki/etcd/server.crt
  --client-cert-auth=true
  --data-dir=/var/lib/etcd
  --initial-advertise-peer-urls=https://192.168.1.46:2380
  --initial-cluster=cp01=https://192.168.1.42:2380,cp02=https://192.168.1.46:2380
  --initial-cluster-state=existing
  --key-file=/etc/kubernetes/pki/etcd/server.key
  --listen-client-urls=https://127.0.0.1:2379,https://192.168.1.46:2379
  --listen-metrics-urls=http://127.0.0.1:2381
  --listen-peer-urls=https://192.168.1.46:2380
  --ชื่อ=cp02
  --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
  --peer-client-cert-auth=true
  --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
  --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
  --snapshot-count=10,000
  --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
  ...

พยายามคัดลอกใบรับรองไปที่ cp01:/etc/kubernetes/pki ก่อนวิ่ง kubeadm เข้าร่วม 192.168.1.49:8443 --token ... --discovery-token-ca-cert-hash แต่กลับเกิดข้อผิดพลาดเดียวกัน
```
# ไฟล์ที่คัดลอกไปยัง cp01
แคลิฟอร์เนีย.crt
ca.key
sa.key
ผับ
front-proxy-ca.crt
front-proxy-ca.key
etcd/ca.crt
etcd/ca.key
```

แก้ไขปัญหาเครือข่าย

สามารถ ping 192.168.1.49 บน cp01
nc -v 192.168.1.49 8443 เมื่อ cp01 กลับมา Ncat: การเชื่อมต่อถูกปฏิเสธ
curl -k https://192.168.1.49:8443/api/v1... ทำงานบน cp02 และโหนดผู้ปฏิบัติงาน (ส่งคืนรหัส 403 ซึ่งควรเป็นปกติ)
/etc/cni/net.d/ ถูกลบใน cp01
ล้างกฎ iptables ด้วยตนเองบน cp01 ด้วย 'KUBE' หรือ 'cali'
firewalld ถูกปิดใช้งานทั้งบน cp01 และ cp02
ฉันลองเข้าร่วมกับเซิร์ฟเวอร์ใหม่ cp03 192.168.1.48 และพบการเรียกเลขหมายเดียวกัน tcp 192.168.1.49:8443: การเชื่อมต่อ: การเชื่อมต่อถูกปฏิเสธ ข้อผิดพลาด
netstat -tlnp | เกรป 8443 เมื่อ cp02 ส่งคืน:
```
tcp 0 0.0.0.0:8443 0.0.0.0:* ฟัง 27316/haproxy
```
nc -v 192.168.1.46 6443 ในการส่งคืน cp01 และ cp03:
```
Ncat: เชื่อมต่อกับ 192.168.1.46:6443
```

คำแนะนำ / คำแนะนำใด ๆ ที่จะได้รับการชื่นชมอย่างมากเนื่องจากฉันสูญเสียที่นี่ ฉันคิดว่าอาจเป็นเพราะกฎเครือข่ายใน cp02 แต่ฉันไม่รู้วิธีตรวจสอบสิ่งนี้จริงๆ ขอขอบคุณ!!

171

1 + 0

คูเบอร์เนเตส

คูบีด

โพสต์คำตอบ