{"id":80532,"date":"2020-05-07T01:42:17","date_gmt":"2020-05-06T23:42:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/problemy-s-dns-v-kubernetes-publichnyj-postmortem"},"modified":"2020-05-07T01:42:17","modified_gmt":"2020-05-06T23:42:17","slug":"problemy-s-dns-v-kubernetes-publichnyj-postmortem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/problemy-s-dns-v-kubernetes-publichnyj-postmortem","title":{"rendered":"DNS probl\u00e9m\u00e1k a Kubernetesben. Nyilv\u00e1nos posztmortem","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Megjegyz\u00e9s:<\/b> ez a v\u00e1llalat m\u00e9rn\u00f6ki blogj\u00e1b\u00f3l sz\u00e1rmaz\u00f3 nyilv\u00e1nos posztmortem ford\u00edt\u00e1sa Preply<\/a><\/noindex>. A dokumentum le\u00edrja a conntrack probl\u00e9m\u00e1t a Kubernetes klaszterben, ami n\u00e9h\u00e1ny termel\u00e9si szolg\u00e1ltat\u00e1s r\u00e9szleges le\u00e1ll\u00e1s\u00e1hoz vezetett.<\/i><\/p>\n

Ez a cikk hasznos lehet azok sz\u00e1m\u00e1ra, akik t\u00f6bbet szeretn\u00e9nek megtudni a posztmortemekr\u0151l, vagy meg akarj\u00e1k el\u0151zni a potenci\u00e1lis DNS probl\u00e9m\u00e1kat a j\u00f6v\u0151ben.<\/p>\n

\"DNS
\nEz nem DNS
\nNem lehet, hogy ez DNS
\nEz DNS volt<\/i>
\n<\/a><\/noindex><\/p>\n

Egy kis tudnival\u00f3 a posztmortemekr\u0151l \u00e9s a Preply folyamatokr\u00f3l<\/h2>\n

<\/p>\n

A posztmortem a m\u0171k\u00f6d\u00e9si zavarokat vagy esem\u00e9nyeket \u00edrja le a termel\u00e9sben. A posztmortem tartalmazza az esem\u00e9nyek id\u0151vonal\u00e1t, a felhaszn\u00e1l\u00f3kra gyakorolt hat\u00e1st, az els\u0151dleges okokat, a tennival\u00f3kat \u00e9s az ebb\u0151l levont tanuls\u00e1gokat.<\/p>\n

Seeking SRE<\/a><\/noindex><\/i><\/p><\/blockquote>\n

\nA heti, pizz\u00e1val egybek\u00f6t\u00f6tt megbesz\u00e9l\u00e9seinken a technikai csapat k\u00f6r\u00e9ben k\u00fcl\u00f6nb\u00f6z\u0151 inform\u00e1ci\u00f3kat osztunk meg. Az ilyen megbesz\u00e9l\u00e9sek legfontosabb r\u00e9szei k\u00f6z\u00e9 tartoznak a posztmortemek, amelyeket legt\u00f6bbsz\u00f6r \u0434\u0438\u0430\u043friz\u00e1ci\u00f3val \u00e9s m\u00e9lyebb elemz\u00e9ssel k\u00eds\u00e9r\u00fcnk. B\u00e1r a posztmortemek ut\u00e1n nem tapsolunk, pr\u00f3b\u00e1ljuk fejleszteni a \"hib\u00e1tlan kult\u00far\u00e1t\" (blameless culture<\/a><\/noindex>). Hisz\u00fcnk abban, hogy a posztmortemek \u00edr\u00e1sa \u00e9s bemutat\u00e1sa seg\u00edthet nek\u00fcnk (\u00e9s m\u00e1soknak) a hasonl\u00f3 esem\u00e9nyek j\u00f6v\u0151beni megel\u0151z\u00e9s\u00e9ben, ez\u00e9rt osztjuk meg \u0151ket.<\/p>\n

Az incidensbe beleavatkoz\u00f3 szem\u00e9lyeknek \u00e9rezni\u00fck kell, hogy r\u00e9szletesen besz\u00e9lhetnek r\u00f3la, an\u00e9lk\u00fcl, hogy a b\u00fcntet\u00e9st\u0151l vagy v\u00e9dekez\u00e9st\u0151l kellene tartaniuk. Nincs elmarasztal\u00e1s! A posztmortem \u00edr\u00e1sa nem b\u00fcntet\u00e9s, hanem tanul\u00e1si lehet\u0151s\u00e9g az eg\u00e9sz v\u00e1llalat sz\u00e1m\u00e1ra.<\/p>\n

Keep CALMS & DevOps: S is for Sharing<\/a><\/noindex><\/i><\/p><\/blockquote>\n

<\/p>\n

DNS probl\u00e9m\u00e1k a Kubernetesben. Posztmortem<\/h2>\n

\nD\u00e1tum:<\/b> 28.02.2020<\/p>\n

Szerz\u0151k:<\/b> Amet U., Andrey S., Igor K., Alexey P.<\/p>\n

\u00c1llapot:<\/b> Befejezve<\/p>\n

R\u00f6viden:<\/b> DNS r\u00e9szleges el\u00e9rhetetlens\u00e9g (26 perc) n\u00e9h\u00e1ny szolg\u00e1ltat\u00e1s sz\u00e1m\u00e1ra a Kubernetes klaszterben<\/p>\n

Hat\u00e1s:<\/b> 15000 esem\u00e9ny elveszett az A, B \u00e9s C szolg\u00e1ltat\u00e1sok sz\u00e1m\u00e1ra<\/p>\n

Els\u0151dleges ok:<\/b> A Kube-proxy nem tudta helyesen elt\u00e1vol\u00edtani a r\u00e9gi bejegyz\u00e9st a conntrack t\u00e1bl\u00e1b\u00f3l, ez\u00e9rt egyes szolg\u00e1ltat\u00e1sok tov\u00e1bbra is a nem l\u00e9tez\u0151 podokhoz pr\u00f3b\u00e1ltak csatlakozni<\/p>\n

E0228 20:13:53.795782       1 proxier.go:610] A kube-system\/kube-dns:dns v\u00e9gpont kapcsolatok t\u00f6rl\u00e9se nem siker\u00fclt, hiba: hiba t\u00f6rt\u00e9nt a conntrack bejegyz\u00e9sek t\u00f6rl\u00e9sekor az UDP t\u00e1rs {100.64.0.10, 100.110.33.231} eset\u00e9n, hiba: a conntrack parancs visszat\u00e9rt: ...<\/code><\/pre>\n
\nTrigger:<\/b> Az alacsony terhel\u00e9s miatt a Kubernetes klaszterben a CoreDNS-autoscaler cs\u00f6kkentette a podok sz\u00e1m\u00e1t a telep\u00edt\u00e9sben h\u00e1rmr\u00f3l kett\u0151re<\/p>\n
Megold\u00e1s:<\/b> A k\u00f6vetkez\u0151 alkalmaz\u00e1s telep\u00edt\u00e9se \u00faj csom\u00f3pontok l\u00e9trehoz\u00e1s\u00e1t ind\u00edtotta el, a CoreDNS-autoscaler t\u00f6bb podot adott hozz\u00e1 a klaszter kiszolg\u00e1l\u00e1s\u00e1hoz, ami a conntrack t\u00e1bl\u00e1zat fel\u00fcl\u00edr\u00e1s\u00e1t okozta.<\/p>\n
Felfedez\u00e9s:<\/b> A Prometheus monitoroz\u00e1s nagy sz\u00e1m\u00fa 5xx hib\u00e1t \u00e9szlelt az A, B \u00e9s C szolg\u00e1ltat\u00e1sokn\u00e1l, \u00e9s \u00e9rtes\u00edtette a hivat\u00e1sos m\u00e9rn\u00f6k\u00f6ket.<\/p>\n
\"DNS
\n5xx hib\u00e1k a Kibana-ban.<\/i><\/p>\n
M\u0171veletek<\/h3>\n
<\/p>\n
M\u0171velet
\nT\u00edpus
\nFelel\u0151s
\nFeladat<\/p>\n
Az automatikus sk\u00e1l\u00e1z\u00f3t le kell \u00e1ll\u00edtani a CoreDNS sz\u00e1m\u00e1ra.
\nmegakad\u00e1lyozni
\nAmet U.
\nDEVOPS-695<\/p>\n
Cache-el\u0151 DNS-szerver be\u00e1ll\u00edt\u00e1sa.
\ncs\u00f6kkenteni
\nMax V.
\nDEVOPS-665<\/p>\n
Conntrack monitoroz\u00e1s be\u00e1ll\u00edt\u00e1sa.
\nmegakad\u00e1lyozni
\nAmet U.
\nDEVOPS-674<\/p>\n
<\/p>\n
Tanulm\u00e1nyozott leck\u00e9k.<\/h3>\n
\nMi ment j\u00f3l:<\/b><\/p>\n