អំពីការកើនឡើងប្រជាប្រិយភាពរបស់ Kubernetes

ហេហេ!

នៅចុងបញ្ចប់នៃរដូវក្តៅយើងចង់រំលឹកអ្នកថាយើងបន្តធ្វើការលើប្រធានបទ Kubernetes ហើយបានសម្រេចចិត្តបោះពុម្ពអត្ថបទពី Stackoverflow ដែលបង្ហាញពីស្ថានភាពនៃកិច្ចការនៅក្នុងគម្រោងនេះនៅដើមខែមិថុនា។

រីករាយអាន!

នៅពេលសរសេរអត្ថបទនេះ អាយុរបស់ Kubernetes គឺប្រហាក់ប្រហែល។ អាយុប្រាំមួយឆ្នាំហើយក្នុងរយៈពេល XNUMX ឆ្នាំកន្លងមកនេះ ប្រជាប្រិយភាពរបស់វាបានកើនឡើងយ៉ាងខ្លាំង ដែលវាជាប់ចំណាត់ថ្នាក់ជាប់លាប់ ចូលចិត្តបំផុត។ វេទិកា។ Kubernetes ជាប់ចំណាត់ថ្នាក់ទីបីនៅឆ្នាំនេះ។ ដើម្បីសង្ខេប៖ Kubernetes គឺជាវេទិកាដែលត្រូវបានរចនាឡើងសម្រាប់ដំណើរការ និងរៀបចំបន្ទុកការងារដែលមានផ្ទុក។

កុងតឺន័របានចាប់ផ្តើមជាការរចនាពិសេសសម្រាប់ដំណើរការដាច់ដោយឡែកនៅក្នុងលីនុច។ កុងតឺន័របានរួមបញ្ចូលតាំងពីឆ្នាំ 2007 ក្រុមហើយចាប់តាំងពីឆ្នាំ 2002 - namespaces ។ កុងតឺន័រ​ត្រូវ​បាន​រចនា​កាន់​តែ​ល្អ​ជាង​មុន​នៅ​ឆ្នាំ 2008 ដែល​វា​មាន​ស្រាប់ អិល។ ស៊ី។ ស៊ីហើយ Google បានបង្កើតយន្តការសាជីវកម្មផ្ទៃក្នុងរបស់ខ្លួនដែលហៅថា បូ។ដែលជាកន្លែងដែល "ការងារទាំងអស់ត្រូវបានធ្វើនៅក្នុងធុង" ។ ពីទីនេះយើងឆ្ពោះទៅមុខយ៉ាងលឿនរហូតដល់ឆ្នាំ 2013 នៅពេលដែលការចេញផ្សាយ Docker លើកដំបូងបានកើតឡើង ហើយទីបំផុតធុងបានក្លាយជាដំណោះស្រាយដ៏ពេញនិយមមួយ។ នៅពេលនោះ ឧបករណ៍សំខាន់សម្រាប់ការរៀបចំកុងតឺន័រគឺ មេសូសទោះបីជាគាត់មិនមានប្រជាប្រិយភាពខ្លាំងក៏ដោយ។ Kubernetes ត្រូវបានចេញផ្សាយជាលើកដំបូងនៅក្នុងឆ្នាំ 2015 បន្ទាប់មកឧបករណ៍នេះបានក្លាយជាស្តង់ដារជាក់ស្តែងនៅក្នុងវិស័យនៃការរៀបចំកុងតឺន័រ។

ដើម្បី​ព្យាយាម​យល់​ពី​មូលហេតុ​ដែល Kubernetes មាន​ប្រជាប្រិយភាព​ខ្លាំង សូម​ព្យាយាម​ឆ្លើយ​សំណួរ​មួយ​ចំនួន។ តើនៅពេលណាដែលអ្នកអភិវឌ្ឍន៍អាចយល់ព្រមលើរបៀបដាក់ពង្រាយកម្មវិធីទៅផលិតកម្ម? តើអ្នកដឹងថាអ្នកអភិវឌ្ឍន៍ប៉ុន្មាននាក់ដែលប្រើឧបករណ៍ដូចដែលពួកគេត្រូវបានផ្តល់ឱ្យចេញពីប្រអប់? តើមានអ្នកគ្រប់គ្រងលើពពកប៉ុន្មាននាក់សព្វថ្ងៃនេះ ដែលមិនយល់ពីរបៀបដែលកម្មវិធីដំណើរការ? យើងនឹងពិនិត្យមើលចម្លើយចំពោះសំណួរទាំងនេះនៅក្នុងអត្ថបទនេះ។

រចនាសម្ព័ន្ធ YAML

នៅក្នុងពិភពលោកដែលបានចេញពីអាយ៉ង និងមេចុងភៅទៅ 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 ការគ្រប់គ្រងកំណែប្រតិបត្តិការ។ វិធីសាស្រ្តនេះអនុញ្ញាតឱ្យអ្នករក្សាទុកឯកសារ Kubernetes YAML ទាំងអស់នៅក្នុងឃ្លាំង git ដូច្នេះអ្នកអាចតាមដានបានច្បាស់នៅពេលដែលការផ្លាស់ប្តូរត្រូវបានធ្វើឡើង អ្នកណាជាអ្នកបង្កើតវា និងអ្វីដែលបានផ្លាស់ប្តូរពិតប្រាកដ។ នេះបង្កើនតម្លាភាពនៃប្រតិបត្តិការនៅទូទាំងអង្គភាព និងបង្កើនប្រសិទ្ធភាពប្រតិបត្តិការដោយលុបបំបាត់ភាពមិនច្បាស់លាស់ ជាពិសេសនៅកន្លែងដែលបុគ្គលិកគួរស្វែងរកធនធានដែលពួកគេត្រូវការ។ ក្នុងពេលជាមួយគ្នានេះ វាកាន់តែងាយស្រួលធ្វើការផ្លាស់ប្តូរដោយស្វ័យប្រវត្តិចំពោះធនធាន Kubernetes ដោយគ្រាន់តែបញ្ចូលសំណើទាញ។
• លទ្ធភាពធ្វើមាត្រដ្ឋាន។ នៅពេលដែលធនធានត្រូវបានកំណត់ថាជា YAML វាក្លាយជាភាពងាយស្រួលបំផុតសម្រាប់ប្រតិបត្តិករចង្កោមក្នុងការផ្លាស់ប្តូរលេខមួយ ឬពីរនៅក្នុងធនធាន Kubernetes ដោយហេតុនេះផ្លាស់ប្តូររបៀបដែលវាធ្វើមាត្រដ្ឋាន។ Kubernetes ផ្តល់នូវយន្តការសម្រាប់ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិផ្តេក ដែលអាចត្រូវបានប្រើដើម្បីកំណត់យ៉ាងងាយស្រួលនូវអ្វីដែលចំនួនអប្បបរមា និងអតិបរមានៃផតត្រូវបានទាមទារនៅក្នុងការកំណត់រចនាសម្ព័ន្ធការដាក់ឱ្យប្រើប្រាស់ជាក់លាក់ ដើម្បីគ្រប់គ្រងកម្រិតទាប និងកម្រិតខ្ពស់នៃចរាចរណ៍។ ឧទាហរណ៍ ប្រសិនបើអ្នកបានដាក់ពង្រាយការកំណត់រចនាសម្ព័ន្ធដែលទាមទារសមត្ថភាពបន្ថែមដោយសារតែចរាចរណ៍កើនឡើងភ្លាមៗនោះ 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"
}

• ជម្រើសសម្រាប់ការរួមបញ្ចូលជាមួយអ្នកផ្តល់សេវាពពក។ និន្នាការគួរឱ្យកត់សម្គាល់បំផុតមួយនៅក្នុងបច្ចេកវិទ្យាខ្ពស់នាពេលបច្ចុប្បន្ននេះគឺការដំណើរការបន្ទុកលើអ្នកផ្តល់សេវាពពកសាធារណៈ។ ការប្រើប្រាស់សមាសធាតុ អ្នកផ្តល់សេវាពពក Kubernetes អនុញ្ញាតឱ្យចង្កោមណាមួយរួមបញ្ចូលជាមួយអ្នកផ្តល់សេវាពពកដែលវាដំណើរការ។ ឧទាហរណ៍ ប្រសិនបើអ្នកប្រើប្រាស់ដំណើរការកម្មវិធីនៅក្នុង Kubernetes នៅលើ AWS ហើយចង់បង្ហាញកម្មវិធីនោះតាមរយៈសេវាកម្ម នោះអ្នកផ្តល់សេវាពពកជួយបង្កើតសេវាកម្មដោយស្វ័យប្រវត្តិ។ LoadBalancerដែលនឹងផ្តល់តុល្យភាពផ្ទុកដោយស្វ័យប្រវត្តិ Amazon Elastic Load Balancerដើម្បីប្តូរទិសចរាចរណ៍ទៅកាន់កម្មវិធី pods ។

លទ្ធភាពពង្រីក

Kubernetes គឺអាចពង្រីកបាន ហើយអ្នកអភិវឌ្ឍន៍ចូលចិត្តវា។ មានសំណុំនៃធនធានដែលមានដូចជា pods, ការដាក់ពង្រាយ, 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

ហើយបន្ទាប់មកកំណត់រចនាសម្ព័ន្ធវាដោយប្រើពាក្យបញ្ជាផ្សេងទៀត៖

$ 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 សំខាន់ៗបានចេញជារៀងរាល់ពីរបីខែម្តង ពោលគឺការចេញផ្សាយធំៗចំនួន XNUMX ទៅ XNUMX ក្នុងមួយឆ្នាំ។ ចំនួននៃមុខងារថ្មីដែលបានណែនាំនៅក្នុងពួកវានីមួយៗមិនថយចុះទេ។ ជាងនេះទៅទៀត វាមិនមានសញ្ញាណាមួយនៃការថមថយឡើយ សូម្បីតែនៅក្នុងគ្រាដ៏លំបាកទាំងនេះក៏ដោយ សូមក្រឡេកមើលថាតើស្ថានភាពពេលនេះជាអ្វី សកម្មភាពគម្រោង Kubernetes នៅលើ Github.

សមត្ថភាព​ថ្មី​អនុញ្ញាត​ឱ្យ​អ្នក​ធ្វើ​ប្រតិបត្តិការ​ចង្កោម​កាន់តែ​បត់បែន​តាម​បន្ទុក​ការងារ​ចម្រុះ។ លើសពីនេះ អ្នកសរសេរកម្មវិធីរីករាយនឹងការគ្រប់គ្រងកាន់តែខ្លាំងនៅពេលដាក់ពង្រាយកម្មវិធីដោយផ្ទាល់ទៅផលិតកម្ម។

សហគមន៍

ទិដ្ឋភាពសំខាន់មួយទៀតនៃប្រជាប្រិយភាពរបស់ Kubernetes គឺភាពរឹងមាំនៃសហគមន៍របស់ខ្លួន។ នៅឆ្នាំ 2015 នៅពេលឈានដល់កំណែ 1.0 Kubernetes ត្រូវបានឧបត្ថម្ភដោយ មូលនិធិកុំព្យូទ័រពពកកំណើត.

ក៏មានសហគមន៍ផ្សេងៗផងដែរ។ SIG (ក្រុមចំណាប់អារម្មណ៍ពិសេស) បានផ្តោតលើការធ្វើការលើផ្នែកផ្សេងៗនៃ Kubernetes នៅពេលដែលគម្រោងមានការវិវត្ត។ ក្រុមទាំងនេះកំពុងបន្ថែមមុខងារថ្មីៗជាបន្តបន្ទាប់ ដែលធ្វើឱ្យការធ្វើការជាមួយ Kubernetes កាន់តែងាយស្រួល និងងាយស្រួល។

មូលនិធិ Cloud Native ក៏ធ្វើជាម្ចាស់ផ្ទះ CloudNativeCon/KubeCon ដែលនៅពេលសរសេរ គឺជាសន្និសីទប្រភពបើកចំហដ៏ធំបំផុតនៅក្នុងពិភពលោក។ ជាធម្មតាធ្វើឡើងបីដងក្នុងមួយឆ្នាំ វាប្រមូលផ្តុំអ្នកជំនាញរាប់ពាន់នាក់ដែលចង់កែលម្អ Kubernetes និងប្រព័ន្ធអេកូរបស់វា ក៏ដូចជាស្វែងយល់ពីមុខងារថ្មីៗដែលលេចឡើងរៀងរាល់បីខែម្តង។

លើសពីនេះទៅទៀត Cloud Native Foundation មាន គណៈកម្មាធិការត្រួតពិនិត្យបច្ចេកទេសដែលរួមជាមួយនឹង SIGs ពិនិត្យមើលថ្មី និងដែលមានស្រាប់ គម្រោង មូលនិធិផ្តោតលើប្រព័ន្ធអេកូឡូស៊ីពពក។ គម្រោងទាំងនេះភាគច្រើនជួយកែលម្អចំណុចខ្លាំងរបស់ Kubernetes ។

ជាចុងក្រោយ ខ្ញុំជឿថា Kubernetes នឹងមិនទទួលបានជោគជ័យដូចដែលវាគ្មានការខិតខំប្រឹងប្រែងដោយមនសិការរបស់សហគមន៍ទាំងមូល ដែលមនុស្សនៅជាមួយគ្នា ប៉ុន្តែក្នុងពេលតែមួយស្វាគមន៍អ្នកចំណូលថ្មីចូលទៅក្នុងផ្នត់គំនិត។

អនាគត

បញ្ហាប្រឈមចម្បងមួយដែលអ្នកអភិវឌ្ឍន៍នឹងត្រូវដោះស្រាយនៅពេលអនាគតគឺសមត្ថភាពក្នុងការផ្តោតលើព័ត៌មានលម្អិតនៃកូដដោយខ្លួនឯង មិនមែនលើហេដ្ឋារចនាសម្ព័ន្ធដែលវាដំណើរការនោះទេ។ វាបំពេញតាមនិន្នាការទាំងនេះ គំរូស្ថាបត្យកម្មគ្មានម៉ាស៊ីនមេដែលជាការឈានមុខគេមួយនាពេលបច្ចុប្បន្ននេះ។ ក្របខ័ណ្ឌកម្រិតខ្ពស់មានរួចហើយ ឧ. គួរអោយចង់ដឹង и OpenFaasដែលប្រើ Kubernetes ដើម្បីទាញយកហេដ្ឋារចនាសម្ព័ន្ធពីអ្នកអភិវឌ្ឍន៍។

នៅក្នុងអត្ថបទនេះ យើងគ្រាន់តែគូសលើផ្ទៃនៃស្ថានភាពបច្ចុប្បន្នរបស់ Kubernetes ប៉ុណ្ណោះ - តាមពិតទៅ វាគ្រាន់តែជាផ្នែកនៃផ្ទាំងទឹកកកប៉ុណ្ណោះ។ អ្នកប្រើប្រាស់ Kubernetes មានធនធាន សមត្ថភាព និងការកំណត់រចនាសម្ព័ន្ធផ្សេងៗជាច្រើនទៀតតាមលទ្ធភាពរបស់ពួកគេ។

ប្រភព: www.habr.com