ຜູ້ປະກອບການສໍາລັບ Kubernetes: ວິທີການດໍາເນີນການຄໍາຮ້ອງສະຫມັກຂອງລັດ

ບັນຫາກັບແອັບພລິເຄຊັນທີ່ມີສະຖານະໃນ Kubernetes

ການຕັ້ງຄ່າ, ການເປີດຕົວແລະການຂະຫຍາຍເພີ່ມເຕີມຂອງຄໍາຮ້ອງສະຫມັກແລະການບໍລິການແມ່ນງ່າຍໃນເວລາທີ່ມັນມາກັບກໍລະນີທີ່ຖືກຈັດປະເພດເປັນ stateless, i.e. ໂດຍບໍ່ມີການບັນທຶກຂໍ້ມູນ. ມັນເປັນການສະດວກທີ່ຈະດໍາເນີນການບໍລິການດັ່ງກ່າວໃນ Kubernetes, ການນໍາໃຊ້ APIs ມາດຕະຖານຂອງຕົນ, ເນື່ອງຈາກວ່າທຸກສິ່ງທຸກຢ່າງເກີດຂຶ້ນ "ນອກກ່ອງ": ອີງຕາມການກໍາຫນົດຄ່າມາດຕະຖານ, ໂດຍບໍ່ມີການກ່ຽວຂ້ອງກັບສະເພາະໃດຫນຶ່ງຫຼື magic.

ເວົ້າງ່າຍໆ, ເພື່ອເປີດຕົວອີກຫ້າສໍາເນົາຂອງ backend ໃນ PHP / Ruby / Python ໃນ cluster ຂອງ containers, ທ່ານພຽງແຕ່ຕ້ອງການຕັ້ງເຄື່ອງແມ່ຂ່າຍໃຫມ່ 5 ຄັ້ງແລະຄັດລອກແຫຼ່ງ. ເນື່ອງຈາກທັງລະຫັດແຫຼ່ງແລະສະຄິບ init ຢູ່ໃນຮູບພາບ, ການຂະຫຍາຍແອັບພລິເຄຊັນທີ່ບໍ່ມີລັດກາຍເປັນພື້ນຖານຢ່າງສົມບູນ. ໃນຖານະເປັນ fans ຂອງ containers ແລະສະຖາປັດຕະ microservice ຮູ້ດີ, ຄວາມຫຍຸ້ງຍາກເລີ່ມຕົ້ນດ້ວຍ ແອັບ stateful, i.e. ກັບຂໍ້ມູນຄົງທີ່ເຊັ່ນ: ຖານຂໍ້ມູນແລະຖານຄວາມຈໍາ (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra ...). ນີ້ນຳໃຊ້ກັບທັງສອງຊອບແວທີ່ປະຕິບັດກຸ່ມກຸ່ມໂຄຣຳຢ່າງເປັນອິດສະຫຼະ (ຕົວຢ່າງ, Percona XtraDB ແລະ Cassandra), ແລະຊອບແວທີ່ຕ້ອງໃຊ້ອຸປະກອນການຈັດການແຍກຕ່າງຫາກ (ເຊັ່ນ: Redis, MySQL, PostgreSQL...).

ຄວາມຫຍຸ້ງຍາກເກີດຂື້ນເພາະວ່າລະຫັດແຫຼ່ງແລະການເປີດຕົວບໍລິການບໍ່ພຽງພໍອີກຕໍ່ໄປ - ທ່ານຈໍາເປັນຕ້ອງປະຕິບັດບາງຂັ້ນຕອນເພີ່ມເຕີມ. ຢ່າງໜ້ອຍ, ສຳເນົາຂໍ້ມູນ ແລະ/ຫຼື ເຂົ້າຮ່ວມກຸ່ມ. ຊັດເຈນກວ່ານັ້ນ, ການບໍລິການເຫຼົ່ານີ້ຕ້ອງການຄວາມເຂົ້າໃຈກ່ຽວກັບວິທີການປັບຂະຫນາດ, ປັບປຸງ ແລະປັບຄ່າພວກມັນໃຫ້ຖືກຕ້ອງ ໂດຍບໍ່ມີການສູນເສຍຂໍ້ມູນ ຫຼືບໍ່ມີຊົ່ວຄາວ. ການພິຈາລະນາຄວາມຕ້ອງການເຫຼົ່ານີ້ເອີ້ນວ່າ "ຄວາມຮູ້ດ້ານການດໍາເນີນງານ".

ຕົວປະຕິບັດການ CoreOS

ໃນຄໍາສັ່ງທີ່ຈະ "ໂຄງການ" ຄວາມຮູ້ການດໍາເນີນງານ, ທ້າຍປີທີ່ຜ່ານມາໂຄງການ CoreOS ແນະ ນຳ "ຊອບແວຊັ້ນໃຫມ່" ສໍາລັບແພລະຕະຟອມ Kubernetes - ຜູ້ປະກອບການ (ຈາກພາສາອັງກິດ "ການດໍາເນີນງານ", i.e. "ການດໍາເນີນງານ").

ຜູ້ປະກອບການທີ່ໃຊ້ ແລະຂະຫຍາຍຄວາມສາມາດຫຼັກຂອງ Kubernetes (ລວມທັງ. StatefulSets, ເບິ່ງຄວາມແຕກຕ່າງຂ້າງລຸ່ມນີ້) ອະນຸຍາດໃຫ້ຜູ້ຊ່ຽວຊານດ້ານ DevOps ເພີ່ມຄວາມຮູ້ດ້ານການດໍາເນີນງານໃຫ້ກັບລະຫັດຄໍາຮ້ອງສະຫມັກ.

ຈຸດປະສົງຂອງຜູ້ປະຕິບັດງານ — ໃຫ້ຜູ້ໃຊ້ມີ API ທີ່ອະນຸຍາດໃຫ້ທ່ານຈັດການຫຼາຍຫນ່ວຍງານຄໍາຮ້ອງສະຫມັກຂອງລັດຢູ່ໃນກຸ່ມ Kubernetes, ໂດຍບໍ່ມີການຄິດກ່ຽວກັບສິ່ງທີ່ຢູ່ພາຍໃຕ້ hood (ຂໍ້ມູນແລະສິ່ງທີ່ຈະເຮັດແນວໃດກັບມັນ, ຄໍາສັ່ງອັນໃດທີ່ຍັງຕ້ອງໄດ້ຮັບການປະຕິບັດເພື່ອຮັກສາກຸ່ມ. ). ໃນຄວາມເປັນຈິງ, Operator ຖືກອອກແບບມາເພື່ອເຮັດໃຫ້ການເຮັດວຽກທີ່ງ່າຍດາຍກັບຄໍາຮ້ອງສະຫມັກພາຍໃນກຸ່ມຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້, ອັດຕະໂນມັດການປະຕິບັດວຽກງານປະຕິບັດງານທີ່ກ່ອນຫນ້ານີ້ຕ້ອງໄດ້ຮັບການແກ້ໄຂດ້ວຍຕົນເອງ.

ວິທີການເຮັດວຽກຂອງຜູ້ປະຕິບັດງານ

ຊຸດຈຳລອງ Kubernetes ອະນຸຍາດໃຫ້ທ່ານລະບຸຈໍານວນທີ່ຕ້ອງການຂອງພອດແລ່ນ, ແລະຜູ້ຄວບຄຸມຮັບປະກັນວ່າຈໍານວນຂອງພວກເຂົາຖືກຮັກສາໄວ້ (ໂດຍການສ້າງແລະລຶບ pods). ຜູ້ປະກອບການເຮັດວຽກໃນລັກສະນະທີ່ຄ້າຍຄືກັນ, ເພີ່ມຊຸດຄວາມຮູ້ການດໍາເນີນງານໃຫ້ກັບຊັບພະຍາກອນແລະຕົວຄວບຄຸມ Kubernetes ມາດຕະຖານທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດດໍາເນີນການເພີ່ມເຕີມເພື່ອສະຫນັບສະຫນູນຈໍານວນຂອງຫນ່ວຍງານຄໍາຮ້ອງສະຫມັກທີ່ຕ້ອງການ.

ນີ້ແຕກຕ່າງຈາກແນວໃດ StatefulSets, ຖືກອອກແບບມາສໍາລັບແອັບພລິເຄຊັນທີ່ຕ້ອງການກຸ່ມເພື່ອໃຫ້ພວກເຂົາມີຊັບພະຍາກອນຂອງລັດເຊັ່ນການເກັບຮັກສາຂໍ້ມູນຫຼື IP ຄົງທີ່? ສໍາລັບຄໍາຮ້ອງສະຫມັກດັ່ງກ່າວ, ຜູ້ປະກອບການສາມາດນໍາໃຊ້ StatefulSets (ແທນທີ່ຈະ ຊຸດຈຳລອງ) ເປັນພື້ນຖານ, ສະເຫນີ ອັດຕະໂນມັດເພີ່ມເຕີມ: ປະຕິບັດການດໍາເນີນການທີ່ຈໍາເປັນໃນກໍລະນີຂອງການຂັດຂ້ອງ, ເຮັດການສໍາຮອງຂໍ້ມູນ, ປັບປຸງການຕັ້ງຄ່າ, ແລະອື່ນໆ.

ດັ່ງ​ນັ້ນ ທັງໝົດນີ້ເຮັດວຽກແນວໃດ? ຜູ້ປະກອບການແມ່ນ daemon ຜູ້ຈັດການທີ່:

1. ສະໝັກໃຊ້ API ເຫດການໃນ Kubernetes;
2. ໄດ້ຮັບຂໍ້ມູນຈາກມັນກ່ຽວກັບລະບົບ (ກ່ຽວກັບມັນ ຊຸດຈຳລອງ, ຫມາກເປັນຝັກ, ບໍລິການ ແລະ ອື່ນໆ.);
3. ໄດ້​ຮັບ​ຂໍ້​ມູນ​ກ່ຽວ​ກັບ ຊັບພະຍາກອນພາກສ່ວນທີສາມ (ເບິ່ງຕົວຢ່າງຂ້າງລຸ່ມນີ້);
4. ປະຕິກິລິຍາຕໍ່ຮູບລັກສະນະ / ການປ່ຽນແປງ ຊັບພະຍາກອນພາກສ່ວນທີສາມ (ຕົວຢ່າງ, ປ່ຽນຂະຫນາດ, ປ່ຽນສະບັບ, ແລະອື່ນໆ);
5. reacts ກັບການປ່ຽນແປງໃນສະຖານະຂອງລະບົບ (ກ່ຽວກັບມັນ ຊຸດຈຳລອງ, ຫມາກເປັນຝັກ, ບໍລິການ ແລະ ອື່ນໆ.);
6. ສໍາ​ຄັນ​ທີ່​ສຸດ:
   1. ຮຽກຮ້ອງໃຫ້ Kubernetes API ເພື່ອສ້າງທຸກສິ່ງທຸກຢ່າງທີ່ມັນຕ້ອງການ (ອີກເທື່ອຫນຶ່ງ, ຂອງມັນເອງ ຊຸດຈຳລອງ, ຫມາກເປັນຝັກ, ບໍລິການ... ),
   2. ດໍາເນີນການ magic ບາງຢ່າງ (ເພື່ອເຮັດໃຫ້ງ່າຍ, ທ່ານສາມາດຄິດວ່າ Operator ເຂົ້າໄປໃນ pods ຕົນເອງແລະໂທຫາຄໍາສັ່ງ, ສໍາລັບການຍົກຕົວຢ່າງ, ເຂົ້າຮ່ວມກຸ່ມຫຼືຍົກລະດັບຮູບແບບຂໍ້ມູນໃນເວລາທີ່ການປັບປຸງສະບັບ).

ໃນຄວາມເປັນຈິງ, ດັ່ງທີ່ເຫັນໄດ້ຈາກຮູບ, ຄໍາຮ້ອງສະຫມັກແຍກຕ່າງຫາກແມ່ນເພີ່ມພຽງແຕ່ Kubernetes (ປົກກະຕິ ການປະຕິບັດ с ຊຸດຈຳລອງ), ເຊິ່ງເອີ້ນວ່າ Operator. ມັນອາໄສຢູ່ໃນຝັກທໍາມະດາ (ປົກກະຕິແລ້ວພຽງແຕ່ຫນຶ່ງ) ແລະ, ຕາມກົດລະບຽບ, ຮັບຜິດຊອບພຽງແຕ່ສໍາລັບມັນ Namespace. ຄໍາຮ້ອງສະຫມັກຂອງຜູ້ປະກອບການນີ້ປະຕິບັດ API ຂອງມັນ - ເຖິງແມ່ນວ່າບໍ່ແມ່ນໂດຍກົງ, ແຕ່ຜ່ານ ຊັບພະຍາກອນພາກສ່ວນທີສາມ ໃນ Kubernetes.

ດັ່ງນັ້ນ, ຫຼັງຈາກທີ່ພວກເຮົາໄດ້ສ້າງໃນ 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 ສ້າງຮູບແບບຕົ້ນຕໍທີ່ໄດ້ຮັບໂດຍວິສະວະກອນໃນຂະນະທີ່ເຮັດວຽກກ່ຽວກັບ Operators. ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າຜູ້ປະຕິບັດງານທັງຫມົດແມ່ນບຸກຄົນ (ສ້າງສໍາລັບຄໍາຮ້ອງສະຫມັກສະເພາະທີ່ມີລັກສະນະແລະຄວາມຕ້ອງການຂອງຕົນເອງ), ການສ້າງຂອງພວກເຂົາຕ້ອງອີງໃສ່ປະເພດຂອງກອບທີ່ກໍານົດຄວາມຕ້ອງການດັ່ງຕໍ່ໄປນີ້:

1. ການຕິດຕັ້ງຕ້ອງໄດ້ເຮັດໂດຍຜ່ານການດຽວ ການປະຕິບັດ: kubectl ສ້າງ -f SOME_OPERATOR_URL/deployment.yaml - ແລະບໍ່ຮຽກຮ້ອງໃຫ້ມີການປະຕິບັດເພີ່ມເຕີມ.
2. ເມື່ອຕິດຕັ້ງ Operator ໃນ Kubernetes, ຕ້ອງສ້າງປະເພດພາກສ່ວນທີສາມໃຫມ່ (ຊັບພະຍາກອນພາກສ່ວນທີສາມ). ເພື່ອເປີດໃຊ້ແອັບພລິເຄຊັນ (ຕົວຢ່າງຂອງກຸ່ມ) ແລະຈັດການພວກມັນຕື່ມອີກ (ການອັບເດດເວີຊັນ, ປັບຂະໜາດ, ແລະອື່ນໆ), ຜູ້ໃຊ້ຈະໃຊ້ປະເພດນີ້.
3. ເມື່ອໃດກໍ່ຕາມທີ່ເປັນໄປໄດ້, ທ່ານຄວນໃຊ້ primitives ທີ່ສ້າງຂຶ້ນໃນ Kubernetes, ເຊັ່ນ: ບໍລິການ и ຊຸດຈຳລອງເພື່ອໃຊ້ລະຫັດທີ່ທົດສອບໄດ້ດີ ແລະເຂົ້າໃຈໄດ້.
4. ຮຽກ​ຮ້ອງ​ໃຫ້​ມີ​ການ​ເຂົ້າ​ກັນ​ໄດ້​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ຂອງ​ຜູ້​ປະ​ຕິ​ບັດ​ການ​ແລະ​ການ​ສະ​ຫນັບ​ສະ​ຫນູນ​ສໍາ​ລັບ​ການ​ສະ​ບັບ​ເກົ່າ​ຂອງ​ຊັບ​ພະ​ຍາ​ກອນ​ທີ່​ຜູ້​ໃຊ້​ສ້າງ​ຕັ້ງ​ຂຶ້ນ​.
5. ຖ້າຜູ້ປະຕິບັດການຖືກໂຍກຍ້າຍ, ແອັບພລິເຄຊັນຂອງມັນເອງຄວນສືບຕໍ່ເຮັດວຽກໂດຍບໍ່ມີການປ່ຽນແປງ.
6. ຜູ້​ໃຊ້​ຄວນ​ຈະ​ສາ​ມາດ​ກໍາ​ນົດ​ສະ​ບັບ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທີ່​ຕ້ອງ​ການ​ແລະ orchestrate ການ​ປັບ​ປຸງ​ສະ​ບັບ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​. ການຂາດການປັບປຸງຊອບແວແມ່ນແຫຼ່ງທົ່ວໄປຂອງບັນຫາການດໍາເນີນງານແລະຄວາມປອດໄພ, ດັ່ງນັ້ນຜູ້ປະຕິບັດງານຕ້ອງຊ່ວຍຜູ້ໃຊ້ໃນເລື່ອງນີ້.
7. ຜູ້ປະຕິບັດງານຄວນໄດ້ຮັບການທົດສອບດ້ວຍເຄື່ອງມືເຊັ່ນ Chaos Monkey, ເຊິ່ງກໍານົດຄວາມລົ້ມເຫລວທີ່ອາດຈະເກີດຂື້ນໃນຝັກ, ການຕັ້ງຄ່າແລະເຄືອຂ່າຍ.

ແລະອື່ນໆ ຜູ້ປະກອບການ

ຕົວຢ່າງການປະຕິບັດຕົວປະຕິບັດການ - ຜູ້​ປະ​ຕິ​ບັດ​ການ​ອື່ນໆ​, ກະກຽມ ໃນມື້ປະກາດແນວຄວາມຄິດນີ້. ການຕັ້ງຄ່າກຸ່ມ etcd ສາມາດສັບສົນໄດ້ເນື່ອງຈາກຄວາມຕ້ອງການທີ່ຈະຮັກສາກຸ່ມ, ຄວາມຕ້ອງການທີ່ຈະ configure ສະມາຊິກກຸ່ມ, ສ້າງສໍາຮອງຂໍ້ມູນ, ແລະອື່ນໆ. ຕົວຢ່າງ, ການຂະຫຍາຍກຸ່ມ etcd ດ້ວຍຕົນເອງຫມາຍຄວາມວ່າທ່ານຈໍາເປັນຕ້ອງສ້າງຊື່ DNS ສໍາລັບສະມາຊິກກຸ່ມໃຫມ່, ເລີ່ມຕົ້ນໃຫມ່ entity etcd, ແລະເຕືອນກຸ່ມກ່ຽວກັບສະມາຊິກໃຫມ່ (ຕື່ມສະມາຊິກ etcdctl). ໃນກໍລະນີຂອງ Operator, ຜູ້ໃຊ້ພຽງແຕ່ຕ້ອງການປ່ຽນຂະຫນາດຂອງກຸ່ມ - ທຸກສິ່ງທຸກຢ່າງອື່ນຈະເກີດຂຶ້ນໂດຍອັດຕະໂນມັດ.

ແລະນັບຕັ້ງແຕ່ etcd ໄດ້ຖືກສ້າງຂື້ນໃນ CoreOS, ມັນຂ້ອນຂ້າງສົມເຫດສົມຜົນທີ່ຈະເຫັນ Operator ຂອງມັນປາກົດເປັນຄັ້ງທໍາອິດ. ລາວເຮັດວຽກແນວໃດ? ເຫດຜົນຂອງຜູ້ປະຕິບັດງານ ແລະອື່ນໆ ຖືກກໍານົດໂດຍສາມອົງປະກອບ:

1. ສັງເກດ. ຜູ້ປະກອບການກວດສອບສະຖານະຂອງກຸ່ມໂດຍໃຊ້ Kubernetes API.
2. ການວິເຄາະ. ຊອກຫາຄວາມແຕກຕ່າງລະຫວ່າງສະຖານະປັດຈຸບັນແລະອັນທີ່ຕ້ອງການ (ກໍານົດໂດຍການຕັ້ງຄ່າຜູ້ໃຊ້).
3. ການປະຕິບັດ. ແກ້ໄຂຄວາມແຕກຕ່າງທີ່ກວດພົບໂດຍໃຊ້ APIs ການບໍລິການ etcd ແລະ/ຫຼື Kubernetes.

ເພື່ອປະຕິບັດເຫດຜົນນີ້, ຫນ້າທີ່ໄດ້ຖືກກະກຽມຢູ່ໃນ Operator ສ້າງ/ທໍາລາຍ (ການ​ສ້າງ​ແລະ​ລຶບ​ສະ​ມາ​ຊິກ​ກຸ່ມ etcd​) ແລະ​ Resize (ການປ່ຽນແປງຈໍານວນສະມາຊິກກຸ່ມ). ຄວາມຖືກຕ້ອງຂອງການດໍາເນີນງານຂອງມັນໄດ້ຖືກກວດສອບໂດຍໃຊ້ປະໂຫຍດທີ່ສ້າງຂື້ນໃນລັກສະນະຂອງ Chaos Monkey ຈາກ Netflix, i.e. ຂ້າ etcd ຝັກແບບສຸ່ມ.

ສໍາລັບການເຮັດວຽກຢ່າງເຕັມທີ່ຂອງ etcd, Operator ສະຫນອງຄຸນນະສົມບັດເພີ່ມເຕີມ: Backup (ອັດຕະໂນມັດແລະເບິ່ງບໍ່ເຫັນກັບຜູ້ໃຊ້ສ້າງສໍາເນົາສໍາຮອງ - ໃນ config ມັນພຽງພໍທີ່ຈະກໍານົດວິທີການເຮັດໃຫ້ເຂົາເຈົ້າເລື້ອຍໆແລະຈໍານວນການເກັບຮັກສາ - ແລະການຟື້ນຟູຂໍ້ມູນຈາກພວກມັນຕໍ່ມາ) ແລະ ການຍົກລະດັບ (ການ​ປັບ​ປຸງ​ການ​ຕິດ​ຕັ້ງ etcd ໂດຍ​ບໍ່​ມີ​ການ downtime​)​.

ການເຮັດວຽກກັບ Operator ມີລັກສະນະແນວໃດ?

$ 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, ແຕ່ມັນຍັງຢູ່ໃນສະບັບ alpha (ບໍ່ແມ່ນຄຸນສົມບັດທີ່ວາງແຜນໄວ້ທັງຫມົດໄດ້ຖືກປະຕິບັດ).

ສະຖານະພາບແລະຄວາມສົດໃສດ້ານ

5 ເດືອນໄດ້ຜ່ານໄປນັບຕັ້ງແຕ່ການປະກາດຂອງ Kubernetes Operators. ຍັງມີພຽງແຕ່ສອງການປະຕິບັດທີ່ມີຢູ່ໃນບ່ອນເກັບມ້ຽນ CoreOS ຢ່າງເປັນທາງການ (ສໍາລັບ etcd ແລະ Prometheus). ທັງສອງຍັງບໍ່ທັນໄດ້ບັນລຸສະບັບທີ່ຫມັ້ນຄົງຂອງເຂົາເຈົ້າ, ແຕ່ຄໍາຫມັ້ນສັນຍາແມ່ນສັງເກດເຫັນປະຈໍາວັນ.

ຜູ້ພັດທະນາຈິນຕະນາການ "ອະນາຄົດທີ່ຜູ້ໃຊ້ຕິດຕັ້ງ Postgres Operators, Cassandra Operators ຫຼື Redis Operators ຢູ່ໃນກຸ່ມ Kubernetes ຂອງພວກເຂົາແລະເຮັດວຽກກັບຫນ່ວຍງານທີ່ສາມາດຂະຫຍາຍໄດ້ຂອງແອັບພລິເຄຊັນເຫຼົ່ານີ້ໄດ້ງ່າຍເທົ່າກັບການຈໍາລອງແບບຈໍາລອງຂອງຄໍາຮ້ອງສະຫມັກເວັບທີ່ບໍ່ມີລັດໃນປະຈຸບັນ." ທໍາອິດ ຜູ້ປະກອບການຈາກຜູ້ພັດທະນາພາກສ່ວນທີສາມ ກໍ່ເລີ່ມປະກົດວ່າ:

• ຕົວປະຕິບັດການ Elasticsearch ຈາກວິສາຫະກິດ UPMC;
• PostgreSQL Operator ຈາກ Crunchy Data (ປະກາດໃນທ້າຍເດືອນມີນາ 2017);
• Rook Operator ຈາກຜູ້ຂຽນຂອງລະບົບການເກັບຮັກສາຂໍ້ມູນທີ່ແຈກຢາຍໂດຍອີງໃສ່ Ceph (Rook ແມ່ນຢູ່ໃນສະຖານະພາບອັນຟາ);
• ຜູ້ປະກອບການ Openstack ຈາກ SAP CCloud.

ໃນກອງປະຊຸມຊອບແວຟຣີທີ່ໃຫຍ່ທີ່ສຸດຂອງເອີຣົບ FOSDEM, ເຊິ່ງໄດ້ຈັດຂຶ້ນໃນເດືອນກຸມພາ 2017 ໃນ Brussels, Josh Wood ຈາກ CoreOS ໄດ້ປະກາດຜູ້ປະຕິບັດງານໃນ ລາຍງານ (ວິດີໂອມີຢູ່ໃນລິ້ງ!), ເຊິ່ງຄວນປະກອບສ່ວນເຂົ້າໃນການຂະຫຍາຍຕົວຂອງຄວາມນິຍົມຂອງແນວຄວາມຄິດນີ້ໃນຊຸມຊົນແຫຼ່ງເປີດກ້ວາງ.

PS ຂອບໃຈສໍາລັບຄວາມສົນໃຈຂອງທ່ານໃນບົດຄວາມ! ຈອງສູນຂອງພວກເຮົາ, ເພື່ອບໍ່ໃຫ້ພາດອຸປະກອນ ແລະສູດອາຫານໃໝ່ໃນ DevOps ແລະລະບົບ GNU/Linux ບໍລິຫານ - ພວກເຮົາຈະເຜີຍແຜ່ພວກມັນເປັນປະຈຳ!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com