Помните, kubectl связывается с apis узлов и управляет узлами. Это происходит следующим образом: у него есть конфигурационный файл, в котором хранятся все IP-адреса API.
- Во-первых, теперь мы увидим наши узлы, используя
kubectl get node
Если он срабатывает, это означает, что ваша командная строка работает и вы получаете данные.
Вы можете даже использовать
kubectl get nodes
или,
kubectl get no
по вашему желанию.
Вы можете даже получить информацию об узле в кратком или широком формате с дополнительными сведениями
kubectl get nodes -o wide
Мы также можем проверить эту информацию в yaml
Он показывает всю информацию!!!!!!!!.
- Мы будем использовать команду describe, чтобы увидеть больше информации об узле
kubectl describe node <node>
Не копируйте команду. Первое использование
kubectl get node
и скопируйте полученное имя узла, а затем используйте его вместо команды Если
- Давайте проверим ресурсы, которые у нас есть
kubectl api-resources
Вы видите, что узел имеет вид «нет».
Помните, мы могли бы использовать
kubectl get no
вместо
kubectl get node
Итак, вот так эти ресурсы помогут вам понять и короткие форматы.
Теперь мы можем узнать гораздо больше о конкретном ресурсе, используя эту команду:
kubectl explain <type>
Вместо типа мы можем взять для примера «node»:
если мы хотим проверить спецификацию, мы можем набрать
kubectl explain node.spec
чтобы получить список всех полей и подполей:
kubectl explain node --recursive
Эта команда в основном показывает в формате списка.
Некоторые названия ресурсов следует уточнить:
Примечание: Вы можете использовать kubectl api-resources и explain, чтобы увидеть подробности о ресурсах или проверить из официальной документации.
Но вы должны уметь делать и то, и другое.
- Проверим сервисы (Сервис — это стабильная конечная точка для подключения к «чему-то»)
kubectl get services
или используйте,
kubectl get svc
Давайте проверим капсулы:
kubectl get pods
Ahha!!!!!!! Никаких капсул. Разве это не очевидно? Мы уже создали какие-нибудь контейнеры или капсулы?
НЕТ!!!
Так как же мы можем ожидать, что у нас будут стручки?
Но что такое «пространство имен по умолчанию»?
На самом деле команды, которые мы используем сейчас, используют «пространство имен» для фильтрации определенных вещей. Например, есть стручки, которые мы еще не создали, но мы не могли их увидеть при использовании команды «kubectl get pods», потому что пространство имен отфильтровало их для нас.
Давайте проверим, что есть в этом пространстве имен
Знаете что… Эта штука с kube-системой выглядит подозрительно.
На самом деле, я уверен, что она появилась раньше, когда мы это сделали:
kubectl describe node <node-name>
Итак, у нас есть капсулы.
Давайте проверим еще … что находится внутри пространства имен.
kubectl get pods --all-namespaces
или,
kubectl get pods -A
Этот вывод немного отличается от «kubernetes get namespace», верно?
Теперь мы можем увидеть статус и многое другое.
Вы можете увидеть coredns, узел, контроллер и т.д.
Итак, это, по сути, капсулы плоскости управления. Чтобы узнать о них больше, вы можете посмотреть это изображение:
Примечание: До сих пор мы проверяли пространства имен «по умолчанию». Мы можем изменить его на любое конкретное пространство имен. Чтобы перечислить только капсулы в пространстве имен kube-system, выполните следующие действия.
kubectl get pods --namespace=kube-system
kubectl get pods -n kube-system
Здесь -n используется для обозначения пространства имен.
Что еще нужно знать:
Некоторые другие основы:
kube-public: Используется для установки и последующего подключения к чему-либо.
Давайте проверим, что находится внутри него
kubectl -n kube-public get pods
Ничего нет, верно? Так для чего же это? На самом деле это помогает в настройке. В основном, это дает нам интересную информацию о том, как подключиться.
Давайте проверим файл конфигурации:
kubectl -n kube-public get configmaps
Мы можем проверить любой из них, добавив «имя файла -o yaml» в конце предыдущей команды. Здесь -o — это показать вывод
Вот и все для этого блога!