В этом материале
Terminating Pod может ещё существовать как процесс и оставаться в EndpointSlice. Для диагностики проверяйте ready, serving и terminating отдельно. Удаление из обычного выбора трафика, распространение состояния и завершение уже установленных соединений происходят на разных участках системы.
Terminating Pod может ещё существовать как процесс и оставаться в EndpointSlice. Для диагностики проверяйте ready, serving и terminating отдельно. Удаление из обычного выбора трафика, распространение состояния и завершение уже установленных соединений происходят на разных участках системы.
Свяжите Pod с нужным Service
Сохраните UID Pod, deletionTimestamp, selector Service и принадлежащие ему EndpointSlice. У одного сервиса может быть несколько slices, поэтому просмотр первого объекта не показывает всю картину. Убедитесь, что адрес endpoint соответствует нужному экземпляру и семейству IP. Также найдите компонент, реально направляющий трафик: kube-proxy, ingress, mesh или внешний балансировщик могут иметь собственные обновления и существующие соединения. Kubernetes status не подтверждает мгновенное обновление каждой такой копии.
Прочитайте условия endpoint
Serving отражает способность endpoint обслуживать ответы, terminating — начало удаления. Ready в обычном случае соответствует serving при отсутствии terminating, но для publishNotReadyAddresses существует отдельная оговорка. Документация также описывает поведение proxy, когда все доступные endpoints завершаются. Поэтому условие ready=false полезно для обычного трафика, но не описывает универсальный контракт всех потребителей EndpointSlice. Сохраните версии и настройки фактического service proxy перед выводом о нарушении поведения.
Постройте временной пример
В учебном опыте оператор удаляет Pod, EndpointSlice получает terminating=true, а локальный процесс ещё выполняет cleanup. Клиент с уже существующим соединением продолжает видеть ответ. Это не обязательно означает выбор Pod для нового соединения после обновления proxy. Для различения сценариев проведите отдельные проверки новых соединений и ранее установленных, используя синтетическую нагрузку. Не переносите результат автоматически на streaming API и не делайте вывод о расчёте прерванного usage.
| Событие | Что записать |
|---|---|
| Pod deletion | UID и точное время |
| Endpoint change | Три condition и адрес |
| Proxy update | Подтверждение выбранного потребителя |
| Process exit | Завершение локального обработчика |
Исправьте конкретный участок
Проверьте readiness при начале завершения и достаточный grace period. Затем исследуйте, как ваш proxy получает обновления и обрабатывает terminating endpoints. Не заменяйте отсутствующий механизм статическим sleep без измерения времени распространения. Если запрос приходит через другое Service или прямой Pod IP, изменения исследуемого EndpointSlice его не контролируют. Идентификатор пути трафика должен присутствовать в каждом тесте, иначе сравнение результатов смешает разные маршруты и режимы соединений.
Зафиксируйте границы вывода
Успешная проверка показывает, что выбранный путь перестаёт назначать новую работу согласно задуманной политике и даёт процессу завершиться. Она не доказывает атомарность распределённого обновления. Сохраните timeline, selectors, endpoint conditions и способ создания клиентских соединений. После смены ingress или service proxy повторите опыт: прежняя временная шкала относится к конкретной реализации. Такой артефакт объясняет наблюдаемое поведение без обещания универсального мгновенного drain.
Сохраните также признак повторного использования клиентского соединения. Он помогает объяснить ответ завершающегося процесса без необоснованного утверждения, что балансировщик продолжает назначать ему новые подключения после получения актуального состояния.
Связанные разборы: network and uptime; vllm health ready.