په کوبرنیټس کې د ګمارنې ستراتیژۍ: رولینګ ، تفریح ​​​​، نیلي / شنه ، کانري ، تیاره (A/B ازموینه)

نوټ ژباړه: د Weaveworks څخه دا کتنه د اپلیکیشن خورا مشهور رول آوټ ستراتیژۍ معرفي کوي او ښیې چې څنګه خورا پرمختللي د کوبرنیټس فلیګر آپریټر په کارولو سره پلي کیدی شي. دا په ساده ژبه لیکل شوی او بصری ډیاګرامونه لري چې حتی نوي انجینرانو ته اجازه ورکوي چې مسله درک کړي.

انځور له دې څخه اخیستل شوی دی بله بیاکتنه د کانټینر حلونو کې رامینځته شوي رول آوټ ستراتیژیانې

نن ورځ د کلاوډ اصلي غوښتنلیکونو رامینځته کولو کې ترټولو لوی ننګونه د پلي کولو ګړندي کول دي. د مایکرو خدماتو چلند کې ، پراختیا کونکي دمخه په بشپړ ډول ماډلر غوښتنلیکونو سره کار کوي او ډیزاین کوي ​​، مختلف ټیمونو ته اجازه ورکوي چې په ورته وخت کې کوډ ولیکي او غوښتنلیک کې بدلونونه رامینځته کړي.

لنډ او ډیر پرله پسې ګمارنې لاندې ګټې لري:

• بازار ته وخت کم دی.
• نوې بڼې په چټکۍ سره کاروونکو ته رسیږي.
• د کارونکي فیډبیک ګړندی پرمختیایی ټیم ته رسي. دا پدې مانا ده چې ټیم کولی شي ځانګړتیاوې اضافه کړي او مسلې په چټکۍ سره حل کړي.
• د پراختیا کونکي مورال ډیریږي: په پراختیا کې ډیرې ځانګړتیاوې د کار کولو لپاره ډیر ساتیري دي.

مګر لکه څنګه چې د خپریدو فریکوینسي ډیریږي ، د غوښتنلیک اعتبار یا د کارونکي تجربې منفي اغیزه کولو امکانات هم ډیریږي. له همدې امله دا د عملیاتو او DevOps ټیمونو لپاره مهم دي چې پروسې رامینځته کړي او د ګمارنې ستراتیژۍ په داسې طریقه اداره کړي چې محصول او کاروونکو ته خطر کم کړي. (تاسو کولی شئ د CI/CD پایپ لاین اتومات کولو په اړه نور معلومات زده کړئ دلته.)

پدې پوسټ کې ، موږ به په کوبرنیټس کې د ګمارنې مختلف ستراتیژیو په اړه بحث وکړو ، پشمول د رولینګ پلي کول او نور پرمختللي میتودونه لکه د کانري رول آوټ او د دوی تغیرات.

د ځای پرځای کولو ستراتیژی

د ګومارلو ستراتیژیو ډیری بیلابیل ډولونه شتون لري چې تاسو یې د خپلې موخې پراساس کارولی شئ. د مثال په توګه، تاسو اړتیا لرئ چې د نورو ازموینو لپاره په یو ځانګړي چاپیریال کې، یا د کاروونکو/پیرودونکو فرعي سیټ ته بدلون ورکړئ، یا تاسو اړتیا لرئ چې د فیچر جوړولو دمخه د محدود کاروونکي ازموینې ترسره کړئ عامه.

رولینګ (په تدریجي ډول، "رولینګ" ځای پرځای کول)

دا په Kubernetes کې د معیاري ګمارنې ستراتیژي ده. دا په تدریجي ډول، یو له بل سره، پوډونه د غوښتنلیک زاړه نسخه سره د پوډونو سره د نوي نسخې سره بدلوي - پرته د کلستر بند وخت.

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

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

د رول اوور تازه پیرامیټرې په مینیفیسټ فایل کې مشخص کیدی شي:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

بیا جوړ کړئ

د ګومارنې په دې ساده ډول کې، زاړه پوډونه ټول په یو وخت کې وژل کیږي او د نوي سره بدلیږي:

اړونده منشور یو څه داسې ښکاري:

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

نیلي/شین (نیلي شنه ځای پرځای کول)

د نیلي - شنه پلي کولو ستراتیژي (کله ناکله سور / تور هم ویل کیږي) د غوښتنلیک د زاړه (شنه) او نوي (نیلي) نسخو سره یوځای ځای پرځای کول شامل دي. د دواړو نسخو پوسټ کولو وروسته، منظم کاروونکي شنه ته لاسرسی لري، پداسې حال کې چې نیلي د QA ټیم لپاره شتون لري ترڅو د جلا خدمت یا مستقیم پورټ فارورډینګ له لارې ازموینې اتومات کړي:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

وروسته له دې چې نیلي (نوي) نسخه ازموینه شوې او د هغې خوشې کول تصویب شوي ، خدمت دې ته بدلیږي ، او شنه (زاړه) نسخه پوښل کیږي:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

کانري (کانري ځای پرځای کول)

د کانري رول آوټونه د نیلي شنه رول آؤټونو سره ورته دي، مګر ښه کنټرول او کارول لري پرمختللی ګام په ګام چلند. پدې ډول کې ډیری بیلابیل ستراتیژیانې شاملې دي، پشمول د "غلط" لانچونو او A/B ازموینې.

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

که څه هم دا ستراتیژي په ځانګړي ډول د Kubernetes په کارولو سره پلي کیدی شي، زاړه پوډونه د نوي سره ځای په ځای کړي، دا د Istio په څیر د خدماتو میش کارول خورا اسانه او ساده دي.

د مثال په توګه ، تاسو ممکن په Git کې دوه مختلف څرګندونه ولرئ: د 0.1.0 ټاګ سره منظم منشور او د 0.2.0 ټاګ سره کینري مینیفیسټ. د اسټیو مجازی دروازې منشور کې د وزنونو بدلولو سره ، تاسو کولی شئ د دې دوه ګمارنې ترمینځ د ترافیک توزیع کنټرول کړئ:

د اسټیو په کارولو سره د کانري پلي کولو پلي کولو لپاره د ګام په ګام لارښود لپاره وګورئ د اسټیو سره د GitOps کاري جریان. (نوټ. ژباړه: موږ په اسټیو کې د کانري رول آوټ په اړه مواد هم ژباړلي دلته.)

د Weaveworks فلیګر سره د کانري ځای پرځای کول

Weaveworks پرچمګر تاسو ته اجازه درکوي په اسانۍ او مؤثره توګه د کانري رول آوټ اداره کړئ.

فلیګر اتومات د دوی سره کار کوي. دا د ټرافیک روټ او بدلولو لپاره اسټیو یا AWS ایپ میش کاروي ، او د پایلو تحلیل لپاره پرومیتیس میټریکونه. سربیره پردې ، د کانري ګمارنې تحلیل د منلو ازموینې ، بار ازموینې ، او نورو ډولونو چکونو ترسره کولو لپاره د ویب هکسونو سره ضمیمه کیدی شي.

د کوبرنیټس ګمارنې پراساس او ، که اړتیا وي ، د پوډ افقی اندازه کول (HPA) ، فلیګر د کانري پلي کولو تحلیل او پلي کولو لپاره د شیانو سیټونه (د کوبرنیټس ګمارنې ، د کلسټر آی پی خدمات او اسټیو یا اپ میش مجازی خدمات) رامینځته کوي:

د کنټرول لوپ پلي کول (کنټرول لوپ)فلیګر په تدریجي ډول د کانري سرور ته ترافیک بدلوي ، پداسې حال کې چې په ورته وخت کې د کلیدي فعالیت میټریک اندازه کول لکه د بریالي HTTP غوښتنو سلنه ، د اوسط غوښتنې موده ، او د پوډ روغتیا. د KPI (د کلیدي فعالیت شاخصونو) تحلیل پراساس، کانری یا وده کوي یا سقوط کوي او د تحلیل پایلې په سلیک کې خپریږي. د دې پروسې توضیحات او څرګندونه په موادو کې موندل کیدی شي د اپلیکیشن میش لپاره پرمختللی تحویل.

تیاره (پټ) یا د A/B ځای پرځای کول

د سټیلټ ګمارل د کانري ستراتیژۍ یو بل توپیر دی (کوم چې په لاره کې، فلیګر هم ورسره کار کولی شي). د سټیلت او کانري ګمارنې ترمینځ توپیر دا دی چې د سټیلت ګمارنې د کانري پلي کولو په څیر د شاتنۍ برخې په پرتله د فرنټ اینډ سره معامله کوي.

د دې ګومارنې لپاره بل نوم د A/B ازموینه ده. د دې پر ځای چې نوی فیچر ټولو کاروونکو ته وړاندې کړي، دا یوازې د دوی محدودې برخې ته وړاندې کیږي. عموما، دا کاروونکي نه پوهیږي چې دوی مخکښ ټیسټران دي (له همدې امله د "غلط ګمارنې" اصطلاح).

د فعالیت سویچونو کارول (د فیچر بدلول) او نورې وسیلې، تاسو کولی شئ څارنه وکړئ چې کاروونکي څنګه د نوي فیچر سره تعامل کوي، ایا دوی پدې کې ښکیل دي، یا ایا دوی د نوي کاروونکي انٹرفیس ګډوډ موندلی، او نور ډولونه میټریکونه.

فلیګر او A/B ځای پرځای کول

د وزن پراساس روټینګ سربیره ، فلیګر کولی شي د HTTP پیرامیټونو پراساس کانري سرور ته ترافیک هم وغځوي. د A/B ازموینې کې، تاسو کولی شئ د HTTP سرلیکونه یا کوکیز وکاروئ ترڅو د کاروونکو ځانګړې برخې په نښه کړئ. دا په ځانګړي توګه د فرنټ اینډ غوښتنلیکونو په قضیه کې مؤثره دی چې سرور ته د ناستې پابندۍ ته اړتیا لري (د غونډې تړاو). نور معلومات د فلیګر اسنادو کې موندل کیدی شي.

لیکوال مننه کوي سټیفن پروډان، Weaveworks انجینر (او د فلیګر جوړونکی) ، د دې ټولو حیرانتیا ګمارلو نمونو لپاره.

PS د ژباړونکي څخه

زموږ په بلاګ کې هم ولولئ:

• «د کوبرنیټس لپاره د انګریس کنټرولرونو عمومي کتنه او پرتله کول»
• «werf - په Kubernetes کې د CI / CD لپاره زموږ وسیله (کتنې او ویډیو راپور)»
• «د ورته ډول مایکرو خدمتونه د werf او GitLab CI سره جوړ او ځای په ځای کړئ»
• «GitOps څه شی دی؟".

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