‫เมื่อคุณมีพ็อดทำงานแล้ว คุณอาจจะต้องเปิดเผยข้อมูลเหล่านั้นต่อบริการภายนอกในบางจุด
‫นั่นหมายถึงการอนุญาตให้พวกเขายอมรับการเชื่อมต่อในบางรูปแบบในคลัสเตอร์ของคุณหรือจากภายนอกคลัสเตอร์ของคุณ
‫ใน Kubernetes เราใช้คำสั่ง kubectl expose
‫เป็นวิธีหนึ่งในการสร้างบริการ
‫เราพูดถึงบริการสองสามครั้งก่อนหน้านี้ แต่ขอให้แน่ใจว่าเราชัดเจนว่าบริการคืออะไร
‫บริการเป็นจุดปลายทางที่สอดคล้องกันเพื่อให้สิ่งอื่นๆ
‫ภายในหรือภายนอกคลัสเตอร์อาจเข้าถึงได้
‫เมื่อคุณสร้างพ็อดใน Kubernetes พวกมันจะไม่ได้รับชื่อ
‫DNS โดยอัตโนมัติสำหรับการเชื่อมต่อภายนอกด้วยที่อยู่
‫IP
‫คุณต้องการทำสิ่งนั้นด้วยการสร้างบริการบนพ็อดที่มีอยู่
‫มีหลายวิธีนอกเหนือจากคำสั่งเปิดเผยนี้เพื่อสร้างบริการ
‫มาโฟกัสกันที่อะไรเดิมๆ
‫สิ่งที่พบบ่อยในที่นี้คือ DNS หลักนั้น
‫หากคุณจำได้ เราได้กล่าวถึงก่อนหน้านี้ว่าเป็นหนึ่งในคุณสมบัติหลักของระนาบการควบคุมของคุณ
‫บริการนั้นจะเป็นเซิร์ฟเวอร์ DNS ของคุณเพื่อแก้ไขชื่อสำหรับสิ่งเหล่านี้ทั้งหมด
‫ยิ่งไปกว่านั้น สำหรับการเลือก IP และพอร์ตและวิธีการทำเช่นนั้น
‫การรับส่งข้อมูลโดยพื้นฐานไปยังบริการของคุณนั้นเป็นหน้าที่ของหนึ่งในสี่ประเภทบริการที่แตกต่างกัน
‫มาดูสิ่งเหล่านั้นกันก่อน
‫แล้วเราจะมาดูตัวอย่างกัน เริ่มต้นด้วยบริการประเภท
‫ClusterIP ซึ่งเป็นค่าเริ่มต้น
‫ในกรณีนี้ สิ่งสำคัญที่สุดคือมีอยู่ในคลัสเตอร์เท่านั้น
‫นี่เป็นเรื่องเกี่ยวกับชุดพ็อด Kubernetes
‫ชุดหนึ่งที่พูดคุยกับชุดพ็อดชุดอื่น
‫สิ่งนี้ทำให้เกิดความเครียด DNS ของตัวเองใช่ไหม
‫นั่นจะเป็นที่อยู่ DNS ในระนาบการควบคุม
‫DNS หลัก จะได้รับที่อยู่ IP ในพื้นที่ที่อยู่
‫IP เสมือนภายในคลัสเตอร์
‫ที่ช่วยให้พ็อดอื่นๆ ของคุณที่ทำงานอยู่ในคลัสเตอร์สามารถพูดคุยกับบริการนี้โดยใช้พอร์ตของบริการ
‫หากคุณกำลังใช้งานแอป
‫Nginx และแอปนั้นทำงานบนพอร์ต 80 เมื่อคุณสร้างบริการ IP ของบริการนั้นอาจอยู่บนพอร์ต
‫80 ด้วย
‫ที่รักษาความสม่ำเสมอบางอย่างไว้ที่นั่น
‫หากคุณลองคิดดู วิธีนี้จะคล้ายกับวิธีสร้างบริการใน Swarm มาก ซึ่งตอนนี้บริการต่างๆ
‫ใน Swarm แตกต่างออกไปเล็กน้อย
‫พวกเขามีความคิดที่แตกต่างรอบตัว
‫แต่อย่างน้อยก็มีความสอดคล้องกันอย่างน้อยเมื่อคุณสร้างบริการ
‫มันจะให้ IP ภายในนั้นแก่คุณบนตัวโหลดบาลานซ์
‫ถ้าคุณจำได้ มันรันบนพอร์ตที่แอพเปิดอยู่
‫ในกรณีนี้ เรากำลังทำสิ่งที่คล้ายกันมาก แต่เราต้องสร้างสิ่งนี้ด้วยคำสั่ง
‫expose หรือตัวเลือกอื่นๆ ที่เราจะพูดถึงในภายหลัง
‫ถัดมาคือ NodePort ซึ่งแตกต่างไปจากเดิมอย่างสิ้นเชิง
‫มันค่อนข้างสับสนนอกกรอบ
‫ClusterIP เป็นค่าเริ่มต้นและใช้งานได้ภายในคลัสเตอร์เสมอ
‫ไม่ต้องการอะไรเป็นพิเศษ ไม่ต้องการกฎไฟร์วอลล์ภายนอกคลัสเตอร์เพื่อให้รับส่งข้อมูล
‫แต่ ClusterIP นั้นดีในคลัสเตอร์เท่านั้น
‫จำไว้. ClusterIP ดีในคลัสเตอร์
‫NodePort ได้รับการออกแบบมาสำหรับบางสิ่งนอกคลัสเตอร์เพื่อพูดคุยกับบริการของคุณผ่านที่อยู่
‫IP บนโหนดเอง
‫เมื่อคุณสร้าง NodePort คุณจะได้รับพอร์ตสูงในแต่ละโหนดที่กำหนดให้กับบริการนี้
‫เมื่อได้รับแล้ว คุณสามารถอัปเดตสิ่งอื่น ๆ ที่จำเป็นต้องทราบเกี่ยวกับพอร์ตนี้ได้
‫พอร์ตนี้จะเป็นพอร์ตสูง
‫คุณจะไม่ใช้พอร์ต 80 ตัวอย่างเช่น เมื่อคุณใช้ประเภทนี้
‫กุญแจสำคัญสำหรับทั้งสองสิ่งนี้คือพร้อมใช้งานในคลัสเตอร์
‫Kubernetes ทุกแห่งเสมอ
‫ไม่ว่าคุณจะใช้โซลูชันของผู้ให้บริการระบบคลาวด์ หรือใช้งาน
‫Kubernetes ของคุณเอง หรือปรับใช้แพ็คเกจ เช่น Docker
‫Enterprise หรือ Rancher
‫สิ่งเหล่านี้เป็นสิ่งที่ใช้งานได้ทันที
‫ถัดลงมาเป็นประเภทโหลดบาลานเซอร์
‫ส่วนใหญ่จะใช้ในคลาวด์
‫แนวคิดในที่นี้คือ คุณกำลังควบคุมตัวโหลดบาลานซ์ภายนอกผ่านบรรทัดคำสั่ง
‫Kubernetes ซึ่งค่อนข้างเจ๋ง
‫โดยพื้นฐานแล้วนี่คือระบบอัตโนมัติจำนวนมาก
‫สิ่งที่คุณกำลังทำอยู่ในเบื้องหลัง เมื่อคุณสร้างตัวโหลดบาลานซ์นี้
‫มันจะสร้าง ClusterIP ใน NodePort โดยอัตโนมัติเพื่อให้พร้อมใช้งาน
‫แล้วมันจะไปคุยกับระบบภายนอก
‫อาจเป็นตัวโหลดบาลานซ์ของ AWS หรือผู้จำหน่ายระบบคลาวด์รายอื่น
‫โดยพื้นฐานแล้ว
‫สิ่งเหล่านี้จะมาจากผู้ให้บริการโครงสร้างพื้นฐานของคุณ และจะอนุญาตให้ Kubernetes
‫พูดคุยกับพวกเขาผ่าน API ระยะไกลและกำหนดค่าให้คุณ
‫ดังนั้น
‫ในกรณีของตัวโหลดบาลานซ์ของ AWS เมื่อคุณสร้างสิ่งนี้
‫ไม่เพียงแต่จะสร้าง NodePorts และ ClusterIPs ในแบ็กเอนด์เท่านั้น
‫แต่ยังเป็นการบอกให้โหลดบาลานเซอร์ของ AWS พูดคุยกับ NodePorts
‫โดยพื้นฐานแล้วนี่เป็นเพียงระบบอัตโนมัติใช่ไหม
‫วิธีนี้ช่วยให้คุณประหยัดเวลาในการเรียกใช้บรรทัดคำสั่งของ
‫AWS หรือเว็บอินเทอร์เฟซ เพื่อตั้งค่าตัวโหลดบาลานซ์นั้นโดยอัตโนมัติ
‫ประเด็นสำคัญสองประการที่ฉันมีสำหรับเรื่องนี้คือการคิดเกี่ยวกับเรื่องนี้
‫เนื่องจากเป็นเพียงการรับส่งข้อมูลที่เข้ามาในคลัสเตอร์ของคุณจากแหล่งภายนอกเท่านั้น
‫ต้องใช้ผู้ให้บริการโครงสร้างพื้นฐานที่ให้ Kubernetes
‫สามารถพูดคุยกับ Kubernetes จากระยะไกลได้
‫ประเภทบริการสุดท้ายจากสี่ประเภทคือ ExternalName
‫มีการใช้น้อยลง และไม่มีส่วนเกี่ยวข้องกับการควบคุมการรับส่งข้อมูลขาเข้าไปยังบริการของคุณ
‫นี่เป็นข้อมูลเพิ่มเติมเกี่ยวกับสิ่งต่างๆ ในคลัสเตอร์ของคุณที่ต้องพูดคุยกับบริการภายนอก
‫คุณต้องการสร้างชื่อ DNS ในระบบ DNS
‫หลัก เพื่อให้คลัสเตอร์ของคุณสามารถแก้ไข ExternalNames
‫ที่คุณอาจไม่ได้ควบคุมจากภายนอก
‫สาเหตุหนึ่งที่คุณอาจใช้
‫ExternalName คือเมื่อคุณทำการย้ายข้อมูล
‫ลองคิดดูว่าคุณมีแอปพลิเคชันระยะไกลหรือไม่
‫แอปพลิเคชันระยะไกลนั้นนอกคลัสเตอร์ Kubernetes
‫ของคุณอาจมีชื่อ DNS อยู่แล้ว
‫หากคุณกำลังจะย้ายจากบริการภายนอกเหล่านั้นไปยังบริการภายใน
‫คุณอาจดูวิธีที่คุณสามารถใช้ ExternalName แทนการควบคุม DNS ภายในเวิร์กโฟลว์ Kubernetes ของคุณ
‫โดยทั่วไปแล้วคุณสามารถมีบรรทัดคำสั่งเดียวของ
‫Kubernetes แทนที่จะพูดว่า โอ้ ฉันต้องเปลี่ยน DNS ภายนอกสำหรับบางอย่าง
‫ดังนั้นฉันต้องเรียกใช้ยูทิลิตี้อื่นสำหรับบริการ DNS
‫นั้น
‫หรือบางทีแม้แต่บางสิ่งที่ไม่มีแม้แต่
‫API เบื้องหลัง อาจเหมือนกับ DNS ขององค์กรหรืออะไรทำนองนั้น
‫คุณสามารถใช้สิ่งนี้ภายในคลัสเตอร์ของคุณ
‫เพื่อให้บริการภายในคลัสเตอร์ของคุณเริ่มแก้ไขปลายทางที่แตกต่างจากที่ก่อนหน้านี้มีที่เป็นภายนอก
‫ฉันพบว่าฉันใช้งานจริง
‫ๆ เฉพาะเมื่อฉันต้องการเปลี่ยนวิธีการนำสิ่งของออกจากคลัสเตอร์ไปเป็นบริการภายนอก
‫แต่ฉันไม่มีวิธีควบคุม DNS จากระยะไกลของสิ่งอื่นๆ เหล่านั้น
‫ดังนั้น
‫ฉันอยากจะทำมันใน Kubernetes และสร้าง ExternalNames สำหรับสิ่งของของฉัน
‫จากนั้น เมื่อฉันต้องการเปลี่ยนแบบไดนามิกใน Kubernetes
‫สำหรับสิ่งของภายในคลัสเตอร์ของฉัน ฉันสามารถทำสิ่งนั้นได้อย่างง่ายดายโดยไม่ต้องพูดคุยกับสิ่งอื่นใด
‫ไม่เป็นไร. เราจะสรุปบริการทั้งสี่ประเภทนี้
‫แต่มีอีกวิธีหนึ่งที่การรับส่งข้อมูลสามารถเข้าไปในคลัสเตอร์ของคุณได้
‫นั่นคือผ่าน Ingress
‫เราจะพูดถึงเรื่องนี้ในภายหลัง
‫ที่ออกแบบมาเฉพาะสำหรับการรับส่งข้อมูล HTTP
‫เมื่อเราไปถึงการบรรยาย คุณจะเข้าใจว่าเหตุใดจึงแตกต่างจากบริการประเภทนี้เล็กน้อย