Score:3

Kubernetes Nginx Ingress และ cert-manager กำลังรอการเผยแพร่ความท้าทาย HTTP-01: รหัสสถานะไม่ถูกต้อง '401' คาดว่าจะเป็น '200'

ธง cd

ฉันมีปัญหากับการติดตั้ง rapberry pi kubernetes

ปัญหา:

ฉันมีผู้จัดการใบรับรองให้เข้ารหัสความท้าทาย ACME ที่รออยู่เนื่องจากรหัสข้อผิดพลาด 401 ในการติดตั้ง kubernetes ของ Bare Metal

ติดตั้ง

แพลตฟอร์ม: Raspberry Pi 4

ระบบปฏิบัติการ: เซิร์ฟเวอร์ Ubuntu 20.04.3 LTS 64 บิต

ขาเข้า: Nginx

ตัวโหลดบาลานเซอร์: Metallb

เครือข่าย: Calico

ฉันติดตั้ง metallb และ nginx ผ่านหางเสือโดยใช้:

หางเสือติดตั้ง metallb metallb/metallb --namespace kube-system\
    --set configInline.address-pools[0].name=default\
    --set configInline.address-pools[0].protocol=layer2\
    --set configInline.address-pools[0].addresses[0]=<ip-range>

และ

หางเสือติดตั้ง ingress-nginx ingress-nginx/ingress-nginx --namespace kube-system

Letsencrypt ของฉันมีลักษณะดังนี้:

apiVersion: cert-manager.io/v1
ประเภท: ClusterIssuer
ข้อมูลเมตา:
  ชื่อ: letsencrypt-prod
  เนมสเปซ: cert-manager
ข้อมูลจำเพาะ:
  จุดสุดยอด:
    อีเมล: <อีเมลถูกแก้ไขแล้ว>
    เซิร์ฟเวอร์: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      ชื่อ: letsencrypt-prod
    นักแก้ปัญหา:
    - http01:
        ทางเข้า:
          คลาส: nginx

การตั้งค่าขาเข้า nginx ของฉันมีลักษณะดังนี้:

---
รุ่น api: networking.k8s.io/v1
ชนิด: ทางเข้า
ข้อมูลเมตา:
  เนมสเปซ: "nextcloud" # เนมสเปซเดียวกันกับการปรับใช้
  ชื่อ: "nextcloud-ingress" # ชื่อของขาเข้า (ดูที่ kubectl รับขาเข้า -A)
  คำอธิบายประกอบ:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/ssl-redirect: "จริง"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "จริง"
    cert-manager.io/cluster-issuer: "letsencrypt-prod" # เข้ารหัสโดยใช้ ClusterIssuer ที่ปรับใช้ขณะตั้งค่า Cert-Manager
    nginx.ingress.kubernetes.io/proxy-body-size: "125m" # เพิ่มขนาดสูงสุดที่อนุญาตของเนื้อหาคำขอไคลเอ็นต์
ข้อมูลจำเพาะ:
  tls:
  - เจ้าภาพ:
    - "nextcloud.<domain redacted>" # โฮสต์เพื่อเข้าถึง nextcloud
    secretName: "nextcloud-prod-tls" # ชื่อของใบรับรอง (ดูที่ kubectl รับใบรับรอง -A)
  กฎ:
  - โฮสต์: "nextcloud.<domain redacted>" # โฮสต์เพื่อเข้าถึง nextcloud
    http:
      เส้นทาง:
        - เส้นทาง: / # เราจะเข้าถึง NextCloud ผ่าน URL https://nextcloud.<domain.com>/
          pathType: คำนำหน้า
          แบ็กเอนด์:
            บริการ: 
              ชื่อ: "เซิร์ฟเวอร์ถัดไปคลาวด์" # การแมปกับบริการ (ดูที่ kubectl รับบริการ -n nextcloud)
              ท่า: 
                หมายเลข: 80 # การแมปกับพอร์ต (ดูที่ kubectl รับบริการ -n nextcloud)
---

การดีบัก

เมื่อฉันดูบันทึกตัวควบคุมขาเข้า (เนมสเปซอื่น) ฉันเห็น:

บริการ "nextcloud/cm-acme-http-solver-9tccf" ไม่มีจุดสิ้นสุดที่ใช้งานอยู่

แต่จุดสิ้นสุดดูเหมือนจะมีอยู่เมื่อฉันทำ kubectl รับจุดสิ้นสุด -A

ใบรับรองของฉันมีอยู่เป็น:

kubectl รับใบรับรอง -n nextcloud
ชื่อพร้อมอายุความลับ
nextcloud-prod-tls เท็จ nextcloud-prod-tls 3h58m

ทำตามขั้นตอนการแก้ไขข้อบกพร่องที่แนะนำจากผู้จัดการใบรับรอง ฉันติดตามปัญหาไปจนถึงความท้าทายที่ฉันได้รับ:

สถานะ:
  นำเสนอ: จริง
  การประมวลผล: จริง
  เหตุผล: กำลังรอการเผยแพร่ความท้าทาย HTTP-01: รหัสสถานะไม่ถูกต้อง '401' คาดว่าจะเป็น '200'
  รัฐ: รอดำเนินการ
เหตุการณ์: <ไม่มี>

ฉันติดอยู่นิดหน่อย ฉันค้นหาในกูเกิลแล้ว แต่ดูเหมือนจะไม่มีอะไรมากเกี่ยวกับเรื่องนี้ ฉันเดาว่าฉันได้เตรียมการตั้งค่าเรียบร้อยแล้ว แต่ฉันได้ติดตามเอกสารประกอบในหน้าที่เกี่ยวข้องเป็นหลัก พอยน์เตอร์ใด ๆ ที่จะได้รับการชื่นชมอย่างมาก :) หากคุณต้องการข้อมูลเพิ่มเติม โปรดแจ้งให้เราทราบ ขณะนี้ค่อนข้างยาว ดังนั้นฉันจึงพยายามรวมสิ่งที่คิดว่าเป็นจุดปัญหา

Dennis Nolte avatar
us flag
ถ้าฉันอ่านการตั้งค่าของคุณถูกต้อง คุณจะได้รับ 401 ในโฟลเดอร์/ไฟล์ที่ร้องขอ cert-manager (certbot?) ดูเหมือนว่าเป็นเพราะการโทรจาก letsencrypt โอนไปยังสิ่งที่คุณอาจมีการป้องกันด้วยรหัสผ่าน บันทึก nginx ของคุณควรแสดงคำขอชื่อโฟลเดอร์ .well-known หรือที่คล้ายกัน หลังจากนั้นเป็นชื่อสามัญ คนนอกนั้นต้องสามารถเข้าถึงได้ (certbot ในตัวอย่างนี้) สำหรับฉันแล้ว การยกเว้นไดเร็กทอรีเฉพาะนั้นเพื่อให้ nginx ให้บริการโดยตรงนั้นได้ผลดีที่สุด บางอย่างเช่นตำแหน่ง .well-known block ในการกำหนดค่า nginx
Mikołaj Głodziak avatar
id flag
ความคิดของ @DennisNolte เป็นสิ่งที่ดี คุณช่วยลองและรู้จักเราว่ามันใช้ได้ไหม
Llewyn S avatar
cd flag
@DennisNolte ขอบคุณสำหรับการตอบกลับของคุณ ฉันไม่พบความพยายามใด ๆ ในการเข้าถึงไดเร็กทอรี /.well-known/ ในบันทึกคอนโทรลเลอร์ Nginx แต่ฉันสามารถค้นหาการอ้างอิงถึงมันและโดเมนของฉันใน nginx.conf คุณกำลังแนะนำให้ฉันเปลี่ยนตำแหน่ง /.well-known/ เป็นไดเร็กทอรีอื่นใน nginx.conf หรือไม่
Mikołaj Głodziak avatar
id flag
คุณเห็น[หัวข้อนี้](https://github.com/jetstack/cert-manager/issues/2517)ไหม มันคล้ายกับปัญหาของคุณหรือไม่?
Llewyn S avatar
cd flag
@MikoÅajGÅodziak ฉันตรวจสอบแล้ว แต่ไม่พบสิ่งใดที่เกี่ยวข้อง ดูเหมือนว่าคนส่วนใหญ่จะไม่ได้รับ 401s...ฉันไม่รู้ว่าจะดีบักอย่างไรเนื่องจากไม่มีปัญหาการอนุญาตในบันทึกการเข้า เพียงแค่การท้าทายใบรับรองจะได้รับข้อผิดพลาด 401 ฉันสงสัยว่าฉันจะเพิ่ม cert-manager ให้กับกลุ่ม RBAC ได้หรือไม่...
Dennis Nolte avatar
us flag
คุณจะต้องพยายามหาว่า cert challenge เข้าถึงเซิร์ฟเวอร์ของคุณด้วยอะไร ซึ่งควรอยู่ในบันทึก ingres ไฟล์นี้มักจะเรียกว่า access.log โดยอาจมีชื่อโดเมนอยู่ข้างหน้า ในไฟล์นั้นคุณจะพบว่าการโทร HTTP nginx ได้รับ หากคุณไม่พบรายการใด ๆ ให้ดำเนินการบางอย่างด้วยตนเองเพื่อยืนยันว่าเป็นไฟล์บันทึกที่ถูกต้อง เช่นเดียวกับแบ็กเอนด์ของคุณ แต่อาจต้องกำหนดค่าก่อน เมื่อคุณทราบการโทรที่ถูกต้องแล้ว คุณสามารถตรวจสอบได้ว่าคุณอนุญาตการเข้าถึงไดเร็กทอรีนั้น และกำหนดว่าใครควรให้บริการไดเร็กทอรีนั้น
Wytrzymały Wiktor avatar
it flag
สวัสดี @LlewynS การปรับปรุงใด ๆ ?
Llewyn S avatar
cd flag
ฉันยังติดตามบันทึกที่เป็นประโยชน์ไม่ได้
Llewyn S avatar
cd flag
ตกลง ฉันตั้งค่าตัวอย่างขั้นต่ำโดยไม่มีผู้จัดการใบรับรอง ฉันพบว่าถ้าฉันพยายามเชื่อมต่อกับ FQDN ของฉันผ่านเครือข่ายในบ้าน แท้จริงแล้วเป็นการพาฉันไปที่การเข้าสู่ระบบเราเตอร์... ฉันสามารถเชื่อมต่อผ่าน FQDN ได้แล้วผ่าน VPN หรือโทรศัพท์มือถือ สิ่งนี้ไม่ได้แก้ปัญหาผู้จัดการใบรับรองที่มีปัญหา 401 นอกจากว่าการกำหนดเส้นทางผ่านเครือข่ายในบ้านยังส่งไปยังการเข้าสู่ระบบเราเตอร์แทนที่จะเข้า....
Score:1
ธง jp

ในกรณีของฉัน ผู้ออกคลัสเตอร์ชี้ไปที่คลาสขาเข้าที่ไม่ถูกต้อง

kubectl แก้ไขคลัสเตอร์ผู้ออก XXXX

นักแก้ปัญหา:
- http01:
    ทางเข้า:
      คลาส: nginternal

ตรวจสอบให้แน่ใจว่าคลาสชี้ไปที่เดียวกับทางเข้า

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา