د کبرنیټس ستونزې حل کولو لپاره بصری لارښود

نوټ. ژباړه: دا مقاله د پروژې د موادو برخه ده چې په عامه ډومین کې خپاره شوي زده کړهد کوبرنیټس سره د کار کولو لپاره د شرکتونو او انفرادي مدیرانو روزنه. پدې کې، د پروژې مدیر، ډینیل پولینسک، د K8s کلستر کې د چلولو غوښتنلیکونو سره د عمومي ستونزو په صورت کې د کوم ګامونو اخیستلو په اړه بصری لارښوونې شریکوي.

TL؛ DR: دلته یو ډیاګرام دی چې تاسو سره به په کبرنیټس کې د ځای په ځای کولو کې مرسته وکړي:

په کلستر کې د غلطیو موندلو او حل کولو لپاره فلو چارټ. اصلي (په انګلیسي کې) دلته شتون لري د PDF и د انځور په توګه.

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

• تعین کول - دا د اپلیکیشن کاپي جوړولو لپاره یو ډول ترکیب دی چې د پوډ په نوم یادیږي؛
• خدمت - د داخلي بار بیلانسر چې د پوډونو ترمینځ ترافیک توزیع کوي؛
• برید - د دې تشریح چې څنګه ټرافیک به له بهرنۍ نړۍ څخه خدمت ته ورسیږي.

دلته یو چټک ګرافیکي لنډیز دی:

1) په Kubernetes کې، غوښتنلیکونه د بهرنۍ نړۍ څخه ټرافيک د دوه پرتونو بار بار بیلنسونو له لارې ترلاسه کوي: داخلي او بهرنۍ.

2) داخلي توازن د خدمت په نوم یادیږي، خارجي ته انګریس ویل کیږي.

3) ځای پرځای کول پوډونه رامینځته کوي او څارنه یې کوي (دوی په لاسي ډول ندي رامینځته شوي).

راځئ چې ووایو تاسو غواړئ یو ساده غوښتنلیک ځای په ځای کړئ سلام نړی. د دې لپاره د YAML ترتیب به داسې ښکاري:

apiVersion: apps/v1
kind: Deployment # <<<
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service # <<<
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress # <<<
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

تعریف خورا اوږد دی او د دې په اړه مغشوش کیدل اسانه دي چې اجزا له یو بل سره څنګه تړاو لري.

د مثال په توګه:

• کله باید پورټ 80 وکاروئ او کله باید 8080 وکاروئ؟
• ایا زه باید د هر خدمت لپاره نوی بندر جوړ کړم ترڅو دوی شخړه ونه کړي؟
• ایا د لیبل نومونه مهم دي؟ ایا دوی باید په هر ځای کې یو شان وي؟

مخکې له دې چې په ډیبګ کولو تمرکز وکړو، راځئ چې په یاد ولرو چې درې برخې څنګه یو له بل سره تړاو لري. راځئ چې د ځای پرځای کولو او خدماتو سره پیل وکړو.

د ګمارنې او خدماتو ترمنځ اړیکه

تاسو به حیران شئ، مګر ګمارل او خدمت په هیڅ ډول تړاو نلري. پرځای یې، خدمت په مستقیم ډول پوډونو ته اشاره کوي، د ګمارلو په واسطه.

په دې توګه، موږ لیوالتیا لرو چې څنګه پوډونه او خدمات یو له بل سره تړاو لري. درې شیان په یاد ولرئ:

1. انتخاب کونکی (selectorد خدمت لپاره باید لږترلږه یو پوډ لیبل سره سمون ولري.
2. targetPort باید مطابقت ولري containerPort د پوډ دننه کانتینر.
3. port خدمت هر څه کیدی شي. مختلف خدمتونه کولی شي ورته پورټ وکاروي ځکه چې دوی مختلف IP پتې لري.

لاندې انځور په ګرافیکي بڼه پورتنۍ ټول استازیتوب کوي:

1) تصور وکړئ چې خدمت یو ځانګړي پوډ ته ترافیک لارښود کوي:

2) کله چې پوډ جوړ کړئ، تاسو باید مشخص کړئ containerPort په پوډونو کې د هر کانټینر لپاره:

3) کله چې یو خدمت رامینځته کړئ، تاسو باید مشخص کړئ port и targetPort. مګر کوم یو د کانټینر سره د نښلولو لپاره کارول کیږي؟

4) له لارې targetPort. دا باید مطابقت ولري containerPort.

5) راځئ چې ووایو 3000 پورټ په کانټینر کې خلاص دی او بیا ارزښت targetPort باید یو شان وي.

د YAML فایل کې، لیبلونه او ports / targetPort باید مطابقت ولري:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
     labels:  # <<<
        any-name: my-app  # <<<
   spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
       - containerPort: 8080  # <<<
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
   targetPort: 8080  # <<<
 selector:  # <<<
    any-name: my-app  # <<<

د لیبل په اړه څه track: canary د ګمارنې برخې په سر کې؟ ایا دا باید سمون ولري؟

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

د انتخاب کونکي په اړه څه matchLabels?

دا باید تل د پوډ لیبل سره سمون ولري، ځکه چې دا د پوډونو تعقیب لپاره د ځای پرځای کولو لخوا کارول کیږي.

راځئ فرض کړو چې تاسو سم سمونونه کړي دي. دوی څنګه چک کړئ؟

تاسو کولی شئ د لاندې کمانډ سره د پوډ لیبل چیک کړئ:

kubectl get pods --show-labels

یا، که پوډونه په څو غوښتنلیکونو پورې اړه ولري:

kubectl get pods --selector any-name=my-app --show-labels

چیرته any-name=my-app یو لیبل دی any-name: my-app.

ایا کوم مشکلات پاتې دي؟

تاسو کولی شئ د پوډ سره وصل شئ! د دې کولو لپاره تاسو اړتیا لرئ کمانډ وکاروئ port-forward په kubectl کې. دا تاسو ته اجازه درکوي چې خدمت سره وصل شئ او پیوستون وګورئ.

kubectl port-forward service/<service name> 3000:80

دلته:

• service/<service name> - د خدمت نوم؛ زموږ په قضیه کې دا دی my-service;
• 3000 هغه بندر دی چې باید په کمپیوټر کې پرانیستل شي؛
• 80 - پورټ په ساحه کې مشخص شوی port خدمت.

که پیوستون رامینځته شوی وي ، نو تنظیمات سم دي.

که اړیکه ناکامه شي، د لیبلونو سره ستونزه شتون لري یا بندرونه سره سمون نه لري.

د خدمت او داخلیدو ترمنځ اړیکه

غوښتنلیک ته د لاسرسي چمتو کولو بل ګام د انګریس تنظیم کول شامل دي. انګریس ته اړتیا لري چې پوه شي چې څنګه یو خدمت ومومئ، بیا پوډونه ومومئ او دوی ته مستقیم ټرافيک. Ingress د نوم او خلاص بندر په واسطه اړین خدمت پیدا کوي.

د ننوتلو او خدماتو په توضیح کې دوه پیرامیټونه باید سره سمون ولري:

1. servicePort Ingress باید د پیرامیټر سره سمون ولري port په خدمت کې
2. serviceName Ingress باید د ساحې سره سمون ولري name په خدمت کې

لاندې ډیاګرام د بندر اړیکې لنډیز کوي:

1) لکه څنګه چې تاسو دمخه پوهیږئ، خدمت یو مشخص ته غوږ نیسي port:

2) Ingress په نوم یو پیرامیټر لري servicePort:

3) دا پیرامیټر (servicePort) باید تل سره سمون ولري port د خدمت په تعریف کې:

4) که پورټ 80 په خدمت کې مشخص شوی وي ، نو دا اړینه ده servicePort هم د 80 سره مساوي وو:

په عمل کې، تاسو باید لاندې کرښو ته پام وکړئ:

apiVersion: v1
kind: Service
metadata:
 name: my-service  # <<<
spec:
  ports:
 - port: 80  # <<<
   targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
       serviceName: my-service  # <<<
       servicePort: 80  # <<<
     path: /

څنګه چیک کړئ چې انګریس روان دی؟

تاسو کولی شئ دا طریقه وکاروئ kubectl port-forward، مګر د خدمت پرځای تاسو اړتیا لرئ د انګریس کنټرولر سره وصل شئ.

لومړی تاسو اړتیا لرئ د انګریس کنټرولر سره د پوډ نوم ومومئ:

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

د انګریس پوډ ومومئ (دا ممکن په بل نوم ځای کې وي) او کمانډ پرمخ وړئ describeد پورټ شمیرو موندلو لپاره:

kubectl describe pod nginx-ingress-controller-6fc5bcc 
--namespace kube-system 
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

په نهایت کې ، پوډ سره وصل شئ:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

اوس هرکله چې تاسو په خپل کمپیوټر کې 3000 پورټ ته غوښتنه واستوئ ، نو دا به د انګریس کنټرولر سره د پوډ 80 پورټ ته واستول شي. ته په تګ سره http://localhost:3000، تاسو باید هغه پاڼه وګورئ چې د غوښتنلیک لخوا رامینځته شوی.

د بندرونو لنډیز

راځئ یو ځل بیا په یاد ولرو چې کوم بندرونه او لیبلونه باید سره سمون ولري:

1. د خدماتو په تعریف کې انتخاب کونکی باید د پوډ لیبل سره سمون ولري؛
2. targetPort په تعریف کې خدمت باید مطابقت ولري containerPort د پوډ دننه کانتینر؛
3. port په تعریف کې خدمت هر څه کیدی شي. مختلف خدمتونه کولی شي ورته پورټ وکاروي ځکه چې دوی مختلف IP پتې لري؛
4. servicePort ننوتل باید مطابقت ولري port د خدمت په تعریف کې؛
5. د خدمت نوم باید د ساحې سره سمون ولري serviceName په داخل کې

له بده مرغه، دا کافي ندي چې پوه شئ چې څنګه د YAML ترتیب په سمه توګه تنظیم کړئ.

څه پیښیږي کله چې شیان غلط شي؟

پوډ ممکن پیل نشي یا دا ممکن خراب شي.

په کوبرنیټس کې د غوښتنلیک ستونزې تشخیص لپاره 3 مرحلې

مخکې لدې چې تاسو د خپل ګمارنې ډیبګ پیل کړئ ، تاسو اړتیا لرئ ښه پوهه ولرئ چې کوبرنیټس څنګه کار کوي.

څرنګه چې په K8s کې ډاونلوډ شوی هر غوښتنلیک درې برخې لري، دوی باید په یو ټاکلي ترتیب کې ډیبګ شي، له ښکته څخه پیل کیږي.

1. لومړی تاسو اړتیا لرئ ډاډ ترلاسه کړئ چې پوډونه کار کوي، بیا ...
2. وګورئ چې ایا خدمت پوډونو ته ترافیک چمتو کوي ، او بیا ...
3. وګوره چې آیا انګریس په سمه توګه تنظیم شوی.

بصری نمایش:

1) تاسو باید له لاندې څخه د ستونزو په لټه کې شئ. لومړی وګورئ چې پوډونه حالتونه لري Ready и Running:

2) که پوزې چمتو وي (Ready) ، تاسو باید ومومئ چې ایا خدمت د پوډونو ترمینځ ترافیک توزیع کوي:

3) په نهایت کې ، تاسو اړتیا لرئ د خدمت او ننوتلو ترمینځ اړیکې تحلیل کړئ:

1. د پوډرو تشخیص

په ډیری قضیو کې ستونزه د پوډ سره تړاو لري. ډاډ ترلاسه کړئ چې پوډونه په توګه لیست شوي دي Ready и Running. تاسو کولی شئ دا د کمانډ په کارولو سره چیک کړئ:

kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

په پورته کمانډ محصول کې، وروستی پوډ په توګه لیست شوی Running и Readyپه هرصورت، دا د نورو دوو لپاره قضیه نده.

څنګه پوه شو چې څه غلط شوي؟

د پوډ تشخیص لپاره څلور ګټور حکمونه شتون لري:

1. kubectl logs <имя pod'а> تاسو ته اجازه درکوي په پوډ کې له کانټینرونو څخه لاګونه راوباسئ؛
2. kubectl describe pod <имя pod'а> تاسو ته اجازه درکوي د پوډ سره تړلي پیښو لیست وګورئ؛
3. kubectl get pod <имя pod'а> تاسو ته اجازه درکوي په Kubernetes کې ذخیره شوي پوډ YAML ترتیب ترلاسه کړئ؛
4. kubectl exec -ti <имя pod'а> bash تاسو ته اجازه درکوي په یو پوډ کانټینر کې د متقابل کمانډ شیل پیل کړئ

کوم یو باید غوره کړئ؟

حقیقت دا دی چې هیڅ نړیوال حکم شتون نلري. د دې ترکیب باید وکارول شي.

د پوستکي عادي ستونزې

د پوډ غلطیو دوه اصلي ډولونه شتون لري: د پیل کولو تېروتنې او د چلولو تېروتنې.

د پیل تېروتنې:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• InvalidImageName

د وخت تېروتنې:

• CrashLoopBackOff
• RunContainerError
• KillContainerError
• VerifyNonRootError
• RunInitContainerError
• CreatePodSandboxError
• ConfigPodSandboxError
• KillPodSandboxError
• SetupNetworkError
• TeardownNetworkError

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

ImagePullBackOff

دا تېروتنه هغه وخت پیښیږي کله چې کوبرنیټس نشي کولی د پوډ کانټینرونو څخه یو عکس ترلاسه کړي. دلته د دې لپاره درې خورا عام دلیلونه دي:

1. د انځور نوم غلط دی - د بیلګې په توګه، تاسو په دې کې تېروتنه کړې، یا عکس شتون نلري؛
2. د انځور لپاره یو غیر موجود ټاګ مشخص شوی و؛
3. عکس په شخصي ثبت کې زیرمه شوی او کوبرنیټس ورته د لاسرسي اجازه نلري.

لومړی دوه دلیلونه له منځه وړل اسانه دي - یوازې د عکس نوم او ټګ سم کړئ. د وروستي حالت په صورت کې، تاسو اړتیا لرئ په پټه کې د تړل شوي راجستر لپاره اسناد داخل کړئ او په پوډونو کې یې لینکونه اضافه کړئ. د Kubernetes اسنادو کې یو مثال شته دا څنګه کیدی شي.

د کریش لوپ بیک آف

کوبینیټس یوه تېروتنه کوي CrashLoopBackOff، که کانټینر نشي پیل کولی. دا معمولا واقع کیږي کله چې:

1. په اپلیکیشن کې یو بګ شتون لري چې د پیل کولو مخه نیسي؛
2. کانټینر په غلطه توګه ترتیب شوی;
3. د ژوندانه ازموینه ډیر ځله ناکامه شوې ده.

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

kubectl logs <pod-name> --previous

دا د کانټینر د پخواني اوتار څخه د خطا پیغامونه ښیې.

RunContainerError

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

• د غیر موجود حجم نصبولو هڅه کول لکه ConfigMap یا راز؛
• د لوستلو لیکلو په توګه یوازې د لوستلو حجم نصبولو هڅه.

ټیم د داسې غلطیو تحلیل لپاره مناسب دی kubectl describe pod <pod-name>.

پوډونه په پاتې حالت کې دي

یوځل چې رامینځته شي ، پوډ په دولت کې پاتې کیږي Pending.

ولې داسې کیږي؟

دلته احتمالي دلیلونه دي (زه ګومان کوم چې مهالویش ښه کار کوي):

1. کلستر د پوډ چلولو لپاره کافي سرچینې نلري، لکه د پروسس ځواک او حافظه.
2. اعتراض په مناسب نوم ځای کې نصب شوی ResourceQuota او د پوډ رامینځته کول به د دې لامل شي چې نوم ځای د کوټې څخه بهر لاړ شي.
3. پوډ د پاتې کیدو پورې تړلی دی PersistentVolumeClaim.

په دې حالت کې، سپارښتنه کیږي چې کمانډ وکاروئ kubectl describe او برخه وګورئ Events:

kubectl describe pod <pod name>

د اړونده غلطیو په صورت کې ResourceQuotas، دا سپارښتنه کیږي چې د کمانډ په کارولو سره کلستر لاګونه وګورئ

kubectl get events --sort-by=.metadata.creationTimestamp

پوډونه چمتو ندي

که پوډ په توګه لیست شوی وي Running، مګر په یو حالت کې نه دی Ready، پدې معنی چې چمتووالی یې چک کول (readiness probe) ناکامیږي

کله چې دا پیښ شي، پوډ خدمت سره نه نښلوي او هیڅ ټرافیک ورته نه ځي. د چمتووالي ازموینې ناکامي په غوښتنلیک کې د ستونزو له امله رامینځته کیږي. په دې حالت کې، د تېروتنې موندلو لپاره، تاسو اړتیا لرئ چې برخه تحلیل کړئ Events د کمانډ محصول کې kubectl describe.

2. د خدماتو تشخیص

که پوډونه په توګه لیست شوي وي Running и Ready، مګر لاهم د غوښتنلیک څخه هیڅ ځواب شتون نلري ، تاسو باید د خدماتو تنظیمات چیک کړئ.

خدمتونه د دوی د لیبلونو پراساس پوډونو ته د ټرافیک د لیږد مسؤلیت لري. له همدې امله، لومړی شی چې تاسو یې کولو ته اړتیا لرئ دا وګورئ چې څومره پوډونه د خدمت سره کار کوي. د دې کولو لپاره، تاسو کولی شئ په خدمت کې پای ټکي وګورئ:

kubectl describe service <service-name> | grep Endpoints

پای ټکی د فورمې د ارزښتونو یوه جوړه ده <IP-адрес:порт>، او لږترلږه یو داسې جوړه باید په محصول کې شتون ولري (دا چې لږترلږه یو پوډ د خدمت سره کار کوي).

که برخه Endpoins خالي، دوه اختیارونه ممکن دي:

1. د سم لیبل سره هیڅ پوډونه شتون نلري (اشاره: وګورئ چې د نوم ځای په سمه توګه غوره شوی)؛
2. په انتخاب کونکي کې د خدماتو لیبلونو کې یوه تېروتنه شتون لري.

که تاسو د پای ټکي لیست وګورئ مګر بیا هم غوښتنلیک ته لاسرسی نشئ کولی، نو احتمالي مجرم یو بګ دی targetPort د خدمت په تفصیل کې.

د خدماتو فعالیت څنګه چیک کړئ؟

د خدمت ډول ته په پام سره، تاسو کولی شئ کمانډ وکاروئ kubectl port-forward د دې سره نښلولو لپاره:

kubectl port-forward service/<service-name> 3000:80

دلته:

• <service-name> - د خدمت نوم؛
• 3000 هغه بندر دی چې تاسو یې په کمپیوټر کې خلاص کړئ؛
• 80 - د خدمت اړخ کې بندر.

3. د تشخیص داخلول

که تاسو دا تر اوسه لوستلی وي، نو:

• پوډونه په توګه لیست شوي دي Running и Ready;
• خدمت په بریالیتوب سره د پوډونو ترمینځ ترافیک توزیع کوي.

په هرصورت، تاسو لاهم نشئ کولی اپلیکیشن ته ورسیږئ.

دا پدې مانا ده چې د انګریس کنټرولر ډیری احتمال په سمه توګه نه دی تنظیم شوی. څرنګه چې د انګریس کنټرولر په کلستر کې د دریمې ډلې برخه ده، د دې ډول پورې اړه لري د ډیبګ کولو مختلف میتودونه شتون لري.

مګر مخکې لدې چې تاسو د انګریس تنظیم کولو لپاره د ځانګړي وسیلو کارولو څخه کار واخلئ ، تاسو کولی شئ یو څه خورا ساده ترسره کړئ. Ingress کاروي serviceName и servicePort د خدمت سره د نښلولو لپاره. تاسو اړتیا لرئ وګورئ چې ایا دوی په سمه توګه تنظیم شوي دي. تاسو کولی شئ دا د کمانډ په کارولو سره ترسره کړئ:

kubectl describe ingress <ingress-name>

که کالم Backend خالي، د تشکیلاتو د تېروتنې ډېر احتمال شته. که بیکینډونه په ځای وي، مګر غوښتنلیک لاهم د لاسرسي وړ نه وي، نو ستونزه ممکن د دې سره تړاو ولري:

• د عامه انټرنیټ څخه د لاسرسي ترتیبات داخل کړئ؛
• د عامه انټرنیټ څخه د کلستر لاسرسي ترتیبات.

تاسو کولی شئ د زیربنا سره ستونزې په مستقیم ډول د انګریس پوډ سره وصل کولو سره وپیژنئ. د دې کولو لپاره، لومړی د انګریس کنټرولر پوډ ومومئ (دا ممکن په بل نوم ځای کې وي):

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

کمانډ وکاروئ describeد بندر د ټاکلو لپاره:

kubectl describe pod nginx-ingress-controller-6fc5bcc
--namespace kube-system 
 | grep Ports

په نهایت کې ، پوډ سره وصل شئ:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

اوس په کمپیوټر کې د 3000 پورټ ټولې غوښتنې به د پوډ 80 پورټ ته لیږل کیږي.

ایا دا اوس کار کوي؟

• که هو، نو ستونزه د زیربنا سره ده. دا اړینه ده چې معلومه کړئ چې څنګه ټرافيک کلستر ته لیږدول کیږي.
• که نه، نو ستونزه د Ingress کنټرولر سره ده.

که تاسو نشئ کولی د انګریس کنټرولر کار وکړي ، نو تاسو به یې ډیبګ کړئ.

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

د Ingress Nginx کنټرولر ډیبګ کول

د Ingress-nginx پروژه یو چارواکی لري د kubectl لپاره پلگ ان. ټیم kubectl ingress-nginx د دې لپاره کارول کیدی شي:

• د لاګونو تحلیل، پس منظر، سندونه، او نور؛
• د ننوتلو سره اړیکې؛
• د اوسني ترتیب مطالعه.

لاندې درې حکمونه به تاسو سره پدې کې مرسته وکړي:

• kubectl ingress-nginx lint – چکونه nginx.conf;
• kubectl ingress-nginx backend - د شاليد پلټنه کوي (ته ورته kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs - لاګونه چک کوي.

په یاد ولرئ چې په ځینو مواردو کې تاسو اړتیا لرئ د بیرغ په کارولو سره د انګریس کنټرولر لپاره سم نوم ځای مشخص کړئ --namespace <name>.

لنډیز

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

• بې کاره دندې او کرون جابز؛
• StatefulSets او DaemonSets.

زه خپله مننه څرګندوم ګرجیلي ریسکو, ډینیل ویبل и چارلس کریسټیراج د ارزښتناکو نظرونو او اضافو لپاره.

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

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

• «د کوبرنیټس پوډونو کې د ډیبګ کولو لپاره kubectl-debug پلگ ان»
• «د کوبرنیټس په عملیاتو کې د ساتیرۍ سیسټم 6 بګونه [او د دوی حل]»
• «په Kubernetes کې د غوښتنلیکونو پراختیا کونکو لپاره وسیلې»
• «زموږ د SRE ورځني ژوند څخه 6 عملي کیسې ".

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