🥇 কুবারনেটস সমস্যা সমাধানের জন্য একটি ভিজ্যুয়াল গাইড

বিঃদ্রঃ. অনুবাদ: এই নিবন্ধটি অবাধে উপলব্ধ প্রকল্প উপকরণের অংশ learn8sযে কোম্পানী এবং পৃথক প্রশাসকদের শেখায় কিভাবে Kubernetes এর সাথে কাজ করতে হয়। এটিতে, প্রকল্পের নেতা, ড্যানিয়েল পোলেনসিক, K8s ক্লাস্টারে চলমান অ্যাপ্লিকেশনগুলির সাথে সাধারণ সমস্যা হলে কী পদক্ষেপ নেওয়া উচিত সে সম্পর্কে একটি ভিজ্যুয়াল গাইড শেয়ার করেছেন৷

TL;DR: আপনার Kubernetes ডিপ্লয়মেন্ট ডিবাগ করতে সাহায্য করার জন্য এখানে একটি ডায়াগ্রাম রয়েছে:

একটি ক্লাস্টারে ত্রুটিগুলি সন্ধান এবং ঠিক করার জন্য ফ্লোচার্ট৷ মূল (ইংরেজিতে) পাওয়া যায় পিডিএফ и ছবির মতো.

Kubernetes এ একটি অ্যাপ্লিকেশন স্থাপন করার সময়, সাধারণত তিনটি উপাদান আছে যা সংজ্ঞায়িত করা প্রয়োজন:

বিস্তৃতি - এটি অ্যাপ্লিকেশনটির অনুলিপি তৈরি করার একটি রেসিপি, যাকে পড বলা হয়;
সেবা - একটি অভ্যন্তরীণ লোড ব্যালেন্সার যা পড জুড়ে ট্রাফিক বিতরণ করে;
প্রবেশ - বহির্বিশ্ব থেকে পরিষেবাতে কীভাবে ট্র্যাফিক আসবে তার একটি বিবরণ৷

এখানে একটি সংক্ষিপ্ত গ্রাফিকাল সারসংক্ষেপ রয়েছে:

1) কুবারনেটসে, অ্যাপ্লিকেশনগুলি লোড ব্যালেন্সারের দুটি স্তরের মাধ্যমে বহির্বিশ্ব থেকে ট্র্যাফিক গ্রহণ করে: অভ্যন্তরীণ এবং বাহ্যিক।

2) অভ্যন্তরীণ ব্যালেন্সারকে বলা হয় সার্ভিস, এক্সটার্নালকে ইনগ্রেস বলা হয়।

3) স্থাপনা পড তৈরি করে এবং তাদের নিরীক্ষণ করে (এগুলি ম্যানুয়ালি তৈরি করা হয় না)।

ধরুন আপনি একটি সহজ অ্যাপ্লিকেশন a la স্থাপন করতে চান হ্যালো ওয়ার্ল্ড. এটির জন্য 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 ব্যবহার করব?
প্রতিটি পরিষেবার জন্য একটি নতুন পোর্ট তৈরি করা উচিত যাতে তারা বিরোধ না করে?
লেবেল নাম কি গুরুত্বপূর্ণ? তাদের কি সব জায়গায় একই হওয়া উচিত?

আমরা ডিবাগিং এর উপর ফোকাস করার আগে, আসুন তিনটি উপাদান একে অপরের সাথে কীভাবে সম্পর্কযুক্ত তা সংক্ষেপে দেখি। এর ডিপ্লয়মেন্ট এবং সার্ভিস দিয়ে শুরু করা যাক।

স্থাপনা এবং পরিষেবার মধ্যে সম্পর্ক

আপনি আশ্চর্য হবেন, কিন্তু স্থাপনা এবং পরিষেবাগুলি কোনোভাবেই সংযুক্ত নয়৷ পরিবর্তে, পরিষেবাটি স্থাপনাকে বাইপাস করে সরাসরি পডের দিকে নির্দেশ করে।

এইভাবে, আমরা কীভাবে পড এবং পরিষেবাগুলি একে অপরের সাথে সম্পর্কিত তা নিয়ে আগ্রহী। তিনটি জিনিস মনে রাখবেন:

নির্বাচক (selector) একটি পরিষেবার জন্য কমপক্ষে একটি পড লেবেল মেলে।
targetPort সঙ্গে মেলাতে হবে containerPort পোড ভিতরে ধারক.
port সেবা যে কোন কিছু হতে পারে। বিভিন্ন পরিষেবা একই পোর্ট ব্যবহার করতে পারে কারণ তাদের আলাদা আইপি ঠিকানা রয়েছে।

নিম্নলিখিত চিত্রটি গ্রাফিকাল আকারে উপরের সমস্তটি উপস্থাপন করে:

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 পরিষেবা

যদি সংযোগটি সফলভাবে প্রতিষ্ঠিত হয়, তাহলে সেটিংস সঠিক।

যদি সংযোগ স্থাপন করা যায় না, তাহলে লেবেলগুলির সাথে একটি সমস্যা আছে বা পোর্টগুলি মেলে না।

পরিষেবা এবং প্রবেশের মধ্যে সম্পর্ক

অ্যাপ্লিকেশানে অ্যাক্সেস প্রদানের পরবর্তী ধাপটি ইনগ্রেস সেট আপ করার সাথে সম্পর্কিত। ইনগ্রেসকে জানতে হবে কীভাবে পরিষেবাটি খুঁজে বের করতে হয়, তারপর পডগুলি খুঁজে বের করে তাদের কাছে ট্রাফিক পাঠান। ইনগ্রেস নাম এবং খোলা পোর্ট দ্বারা প্রয়োজনীয় পরিষেবা খুঁজে পায়।

প্রবেশ এবং পরিষেবার বিবরণে, দুটি পরামিতি অবশ্যই মিলবে:

servicePort ইনগ্রেস অবশ্যই প্যারামিটারের সাথে মেলে port সেবা;
serviceName ইনগ্রেস অবশ্যই মাঠের সাথে মিলবে 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, আপনি অ্যাপ্লিকেশন দ্বারা উত্পন্ন পৃষ্ঠা দেখতে হবে.

পোর্ট দ্বারা সংক্ষিপ্ত

আসুন আবার মনে করি কোন পোর্ট এবং লেবেল অবশ্যই মিলবে:

পরিষেবা সংজ্ঞাতে নির্বাচক অবশ্যই পডের লেবেলের সাথে মিলবে;
targetPort পরিষেবার সংজ্ঞা অবশ্যই মিলবে containerPort একটি শুঁটির ভিতরে একটি ধারক;
port পরিষেবা সংজ্ঞাতে যে কোনও কিছু হতে পারে। বিভিন্ন পরিষেবা একই পোর্ট ব্যবহার করতে পারে কারণ তাদের আলাদা আইপি ঠিকানা রয়েছে;
servicePort প্রবেশ অবশ্যই মিলবে port পরিষেবা সংজ্ঞায়;
পরিষেবার নাম অবশ্যই ক্ষেত্রের সাথে মিলবে serviceName ইনগ্রেস

হায়, YAML কনফিগারেশন সঠিকভাবে কীভাবে গঠন করা যায় তা জানা যথেষ্ট নয়।

কিছু ভুল হয়ে গেলে কি হয়?

পড শুরু নাও হতে পারে বা বিপর্যস্ত হতে পারে।

Kubernetes-এ অ্যাপ্লিকেশনের সমস্যা সমাধানের 3টি ধাপ

আপনি আপনার স্থাপনা ডিবাগ করা শুরু করার আগে, কুবারনেটস কীভাবে কাজ করে সে সম্পর্কে আপনার ভাল ধারণা থাকতে হবে।

যেহেতু K8s-এ প্রতিটি ডাউনলোড করা অ্যাপ্লিকেশানে তিনটি উপাদান রয়েছে, সেগুলিকে একটি নির্দিষ্ট ক্রমে ডিবাগ করুন, নীচে থেকে শুরু করে৷

প্রথমে আপনাকে নিশ্চিত করতে হবে যে পডগুলি কাজ করছে, তারপর ...
পরিষেবাটি পডগুলিতে ট্র্যাফিক সরবরাহ করছে কিনা তা পরীক্ষা করুন এবং তারপরে…
ইনগ্রেস সঠিকভাবে কনফিগার করা হয়েছে কিনা তা পরীক্ষা করুন।

চাক্ষুষ উপস্থাপনা:

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, কিন্তু এটি অন্য দুটির ক্ষেত্রে নয়।

কী করে বুঝব কী ভুল হয়েছে?

পড নির্ণয়ের জন্য চারটি দরকারী কমান্ড রয়েছে:

kubectl logs <имя pod'а> আপনাকে একটি পডের পাত্রে থেকে লগগুলি বের করতে দেয়;
kubectl describe pod <имя pod'а> আপনাকে পডের সাথে যুক্ত ইভেন্টের তালিকা দেখতে দেয়;
kubectl get pod <имя pod'а> আপনাকে কুবারনেটসে সংরক্ষিত একটি পডের YAML কনফিগারেশন পেতে অনুমতি দেয়;
kubectl exec -ti <имя pod'а> bash আপনাকে পডের একটি পাত্রে একটি ইন্টারেক্টিভ কমান্ড শেল চালানোর অনুমতি দেয়

কোনটি বেছে নেবেন?

বাস্তবতা হল কোন সার্বজনীন আদেশ নেই। তাদের একটি সংমিশ্রণ ব্যবহার করা উচিত।

সাধারণ পড সমস্যা

দুটি প্রধান ধরণের পড ত্রুটি রয়েছে: স্টার্টআপ ত্রুটি এবং রানটাইম ত্রুটি৷

লঞ্চ ত্রুটি:

ImagePullBackoff
ImageInspectError
ErrImagePull
ErrImageNeverPull
RegistryUnavailable
InvalidImageName

রানটাইম ত্রুটি:

CrashLoopBackOff
RunContainerError
KillContainerError
VerifyNonRootError
RunInitContainerError
CreatePodSandboxError
ConfigPodSandboxError
KillPodSandboxError
SetupNetworkError
TeardownNetworkError

কিছু ত্রুটি অন্যদের চেয়ে বেশি সাধারণ। এখানে কিছু সাধারণ ত্রুটি এবং কীভাবে সেগুলি ঠিক করা যায় তা রয়েছে৷

ইমেজপুলব্যাকঅফ

এই ত্রুটিটি ঘটে যখন কুবারনেটস পডের একটি পাত্রের জন্য একটি চিত্র পেতে অক্ষম হয়। এখানে এর তিনটি সবচেয়ে সাধারণ কারণ রয়েছে:

ছবির নামটি ভুল - উদাহরণস্বরূপ, আপনি এটিতে একটি ভুল করেছেন, বা ছবিটি বিদ্যমান নেই;
ছবির জন্য একটি অবৈধ ট্যাগ নির্দিষ্ট করা হয়েছে;
ছবিটি একটি প্রাইভেট রেজিস্ট্রিতে সংরক্ষিত আছে এবং কুবারনেটসের এটি অ্যাক্সেস করার অনুমতি নেই।

প্রথম দুটি কারণ ঠিক করা সহজ - শুধু ছবির নাম এবং ট্যাগ ঠিক করুন৷ পরেরটির ক্ষেত্রে, গোপনে প্রাইভেট রেজিস্ট্রির জন্য শংসাপত্রগুলি প্রবেশ করানো এবং পডগুলিতে এটিতে লিঙ্ক যুক্ত করা প্রয়োজন। কুবারনেটস ডকুমেন্টেশনে একটি উদাহরণ আছে এটা কিভাবে করা যেতে পারে।

ক্র্যাশ লুপ ব্যাক অফ

Kubenetes একটি ত্রুটি নিক্ষেপ CrashLoopBackOffযদি ধারকটি শুরু করতে না পারে। এটি সাধারণত ঘটে যখন:

অ্যাপ্লিকেশনটিতে একটি বাগ রয়েছে যা এটিকে চলতে বাধা দেয়;
আধার ভুলভাবে কনফিগার করা হয়েছে;
লাইভনেস পরীক্ষা অনেকবার ফেল করেছে।

এটির ব্যর্থতার কারণ খুঁজে বের করার জন্য ধারক থেকে লগগুলিতে যাওয়ার চেষ্টা করা প্রয়োজন। যদি লগগুলি অ্যাক্সেস করা কঠিন হয় কারণ ধারকটি খুব দ্রুত পুনরায় চালু হয়, আপনি নিম্নলিখিত কমান্ডটি ব্যবহার করতে পারেন:

kubectl logs <pod-name> --previous

এটি কন্টেইনারের পূর্ববর্তী পুনর্জন্ম থেকে ত্রুটি বার্তা প্রিন্ট করে।

RunContainerError

ধারকটি শুরু করতে অক্ষম হলে এই ত্রুটিটি ঘটে। এটি অ্যাপ্লিকেশন শুরু হওয়ার আগের মুহূর্তের সাথে মিলে যায়। এটি সাধারণত একটি ভুল কনফিগারেশনের কারণে হয়, যেমন:

কনফিগম্যাপ বা সিক্রেটসের মতো একটি অস্তিত্বহীন ভলিউম মাউন্ট করার চেষ্টা করছে;
পঠন-লেখা হিসাবে একটি শুধুমাত্র-পঠন ভলিউম মাউন্ট করার চেষ্টা করছে।

এই ধরনের ত্রুটি বিশ্লেষণের জন্য কমান্ডটি উপযুক্ত। kubectl describe pod <pod-name>.

মুলতুবি অবস্থায় শুঁটি

সৃষ্টির পর শুঁটি অবস্থায় থাকে Pending.

এটি কেন ঘটছে?

এখানে সম্ভাব্য কারণ রয়েছে (আমি অনুমান করছি সময়সূচী ঠিক কাজ করে):

পড চালানোর জন্য ক্লাস্টারে পর্যাপ্ত সংস্থান নেই, যেমন প্রক্রিয়াকরণ শক্তি এবং মেমরি।
একটি বস্তু উপযুক্ত নামস্থানে সেট করা হয় ResourceQuota এবং একটি পড তৈরি করলে নামস্থান কোটার বাইরে চলে যাবে।
পড মুলতুবি বাঁধা PersistentVolumeClaim.

এই ক্ষেত্রে, কমান্ডটি ব্যবহার করার পরামর্শ দেওয়া হয় kubectl describe এবং বিভাগ চেক করুন Events:

kubectl describe pod <pod name>

এর সাথে সম্পর্কিত ত্রুটির ক্ষেত্রে ResourceQuotas, কমান্ড ব্যবহার করে ক্লাস্টার লগগুলি দেখার পরামর্শ দেওয়া হয়

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

শুঁটি প্রস্তুত নয়

যদি পড হিসাবে তালিকাভুক্ত করা হয় Running, কিন্তু রাজ্যে নেই Ready, মানে এর প্রস্তুতি পরীক্ষা করা (প্রস্তুতি তদন্ত) ব্যর্থ হয়

যখন এটি ঘটে, পডটি পরিষেবার সাথে সংযুক্ত হয় না এবং এতে কোনও ট্র্যাফিক পাঠানো হয় না। প্রস্তুতি পরীক্ষায় ব্যর্থতা প্রয়োগে সমস্যার কারণে হয়। এই ক্ষেত্রে, ত্রুটি খুঁজে পেতে, আপনি বিভাগ বিশ্লেষণ করতে হবে Events কমান্ড আউটপুটে kubectl describe.

2. পরিষেবা ডায়াগনস্টিকস

যদি পড হিসাবে তালিকাভুক্ত করা হয় Running и Ready, কিন্তু অ্যাপ্লিকেশন থেকে এখনও কোন প্রতিক্রিয়া নেই, আপনি পরিষেবা সেটিংস চেক করা উচিত.

পরিষেবাগুলি তাদের লেবেলের উপর নির্ভর করে পডগুলিতে ট্র্যাফিক রাউটিং করতে নিযুক্ত রয়েছে৷ অতএব, প্রথম জিনিসটি পরীক্ষা করতে হবে কতগুলি পড পরিষেবার সাথে কাজ করছে। এটি করার জন্য, আপনি পরিষেবার শেষ পয়েন্টগুলি পরীক্ষা করতে পারেন:

kubectl describe service <service-name> | grep Endpoints

এন্ডপয়েন্ট হল ফর্মের মানগুলির একটি জোড়া <IP-адрес:порт>, এবং অন্তত একটি এই ধরনের জোড়া আউটপুটে উপস্থিত থাকতে হবে (অর্থাৎ, অন্তত একটি পড পরিষেবার সাথে কাজ করছে)।

যদি বিভাগ Endpoins খালি, দুটি বিকল্প আছে:

সঠিক লেবেল সহ কোন পড নেই (ইঙ্গিত: নামস্থানটি সঠিক কিনা তা পরীক্ষা করুন);
নির্বাচকের পরিষেবা লেবেলে একটি ত্রুটি আছে৷

আপনি যদি শেষ পয়েন্টগুলির একটি তালিকা দেখতে পান তবে এখনও অ্যাপ্লিকেশনটি অ্যাক্সেস করতে না পারেন, তাহলে সম্ভবত অপরাধী একটি বাগ targetPort পরিষেবার বিবরণে।

পরিষেবাটি কাজ করছে কিনা তা কীভাবে পরীক্ষা করবেন?

পরিষেবার ধরন নির্বিশেষে, আপনি কমান্ড ব্যবহার করতে পারেন kubectl port-forward এটি সংযোগ করতে:

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

এখানে:

<service-name> - কাজের নাম;
3000 হল সেই পোর্ট যা আপনি কম্পিউটারে খুলবেন;
80 - পরিষেবার দিকে পোর্ট।

3. ইনগ্রেস ডায়াগনস্টিকস

আপনি যদি এই পর্যন্ত পড়ে থাকেন, তাহলে:

পড হিসাবে তালিকাভুক্ত করা হয় Running и Ready;
পরিষেবাটি সফলভাবে পডের মধ্যে ট্র্যাফিক বিতরণ করে।

যাইহোক, আপনি এখনও অ্যাপ্লিকেশনটিতে "এর মাধ্যমে পেতে" পারবেন না।

এর মানে হল যে ইনগ্রেস কন্ট্রোলারটি সম্ভবত ভুল কনফিগার করা হয়েছে। যেহেতু ইনগ্রেস কন্ট্রোলার ক্লাস্টারের একটি তৃতীয় পক্ষের উপাদান, তাই এর প্রকারের উপর নির্ভর করে বিভিন্ন ডিবাগিং পদ্ধতি রয়েছে।

কিন্তু Ingress'a কনফিগার করার জন্য বিশেষ সরঞ্জামগুলির সাহায্য নেওয়ার আগে, আপনি খুব সহজ কিছু করতে পারেন। ইনগ্রেস ব্যবহার করে 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 পোর্টে পুনঃনির্দেশিত হবে।

এটা কি এখন কাজ করে?

যদি তাই হয়, তাহলে সমস্যা হল পরিকাঠামো নিয়ে। ট্রাফিক কিভাবে ক্লাস্টারে রুট করা হয় তা খুঁজে বের করা প্রয়োজন।
যদি না হয়, তাহলে সমস্যাটি ইনগ্রেস কন্ট্রোলারের সাথে।

আপনি যদি ইনগ্রেস কন্ট্রোলারটি কাজ করতে না পারেন তবে আপনাকে এটি ডিবাগ করতে হবে।

ইনগ্রেস কন্ট্রোলার অনেক বৈচিত্র্য আছে. সবচেয়ে জনপ্রিয় হল Nginx, HAProxy, Traefik ইত্যাদি। (বিদ্যমান সমাধান সম্পর্কে আরও তথ্যের জন্য, দেখুন আমাদের পর্যালোচনা - প্রায়. অনুবাদ।) উপযুক্ত নিয়ামকের জন্য ডকুমেন্টেশনে সমস্যা সমাধানের নির্দেশিকা পড়ুন। কারন Ingress Nginx সবচেয়ে জনপ্রিয় ইনগ্রেস কন্ট্রোলার, আমরা এই নিবন্ধে এটির সাথে কীভাবে মোকাবিলা করতে হয় তার কয়েকটি টিপস অন্তর্ভুক্ত করেছি।

একটি Nginx ইনগ্রেস কন্ট্রোলার ডিবাগ করা

Ingress-nginx প্রকল্পের একজন কর্মকর্তা আছে kubectl এর জন্য প্লাগইন. টীম kubectl ingress-nginx এর জন্য ব্যবহার করা যেতে পারে:

লগ, ব্যাকএন্ড, সার্টিফিকেট ইত্যাদির বিশ্লেষণ;
Ingress'u সংযোগ;
বর্তমান কনফিগারেশন পরীক্ষা করা হচ্ছে।

নিম্নলিখিত তিনটি কমান্ড আপনাকে এতে সাহায্য করবে:

kubectl ingress-nginx lint - চেক nginx.conf;
kubectl ingress-nginx backend - ব্যাকএন্ড অন্বেষণ করে (এর অনুরূপ kubectl describe ingress <ingress-name>);
kubectl ingress-nginx logs - লগ চেক করে।

অনুগ্রহ করে মনে রাখবেন যে কিছু ক্ষেত্রে পতাকা ব্যবহার করে ইনগ্রেস কন্ট্রোলারের জন্য সঠিক নামস্থান নির্দিষ্ট করার প্রয়োজন হতে পারে --namespace <name>.

সারাংশ

আপনি কোথা থেকে শুরু করবেন তা না জানলে কুবারনেটস সমস্যা সমাধান করা কঠিন হতে পারে। সমস্যাটি সর্বদা নীচের দিক থেকে যোগাযোগ করা উচিত: পড দিয়ে শুরু করুন এবং তারপরে পরিষেবা এবং প্রবেশে যান। নিবন্ধে বর্ণিত ডিবাগিং পদ্ধতিগুলি অন্যান্য বস্তুতে প্রয়োগ করা যেতে পারে, যেমন:

নিষ্ক্রিয় চাকরি এবং ক্রনজবস;
স্টেটফুল সেট এবং ডেমনসেট।

আমি কৃতজ্ঞতা প্রকাশ করছি Gergely Risko, ড্যানিয়েল ওয়েইবেল и চার্লস ক্রিস্টিরাজ মূল্যবান মন্তব্য এবং সংযোজনের জন্য।

অনুবাদক থেকে PS

আমাদের ব্লগেও পড়ুন:

উত্স: www.habr.com

কুবারনেটস সমস্যা সমাধানের জন্য একটি ভিজ্যুয়াল গাইড