ในรอบ 1-2 ปีนี้ ชื่อเทคโนโลยีฝั่งเซิร์ฟเวอร์ที่พบเห็นได้บ่อยมากคือคำว่า Kubernetes ที่แค่เห็นก็อ่านไม่ออกแล้วว่าออกเสียงอย่างไร (อ่านว่า "คูเบอร์เนเตส") แต่ความร้อนแรงของมันถึงขั้นพลิกโฉมสถาปัตยกรรมของระบบโครงสร้างพื้นฐานทางไอที (infrastructure) ไปอย่างสิ้นเชิง
Kubernetes เป็นซอฟต์แวร์สำหรับ Container Orchestration (คำเดียวกับ "วงออเคสตร้า") ถ้าให้อธิบายแบบสั้นๆ มันคือซอฟต์แวร์ที่ใช้จัดการและควบคุม "วงดนตรีคอนเทนเนอร์" นั่นเอง ส่วนคำอธิบายแบบยาวๆ สามารถอ่านได้จากบทความนี้ครับ
ในบทความตอนที่แล้ว เราอธิบายถึง "คอนเทนเนอร์" ว่ามันคืออะไร (รู้จัก Container มันคืออะไร แตกต่างจาก Virtualization อย่างไร?)
เทคโนโลยีคอนเทนเนอร์ถูกสร้างขึ้นมาเพื่อให้เราจัดการแพ็กเกจซอฟต์แวร์ที่จำเป็น และขนย้ายมันไปใช้ตามที่ต่างๆ ได้ง่ายขึ้น เหมือนกับจับของใส่ตู้คอนเทนเนอร์แล้วขนขึ้นเรือหรือรถบรรทุกก็ได้
แต่การจะนำคอนเทนเนอร์ไปใช้งานอย่างไร ถือเป็นอิสระเต็มที่ของผู้ใช้งาน ซึ่งเราสามารถรันคอนเทนเนอร์ในเครื่องโลคอล (นักพัฒนาทดสอบโค้ดตัวเองบนเครื่องตัวเอง) หรือรันบนเซิร์ฟเวอร์แบบดั้งเดิม (bare metal) ก็ได้ทั้งนั้น
ในโลกยุคคลาวด์ เราสามารถเช่าเซิร์ฟเวอร์ใหม่ขึ้นมาได้ทันทีตามความต้องการของผู้ใช้ การเช่าเครื่องเสมือนจำนวนมากๆ แล้วมาต่อเชื่อมกันเป็นคลัสเตอร์เพื่อขยายตัว รองรับโหลดจำนวนมหาศาล เป็นเรื่องปกติที่ทำกันทั่วไป
เมื่อเรานำเทคโนโลยี "คอนเทนเนอร์" ในฝั่งแอพพลิเคชัน มาจับคู่กับ "คลัสเตอร์" ในฝั่งของโครงสร้างพื้นฐานที่รันงานเหล่านั้น หน้าที่บริหารจัดการตรงนี้คือคำว่า Orchestration นั่นเอง (บางครั้งก็ใช้คำว่า container management)
ในอดีต การนำแอพพลิเคชันที่พัฒนาเสร็จแล้วไปรันบนเครื่องจริง (deployment) เป็นกระบวนการที่ซับซ้อน และต้องพึ่งพางานแบบ manual ซะเยอะ ผู้ดูแลระบบมักต้องเขียนสคริปต์กันเอง ซึ่งมีข้อผิดพลาดได้ง่าย ยิ่งการรันบนคลัสเตอร์ที่มีเครื่องจำนวนมาก ต้องย้ายงานไปมา ต้องขยายตัวหรือหดตัวตามความต้องการของลูกค้า ยิ่งก่อให้เกิดความซับซ้อนมากขึ้นเป็นทวีคูณ
หลายปีที่ผ่านมาจึงมีความพยายามแก้ปัญหานี้จากหลายฝ่าย รายที่โดดเด่นมีด้วยกัน 3 ค่ายคือ
แนวคิดทางเทคนิคของซอฟต์แวร์ orchestration แต่ละรายมีความแตกต่างกันอยู่บ้าง
กรณีของ Apache Mesos สร้างขึ้นก่อนเป็นรายแรก (เริ่มในปี 2009) และออกแบบมาจัดการคลัสเตอร์อะไรก็ได้ ไม่จำเป็นต้องเป็นคอนเทนเนอร์อย่างเดียว ภายหลังจึงมีซอฟต์แวร์ Marathon มาเสริมเรื่องการจัดการคอนเทนเนอร์ ในขณะที่บริษัท Mesosphere นำ Mesos ไปปรับแต่งเป็นซอฟต์แวร์เชิงพาณิชย์ และเรียกชื่อว่า DC/OS (ย่อมาจาก Datacenter OS) แสดงให้เห็นถึงการเน้นเรื่องการจัดการศูนย์ข้อมูลเป็นหลัก
ส่วน Docker Swarm เริ่มออกเวอร์ชันแรกๆ ในปี 2015 โดยเป็นส่วนต่อขยายตามธรรมชาติของ Docker Container ของบริษัท Docker Inc. ที่เอาชนะสงครามคอนเทนเนอร์ได้อย่างเบ็ดเสร็จ (อีกฝ่ายคือ Rocket หรือ rkt ของ CoreOS)
แน่นอนว่ามาถึงตอนนี้ เรารู้แล้วว่าผู้ชนะสงคราม orchestration คือ Kubernetes ของกูเกิล ดังนั้นมาย้อนประวัติของมันแบบละเอียดกันสักหน่อย
ชื่อ Kubernetes มาจากภาษากรีก κυβερνήτης ซึ่งแปลเป็นภาษาอังกฤษได้ว่า helmsman หรือ "กัปตันเรือ" จึงเป็นที่มาของโลโก้รูปพวงมาลัยเรือ (คำว่า Kubernetes มีรากศัพท์มาจากคำเดียวกับคำว่า Governor ด้วย) แต่เนื่องจากชื่อโครงการค่อนข้างยาว เรียกยาก ในวงการเลยมักเรียกกันย่อๆ ว่า K8s หรือบ้างก็เรียก Kube
Kubernetes เปิดตัวต่อสาธารณะครั้งแรกในเดือนมิถุนายน 2014 (เป็นข่าวใน Blognone ครั้งแรกเดือนกรกฎาคม 2014) แต่ประวัติของมันยาวนานกว่านั้น
กูเกิลมีธรรมเนียมการสร้างซอฟต์แวร์เพื่อใช้เองภายในอยู่แล้ว และมีระบบจัดการคอนเทนเนอร์ของตัวเองเรียกว่า Borg (มาจากเผ่าเอเลี่ยนกึ่งหุ่นยนต์ในซีรีส์ Star Trek) ซึ่งทำงานอยู่บน cgroups ฟีเจอร์ของเคอร์เนลลินุกซ์ และเป็นต้นแบบของคอนเทนเนอร์ในยุคปัจจุบัน
Borg วิวัฒนาการมาเรื่อยๆ โดยไม่ได้คำนึงถึงการออกแบบสถาปัตยกรรมมาตั้งแต่ต้น เพราะเน้นสร้างฟีเจอร์ใหม่ตามความต้องการของทีมงานภายในแต่ละทีม สุดท้าย Borg จึงไปต่อไม่ไหว กูเกิลจึงสร้างซอฟต์แวร์ตัวใหม่ขึ้นมาแทนโดยใช้ชื่อว่า Omega
Omega นำแนวคิดหลายอย่างจาก Borg มาใช้งาน แล้วเพิ่มระบบการเก็บสถานะของคลัสเตอร์ไว้ที่ส่วนกลางเพื่อป้องกันข้อมูลขัดแย้งกันเอง
เมื่อเทคโนโลยีคอนเทนเนอร์เริ่มได้รับความนิยม และกูเกิลเองก็มีบริการลักษณะนี้ต่อลูกค้าภายนอกบริษัท (Google Cloud Platform) วิศวกรกลุ่มหนึ่งของกูเกิลจึงตัดสินใจสร้างโครงการแบบนี้ขึ้นมาใหม่อีกครั้ง ซึ่งก็คือ Kubernetes
เนื่องจาก Kubernetes สืบทอดแนวคิดหลายอย่างมาจาก Borg ในช่วงแรก โครงการจึงมีโค้ดเนมว่า Project Seven ซึ่งมาจากตัวละคร Seven of Nine บอร์กสาวจากเรื่อง Star Trek เช่นกัน (และเป็นเหตุผลว่าทำไมไอคอนพวงมาลัยเรือถึงมี 7 แกน)
Kubernetes ได้รับความนิยมอย่างรวดเร็ว และได้รับการสนับสนุนจากบริษัทยักษ์ใหญ่อย่าง Microsoft, Red Hat, IBM จนเมื่อกูเกิลออก Kubernetes 1.0 ในเดือนกรกฎาคม 2015 ก็ตัดสินใจตั้งมูลนิธิ Cloud Native Computing Foundation (CNCF) มาดูแลโครงการต่อแทน
หมายเหตุ: ประวัติอย่างละเอียดของ Borg, Omega, Kubernetes สามารถอ่านได้จากบทความ Borg, Omega, and Kubernetes ที่เขียนโดยทีมงานของกูเกิลผู้ร่วมก่อตั้ง Kubernetes
เนื่องจากบทความนี้ไม่ใช่บทความสอนการใช้งานเชิงเทคนิค จึงอธิบายแนวคิดของ Kubernetes เพียงคร่าวๆ เพื่อให้เห็นภาพเท่านั้น รายละเอียดอื่นๆ สามารถอ่านได้จากเว็บไซต์ Kubernetes
สถาปัตยกรรมคลัสเตอร์ของ Kubernetes ไม่ต่างอะไรจากคลัสเตอร์ทั่วๆ ไป นั่นคือมีเครื่องที่เป็น Master และ Slave (ในโลกของ Kubernetes ใช้คำว่า Node) โดยในแต่ละโหนดติดตั้งซอฟต์แวร์ Kubelet เพื่อบริหารจัดการ
จากนั้นเมื่อเรานำแอพในคอนเทนเนอร์ไปรันบนคลัสเตอร์ (deploy) ระบบของ Kubernetes จะสื่อสารกันระหว่าง Master/Node เพื่อนำงานไปรันบนเครื่องให้เราเอง
แนวคิดสำคัญของ Kubernetes คือคำว่า Pod เปรียบเสมือนเป็นก้อนรวมของสิ่งที่จำเป็นทั้งหมดในการรันแอพพลิเคชัน ประกอบด้วยตัวแอพเอง (ที่อยู่ในคอนเทนเนอร์) และสตอเรจ (Volume) โดย Pod แต่ละก้อนมีหมายเลขไอพีของตัวเอง
ในเครื่องแต่ละ Node จึงสามารถมีงานไปรันได้หลาย Pod ตามภาพ
นอกจาก Pod แล้ว โลกของ Kubernetes ยังมีแนวคิดเรื่อง Services หรือการจัดกลุ่ม Node/Pod จำนวนมากๆ เข้าด้วยกัน แอพพลิเคชันหนึ่งตัวสามารถแบ่งได้เป็นหลาย Pod และรันอยู่บนหลาย Node ดังนั้น การสเกลให้รองรับโหลดที่เพิ่มขึ้นจึงทำได้ง่าย เพราะมีแนวคิดเชิง abstraction คือ Node/Pod/Service มาคอยช่วยนั่นเอง
นอกจากนี้ Kubernetes ยังมีฟีเจอร์อื่นๆ อีกมาก เช่น การอัพเดตข้อมูลในคอนเทนเนอร์ (เปลี่ยนเวอร์ชันของไลบรารีหรือโค้ด), การ rollback กลับไปเวอร์ชันเดิมเมื่อเกิดปัญหา และการทำ Continuous Integration and Continuous Delivery (CI/CD) ซึ่งจะไม่กล่าวถึงในบทความนี้
ชัยชนะของ Kubernetes มาจากปัจจัยหลายประการ ในแง่เทคนิค มันสืบทอดสถาปัตยกรรมภายในของกูเกิลที่ผ่านการทดสอบงานจริง รองรับโหลดหนักๆ ระดับกูเกิลมาได้แล้ว (Pokemon Go ก็รันอยู่บน Kubernetes) บวกกับมีจุดสมดุลที่พอดีระหว่างฟีเจอร์และความซับซ้อนในการดูแล เมื่อเปรียบเทียบกับคู่แข่งอย่าง Docker Swarm ที่อาจใช้ง่ายกว่า แต่ความสามารถด้อยกว่า ส่วน Apache Mesos ก็มีความซับซ้อนสูงมาก
ปัจจัยเรื่องพันธมิตรร่วมรบก็มีความสำคัญไม่แพ้กัน Kubernetes เป็นโครงการของกูเกิล ย่อมได้รับการสนับสนุนจากกูเกิลอย่างเต็มที่มาตั้งแต่แรก แถมยังได้พันธมิตรระดับบิ๊กอย่าง IBM หรือ Red Hat เข้าร่วมด้วยตั้งแต่ยุคแรกๆ
พันธมิตรของ Kubernetes ที่น่าสนใจคือไมโครซอฟท์ ช่วงแรกที่กระแส container orchestration เริ่มมาแรง แต่ยังไม่ปรากฏผู้ชนะที่ชัดเจน ไมโครซอฟท์ก็ใช้วิธีสนับสนุนทุกฝ่ายแล้วรอดูว่าใครจะชนะ โดยการเข้าลงทุนในบริษัท Mesosphere เมื่อปี 2016 และเปิดตัวบริการ Azure Container Service (ACS) ที่รองรับทั้ง Mesos และ Docker Swarm
แต่พอมาถึงปี 2017 เมื่อชัยชนะของ Kubernetes เริ่มปรากฏชัด ไมโครซอฟท์ก็เปลี่ยนใจกันง่ายๆ เปลี่ยนชื่อ Azure Container Service (ACS) เป็น Azure Kubernetes Service (AKS) และหันมาเลือกข้าง Kubernetes เต็มตัว (ปัจจุบันถ้าเข้าหน้าเว็บ ACS จะถูก redirect มายัง AKS แทน และ ACS ยังมีให้ใช้งานอยู่บน Azure Marketplace แต่ก็ไม่เน้นแล้ว)
ไมโครซอฟท์ยังจ้าง Brendan Burns หนึ่งในผู้ร่วมก่อตั้ง Kubernetes มาทำงานด้วย เรียกได้ว่าดึงตัวมาจากกูเกิลกันตรงๆ เพื่อมารับผิดชอบงานด้าน Kubernetes โดยเฉพาะ แสดงให้เห็นถึงความสำคัญของ Kubernetes ในสายตาไมโครซอฟท์ได้เป็นอย่างดี
อีกตัวอย่างที่น่าสนใจไม่แพ้กันคือ AWS ที่ช่วงแรกๆ อินดี้ไม่สนใจใคร สร้างระบบ orchestration ของตัวเองขึ้นมาโดยไม่ยุ่งกับใคร โดยใช้ชื่อว่า Amazon Elastic Container Service (ECS) และผูกกับเทคโนโลยีของ AWS อย่างแนบแน่น
แต่เมื่อ Kubernetes เริ่มดังขึ้นมา AWS ก็ออกบริการใหม่อีกตัวคือ Amazon Elastic Container Service for Kubernetes (EKS) ขึ้นมาให้เลือกใช้งานได้ตามชอบ (อย่างไรก็ตาม ECS ใช้ฟรี แต่ EKS คิดเงิน)
ทั้งไมโครซอฟท์และ AWS ต่างก็สมัครเข้าร่วมเป็นสมาชิก Cloud Native Computing Foundation (CNCF) ในช่วงกลางปี 2017 เป็นสัญญาณว่าผู้ให้บริการคลาวด์รายใหญ่ต่างยอมสยบให้กับ Kubernetes แล้ว
แต่จุดสิ้นสุดสงครามคือเดือนตุลาคม 2017 ที่ Docker ประกาศความพ่ายแพ้ ทานกระแสไม่ไหว ต้องยอมซัพพอร์ต Kubernetes นอกเหนือจาก Docker Swarm ของตัวเอง (หลังจากดึงดัน พยายามต่อสู้มานาน) ถึงแม้ในแถลงการณ์ของ Docker จะบอกว่า "ผู้ใช้มีสิทธิเลือก" ว่าจะใช้ตัวไหน แต่ก็สะท้อนว่าถ้าสู้เขาไม่ได้ เข้าร่วมดีกว่านั่นเอง
ฝั่งของ Apache Mesos ก็ไม่ใช่คู่แข่งตรงๆ ของ Kubernetes และสามารถทำงานด้วยกันได้ โดยบริษัท Mesosphere เองก็มีผลิตภัณฑ์ Mesosphere Kubernetes Engine (MKE) ออกมาจับตลาดเช่นกัน
มาถึงตอนนี้โลก container orchestration ได้คำตอบชัดเจนแล้วว่า ถ้าต้องการ container ให้ใช้ Docker และถ้าต้องการ orchestration ให้ใช้ Kubernetes
ในการใช้งานจริง Kubernetes ประกอบด้วยโครงการย่อยๆ มากมาย การใช้ซอฟต์แวร์จากโครงการโอเพนซอร์สต้นน้ำ (เช่น ระบบมอนิเตอร์ Prometheus) จึงต้องใช้ความรู้ความเชี่ยวชาญสูง
ตรงนี้จึงเกิด Kubernetes Distribution หรือเทียบได้กับ "ดิสโทร" ของลินุกซ์ ที่เป็นการรวบรวมซอฟต์แวร์ที่จำเป็น และเครื่องมืออำนวยความสะดวกอื่นๆ มาให้พร้อมสรรพ ติดตั้งแล้วใช้งานได้ทันที
ตัวอย่าง Kubernetes Distribution แบบง่ายๆ ได้แก่ Minikube ที่เน้นการใช้งานบนเครื่องตัวเอง (คลัสเตอร์มีเครื่องเราเครื่องเดียว) เหมาะสำหรับการทดสอบและลองใช้งาน
ปัจจุบัน บริษัทไอทียักษ์ใหญ่ที่มีธุรกิจด้านศูนย์ข้อมูล-คลาวด์ ต่างก็มี Kubernetes Distribution เวอร์ชันของตัวเองไว้บริการลูกค้า โดยใช้ชื่อเชิงพาณิชย์แตกต่างกันไป (บางครั้งถ้าไม่บอกก็ไม่รู้ว่ามันคือ Kubernetes) เช่น
โซลูชันเหล่านี้สามารถรันได้ทั้งบนคลาวด์แบบสาธารณะ (public cloud) หรือเครื่องขององค์กรเอง (private cloud/on premise)
ส่วนผู้ให้บริการคลาวด์แบบสาธารณะ (public cloud) รายใหญ่ ต่างก็มีบริการ Kubernetes ให้บริการเช่นกัน
รายชื่อทั้งหมดดูได้จาก Kubernetes Partners
แน่นอนว่า Kubernetes (หรือ container orchestration) ไม่ใช่โซลูชันที่เหมาะสำหรับทุกคน แถมการใช้งานยังต้องแลกมาด้วยความซับซ้อนของระบบที่เพิ่มจากเดิมมาก
รูปแบบงานที่เหมาะสมกับการทำ container orchestration จึงควรมีปัจจัยเหล่านี้
สรุปง่ายๆ ว่าถ้างานของเรา "ไม่ใหญ่พอ" ที่จะต้องใช้ Kubernetes ก็ไม่จำเป็นต้องใช้ Kubernetes นั่นเอง
ซอฟต์แวร์อย่าง Kubernetes เกิดขึ้นมาสำหรับยุคของคลาวด์ จึงเกิดคำเรียกซอฟต์แวร์กลุ่มนี้ว่า Cloud Native
กูเกิลเองก็ใช้คำนี้ไปตั้งชื่อมูลนิธิ Cloud Native Computing Foundation (CNCF) ซึ่งนอกจาก Kubernetes แล้ว ยังมีซอฟต์แวร์ตัวอื่นๆ ที่เกี่ยวข้องกันอีกหลายตัว เช่น
นอกจากนี้ยังมีซอฟต์แวร์ตัวอื่นๆ ที่อยู่นอก CNCF แต่พัฒนาโดยกูเกิลและพันธมิตร เช่น Istio ที่ร่วมกับ IBM และ Red Hat โดยเรียกใช้ซอฟต์แวร์บางตัวจาก CNCF เช่น Envoy อีกทีหนึ่ง
ซอฟต์แวร์เหล่านี้นำมาใช้ร่วมกันเพื่อให้การสร้าง container orchestration สมบูรณ์แบบมากขึ้น เพิ่มส่วนการบริหารจัดการ, monitoring, logging เข้ามา และการวางโครงสร้างพื้นฐานด้านการประมวลผลยุคคลาวด์ในอนาคต ซึ่งถ้ามีโอกาส เราจะหยิบมันมาเล่าถึงต่อไป