Kubernetes and Container Orchestration (Kubernetes และ Container Orchestration)

เมื่อ container เริ่มได้รับความนิยม หลายคนเริ่มมองหา solution สำหรับวิธีจัดการ container ข้ามหลายเครื่อง Docker มีความพยายามสองครั้งกับเรื่องนี้ (ด้วย Docker Swarm และ Docker Swarm Mode ตามลำดับ) บริษัทอย่าง Rancher และ CoreOS ก็มีแนวทางของตัวเอง และ platform วัตถุประสงค์ทั่วไปมากขึ้นอย่าง Mesos ถูกใช้เพื่อรัน container ควบคู่ไปกับ workload ประเภทอื่น ๆ ท้ายที่สุด อย่างไรก็ตาม แม้จะมีความพยายามอย่างมากกับผลิตภัณฑ์เหล่านี้ Kubernetes ได้ครองพื้นที่นี้ในช่วงสองสามปีที่ผ่านมา

ก่อนที่เราจะพูดถึง Kubernetes เอง เราควรพูดคุยกันก่อนว่าทำไมถึงจำเป็นต้องมีเครื่องมือแบบนี้ตั้งแต่แรก

The Case for Container Orchestration (เหตุผลสำหรับ Container Orchestration)

พูดกว้าง ๆ Kubernetes สามารถอธิบายได้หลายแบบว่าเป็น container orchestration platform หรือ เพื่อใช้คำที่ไม่ค่อยได้รับความนิยมแล้ว container scheduler แล้ว platform เหล่านี้คืออะไร และทำไมเราถึงต้องการมัน?

Container ถูกสร้างขึ้นโดยการแยก resource ชุดหนึ่งบนเครื่องเบื้องล่าง เครื่องมืออย่าง Docker ช่วยให้เรากำหนดว่า container ควรมีลักษณะอย่างไรและสร้าง instance ของ container นั้นบนเครื่อง แต่ solution ส่วนใหญ่ต้องการให้ซอฟต์แวร์ของเราถูกกำหนดบนหลายเครื่อง อาจเพื่อรองรับโหลดที่เพียงพอ หรือเพื่อให้แน่ใจว่าระบบมี redundancy เพื่อทนต่อความล้มเหลวของ node เดียว Container orchestration platform จัดการว่า container workload จะถูกรันอย่างไรและที่ไหน คำว่า "scheduling" เริ่มสมเหตุสมผลมากขึ้นในบริบทนี้ operator พูดว่า "ผมต้องการให้สิ่งนี้รัน" และ orchestrator จะหาวิธี schedule งานนั้น—หา resource ที่มีอยู่ จัดสรรใหม่ถ้าจำเป็น และจัดการรายละเอียดให้ operator

Container orchestration platform ต่าง ๆ ยังจัดการ desired state management ให้เราด้วย ทำให้แน่ใจว่า expected state ของชุด container (microservice instance ในกรณีของเรา) ถูกรักษาไว้ พวกมันยังช่วยให้เรากำหนดวิธีที่เราต้องการให้ workload เหล่านี้ถูกกระจาย ทำให้เราสามารถ optimize สำหรับ resource utilization, latency ระหว่าง process หรือเหตุผลด้านความทนทานได้

ถ้าไม่มีเครื่องมือแบบนี้ คุณจะต้องจัดการการกระจาย container ของคุณเอง ซึ่งเป็นสิ่งที่ผมบอกคุณได้จากประสบการณ์ตรงว่ามันน่าเบื่อมากอย่างรวดเร็ว การเขียน script เพื่อจัดการการเปิดตัวและ networking ของ container instance นั้นไม่สนุกเลย

พูดกว้าง ๆ container orchestration platform ทั้งหมด รวมถึง Kubernetes ให้ความสามารถเหล่านี้ในรูปแบบใดรูปแบบหนึ่ง ถ้าคุณดู scheduler วัตถุประสงค์ทั่วไปอย่าง Mesos หรือ Nomad managed solution อย่าง ECS ของ AWS, Docker Swarm Mode และอื่น ๆ คุณจะเห็น featureset ที่คล้ายกัน แต่ด้วยเหตุผลที่เราจะสำรวจในไม่ช้า Kubernetes ได้ชนะในพื้นที่นี้ มันยังมีแนวคิดที่น่าสนใจหนึ่งหรือสองอย่างที่คุ้มค่าที่จะสำรวจสั้น ๆ

A Simplified View of Kubernetes Concepts (มุมมองแบบง่ายของแนวคิด Kubernetes)

มีแนวคิดอื่น ๆ อีกมากมายใน Kubernetes ดังนั้นคุณคงให้อภัยผมที่ไม่ลงลึกทั้งหมด (นั่นสมควรจะเป็นหนังสือทั้งเล่มของมันเอง) สิ่งที่ผมจะพยายามทำตรงนี้คือสรุปแนวคิดหลักที่คุณต้องเข้าใจเมื่อคุณเริ่มทำงานกับเครื่องมือนี้เป็นครั้งแรก มาดูแนวคิดของ cluster กันก่อน ดังที่แสดงใน Figure 8-22

Figure 8-22. ภาพรวมแบบง่ายของ topology ของ Kubernetes

โดยพื้นฐานแล้ว Kubernetes cluster ประกอบด้วยสองสิ่ง อย่างแรก มีชุดของเครื่องที่ workload จะรันอยู่ เรียกว่า node อย่างที่สอง มีชุดของ controlling software ที่จัดการ node เหล่านี้ เรียกว่า control plane node เหล่านี้อาจกำลังรันเครื่อง physical หรือ virtual machine เบื้องหลัง แทนที่จะ schedule container Kubernetes กลับ schedule สิ่งที่เรียกว่า pod pod ประกอบด้วย container หนึ่งตัวหรือมากกว่าที่จะถูก deploy ด้วยกัน

โดยทั่วไป คุณจะมี container เพียงตัวเดียวใน pod—ตัวอย่างเช่น instance ของ microservice ของคุณ มีบางโอกาส (ที่หายากตามประสบการณ์ของผม) ที่การมี container หลายตัวถูก deploy ด้วยกันสมเหตุสมผล ตัวอย่างที่ดีของสิ่งนี้คือการใช้ sidecar proxy อย่าง Envoy มักเป็นส่วนหนึ่งของ service mesh—หัวข้อที่เราพูดคุยกันไปแล้วใน "Service Meshes and API Gateways"

แนวคิดถัดไปที่มีประโยชน์ที่จะรู้จักคือสิ่งที่เรียกว่า service ในบริบทของ Kubernetes คุณสามารถคิดว่า service เป็น stable routing endpoint—โดยพื้นฐานแล้วเป็นวิธี map จาก pod ที่คุณมีอยู่ไปสู่ network interface ที่เสถียรซึ่งมีให้ใช้ภายใน cluster Kubernetes จัดการ routing ภายใน cluster ดังที่เราเห็นใน Figure 8-23

Figure 8-23. Pod, service และ deployment ทำงานร่วมกันอย่างไร

แนวคิดคือ pod ที่กำหนดสามารถถือได้ว่าเป็นแบบชั่วคราว—มันอาจถูกปิดตัวลงด้วยเหตุผลใด ๆ ก็ได้—ในขณะที่ service โดยรวมยังคงอยู่ Service มีไว้เพื่อ route call ไปมาจาก pod และสามารถจัดการ pod ที่ถูกปิดตัวลงหรือ pod ใหม่ที่ถูกเปิดตัวได้ ในแง่ของคำศัพท์เพียงอย่างเดียว สิ่งนี้อาจสับสนได้ เราพูดโดยทั่วไปเกี่ยวกับการ deploy service แต่ใน Kubernetes คุณไม่ได้ deploy service—คุณ deploy pod ที่ map ไปยัง service มันอาจใช้เวลาสักพักที่จะทำความเข้าใจเรื่องนี้

ถัดไป เรามี replica set ด้วย replica set คุณกำหนด desired state ของชุด pod นี่คือที่ที่คุณพูดว่า "ผมต้องการ pod เหล่านี้ 4 ตัว" และ Kubernetes จัดการที่เหลือ ในทางปฏิบัติ คุณจะไม่ถูกคาดหวังให้ทำงานกับ replica set โดยตรงอีกต่อไป แทนที่จะเป็นแบบนั้น มันถูกจัดการให้คุณผ่าน deployment ซึ่งเป็นแนวคิดสุดท้ายที่เราจะดู deployment คือวิธีที่คุณนำการเปลี่ยนแปลงไปใช้กับ pod และ replica set ของคุณ ด้วย deployment คุณสามารถทำสิ่งต่าง ๆ เช่น issue rolling upgrade (ดังนั้นคุณจึงแทนที่ pod ด้วยเวอร์ชันใหม่แบบค่อยเป็นค่อยไปเพื่อหลีกเลี่ยง downtime), rollback, การ scale จำนวน node ขึ้นและอื่น ๆ

ดังนั้น เพื่อ deploy microservice ของคุณ คุณกำหนด pod ซึ่งจะบรรจุ microservice instance ของคุณอยู่ข้างใน คุณกำหนด service ซึ่งจะให้ Kubernetes รู้ว่า microservice ของคุณจะถูกเข้าถึงอย่างไร และคุณนำการเปลี่ยนแปลงไปใช้กับ pod ที่กำลังรันอยู่โดยใช้ deployment มันดูง่ายเมื่อผมพูดแบบนั้นใช่ไหม? ให้พูดตรง ๆ ว่าผมได้ตัดรายละเอียดจำนวนมากออกไปตรงนี้เพื่อความกระชับ

Multitenancy and Federation (Multitenancy และ Federation)

จากมุมมองด้านประสิทธิภาพ คุณอยากจะรวม computing resource ทั้งหมดที่คุณมีไว้ใน Kubernetes cluster เดียว และให้ workload ทั้งหมดจากทั่วองค์กรของคุณรันอยู่ที่นั่น สิ่งนี้น่าจะให้ utilization ของ resource เบื้องล่างที่สูงขึ้น เนื่องจาก resource ที่ไม่ได้ใช้สามารถถูกจัดสรรใหม่ให้ใครก็ตามที่ต้องการได้อย่างอิสระ นี่ในทางกลับกันควรจะลดต้นทุนตามไปด้วย

ความท้าทายคือ แม้ Kubernetes จะสามารถจัดการ microservice ที่แตกต่างกันเพื่อวัตถุประสงค์ที่แตกต่างกันได้ดี แต่มันก็มีข้อจำกัดเกี่ยวกับว่า platform นี้ "multitenant" ได้มากแค่ไหน แผนกต่าง ๆ ในองค์กรของคุณอาจต้องการระดับการควบคุมที่แตกต่างกันเหนือ resource ต่าง ๆ การควบคุมประเภทนี้ไม่ได้ถูกสร้างเข้าไปใน Kubernetes ซึ่งเป็นการตัดสินใจที่ดูสมเหตุสมผลในแง่ของการพยายามจำกัดขอบเขตของ Kubernetes ให้ค่อนข้างจำกัด เพื่อแก้ปัญหานี้ องค์กรต่าง ๆ ดูเหมือนจะสำรวจเส้นทางที่แตกต่างกันสองสามเส้นทาง

ตัวเลือกแรกคือการรับเอา platform ที่สร้างขึ้นบน Kubernetes ที่ให้ความสามารถเหล่านี้—OpenShift จาก Red Hat ตัวอย่างเช่น มีชุด access control และความสามารถอื่น ๆ ที่หลากหลายซึ่งถูกสร้างขึ้นโดยคำนึงถึงองค์กรขนาดใหญ่ และสามารถทำให้แนวคิดของ multitenancy ง่ายขึ้นได้บ้าง นอกเหนือจากผลกระทบทางการเงินใด ๆ ของการใช้ platform ประเภทนี้ เพื่อให้มันทำงานได้ บางครั้งคุณจะต้องทำงานกับ abstraction ที่ vendor ที่คุณเลือกมอบให้คุณ—หมายความว่านักพัฒนาของคุณต้องรู้ไม่เพียงแค่วิธีใช้ Kubernetes แต่ยังต้องรู้วิธีใช้ platform เฉพาะของ vendor นั้นด้วย

อีกแนวทางหนึ่งคือการพิจารณาโมเดลแบบ federated ที่ระบุใน Figure 8-24 ด้วย federation คุณมี cluster แยกกันหลายตัว พร้อมกับ software layer บางอย่างที่อยู่ข้างบนซึ่งช่วยให้คุณทำการเปลี่ยนแปลงข้าม cluster ทั้งหมดได้ถ้าจำเป็น ในหลายกรณี คนจะทำงานโดยตรงกับ cluster เดียว ให้ประสบการณ์ Kubernetes ที่ค่อนข้างคุ้นเคยกับพวกเขา แต่ในบางสถานการณ์ คุณอาจต้องการกระจายแอปพลิเคชันข้ามหลาย cluster โดยเฉพาะถ้า cluster เหล่านั้นอยู่ในภูมิภาคทางภูมิศาสตร์ที่แตกต่างกัน และคุณต้องการให้แอปพลิเคชันของคุณถูก deploy พร้อมความสามารถในการรับมือกับการสูญเสีย cluster ทั้งหมด

Figure 8-24. ตัวอย่างของ federation ใน Kubernetes

ธรรมชาติแบบ federated ทำให้การ pool resource ท้าทายมากขึ้น ดังที่เราเห็นใน Figure 8-24 Cluster A ถูกใช้งานเต็มที่ ในขณะที่ Cluster B มี capacity ที่ไม่ได้ใช้จำนวนมาก ถ้าเราต้องการรัน workload มากขึ้นบน Cluster A การทำเช่นนั้นจะเป็นไปได้ก็ต่อเมื่อเราสามารถมอบ resource มากขึ้นให้มัน เช่น การย้าย node ที่ว่างจาก Cluster B ไปยัง Cluster A ความง่ายในการย้าย node จาก cluster หนึ่งไปยังอีก cluster หนึ่งจะขึ้นอยู่กับลักษณะของ federation software ที่ใช้ แต่ผมนึกภาพออกเลยว่านี่อาจเป็นการเปลี่ยนแปลงที่ไม่ธรรมดา จำไว้ว่า node เดียวสามารถเป็นส่วนหนึ่งของ cluster เดียวหรืออีก cluster หนึ่งเท่านั้น และดังนั้นจึงไม่สามารถรัน pod สำหรับทั้ง Cluster A และ Cluster B พร้อมกันได้

ควรสังเกตว่าการมี cluster หลายตัวสามารถเป็นประโยชน์เมื่อเราพิจารณาความท้าทายของการ upgrade cluster เอง มันอาจง่ายกว่าและปลอดภัยกว่าที่จะย้าย microservice ไปยัง cluster ที่ upgrade ใหม่มากกว่าที่จะ upgrade cluster แบบ in-place

โดยพื้นฐานแล้ว สิ่งเหล่านี้เป็นความท้าทายของขนาด สำหรับบางองค์กร คุณจะไม่มีปัญหาเหล่านี้เลย เพราะคุณพอใจที่จะ share cluster เดียว สำหรับองค์กรอื่น ๆ ที่ต้องการประสิทธิภาพในระดับที่ใหญ่กว่า นี่เป็นพื้นที่ที่คุณจะต้องสำรวจในรายละเอียดมากขึ้นอย่างแน่นอน ควรสังเกตว่ามีวิสัยทัศน์ที่แตกต่างกันหลายแบบว่า Kubernetes federation ควรมีลักษณะอย่างไร และมี toolchain ที่แตกต่างกันหลายตัวสำหรับการจัดการมัน

The Background Behind Kubernetes (เบื้องหลังของ Kubernetes)

Kubernetes เริ่มต้นเป็นโปรเจกต์ open source ที่ Google โดยได้แรงบันดาลใจจากระบบจัดการ container รุ่นก่อนหน้าอย่าง Omega และ Borg แนวคิดหลักหลายอย่างใน Kubernetes มีพื้นฐานมาจากแนวคิดเกี่ยวกับวิธีจัดการ container workload ภายใน Google แม้จะมีเป้าหมายที่แตกต่างกันเล็กน้อยในใจ Borg รันระบบในขนาดใหญ่ระดับโลก จัดการ container นับหมื่นถึงหลายแสนตัวข้าม data center ทั่วโลก ถ้าคุณต้องการรายละเอียดเพิ่มเติมเกี่ยวกับว่า mindset ที่แตกต่างกันเบื้องหลัง Google platform ทั้งสามนี้เปรียบเทียบกันอย่างไร แม้จะจากมุมมองที่เน้น Google เป็นศูนย์กลาง ผมแนะนำ "Borg, Omega, and Kubernetes" โดย Brendan Burns และคณะ เป็นภาพรวมที่ดี

แม้ Kubernetes จะมี DNA บางส่วนร่วมกับ Borg และ Omega การทำงานในขนาดมหาศาลไม่ได้เป็นแรงขับเคลื่อนหลักของโปรเจกต์นี้ ทั้ง Nomad และ Mesos (ซึ่งทั้งคู่ได้แนวคิดมาจาก Borg) พบช่องทางเฉพาะของตัวเองในสถานการณ์ที่ต้องการ cluster ที่มีเครื่องนับพันตัว ดังที่แสดงให้เห็นในการใช้ Mesos ของ Apple สำหรับ Siri 5 หรือ การใช้ Nomad ของ Roblox

Kubernetes ต้องการนำแนวคิดจาก Google มาใช้แต่มอบประสบการณ์ที่เป็นมิตรกับนักพัฒนามากกว่าที่ Borg หรือ Omega มอบให้ มันเป็นไปได้ที่จะมองการตัดสินใจของ Google ในการลงทุนความพยายามด้าน engineering จำนวนมากในการสร้างเครื่องมือ open source ในแง่ของความเสียสละล้วน ๆ และแม้ผมมั่นใจว่านั่นคือความตั้งใจของบางคน แต่ความจริงคือมันเกี่ยวข้องมากพอ ๆ กันกับความเสี่ยงที่ Google เห็นจากการแข่งขันใน public cloud space โดยเฉพาะกับ AWS

ในตลาด public cloud Google Cloud ได้ครองส่วนแบ่งเพิ่มขึ้น แต่ก็ยังเป็นอันดับสามที่ห่างไกลตามหลัง Azure และ AWS (ซึ่งนำอยู่) และการวิเคราะห์บางส่วนก็ระบุว่ามันถูกแซงไปอยู่อันดับสี่โดย Alibaba Cloud แม้ส่วนแบ่งตลาดจะดีขึ้น แต่มันก็ยังห่างไกลจากที่ Google ต้องการมาก

ดูเหมือนว่าความกังวลหลักคือผู้นำตลาดที่ชัดเจนอย่าง AWS อาจในที่สุดมี monopoly ที่เกือบสมบูรณ์ในพื้นที่ cloud computing ยิ่งไปกว่านั้น ความกังวลเกี่ยวกับต้นทุนของการย้ายจาก provider หนึ่งไปยังอีก provider หนึ่งหมายความว่าตำแหน่งการครองตลาดแบบนั้นจะยากที่จะเปลี่ยนแปลง แล้วก็มี Kubernetes เข้ามา พร้อมคำมั่นสัญญาว่าจะส่งมอบ platform มาตรฐานสำหรับการรัน container workload ที่สามารถรันได้โดย vendor หลายราย ความหวังคือสิ่งนี้จะทำให้การย้ายจาก provider หนึ่งไปยังอีก provider หนึ่งเป็นไปได้ และหลีกเลี่ยงอนาคตที่มีแต่ AWS เท่านั้น

ดังนั้น คุณสามารถมอง Kubernetes ว่าเป็นการมีส่วนร่วมอย่างเอื้อเฟื้อจาก Google สู่อุตสาหกรรม IT ในวงกว้าง หรือเป็นความพยายามของ Google ที่จะยังคงมีความเกี่ยวข้องในพื้นที่ public cloud ที่เคลื่อนไหวอย่างรวดเร็ว ผมไม่มีปัญหาที่จะมองว่าทั้งสองอย่างเป็นความจริงเท่า ๆ กัน

The Cloud Native Computing Federation (The Cloud Native Computing Foundation)

Cloud Native Computing Foundation (เรียกสั้น ๆ ว่า CNCF) เป็นสาขาหนึ่งของ nonprofit Linux Foundation CNCF มุ่งเน้นการดูแล ecosystem ของโปรเจกต์เพื่อช่วยส่งเสริมการพัฒนาแบบ cloud native แม้ในทางปฏิบัติ นี่หมายถึงการสนับสนุน Kubernetes และโปรเจกต์ที่ทำงานร่วมกับหรือสร้างขึ้นบน Kubernetes เอง โปรเจกต์เหล่านี้เองไม่ได้ถูกสร้างหรือพัฒนาโดยตรงโดย CNCF แทนที่จะเป็นแบบนั้น คุณสามารถมอง CNCF เป็นสถานที่ที่โปรเจกต์เหล่านี้ ซึ่งอาจถูกพัฒนาแยกกันในที่อื่น สามารถถูก host ร่วมกันในที่เดียวกัน และที่ซึ่งมาตรฐานร่วมกันและ interoperability สามารถถูกพัฒนาได้

ในแง่นี้ CNCF ทำให้ผมนึกถึงบทบาทของ Apache Software Foundation—เช่นเดียวกับ CNCF การที่โปรเจกต์หนึ่งเป็นส่วนหนึ่งของ Apache Software Foundation โดยปกติแล้วบ่งบอกถึงระดับคุณภาพและการสนับสนุนจากชุมชนที่กว้างขึ้น โปรเจกต์ทั้งหมดที่ host โดย CNCF เป็น open source แม้การพัฒนาโปรเจกต์เหล่านี้อาจถูกขับเคลื่อนโดยหน่วยงานเชิงพาณิชย์ก็ตาม

นอกเหนือจากการช่วยชี้นำการพัฒนาของโปรเจกต์ที่เกี่ยวข้องเหล่านี้ CNCF ยังจัด event, จัดหาเอกสารและสื่อการฝึกอบรม และกำหนดโปรแกรมการรับรองต่าง ๆ เกี่ยวกับ Kubernetes กลุ่มนี้มีสมาชิกจากทั่วอุตสาหกรรม และแม้มันอาจเป็นเรื่องยากสำหรับกลุ่มเล็ก ๆ หรือบุคคลอิสระที่จะมีบทบาทมากนักในองค์กรเอง ระดับการสนับสนุนข้ามอุตสาหกรรม (รวมถึงหลายบริษัทที่เป็นคู่แข่งกัน) ก็น่าประทับใจ

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

Platforms and Portability (Platform และ Portability)

คุณจะได้ยิน Kubernetes ถูกอธิบายว่าเป็น "platform" บ่อย ๆ แต่มันไม่ใช่ platform ในความหมายที่นักพัฒนาจะเข้าใจคำนี้จริง ๆ นอกกล่อง สิ่งเดียวที่มันให้คุณจริง ๆ คือความสามารถในการรัน container workload คนส่วนใหญ่ที่ใช้ Kubernetes จบลงด้วยการประกอบ platform ของตัวเองขึ้นมาโดยการติดตั้งซอฟต์แวร์สนับสนุนอย่าง service mesh, message broker, เครื่องมือ log aggregation และอื่น ๆ ในองค์กรขนาดใหญ่ สิ่งนี้จบลงด้วยการเป็นความรับผิดชอบของทีม platform engineering ที่ประกอบ platform นี้เข้าด้วยกันและจัดการมัน และช่วยนักพัฒนาใช้ platform อย่างมีประสิทธิภาพ

สิ่งนี้อาจเป็นทั้งพรและคำสาป แนวทาง pick-and-mix นี้เป็นไปได้เนื่องจาก ecosystem ของเครื่องมือที่ค่อนข้างเข้ากันได้ (ต้องขอบคุณงานของ CNCF เป็นส่วนใหญ่) นี่หมายความว่าคุณสามารถเลือกเครื่องมือที่คุณชื่นชอบสำหรับงานเฉพาะได้ถ้าต้องการ แต่มันก็สามารถนำไปสู่ความบีบคั้นของทางเลือก—เราสามารถถูกครอบงำได้ง่ายด้วยตัวเลือกที่มากมาย ผลิตภัณฑ์อย่าง OpenShift ของ Red Hat นำทางเลือกนี้ออกไปจากเราบางส่วน เพราะมันให้ platform สำเร็จรูปพร้อมการตัดสินใจบางอย่างที่ทำไว้ให้เราแล้ว

สิ่งนี้หมายความว่าแม้ในระดับพื้นฐาน Kubernetes จะให้ portable abstraction สำหรับการรัน container ในทางปฏิบัติมันไม่ได้ง่ายเหมือนการนำแอปพลิเคชันที่ทำงานได้บน cluster หนึ่งไปคาดหวังว่ามันจะทำงานได้ที่อื่น แอปพลิเคชันของคุณ, operations และ developer workflow ของคุณ อาจพึ่งพา platform ที่ปรับแต่งเองของคุณอย่างมาก การย้ายจาก Kubernetes cluster หนึ่งไปยังอีก cluster หนึ่งอาจต้องการให้คุณสร้าง platform นั้นขึ้นใหม่บนปลายทางใหม่ของคุณด้วย ผมเคยคุยกับหลายองค์กรที่รับเอา Kubernetes มาใช้เป็นหลักเพราะพวกเขากังวลเรื่องการถูก lock ไว้กับ vendor รายเดียว แต่องค์กรเหล่านี้ไม่เข้าใจความละเอียดอ่อนนี้—แอปพลิเคชันที่สร้างบน Kubernetes สามารถ portable ข้าม Kubernetes cluster ได้ในทางทฤษฎี แต่ไม่เสมอไปในทางปฏิบัติ

Helm, Operators, and CRDs, Oh My! (Helm, Operator และ CRD, โอ้แม่เจ้า!)

พื้นที่หนึ่งที่ยังคงมีความสับสนต่อเนื่องในโลกของ Kubernetes คือวิธีจัดการการ deploy และ life cycle ของแอปพลิเคชันและ subsystem ของบุคคลที่สาม ลองพิจารณาความจำเป็นในการรัน Kafka บน Kubernetes cluster ของคุณ คุณสามารถสร้าง pod, service และ deployment specification ของตัวเองและรันมันเองได้ แต่แล้วเรื่องการจัดการ upgrade การตั้งค่า Kafka ของคุณล่ะ? แล้วงาน maintenance ทั่วไปอื่น ๆ ที่คุณอาจต้องจัดการ เช่น การ upgrade stateful software ที่กำลังรันอยู่ล่ะ?

เครื่องมือจำนวนหนึ่งได้เกิดขึ้นมาโดยมุ่งหมายที่จะให้คุณมีความสามารถในการจัดการแอปพลิเคชันประเภทนี้ในระดับ abstraction ที่สมเหตุสมผลมากขึ้น แนวคิดคือให้บางคนสร้างบางอย่างที่คล้าย package สำหรับ Kafka และคุณรันมันบน Kubernetes cluster ของคุณในลักษณะ black-box มากขึ้น สอง solution ที่รู้จักกันดีที่สุดในพื้นที่นี้คือ Operator และ Helm Helm ถือว่าตัวเองเป็น "the missing package manager" สำหรับ Kubernetes และในขณะที่ Operator สามารถจัดการการติดตั้งเริ่มต้นได้ มันดูเหมือนจะเน้นไปที่การจัดการอย่างต่อเนื่องของแอปพลิเคชันมากกว่า ที่น่าสับสนคือ แม้คุณจะมอง Operator และ Helm เป็นทางเลือกของกันและกันได้ คุณก็ยังสามารถใช้ทั้งสองอย่างร่วมกันได้ในบางสถานการณ์ (Helm สำหรับการติดตั้งเริ่มต้น Operator สำหรับการดำเนินงานตลอด life-cycle)

วิวัฒนาการล่าสุดในพื้นที่นี้คือสิ่งที่เรียกว่า custom resource definition หรือ CRD ด้วย CRD คุณสามารถขยาย core Kubernetes API ช่วยให้คุณเสียบพฤติกรรมใหม่เข้าไปใน cluster ของคุณได้ สิ่งที่ดีเกี่ยวกับ CRD คือมันผสานเข้ากับ command-line interface, access control และอื่น ๆ ที่มีอยู่แล้วอย่างค่อนข้างราบรื่น—ดังนั้น extension ที่คุณปรับแต่งเองจึงไม่รู้สึกเหมือนสิ่งแปลกปลอม โดยพื้นฐานแล้วมันช่วยให้คุณ implement Kubernetes abstraction ของคุณเอง ลองนึกถึง pod, replica set, service และ deployment abstraction ที่เราพูดถึงก่อนหน้านี้—ด้วย CRD คุณสามารถเพิ่ม abstraction ของคุณเองเข้าไปได้

คุณสามารถใช้ CRD สำหรับทุกอย่างตั้งแต่การจัดการชิ้นส่วนเล็ก ๆ ของ configuration ไปจนถึงการควบคุม service mesh อย่าง Istio หรือซอฟต์แวร์ที่เน้น cluster อย่าง Kafka ด้วยแนวคิดที่ยืดหยุ่นและทรงพลังขนาดนี้ ผมพบว่ามันยากที่จะเข้าใจว่า CRD ควรถูกใช้ที่ไหนดีที่สุด และดูเหมือนจะไม่มีฉันทามติทั่วไปในหมู่ผู้เชี่ยวชาญที่ผมเคยคุยด้วยเช่นกัน พื้นที่นี้ทั้งหมดดูเหมือนจะยังไม่นิ่งเร็วเท่าที่ผมหวังไว้ และไม่มีฉันทามติมากเท่าที่ผมต้องการ—ซึ่งเป็นแนวโน้มใน Kubernetes ecosystem

And Knative (และ Knative)

Knative เป็นโปรเจกต์ open source ที่มุ่งหมายจะให้ workflow แบบ FaaS-style แก่นักพัฒนา โดยใช้ Kubernetes เบื้องหลัง โดยพื้นฐานแล้ว Kubernetes ไม่ค่อยเป็นมิตรกับนักพัฒนามากนัก โดยเฉพาะเมื่อเราเทียบกับ usability ของสิ่งอย่าง Heroku หรือ platform ที่คล้ายกัน เป้าหมายของ Knative คือการนำประสบการณ์นักพัฒนาของ FaaS มาสู่ Kubernetes ซ่อนความซับซ้อนของ Kubernetes จากนักพัฒนา ในทางกลับกัน สิ่งนี้ควรหมายความว่าทีมพัฒนาสามารถจัดการ life cycle เต็มรูปแบบของซอฟต์แวร์ของพวกเขาได้ง่ายขึ้น

เราได้พูดถึง service mesh ไปแล้ว และพูดถึง Istio โดยเฉพาะ ย้อนกลับไปใน Chapter 5 Service mesh เป็นสิ่งจำเป็นสำหรับ Knative ในการรัน แม้ Knative จะในทางทฤษฎีอนุญาตให้คุณเสียบ service mesh ที่แตกต่างกันได้ มีเพียง Istio เท่านั้นที่ถือว่าเสถียรในตอนนี้ (โดย mesh อื่น ๆ อย่าง Ambassador และ Gloo ยังอยู่ใน alpha) ในทางปฏิบัติ นี่หมายความว่าถ้าคุณต้องการรับเอา Knative มาใช้ คุณจะต้องซื้อ Istio มาใช้ด้วยแล้ว

ทั้ง Kubernetes และ Istio เป็นโปรเจกต์ที่ขับเคลื่อนโดย Google เป็นหลัก ใช้เวลานานมากกว่าพวกมันจะไปถึงจุดที่ถือว่าเสถียรได้ Kubernetes ยังคงมีการเปลี่ยนแปลงครั้งใหญ่หลังจาก release เวอร์ชัน 1.0 และเมื่อไม่นานมานี้เอง Istio ซึ่งจะรองรับ Knative ก็ถูก rearchitect ใหม่ทั้งหมด ประวัติการส่งมอบโปรเจกต์ที่เสถียรและพร้อมใช้งานจริงแบบนี้ทำให้ผมคิดว่า Knative อาจใช้เวลานานกว่ามากในการพร้อมสำหรับการใช้งานของพวกเราส่วนใหญ่ แม้บางองค์กรจะใช้มันอยู่ และคุณก็อาจใช้มันได้เช่นกัน ประสบการณ์บอกว่ามันจะเป็นเพียงระยะเวลาไม่นานก่อนที่การเปลี่ยนแปลงครั้งใหญ่บางอย่างจะเกิดขึ้นซึ่งต้องการการ migration ที่เจ็บปวด ส่วนหนึ่งด้วยเหตุผลนี้ ผมจึงแนะนำให้องค์กรที่อนุรักษ์นิยมมากกว่าซึ่งกำลังพิจารณาข้อเสนอแบบ FaaS สำหรับ Kubernetes cluster ของพวกเขามองหาที่อื่น—โปรเจกต์อย่าง OpenFaaS ถูกใช้ใน production โดยองค์กรทั่วโลกอยู่แล้ว และไม่ต้องการ service mesh เบื้องล่าง แต่ถ้าคุณกระโดดขึ้นรถไฟ Knative ตอนนี้ ก็อย่าแปลกใจถ้าคุณเจอเหตุการณ์ตกรางบ้างในอนาคต

อีกข้อสังเกตหนึ่ง เป็นเรื่องน่าเสียดายที่เห็นว่า Google ตัดสินใจไม่ทำให้ Knative เป็นส่วนหนึ่งของ CNCF—เราอาจคาดเดาได้ว่านี่เป็นเพราะ Google ต้องการขับเคลื่อนทิศทางของเครื่องมือนี้ด้วยตัวเอง Kubernetes เป็นข้อเสนอที่สับสนสำหรับหลายคนเมื่อเปิดตัว ส่วนหนึ่งเพราะมันสะท้อน mindset ของ Google เกี่ยวกับวิธีที่ container ควรถูกจัดการ มันได้ประโยชน์อย่างมากจากการมีส่วนร่วมจากกลุ่มอุตสาหกรรมที่กว้างขึ้น และน่าเสียดายที่อย่างน้อยในขั้นตอนนี้ Google ตัดสินใจว่าไม่สนใจการมีส่วนร่วมจากอุตสาหกรรมในวงกว้างแบบเดียวกันสำหรับ Knative

The Future (อนาคต)

เมื่อมองไปข้างหน้า ผมไม่เห็นสัญญาณใด ๆ ว่ารถไฟด่วนของ Kubernetes จะหยุดในเร็ว ๆ นี้ และผมคาดหวังอย่างเต็มที่ว่าจะเห็นองค์กรมากขึ้นเรื่อย ๆ implement Kubernetes cluster ของตัวเองสำหรับ private cloud หรือใช้ managed cluster ใน public cloud setting อย่างไรก็ตาม ผมคิดว่าสิ่งที่เรากำลังเห็นตอนนี้ ที่นักพัฒนาต้องเรียนรู้วิธีใช้ Kubernetes โดยตรง จะเป็นช่วงเวลาสั้น ๆ ค่อนข้างมาก Kubernetes ยอดเยี่ยมในการจัดการ container workload และให้ platform สำหรับสร้างสิ่งอื่น ๆ ต่อไป แต่มันไม่ใช่สิ่งที่ถือได้ว่าเป็นประสบการณ์ที่เป็นมิตรกับนักพัฒนา Google เองได้แสดงให้เราเห็นเรื่องนี้ด้วยการผลักดัน Knative และผมคิดว่าเราจะยังคงเห็น Kubernetes ถูกซ่อนอยู่ใต้ higher-level abstraction layer ต่อไปเรื่อย ๆ ดังนั้นในอนาคต ผมคาดว่า Kubernetes จะอยู่ทุกที่ คุณแค่จะไม่รู้ตัว

นี่ไม่ได้หมายความว่านักพัฒนาสามารถลืมไปได้ว่าพวกเขากำลังสร้าง distributed system พวกเขายังคงต้องเข้าใจความท้าทายมากมายที่สถาปัตยกรรมประเภทนี้นำมา เพียงแต่พวกเขาจะไม่ต้องกังวลมากนักเกี่ยวกับรายละเอียดว่าซอฟต์แวร์ของพวกเขาถูก map ไปยัง computing resource เบื้องล่างอย่างไร

Should You Use It? (คุณควรใช้มันไหม?)

ดังนั้น สำหรับพวกคุณที่ยังไม่ได้เป็นสมาชิกเต็มตัวของชมรม Kubernetes คุณควรเข้าร่วมไหม? ผมมีแนวทางบางอย่างมาแชร์ อย่างแรก การ implement และจัดการ Kubernetes cluster ของตัวเองไม่ใช่สิ่งที่เหมาะสำหรับคนใจไม่สู้—มันเป็นภารกิจที่ใหญ่มาก คุณภาพประสบการณ์ที่นักพัฒนาของคุณจะได้รับจากการติดตั้ง Kubernetes ของคุณส่วนใหญ่จะขึ้นอยู่กับประสิทธิภาพของทีมที่รัน cluster ด้วยเหตุนี้ องค์กรขนาดใหญ่หลายแห่งที่ผมเคยคุยด้วยที่เดินหน้าไปทาง Kubernetes on-prem ได้ outsource งานนี้ไปยังบริษัทที่เชี่ยวชาญเฉพาะทาง

ยิ่งดีไปกว่านั้น ใช้ managed cluster เต็มรูปแบบ ถ้าคุณสามารถใช้ public cloud ได้ ก็ใช้ managed solution เต็มรูปแบบอย่างที่จัดหาโดย Google, Azure และ AWS สิ่งที่ผมอยากพูดถึง อย่างไรก็ตาม คือถ้าคุณสามารถใช้ public cloud ได้ ก็ควรพิจารณาว่า Kubernetes เป็นสิ่งที่คุณต้องการจริง ๆ หรือไม่ ถ้าคุณกำลังมองหา platform ที่เป็นมิตรกับนักพัฒนาสำหรับจัดการการ deploy และ life cycle ของ microservices ของคุณ FaaS platform ที่เราได้ดูไปแล้วอาจเป็นตัวเลือกที่ยอดเยี่ยม คุณยังสามารถดูข้อเสนอแบบ PaaS อื่น ๆ เช่น Azure Web Apps, Google App Engine หรือ provider เล็ก ๆ บางเจ้าอย่าง Zeit หรือ Heroku

ก่อนที่คุณจะตัดสินใจเริ่มใช้ Kubernetes ให้ administrator และนักพัฒนาบางคนของคุณลองใช้มันก่อน นักพัฒนาสามารถเริ่มต้นด้วยการรันบางอย่างที่เบา ๆ ในเครื่อง เช่น minikube หรือ MicroK8s ที่ให้พวกเขาได้ประสบการณ์ที่ใกล้เคียงกับ Kubernetes เต็มรูปแบบ แต่บน laptop ของพวกเขา คนที่คุณจะให้จัดการ platform อาจต้องดำดิ่งลงไปลึกกว่า Katacoda มี online tutorial ที่ยอดเยี่ยมสำหรับการทำความเข้าใจแนวคิดหลัก และ CNCF ช่วยผลิตสื่อการฝึกอบรมจำนวนมากในพื้นที่นี้ ให้แน่ใจว่าคนที่จะใช้สิ่งนี้จริง ๆ ได้ลองเล่นกับมันก่อนที่คุณจะตัดสินใจ

อย่าติดกับดักความคิดว่าคุณต้องมี Kubernetes "เพราะทุกคนก็ทำแบบนั้น" นี่เป็นเหตุผลที่อันตรายพอ ๆ กันในการเลือก Kubernetes เช่นเดียวกับการเลือก microservices แม้ Kubernetes จะดีแค่ไหน มันก็ไม่ได้เหมาะกับทุกคน—ทำการประเมินของตัวเองให้ดี แต่ให้พูดตรง ๆ กันเถอะ—ถ้าคุณมีนักพัฒนาเพียงหยิบมือและมี microservices เพียงไม่กี่ตัว Kubernetes น่าจะเกินความจำเป็นไปมาก แม้จะใช้ platform ที่ managed เต็มรูปแบบก็ตาม