[DevOps, Kubernetes, Серверное администрирование, Системное администрирование] В Kubernetes 1.18 сломали «kubectl run». Что на замену? (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Если вы применяли в работе предыдущие выпуски Kubernetes — тот же 1.16 — вы, возможно, видели странное предупреждение от kubectl run.
До недавнего времени этой командой можно было сгенерировать объекты для развертывания или YAML из командной строки. Начиная с Kubernetes 1.18 такая возможность была сломана весьма удивительным образом. В статье будут ответы на вопросы "Почему?" и "Как дальше жить с этим?"
Прежде чем занырнуть поглубже в эти вопросы, вспомним, что есть три основных способа создания объектов для развертывания в Kubernetes:
- Через API (как это делает например OpenFaaS)
- Путем создания вручную файла YAML. Или более приближенно к реальность — копипасты в него откуда-то из разных сайтов (привет, StackOverflow)
- Запуская kubectl run или kubectl run -o yaml --dry-run
Как видно — я также перечислил варианты по порядку по сложности (от сложного до простого).
Сравнение вариантов
Первый случай, использование 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.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-1
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
Этот пример скопирован из документации к Kubernetes, а затем число реплик изменено с трех на одну. Лично мне не хотелось бы писать такое с нуля, хоть убейте.
Написание Kubernetes YAML напоминает мне задачу на собеседовании на листике с карандашом про переворачивание двойного связного списка, без ошибок и опечаток (сложно, но можно прим. переводчика).
Третий вариант до недавнего времени был весьма приятной альтернативой первому и второму вариантам:
- особенно для обучения;
- при необходимости написания коротких инструкций для демонстрации приложения;
- для создания YAML для дальнейшей настройки;
- использования в конвейерах CI\CD.
Например, для раскатки приложения в кластере с политикой перезапуска, именем, образом и портом можно сделать так:
$ kubectl run nginx-1 --image=nginx --port=80 --restart=Always
Если хотите лучше, можно смешать вариант два и три — выводим YAML без его применения, после чего ковыряем его. Давайте сравним то, что выводится командой и документацией?
$ kubectl run nginx-1 --image=nginx:1.14.2 --port=80 \
--restart=Always -o yaml --dry-run
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
run: nginx-1
name: nginx-1
spec:
replicas: 1
selector:
matchLabels:
run: nginx-1
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
run: nginx-1
spec:
containers:
- image: nginx:1.14.2
name: nginx-1
ports:
- containerPort: 80
resources: {}
Еще есть пара флагов, типа --replicas и --serviceaccount. Вывод не сильно отличается от документации.
Но причина написания этой статьи — вы больше не сможете так делать, поскольку эта функция удалена, начиная с Kubernetes версии 1.18 и более поздних выпусков.
Предупреждения
Я всегда был немного удивлён этой ошибкой, но в ней не было ни времени, ни другого контекста для помощи.
Как и вы, я подумал "ну допустим, в будущем я выучу альтернативную команду"
$ kubectl run nginx-1 --image=nginx --port=80 --restart=Always
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/nginx-1 created
Если вы скачаете kubectl 1.17 или более раннюю (я работаю 1.15 в этой статье), то вы все еще сможете разворачивать приложения или создавать YAML. Но как только вы обновитесь до Kubernetes 1.18 получится так:
kubectl run nginx-1 --image=nginx --port=80 --restart=Always -o yaml --dry-run
W0512 14:27:13.111424 30104 helpers.go:535] --dry-run is deprecated and can be replaced with --dry-run=client.
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx-1
name: nginx-1
spec:
containers:
- image: nginx
name: nginx-1
ports:
- containerPort: 80
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
Это Pod — не то же самое что Deployment. К счастью все еще можно указать service account и порт, но работать напрямую с подами не стоит, особенно на боевых серверах, поскольку они эфемерны, могут переехать на другой узел, быть убиты и не имеют (по умолчанию) стабильного имени или ip-адреса. Deployments и Services решают эту проблему.
Работать с подами можно, для одноразовых задач типа запуска curl для проверки api, или же для добавления сообщений в Kafka.
Мы с этим столкнулись в проекте inlets-operator, когда пользователь пожаловался, что примеры из документации не работают.
Мы хотели простейшую инструкцию для документации и для вспомогательного сообщения helm chart, которая помогла бы пользователям понять, как пользоваться проектом. Вы создаете Deployment, затем открываете доступ извне через LoadBalancer, мы создаем VM в вашем любимом облаке, создаем обратный туннель, так что вы в результате имеете полностью внедренный белый ip-адрес.
Наша старая документация выглядела так:
kubectl run nginx-1 --image=nginx --port=80 --restart=Always
kubectl expose deployment nginx-1 --port=80 --type=LoadBalancer
Новая так:
export DEPLOYMENT=nginx-1
(cat<<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: $DEPLOYMENT
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
EOF
) | kubectl apply -f -
kubectl expose deployment nginx-1 --port=80 --type=LoadBalancer
Просьба к разработчикам Kubernetes, пожалуйста не отбирайте у нас команду kubectl expose ;-)
Жду с нетерпением сохранения текстов такого же объема во всех моих руководствах, а также начинаю привыкать писать простыни для Deployment. Я был настолько недоволен полученным руководством, что поместил его в отдельный файл, который надо будет скачать всем желающим для проверки перед запуском кластера:
$ kubectl apply -f https://raw.githubusercontent.com/inlets/inlets-operator/master/contrib/nginx-sample-deployment.yaml
Люди, никогда не делайте kubectl apply -f файлов из интернета без их предварительной проверки.
Что делать?
Оказывается, нет никакой полноценной альтернативы. Некоторые считают, что новая команда это kubectl create deployment.
Самые внимательные уже заметили, что все важные опции отсутствуют, к примеру --port, --serviceaccount, --replicas и --restart-policy.
kubectl create deployment --help
Create a deployment with the specified name.
Aliases:
deployment, deploy
Examples:
# Create a new deployment named my-dep that runs the busybox image.
kubectl create deployment my-dep --image=busybox
Options:
--allow-missing-template-keys=true: If true, ignore any errors in templates when a field or map key is missing in
the template. Only applies to golang and jsonpath output formats.
--dry-run='none': Must be "none", "server", or "client". If client strategy, only print the object that would be
sent, without sending it. If server strategy, submit server-side request without persisting the resource.
--image=[]: Image name to run.
-o, --output='': Output format. One of:
json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-file.
--save-config=false: If true, the configuration of current object will be saved in its annotation. Otherwise, the
annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future.
--template='': Template string or path to template file to use when -o=go-template, -o=go-template-file. The
template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].
--validate=true: If true, use a schema to validate the input before sending it
Usage:
kubectl create deployment NAME --image=image [--dry-run=server|client|none] [options]
Use "kubectl options" for a list of global command-line options (applies to all commands).
Так что наш изначальный пример не будет больше работать с kubectl create, а также не может быть применен иначе, как блок YAML. Если нужен динамический порт — есть вариант с шаблонами на bash, что однако не кроссплатформенно.
Лучшее что можно сделать с новой командой — это очередной поиск по StackOverflow или документации Kubernetes каждый раз для простого Deployment. Почему? Потому что вложенные схемы на YAML сложно запоминать.
$ kubectl create deployment nginx-1 --image=nginx -o yaml --dry-run
W0512 14:38:18.296270 30135 helpers.go:535] --dry-run is deprecated and can be replaced with --dry-run=client.
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: nginx-1
name: nginx-1
spec:
replicas: 1
selector:
matchLabels:
app: nginx-1
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: nginx-1
spec:
containers:
- image: nginx
name: nginx
resources: {}
Обратите внимание, что нет порта, restartPolicy и других вещей.
Какие выводы?
Хотел бы я ошибаться, но чаще всего благими намерениями вымощена дорога в ад, а решение проблем с техническим долгом может привести к ухудшению положения пользователей, несмотря на то, что намерения изначально были ради улучшения.
Запрос на слияние 68132 внес все это, желая приблизить поведение kubectl run к docker run. Вообще неплохая задумка.
Я надеялся, что разработчики Kubernetes рассмотрят вопрос о добавлении различных отсутствующих флагов и опций в новую команду kubectl create deployment, однако первому же человеку, пожелавшему такое, сказали "хочешь — пиши свой PR".
Вас это тоже затронуло? Пишите в Twitter, или комментируйте запрос, в котором будут изменения.
Трудно сделать что-то лучше, особенно если это ломает пользовательский опыт, однако это у вас, авторов Kubernetes, "получилось". И получилось просто "идеально".
Полный список изменений в 1.18.
Статья переведена и подготовлена для Хабра сотрудниками обучающего центра Слёрм — интенсивы, видеокурсы и корпоративное обучение от практикующих специалистов (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)
===========
Источник:
habr.com
===========
===========
Автор оригинала: Alex Ellis
===========Похожие новости:
- [Python, Программирование] Создание нейросети по распознаванию лиц на фотографиях из Вконтакте
- [Big Data, SQL, Высокая производительность, Системное администрирование, Хранилища данных] Benchmark ClickHouse Database and clickhousedb_fdw (PostgreSQL) (перевод)
- [API, C, Параллельное программирование, Программирование] Реализуем простые кооперативные потоки на C (перевод)
- [API, Google API, Здоровье, Информационная безопасность] Google заподозрили в сборе геоданных через приложения для отслеживания контактов больных COVID
- [Информационная безопасность, Сетевые технологии, Системное администрирование] 1. Check Point SandBlast Agent Management Platform
- [IT-инфраструктура, Информационная безопасность, Системное администрирование] OpenVPN с двухуровневой иерархией ЦС
- [Финансы в IT] Разбор: почему акции AMD выросли почти на 2000% за пять лет, и каковы их перспективы
- [API, Python, Анализ и проектирование систем, Программирование] Между дизайн-системой и Server Driven UI
- [PHP, Системное администрирование] Apache & Nginx. Связаны одной цепью (2 часть)
- [JavaScript, Программирование, Разработка веб-сайтов] Работа с файлами в JavaScript
Теги для поиска: #_devops, #_kubernetes, #_servernoe_administrirovanie (Серверное администрирование), #_sistemnoe_administrirovanie (Системное администрирование), #_kubernetes, #_k8s, #_versija_1.16_k8s (версия 1.16 K8s), #_versija_1.18_k8s (версия 1.18 K8s), #_kubectl_run, #_hoteli_kak_luchshe (хотели как лучше), #_api, #_rabotaet__ne_trogaj (работает - не трогай), #_blagimi_namerenijami (благими намерениями), #_blog_kompanii_southbridge (
Блог компании Southbridge
), #_devops, #_kubernetes, #_servernoe_administrirovanie (
Серверное администрирование
), #_sistemnoe_administrirovanie (
Системное администрирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:49
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Если вы применяли в работе предыдущие выпуски 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. apiVersion: apps/v1
kind: Deployment metadata: name: nginx-1 labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 Этот пример скопирован из документации к Kubernetes, а затем число реплик изменено с трех на одну. Лично мне не хотелось бы писать такое с нуля, хоть убейте. Написание Kubernetes YAML напоминает мне задачу на собеседовании на листике с карандашом про переворачивание двойного связного списка, без ошибок и опечаток (сложно, но можно прим. переводчика).
Например, для раскатки приложения в кластере с политикой перезапуска, именем, образом и портом можно сделать так: $ kubectl run nginx-1 --image=nginx --port=80 --restart=Always
Если хотите лучше, можно смешать вариант два и три — выводим YAML без его применения, после чего ковыряем его. Давайте сравним то, что выводится командой и документацией? $ kubectl run nginx-1 --image=nginx:1.14.2 --port=80 \
--restart=Always -o yaml --dry-run apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: run: nginx-1 name: nginx-1 spec: replicas: 1 selector: matchLabels: run: nginx-1 strategy: {} template: metadata: creationTimestamp: null labels: run: nginx-1 spec: containers: - image: nginx:1.14.2 name: nginx-1 ports: - containerPort: 80 resources: {} Еще есть пара флагов, типа --replicas и --serviceaccount. Вывод не сильно отличается от документации. Но причина написания этой статьи — вы больше не сможете так делать, поскольку эта функция удалена, начиная с Kubernetes версии 1.18 и более поздних выпусков. Предупреждения Я всегда был немного удивлён этой ошибкой, но в ней не было ни времени, ни другого контекста для помощи. Как и вы, я подумал "ну допустим, в будущем я выучу альтернативную команду"
$ kubectl run nginx-1 --image=nginx --port=80 --restart=Always
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead. deployment.apps/nginx-1 created Если вы скачаете kubectl 1.17 или более раннюю (я работаю 1.15 в этой статье), то вы все еще сможете разворачивать приложения или создавать YAML. Но как только вы обновитесь до Kubernetes 1.18 получится так: kubectl run nginx-1 --image=nginx --port=80 --restart=Always -o yaml --dry-run
W0512 14:27:13.111424 30104 helpers.go:535] --dry-run is deprecated and can be replaced with --dry-run=client. apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: nginx-1 name: nginx-1 spec: containers: - image: nginx name: nginx-1 ports: - containerPort: 80 resources: {} dnsPolicy: ClusterFirst restartPolicy: Always Это Pod — не то же самое что Deployment. К счастью все еще можно указать service account и порт, но работать напрямую с подами не стоит, особенно на боевых серверах, поскольку они эфемерны, могут переехать на другой узел, быть убиты и не имеют (по умолчанию) стабильного имени или ip-адреса. Deployments и Services решают эту проблему. Работать с подами можно, для одноразовых задач типа запуска curl для проверки api, или же для добавления сообщений в Kafka. Мы с этим столкнулись в проекте inlets-operator, когда пользователь пожаловался, что примеры из документации не работают. Мы хотели простейшую инструкцию для документации и для вспомогательного сообщения helm chart, которая помогла бы пользователям понять, как пользоваться проектом. Вы создаете Deployment, затем открываете доступ извне через LoadBalancer, мы создаем VM в вашем любимом облаке, создаем обратный туннель, так что вы в результате имеете полностью внедренный белый ip-адрес. Наша старая документация выглядела так: kubectl run nginx-1 --image=nginx --port=80 --restart=Always
kubectl expose deployment nginx-1 --port=80 --type=LoadBalancer Новая так: export DEPLOYMENT=nginx-1
(cat<<EOF apiVersion: apps/v1 kind: Deployment metadata: name: $DEPLOYMENT labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 EOF ) | kubectl apply -f - kubectl expose deployment nginx-1 --port=80 --type=LoadBalancer Просьба к разработчикам Kubernetes, пожалуйста не отбирайте у нас команду kubectl expose ;-)
$ kubectl apply -f https://raw.githubusercontent.com/inlets/inlets-operator/master/contrib/nginx-sample-deployment.yaml
Люди, никогда не делайте kubectl apply -f файлов из интернета без их предварительной проверки. Что делать? Оказывается, нет никакой полноценной альтернативы. Некоторые считают, что новая команда это kubectl create deployment. Самые внимательные уже заметили, что все важные опции отсутствуют, к примеру --port, --serviceaccount, --replicas и --restart-policy.
kubectl create deployment --help
Create a deployment with the specified name. Aliases: deployment, deploy Examples: # Create a new deployment named my-dep that runs the busybox image. kubectl create deployment my-dep --image=busybox Options: --allow-missing-template-keys=true: If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. --dry-run='none': Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. --image=[]: Image name to run. -o, --output='': Output format. One of: json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-file. --save-config=false: If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. --template='': Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview]. --validate=true: If true, use a schema to validate the input before sending it Usage: kubectl create deployment NAME --image=image [--dry-run=server|client|none] [options] Use "kubectl options" for a list of global command-line options (applies to all commands). Так что наш изначальный пример не будет больше работать с kubectl create, а также не может быть применен иначе, как блок YAML. Если нужен динамический порт — есть вариант с шаблонами на bash, что однако не кроссплатформенно. Лучшее что можно сделать с новой командой — это очередной поиск по StackOverflow или документации Kubernetes каждый раз для простого Deployment. Почему? Потому что вложенные схемы на YAML сложно запоминать. $ kubectl create deployment nginx-1 --image=nginx -o yaml --dry-run
W0512 14:38:18.296270 30135 helpers.go:535] --dry-run is deprecated and can be replaced with --dry-run=client. apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: nginx-1 name: nginx-1 spec: replicas: 1 selector: matchLabels: app: nginx-1 strategy: {} template: metadata: creationTimestamp: null labels: app: nginx-1 spec: containers: - image: nginx name: nginx resources: {} Обратите внимание, что нет порта, restartPolicy и других вещей.
Какие выводы? Хотел бы я ошибаться, но чаще всего благими намерениями вымощена дорога в ад, а решение проблем с техническим долгом может привести к ухудшению положения пользователей, несмотря на то, что намерения изначально были ради улучшения. Запрос на слияние 68132 внес все это, желая приблизить поведение kubectl run к docker run. Вообще неплохая задумка. Я надеялся, что разработчики Kubernetes рассмотрят вопрос о добавлении различных отсутствующих флагов и опций в новую команду kubectl create deployment, однако первому же человеку, пожелавшему такое, сказали "хочешь — пиши свой PR". Вас это тоже затронуло? Пишите в Twitter, или комментируйте запрос, в котором будут изменения. Трудно сделать что-то лучше, особенно если это ломает пользовательский опыт, однако это у вас, авторов Kubernetes, "получилось". И получилось просто "идеально". Полный список изменений в 1.18. Статья переведена и подготовлена для Хабра сотрудниками обучающего центра Слёрм — интенсивы, видеокурсы и корпоративное обучение от практикующих специалистов (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE) =========== Источник: habr.com =========== =========== Автор оригинала: Alex Ellis ===========Похожие новости:
Блог компании Southbridge ), #_devops, #_kubernetes, #_servernoe_administrirovanie ( Серверное администрирование ), #_sistemnoe_administrirovanie ( Системное администрирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:49
Часовой пояс: UTC + 5