Анхаарна уу орчуулга: Энэ бол компанийн инженерийн блогоос олон нийтэд нас барсны дараах орчуулгын орчуулга юм . Энэ нь Kubernetes кластер дахь холболттой холбоотой асуудлыг тайлбарласан бөгөөд энэ нь зарим үйлдвэрлэлийн үйлчилгээний хэсэгчилсэн сааталд хүргэсэн.
Энэ нийтлэл нь үхлийн дараах өвчний талаар бага зэрэг мэдээлэл авах эсвэл ирээдүйд болзошгүй DNS асуудлаас урьдчилан сэргийлэхийг хүсч буй хүмүүст хэрэгтэй байж магадгүй юм.
Энэ DNS биш
Энэ нь DNS байж болохгүй
Энэ нь DNS байсан
Preply дахь үхлийн дараах болон үйл явцын талаар бага зэрэг
Үхлийн дараах гэмтэл нь үйлдвэрлэлийн явцад гарсан эвдрэл эсвэл зарим үйл явдлыг дүрсэлдэг. Үхлийн дараах судалгаанд үйл явдлын он цагийн хуваарь, хэрэглэгчийн нөлөөлөл, үндсэн шалтгаан, хийсэн арга хэмжээ, сургамж зэрэг багтана.
Техникийн багийнхны дунд долоо хоног бүр пиццатай уулзахдаа бид янз бүрийн мэдээллийг хуваалцдаг. Ийм уулзалтын хамгийн чухал хэсгүүдийн нэг бол үхлийн дараах шинжилгээ бөгөөд ихэвчлэн слайдтай танилцуулга, үйл явдлын талаар илүү гүнзгий дүн шинжилгээ хийдэг. Бид нас барсны дараа алга ташилт хийдэггүй ч "гэм буруугүй" соёлыг хөгжүүлэхийг хичээдэг (). Бид үхлийн дараах мэдээг бичиж, танилцуулах нь бидэнд (болон бусад хүмүүст) ирээдүйд үүнтэй төстэй тохиолдлуудаас урьдчилан сэргийлэхэд тусална гэдэгт итгэдэг, тиймээс бид тэдгээрийг хуваалцаж байна.
Хэрэг явдалд оролцсон хүмүүс шийтгэл, шийтгэлээс айхгүйгээр дэлгэрэнгүй ярьж чадна гэдгээ мэдрэх ёстой. Гэм буруугүй! Үхлийн дараах бичвэр нь шийтгэл биш, харин бүхэл бүтэн компанид суралцах боломж юм.
Kubernetes дахь DNS-тэй холбоотой асуудлууд. Үхлийн дараах
Огноо: 28.02.2020
Зохиогчид: Амет У., Андрей С., Игорь К., Алексей П.
Статус: Дууслаа
Товчхондоо: Kubernetes кластерын зарим үйлчилгээнд хэсэгчилсэн DNS боломжгүй байна (26 минут).
Нөлөөлөл: A, B, C үйлчилгээнд 15000 үйл явдал алдагдсан
Үндсэн шалтгаан: Kube-proxy нь холболтын хүснэгтээс хуучин оруулгыг зөв устгаж чадаагүй тул зарим үйлчилгээнүүд байхгүй pods-д холбогдохоор оролдсон хэвээр байна.
E0228 20:13:53.795782 1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...Өдөөгч: Kubernetes кластер доторх ачаалал багатай тул CoreDNS-autoscaler нь байршуулалт дахь pods-ийн тоог гурваас хоёр болгон бууруулсан.
шийдэл: Аппликешныг дараагийн байршуулалт нь шинэ зангилаа үүсгэх эхлэлийг тавьсан бөгөөд CoreDNS-autoscaler нь кластерт үйлчлэхийн тулд илүү олон pods нэмсэн нь conntrack хүснэгтийг дахин бичихэд хүргэсэн.
Илрүүлэх: Prometheus мониторинг нь A, B, C үйлчилгээнүүдэд олон тооны 5xx алдаа илрүүлж, жижүүрийн инженерүүдэд дуудлага өгсөн.
Кибана дахь 5xx алдаа
Үйлдэл
үр нөлөө
Төрөл
Хариуцлагатай
Зорилго
CoreDNS-ийн автомат масштабыг идэвхгүй болгох
урьдчилан сэргийлэх
Амет У.
DEVOPS-695
Кэш хийх DNS серверийг тохируулна уу
буурах
Макс В.
DEVOPS-665
Холболтын хяналтыг тохируулна уу
урьдчилан сэргийлэх
Амет У.
DEVOPS-674
Хичээл сурсан
Юу сайн болсон:
- Хяналт шалгалт сайн ажилласан. Хариулт нь хурдан бөгөөд зохион байгуулалттай байсан
- Бид зангилаанд ямар ч хязгаарлалт тавиагүй
Юу буруу байсан:
- Үүнтэй төстэй жинхэнэ үндсэн шалтгаан тодорхойгүй хэвээр байна эсрэгээр
- Бүх үйлдэл нь үндсэн шалтгааныг биш зөвхөн үр дагаврыг нь засдаг (алдаа)
- Бид эрт орой хэзээ нэгэн цагт DNS-тэй холбоотой асуудал гарч болзошгүйг мэдэж байсан ч бид даалгавруудыг эрэмбэлсэнгүй
Бид азтай газар:
- Дараагийн байршуулалтыг CoreDNS-autoscaler эхлүүлсэн бөгөөд энэ нь холболтын хүснэгтийг дарж бичсэн.
- Энэ алдаа нь зөвхөн зарим үйлчилгээнд нөлөөлсөн
Он цагийн хэлхээс (EET)
Цаг хугацаа
үр нөлөө
22:13
CoreDNS-autoscaler нь хонгилын тоог гурваас хоёр болгон бууруулсан
22:18
Хяналтын системээс жижүүрийн инженерүүд дуудлага авч эхэлжээ
22:21
Алдаа гарсан шалтгааныг жижүүрийн инженерүүд хайж эхэлжээ.
22:39
Жижүүрийн инженерүүд хамгийн сүүлийн үеийн үйлчилгээний нэгийг өмнөх хувилбар руу буцаан шилжүүлж эхлэв
22:40
5xx алдаа гарахаа больсон, нөхцөл байдал тогтворжсон
- Илрүүлэх хугацаа: 4 мин
- Үйлдлийн өмнөх хугацаа: 21 мин
- Засах цаг: 1 мин
нэмэлт мэдээлэл
- CoreDNS бүртгэлүүд:
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - Кибана (тайрах), Графана (тайрах) холбоосууд
CPU-ийн хэрэглээг багасгахын тулд Linux цөм нь conntrack гэж нэрлэгддэг зүйлийг ашигладаг. Товчхондоо, энэ нь тусгай хүснэгтэд хадгалагдсан NAT бичлэгүүдийн жагсаалтыг агуулсан хэрэгсэл юм. Дараагийн пакет өмнөхтэй ижил подволд ирэхэд эцсийн IP хаягийг дахин тооцоолохгүй, харин conntrack хүснэгтээс авна.
Conntrack хэрхэн ажилладаг
Үр дүн
Энэ бол зарим хэрэгтэй холбоос бүхий бидний үхлийн дараах нэг жишээ байсан юм. Ялангуяа энэ нийтлэлд бид бусад компаниудад хэрэгтэй байж болох мэдээллийг хуваалцаж байна. Тийм ч учраас бид алдаа гаргахаас айдаггүй бөгөөд үхлийн дараах шинжилгээнийхээ нэгийг олон нийтэд зарладаг. Эндээс илүү сонирхолтой олон нийтийн үхлийн дараах судалгаанууд байна:
- GitLab:
- Dropbox:
- Spotify:
- Бусад олон болон хадгалах газар
- Мөн түүнчлэн SRE Book бүхий олон нийтийн үхлийн дараах
Эх сурвалж: www.habr.com