Введение
kubectl — это инструмент командной строки, который вы будете использовать на протяжении всей работы с Kubernetes в стиле CKAD. Прежде чем создавать поды (Pods), развертывания (Deployments), сервисы (Services) или объекты конфигурации, необходимо понимать, к какому кластеру подключен kubectl и какое пространство имен (namespace) используется по умолчанию для ваших команд.
В этой лабораторной работе вы проверите активный контекст Kubernetes, выведете список пространств имен, установите рабочее пространство имен в качестве текущего и создадите небольшой объект ConfigMap, чтобы увидеть, как изолируются объекты в разных пространствах имен. Проверки ориентированы на ключевое состояние Kubernetes, которое вы создаете, а не на точное форматирование вывода команд.
Проверка доступа к kubectl
На этом этапе вы убедитесь, что kubectl может связаться с подготовленным кластером Kubernetes, и определите контекст, который используют ваши команды.
Начните работу в директории /home/labex/project. Команда mkdir -p создает директорию, если она отсутствует, и не выполняет никаких действий, если она уже существует. В этом курсе работы учащихся хранятся в этой директории, чтобы в последующих лабораторных работах можно было создавать манифесты и вспомогательные файлы в одном предсказуемом месте.
mkdir -p /home/labex/project
cd /home/labex/project
Контекст Kubernetes — это сохраненный вариант подключения в вашем файле kubeconfig. Он сообщает kubectl, какой кластер, учетные данные пользователя и пространство имен по умолчанию следует использовать. Проверяйте активный контекст перед выполнением любой команды, изменяющей объекты.
kubectl config current-context
Вы должны увидеть имя подготовленного профиля LabEx Kubernetes:
labex-v135
Для предсказуемой отправной точки установите пространство имен текущего контекста на default. Вы не создаете здесь объект; вы лишь сообщаете kubectl, какое пространство имен использовать, если в последующей команде не указан флаг --namespace.
kubectl config set-context --current --namespace=default
Вывод должен подтвердить, что текущий контекст был обновлен:
Context "labex-v135" modified.
Профилю Kubernetes может потребоваться немного времени для запуска после появления виртуальной машины. Сначала выведите список узлов кластера. Если эта команда сообщает, что API-сервер еще не готов, подождите несколько секунд и повторите команду, пока не увидите узел со статусом Ready.
kubectl get nodes --request-timeout=5s
Ожидаемый вывод будет включать готовый узел и версию Kubernetes:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Теперь запросите у API-сервера базовую информацию о кластере. Это доказывает, что ваш терминал не просто находит бинарный файл kubectl, но и успешно аутентифицирован в работающем кластере.
kubectl cluster-info
Вывод должен содержать адрес контрольной панели (control plane) Kubernetes:
Kubernetes control plane is running at ...
...
Чтение пространств имен
На этом этапе вы изучите пространства имен Kubernetes и проверите, какое из них используется в вашем текущем контексте по умолчанию.
Пространства имен — это способ разделения объектов Kubernetes на отдельные области видимости внутри одного кластера. Многие ресурсы приложений, такие как поды, развертывания, сервисы, секреты (Secrets) и ConfigMap, существуют строго в рамках одного пространства имен.
Выведите список пространств имен, которые уже существуют в кластере:
kubectl get namespaces
Вы должны увидеть системные пространства имен, такие как kube-system, и обычное пространство имен для приложений default:
NAME STATUS AGE
default Active ...
kube-system Active ...
...
Ваш контекст также может хранить пространство имен по умолчанию. Когда вы запускаете команду, требующую указания пространства имен, без флага --namespace, kubectl использует это значение по умолчанию. Опция --minify отображает только активный контекст, а выражение jsonpath выводит только поле namespace.
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Поскольку вы установили пространство имен контекста на предыдущем шаге, будет выведено default:
default
Вы всегда можете переопределить текущее пространство имен для одной команды с помощью --namespace. Например, проверьте поды в системном пространстве имен Kubernetes, не меняя контекст:
kubectl get pods --namespace kube-system
Точные имена подов могут отличаться, но команда должна вернуть системные поды, такие как CoreDNS, сетевые компоненты или компоненты хранилища:
NAME READY STATUS RESTARTS AGE
... ... ... ... ...
Выбор рабочего пространства имен
На этом этапе вы создадите пространство имен для этой лабораторной работы и сделаете его пространством имен по умолчанию для последующих команд.
Создайте пространство имен с именем ckad-prep-contexts. Имена пространств имен являются частью идентификации объекта: ConfigMap с именем app-settings в одном пространстве имен отличается от ConfigMap с таким же именем в другом.
kubectl create namespace ckad-prep-contexts
Команда создания должна подтвердить появление нового пространства имен:
namespace/ckad-prep-contexts created
Теперь обновите текущий контекст, чтобы команды без флага --namespace использовали ckad-prep-contexts. Опция --current означает «изменить контекст, который я использую сейчас», вместо того чтобы указывать имя контекста вручную.
kubectl config set-context --current --namespace=ckad-prep-contexts
Вывод подтверждает, что контекст был изменен:
Context "labex-v135" modified.
Снова проверьте пространство имен, сохраненное в активном контексте:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Теперь должно быть выведено:
ckad-prep-contexts
Запустите простой список подов без флага --namespace. Поскольку текущим пространством имен теперь является ckad-prep-contexts, эта команда выполнит поиск внутри вашего рабочего пространства имен. То, что оно пустое — это нормально.
kubectl get pods
Ожидаемый вывод:
No resources found in ckad-prep-contexts namespace.
Наблюдение за областью видимости пространств имен
На этом этапе вы создадите небольшой ConfigMap и используете его, чтобы увидеть, как текущее пространство имен влияет на поиск объектов.
ConfigMap хранит неконфиденциальные данные конфигурации для приложений. Он легкий, быстро создается и привязан к пространству имен, что делает его полезным для практики работы с пространствами имен перед развертыванием реальных приложений.
Создайте ConfigMap с именем app-settings без использования флага --namespace. Поскольку на предыдущем шаге вы выбрали ckad-prep-contexts, Kubernetes создаст его именно в этом пространстве имен.
kubectl create configmap app-settings --from-literal=mode=prep
Команда должна сообщить:
configmap/app-settings created
Выведите список ConfigMap без флага пространства имен. Будет использовано пространство имен текущего контекста.
kubectl get configmap app-settings
Ожидаемый вывод:
NAME DATA AGE
app-settings 1 ...
Теперь запросите тот же объект с явным указанием пространства имен. Это должно вернуть тот же ConfigMap, так как ckad-prep-contexts — это место, где вы его создали.
kubectl get configmap app-settings --namespace ckad-prep-contexts
Наконец, проверьте пространство имен default. Опция --ignore-not-found заставляет kubectl завершиться успешно и ничего не выводить, если объект не существует, что полезно для учебных лабораторных работ, так как отсутствие объекта здесь является ожидаемым результатом.
kubectl get configmap app-settings --namespace default --ignore-not-found
Отсутствие вывода означает, что ConfigMap не был создан в default. Теперь вы увидели практический эффект установки пространства имен в вашем текущем контексте.
Резюме
Вы подтвердили, что kubectl может связаться с подготовленным кластером Kubernetes, определили активный контекст, изучили существующие пространства имен, изменили пространство имен текущего контекста и создали ConfigMap, чтобы понаблюдать за областью видимости пространств имен. Эти основы являются фундаментом для последующих лабораторных работ по подготовке к CKAD, где вы будете создавать объекты приложений и должны будете точно знать, где именно создается и проверяется каждый объект.
