с 1.18 до 1.19. В процессе поиска устаревших(deprecated) ресурсов есть вопросов. Использую для этого две утилиты pluto и kubent. Обе показывают неверные apiVersion. Пример вывода
pluto detect-helm -o wide
можете посмотреть на скрине
Но, когда я пытаюсь определить apiVersion при помощи:
kubectl get clusterrole -n grafana -o yaml | head -n 8
Вывод такой:
apiVersion: v1
items:
- aggregationRule:
clusterRoleSelectors:
- matchLabels:
rbac.authorization.k8s.io/aggregate-to-admin: "true"
apiVersion: rbac.authorization.k8s.io/v1
Так вот возникает резонный вопрос: Почему Плуто показывает неверную apiVersion?
тебе ж в слаке ответили)))
Ответили, но я слегка не понял)
Да обновись, по ходу разберёшься
Спасибо, но пока дров ломать не буду)
ресурсы в кластере итак обновяться сами при апргрейде. Задача то обновить твои манифесты в репах, которые деплоятся в куб.
Я понимаю это. Может подскажешь утилиту, которая чекает манифесты в репе?
pluto вроде это делает не? https://github.com/doitintl/kube-no-trouble вот еще было
а ну ты тоже самое же нашел. Уже пробовал их?
Пробовал, но проверял не репу, а сам куб и вот выходит не стыковка, которую описал в первом сообщении. Попробую тогда чекнуть репу ими. Спасибо за подсказку
надо локальные файлы проверять. Куб то может возвращать другой apiVersion (не тот что ты указан в манифестах). Об этом в pluto написано в README в самом начале > You might think, "I'll just ask the api-server to tell me!", but this is fraught with danger. If you ask the api-server to give you deployments.v1.apps, and the deployment was deployed as deployments.v1beta1.extensions, the api-server will quite happily convert the api version and return a manifest with apps/v1. This is fairly well outlined in the discussion in this issue.
О, уже что-то проясняется в моей голове. Благодарствую
Обсуждают сегодня