Получить "не удается найти поле API в структуре контейнера" ​​с "патч kubectl" вызывается через Ansible - PullRequest
0 голосов
/ 24 февраля 2020

Я пытаюсь отладить проблему, о которой недостаточно знаю. Он включает в себя интеграцию Ansible, Helm и Kubectl, все они работают в контейнере на CI-сервере.

У нас есть Docker образ, который работает Ansible. Я не знаю, является ли это нестандартное изображение или нет. Он называется "ansible: 2.2", поэтому похоже, что он ссылается на версию 2.2 Ansible.

. Недавно мы внесли некоторые изменения в сборку, интегрирующие Helm. Вместо того, чтобы хранить шаблоны k8s в git, мы используем Helm для генерации шаблонов и заполняем некоторые дополнительные свойства с помощью Ansible.

В двух сервисах, которые я обновил, чтобы использовать новую систему сборки , Я вижу сообщение об ошибке Ansible, которое начинается так:

не удалось: [] (item = / home / aft / ansible / role / _configrole / tasks /../ templates / k8s / deploy_bg.yaml) => {"updated:" true, "cmd": ["/ usr / bin / kubectl", ...], ..., "stderr:" error: ошибка при применении исправления: \ n \ nto: ...

За ним следуют большие блоки json, и, наконец, заканчивающиеся:

невозможно найти поле API в структуре Container для json field \ "$ setElementOrder / env \"

В общем большом сообщении об ошибке, по-видимому, как часть сообщения об ошибке «kubectl patch», я вижу три больших блока, помеченных как «оригинальный», «Измененный» и «Текущий», все они являются слегка отличающимися вариантами объекта развертывания k8s.

Я не могу понять отношения Подсказка этих трех «оригинальных», «измененных» и «текущих» блоков к тексту этого сообщения об ошибке.

В первом сервисе, в котором мы видели это сообщение об ошибке, один из администраторов сборки сказал, что он попытался удалить существующий объект Deployment вместо того, чтобы позволить процессу попытаться изменить его, и это, похоже, сработало, но я считаю, что это не идеально.

1 Ответ

0 голосов
/ 05 марта 2020

Просто чтобы подвести итоги обсуждения в комментариях.

Проблема была исправлена ​​в соответствии с: ... / Issues / 50040 и ... / pull / 49834 .

Кроме того, документация [1] [2] гласит:

Вы должны использовать версию kubectl, которая находится в пределах одной незначительной разницы версий вашего кластера. Например, клиент v1.2 должен работать с хозяином v1.1, v1.2 и v1.3. Использование последней версии kubectl помогает избежать непредвиденных проблем.

В кластерах высокой доступности (HA) самые новые и самые старые экземпляры kube-apiserver должны быть в пределах одной вспомогательной версии.

kubelet не должен быть новее, чем kube-apiserver, и может быть до двух младших версий старше.

kube-controller-manager, kube-scheduler и cloud-controller-manager не должны быть новее, чем экземпляры kube-apiserver, с которыми они общаются. Предполагается, что они соответствуют младшей версии kube-apiserver, но могут быть до одной младшей версии более старой (для обновления в реальном времени).

kubectl поддерживается в одной минорной версии (более старой или новой) kube-apiserver

...