🥇 10 عام غلطۍ کله چې Kubernetes کاروئ

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

د Kubernetes کارولو په کلونو کې، موږ د ډیری کلسترونو سره کار کړی دی (دواړه اداره شوي او غیر منظم شوي - په GCP، AWS او Azure کې). د وخت په تیریدو سره، موږ پوهیدل پیل کړل چې ځینې غلطۍ په دوامداره توګه تکرار شوي. په هرصورت، پدې کې هیڅ شرم نشته: موږ ډیری یې پخپله کړي دي!

مقاله خورا عام غلطۍ لري او دا هم په ګوته کوي چې څنګه یې سم کړئ.

1. سرچینې: غوښتنې او محدودیتونه

دا توکي یقینا د نږدې پاملرنې مستحق دي او په لیست کې لومړی ځای لري.

د CPU غوښتنه معمولا یا په بشپړ ډول مشخص شوي ندي یا خورا ټیټ ارزښت لري (د امکان تر حده په هر نوډ کې ډیری پوډونه ځای په ځای کول). په دې توګه، نوډونه ډیر بار شوي. د لوړ بار په وخت کې، د نوډ پروسس کولو ځواک په بشپړه توګه کارول کیږي او یو ځانګړي کاري بار یوازې هغه څه ترلاسه کوي چې د هغې لخوا "غوښتنه" کیږي. CPU throttling. دا د غوښتنلیک د ځنډیدو، وخت پای ته رسیدو، او نورو ناخوښ پایلو لامل کیږي. (د دې په اړه نور زموږ په وروستي ژباړه کې ولولئ: "په کبرنیټس کې د CPU محدودیتونه او تیري کوونکی"- نږدې ژباړه.)

غوره هڅه (ډیر نه وړاندیز شوی):

resources: {}

خورا ټیټ CPU غوښتنه (خورا نه وړاندیز شوی):

   resources:
      Requests:
        cpu: "1m"

له بلې خوا، د CPU محدودیت شتون کولی شي د پوډونو لخوا د ساعت دورې غیر معقول پریښودو لامل شي، حتی که د نوډ پروسیسر په بشپړه توګه نه وي پورته شوی. یوځل بیا ، دا کولی شي د ځنډ ډیروالي لامل شي. د پیرامیټر په شاوخوا کې شخړې دوام لري د CPU CFS کوټه په لینکس کرنل او CPU کې د ټاکل شوي حدونو پورې اړه لري، او همدارنګه د CFS کوټې غیر فعال کول ... افسوس، د CPU محدودیت کولی شي د حل کولو په پرتله ډیرې ستونزې رامینځته کړي. په دې اړه نور معلومات په لاندې لینک کې موندلی شئ.

ډیر انتخاب (ډیر ژمنتیا) د حافظې ستونزې کولی شي لویې ستونزې رامینځته کړي. د CPU حد ته رسیدل د ساعت دوره پریږدي، پداسې حال کې چې د حافظې حد ته رسیدل د پوډ وژلو ته اړتیا لري. ایا تاسو کله لیدلی دی OOMkill؟ هو، دا هغه څه دي چې موږ یې په اړه خبرې کوو.

ایا تاسو غواړئ د دې پیښې احتمال کم کړئ؟ د حافظې ډیر تخصیص مه کوئ او د حافظې غوښتنې حد ته په ټاکلو سره تضمین شوي QoS (د خدماتو کیفیت) وکاروئ (لکه څنګه چې لاندې مثال کې). په دې اړه نور ولولئ د هینینګ جیکبس پریزنټشنونه (په ځلانډو کې مخکښ انجینر).

د سوځولو وړ (د OOM د وژل کیدو لوړ چانس):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

تضمین شوی:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

د سرچینو تنظیم کولو په وخت کې به څه مرسته وکړي؟

د مرستې په مرسته metrics-server تاسو کولی شئ د اوسني CPU سرچینې مصرف او د حافظې کارول د پوډونو (او د دوی دننه کانټینرونه) وګورئ. ډیری احتمال، تاسو دمخه دا کاروئ. یوازې لاندې کمانډونه پرمخ وړئ:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

په هرصورت، دوی یوازې اوسنی کارول ښیې. دا کولی شي تاسو ته د اندازې ترتیب په اړه یو څه نظر درکړي، مګر په نهایت کې تاسو اړتیا لرئ د وخت په تیریدو سره په میټریکونو کې د بدلون تاریخ (د پوښتنو ځوابولو لپاره لکه: "د لوړ CPU بار څه و؟"، "پرون سهار بار څه وو؟"، او داسې نور). د دې لپاره تاسو کارولی شئ Prometheus, DataDog او نور وسایل. دوی په ساده ډول د میټریک سرور څخه میټریکونه ترلاسه کوي او ذخیره کوي، او کاروونکي کولی شي دوی پوښتنه وکړي او د هغې مطابق یې پلاټ کړي.

VerticalPodAutoscaler دا اجازه ورکوي اتومات دا پروسه. دا د CPU او حافظې کارولو تاریخ تعقیبوي او د دې معلوماتو پراساس نوي غوښتنې او حدود تنظیموي.

د کمپیوټري ځواک په اغیزمنه توګه کارول اسانه کار نه دی. دا هر وخت د Tetris لوبولو په څیر دی. که تاسو د ټیټ اوسط مصرف سره د کمپیوټري بریښنا لپاره خورا ډیر تادیه کوئ (وایی ~ 10٪) ، موږ وړاندیز کوو چې د AWS Fargate یا Virtual Kubelet پراساس محصولات وګورو. دوی د سرور پرته / تادیه - د کارولو بلینګ ماډل کې رامینځته شوي ، کوم چې ممکن په ورته شرایطو کې ارزانه وي.

2. ژوندیتوب او چمتووالی تحقیقات

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

مګر تاسو څنګه کولی شئ د وژونکي خطا په حالت کې د خدمت بیا پیل پیل کړئ؟ او د بار بیلانس څنګه پوهیږي چې یو پوډ د ټرافیک منلو لپاره چمتو دی؟ یا دا چې دا کولی شي ډیر ترافیک اداره کړي؟

دا ازموینې اکثرا د یو بل سره مغشوش کیږي:

ژوندون - د "ژوندي پاتې کیدو" چک، کوم چې پوډ بیا پیل کوي که ناکام شي؛
چمتووالی - د چمتووالي چک، که دا ناکام شي، دا د کوبرنیټس خدمت څخه پوډ منقطع کوي (دا په کارولو سره چیک کیدی شي kubectl get endpoints) او ټرافیک دې ته نه رسیږي تر هغه چې راتلونکی چک په بریالیتوب سره بشپړ نشي.

دا دواړه چکونه د پوډ د ټول ژوند دورې په جریان کې ترسره شوی. دا ډیره مهمه ده.

یو عام غلط فهم دا دی چې د چمتووالي تحقیقات یوازې په پیل کې پرمخ وړل کیږي ترڅو بیلانسر پوه شي چې پوډ چمتو دی (Ready) او کولی شي د ترافیک پروسس پیل کړي. په هرصورت، دا د دوی د کارولو لپاره یوازې یو انتخاب دی.

بل د موندلو امکان دی چې په پوډ باندې ترافیک ډیر دی او ډیریږي (یا پوډ د منابعو ژورې محاسبې ترسره کوي). په دې حالت کې، د چمتووالي معاینه مرسته کوي په پوډ باندې بار کم کړئ او "یخ" یې کړئ. په راتلونکي کې د چمتووالي چیک بریالي بشپړول اجازه ورکوي بیا په پوډ باندې بار زیات کړئ. په دې حالت کې (که د چمتووالي ازموینه ناکامه شي)، د ژوندانه ازموینې ناکامي به خورا ګټور وي. ولې یو پوډ بیا پیل کړئ چې صحي او سخت کار کوي؟

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

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

3. د هر HTTP خدمت لپاره LoadBlancer

ډیری احتمال، تاسو په خپل کلستر کې HTTP خدمتونه لرئ چې تاسو غواړئ بهرنۍ نړۍ ته لاړ شئ.

که تاسو د خدمت په توګه خلاص کړئ type: LoadBalancer، د دې کنټرولر (د خدماتو چمتو کونکي پورې اړه لري) به یو بهرنی LoadBlancer چمتو او خبرې اترې وکړي (ضروري نه ده چې په L7 کې پرمخ ځي، مګر حتی په L4 کې)، او دا کیدای شي په لګښت اغیزه وکړي (بهرني جامد IPv4 پته، د کمپیوټر ځواک، د فی ثانیې بلینګ. ) د دې ډول سرچینو لوی شمیر رامینځته کولو اړتیا له امله.

پدې حالت کې ، دا خورا منطقي دی چې د یو بهرني بار بیلنسر کارولو لپاره ، د خدماتو خلاصولو په توګه type: NodePort. یا لا تر اوسه ښه، یو څه پراخ کړئ لکه nginx-ingress-controller (يا صراف)، څوک به یوازینی وي نوډپورټ پای ټکی د بهرني بار بیلانسر سره تړاو لري او په کارولو سره به په کلستر کې ټرافيک ودروي ننوتل- Kubernetes سرچینې.

نور داخلي کلستر (مایکرو) خدمتونه چې یو له بل سره اړیکه لري کولی شي د خدماتو په کارولو سره "خبرې اترې" وکړي ClusterIP او د DNS له لارې د خدماتو کشف میکانیزم جوړ شوی. یوازې د دوی عامه DNS/IP مه کاروئ ، ځکه چې دا کولی شي ځنډ اغیزه وکړي او د کلاوډ خدماتو لګښت ډیر کړي.

4. د کلستر د ځانګړتیاوو په پام کې نیولو پرته په اتوماتيک ډول اندازه کول

کله چې نوډونه اضافه کول او له کلستر څخه یې لرې کول، تاسو باید په ځینو اساسي میټریکونو باندې تکیه ونکړئ لکه په دې نوډونو کې د CPU کارول. د پوډ پلان جوړونه باید ډیری په پام کې ونیسي محدودیتونهلکه د پوډ/نوډ تړاو، داغونه او زغم، د سرچینو غوښتنې، QoS، او داسې نور. د بهرني آټوسکلر کارول چې دا لنډیزونه په پام کې نه نیسي کولی شي ستونزې رامینځته کړي.

تصور وکړئ چې یو ټاکلی پوډ باید مهالویش وي، مګر ټول موجود CPU بریښنا غوښتنه شوې / جلا شوې او پوډ په یوه حالت کې بندیږي Pending. بهرنی آټوسکلر د اوسط اوسني CPU بار ګوري (نه غوښتل شوی) او توسع پیل نه کوي (پیمانه کول) - بل نوډ نه اضافه کوي. د پایلې په توګه، دا پوډ به مهالویش نه وي.

په دې حالت کې، بیرته اندازه کول (پیمانه) - له کلستر څخه د نوډ لرې کول تل پلي کول خورا ستونزمن وي. تصور وکړئ چې تاسو یو دولتي پوډ لرئ (د دوامداره ذخیره کولو سره وصل شوی). دوامداره حجمونه معمولا پورې اړه لري د ځانګړي شتون زون او په سیمه کې نه تکراریږي. په دې توګه، که یو بهرنی آټوسکلر د دې پوډ سره یو نوډ حذف کړي، شیډولر به ونه شي کولی دا پوډ په بل نوډ کې مهالویش کړي، ځکه چې دا یوازې د شتون په زون کې ترسره کیدی شي چیرې چې دوامداره ذخیره موقعیت لري. پوډ به په حالت کې ودرول شي Pending.

د Kubernetes ټولنه کې خورا مشهور کلستر-آټوسکلر. دا په کلستر کې پرمخ ځي، د لوی کلاوډ چمتو کونکو څخه APIs ملاتړ کوي، ټول محدودیتونه په پام کې نیسي او په پورته قضیو کې اندازه کولی شي. دا د ټولو ټاکل شوي محدودیتونو ساتلو په وخت کې د اندازه کولو وړتیا هم لري، پدې توګه پیسې خوندي کوي (کوم چې په غیر استعمال شوي ظرفیت کې مصرف کیږي).

5. د IAM/RBAC وړتیاوو غفلت کول

د دوامدار رازونو سره د IAM کاروونکو کارولو څخه خبر اوسئ ماشینونه او غوښتنلیکونه. د رولونو او خدماتو حسابونو په کارولو سره لنډمهاله لاسرسي تنظیم کړئ (خدمت حسابونه).

موږ ډیری وختونه د دې حقیقت سره مخ کیږو چې د لاسرسي کیلي (او رازونه) د غوښتنلیک ترتیب کې هارډ کوډ شوي ، او همدارنګه د کلاوډ IAM ته د لاسرسي سره سره د رازونو گردش غفلت کوي. د کاروونکو پرځای د IAM رول او خدماتو حسابونه وکاروئ چیرې چې مناسب وي.

د kube2iam په اړه هیر کړئ او د خدماتو حسابونو لپاره مستقیم د IAM رولونو ته لاړ شئ (لکه څنګه چې تشریح شوي د ورته نوم یادښت Štěpán Vraný):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

یو تبصره. دومره سخت نه، سمه ده؟

همدارنګه، د خدماتو حسابونه او د مثال پروفایل امتیازات مه ورکوئ admin и cluster-adminکه دوی ورته اړتیا نلري. دا پلي کول یو څه ډیر ستونزمن دي ، په ځانګړي توګه په RBAC K8s کې ، مګر یقینا د هڅو ارزښت لري.

6. د پوډونو لپاره په اتوماتیک ضد تړاو باندې تکیه مه کوئ

تصور وکړئ چې تاسو په نوډ کې د ځینې ګمارنې درې نقلونه لرئ. نوډ راټیټیږي، او د هغې سره ټول نقلونه. ناخوښ حالت، سمه ده؟ مګر ولې ټول نقلونه په ورته نوډ کې وو؟ ایا Kubernetes باید لوړ شتون (HA) چمتو نکړي؟!

له بده مرغه، د Kubernetes مهالویشونکی، په خپل نوښت، د جلا وجود د قواعدو سره سمون نه خوري (د تړاو ضد) د پوزې لپاره. دوی باید په واضح ډول وویل شي:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

بس نور څه نه. اوس پوډونه به په مختلف نوډونو کې تنظیم شي (دا حالت یوازې د مهالویش پرمهال چیک کیږي ، مګر د دوی د عملیاتو پرمهال نه - له همدې امله requiredDuringSchedulingIgnoredDuringExecution).

دلته موږ په اړه خبرې کوو podAntiAffinity په مختلفو نوډونو کې: topologyKey: "kubernetes.io/hostname"، - او نه د مختلف شتون زونونو په اړه. د بشپړ شوي HA پلي کولو لپاره، تاسو باید دې موضوع ته ژوره وخورئ.

7. د PodDisruption Budgets له پامه غورځول

تصور وکړئ چې تاسو د کبرنیټس کلستر کې د تولید بار لرئ. په دوره توګه، نوډونه او کلستر پخپله باید تازه شي (یا له منځه یوړل شي). PodDisruptionBudget (PDB) د کلستر مدیرانو او کاروونکو ترمنځ د خدماتو تضمین تړون په څیر یو څه دی.

PDB تاسو ته اجازه درکوي د نوډونو نشتوالي له امله د خدماتو خنډونو څخه مخنیوی وکړئ:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

په دې مثال کې، تاسو، د کلستر د کاروونکي په توګه، مدیرانو ته ووایاست: "ای، زه د زوکیپر خدمت لرم، او مهمه نده چې تاسو څه کوئ، زه غواړم د دې خدمت لږترلږه 2 نقلونه هر وخت موجود وي. "

تاسو کولی شئ پدې اړه نور ولولئ دلته.

8. په یو عام کلستر کې ډیری کاروونکي یا چاپیریال

د Kubernetes نوم ځایونه (نوم ځایونه) قوي موصلیت مه ورکوئ.

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

هغه څوک چې اړتیا لري په ورته کلستر کې دواړه ډوله کاري بارونه یوځای کړي باید د پیچلتیا سره مخ شي. که چیرې داسې اړتیا نشته، او تاسو کولی شئ یو یې ولرئ یو بل کلستر (ووایه، په عامه بادل کې)، نو دا غوره ده چې دا کار وکړئ. دا به د موصلیت خورا لوړه کچه ترلاسه کړي.

9. بهرنۍ ترافیک پالیسي: کلستر

ډیری وختونه موږ ګورو چې د کلستر دننه ټول ترافیک د نوډ پورټ په څیر د خدماتو له لارې راځي ، د کوم لپاره چې ډیفالټ پالیسي ټاکل شوې وي. externalTrafficPolicy: Cluster... دا پدې مانا ده نوډپورټ په کلستر کې په هر نوډ کې خلاص دی، او تاسو کولی شئ د دوی هر یو د مطلوب خدمت (د پوډونو سیټ) سره د تعامل لپاره وکاروئ.

په ورته وخت کې ، د پورتنۍ ذکر شوي نوډ پورټ خدمت پورې اړوند ریښتیني پوډونه معمولا یوازې په یو ځانګړي کې شتون لري د دې نوډونو فرعي سیټ. په بل عبارت، که زه یو نوډ سره وصل کړم چې اړین پوډ نلري، دا به ټرافيک بل نوډ ته ولیږدوي، یو هپ اضافه کول او د ځنډ زیاتوالی (که نوډونه د مختلف شتون زونونو / ډیټا مرکزونو کې موقعیت ولري ، نو ځنډ خورا لوړ کیدی شي؛ سربیره پردې ، د وتلو ترافیک لګښتونه به ډیر شي).

له بلې خوا، که چیرې یو ځانګړی Kubernetes خدمت پالیسي جوړه کړي externalTrafficPolicy: Local، بیا نوډ پورټ یوازې په هغه نوډونو کې خلاصیږي چیرې چې اړین پوډونه واقعیا روان دي. کله چې د بهرني بار بیلنس کاروئ چې حالت چیک کوي (روغتیا معاینه کول) پای ټکي (دا څنګه کوي AWS ELB)، هغه ټرافیک به یوازې اړین نوډونو ته واستوي، کوم چې به په ځنډونو ، کمپیوټري اړتیاو ، د وتلو بیلونو باندې ګټور اغیزه ولري (او عام احساس ورته حکم کوي).

ډیر چانس شتون لري چې تاسو دمخه یو څه کاروئ صراف او یا nginx-ingress-controller د نوډ پورټ پای پاینټ په توګه (یا د LoadBlancer، چې د نوډ پورټ هم کاروي) د HTTP ننوتلو ترافیک ته لاره هواروي ، او د دې اختیار تنظیم کول کولی شي د دې ډول غوښتنو لپاره ځنډ د پام وړ کم کړي.

В دا خپرونه تاسو کولی شئ د بهرنۍ ترافیک پالیسي، د هغې ګټې او زیانونو په اړه نور معلومات زده کړئ.

10. په کلسترونو کې مه وتړئ او د کنټرول الوتکې څخه ناوړه ګټه مه اخلئ

پخوا، دا دود و چې سرورونه په مناسبو نومونو غږ کړئ: انتون, HAL9000 او Colossus... نن ورځ دوی د تصادفي تولید شوي پیژندونکو لخوا بدل شوي. په هرصورت، عادت پاتې شو، او اوس سم نومونه کلستر ته ځي.

یوه عادي کیسه (د حقیقي پیښو پر بنسټ): دا ټول د مفهوم ثبوت سره پیل شوي، نو کلستر یو ویاړلي نوم درلود ازمايښت... کلونه تیر شوي او دا لاهم په تولید کې کارول کیږي، او هرڅوک ویره لري چې لمس کړي.

د کلسترونو په څارویو بدلیدو کې هیڅ ساتیري شتون نلري ، نو موږ وړاندیز کوو چې د تمرین کولو پرمهال یې په دوره توګه لرې کړئ د ناورین بیا رغونه (دا به مرسته وکړي ګډوډي انجینري - نږدې ژباړه.). سربیره پردې ، دا به د کنټرول پرت کې کار کولو ته زیان ونه رسوي (د کنټرول الوتکه). د هغه د لمس کولو څخه ویره ښه نښه نده. etc مړ؟ هلکانو، تاسو واقعیا په ستونزه کې یاست!

له بلې خوا، تاسو باید د دې په مینځلو سره لیرې نه شئ. د وخت سره د کنټرول پرت ممکن ورو شي. ډیری احتمال، دا د لوی شمیر شیانو له امله وي چې د دوی د گردش پرته رامینځته کیږي (د ډیفالټ ترتیباتو سره د هیلم کارولو په وخت کې یو عام حالت، له همدې امله د دې حالت په configmaps/رازونو کې نه تازه کیږي - د پایلې په توګه، په زرګونو شیان راټولیږي. د کنټرول پرت) یا د kube-api شیانو دوامداره ترمیم سره (د اتوماتیک اندازه کولو لپاره، د CI/CD لپاره، د څارنې لپاره، د پیښو لاګ، کنټرولر، او نور).

برسېره پردې، موږ وړاندیز کوو چې د مدیریت شوي Kubernetes چمتو کونکي سره د SLA/SLO تړونونه وڅیړئ او تضمینونو ته پاملرنه وکړئ. پلورونکی کولی شي تضمین کړي د کنټرول پرت شتون (یا د هغې فرعي برخې)، مګر د هغو غوښتنو p99 ځنډ ندی چې تاسو ورته لیږئ. په بل عبارت، تاسو کولی شئ داخل شئ kubectl get nodes، او یوازې د 10 دقیقو وروسته ځواب ترلاسه کړئ ، او دا به د خدماتو تړون شرایطو څخه سرغړونه نه وي.

11. بونس: د وروستي ټګ کارول

مګر دا لا دمخه یو کلاسیک دی. په دې وروستیو کې موږ د دې تخنیک سره لږ وخت لیدلی یو، ځکه چې ډیری، د ترخې تجربې څخه زده کړې، د ټاګ کارول بند کړي. :latest او د نسخو پین کول یې پیل کړل. هورې!

ECR د عکس ټاګونو بې ثباتي ساتي; موږ وړاندیز کوو چې تاسو د دې د پام وړ ځانګړتیا سره ځان وپیژنئ.

لنډیز

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

تاسو کولی شئ د مختلفو ټیمونو له ناکامو تجربو سره آشنا شئ د کیسو دا ټولګه د هینینګ جیکبز لخوا.

هغه څوک چې غواړي پدې مقاله کې ورکړل شوي غلطیو لیست کې اضافه کړي کولی شي موږ سره په ټویټر کې اړیکه ونیسي (@MarekBartik, @MstrsObserver).

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

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

«د Kubernetes کلسترونو ډیزاین کول: څو باید وي؟»
«په Kubernetes کې د امنیت ABC: تصدیق، واک ورکول، پلټنه»
«په کبرنیټس کې د اتوماتیک کولو او سرچینو مدیریت"( بیاکتنه او ویډیو راپور)
«په Kubernetes کې ConfigMaps: په اړه د پوهیدو وړ باریکي".

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

10 عام غلطۍ کله چې د کوبرنیټس کارول