Это третий день моего участия в Gengwen Challenge.Подробности о мероприятии, пожалуйста, проверьте:Обновить вызов
задний фон
После получения сигнализации кластера тестовой среды входите в кластер K8S для устранения неполадок.
Два места неисправности
2.1 Панель просмотра
Проверьте исключение calico pod узла kube-system node2.
- Просмотрите подробности, убедитесь, что на узле node2 нет места для хранения, а cgroup утекла.
2.2 Просмотр хранилища
- Войдите в node2, чтобы просмотреть информацию о хранилище сервера, в настоящее время еще достаточно места
- Распределенное хранилище, используемое кластером, — это ceph, поэтому проверьте состояние кластера ceph.
Три операции
3.1 исправление цефалограммы
В настоящее время кластер ceph неисправен, что может вызвать аномальную утечку cgroup узла node2, и кластер ceph необходимо восстанавливать вручную.
数据的不一致性（inconsistent）指对象的大小不正确、恢复结束后某副本出现了对象丢失的情况。数据的不一致性会导致清理失败（scrub error）。
CEPH在存储的过程中，由于特殊原因，可能遇到对象信息大小和物理磁盘上实际大小数据不一致的情况，这也会导致清理失败。
Как видно из рисунка, есть проблема с пг номер 1.7с и ее надо ремонтировать.
- ремонт пг
ceph pg repair 1.7c
- После восстановления подождите некоторое время и снова проверьте, восстановлен ли кластер ceph
3.2 Выполнение ремонта модуля
Удалите ненормальный модуль. Из-за контроллера последний модуль будет снова загружен.
Просмотр POD или ранее, анализ может привести к утечке CGroup Node2 узла, онлайн-поиск
- Немного погуглив, я обнаружил, чтоGithub.com/root Отправить военные / ...Студенты в основном та же проблема. Может существовать,
- Ядро Linux хоста Kublet слишком низко - Linux версия 3.10.0-862.el7.x86_64
- Это можно решить, отключив kmem
Проверьте системное ядро, но это младшая версия.
3.3 Переместите неисправность
Наконец, поскольку логика runc будет открывать учетную запись kmem контейнера по умолчанию при запуске контейнера, что приведет к возможной утечке ядра 3.10.
Здесь необходимо выполнить операцию на сервере без свободного местаперезагрузка перезагрузка, проблема может быть решена.Проблема может быть вызвана удалением большого количества модулей за определенный период времени.
Первоначальная идея состоит в том, чтобы подвести итоги управления кластером в будущем, восстановить сервер, удалить узел и перезагрузить узел.
3.4 Поддерживать узел node2
3.4.1 Отметить node2 как незапланированный
kubectl cordon node02
3.4.2 Удаление модулей на node2
kubectl drain node02 --delete-local-data --ignore-daemonsets --force
- --delete-local-data удалить локальные данные, даже emptyDir удалит их;
- --ignore-daemonsets Игнорировать DeamonSet, иначе DeamonSet будет автоматически перестроен после удаления;
- --force Без параметра force будут удалены только ReplicationController, ReplicaSet, DaemonSet, StatefulSet или Job на узле, а после добавления будут удалены все поды;
В настоящее время стручки базового узла2 устранены.
На этом этапе, в отличие от миграции по умолчанию, модуль先重建再终止, В настоящее времяВремя прерывания службы = время восстановления + время запуска службы + нормальное время обнаружения зонда готовности, надо подождать пока1/1 Runningобслуживание будет нормальным.Поэтому при миграции в единственном экземпляре сервисный терминал неизбежен..
3.4.3 Перезапустите node02
После перезапуска node02 был отремонтирован.
Восстановить node02
- Node02 может возобновить обычный график
kubectl uncordon node02
Четыре отражения
- Вы можете обновить развернутое ядро кластера k8s позже.
- Аномалии Pod в кластере могут быть вызваны базовым хранилищем или другими причинами, и необходимо специально локализовать проблему для целевого исправления.