Итак, у вас есть 3 проблемы в одном здесь. К сожалению, это частичный ответ.
1) @ Dine sh абсолютно правильно с изображением.
containers:
- name: nginx-container
- image: nginx
В вашей конфигурации он пытается использовать 2 изображения - nginx-container и nginx. Вместо этого вам нужно только nginx с именем: nginx -container
правильное значение
spec:
containers:
- name: nginx-container
image: nginx
2) В метаданных всегда следует указывать name: - это обязательное поле , Без указания .metadata.name вы получите resource name may not be empty
Object: &{map["apiVersion":"v1" "kind":"Pod" "metadata":map["annotations":map["kubectl.kubernetes.io/last-applied-configuration":""] "labels":map["app":"myapp"] "namespace":"default"] "spec":map["containers":[map["image":"nginx" "name":"nginx-container"]]]]}
from server for: "pod-defination.yml": resource name may not be empty
Согласно Понимание объектов Kubernetes
В файле .yaml для объекта Kubernetes Вы хотите создать, вам нужно установить значения для следующих полей:
- apiVersion - Какую версию API Kubernetes вы используете для создания этого объекта
- kind - Какой тип объекта вы хотите создать
- метаданные - Данные, которые помогают однозначно идентифицировать объект, включая строку имени, UID и необязательное пространство имен
- spe c - В каком состоянии вы хотите объект
Также согласно Соглашениям API метаданных
Каждый тип объекта ДОЛЖЕН иметь следующие метаданные в поле вложенного объекта с именем " метаданные ":
- пространство имен: пространство имен - это DNS-совместимая метка, на которую подразделяются объекты. Пространством имен по умолчанию является «default». Подробнее см. В документах по пространству имен.
- name: строка, которая однозначно идентифицирует этот объект в текущем пространстве имен (см. Документацию по идентификаторам). Это значение используется в пути при извлечении отдельного объекта.
- uid: уникальное во времени и пространстве значение (как правило, сгенерированный идентификатор RF C 4122, см. Документы идентификаторов), используемое для различения объектов с то же имя, которое было удалено и воссоздано
3) модуль не имеет аннотации "kubernetes.io/config.mirror"
модуль "блабла" запрещено: модуль не имеет аннотации «kubernetes.io/config.mirror», узел «blablabla» может создавать только зеркальные модули
Выше ошибка характерна для ситуаций, когда у вас есть проблема с [NodeRestriction подключаемый модуль] {https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction}
Контроллер доступа - это фрагмент кода, который перехватывает запросы к серверу API Kubernetes до сохранения объекта, но после запроса аутентифицирован и авторизован. […] Контроллеры допуска могут быть «проверяющими», «мутирующими» или обоими. Мутирующие контроллеры могут изменять объекты, которые они допускают; проверять контроллеры нельзя. […] Если какой-либо из контроллеров в любой фазе отклоняет запрос, весь запрос немедленно отклоняется, и конечному пользователю возвращается ошибка.
Контроллер допуска NodeRestriction:
Этот контроллер доступа ограничивает объекты Node и Pod, которые может изменить kubelet. Чтобы быть ограниченным этим контроллером доступа, kubelets должны использовать учетные данные в системе: узлы, с именем пользователя в системе формы: узел :. Таким кублетам будет разрешено изменять только собственный объект API Node и изменять только объекты API Pod, которые связаны с их узлом. В Kubernetes 1.11+ kubelets не разрешается обновлять или удалять портящие объекты из своего объекта API Node.
Согласно версиям платформы EKS kubernetes мы видим, что NodeRestriction является частью включенных контроллеров доступа.
NamespaceLifecycle, LimitRanger, ServiceAccount, DefaultStorageClass, ResourceQuota, DefaultTolerationSeconds, NodeRestriction, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, PodSecurityPolicy * 10 * 10 * 1082 081 3 * 1082 881 был уже тот же вопрос но он остался без ответов.
Поскольку EKS управляется плоскостью управления AWS - кажется, невозможно изменить встроенные контроллеры доступа, но вы можете заглянуть в Dynami c Admission Controllers и Admission Webhooks. Дополнительную информацию можно найти в Dynami c Контроль доступа .
Согласно Amazon EKS включает поддержку Kubernetes Dynami c Контроллеры доступа - EKS поддерживает Dynami * Контроллеры доступа 1109 *, позволяющие заказчикам развертывать пользовательские веб-подключения, которые включают дополнительные инструменты с открытым исходным кодом для управления сетевым трафиком c и мониторинга кластеров Kubernetes на AWS.
. Я бы порекомендовал использовать kops * 1096. * вручную создать кластер со всеми необходимыми вам опциями.
Надеюсь, это поможет