Kubernetes ၏ လူကြိုက်များမှု တိုးပွားလာခြင်းအကြောင်း

ဟေး ဟာဘ!

နွေရာသီ၏အဆုံးတွင်၊ ကျွန်ုပ်တို့သည် ခေါင်းစဉ်ကို ဆက်လက်လုပ်ဆောင်ရန် သင့်အား သတိပေးလိုပါသည်။ Kubernetes ဇွန်လအစတွင် ဤပရောဂျက်ရှိ အခြေအနေများကို သရုပ်ပြသည့် Stackoverflow မှ ဆောင်းပါးတစ်ပုဒ် ထုတ်ဝေရန် ဆုံးဖြတ်ခဲ့သည်။

စာဖတ်ရတာကိုနှစ်သက်ပါတယ်

ဤဆောင်းပါးကိုရေးသားချိန်တွင် Kubernetes ၏အသက်သည် ခန့်မှန်းခြေအားဖြင့်ဖြစ်သည်။ ခြောက်နှစ်ပြီးခဲ့သော နှစ်နှစ်တာကာလအတွင်း ၎င်း၏ကျော်ကြားမှုသည် အလွန်ကြီးထွားလာခဲ့ပြီး ၎င်းသည် ၎င်းကို အစဉ်တစိုက် အဆင့်သတ်မှတ်ခဲ့သည်။ အကြိုက်ဆုံး ပလက်ဖောင်းများ။ Kubernetes သည် ယခုနှစ်တွင် တတိယအဆင့်ရှိသည်။ ပြန်လည်သုံးသပ်ရန်- Kubernetes သည် ကွန်တိန်နာတင်ထားသော အလုပ်များကို လုပ်ဆောင်ရန်နှင့် စီမံကွပ်ကဲရန်အတွက် ဒီဇိုင်းထုတ်ထားသော ပလပ်ဖောင်းတစ်ခုဖြစ်သည်။

ကွန်တိန်နာများသည် Linux ရှိ လုပ်ငန်းစဉ်များကို သီးခြားခွဲထုတ်ရန်အတွက် အထူးဒီဇိုင်းအဖြစ် စတင်ခဲ့သည်။ ကွန်တိန်နာများသည် ၂၀၀၇ ခုနှစ်ကတည်းက ပါဝင်သည်။ အုပ်စုများနှင့် 2002 ခုနှစ်ကတည်းက - namespaces ။ ကွန်တိန်နာများကို 2008 ခုနှစ်တွင် ပိုမိုကောင်းမွန်အောင် ဒီဇိုင်းထုတ်ခဲ့ပြီး စတင်အသုံးပြုလာခဲ့သည်။ LXCGoogle သည် ၎င်း၏ကိုယ်ပိုင်အတွင်းပိုင်းကော်ပိုရိတ်ယန္တရားကို တီထွင်ခဲ့သည်။ Borg"အလုပ်အားလုံးကို ကွန်တိန်နာထဲမှာ ပြီးပါပြီ။" Docker ၏ပထမဆုံးထုတ်လွှတ်မှုစတင်သောအခါ၊ 2013 သို့ကျွန်ုပ်တို့အလျင်အမြန်ရှေ့ဆက်ပြီးကွန်တိန်နာများသည်နောက်ဆုံးတွင်ရေပန်းစားသောအစုလိုက်အပြုံလိုက်ဖြေရှင်းချက်ဖြစ်လာခဲ့သည်။ ထိုအချိန်တွင်၊ ကွန်တိန်နာတီးမှုတ်ခြင်းအတွက် အဓိကကိရိယာမှာ Mesosကျော်ကြားလှသောလူမဟုတ်သော်လည်း၊ Kubernetes ကို 2015 ခုနှစ်တွင် စတင်ဖြန့်ချိခဲ့ပြီး၊ ထို့နောက်တွင် ဤကိရိယာသည် ကွန်တိန်နာတီးမှုတ်ခြင်းနယ်ပယ်တွင် အချက်အလက်မှန်စံဖြစ်လာခဲ့သည်။

Kubernetes သည် အဘယ်ကြောင့် ဤမျှရေပန်းစားသည်ကို နားလည်ရန် ကြိုးစားရန်၊ မေးခွန်းအချို့ကို ဖြေကြည့်ကြပါစို့။ အပလီကေးရှင်းများကို ထုတ်လုပ်ရေးတွင် မည်သို့အသုံးချရမည်ကို ဆော့ဖ်ဝဲအင်ဂျင်နီယာများက သဘောတူညီနိုင်ခဲ့သည့် နောက်ဆုံးအချိန်ကား မည်သည့်အချိန်တွင် ဖြစ်သနည်း။ ကိရိယာအစုံအလင်ကို ကွက်လပ်အပြင်တွင် ပံ့ပိုးပေးထားသည့်အတိုင်း developer မည်မျှအသုံးပြုသည်ကို သင်သိပါသလား။ ယနေ့ခေတ်တွင် အပလီကေးရှင်းများ အလုပ်လုပ်ပုံကို နားမလည်သော cloud စီမံခန့်ခွဲသူ မည်မျှရှိသနည်း။ ဤမေးခွန်းများအတွက် အဖြေများကို ဤဆောင်းပါးတွင် ကြည့်ရှုပါမည်။

YAML အနေဖြင့် အခြေခံအဆောက်အဦ

Puppet နှင့် Chef မှ Kubernetes သို့ပြောင်းသွားသောကမ္ဘာတွင်၊ အကြီးမားဆုံးပြောင်းလဲမှုတစ်ခုမှာ "infrastructure as code" မှ "infrastructure as data" သို့ပြောင်းခြင်း—အထူးသဖြင့် YAML ကဲ့သို့ဖြစ်သည်။ pods၊ configurations၊ deployed instances၊ volumes အစရှိသည်တို့ပါဝင်သည့် 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 ဗားရှင်းထိန်းချုပ်မှု။ ဤနည်းလမ်းသည် သင့်အား Kubernetes YAML ဖိုင်အားလုံးကို git repositories တွင် သိမ်းဆည်းထားနိုင်သောကြောင့် အပြောင်းအလဲတစ်ခုပြုလုပ်သည့်အခါ၊ မည်သူက ၎င်းကိုပြုလုပ်ခဲ့သည်နှင့် အတိအကျပြောင်းလဲသွားသည်ကို အတိအကျခြေရာခံနိုင်ပါသည်။ ၎င်းသည် အဖွဲ့အစည်းတစ်ဝှမ်းလုံးရှိ လုပ်ငန်းဆောင်တာများ၏ ပွင့်လင်းမြင်သာမှုကို တိုးမြင့်လာစေပြီး အထူးသဖြင့် ဝန်ထမ်းများသည် ၎င်းတို့လိုအပ်သည့် အရင်းအမြစ်များကို ရှာဖွေသင့်သည့်နေရာတွင် မရှင်းလင်းမှုများကို ဖယ်ရှားခြင်းဖြင့် လုပ်ငန်းဆောင်ရွက်မှုဆိုင်ရာ စွမ်းဆောင်ရည်ကို မြှင့်တင်ပေးပါသည်။ တစ်ချိန်တည်းမှာပင်၊ ဆွဲယူတောင်းဆိုမှုတစ်ခုကို ပေါင်းစည်းရုံဖြင့် 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 တရားဝင်စနစ်၊ အပေါင်း မူဝါဒအေးဂျင့်ဖွင့်ပါ။စကားစပ်ကြောင်း သေချာစေရန် မူဝါဒ မှန်ကန်သူ လုံခြုံရေးအကြောင်းအရာ သင်၏အလုပ်တာဝန်များသည် စီမံခန့်ခွဲသူအခွင့်ထူးများဖြင့် ကွန်တိန်နာကိုလည်ပတ်ရန် ခွင့်မပြုပါ။ လိုအပ်ပါက အသုံးပြုသူများသည် ရိုးရှင်းသောမူဝါဒကို ကျင့်သုံးနိုင်သည်။ ကျွန်တော်ဆုတောင်းပါတယ်, ဒီလိုမျိုး:

package main

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

• cloud ဝန်ဆောင်မှုပေးသူနှင့် ပေါင်းစည်းခြင်းအတွက် ရွေးချယ်စရာများ။ ယနေ့ခေတ် နည်းပညာမြင့်မားမှုတွင် အထင်ရှားဆုံးသော ခေတ်ရေစီးကြောင်းများထဲမှ တစ်ခုသည် အများသူငှာ cloud ဝန်ဆောင်မှုပေးသူများပေါ်တွင် အလုပ်များလုပ်ဆောင်ရန်ဖြစ်သည်။ အစိတ်အပိုင်းကိုအသုံးပြုခြင်း။ cloud-ပံ့ပိုးပေးသူ Kubernetes သည် မည်သည့် အစုအဝေးကိုမဆို ၎င်းလည်ပတ်နေသော cloud ဝန်ဆောင်မှုပေးသူနှင့် ပေါင်းစည်းရန် ခွင့်ပြုသည်။ ဥပမာအားဖြင့်၊ အသုံးပြုသူတစ်ဦးသည် AWS တွင် Kubernetes တွင် အပလီကေးရှင်းတစ်ခုအား လုပ်ဆောင်ပြီး ထိုအက်ပ်အား ဝန်ဆောင်မှုတစ်ခုမှတစ်ဆင့် ဖော်ထုတ်လိုပါက cloud ဝန်ဆောင်မှုပေးသူက ဝန်ဆောင်မှုကို အလိုအလျောက်ဖန်တီးပေးပါသည်။ LoadBalancer၎င်းသည် load balancer ကိုအလိုအလျောက်ပေးလိမ့်မည်။ Amazon Elastic Load Balancerအပလီကေးရှင်း pods သို့ လမ်းကြောင်းပြောင်းရန်။

ချဲ့ထွင်နိုင်မှု

Kubernetes သည် အလွန်ကျယ်ပြန့်ပြီး developer များက ၎င်းကိုနှစ်သက်သည်။ ရရှိနိုင်သောအရင်းအမြစ်များဖြစ်သည့် pods၊ ဖြန့်ကျက်မှုများ၊ StatefulSetsလျှို့ဝှက်ချက်များ၊ ConfigMapsစသည်တို့ အသုံးပြုသူများနှင့် developer များသည် ဖောင်တွင် အခြားအရင်းအမြစ်များကို ထည့်နိုင်သည်။ စိတ်ကြိုက်အရင်းအမြစ် အဓိပ္ပါယ်ဖွင့်ဆိုချက်များ.

ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် အရင်းအမြစ်တစ်ခုကို သတ်မှတ်လိုလျှင် 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 အစုအဝေးရှိ အထူးလုပ်ငန်းစဉ်တစ်ခုဖြစ်သည်။ထိန်းချုပ်ပတ်လမ်း“ အော်ပရေတာတစ်ခု၏အကူအညီဖြင့်၊ အသုံးပြုသူသည် Kubernetes API နှင့် အချက်အလက်ဖလှယ်ခြင်းဖြင့် CRDs (စိတ်ကြိုက်အရင်းအမြစ်အဓိပ္ပါယ်ဖွင့်ဆိုချက်များ) ကို အလိုအလျောက်လုပ်ဆောင်နိုင်သည်။

ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် ၎င်းတို့၏ကိုယ်ပိုင်အော်ပရေတာများကိုဖန်တီးရန်လွယ်ကူစေသည့်အသိုင်းအဝိုင်းတွင်ကိရိယာများစွာရှိသည်။ သူတို့ထဲတွင် - အော်ပရေတာဘောင် နှင့် အော်ပရေတာ SDK. ဤ SDK သည် developer သည် အော်ပရေတာတစ်ခုကို လျင်မြန်စွာ စတင်ဖန်တီးနိုင်သည့် အခြေခံအုတ်မြစ်ကို ပံ့ပိုးပေးပါသည်။ သင်ဤကဲ့သို့သော command line မှစတင်နိုင်သည်ဆိုကြပါစို့။

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

၎င်းသည် 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 နှင့် controller ကို ဤကဲ့သို့ ထည့်နိုင်သည်။

$ 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

ဆော့ဖ်ဝဲအင်ဂျင်နီယာသည် ပိုမိုထိန်းချုပ်လိုပါက Go ဖိုင်များတွင် ဘွိုင်လာပြားကုဒ်ကို ပြောင်းလဲနိုင်သည်။ ဥပမာအားဖြင့်၊ controller ၏အသေးစိတ်အချက်အလက်များကိုမွမ်းမံရန်၊ သင်သည်ဖိုင်ကိုပြောင်းလဲနိုင်သည်။ controller.go.

နောက်ထပ် ပရောဂျက်တစ်ခု နေရာတိုင်း၊ ကြေငြာချက် YAML ဖိုင်များကိုသာ အသုံးပြု၍ ထုတ်ပြန်ချက်များအား ဖန်တီးနိုင်စေပါသည်။ ဥပမာအားဖြင့်၊ Apache Kafka အတွက် အော်ပရေတာတစ်ခုသည် ခန့်မှန်းခြေအားဖြင့် သတ်မှတ်ခံရမည်ဖြစ်သည်။ ဒါကြောင့်. ၎င်းနှင့်အတူ၊ သင်သည် command အနည်းငယ်ဖြင့် Kubernetes ၏ထိပ်တွင် Kafka အစုအဝေးကို ထည့်သွင်းနိုင်သည်-

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

ပြီးလျှင် ၎င်းကို အခြား command ဖြင့် 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 ဖြန့်ချိမှုများသည် လအနည်းငယ်တိုင်းတွင် ထွက်ပေါ်နေပါသည်- ဆိုလိုသည်မှာ တစ်နှစ်လျှင် အကြီးစားထုတ်မှု သုံးမျိုးမှ လေးခုအထိရှိသည်။ ၎င်းတို့ တစ်ခုစီတွင် မိတ်ဆက်သည့် အင်္ဂါရပ်အသစ် အရေအတွက်သည် လျော့မသွားပါ။ ထို့အပြင်၊ ဤခက်ခဲသောအချိန်များတွင်ပင် နှေးကွေးသွားမည့် လက္ခဏာများ မတွေ့ရသေးပါ - ယခုအခြေအနေမှာ ကြည့်ပါ။ Github ရှိ Kubernetes ပရောဂျက်လုပ်ဆောင်ချက်.

စွမ်းရည်အသစ်များသည် မတူကွဲပြားသော အလုပ်တာဝန်များတစ်လျှောက်တွင် လုပ်ဆောင်ချက်များကို ပိုမိုပျော့ပြောင်းစွာ အစုလိုက်အပြုံလိုက် လုပ်ဆောင်နိုင်စေပါသည်။ ထို့အပြင်၊ ပရိုဂရမ်မာများသည် အပလီကေးရှင်းများကို ထုတ်လုပ်မှုတွင် တိုက်ရိုက်အသုံးချသည့်အခါ ပိုမိုထိန်းချုပ်မှုကို နှစ်သက်ကြသည်။

အသိုင်းအဝိုင်း

Kubernetes ၏ကျော်ကြားမှု၏နောက်ထပ်အဓိကအချက်မှာ ၎င်း၏အသိုင်းအဝိုင်း၏အင်အားဖြစ်သည်။ 2015 ခုနှစ်တွင် ဗားရှင်း 1.0 သို့ရောက်ရှိသောအခါ Kubernetes မှ ပံ့ပိုးကူညီမှုပေးခဲ့သည်။ Cloud Native ကွန်ပျူတာဖောင်ဒေးရှင်း.

အသိုင်းအဝန်းလည်း အမျိုးမျိုးရှိတယ်။ SIG ပရောဂျက်တိုးတက်ပြောင်းလဲလာသည်နှင့်အမျှ Kubernetes ၏ မတူညီသောနယ်ပယ်များတွင် လုပ်ဆောင်ရန် (အထူးစိတ်ဝင်စားသည့်အုပ်စုများ) အာရုံစိုက်ခဲ့သည်။ ဤအဖွဲ့များသည် Kubernetes နှင့် လုပ်ဆောင်ရာတွင် ပိုမိုအဆင်ပြေပြီး အဆင်ပြေစေမည့် အင်္ဂါရပ်အသစ်များကို အဆက်မပြတ်ထည့်သွင်းနေပါသည်။

Cloud Native Foundation သည် စာရေးနေချိန်တွင် ကမ္ဘာပေါ်တွင် အကြီးဆုံး open source ကွန်ဖရင့်ဖြစ်သည့် CloudNativeCon/KubeCon ကိုလည်း လက်ခံကျင်းပပါသည်။ ပုံမှန်အားဖြင့် တစ်နှစ်လျှင် သုံးကြိမ်ကျင်းပလေ့ရှိပြီး Kubernetes နှင့် ၎င်း၏ဂေဟစနစ်ကို မြှင့်တင်လိုသော ထောင်ပေါင်းများစွာသော ပရော်ဖက်ရှင်နယ်များကို စုစည်းကာ သုံးလတစ်ကြိမ်ပေါ်လာသည့် ဝန်ဆောင်မှုအသစ်များကို လေ့လာပါ။

ဒါ့အပြင် Cloud Native Foundation လည်း ရှိပါတယ်။ နည်းပညာကြီးကြပ်ရေးကော်မတီSIGs များနှင့်အတူ အသစ်နှင့် ရှိပြီးသားကို ပြန်လည်သုံးသပ်သည်။ စီမံကိန်းများ ရန်ပုံငွေများသည် cloud ဂေဟစနစ်ကို အာရုံစိုက်သည်။ ဤပရောဂျက်အများစုသည် Kubernetes ၏ အားသာချက်များကို မြှင့်တင်ပေးသည်။

နောက်ဆုံးအနေနဲ့၊ လူတွေက တညီတညွတ်တည်း လက်တွဲနေကြပေမယ့် တစ်ချိန်တည်းမှာပဲ လူသစ်တွေကို ကြိုဆိုတဲ့ အသိုက်အဝန်းတစ်ခုလုံးရဲ့ သတိရှိမှုတွေမပါဘဲ Kubernetes လောက် အောင်မြင်မှာမဟုတ်ဘူးလို့ ကျွန်တော်ယုံကြည်ပါတယ်။

အနာဂတ်မှာ

အနာဂတ်တွင် developer များ ရင်ဆိုင်ရမည့် အဓိကစိန်ခေါ်မှုများထဲမှတစ်ခုမှာ ကုဒ်၏အသေးစိတ်အချက်အလက်များကို ၎င်းကိုယ်တိုင်လုပ်ဆောင်နိုင်သည့် အခြေခံအဆောက်အအုံအပေါ်မဟုတ်ဘဲ အာရုံစိုက်နိုင်မှုဖြစ်သည်။ ၎င်းသည် ဤလမ်းကြောင်းများနှင့် ကိုက်ညီပါသည်။ ဆာဗာမဲ့ ဗိသုကာဆိုင်ရာ ပါရာဒိုင်းယနေ့ခေတ် ဦးဆောင်သူများထဲမှ တစ်ဦးဖြစ်သည်။ အဆင့်မြင့်ဘောင်များ ရှိနှင့်ပြီးဖြစ်သည်၊ ဥပမာ၊ တတ်မြောက်သော и OpenFaasဆော့ဖ်ဝဲရေးသားသူထံမှ အခြေခံအဆောက်အဦများကို သရုပ်ဖော်ရန် Kubernetes ကိုအသုံးပြုသည်။

ဤဆောင်းပါးတွင်၊ ကျွန်ုပ်တို့သည် Kubernetes ၏ လက်ရှိအခြေအနေ၏ မျက်နှာပြင်ကို ခြစ်လိုက်သည်—တကယ်တော့၊ ၎င်းသည် ရေခဲတောင်၏အစွန်အဖျားမျှသာဖြစ်သည်။ Kubernetes အသုံးပြုသူများတွင် အခြားအရင်းအမြစ်များ၊ စွမ်းဆောင်ရည်များနှင့် စီစဉ်သတ်မှတ်မှုများ အများအပြားရှိသည်။

source: www.habr.com