Если вы применяли в работе предыдущие выпуски Kubernetes — тот же 1.16 — вы, возможно, видели странное предупреждение от kubectl run.  До недавнего времени этой командой можно было сгенерировать объекты для развертывания или YAML из командной строки. Начиная с Kubernetes 1.18 такая возможность была сломана весьма удивительным образом. В статье будут ответы на вопросы «Почему?» и «Как дальше с этим жить?»  Прежде чем занырнуть поглубже в эти вопросы, вспомним, что есть три основных способа создания объектов для развертывания в Kubernetes: Как видно — я также перечислил варианты по порядку по сложности (от сложного до простого). Первый случай, использование API — возможно наиболее стабильный путь для развертывания, но и наиболее сложный в реализации. До недавнего времени API был относительно стабильным в «extensions/v1beta», пока не перешел в «apps/v1», это было достаточно большое изменение и многие проекты с открытым исходным кодом должны были переработать свой код и файлы YAML. Я не уверен, что сложнее — создавать объекты в Go или YAML. С Go вы получаете возможность подсказок IDE, но нужно искать описание пакетов, где и в каком из них требуемый тип. Core? Meta? Apps? Extensions? Может быть это то, что мы упускаем при редактировании манифестов — старый добрый Intellisense? 
Кусочек кода из контроллера OpenFaaS для Kubernetes (aka faas-netes) Второй вариант — создание YAML вручную. Если пользовались Twitter или смотрели по хэштегу #kubernetes, то могли видеть еще и то, что все, от новичков, уважаемых авторов и до основателей Kubernetes, ругаются на то, как трудно писать и понимать YAML.  Лично мне он нравится, и я считаю, что его легче всего применять, но я-то понимаю, что к чему с жалобами. Я предполагаю, что они на самом деле жалуются на сложную и вложенную структуру схемы API Kubernetes. Этот пример скопирован из документации к Kubernetes, а затем число реплик изменено с трех на одну. Лично мне не хотелось бы писать такое с нуля, хоть убейте. Третий вариант до недавнего времени был весьма приятной альтернативой первому и второму вариантам: Например, для раскатки приложения в кластере с политикой перезапуска, именем, образом и портом можно сделать так: Если хотите лучше, можно смешать вариант два и три — выводим YAML без его применения, после чего ковыряем его. Давайте сравним то, что выводится командой и документацией? Еще есть пара флагов, типа --replicas и --serviceaccount. Вывод не сильно отличается от документации.  Но причина написания этой статьи — вы больше не сможете так делать, поскольку эта функция удалена, начиная с Kubernetes версии 1.18 и более поздних выпусков. Я всегда был немного удивлён этой ошибкой, но в ней не было ни времени, ни другого контекста для помощи. Если вы скачаете kubectl 1.17 или более раннюю (я работаю 1.15 в этой статье), то вы все еще сможете разворачивать приложения или создавать YAML. Но как только вы обновитесь до Kubernetes 1.18 получится так: Это Pod — не то же самое что Deployment. К счастью все еще можно указать service account и порт, но работать напрямую с подами не стоит, особенно на боевых серверах, поскольку они эфемерны, могут переехать на другой узел, быть убиты и не имеют (по умолчанию) стабильного имени или ip-адреса. Deployments и Services решают эту проблему. Работать с подами можно, для одноразовых задач типа запуска curl для проверки api, или же для добавления сообщений в Kafka. Мы с этим столкнулись в проекте inlets-operator, когда пользователь пожаловался, что примеры из документации не работают.  Мы хотели простейшую инструкцию для документации и для вспомогательного сообщения helm chart, которая помогла бы пользователям понять, как пользоваться проектом. Вы создаете Deployment, затем открываете доступ извне через LoadBalancer, мы создаем VM в вашем любимом облаке, создаем обратный туннель, так что вы в результате имеете полностью внедренный белый ip-адрес. Наша старая документация выглядела так: Новая так: Жду с нетерпением сохранения текстов такого же объема во всех моих руководствах, а также начинаю привыкать писать простыни для Deployment. Я был настолько недоволен полученным руководством, что поместил его в отдельный файл, который надо будет скачать всем желающим для проверки перед запуском кластера: Люди, никогда не делайте kubectl apply -f файлов из интернета без их предварительной проверки. Оказывается, нет никакой полноценной альтернативы. Некоторые считают, что новая команда это kubectl create deployment. Так что наш изначальный пример не будет больше работать с kubectl create, а также не может быть применен иначе, как блок YAML. Если нужен динамический порт — есть вариант с шаблонами на bash, что однако не кроссплатформенно. Лучшее что можно сделать с новой командой — это очередной поиск по StackOverflow или документации Kubernetes каждый раз для простого Deployment. Почему? Потому что вложенные схемы на YAML сложно запоминать. Хотел бы я ошибаться, но чаще всего благими намерениями вымощена дорога в ад, а решение проблем с техническим долгом может привести к ухудшению положения пользователей, несмотря на то, что намерения изначально были ради улучшения. Pull request 68132 внес все это, желая приблизить поведение kubectl run к docker run. Вообще неплохая задумка. Я надеялся, что разработчики Kubernetes рассмотрят вопрос о добавлении различных отсутствующих флагов и опций в новую команду kubectl create deployment, однако первому же человеку, пожелавшему такое, сказали: «хочешь — пиши свой PR».  Вас это тоже затронуло? Пишите в Twitter, или комментируйте запрос, в котором будут изменения. Трудно сделать что-то лучше, особенно если это ломает пользовательский опыт, однако это у вас, авторов Kubernetes, «получилось». И вышло просто «идеально».  Полный список изменений в 1.18. Статья переведена и подготовлена для Хабра сотрудниками обучающего центра Слёрм — интенсивы, видеокурсы и корпоративное обучение от практикующих специалистов (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE) Подниматель пингвинов