ວິທີການເຊື່ອມຕໍ່ Kubernetes clusters ໃນສູນຂໍ້ມູນທີ່ແຕກຕ່າງກັນ

ຍິນດີຕ້ອນຮັບສູ່ຊຸດ Kubernetes Quick Start ຂອງພວກເຮົາ. ນີ້ແມ່ນຄໍລໍາປົກກະຕິທີ່ມີຄໍາຖາມທີ່ຫນ້າສົນໃຈທີ່ສຸດທີ່ພວກເຮົາໄດ້ຮັບອອນໄລນ໌ແລະໃນການຝຶກອົບຮົມຂອງພວກເຮົາ. ຄໍາຕອບຂອງຜູ້ຊ່ຽວຊານ Kubernetes.

ຜູ້ຊ່ຽວຊານໃນມື້ນີ້ແມ່ນ Daniel Polenchik (Daniele Polencic). Daniel ເຮັດ​ວຽກ​ເປັນ instructor ແລະ​ການ​ພັດ​ທະ​ນາ​ຊອບ​ແວ​ທີ່ ຮຽນຮູ້ 8s.

ຖ້າທ່ານຕ້ອງການໃຫ້ຄໍາຖາມຂອງເຈົ້າຕອບໃນບົດຄວາມຕໍ່ໄປ, ຕິດຕໍ່ພວກເຮົາທາງອີເມວ ຫຼື Twitter: @learnk8s.

ພາດຂໍ້ຄວາມທີ່ຜ່ານມາບໍ? ຊອກຫາພວກມັນໄດ້ທີ່ນີ້.

ວິທີການເຊື່ອມຕໍ່ກຸ່ມ Kubernetes ໃນສູນຂໍ້ມູນທີ່ແຕກຕ່າງກັນ?

ໄລຍະສັ້ນໆ: Kubefed v2 ໃນໄວໆນີ້, ແລະຂ້າພະເຈົ້າຍັງແນະນໍາໃຫ້ອ່ານກ່ຽວກັບ ຜູ້ຂົນສົ່ງ и ໂຄງການ multi-cluster-scheduler.

ຂ້ອນຂ້າງມັກ, ໂຄງສ້າງພື້ນຖານໄດ້ຖືກຈໍາລອງແລະແຈກຢາຍໃນທົ່ວພາກພື້ນຕ່າງໆ, ໂດຍສະເພາະໃນສະພາບແວດລ້ອມທີ່ມີການຄວບຄຸມ.

ຖ້າພາກພື້ນຫນຶ່ງບໍ່ສາມາດໃຊ້ໄດ້, ການຈະລາຈອນຈະຖືກໂອນໄປຫາອີກເຂດຫນຶ່ງເພື່ອຫຼີກເວັ້ນການຂັດຂວາງ.

ດ້ວຍ Kubernetes, ທ່ານສາມາດໃຊ້ຍຸດທະສາດທີ່ຄ້າຍຄືກັນ ແລະແຈກຢາຍວຽກໃນທົ່ວພາກພື້ນຕ່າງໆ.

ທ່ານ​ສາ​ມາດ​ມີ​ຫນຶ່ງ​ຫຼື​ຫຼາຍ​ກຸ່ມ​ຕໍ່​ທີມ​ງານ​, ພາກ​ພື້ນ​, ສະ​ພາບ​ແວດ​ລ້ອມ​, ຫຼື​ການ​ປະ​ສົມ​ຂອງ​ອົງ​ປະ​ກອບ​ເຫຼົ່າ​ນີ້​.

ກຸ່ມຂອງທ່ານສາມາດຖືກໂຮດຢູ່ໃນຄລາວທີ່ແຕກຕ່າງກັນ ແລະຢູ່ໃນສະຖານທີ່.

ແຕ່ເຈົ້າວາງແຜນໂຄງສ້າງພື້ນຖານແນວໃດສໍາລັບການແຜ່ກະຈາຍທາງພູມສາດດັ່ງກ່າວ?
ທ່ານຈໍາເປັນຕ້ອງສ້າງກຸ່ມຂະຫນາດໃຫຍ່ຫນຶ່ງສໍາລັບສະພາບແວດລ້ອມຄລາວຫຼາຍໆຄັ້ງຜ່ານເຄືອຂ່າຍດຽວບໍ?
ຫຼືມີຫຼາຍກຸ່ມຂະຫນາດນ້ອຍແລະຊອກຫາວິທີທີ່ຈະຄວບຄຸມແລະ synchronize ໃຫ້ເຂົາເຈົ້າ?

ໜຶ່ງກຸ່ມຜູ້ນຳ

ການສ້າງກຸ່ມດຽວຜ່ານເຄືອຂ່າຍດຽວບໍ່ແມ່ນເລື່ອງງ່າຍ.

ຈິນຕະນາການວ່າທ່ານມີອຸປະຕິເຫດ, ການເຊື່ອມຕໍ່ລະຫວ່າງກຸ່ມກຸ່ມແມ່ນສູນເສຍ.

ຖ້າທ່ານມີເຄື່ອງແມ່ຂ່າຍຕົ້ນສະບັບຫນຶ່ງ, ເຄິ່ງຫນຶ່ງຂອງຊັບພະຍາກອນຈະບໍ່ສາມາດໄດ້ຮັບຄໍາສັ່ງໃຫມ່ເພາະວ່າພວກເຂົາຈະບໍ່ສາມາດຕິດຕໍ່ກັບແມ່ບົດໄດ້.

ແລະໃນເວລາດຽວກັນທ່ານມີຕາຕະລາງການກໍານົດເສັ້ນທາງເກົ່າ (kube-proxy ບໍ່​ສາ​ມາດ​ດາວ​ນ​໌​ໂຫລດ​ໃຫມ່​) ແລະ​ບໍ່​ມີ pods ເພີ່ມ​ເຕີມ (kubelet ບໍ່​ສາ​ມາດ​ຮ້ອງ​ຂໍ​ການ​ປັບ​ປຸງ​)​.

ເພື່ອເຮັດໃຫ້ບັນຫາຮ້າຍແຮງກວ່າເກົ່າ, ຖ້າ Kubernetes ບໍ່ເຫັນ node, ມັນຈະຫມາຍມັນວ່າເປັນເດັກກໍາພ້າແລະແຈກຢາຍ pods ທີ່ບໍ່ມີຢູ່ກັບ nodes.

ດັ່ງນັ້ນ, ທ່ານມີຝັກຫຼາຍສອງເທົ່າ.

ຖ້າທ່ານສ້າງເຄື່ອງແມ່ຂ່າຍແມ່ບົດຫນຶ່ງສໍາລັບແຕ່ລະພາກພື້ນ, ມັນຈະມີບັນຫາກັບລະບົບ consensus algorithm ໃນຖານຂໍ້ມູນ etcd. (ປະມານ ed. - ໃນຄວາມເປັນຈິງ, ຖານຂໍ້ມູນ etcd ບໍ່ຈໍາເປັນຕ້ອງຕັ້ງຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຕົ້ນສະບັບ. ມັນສາມາດດໍາເນີນການຢູ່ໃນກຸ່ມເຊີຟເວີແຍກຕ່າງຫາກຢູ່ໃນພາກພື້ນດຽວກັນ. ຄວາມຈິງ, ໃນເວລາດຽວກັນໄດ້ຮັບຈຸດຂອງຄວາມລົ້ມເຫຼວຂອງກຸ່ມ. ແຕ່ໄວ.)

ການ​ນໍາ​ໃຊ້​ອື່ນໆ​ ສູດການຄິດໄລ່ raftເພື່ອເຈລະຈາມູນຄ່າກ່ອນທີ່ຈະຂຽນມັນໃສ່ແຜ່ນ.
ນັ້ນແມ່ນ, ກໍລະນີສ່ວນໃຫຍ່ຈະຕ້ອງບັນລຸຄວາມເຫັນດີກ່ອນທີ່ລັດສາມາດຂຽນເປັນ etcd.

ຖ້າເວລາ latency ລະຫວ່າງ etcd ເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ, ເຊັ່ນດຽວກັບສາມຕົວຢ່າງ etcd ໃນພາກພື້ນຕ່າງໆ, ມັນໃຊ້ເວລາດົນໃນການເຈລະຈາມູນຄ່າແລະຂຽນມັນໃສ່ແຜ່ນ.
ອັນນີ້ແມ່ນສະທ້ອນຢູ່ໃນຕົວຄວບຄຸມ Kubernetes.

ຜູ້ຈັດການຄວບຄຸມຕ້ອງການເວລາເພີ່ມເຕີມເພື່ອຮຽນຮູ້ກ່ຽວກັບການປ່ຽນແປງແລະຂຽນຄໍາຕອບກັບຖານຂໍ້ມູນ.

ແລະເນື່ອງຈາກວ່າບໍ່ມີຕົວຄວບຄຸມຫນຶ່ງ, ແຕ່ຫຼາຍ, ສົ່ງຜົນໃຫ້ເກີດປະຕິກິລິຍາລະບົບຕ່ອງໂສ້ ແລະກຸ່ມທັງໝົດເລີ່ມເຮັດວຽກຊ້າຫຼາຍ.

etcd ແມ່ນມີຄວາມອ່ອນໄຫວ latency ນັ້ນ ເອກະສານທີ່ເປັນທາງການແນະນໍາໃຫ້ໃຊ້ SSDs ແທນທີ່ຈະເປັນຮາດໄດປົກກະຕິ.

ໃນປັດຈຸບັນບໍ່ມີຕົວຢ່າງທີ່ດີຂອງເຄືອຂ່າຍຂະຫນາດໃຫຍ່ສໍາລັບກຸ່ມດຽວ.

ໂດຍພື້ນຖານແລ້ວ, ຊຸມຊົນນັກພັດທະນາແລະກຸ່ມ SIG-cluster ກໍາລັງພະຍາຍາມຊອກຫາວິທີການຈັດກຸ່ມແບບດຽວກັນກັບ Kubernetes orchestrates containers.

ທາງເລືອກ 1: ກຸ່ມສະຫະພັນກັບ kubefed

ຄໍາຕອບຢ່າງເປັນທາງການຈາກ SIG-cluster - kubefed2, ຮຸ່ນໃຫມ່ຂອງລູກຄ້າແລະຜູ້ປະກອບການ kube ຕົ້ນສະບັບ.

ຄັ້ງທໍາອິດ, ພວກເຮົາໄດ້ພະຍາຍາມຈັດການການລວບລວມກຸ່ມເປັນວັດຖຸດຽວໂດຍໃຊ້ເຄື່ອງມືສະຫະພັນ kube.

ການເລີ່ມຕົ້ນແມ່ນດີ, ແຕ່ໃນທີ່ສຸດສະຫະພັນ kube ບໍ່ເຄີຍໄດ້ຮັບຄວາມນິຍົມເພາະວ່າມັນບໍ່ສະຫນັບສະຫນູນຊັບພະຍາກອນທັງຫມົດ.

ມັນສະຫນັບສະຫນູນການຈັດສົ່ງແລະການບໍລິການສະຫະພັນ, ແຕ່ບໍ່ແມ່ນ StatefulSets, ຕົວຢ່າງ.
ນອກຈາກນີ້, ການຕັ້ງຄ່າສະຫະພັນໄດ້ຖືກຖ່າຍທອດໃນຮູບແບບຂອງຄໍາບັນຍາຍແລະບໍ່ປ່ຽນແປງໄດ້.

ຈິນຕະນາການວິທີທີ່ທ່ານສາມາດອະທິບາຍການແບ່ງປັນແບບຈໍາລອງສໍາລັບແຕ່ລະກຸ່ມໃນສະຫະພັນໂດຍໃຊ້ພຽງແຕ່ຄໍາບັນຍາຍ.

ມັນເປັນການລັງກິນອາຫານທີ່ສົມບູນ.

SIG-cluster ໄດ້ເຮັດວຽກຫຼາຍຫຼັງຈາກ kubefed v1 ແລະຕັດສິນໃຈເຂົ້າຫາບັນຫາຈາກມຸມທີ່ແຕກຕ່າງກັນ.

ແທນທີ່ຈະເປັນຄໍາບັນຍາຍ, ພວກເຂົາຕັດສິນໃຈປ່ອຍຕົວຄວບຄຸມທີ່ຕິດຕັ້ງຢູ່ໃນກຸ່ມ. ມັນສາມາດຖືກປັບແຕ່ງໂດຍໃຊ້ Custom Resource Definitions (CRDs).

ສໍາລັບແຕ່ລະຊັບພະຍາກອນທີ່ຈະເປັນສ່ວນຫນຶ່ງຂອງສະຫະພັນ, ທ່ານມີຄໍານິຍາມ CRD ແບບກໍານົດເອງທີ່ມີສາມພາກ:

• ຄໍານິຍາມມາດຕະຖານຂອງຊັບພະຍາກອນ, ສໍາລັບການຍົກຕົວຢ່າງ, ການນໍາໃຊ້;
• ສ່ວນ placement, ບ່ອນທີ່ທ່ານກໍານົດວິທີການຊັບພະຍາກອນຈະຖືກແຈກຢາຍຢູ່ໃນສະຫະພັນ;
• ສ່ວນ override, ບ່ອນທີ່ຊັບພະຍາກອນສະເພາະທີ່ທ່ານສາມາດ override ນ້ໍາຫນັກແລະຕົວກໍານົດການຈາກການຈັດວາງ.

ນີ້ແມ່ນຕົວຢ່າງຂອງການຈັດສົ່ງລວມກັບພາກສ່ວນການຈັດວາງ ແລະ override.

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ການສະຫນອງໄດ້ຖືກແຈກຢາຍໃນທົ່ວສອງກຸ່ມ: cluster1 и cluster2.

ກຸ່ມທໍາອິດສະຫນອງສາມ replicas, ແລະທີສອງແມ່ນກໍານົດ 5.

ຖ້າທ່ານຕ້ອງການຄວບຄຸມຈໍານວນຂອງ replicas, kubefed2 ສະຫນອງວັດຖຸ ReplicaSchedulingPreference ໃໝ່ ບ່ອນທີ່ replicas ສາມາດນ້ໍາຫນັກໄດ້:

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

ໂຄງສ້າງ CRD ແລະ API ຍັງບໍ່ພ້ອມເທື່ອ, ແລະວຽກງານທີ່ຫ້າວຫັນແມ່ນກໍາລັງດໍາເນີນຢູ່ໃນບ່ອນເກັບມ້ຽນໂຄງການຢ່າງເປັນທາງການ.

ຮັກສາຕາກ່ຽວກັບ kubefed2, ແຕ່ຈື່ວ່າມັນຍັງບໍ່ທັນເຫມາະສົມສໍາລັບການຜະລິດ.

ຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບ kubefed2 ຈາກ ບົດຄວາມຢ່າງເປັນທາງການກ່ຽວກັບ kubefed2 ໃນ blog ກ່ຽວກັບ Kubernetes ແລະໃນ repository ຢ່າງເປັນທາງການຂອງໂຄງການ kubefed.

ທາງເລືອກ 2: ການລວມກຸ່ມຢູ່ໃນແບບ Booking.com

ນັກພັດທະນາຂອງ Booking.com ບໍ່ໄດ້ເຮັດວຽກຢູ່ໃນ kubefed v2, ແຕ່ພວກເຂົາມາພ້ອມກັບ Shipper - ຜູ້ປະກອບການສໍາລັບການຈັດສົ່ງໃນຫຼາຍໆກຸ່ມ, ໃນຫຼາຍໆພາກພື້ນແລະໃນຫຼາຍໆ clouds.

ຜູ້ຂົນສົ່ງ ຂ້ອນຂ້າງຄ້າຍຄືກັນກັບ kubefed2.

ເຄື່ອງມືທັງສອງຊ່ວຍໃຫ້ທ່ານສາມາດປັບແຕ່ງຍຸດທະສາດການນໍາໃຊ້ຫຼາຍກຸ່ມຂອງທ່ານ (ກຸ່ມໃດຖືກນໍາໃຊ້ແລະຈໍານວນ replicas ທີ່ພວກເຂົາມີ).

ແຕ່ວ່າ ເປົ້າຫມາຍຂອງຜູ້ຂົນສົ່ງແມ່ນເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງຄວາມຜິດພາດໃນລະຫວ່າງການຈັດສົ່ງ.

ໃນ Shipper, ທ່ານສາມາດກໍານົດຊຸດຂອງຂັ້ນຕອນທີ່ອະທິບາຍການແບ່ງສ່ວນຂອງ replicas ລະຫວ່າງການນໍາໃຊ້ທີ່ຜ່ານມາແລະປະຈຸບັນແລະປະລິມານຂອງການຈະລາຈອນຂາເຂົ້າ.

ເມື່ອທ່ານຍູ້ຊັບພະຍາກອນໄປຫາກຸ່ມໃດໜຶ່ງ, ຕົວຄວບຄຸມ Shipper ຄ່ອຍໆອອກການປ່ຽນແປງນັ້ນໃນທົ່ວກຸ່ມທີ່ເຂົ້າຮ່ວມທັງໝົດ.

ນອກຈາກນີ້, Shipper ແມ່ນຈໍາກັດຫຼາຍ.

ສໍາລັບຕົວຢ່າງ, ມັນຍອມຮັບຕາຕະລາງຫມວກກັນກະທົບເປັນການປ້ອນຂໍ້ມູນ ແລະບໍ່ສະຫນັບສະຫນູນຊັບພະຍາກອນ vanilla.
ໂດຍທົ່ວໄປ, Shipper ເຮັດວຽກແບບນີ້.

ແທນທີ່ຈະສົ່ງມາດຕະຖານ, ທ່ານຈໍາເປັນຕ້ອງສ້າງຊັບພະຍາກອນຄໍາຮ້ອງສະຫມັກທີ່ປະກອບມີຕາຕະລາງ Helm:

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

Shipper ເປັນທາງເລືອກທີ່ດີສໍາລັບການຄຸ້ມຄອງຫຼາຍກຸ່ມ, ແຕ່ຄວາມໃກ້ຊິດຂອງຕົນກັບ Helm ພຽງແຕ່ໄດ້ຮັບໃນວິທີການ.

ຈະເປັນແນວໃດຖ້າພວກເຮົາທັງຫມົດປ່ຽນຈາກ Helm ເປັນ ປັບແຕ່ງ ຫຼື ຕັນ?

ຊອກຫາເພີ່ມເຕີມກ່ຽວກັບ Shipper ແລະປັດຊະຍາຂອງມັນໄດ້ທີ່ ຖະແຫຼງຂ່າວຢ່າງເປັນທາງການນີ້.

ຖ້າທ່ານຕ້ອງການຂຸດຄົ້ນລະຫັດ, ໄປຫາບ່ອນເກັບມ້ຽນໂຄງການຢ່າງເປັນທາງການ.

ທາງເລືອກ 3: ການລວມກຸ່ມ “magic”

Kubefed v2 ແລະ Shipper ເຮັດວຽກກັບສະຫະພັນກຸ່ມ, ການສະຫນອງຊັບພະຍາກອນໃຫມ່ໃຫ້ແກ່ກຸ່ມໂດຍຜ່ານການກໍານົດຊັບພະຍາກອນທີ່ກໍາຫນົດເອງ.

ແຕ່ຈະເຮັດແນວໃດຖ້າທ່ານບໍ່ຕ້ອງການຂຽນຄືນການຈັດສົ່ງທັງຫມົດ, StatefulSets, DaemonSets, ແລະອື່ນໆ.

ວິທີການລວມເອົາກຸ່ມທີ່ມີຢູ່ແລ້ວຢູ່ໃນສະຫະພັນໂດຍບໍ່ມີການປ່ຽນ YAML?

multi-cluster-scheduler ແມ່ນໂຄງການ Admirality, ເຊິ່ງຈັດການກັບການກໍານົດເວລາວຽກຢູ່ໃນກຸ່ມ.

ແຕ່ແທນທີ່ຈະມີວິທີການໃຫມ່ເພື່ອພົວພັນກັບກຸ່ມແລະຫໍ່ຊັບພະຍາກອນໃນຄໍານິຍາມທີ່ກໍາຫນົດເອງ, multi-cluster-scheduler ໄດ້ຖືກຝັງຢູ່ໃນວົງຈອນຊີວິດ Kubernetes ມາດຕະຖານແລະຂັດຂວາງການໂທທັງຫມົດທີ່ສ້າງ pods.

ແຕ່ລະຝັກທີ່ສ້າງຂຶ້ນຈະຖືກແທນທີ່ທັນທີດ້ວຍ dummy.

multi-cluster-scheduler ໃຊ້ webhooks ສໍາລັບການດັດແກ້ການເຂົ້າເຖິງເພື່ອຂັດຂວາງການໂທແລະສ້າງຝັກ dummy ທີ່ບໍ່ມີປະໂຫຍດ.

ຝັກຕົ້ນແມ່ນຜ່ານວົງຈອນການວາງແຜນອີກອັນໜຶ່ງ, ຫຼັງຈາກການລົງຄະແນນສຽງຂອງສະຫະພັນທັງໝົດ, ການຕັດສິນໃຈບັນຈຸເຂົ້າຮຽນແມ່ນເຮັດ.

ສຸດທ້າຍ, ຝັກຖືກສົ່ງໄປຫາກຸ່ມເປົ້າໝາຍ.

ດັ່ງນັ້ນ, ທ່ານມີຝັກພິເສດທີ່ບໍ່ໄດ້ເຮັດຫຍັງ, ພຽງແຕ່ໃຊ້ເວລາເຖິງພື້ນທີ່.

ປະໂຫຍດແມ່ນວ່າທ່ານບໍ່ຈໍາເປັນຕ້ອງຂຽນຊັບພະຍາກອນໃຫມ່ເພື່ອສົມທົບການສະຫນອງ.

ແຕ່ລະຊັບພະຍາກອນທີ່ສ້າງ pod ແມ່ນພ້ອມທີ່ຈະຖືກລວມເຂົ້າກັນໂດຍອັດຕະໂນມັດ.

ນີ້ແມ່ນຫນ້າສົນໃຈ, ເພາະວ່າໃນທັນທີທັນໃດເຈົ້າມີເຄື່ອງໃຊ້ແຈກຢາຍຢູ່ທົ່ວທຸກຂົງເຂດ, ແລະເຈົ້າບໍ່ໄດ້ສັງເກດເຫັນ. ຢ່າງໃດກໍຕາມ, ນີ້ແມ່ນຂ້ອນຂ້າງມີຄວາມສ່ຽງ, ເພາະວ່າທຸກສິ່ງທຸກຢ່າງຢູ່ທີ່ນີ້ rests ສຸດ magic.

ແຕ່ໃນຂະນະທີ່ Shipper ພະຍາຍາມສ່ວນຫຼາຍແມ່ນຫຼຸດຜ່ອນຜົນກະທົບຂອງການຈັດສົ່ງ, multi-cluster-scheduler ຈັດການກັບວຽກງານທົ່ວໄປຫຼາຍຂຶ້ນແລະບາງທີອາດເຫມາະສົມກັບວຽກ batch.

ມັນບໍ່ມີກົນໄກການຈັດສົ່ງເທື່ອລະກ້າວທີ່ກ້າວຫນ້າ.

ຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບ multi-cluster-scheduler ສາມາດພົບໄດ້ທີ່ ຫນ້າ repository ຢ່າງເປັນທາງການ.

ຖ້າທ່ານຕ້ອງການອ່ານກ່ຽວກັບ multi-cluster-scheduler ໃນການປະຕິບັດ, Admiralty ມີ ກໍລະນີການນໍາໃຊ້ທີ່ຫນ້າສົນໃຈກັບ Argo — ຂັ້ນຕອນການເຮັດວຽກ, ເຫດການ, CI ແລະ CD Kubernetes.

ເຄື່ອງມືແລະວິທີແກ້ໄຂອື່ນໆ

ການ​ເຊື່ອມ​ຕໍ່​ແລະ​ການ​ຄຸ້ມ​ຄອງ​ຫຼາຍ​ກຸ່ມ​ແມ່ນ​ເປັນ​ວຽກ​ງານ​ສະ​ລັບ​ສັບ​ຊ້ອນ​, ແລະ​ບໍ່​ມີ​ການ​ແກ້​ໄຂ​ທົ່ວ​ໄປ​.

ຖ້າທ່ານຕ້ອງການຄົ້ນຫາຫົວຂໍ້ນີ້ຕື່ມອີກ, ນີ້ແມ່ນຊັບພະຍາກອນບາງຢ່າງ:

• Submariner ໂດຍ Rancher ເປັນເຄື່ອງມືທີ່ເຊື່ອມຕໍ່ເຄືອຂ່າຍຊ້ອນກັນຂອງກຸ່ມ Kubernetes ທີ່ແຕກຕ່າງກັນ.
• ລະບົບຕ່ອງໂສ້ຂາຍຍ່ອຍເປົ້າຫມາຍການນໍາໃຊ້ Unimatrix ສົມທົບກັບ Spinnaker ເພື່ອຈັດຕັ້ງການຈັດຕັ້ງປະຕິບັດໃນທົ່ວຫຼາຍກຸ່ມ.
• ລອງໃຊ້ IPV6 ແລະ ເຄືອຂ່າຍດຽວໃນຫຼາຍຂົງເຂດ.
• ທ່ານສາມາດນໍາໃຊ້ຕາຫນ່າງການບໍລິການ, ສໍາລັບການຍົກຕົວຢ່າງ Istio ສໍາລັບການເຊື່ອມຕໍ່ຫຼາຍກຸ່ມ.
• Cilium, plugin ການໂຕ້ຕອບເຄືອຂ່າຍ container, ສະເຫນີ ຟັງຊັນຕາຫນ່າງກຸ່ມ, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສາມາດສົມທົບຫຼາຍກຸ່ມ

ນັ້ນແມ່ນທັງຫມົດສໍາລັບມື້ນີ້

ຂອບໃຈທີ່ອ່ານຈົນຈົບ!

ຖ້າເຈົ້າຮູ້ວິທີເຊື່ອມຕໍ່ຫຼາຍກຸ່ມຢ່າງມີປະສິດທິພາບ, ບອກ​ພວກ​ເຮົາ.

ພວກເຮົາຈະເພີ່ມວິທີການຂອງທ່ານເຂົ້າໃນການເຊື່ອມຕໍ່.

ຂອບໃຈເປັນພິເສດກັບ Chris Nesbitt-Smith (Chris Nesbitt-Smith) ແລະ Vincent de Sme (Vincent De Smet) (ວິສະວະກອນຄວາມຫນ້າເຊື່ອຖືໃນ swatmobile.io) ສໍາລັບການອ່ານບົດຄວາມແລະແບ່ງປັນຂໍ້ມູນທີ່ເປັນປະໂຫຍດກ່ຽວກັບວິທີການເຮັດວຽກຂອງສະຫະພັນ.

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