ກ່ຽວກັບຄວາມນິຍົມເພີ່ມຂຶ້ນຂອງ Kubernetes

Hey Habr!

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

ເພີດເພີນກັບການອ່ານ!

ໃນເວລາທີ່ຂຽນບົດຄວາມນີ້, ອາຍຸຂອງ Kubernetes ແມ່ນປະມານ. ຫົກ​ປີ​, ແລະໃນໄລຍະສອງປີທີ່ຜ່ານມາຄວາມນິຍົມຂອງມັນໄດ້ເຕີບໂຕຢ່າງຫຼວງຫຼາຍທີ່ມັນໄດ້ຖືກຈັດອັນດັບຢ່າງຕໍ່ເນື່ອງ ມັກທີ່ສຸດ ເວທີ. Kubernetes ອັນດັບສາມໃນປີນີ້. ເພື່ອສະຫຼຸບ: Kubernetes ແມ່ນແພລະຕະຟອມທີ່ອອກແບບມາສໍາລັບການແລ່ນແລະຈັດລຽງວຽກທີ່ບັນຈຸບັນຈຸ.

ຕູ້ຄອນເທນເນີໄດ້ເລີ່ມຕົ້ນເປັນການອອກແບບພິເສດສໍາລັບການແຍກຂະບວນການໃນ Linux; ຕູ້ຄອນເທນເນີໄດ້ລວມເອົາຕັ້ງແຕ່ປີ 2007 ກຸ່ມ, ແລະນັບຕັ້ງແຕ່ 2002 - namespaces. ຕູ້ຄອນເທນເນີໄດ້ຖືກອອກແບບດີກວ່າໃນປີ 2008, ເມື່ອມັນສາມາດໃຊ້ໄດ້ LXC, ແລະ Google ພັດທະນາກົນໄກຂອງບໍລິສັດພາຍໃນຂອງຕົນເອງທີ່ເອີ້ນວ່າ Borg, ບ່ອນທີ່ "ວຽກງານທັງຫມົດແມ່ນເຮັດຢູ່ໃນຖັງ." ຈາກທີ່ນີ້ພວກເຮົາກ້າວໄປສູ່ປີ 2013, ເມື່ອການເປີດຕົວ Docker ຄັ້ງທໍາອິດເກີດຂຶ້ນ, ແລະສຸດທ້າຍ containers ໄດ້ກາຍເປັນການແກ້ໄຂມະຫາຊົນທີ່ນິຍົມ. ໃນເວລານັ້ນ, ເຄື່ອງມືຕົ້ນຕໍສໍາລັບການ orchestration ຕູ້ຄອນເທນເນີແມ່ນ ເມໂຊ, ເຖິງແມ່ນວ່າລາວບໍ່ໄດ້ເປັນທີ່ນິຍົມ. Kubernetes ໄດ້ຖືກປ່ອຍອອກມາຄັ້ງທໍາອິດໃນປີ 2015, ຫຼັງຈາກນັ້ນເຄື່ອງມືນີ້ໄດ້ກາຍເປັນມາດຕະຖານ de facto ໃນພາກສະຫນາມຂອງ orchestration ບັນຈຸ.

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

ໂຄງສ້າງພື້ນຖານເປັນ YAML

ໃນໂລກທີ່ໄດ້ຈາກ Puppet ແລະ Chef ໄປ Kubernetes, ຫນຶ່ງໃນການປ່ຽນແປງທີ່ໃຫຍ່ທີ່ສຸດແມ່ນການຍ້າຍຈາກ "ໂຄງສ້າງພື້ນຖານເປັນລະຫັດ" ໄປ "ໂຄງສ້າງພື້ນຖານເປັນຂໍ້ມູນ" ໂດຍສະເພາະ, ເຊັ່ນ YAML. ຊັບພະຍາກອນທັງໝົດໃນ Kubernetes, ເຊິ່ງຮວມມີພອດ, ການຕັ້ງຄ່າ, ຕົວຢ່າງທີ່ນຳໃຊ້, ປະລິມານ ແລະ ອື່ນໆ, ສາມາດອະທິບາຍໄດ້ງ່າຍໃນໄຟລ໌ YAML. ຍົກ​ຕົວ​ຢ່າງ:

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

ມຸມເບິ່ງນີ້ເຮັດໃຫ້ມັນງ່າຍຂຶ້ນສໍາລັບຜູ້ຊ່ຽວຊານດ້ານ DevOps ຫຼື SRE ເພື່ອສະແດງອອກຢ່າງເຕັມທີ່ກ່ຽວກັບວຽກງານຂອງພວກເຂົາໂດຍບໍ່ຈໍາເປັນຕ້ອງຂຽນລະຫັດໃນພາສາເຊັ່ນ Python ຫຼື Javascript.

ຂໍ້ໄດ້ປຽບອື່ນໆຂອງການຈັດໂຄງສ້າງພື້ນຖານເປັນຂໍ້ມູນປະກອບມີ:

• GitOps ຫຼື Git Operations Version Control. ວິທີການນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດເກັບໄຟລ໌ Kubernetes YAML ທັງໝົດໄວ້ໃນບ່ອນເກັບມ້ຽນ git, ດັ່ງນັ້ນທ່ານສາມາດຕິດຕາມໄດ້ຢ່າງແນ່ນອນວ່າມີການປ່ຽນແປງເມື່ອໃດ, ໃຜເປັນຜູ້ສ້າງ ແລະອັນໃດຖືກປ່ຽນແປງ. ນີ້ເພີ່ມຄວາມໂປ່ງໃສຂອງການດໍາເນີນງານໃນທົ່ວອົງການຈັດຕັ້ງແລະປັບປຸງປະສິດທິພາບການດໍາເນີນງານໂດຍການກໍາຈັດຄວາມບໍ່ແນ່ນອນ, ໂດຍສະເພາະໃນບ່ອນທີ່ພະນັກງານຄວນຊອກຫາຊັບພະຍາກອນທີ່ພວກເຂົາຕ້ອງການ. ໃນຂະນະດຽວກັນ, ມັນກໍ່ງ່າຍຂຶ້ນທີ່ຈະປ່ຽນແປງຊັບພະຍາກອນ Kubernetes ໂດຍອັດຕະໂນມັດໂດຍການລວມເອົາຄໍາຮ້ອງຂໍດຶງ.
• ຄວາມສາມາດໃນການຂະຫຍາຍ. ເມື່ອຊັບພະຍາກອນຖືກກໍານົດເປັນ YAML, ມັນຈະກາຍເປັນເລື່ອງງ່າຍທີ່ສຸດສໍາລັບຕົວປະຕິບັດການກຸ່ມທີ່ຈະປ່ຽນຫນຶ່ງຫຼືສອງຕົວເລກໃນຊັບພະຍາກອນ Kubernetes, ດັ່ງນັ້ນຈຶ່ງປ່ຽນວິທີການປັບຂະຫນາດ. Kubernetes ສະຫນອງກົນໄກສໍາລັບການປັບຂະຫນາດອັດຕະໂນມັດຕາມແນວນອນຂອງຝັກ, ເຊິ່ງສາມາດນໍາໃຊ້ໄດ້ຢ່າງສະດວກເພື່ອກໍານົດວ່າຈໍານວນ pods ຕໍາ່ສຸດແລະສູງສຸດທີ່ຕ້ອງການໃນການຕັ້ງຄ່າສະເພາະເພື່ອຈັດການກັບການຈະລາຈອນໃນລະດັບຕ່ໍາແລະສູງ. ຕົວຢ່າງ, ຖ້າທ່ານໄດ້ນໍາໃຊ້ການຕັ້ງຄ່າທີ່ຕ້ອງການຄວາມສາມາດເພີ່ມເຕີມເນື່ອງຈາກການຈະລາຈອນເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ, maxReplicas ສາມາດປ່ຽນຈາກ 10 ຫາ 20:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

• ຄວາມປອດໄພແລະການຄຸ້ມຄອງ. YAML ແມ່ນດີເລີດສໍາລັບການປະເມີນວ່າສິ່ງທີ່ຖືກນຳໃຊ້ຢູ່ໃນ Kubernetes. ຕົວຢ່າງ, ຄວາມກັງວົນກ່ຽວກັບຄວາມປອດໄພທີ່ສໍາຄັນແມ່ນເປັນຫ່ວງວ່າວຽກຂອງເຈົ້າກໍາລັງເຮັດວຽກເປັນຜູ້ໃຊ້ທີ່ບໍ່ແມ່ນຜູ້ເບິ່ງແຍງບໍ? ໃນກໍລະນີນີ້, ພວກເຮົາອາດຈະຕ້ອງການເຄື່ອງມືເຊັ່ນ: ການແຂ່ງຂັນ, YAML/JSON validator, plus ເປີດຕົວແທນນະໂຍບາຍ, ຜູ້ກວດສອບນະໂຍບາຍເພື່ອຮັບປະກັນວ່າສະພາບການ ເນື້ອໃນຄວາມປອດໄພ ວຽກງານຂອງເຈົ້າບໍ່ອະນຸຍາດໃຫ້ພາຊະນະແລ່ນດ້ວຍສິດທິຂອງຜູ້ເບິ່ງແຍງລະບົບ. ຖ້າອັນນີ້ຕ້ອງການ, ຜູ້ໃຊ້ສາມາດໃຊ້ນະໂຍບາຍງ່າຍໆໄດ້ ຮ່ອງ, ແບບນີ້:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

• ທາງເລືອກໃນການເຊື່ອມໂຍງກັບຜູ້ໃຫ້ບໍລິການຄລາວ. ຫນຶ່ງໃນທ່າອ່ຽງທີ່ຫນ້າສັງເກດທີ່ສຸດໃນເຕັກໂນໂລຢີສູງຂອງມື້ນີ້ແມ່ນການດໍາເນີນການເຮັດວຽກຢູ່ໃນຜູ້ໃຫ້ບໍລິການຟັງສາທາລະນະ. ການນໍາໃຊ້ອົງປະກອບ cloud-ຜູ້ໃຫ້ບໍລິການ Kubernetes ອະ​ນຸ​ຍາດ​ໃຫ້​ກຸ່ມ​ໃດ​ຫນຶ່ງ​ເຊື່ອມ​ໂຍງ​ກັບ​ຜູ້​ໃຫ້​ບໍ​ລິ​ຄ​ລາວ​ທີ່​ມັນ​ດໍາ​ເນີນ​ການ​. ຕົວຢ່າງ, ຖ້າຜູ້ໃຊ້ແລ່ນແອັບພລິເຄຊັນໃນ Kubernetes ໃນ AWS ແລະຕ້ອງການເປີດເຜີຍແອັບພລິເຄຊັນນັ້ນຜ່ານການບໍລິການ, ຜູ້ໃຫ້ບໍລິການຄລາວຊ່ວຍສ້າງບໍລິການໂດຍອັດຕະໂນມັດ. LoadBalancerເຊິ່ງຈະສະຫນອງການດຸ່ນດ່ຽງການໂຫຼດອັດຕະໂນມັດ Amazon Elastic Load Balancerເພື່ອປ່ຽນເສັ້ນທາງການຈະລາຈອນໄປຫາແອັບພລິເຄຊັນ pods.

ການຂະຫຍາຍ

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

ຕົວຢ່າງ, ຖ້າພວກເຮົາຕ້ອງການກໍານົດຊັບພະຍາກອນ CronTabຫຼັງຈາກນັ້ນ, ທ່ານສາມາດເຮັດບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.my.org
spec:
  group: my.org
  versions:
    - name: v1
      served: true
      storage: true
      Schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

ຕໍ່ມາພວກເຮົາສາມາດສ້າງຊັບພະຍາກອນ CronTab ບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

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

ມີເຄື່ອງມືຈໍານວນຫນຶ່ງໃນຊຸມຊົນທີ່ເຮັດໃຫ້ມັນງ່າຍສໍາລັບນັກພັດທະນາໃນການສ້າງຕົວປະຕິບັດການຂອງຕົນເອງ. ໃນ​ບັນ​ດາ​ພວກ​ເຂົາ - ກອບການດໍາເນີນການ ແລະລາວ ຜູ້ປະກອບການ SDK. SDK ນີ້ສະຫນອງພື້ນຖານທີ່ນັກພັດທະນາສາມາດເລີ່ມຕົ້ນສ້າງຕົວປະຕິບັດການໄດ້ໄວ. ໃຫ້ເວົ້າວ່າທ່ານສາມາດເລີ່ມຕົ້ນຈາກເສັ້ນຄໍາສັ່ງບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

ນີ້ສ້າງລະຫັດ boilerplate ທັງຫມົດສໍາລັບຜູ້ປະກອບການຂອງທ່ານ, ລວມທັງໄຟລ໌ YAML ແລະລະຫັດ Golang:

.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.go

ຈາກນັ້ນທ່ານສາມາດເພີ່ມ APIs ແລະຕົວຄວບຄຸມທີ່ຕ້ອງການ, ເຊັ່ນນີ້:

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

ຫຼັງຈາກນັ້ນ, ສຸດທ້າຍ, ປະກອບຕົວປະຕິບັດການແລະສົ່ງໄປທີ່ທະບຽນຂອງບັນຈຸຂອງທ່ານ:

$ operator-sdk build your.container.registry/youruser/myapp-operator

ຖ້າຜູ້ພັດທະນາຕ້ອງການການຄວບຄຸມຫຼາຍກວ່າເກົ່າ, ລະຫັດ boilerplate ໃນໄຟລ໌ Go ສາມາດປ່ຽນແປງໄດ້. ຕົວຢ່າງ, ເພື່ອດັດແປງສະເພາະຂອງຕົວຄວບຄຸມ, ທ່ານສາມາດເຮັດການປ່ຽນແປງໄຟລ໌ controller.go.

ໂຄງການອື່ນ ທຸກບ່ອນ, ອະນຸຍາດໃຫ້ທ່ານສ້າງຄໍາຖະແຫຼງທີ່ໃຊ້ພຽງແຕ່ໄຟລ໌ YAML ປະກາດ. ຕົວຢ່າງ, ຜູ້ປະກອບການສໍາລັບ Apache Kafka ຈະຖືກກໍານົດປະມານ ສະນັ້ນ. ດ້ວຍມັນ, ທ່ານສາມາດຕິດຕັ້ງກຸ່ມ Kafka ຢູ່ເທິງ Kubernetes ດ້ວຍສອງສາມຄໍາສັ່ງ:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

ແລະຫຼັງຈາກນັ້ນ configure ມັນດ້ວຍຄໍາສັ່ງອື່ນ:

$ kubectl kudo install kafka --instance=my-kafka-name 
            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 
            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m 
            -p BROKER_COUNT=5 -p BROKER_MEM=4096m 
            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 
            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

ນະວັດຕະ ກຳ

ໃນໄລຍະສອງສາມປີຜ່ານມາ, ການປ່ອຍ Kubernetes ທີ່ສໍາຄັນໄດ້ອອກມາທຸກໆສອງສາມເດືອນ - ນັ້ນແມ່ນ, ສາມຫາສີ່ການປ່ອຍໃຫຍ່ຕໍ່ປີ. ຈໍານວນຂອງລັກສະນະໃຫມ່ທີ່ນໍາສະເຫນີໃນແຕ່ລະພວກມັນບໍ່ຫຼຸດລົງ. ຍິ່ງໄປກວ່ານັ້ນ, ບໍ່ມີສັນຍານທີ່ຈະຊ້າລົງເຖິງແມ່ນວ່າໃນເວລາທີ່ມີຄວາມຫຍຸ້ງຍາກເຫຼົ່ານີ້ - ເບິ່ງສິ່ງທີ່ສະຖານະການໃນປັດຈຸບັນ ກິດຈະກໍາໂຄງການ Kubernetes ໃນ Github.

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

ຊຸມຊົນ

ລັກສະນະທີ່ສໍາຄັນອີກອັນຫນຶ່ງຂອງຄວາມນິຍົມຂອງ Kubernetes ແມ່ນຄວາມເຂັ້ມແຂງຂອງຊຸມຊົນຂອງຕົນ. ໃນປີ 2015, ເມື່ອເຖິງເວີຊັນ 1.0, Kubernetes ໄດ້ຮັບການສະໜັບສະໜູນໂດຍ ມູນນິທິຄອມພິວເຕີ້ Cloud Native.

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

ມູນນິທິ Cloud Native ຍັງເປັນເຈົ້າພາບ CloudNativeCon/KubeCon, ເຊິ່ງໃນເວລາຂຽນ, ເປັນກອງປະຊຸມແຫຼ່ງເປີດທີ່ໃຫຍ່ທີ່ສຸດໃນໂລກ. ໂດຍປົກກະຕິຈັດຂຶ້ນສາມຄັ້ງຕໍ່ປີ, ມັນນໍາເອົາຜູ້ຊ່ຽວຊານຫລາຍພັນຄົນທີ່ຕ້ອງການປັບປຸງ Kubernetes ແລະລະບົບນິເວດຂອງມັນ, ເຊັ່ນດຽວກັນກັບການຮຽນຮູ້ລັກສະນະໃຫມ່ທີ່ປາກົດໃນທຸກໆສາມເດືອນ.

ຍິ່ງໄປກວ່ານັ້ນ, Cloud Native Foundation ມີ ຄະນະກໍາມະການກວດກາດ້ານວິຊາການ, ເຊິ່ງ, ພ້ອມກັບ SIGs, ທົບທວນຄືນໃຫມ່ແລະທີ່ມີຢູ່ແລ້ວ ໂຄງການ ກອງທຶນສຸມໃສ່ລະບົບນິເວດເມຄ. ສ່ວນໃຫຍ່ຂອງໂຄງການເຫຼົ່ານີ້ຊ່ວຍປັບປຸງຄວາມເຂັ້ມແຂງຂອງ Kubernetes.

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

ອະນາຄົດ

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

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

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