ฉันกำลังขุดลงไปใน Kubernetes PKI ฉันสังเกตเห็นว่าส่วนประกอบของ controlplane ส่วนใหญ่รวมถึง kubelet รับรองความถูกต้องกับเซิร์ฟเวอร์ api โดยใช้ใบรับรอง TLS
เฉพาะ kube-proxy & flannel ที่ทำงานเป็น Daemonsets รับรองความถูกต้องโดยใช้บัญชีบริการ
รัฐเอกสาร:
DaemonSet: เนื่องจากตัว kubelet ถูกโหลดในแต่ละโหนด และเพียงพอที่จะเริ่มบริการพื้นฐาน คุณจึงสามารถเรียกใช้ kube-proxy และบริการเฉพาะโหนดอื่น ๆ ที่ไม่ใช่เป็นกระบวนการแบบสแตนด์อโลน แต่เป็น daemonset ในเนมสเปซระบบ kube เนื่องจากจะอยู่ในคลัสเตอร์ คุณจึงสามารถให้บัญชีบริการที่เหมาะสมแก่บัญชีดังกล่าวพร้อมสิทธิ์ที่เหมาะสมในการดำเนินกิจกรรมต่างๆ นี่อาจเป็นวิธีที่ง่ายที่สุดในการกำหนดค่าบริการดังกล่าว
มีอะไรพิเศษที่นี่เกี่ยวกับ Daemonsets เกี่ยวกับการรับรองความถูกต้อง?
เบื้องหลังคืออะไร"เนื่องจาก kubelet นั้นถูกโหลดในแต่ละโหนดและเพียงพอที่จะเริ่มบริการพื้นฐาน"?
เพื่อให้เข้าใจคำถามนี้ได้ดีขึ้น ควรเตือนพื้นฐาน ส่วนประกอบ Kubernetes.
โดยทั่วไปเราสามารถแบ่งคลัสเตอร์ออกเป็น:
มาดูส่วนประกอบของส่วน "โหนด" (ผู้ปฏิบัติงาน):
คูเบเลต
ตัวแทนที่ทำงานในแต่ละ โหนด ในคลัสเตอร์ มันทำให้แน่ใจว่า ตู้คอนเทนเนอร์ กำลังทำงานใน พ็อด. kubelet ใช้ชุดของ PodSpecs ที่ได้รับผ่านกลไกต่างๆ และตรวจสอบให้แน่ใจว่าคอนเทนเนอร์ที่อธิบายใน PodSpec เหล่านั้นทำงานและมีสุขภาพดี Kubelet ไม่จัดการคอนเทนเนอร์ที่ไม่ได้สร้างโดย Kubernetes
kube-พร็อกซี
kube-proxy เป็นพร็อกซีเครือข่ายที่ทำงานบนแต่ละรายการ โหนด ในคลัสเตอร์ของคุณ โดยนำส่วนหนึ่งของ Kubernetes ไปใช้ บริการ แนวคิด. kube-พร็อกซี รักษากฎเครือข่ายบนโหนด กฎเครือข่ายเหล่านี้อนุญาตให้มีการสื่อสารเครือข่ายไปยัง Pods ของคุณจากเซสชันเครือข่ายภายในหรือภายนอกคลัสเตอร์ของคุณ kube-proxy ใช้เลเยอร์การกรองแพ็คเก็ตของระบบปฏิบัติการ หากมีและพร้อมใช้งาน มิฉะนั้น kube-proxy จะส่งต่อทราฟฟิกเอง
รันไทม์คอนเทนเนอร์
รันไทม์ของคอนเทนเนอร์คือซอฟต์แวร์ที่รับผิดชอบในการรันคอนเทนเนอร์ Kubernetes รองรับรันไทม์คอนเทนเนอร์หลายรายการ: นักเทียบท่า, ตู้คอนเทนเนอร์, ซีอาร์ไอ-โอและการดำเนินการใด ๆ ของ Kubernetes CRI (อินเทอร์เฟซรันไทม์คอนเทนเนอร์).
ในฐานะที่เป็น คูเบเลต และคอนเทนเนอร์รันไทม์เป็นสององค์ประกอบหลักที่รับผิดชอบในการรันพ็อดและสร้างการเชื่อมต่อกับ Control Plane โดยจะต้องติดตั้งโดยตรงบนระบบปฏิบัติการของโหนด นอกจากนี้ยังหมายถึงสำหรับ คูเบเลต ต้องมีใบรับรอง TLS ที่คุณกล่าวถึงในคำถามของคุณเพื่อให้แน่ใจว่าเชื่อมต่อกับ Control Plane อย่างปลอดภัย เกี่ยวกับอะไร kube-พร็อกซี?
สามารถติดตั้งได้สองวิธีระหว่างการจัดเตรียมคลัสเตอร์ - โดยตรงบนระบบปฏิบัติการของโหนด (ตัวอย่างเช่น วิธีนี้ใช้ใน Kubernetes วิธีที่ยาก) หรือเป็น DaemonSet (คูบีด).
เมื่อไร kube-พร็อกซี เป็น ติดตั้งโดยตรง มันจะมีแยกกันด้วย สร้างใบรับรอง TLS, เหมือนกับ คูเบเลต.
วิธีที่สองคือ "DeamonSet" ที่กล่าวถึงในคำถามของคุณ หมายความว่า แทนที่จะทำงานเป็น OS deamon โดยตรงบนโหนด ระบบจะกำหนดค่าผ่าน ชุดเดมอน การปรับใช้และจะทำงานเป็นพ็อดในทุก ๆ โหนด ข้อดีกว่าการทำงานบน OS โดยตรง:
ตอบคำถามของคุณ:
มีอะไรพิเศษที่นี่เกี่ยวกับ Daemonsets เกี่ยวกับการรับรองความถูกต้อง?
เพื่อให้เข้าใจได้ดีขึ้น เรามาดูข้อมูลเชิงลึกของ kube-พร็อกซี กำหนดค่าผ่าน DaemonSets โดยใช้คลัสเตอร์ที่จัดเตรียมไว้ คูบีด. ขึ้นอยู่กับ Kubernetes เอกสาร:
บัญชีบริการสำหรับ
kube-พร็อกซีถูกสร้างขึ้นในระบบ kubeเนมสเปซ; จากนั้น kube-proxy จะถูกปรับใช้เป็น DaemonSet:
- ข้อมูลประจำตัว (
แคลิฟอร์เนีย.crtและโทเค็น) ไปยังระนาบควบคุมมาจาก ServiceAccount- ตำแหน่ง (URL) ของเซิร์ฟเวอร์ API มาจาก ConfigMap
- เดอะ
kube-พร็อกซีServiceAccount จะผูกพันกับสิทธิพิเศษในระบบ:โหนดพร็อกซีคลัสเตอร์บทบาท
มีสามจุด ก่อนอื่นมาตรวจสอบอันแรกกัน:
ข้อมูลรับรอง - ความลับ
รับชื่อบัญชีบริการจากคำจำกัดความของพ็อด:
kubectl รับ daemonset kube-proxy -n kube-system -o yaml
...
บัญชีบริการ: kube-proxy
serviceAccountName: kube-proxy
...
อย่างที่เห็นก็มี กำหนดบัญชีบริการ เรียกว่า kube-พร็อกซี:
มาตรวจสอบกัน:
kubectl รับ sa kube-proxy -n kube-system -o yaml
เอาท์พุต:
api เวอร์ชัน: v1
ชนิด: ServiceAccount
ข้อมูลเมตา:
การสร้างการประทับเวลา: "2021-08-16T14:14:56Z"
ชื่อ: kube-proxy
เนมสเปซ: ระบบ kube
ทรัพยากรเวอร์ชัน: "259"
ไอดี: (UID)
ความลับ:
- ชื่อ: kube-proxy-token-2qhph
อย่างที่เห็น เรากำลังหมายถึงความลับที่มีชื่อ kube-proxy-token-2qhph:
kubectl รับความลับ kube-proxy-token-2qhph -n kube-system -o yaml
เอาท์พุต:
api เวอร์ชัน: v1
ข้อมูล:
ca.crt: (เข้ารหัส CA BASE64 ของ APISERVER)
เนมสเปซ: (เข้ารหัส NAMESPACE BASE64)
โทเค็น: (เข้ารหัส BASE64 BEARER TOKEN)
ประเภท: ความลับ
ข้อมูลเมตา:
คำอธิบายประกอบ:
kubernetes.io/service-account.name: kube-proxy
kubernetes.io/service-account.uid: ...
การสร้างการประทับเวลา: "2021-08-16T14:14:56Z"
ชื่อ: kube-proxy-token-2qhph
เนมสเปซ: ระบบ kube
ทรัพยากรเวอร์ชัน: "256"
ไอดี: (UID)
ประเภท: kubernetes.io/service-account-token
ความลับที่สร้างขึ้นจะเก็บ CA สาธารณะของเซิร์ฟเวอร์ API และ JSON Web Token (JWT) ที่ลงนามแล้ว
เรากำลังใช้โทเค็นผู้ถือ "JSON Web Token" เพื่อยืนยันคำขอ:
บัญชีบริการเป็นตัวรับรองความถูกต้องที่เปิดใช้งานโดยอัตโนมัติซึ่งใช้โทเค็นผู้ถือที่ลงนามเพื่อตรวจสอบคำขอ
JWT ที่ลงชื่อสามารถใช้เป็นโทเค็นผู้ถือเพื่อตรวจสอบสิทธิ์เป็นบัญชีบริการที่กำหนด ดู ข้างต้น สำหรับวิธีรวมโทเค็นในคำขอ โดยปกติแล้ว ข้อมูลลับเหล่านี้จะติดตั้งในพ็อดสำหรับการเข้าถึงในคลัสเตอร์ไปยังเซิร์ฟเวอร์ API แต่สามารถใช้จากภายนอกคลัสเตอร์ได้เช่นกัน
หากต้องการข้อมูลเพิ่มเติมเกี่ยวกับโทเค็น bootstrap ฉันขอแนะนำให้อ่านเอกสาร Kubernetes ต่อไปนี้: การตรวจสอบสิทธิ์ด้วยโทเค็น Bootstrap, โทเค็น kubeadm และ Kubernetes RBAC 101: การรับรองความถูกต้อง.
ConfigMap
โดยทำตามขั้นตอนที่คล้ายกันเพื่อรับชื่อ ServiceAccount เราจะได้ชื่อ ConfigMap ซึ่งติดตั้งกับ kube-พร็อกซี พ็อด:
kubectl รับ daemonset kube-proxy -n kube-system -o yaml
...
ปริมาณ:
- คอนฟิกแมป:
โหมดเริ่มต้น: 420
ชื่อ: kube-proxy
...
ทีนี้ มาดูคำจำกัดความของ ConfigMap:
kubectl รับ cm kube-proxy -n kube-system -o yaml
kubeconfig.conf: |-
api เวอร์ชัน: v1
ประเภท: การกำหนดค่า
คลัสเตอร์:
- กลุ่ม:
ผู้ออกใบรับรอง: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
เซิร์ฟเวอร์: https://10.230.0.12:6443
ชื่อ: ค่าเริ่มต้น
บริบท:
- บริบท:
คลัสเตอร์: ค่าเริ่มต้น
เนมสเปซ: ค่าเริ่มต้น
ผู้ใช้: ค่าเริ่มต้น
ชื่อ: ค่าเริ่มต้น
บริบทปัจจุบัน: ค่าเริ่มต้น
ผู้ใช้:
- ชื่อ: ค่าเริ่มต้น
ผู้ใช้:
ไฟล์โทเค็น: /var/run/secrets/kubernetes.io/serviceaccount/token
ที่อยู่ IP นี้ภายใต้ เซิร์ฟเวอร์: เป็นที่อยู่ API ดังนั้น kube-พร็อกซี รู้และสื่อสารกับมันได้
นอกจากนี้ยังมีการอ้างอิงถึง รถเข็น และ โทเค็น ที่ติดตั้งจาก kube-proxy-token-2qhph ความลับ.
คลัสเตอร์บทบาท
ตรวจสอบ ClusterRole ที่กล่าวถึงก่อนหน้านี้ - ระบบ:โหนดพร็อกซี:
kubectl อธิบายระบบคลัสเตอร์บทบาท: node-proxier
ชื่อ: ระบบ:โหนดพร็อกซี
ป้ายกำกับ: kubernetes.io/bootstrapping=rbac-defaults
คำอธิบายประกอบ: rbac.authorization.kubernetes.io/autoupdate: จริง
กฎนโยบาย:
ทรัพยากร URL ที่ไม่ใช่ทรัพยากร ชื่อทรัพยากร กริยา
--------- ----------------- ------------- -----
เหตุการณ์ [] [] [สร้างการอัปเดตแพตช์]
events.events.k8s.io [] [] [สร้างการอัปเดตแพตช์]
โหนด [] [] [รับรายการเฝ้าดู]
จุดสิ้นสุด [] [] [รายการเฝ้าดู]
บริการ [] [] [ดูรายการ]
endpointslices.discovery.k8s.io [] [] [ดูรายการ]
เราสามารถให้บทบาทนี้แสดงรายการและดูจุดสิ้นสุดของโหนด จุดบริการ ฯลฯ...
โดยอธิบาย ClusterRoleBinding kubeadm:node-proxier เราสามารถยืนยันบทบาทนั้นได้ ระบบ:โหนดพร็อกซี ถูกใช้โดย kube-พร็อกซี บัญชีบริการ:
kubectl อธิบายคลัสเตอร์บทบาทผูกพัน kubeadm:node-proxier
ชื่อ: kubeadm:node-proxier
ป้ายกำกับ: <ไม่มี>
คำอธิบายประกอบ: <ไม่มี>
บทบาท:
ประเภท: ClusterRole
ชื่อ: ระบบ:โหนดพร็อกซี
วิชา:
ชื่อชนิด Namespace
---- ---- ---------
ServiceAccount kube-proxy ระบบ kube
หากต้องการรายละเอียดเพิ่มเติมฉันขอแนะนำให้อ่าน คูบีด รายละเอียดการใช้งาน.
ตอบคำถามที่สองของคุณ:
เบื้องหลังคืออะไร"เนื่องจากตัว kubelet ถูกโหลดในแต่ละโหนด และเพียงพอที่จะเริ่มบริการพื้นฐาน" ?
หมายความว่าโหนดสร้างการเชื่อมต่อกับ Control Plane (เช่น คูเบเลต เป็นส่วนประกอบที่รับผิดชอบ) ดังนั้น Control Plane จึงสามารถเริ่มการตั้งเวลาได้ kube-พร็อกซี พ็อดบนโหนดโดยใช้รันไทม์ของคอนเทนเนอร์ที่กำหนดไว้ล่วงหน้า
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
