Может ли somene объяснить различные файлы и типы yaml Kubernetes?

Question

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

Я пытаюсь выясните, сколько типов «файлов развертывания» существует для Kubernetes. Я называю их «файлами развертывания», потому что я действительно не знаю, как их еще называть, и они обычно связаны с развертыванием.

До сих пор каждый файл yml / yaml, который я видел, начинался так :

apiVersion:
kind: << this is what I'm asking about >>
metadata:

И до сих пор я видел это множество "видов"

ClusterConfig
ClusterRole
ClusterRoleBinding
CronJob
Deployment
Job
PersistentVolumeClaim
Pod
ReplicationController
Role
RoleBinding
Secret
Service
ServiceAccount

Я уверен, что есть еще много. Но я не могу найти место, где они перечислены и контексты разбиты.

Итак, я хочу знать следующее:

1. Где найти объяснение для этих файлов yaml?
2. Где я могу узнать о различных видах?
3. Где можно получить подробное объяснение минимальных обязательных полей / значений для любого из них?
4. Есть ли шаблоны для этих файлов?

Спасибо

Answer 1

На этот вопрос потребуется блог, чтобы ответить, но вкратце вы можете попробовать эти опции и команду, чтобы поучиться у своего kubectl CLI.

Научиться использовать команду kubectl объяснять , которая показывает вам список объектов Kubernetes:

$ kubectl explain

Вы можете получить подробную информацию о любом из перечисленных ресурсов, используя этот синтаксис

`$ kubectl объяснение pod

$ kubectl объяснение pod.spe c

$ kubectl объяснение pod.spe c .containers`

Или вы можете получить шаблон объекта yam, добавив флаг --recursive к Команда объяснения.

$ kubectl explain pod --recursive

Это также даст вам официальную ссылку на документ.

Так что в краткосрочной перспективе kubectl объяснение с рекурсивной опцией перечислит все вещи .

Answer 2

Когда вы говорите об указанном c файле yaml, содержащем определение объекта c kubernetes, вы можете назвать их yaml manifests или просто yaml definition files. Использование слова Deployment для всех из них не очень хорошая идея, поскольку уже указан c тип ресурса, определенный и названный этим именем в kubernetes . Так что лучше не называть их всех deployments для согласованности.

Я уверен, что есть еще много. Но я не могу найти место, где они перечислены и контексты разбиты.

Да, их намного больше, и вы можете перечислить те, которые доступны, запустив:

kubectl api-resources

Эти разные объекты на самом деле называются api-resources. Как вы можете видеть, они перечислены в трех столбцах: NAME, SHORTNAMES, APIGROUP, NAMESPACED и KIND

NAME                                       SHORTNAMES   APIGROUP                       NAMESPACED   KIND
bindings                                                                               true         Binding
componentstatuses                          cs                                          false        ComponentStatus
configmaps                                 cm                                          true         ConfigMap
endpoints                                  ep                                          true         Endpoints
events                                     ev                                          true         Event
limitranges                                limits                                      true         LimitRange
namespaces                                 ns                                          false        Namespace
nodes                                      no                                          false        Node

Обратите внимание, что имя ресурса соответствует его KIND, но оно немного отличается. NAME просто описывает типы ресурсов, так как мы ссылаемся на них, например, используя kubectl command line utility. Просто в качестве одного примера, когда вы хотите перечислить модули, доступные в вашем кластере, вы просто набираете kubectl get pods. Вам не нужно использовать вид ресурса, то есть Pod в этом контексте. Вы можете, но не обязаны. Так что kubectl get Pod или kubectl get ConfigMap также вернет желаемый результат. Вы также можете ссылаться на них по их псевдонимам, так что kubectl get daemonsets и kubectl get ds эквивалентны.

Это совершенно другое, когда речь идет о конкретном c определении ресурса / объекта. В контексте файла yaml definition мы должны использовать правильный KIND ресурса. Они в большинстве случаев начинаются с заглавной буквы и пишутся с помощью co. CamelCase, но есть исключения из этого правила.

Я действительно рекомендую вам ознакомиться с документацией kubernetes. Он очень удобен для пользователя и хорошо объясняет как ключевые понятия kubernetes, так и все очень мелкие детали.

Здесь у вас есть еще более полезные команды для изучения ресурсов API:

kubectl api-resources --namespaced=true      # All namespaced resources
kubectl api-resources --namespaced=false     # All non-namespaced resources
kubectl api-resources -o name                # All resources with simple output (just the resource name)
kubectl api-resources -o wide                # All resources with expanded (aka "wide") output
kubectl api-resources --verbs=list,get       # All resources that support the "list" and "get" request verbs
kubectl api-resources --api-group=extensions # All resources in the "extensions" API group

Как уже упоминал @wargre в своем комментарии, официальное документирование kubernetes - определенно лучшее место для начала, поскольку вы найдете там очень подробное описание каждого ресурса.

Answer 3

Понимание объектов Kubernetes

Вы можете начать с прочтения этой статьи: Понимание объектов Kubernetes

Объекты Kubernetes являются постоянными объектами в система Кубернетеса. Kubernetes использует эти объекты для представления состояния вашего кластера. В частности, они могут описывать:

• Какие приложения в контейнерах запущены (и на каких узлах)
• Ресурсы, доступные этим приложениям
• Политики в отношении того, как эти приложения поведение, такое как политики перезапуска, обновления и отказоустойчивость

Объект Kubernetes - это «запись намерений» - как только вы создаете объект, система Kubernetes будет постоянно работать, чтобы гарантировать, что объект существует , Создавая объект, вы фактически сообщаете системе Kubernetes, какой должна быть рабочая нагрузка вашего кластера; это желаемое состояние вашего кластера .

Справочник по API K8s

Подробное описание всех объектов можно найти в Kubernetes API справочник.