കുബെർനെറ്റസ് ട്രബിൾഷൂട്ടിംഗിനുള്ള ഒരു വിഷ്വൽ ഗൈഡ്

കുറിപ്പ്. വിവർത്തനം.: ഈ ലേഖനം പൊതുസഞ്ചയത്തിൽ പ്രസിദ്ധീകരിച്ച പ്രോജക്റ്റ് മെറ്റീരിയലുകളുടെ ഭാഗമാണ് പഠിക്കുക8s, പരിശീലന കമ്പനികളും വ്യക്തിഗത അഡ്മിനിസ്ട്രേറ്റർമാരും കുബെർനെറ്റുമായി പ്രവർത്തിക്കാൻ. അതിൽ, K8s ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷനുകളിൽ പൊതുവായ പ്രശ്‌നങ്ങളുണ്ടെങ്കിൽ എന്ത് നടപടികളാണ് സ്വീകരിക്കേണ്ടതെന്ന് പ്രോജക്റ്റ് മാനേജർ ഡാനിയേൽ പോളൻസിക് വിഷ്വൽ നിർദ്ദേശങ്ങൾ പങ്കിടുന്നു.

TL;DR: Kubernetes-ലെ വിന്യാസം ഡീബഗ് ചെയ്യാൻ നിങ്ങളെ സഹായിക്കുന്ന ഒരു ഡയഗ്രം ഇതാ:

ഒരു ക്ലസ്റ്ററിലെ പിശകുകൾ കണ്ടെത്തുന്നതിനും പരിഹരിക്കുന്നതിനുമുള്ള ഫ്ലോചാർട്ട്. ഒറിജിനൽ (ഇംഗ്ലീഷിൽ) ഇവിടെ ലഭ്യമാണ് പീഡിയെഫ് и ചിത്രമായി.

Kubernetes-ലേക്ക് ഒരു ആപ്ലിക്കേഷൻ വിന്യസിക്കുമ്പോൾ, സാധാരണയായി മൂന്ന് ഘടകങ്ങൾ നിങ്ങൾ നിർവചിക്കേണ്ടതുണ്ട്:

• വിന്യാസ - ഇത് പോഡ്‌സ് എന്ന് വിളിക്കുന്ന ആപ്ലിക്കേഷന്റെ പകർപ്പുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള ഒരുതരം പാചകക്കുറിപ്പാണ്;
• സേവനം - പോഡുകൾക്കിടയിൽ ട്രാഫിക് വിതരണം ചെയ്യുന്ന ആന്തരിക ലോഡ് ബാലൻസർ;
• തുടരുക — പുറം ലോകത്തിൽ നിന്ന് സേവനത്തിലേക്ക് ട്രാഫിക് എങ്ങനെ എത്തും എന്നതിന്റെ വിവരണം.

ഒരു ദ്രുത ഗ്രാഫിക്കൽ സംഗ്രഹം ഇതാ:

1) കുബെർനെറ്റസിൽ, ലോഡ് ബാലൻസറുകളുടെ രണ്ട് പാളികളിലൂടെ ബാഹ്യലോകത്തിൽ നിന്ന് ആപ്ലിക്കേഷനുകൾ ട്രാഫിക് സ്വീകരിക്കുന്നു: ആന്തരികവും ബാഹ്യവും.

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 സേവനം.

കണക്ഷൻ സ്ഥാപിച്ചിട്ടുണ്ടെങ്കിൽ, ക്രമീകരണങ്ങൾ ശരിയാണ്.

കണക്ഷൻ പരാജയപ്പെടുകയാണെങ്കിൽ, ലേബലുകളിൽ ഒരു പ്രശ്നമുണ്ട് അല്ലെങ്കിൽ പോർട്ടുകൾ പൊരുത്തപ്പെടുന്നില്ല.

സേവനവും പ്രവേശനവും തമ്മിലുള്ള ബന്ധം

അപ്ലിക്കേഷനിലേക്ക് ആക്‌സസ് നൽകുന്നതിനുള്ള അടുത്ത ഘട്ടത്തിൽ ഇൻഗ്രെസ്സ് സജ്ജീകരിക്കുന്നത് ഉൾപ്പെടുന്നു. ഒരു സേവനം എങ്ങനെ കണ്ടെത്താമെന്നും പോഡുകൾ കണ്ടെത്തി അവയിലേക്ക് നേരിട്ടുള്ള ട്രാഫിക്കും എങ്ങനെ കണ്ടെത്താമെന്നും ഇൻഗ്രസിന് അറിയേണ്ടതുണ്ട്. പേരും ഓപ്പൺ പോർട്ടും ഉപയോഗിച്ച് ഇൻഗ്രെസ്സ് ആവശ്യമായ സേവനം കണ്ടെത്തുന്നു.

പ്രവേശനത്തിന്റെയും സേവനത്തിന്റെയും വിവരണത്തിൽ രണ്ട് പാരാമീറ്ററുകൾ പൊരുത്തപ്പെടണം:

1. servicePort ഇൻഗ്രെസ്സ് പാരാമീറ്ററുമായി പൊരുത്തപ്പെടണം port ജോലിയിൽ;
2. 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: /

Ingress പ്രവർത്തിക്കുന്നുണ്ടോയെന്ന് എങ്ങനെ പരിശോധിക്കാം?

ഉപയോഗിച്ച് നിങ്ങൾക്ക് രീതി ഉപയോഗിക്കാം 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

Ingress പോഡ് കണ്ടെത്തി (അത് മറ്റൊരു നെയിംസ്‌പെയ്‌സിലായിരിക്കാം) കമാൻഡ് പ്രവർത്തിപ്പിക്കുക 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. Ingress ശരിയായി ക്രമീകരിച്ചിട്ടുണ്ടോയെന്ന് പരിശോധിക്കുക.

വിഷ്വൽ പ്രാതിനിധ്യം:

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. ചിത്രം ഒരു സ്വകാര്യ രജിസ്ട്രിയിൽ സംഭരിച്ചിരിക്കുന്നു, കുബർനെറ്റസിന് അത് ആക്‌സസ് ചെയ്യാൻ അനുമതിയില്ല.

ആദ്യത്തെ രണ്ട് കാരണങ്ങൾ ഇല്ലാതാക്കാൻ എളുപ്പമാണ് - ചിത്രത്തിന്റെ പേരും ടാഗും ശരിയാക്കുക. രണ്ടാമത്തേതിന്റെ കാര്യത്തിൽ, നിങ്ങൾ സീക്രട്ടിൽ അടച്ച രജിസ്ട്രിയുടെ ക്രെഡൻഷ്യലുകൾ നൽകുകയും അതിലേക്കുള്ള ലിങ്കുകൾ പോഡുകളിൽ ചേർക്കുകയും വേണം. കുബർനെറ്റസ് ഡോക്യുമെന്റേഷനിൽ ഒരു ഉദാഹരണമുണ്ട് ഇത് എങ്ങനെ ചെയ്യാം.

ക്രാഷ് ലൂപ്പ് ബാക്ക് ഓഫ്

കുബെനെറ്റസ് ഒരു പിശക് എറിയുന്നു CrashLoopBackOff, കണ്ടെയ്നർ ആരംഭിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ. ഇത് സാധാരണയായി സംഭവിക്കുമ്പോൾ:

1. ആപ്ലിക്കേഷനിൽ ഒരു ബഗ് ഉണ്ട്, അത് സമാരംഭിക്കുന്നതിൽ നിന്ന് തടയുന്നു;
2. കണ്ടെയ്നർ തെറ്റായി ക്രമീകരിച്ചു;
3. ലൈവ്‌നെസ് ടെസ്റ്റ് പലതവണ പരാജയപ്പെട്ടു.

അതിന്റെ പരാജയത്തിന്റെ കാരണം കണ്ടെത്താൻ നിങ്ങൾ കണ്ടെയ്നറിൽ നിന്ന് ലോഗുകളിലേക്ക് പോകാൻ ശ്രമിക്കണം. കണ്ടെയ്നർ വളരെ വേഗത്തിൽ പുനരാരംഭിക്കുന്നതിനാൽ ലോഗുകൾ ആക്സസ് ചെയ്യാൻ പ്രയാസമാണെങ്കിൽ, നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന കമാൻഡ് ഉപയോഗിക്കാം:

kubectl logs <pod-name> --previous

കണ്ടെയ്‌നറിന്റെ മുൻ അവതാരത്തിൽ നിന്നുള്ള പിശക് സന്ദേശങ്ങൾ ഇത് പ്രദർശിപ്പിക്കുന്നു.

റൺകണ്ടെയ്നർ പിശക്

കണ്ടെയ്നർ ആരംഭിക്കുന്നതിൽ പരാജയപ്പെടുമ്പോൾ ഈ പിശക് സംഭവിക്കുന്നു. ആപ്ലിക്കേഷൻ സമാരംഭിക്കുന്നതിന് മുമ്പുള്ള നിമിഷവുമായി ഇത് പൊരുത്തപ്പെടുന്നു. ഇത് സാധാരണയായി തെറ്റായ ക്രമീകരണങ്ങൾ മൂലമാണ് സംഭവിക്കുന്നത്, ഉദാഹരണത്തിന്:

• ConfigMap അല്ലെങ്കിൽ Secrets പോലുള്ള നിലവിലില്ലാത്ത ഒരു വോള്യം മൌണ്ട് ചെയ്യാൻ ശ്രമിക്കുന്നു;
• റീഡ്-റൈറ്റായി ഒരു റീഡ്-ഒൺലി വോളിയം മൗണ്ട് ചെയ്യാനുള്ള ശ്രമം.

അത്തരം പിശകുകൾ വിശകലനം ചെയ്യാൻ ടീം അനുയോജ്യമാണ് 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, അതിന്റെ സന്നദ്ധത പരിശോധിക്കുന്നു എന്നാണ് (തയ്യാറെടുപ്പ് അന്വേഷണം) പരാജയപ്പെടുന്നു.

ഇത് സംഭവിക്കുമ്പോൾ, പോഡ് സേവനവുമായി ബന്ധിപ്പിക്കുന്നില്ല, അതിലേക്ക് ട്രാഫിക് ഒഴുകുന്നില്ല. ആപ്ലിക്കേഷനിലെ പ്രശ്‌നങ്ങളാണ് റെഡിനെസ് ടെസ്റ്റ് പരാജയത്തിന് കാരണം. ഈ സാഹചര്യത്തിൽ, പിശക് കണ്ടെത്താൻ, നിങ്ങൾ വിഭാഗം വിശകലനം ചെയ്യേണ്ടതുണ്ട് 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-ലേക്ക് റീഡയറക്‌ടുചെയ്യും.

അത് ഇപ്പോൾ പ്രവർത്തിക്കുന്നുണ്ടോ?

• അതെ എങ്കിൽ, അടിസ്ഥാന സൗകര്യങ്ങളുടെ പ്രശ്നമാണ്. ക്ലസ്റ്ററിലേക്കുള്ള ഗതാഗതം എങ്ങനെയാണെന്ന് കൃത്യമായി കണ്ടെത്തേണ്ടത് ആവശ്യമാണ്.
• ഇല്ലെങ്കിൽ, പ്രശ്നം ഇൻഗ്രെസ്സ് കൺട്രോളറിലാണ്.

നിങ്ങൾക്ക് ഇൻഗ്രെസ്സ് കൺട്രോളർ പ്രവർത്തിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, നിങ്ങൾ അത് ഡീബഗ് ചെയ്യേണ്ടിവരും.

ഇൻഗ്രെസ്സ് കൺട്രോളറുകളിൽ നിരവധി ഇനങ്ങൾ ഉണ്ട്. 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 പോഡുകളിലെ ഡീബഗ്ഗിംഗിനുള്ള kubectl-debug പ്ലഗിൻ";
• «കുബെർനെറ്റസിന്റെ പ്രവർത്തനത്തിലെ 6 രസകരമായ സിസ്റ്റം ബഗുകളും [അവയുടെ പരിഹാരവും]";
• «Kubernetes-ൽ പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷനുകളുടെ ഡെവലപ്പർമാർക്കുള്ള ഉപകരണങ്ങൾ";
• «ഞങ്ങളുടെ SRE ദൈനംദിന ജീവിതത്തിൽ നിന്നുള്ള 6 പ്രായോഗിക കഥകൾ ".

അവലംബം: www.habr.com