Каскад ошибок в Kubernetes

это прям оооочень на пальцах. на самом деле дофига проблем решается, все описывать смысла нет. но даже в той ситуации которую выше описал, когда у тебя что то где то отвалилось, тебе скорей всего СНАЧАЛА придется разбираться с каскадом ошибок чтобы понять что именно сдохло, а потом уже переподнимать упавшее. и возможно что переподнимать придется каскадом несколько сервисов, к примеру упавший сервис потянул за собой 2-3 живых, и они висят в таймауте ожидая ответа оч долго. и выяснять это ты будешь методом тыка тк оч врядли что трассировка была кем то настроена...

На скриншоте длинное сообщение с простым, но мрачным объяснением отладки Kubernetes: после падения одного сервиса приходится разбирать каскад ошибок и методом тыка искать причину, потому что трассировка, скорее всего, не настроена. Шутка в контрасте между обещанием объяснить Kubernetes «на пальцах» и реальностью хаотичного восстановления множества зависимых сервисов; такое отправляют как реакцию на сложность DevOps и Kubernetes. EN: The screenshot shows a long message giving a simple but grim explanation of debugging Kubernetes: after one service fails, you have to untangle a cascade of errors and search for the cause by trial and error because tracing is probably not configured. The joke is the contrast between promising to explain Kubernetes “in simple terms” and the reality of chaotically restoring many dependent services; it is shared as a reaction to the complexity of DevOps and Kubernetes.

• @ithueti / 4980 2021-10-28