Введение
Объект ConfigMap позволяет хранить неконфиденциальные параметры настройки отдельно от образа контейнера. Это дает возможность использовать один и тот же образ приложения с разными настройками, такими как режим разработки (development mode), уровень логирования, переключатели функций (feature flags) или имена конечных точек (endpoints).
В этой лабораторной работе вы создадите ConfigMap, изучите его содержимое, используете его для настройки пода, обновите ConfigMap и пересоздадите под, чтобы он получил новые значения. В последующих лабораторных работах мы подробнее рассмотрим передачу переменных окружения и монтирование файлов конфигурации; данная работа сфокусирована на объекте ConfigMap и базовом рабочем процессе настройки приложений.
Подготовка пространства имен для ConfigMap
На этом этапе вы подготовите чистое пространство имен (namespace) для практики работы с ConfigMap.
Начните работу в директории /home/labex/project. В этой директории вы создадите манифест пода.
mkdir -p /home/labex/project
cd /home/labex/project
Проверьте доступность API-сервера Kubernetes. Если виртуальная машина только что запустилась и узел еще не готов, подождите несколько секунд и повторите команду.
kubectl get nodes --request-timeout=5s
Ожидаемый вывод:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Дождитесь готовности пода сетевого плагина кластера перед созданием объектов приложения.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Ожидаемый вывод:
pod/calico-node-... condition met
Создайте пространство имен с именем ckad-prep-configmaps:
kubectl create namespace ckad-prep-configmaps
Установите это пространство имен в качестве текущего контекста:
kubectl config set-context --current --namespace=ckad-prep-configmaps
Проверьте текущее пространство имен:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Ожидаемый вывод:
ckad-prep-configmaps
Создание и проверка ConfigMap
На этом этапе вы создадите ConfigMap, содержащий простые настройки приложения.
Команда kubectl create configmap позволяет создать ConfigMap напрямую из литеральных пар ключ-значение. Каждый флаг --from-literal добавляет одну запись в поле data объекта ConfigMap.
kubectl create configmap app-settings \
--from-literal=APP_MODE=dev \
--from-literal=LOG_LEVEL=debug \
--from-literal=FEATURE_BANNER=enabled
Ожидаемый вывод:
configmap/app-settings created
Просмотрите сводную информацию о ConfigMap:
kubectl get configmap app-settings
Ожидаемый вывод:
NAME DATA AGE
app-settings 3 ...
Прочитайте сохраненные значения. Параметр jsonpath позволяет вывести выбранные поля, не отображая весь объект целиком.
kubectl get configmap app-settings -o 'jsonpath={.data.APP_MODE}{" "}{.data.LOG_LEVEL}{" "}{.data.FEATURE_BANNER}{"\n"}'
Ожидаемый вывод:
dev debug enabled
Вы также можете просмотреть ConfigMap в формате YAML, чтобы увидеть, где именно ключи расположены внутри объекта.
kubectl get configmap app-settings -o yaml
Ожидаемый вывод:
data:
APP_MODE: dev
FEATURE_BANNER: enabled
LOG_LEVEL: debug
Настройка пода с использованием ConfigMap
На этом этапе вы запустите под, который считывает значения из ConfigMap в качестве переменных окружения.
Поле envFrom.configMapRef импортирует все ключи из ConfigMap в окружение контейнера. Это компактный способ подключения небольшого набора неконфиденциальных настроек к приложению.
Создайте файл config-reader-pod.yaml:
cat > config-reader-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: config-reader
labels:
app: config-reader
spec:
terminationGracePeriodSeconds: 0
containers:
- name: reader
image: busybox:1.36
command:
- /bin/sh
- -c
- 'echo mode=${APP_MODE}; echo level=${LOG_LEVEL}; echo banner=${FEATURE_BANNER}; sleep 3600'
envFrom:
- configMapRef:
name: app-settings
EOF
Примените манифест пода:
kubectl apply -f config-reader-pod.yaml
Ожидаемый вывод:
pod/config-reader created
Дождитесь готовности пода:
kubectl wait --for=condition=Ready pod/config-reader --timeout=120s
Ожидаемый вывод:
pod/config-reader condition met
Прочитайте логи пода. Приложение выводит значения, полученные из ConfigMap.
kubectl logs config-reader -c reader
Ожидаемый вывод:
mode=dev
level=debug
banner=enabled
Обновление ConfigMap и пересоздание пода
На этом этапе вы обновите ConfigMap и пересоздадите под, чтобы контейнер получил новые значения.
Когда ConfigMap используется в качестве переменных окружения, запущенный контейнер не обновляет свое окружение автоматически. Чтобы считать обновленные значения, необходимо запустить новый контейнер. Это важная деталь для экзамена CKAD, так как вам может потребоваться обновить конфигурацию, а затем перезапустить или пересоздать рабочую нагрузку.
Обновите ConfigMap с помощью патча:
kubectl patch configmap app-settings --type merge --patch '{"data":{"APP_MODE":"prod","LOG_LEVEL":"warn","FEATURE_BANNER":"disabled"}}'
Ожидаемый вывод:
configmap/app-settings patched
Проверьте новые значения в ConfigMap:
kubectl get configmap app-settings -o 'jsonpath={.data.APP_MODE}{" "}{.data.LOG_LEVEL}{" "}{.data.FEATURE_BANNER}{"\n"}'
Ожидаемый вывод:
prod warn disabled
Удалите старый под:
kubectl delete pod config-reader
Ожидаемый вывод:
pod "config-reader" deleted
Пересоздайте под из того же манифеста и дождитесь его готовности:
kubectl apply -f config-reader-pod.yaml
kubectl wait --for=condition=Ready pod/config-reader --timeout=120s
Ожидаемый вывод:
pod/config-reader created
pod/config-reader condition met
Снова прочитайте логи. Теперь новый под видит обновленные значения из ConfigMap.
kubectl logs config-reader -c reader
Ожидаемый вывод:
mode=prod
level=warn
banner=disabled
Резюме
Вы создали ConfigMap, изучили его данные, подключили его к поду приложения, обновили ConfigMap и пересоздали под, чтобы контейнер применил новые значения. Это дает вам базовое понимание рабочего процесса с ConfigMap перед переходом к более сложным методам использования переменных окружения и монтирования файлов в следующих лабораторных работах.
