🥇ตัวดำเนินการสำหรับ Kubernetes: วิธีเรียกใช้แอปพลิเคชันที่มีสถานะ

ปัญหาเกี่ยวกับแอปพลิเคชัน stateful ใน Kubernetes

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

พูดง่ายๆ ก็คือ หากต้องการเปิดตัวแบ็กเอนด์อีกห้าชุดใน PHP/Ruby/Python ในกลุ่มคอนเทนเนอร์ คุณเพียงแค่ต้องตั้งค่าเซิร์ฟเวอร์ใหม่ 5 ครั้งแล้วคัดลอกแหล่งที่มา เนื่องจากทั้งซอร์สโค้ดและสคริปต์เริ่มต้นอยู่ในรูปภาพ การปรับขนาดแอปพลิเคชันไร้สัญชาติจึงกลายเป็นเรื่องพื้นฐานโดยสิ้นเชิง ตามที่แฟน ๆ ของคอนเทนเนอร์และสถาปัตยกรรมไมโครเซอร์วิสรู้ดีว่าความยากลำบากเริ่มต้นขึ้นด้วย แอปเก็บสถานะ, เช่น. ด้วยความคงอยู่ของข้อมูล เช่น ฐานข้อมูลและแคช (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...) สิ่งนี้ใช้ได้กับทั้งซอฟต์แวร์ที่ใช้คลัสเตอร์ควอรัมอย่างอิสระ (เช่น Percona XtraDB และ Cassandra) และซอฟต์แวร์ที่ต้องใช้ยูทิลิตีการจัดการแยกต่างหาก (เช่น Redis, MySQL, PostgreSQL...)

ความยากลำบากเกิดขึ้นเนื่องจากซอร์สโค้ดและการเปิดตัวบริการไม่เพียงพออีกต่อไป - คุณต้องดำเนินการขั้นตอนเพิ่มเติม อย่างน้อยที่สุด ให้คัดลอกข้อมูลและ/หรือเข้าร่วมคลัสเตอร์ แม่นยำยิ่งขึ้น บริการเหล่านี้จำเป็นต้องมีความเข้าใจเกี่ยวกับวิธีการปรับขนาด อัปเดต และกำหนดค่าใหม่อย่างเหมาะสม โดยไม่สูญเสียข้อมูลหรือใช้งานไม่ได้ชั่วคราว การพิจารณาความต้องการเหล่านี้เรียกว่า "ความรู้เชิงปฏิบัติ"

ตัวดำเนินการ CoreOS

เพื่อที่จะ "โปรแกรม" ความรู้ในการดำเนินงานโครงการ CoreOS เมื่อปลายปีที่แล้ว ส่ง “ ซอฟต์แวร์ระดับใหม่” สำหรับแพลตฟอร์ม Kubernetes - ตัวดำเนินการ (จากภาษาอังกฤษว่า "การทำงาน" เช่น "การทำงาน")

ผู้ปฏิบัติงานที่ใช้และขยายความสามารถหลักของ Kubernetes (รวมถึง ชุดเก็บสถานะดูความแตกต่างด้านล่าง) อนุญาตให้ผู้เชี่ยวชาญ DevOps เพิ่มความรู้ด้านการปฏิบัติงานให้กับโค้ดของแอปพลิเคชัน

วัตถุประสงค์ของผู้ประกอบการ — มอบ API ให้กับผู้ใช้ที่ช่วยให้คุณจัดการเอนทิตีแอปพลิเคชันที่มีสถานะหลายรายการในคลัสเตอร์ Kubernetes โดยไม่ต้องคำนึงถึงสิ่งที่อยู่ภายใต้ประทุน (ข้อมูลอะไรและจะทำอย่างไรกับมัน คำสั่งใดที่ยังต้องดำเนินการเพื่อรักษาคลัสเตอร์ ). อันที่จริง Operator ได้รับการออกแบบมาเพื่อทำให้การทำงานกับแอปพลิเคชันภายในคลัสเตอร์ง่ายขึ้นมากที่สุดเท่าที่จะเป็นไปได้ ทำให้การปฏิบัติงานที่ต้องแก้ไขด้วยตนเองก่อนหน้านี้เป็นไปโดยอัตโนมัติ

ผู้ประกอบการทำงานอย่างไร

ชุดแบบจำลอง Kubernetes ช่วยให้คุณระบุจำนวนพ็อดที่ทำงานอยู่ที่ต้องการได้ และผู้ควบคุมจะดูแลให้แน่ใจว่าหมายเลขนั้นยังคงอยู่ (โดยการสร้างและการลบพ็อด) ตัวดำเนินการทำงานในลักษณะเดียวกัน โดยเพิ่มชุดความรู้ด้านการปฏิบัติงานให้กับทรัพยากรและตัวควบคุม Kubernetes มาตรฐาน ซึ่งช่วยให้คุณสามารถดำเนินการเพิ่มเติมเพื่อรองรับเอนทิตีแอปพลิเคชันตามจำนวนที่ต้องการ

สิ่งนี้แตกต่างอย่างไรกับ ชุดเก็บสถานะออกแบบมาสำหรับแอปพลิเคชันที่ต้องการคลัสเตอร์เพื่อจัดเตรียมทรัพยากรแบบมีสถานะ เช่น พื้นที่จัดเก็บข้อมูลหรือ IP แบบคงที่ สำหรับการใช้งานดังกล่าว Operators สามารถใช้ ชุดเก็บสถานะ (แทน ชุดแบบจำลอง) เป็นพื้นฐานการเสนอขาย ระบบอัตโนมัติเพิ่มเติม: ดำเนินการที่จำเป็นในกรณีที่เกิดข้อขัดข้อง ทำการสำรองข้อมูล อัปเดตการกำหนดค่า ฯลฯ

ดังนั้น ทั้งหมดนี้ทำงานยังไง? ตัวดำเนินการเป็น daemon ผู้จัดการที่:

สมัครรับเหตุการณ์ API ใน Kubernetes
รับข้อมูลเกี่ยวกับระบบจากมัน (ประมาณ ชุดแบบจำลอง, ฝัก, บริการ และอื่นๆ.);
รับข้อมูลเกี่ยวกับ ทรัพยากรของบุคคลที่สาม (ดูตัวอย่างด้านล่าง);
ตอบสนองต่อรูปลักษณ์/การเปลี่ยนแปลง ทรัพยากรของบุคคลที่สาม (เช่น เปลี่ยนขนาด เปลี่ยนเวอร์ชัน และอื่นๆ)
ตอบสนองต่อการเปลี่ยนแปลงสถานะของระบบ (ประมาณ ชุดแบบจำลอง, ฝัก, บริการ และอื่นๆ.);
สำคัญที่สุด:
1. เรียกใช้ Kubernetes API เพื่อสร้างทุกสิ่งที่ต้องการ (อีกครั้งเป็นของตัวเอง ชุดแบบจำลอง, ฝัก, บริการ...),
2. ทำเวทย์มนตร์บางอย่าง (เพื่อให้ง่ายขึ้น คุณอาจคิดว่าตัวดำเนินการเข้าไปในพ็อดเองและเรียกคำสั่ง เช่น เข้าร่วมคลัสเตอร์หรืออัปเกรดรูปแบบข้อมูลเมื่ออัปเดตเวอร์ชัน)

ในความเป็นจริง ดังที่เห็นจากรูปภาพ แอปพลิเคชันแยกต่างหากจะถูกเพิ่มลงใน Kubernetes (แอปพลิเคชันปกติ) การใช้งาน с ชุดแบบจำลอง) ซึ่งเรียกว่าตัวดำเนินการ มันอาศัยอยู่ในฝักธรรมดา (โดยปกติจะมีเพียงฝักเดียว) และตามกฎแล้วจะต้องรับผิดชอบเพียงฝักเดียวเท่านั้น namespace. แอปพลิเคชันตัวดำเนินการนี้ใช้ API แม้ว่าจะไม่ใช่โดยตรง แต่ผ่าน ทรัพยากรของบุคคลที่สาม ในคูเบอร์เนเตส

ดังนั้นหลังจากที่เราได้สร้างมาแล้ว namespace โอเปอเรเตอร์เราสามารถเพิ่มเข้าไปได้ ทรัพยากรของบุคคลที่สาม.

ตัวอย่างสำหรับ ฯลฯ (ดูรายละเอียดด้านล่าง):

apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
  name: example-etcd-cluster
spec:
  size: 3
  version: 3.1.0

ตัวอย่างสำหรับ Elasticsearch:

apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
  name: example-es-cluster
spec:
  client-node-replicas: 3
  master-node-replicas: 2
  data-node-replicas: 3
  zones:
  - us-east-1c
  - us-east-1d
  - us-east-1e
  data-volume-size: 10Gi
  java-options: "-Xms1024m -Xmx1024m"
  snapshot:
    scheduler-enabled: true
    bucket-name: elasticsnapshots99
    cron-schedule: "@every 2m"
  storage:
    type: gp2
    storage-class-provisioner: kubernetes.io/aws-ebs

ข้อกำหนดสำหรับผู้ปฏิบัติงาน

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

การติดตั้งจะต้องทำผ่านระบบเดียว การใช้งาน: kubectl สร้าง -f SOME_OPERATOR_URL/deployment.yaml - และไม่ต้องการการดำเนินการเพิ่มเติม
เมื่อติดตั้ง Operator ใน Kubernetes จะต้องสร้างประเภทบุคคลที่สามใหม่ (ทรัพยากรของบุคคลที่สาม). หากต้องการเปิดใช้อินสแตนซ์แอปพลิเคชัน (อินสแตนซ์คลัสเตอร์) และจัดการเพิ่มเติม (การอัปเดตเวอร์ชัน การปรับขนาด ฯลฯ) ผู้ใช้จะใช้ประเภทนี้
เมื่อใดก็ตามที่เป็นไปได้ คุณควรใช้พื้นฐานที่มีอยู่ใน Kubernetes เช่น บริการ и ชุดแบบจำลองเพื่อใช้โค้ดที่ได้รับการทดสอบอย่างดีและเข้าใจได้
ต้องการความเข้ากันได้แบบย้อนหลังของตัวดำเนินการและการสนับสนุนสำหรับทรัพยากรที่ผู้ใช้สร้างขึ้นเวอร์ชันเก่า
หากตัวดำเนินการถูกลบ ตัวแอปพลิเคชันควรจะทำงานต่อไปโดยไม่มีการเปลี่ยนแปลง
ผู้ใช้ควรจะสามารถกำหนดเวอร์ชันของแอปพลิเคชันที่ต้องการและประสานการอัปเดตเวอร์ชันของแอปพลิเคชันได้ การขาดการอัปเดตซอฟต์แวร์เป็นสาเหตุที่พบบ่อยของปัญหาการปฏิบัติงานและความปลอดภัย ดังนั้นผู้ให้บริการจะต้องช่วยเหลือผู้ใช้ในเรื่องนี้
ผู้ปฏิบัติงานควรได้รับการทดสอบด้วยเครื่องมือเช่น Chaos Monkey ซึ่งระบุความล้มเหลวที่อาจเกิดขึ้นในพ็อด การกำหนดค่า และเครือข่าย

ตัวดำเนินการ ฯลฯ

ตัวอย่างการใช้งานตัวดำเนินการ - ตัวดำเนินการ ฯลฯ เตรียมไว้ ในวันประกาศแนวคิดนี้ การกำหนดค่าคลัสเตอร์ ฯลฯ อาจมีความซับซ้อนเนื่องจากจำเป็นต้องรักษาองค์ประชุม จำเป็นต้องกำหนดค่าความเป็นสมาชิกคลัสเตอร์ใหม่ สร้างการสำรองข้อมูล ฯลฯ ตัวอย่างเช่น การปรับขนาดคลัสเตอร์ ฯลฯ ด้วยตนเองหมายความว่าคุณต้องสร้างชื่อ DNS สำหรับสมาชิกคลัสเตอร์ใหม่ เริ่มต้นเอนทิตี ฯลฯ ใหม่ และแจ้งเตือนคลัสเตอร์เกี่ยวกับสมาชิกใหม่ (เพิ่มสมาชิก etcdctl). ในกรณีของโอเปอเรเตอร์ ผู้ใช้จะต้องเปลี่ยนขนาดคลัสเตอร์เท่านั้น ส่วนอย่างอื่นจะเกิดขึ้นโดยอัตโนมัติ

และเนื่องจาก etcd ถูกสร้างขึ้นใน CoreOS ดังนั้นจึงค่อนข้างสมเหตุสมผลที่จะเห็น Operator ปรากฏก่อน เขาทำงานยังไงบ้าง? ตรรกะของตัวดำเนินการ ฯลฯ ถูกกำหนดโดยองค์ประกอบสามประการ:

สังเกต. ผู้ปฏิบัติงานตรวจสอบสถานะของคลัสเตอร์โดยใช้ Kubernetes API
การวิเคราะห์. ค้นหาความแตกต่างระหว่างสถานะปัจจุบันและสถานะที่ต้องการ (กำหนดโดยการกำหนดค่าผู้ใช้)
การกระทำ. แก้ไขความแตกต่างที่ตรวจพบโดยใช้ API บริการ ฯลฯ และ/หรือ Kubernetes

เพื่อนำตรรกะนี้ไปใช้ ฟังก์ชันต่างๆ ได้ถูกจัดเตรียมไว้ในตัวดำเนินการแล้ว สร้าง/ทำลาย (การสร้างและการลบสมาชิกคลัสเตอร์ ฯลฯ ) และ การปรับขนาด (การเปลี่ยนแปลงจำนวนสมาชิกคลัสเตอร์) ตรวจสอบความถูกต้องของการดำเนินการโดยใช้ยูทิลิตี้ที่สร้างขึ้นในลักษณะของ Chaos Monkey จาก Netflix เช่น ฆ่าพ็อด ฯลฯ แบบสุ่ม

สำหรับการดำเนินการของ etcd อย่างเต็มรูปแบบ ผู้ดำเนินการจะมีคุณสมบัติเพิ่มเติม: สำรอง (โดยอัตโนมัติและมองไม่เห็นสำหรับผู้ใช้ในการสร้างสำเนาสำรอง - ในการกำหนดค่าก็เพียงพอที่จะกำหนดความถี่ที่จะสร้างและจำนวนที่จะจัดเก็บ - และการกู้คืนข้อมูลจากพวกเขาในภายหลัง) และ อัพเกรด (อัปเดตการติดตั้ง ฯลฯ โดยไม่ต้องหยุดทำงาน)

การทำงานร่วมกับโอเปอเรเตอร์มีหน้าตาเป็นอย่างไร?

$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
etcd-cluster-0000                1/1       Running   0          23s
etcd-cluster-0001                1/1       Running   0          16s
etcd-cluster-0002                1/1       Running   0          8s
etcd-cluster-backup-tool-rhygq   1/1       Running   0          18s

สถานะปัจจุบันของ etcd Operator เป็นเวอร์ชันเบต้า ซึ่งต้องใช้ Kubernetes 1.5.3+ และ etcd 3.0+ จึงจะทำงานได้ มีซอร์สโค้ดและเอกสารประกอบ (รวมถึงคำแนะนำในการใช้งาน) อยู่ที่ GitHub.

อีกตัวอย่างการใช้งานจาก CoreOS ได้ถูกสร้างขึ้น - ผู้ดำเนินการ Prometheusแต่ยังอยู่ในเวอร์ชันอัลฟ่า (ฟีเจอร์ที่วางแผนไว้บางส่วนไม่ได้ถูกนำมาใช้)

สถานะและโอกาส

ผ่านไป 5 เดือนแล้วนับตั้งแต่การประกาศเปิดตัวผู้ให้บริการ Kubernetes ยังมีการใช้งานเพียงสองรายการเท่านั้นในที่เก็บ CoreOS อย่างเป็นทางการ (สำหรับ etcd และ Prometheus) ทั้งสองเวอร์ชันยังไม่ถึงเวอร์ชันเสถียร แต่จะมีการสังเกตการคอมมิตทุกวัน

นักพัฒนามองเห็น “อนาคตที่ผู้ใช้ติดตั้งตัวดำเนินการ Postgres, ตัวดำเนินการ Cassandra หรือตัวดำเนินการ Redis บนคลัสเตอร์ Kubernetes และทำงานร่วมกับเอนทิตีที่ปรับขนาดได้ของแอปพลิเคชันเหล่านี้ เช่นเดียวกับการนำแบบจำลองของเว็บแอปพลิเคชันไร้สัญชาติมาใช้ในปัจจุบัน” อันดับแรก ผู้ประกอบการจากนักพัฒนาบุคคลที่สาม เริ่มปรากฏให้เห็นแล้วจริงๆ:

ตัวดำเนินการ Elasticsearch จาก UPMC Enterprises;
ตัวดำเนินการ PostgreSQL จาก Crunchy Data (ประกาศปลายเดือนมีนาคม 2017);
ผู้ประกอบการโกง จากผู้เขียนระบบจัดเก็บข้อมูลแบบกระจายตาม Ceph (Rook อยู่ในสถานะอัลฟ่า)
ตัวดำเนินการ OpenStack จาก SAP CCloud

ในการประชุมซอฟต์แวร์ฟรีที่ใหญ่ที่สุดในยุโรป FOSDEM ซึ่งจัดขึ้นในเดือนกุมภาพันธ์ 2017 ที่กรุงบรัสเซลส์ Josh Wood จาก CoreOS ได้ประกาศผู้ให้บริการใน รายงาน (มีวิดีโออยู่ที่ลิงก์!) ซึ่งน่าจะมีส่วนทำให้แนวคิดนี้ได้รับความนิยมเพิ่มขึ้นในชุมชนโอเพ่นซอร์สในวงกว้าง

PS ขอบคุณสำหรับความสนใจในบทความ! สมัครสมาชิกฮับของเราเพื่อไม่ให้พลาดเนื้อหาและสูตรอาหารใหม่ๆ เกี่ยวกับการบริหารระบบ DevOps และ GNU/Linux เราจะเผยแพร่เนื้อหาเหล่านี้เป็นประจำ!

ที่มา: will.com

ตัวดำเนินการสำหรับ Kubernetes: วิธีเรียกใช้แอปพลิเคชันแบบเก็บสถานะ