د Kubernetes مخ پر ودې شهرت په اړه

اې حبره!

د دوبي په پای کې، موږ غواړو تاسو ته یادونه وکړو چې موږ په موضوع کار ته دوام ورکوو کوبنیټس او پریکړه یې وکړه چې د Stackoverflow څخه یوه مقاله خپره کړي چې د جون په پیل کې پدې پروژه کې د چارو حالت څرګندوي.

مطالعه وکړئ!

د دې مقالې لیکلو په وخت کې، د کبرنیټس عمر نږدې دی. شپږ کلن، او په تیرو دوو کلونو کې د دې شهرت دومره وده کړې چې دا په دوامداره توګه په مینځ کې درجه بندي کیږي ترټولو غوره پلیټ فارمونه Kubernetes سږکال دریم ځای لري. د بیاکتنې لپاره: کوبرنیټس یو پلیټ فارم دی چې د کانټینر شوي کاري بارونو چلولو او تنظیم کولو لپاره ډیزاین شوی.

کانټینرونه په لینکس کې د جلا کولو پروسو لپاره د ځانګړي ډیزاین په توګه پیل شوي؛ کانټینرونه د 2007 راهیسې شامل دي ګروپونه، او د 2002 راهیسې - نوم ځایونه. کانټینرونه په 2008 کې لا ښه ډیزاین شوي، کله چې دا شتون لري LXC، او ګوګل خپل داخلي کارپوریټ میکانیزم رامینځته کړ چې په نوم یادیږي بورګ، چیرې چې "ټول کار په کانتینرونو کې ترسره کیږي." له دې ځایه موږ 2013 ته ګړندی وړاندې کوو ، کله چې د ډاکر لومړی خوشې کول ترسره شو ، او کانټینرونه په پای کې یو مشهور ډله ایز حل شو. په هغه وخت کې، د کانټینر آرکیسټریشن اصلي وسیله وه Mesosکه څه هم هغه په ​​پراخه کچه مشهور نه و. Kubernetes لومړی ځل په 2015 کې خپور شو، وروسته له هغه چې دا وسیله د کانټینر آرکیسټریشن په ډګر کې د حقیقت معیار شو.

د دې لپاره چې پوه شي چې ولې Kubernetes دومره مشهور دی، راځئ چې یو څو پوښتنو ته ځواب ووایو. وروستی ځل کله و چې پراختیا کونکي وکولی شول په دې موافقه وکړي چې څنګه تولید ته غوښتنلیکونه ځای په ځای کړي؟ تاسو څومره پراختیا کونکي پوهیږئ څوک چې وسیلې کاروي لکه څنګه چې دوی د بکس څخه بهر چمتو شوي؟ نن ورځ څومره بادل مدیران شتون لري چې نه پوهیږي چې غوښتنلیکونه څنګه کار کوي؟ موږ به پدې مقاله کې د دې پوښتنو ځوابونه وګورو.

د YAML په توګه زیربنا

په نړۍ کې چې له ګوډاګي او شیف څخه کوبرنیټس ته لاړ ، یو له لوی بدلونونو څخه د "کوډ په توګه زیربنا" څخه "د معلوماتو په توګه زیربنا" ته حرکت کول و - په ځانګړي توګه د YAML په څیر. په کوبرنیټس کې ټولې سرچینې ، چې پکې پوډونه ، تشکیلات ، ځای پرځای شوي مثالونه ، حجمونه او نور شامل دي ، په اسانۍ سره د 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 عملیاتو نسخه کنټرول. دا طریقه تاسو ته اجازه درکوي د کوبرنیټس YAML ټولې فایلونه په git ذخیره کې وساتئ ، نو تاسو کولی شئ دقیقا تعقیب کړئ کله چې بدلون رامینځته شوی ، چا یې رامینځته کړی ، او واقعیا څه بدل شوي. دا په ټوله اداره کې د عملیاتو روڼتیا زیاتوي او د ابهام له منځه وړلو سره عملیاتي موثریت ته وده ورکوي، په ځانګړې توګه چیرې چې کارمندان باید هغه سرچینې وګوري چې دوی ورته اړتیا لري. په ورته وخت کې ، دا اسانه کیږي چې په اوتومات ډول د کوبرنیټس سرچینو کې بدلونونه په ساده ډول د پلې غوښتنې سره یوځای کولو سره رامینځته کړئ.
• د توزیع وړتیا. کله چې سرچینې د 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 د ارزونې لپاره عالي دی چې څنګه شیان په کوبرنیټس کې ځای په ځای شوي. د مثال په توګه، یو لوی امنیتي اندیښنه اندیښنه لري چې آیا ستاسو د کار بارونه د غیر اداري کارونکي په توګه پرمخ ځي. په دې حالت کې، موږ ممکن وسایلو ته اړتیا ولرو لکه سیالۍ، YAML/JSON تایید کونکی، پلس د پالیسۍ ایجنټ خلاص کړئ، د پالیسۍ تصدیق کونکی ترڅو ډاډ ترلاسه کړي چې شرایط د امنیت متن ستاسو د کار بارونه کانټینر ته اجازه نه ورکوي چې د مدیر امتیازاتو سره پرمخ بوځي. که دا اړتیا وي، کاروونکي کولی شي ساده پالیسي پلي کړي زه لمونځ کوم، لکه دغه:

package main

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

• د بادل چمتو کونکي سره د ادغام لپاره اختیارونه. د نن ورځې لوړې ټیکنالوژۍ کې یو له خورا پام وړ رجحاناتو څخه د عامه کلاوډ چمتو کونکو باندې د کار بار چلول دي. د برخې کارول بادل برابرونکی Kubernetes هر کلستر ته اجازه ورکوي چې د کلاوډ چمتو کونکي سره مدغم شي په کوم کې چې دا پرمخ ځي. د مثال په توګه، که چیرې یو کاروونکي په AWS کې په کوبرنیټس کې یو اپلیکیشن پرمخ وړي او غواړي چې دا غوښتنلیک د خدمت له لارې افشا کړي، د کلاوډ چمتو کونکی په اوتومات ډول د خدمت رامینځته کولو کې مرسته کوي LoadBalancerکوم چې به په اتوماتيک ډول د بار توازن چمتو کړي د ایمیزون لچکدار بار بیلنسرد غوښتنلیک پوډونو ته ټرافیک لیږلو لپاره.

پراخوالی

Kubernetes خورا پراخ دی او پراختیا کونکي یې خوښوي. د شته منابعو یوه ټولګه شتون لري لکه پوډونه، ځای پرځای کول، StatefulSetsرازونه ConfigMaps, etc. ریښتیا، کاروونکي او پراختیا کونکي کولی شي په فورمه کې نورې سرچینې اضافه کړي د دودیز سرچینې تعریفونه.

د مثال په توګه، که موږ غواړو یوه سرچینه تعریف کړو 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 کلستر کې یوه ځانګړې پروسه ده چې د "د کنټرول سرکټ" د یو آپریټر په مرسته، کاروونکي کولی شي د کوبرنیټس API سره د معلوماتو تبادله کولو سره د CRDs (د ګمرک سرچینو تعریفونه) مدیریت اتومات کړي.

په ټولنه کې ډیری وسیلې شتون لري چې د پراختیا کونکو لپاره دا اسانه کوي چې خپل آپریټرونه رامینځته کړي. د هغو په منځ کې - د چلونکي چوکاټ او د هغه آپریټر SDK. دا SDK یو بنسټ چمتو کوي چې له هغې څخه یو پراختیا کونکی کولی شي په چټکۍ سره د آپریټر رامینځته کول پیل کړي. راځئ چې ووایو تاسو کولی شئ د کمانډ لاین څخه داسې څه پیل کړئ:

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

دا ستاسو د آپریټر لپاره ټول بویلر پلیټ کوډ رامینځته کوي ، پشمول د YAML فایلونو او ګولنګ کوډ:

.
|____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

که پراختیا کونکی حتی ډیر کنټرول غواړي ، د Go فایلونو کې د بویلر پلیټ کوډ بدل کیدی شي. د مثال په توګه، د کنټرولر ځانګړتیاو بدلولو لپاره، تاسو کولی شئ په فایل کې بدلونونه رامنځته کړئ controller.go.

بله پروژه کوډو، تاسو ته اجازه درکوي یوازې د اعلاناتي YAML فایلونو په کارولو سره بیانونه رامینځته کړئ. د مثال په توګه، د اپاچي کافکا لپاره یو آپریټر به تقریبا تعریف شي نو. د دې سره، تاسو کولی شئ د کافکا کلستر د یو څو امرونو سره د کبرنیټس په سر کې نصب کړئ:

$ 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 د شهرت بل لوی اړخ د دې ټولنې ځواک دی. په 2015 کې، د 1.0 نسخې ته رسیدو سره، Kubernetes لخوا سپانسر شوی و د بادل اصلي کمپیوټري بنسټ.

بیلابیلې ټولنې هم شتون لري SIG (د ځانګړو ګټو ګروپونه) د کوبرنیټس په مختلفو برخو کې په کار کولو تمرکز کوي لکه څنګه چې پروژه وده کوي. دا ګروپونه په دوامداره توګه نوي ب featuresې اضافه کوي ، د کوبرنیټس سره کار کول خورا اسانه او اسانه کوي.

د کلاوډ اصلي بنسټ هم د CloudNativeCon/KubeCon کوربه توب کوي، کوم چې د لیکلو په وخت کې، په نړۍ کې ترټولو لوی پرانیستې سرچینې کنفرانس دی. عموما په کال کې درې ځله ترسره کیږي، دا په زرګونو مسلکي کسان راټولوي چې غواړي د کوبرنیټس او د هغې ایکوسیستم ته وده ورکړي، او همدارنګه نوي ځانګړتیاوې زده کړي چې په هرو دریو میاشتو کې څرګندیږي.

سربیره پردې، د کلاوډ اصلي بنسټ لري د تخنیکي څارنې کمیټه، کوم چې د SIGs سره یوځای نوي او موجوده بیاکتنه کوي پروژې فنډونه د بادل ایکوسیستم باندې تمرکز کوي. ډیری دا پروژې د کبرنیټس پیاوړتیا کې مرسته کوي.

په نهایت کې ، زه باور لرم چې کبرنیټس به دومره بریالي نه وي لکه څنګه چې د ټولې ټولنې له شعوري هڅو پرته وي ، چیرې چې خلک یوځای پاتې کیږي مګر په ورته وخت کې نوي راغلو ته ښه راغلاست ویل کیږي.

راتلونکی

یو له اصلي ننګونو څخه چې پراختیا کونکي به یې په راتلونکي کې ورسره معامله وکړي د دې وړتیا ده چې پخپله د کوډ توضیحاتو تمرکز وکړي ، نه په زیربنا باندې چې دا پرمخ ځي. دا د دې رجحاناتو سره سمون لري بې سروره معماري تمثیل، کوم چې نن ورځ یو له مخکښو څخه دی. پرمختللي چوکاټونه لا دمخه شتون لري، د بیلګې په توګه ژړا и OpenFaas، کوم چې د پراختیا کونکي څخه زیربنا خلاصولو لپاره Kubernetes کاروي.

په دې مقاله کې، موږ یوازې د کوبرنیټس اوسني حالت سطحه کښلې ده - په حقیقت کې، دا یوازې د یخ برګ یوه برخه ده. د Kubernetes کاروونکي د دوی په اختیار کې ډیری نورې سرچینې، وړتیاوې او تشکیلات لري.

سرچینه: www.habr.com