Введение
Orchard Market нужна небольшая панель состояния приложений торговых точек и доставки. Программа панели готова, но её текущая идентичность Kubernetes не может читать их Deployment. Предоставьте панели собственную идентичность и только те разрешения, которые нужны для показа настоящего желаемого числа реплик, доступных реплик и образов шаблонов. Оставьте пространство имён сотрудников, Secret и изменения нагрузки за пределами её доступа.
Ваш результат — пригодная к использованию панель и выгрузка CSV, а также четыре сохранённых манифеста, описывающих её идентичность, разрешения в двух пространствах имён и выбор идентичности нагрузки. Панель выполняет настоящие HTTPS-запросы к подготовленному кластеру. У неё нет статических успешных данных для подстановки при отказе доступа.
Вы уже должны знать базовые пути терминала, простой YAML, пространства имён, Pod, Deployment, Service и метки. Эта работа объясняет ServiceAccount, Role, RoleBinding и предоставленный клиент до их использования. Настоящий одноузловой кластер Kubernetes, панель, синтетические данные приложений и диагностический инструмент подготовлены. Вы не устанавливаете кластер, не собираете образ, не программируете клиент и не копируете токены. Продолжительность — авторская оценка, включающая чтение и обычные ошибки, а не измеренное время выполнения начинающими.
Создайте отдельную идентичность панели
На этом шаге вы прочитаете фактическую начальную идентичность панели и сохраните отдельный ServiceAccount, пока не предоставляя ему доступа к приложениям.
Начните на вкладке Board. Orchard Market должен показывать A clear view of the working day., группы Market stalls и Market delivery, а также Access denied · API 403 для обеих групп. Это ожидаемая исходная проблема. Полный результат покажет catalogue с 2 желаемыми и 2 доступными репликами, checkout с 1 и 1, pickup с 1 и 1 и receipts с 0 и 0. Все четыре используют подготовленный образ шаблона python:3.12-alpine. Архив чеков намеренно масштабирован до нуля.
Три основных поля отвечают на разные вопросы. Desired replicas — объявленное число в Deployment. Available replicas — число, сообщаемое контроллером после проверки готовности и минимального периода готовности. Template image — образ, запрошенный шаблоном Deployment; во время обновления он не доказывает, что каждый существующий Pod уже использует этот образ. Разверните What these fields mean, прочитайте и снова сверните. Это наблюдения контроллера, а не проверки непрерывной работы сайта для покупателей.
Выберите Access details. Значение Read as приходит от API и вначале заканчивается на market-board:default. Таблица указывает предполагаемую область разрешений; она не утверждает, что доступ уже предоставлен. Используйте Back to status board, затем переключитесь на Workspace.
Терминал запускается в /home/labex/project/status-board. pwd выводит рабочий каталог, ls перечисляет его содержимое, а cd с абсолютным путём возвращает сюда, если вы меняли каталог:
pwd
ls
cd /home/labex/project/status-board
Ожидаются scope.json, starter и tools. cat показывает подготовленный файл области работы. Он использует JSON (JavaScript Object Notation) — текстовый формат именованных значений и списков — для записи настоящих пространств имён, идентичности и имён приложений:
cat scope.json
Панель работает в market-board, а утверждённые данные приложений находятся в market-stalls и market-delivery. market-office исключён. --context=labex-v135 выбирает подготовленный кластер; -n выбирает пространство имён. Существующие учётные данные оператора Workspace позволяют изучать и настраивать эти объекты курса. Это не учётные данные панели. Изучите настоящие целевые Deployment от имени этого оператора:
kubectl --context=labex-v135 get deployments -n market-stalls
kubectl --context=labex-v135 get deployments -n market-delivery
Прочитайте имена и результаты желаемого/доступного числа реплик, включая архив чеков с нулевым желаемым числом. Объекты существуют, хотя панель не может их читать. Успех в терминале оператора не доказывает доступ для процесса внутри Pod панели.
ServiceAccount — идентичность API Kubernetes для нагрузки в определённом пространстве имён, а не пользователь Linux или посетитель браузера. Подготовленный Deployment панели вначале выбирает ServiceAccount default. describe представляет конфигурацию объекта в читаемых разделах:
kubectl --context=labex-v135 describe deployment status-board -n market-board
Найдите выбранный ServiceAccount в его шаблоне Pod. Pod получает проецируемые учётные данные этой учётной записи. Подготовленный клиент читает их внутри и проверяет сертификат сервера API с помощью предоставленного центра сертификации; он никогда не выводит учётные данные и не использует kubeconfig оператора. Вы настраиваете идентичность и разрешения, а не реализуете обработку учётных данных.
Предоставленный ./tools/board-test запускает этот клиент внутри текущего Pod панели. Начальное ./ означает, что инструмент находится в этом рабочем каталоге. Первый аргумент выбирает изучаемую диагностическую операцию. identity спрашивает API, как он аутентифицировал эти фактические учётные данные:
./tools/board-test identity
Ожидается username, равный system:serviceaccount:market-board:default, с текущим pod_uid. Значение http_status, равное 201, означает, что API ответил на этот запрос проверки собственной идентичности. Проверка не является сохраняемым объектом кластера, не меняет разрешения и не создаёт Deployment. Токен не показывается. Готовый процесс панели с подтверждённой идентичностью всё ещё может не иметь доступа к данным приложений.
Создайте каталог выпуска. mkdir -p создаёт его при необходимости и сохраняет существующий каталог. В следующей команде > перенаправляет вывод в ваш редактируемый файл. Маркер YAML в кавычках сохраняет текст буквально до последнего маркера на отдельной строке. Повторение команды перезаписывает только этот файл выпуска:
mkdir -p release
cat > release/identity.yaml <<'YAML'
apiVersion: v1
kind: ServiceAccount
metadata:
name: market-reader
namespace: market-board
YAML
Прочитайте файл, затем примените его. apply -f читает указанный манифест и создаёт или обновляет его объект:
cat release/identity.yaml
kubectl --context=labex-v135 apply -f release/identity.yaml
kubectl --context=labex-v135 get serviceaccount market-reader -n market-board
Отдельная идентичность теперь существует. Долгоживущий Secret с токеном не требуется автоматически: Kubernetes проецирует привязанные учётные данные в Pod, когда тот использует идентичность. Само создание этого ServiceAccount не предоставляет доступ к Deployment и не меняет идентичность работающей панели. Оставьте исходную учётную запись по умолчанию без изменений.
При опечатке в пути используйте уже показанные pwd, ls и cd с абсолютным путём, затем повторите неудавшуюся операцию. При ошибке YAML прочитайте редактируемый файл, сравните отступы с полным примером, перезапишите и примените снова. Оставьте scope.json, начальный файл, инструменты, исходные пространства имён, приложения и данные без изменений. Вы будете редактировать только указанные манифесты выпуска и их именованные объекты идентичности/RBAC, а также выбранный ServiceAccount Deployment панели.
Подключите первое пространство имён
На этом шаге вы предоставите две операции чтения в пространстве имён торговых точек, затем заставите новый Pod панели действительно использовать отдельную идентичность.
Начните в Workspace, в /home/labex/project/status-board. RBAC Kubernetes означает управление доступом на основе ролей. Role определяет разрешения внутри одного пространства имён. RoleBinding связывает Role этого пространства имён с идентичностью. Одно лишь совпадение имён не создаёт эту связь.
Панели нужен list для чтения коллекции Deployment и get для открытия отдельного Deployment. Deployment принадлежат группе API apps; правило использует apps, без /v1. watch запросил бы поток изменений, который эта панель не использует. Операции записи и доступ к Secret не нужны. Сохраните оба глагола чтения доступными для всех Deployment в каждом утверждённом пространстве имён. Не указывайте resourceNames — необязательное поле правила, ограничивающее разрешение именованными ресурсами. roleRef.apiGroup привязки определяет API RBAC, rbac.authorization.k8s.io; он отличается от группы apps, которой принадлежат Deployment, доступ к которым разрешает Role.
Сохраните Role и её привязку в одном манифесте. Разделитель --- начинает второй документ YAML. metadata.namespace привязки — место действия разрешения, а subjects.namespace — место существования ServiceAccount. Здесь они намеренно различаются:
cat > release/first-access.yaml <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: market-stalls
rules:
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: board-reader
namespace: market-stalls
subjects:
- kind: ServiceAccount
name: market-reader
namespace: market-board
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployment-reader
YAML
Прочитайте и примените оба объекта, затем изучите интерпретированную связь:
cat release/first-access.yaml
kubectl --context=labex-v135 apply -f release/first-access.yaml
kubectl --context=labex-v135 describe role deployment-reader -n market-stalls
kubectl --context=labex-v135 describe rolebinding board-reader -n market-stalls
Ожидаются только get и list для Deployment. Проследите roleRef до Role в market-stalls, а субъект — до market-reader в market-board. Привязка не создаёт второй ServiceAccount в целевом пространстве имён.
Работающая панель всё ещё использует default. Операция list диагностического инструмента запрашивает настоящую коллекцию Deployment с текущими учётными данными этого Pod. Запрещённое чтение возвращает http_status: 403 и ненулевой код завершения команды; это ожидаемо до переключения идентичности нагрузки:
./tools/board-test list market-stalls
Новое разрешение принадлежит market-reader, а не default. Не исправляйте это предоставлением доступа учётной записи по умолчанию. Выберите отдельную учётную запись в сохранённой копии подготовленного Deployment панели.
Сначала прочитайте начальный файл целиком. Он содержит существующий образ, подключённый исходный код, проверку здоровья, число реплик и другие настройки, которые нужно сохранить:
cat starter/board.yaml
kubectl set serviceaccount меняет выбранную идентичность. --local преобразует входной файл, не применяя его к кластеру. -f задаёт вход, -o yaml записывает манифест YAML в стандартный вывод, а уже изученный > сохраняет его как ваш редактируемый файл выпуска:
kubectl --context=labex-v135 set serviceaccount --local -f starter/board.yaml market-reader -o yaml > release/board.yaml
Прочитайте результат и подтвердите, что spec.template.spec.serviceAccountName равен market-reader. Сохраните все остальные настройки приложения:
cat release/board.yaml
kubectl --context=labex-v135 apply -f release/board.yaml
У существующего Pod нельзя изменить ServiceAccount на месте. Обновление шаблона Pod в Deployment создаёт новый Pod. rollout status ждёт новую нагрузку; --timeout=120s ограничивает ожидание:
kubectl --context=labex-v135 rollout status deployment/status-board -n market-board --timeout=120s
kubectl --context=labex-v135 get pods -n market-board
Ожидается один готовый текущий Pod панели. Замена этого Pod панели необходима; Pod целевых приложений не меняются. Снова прочитайте его фактически аутентифицированную идентичность:
./tools/board-test identity
Ожидаются system:serviceaccount:market-board:market-reader и pod_uid, отличный от исходного Pod с идентичностью по умолчанию. Это подтверждает учётные данные процесса, а не только оценку идентичности через impersonation.
Результаты чтения коллекции и отдельного Deployment также включают generation — версию желаемого состояния Deployment — и observed_generation — версию, которую его контроллер обработал последней. Страница подробностей обозначает их Deployment generation и Observed generation. Контроллер может ненадолго отставать от желаемого изменения. Эти поля не считают запросы покупателей и не устанавливают доступность сайта.
Прочитайте коллекцию торговых точек и отдельный Deployment. get принимает пространство имён, затем имя Deployment:
./tools/board-test list market-stalls
./tools/board-test get market-stalls catalogue
Ожидаются http_status: 200, оба исходных Deployment торговых точек в коллекции и catalogue с 2 желаемыми и 2 доступными репликами в отдельном результате. uid определяет исходный объект; образ шаблона остаётся python:3.12-alpine. Role пространства имён не распространяется на пространство имён доставки:
./tools/board-test list market-delivery
Для последней команды ожидаются API 403 и ненулевой код завершения. Переключитесь на Board, используйте Refresh view, откройте Inspect catalogue и прочитайте желаемое/доступное число реплик и Template image. Используйте Back to status board. Карточки торговых точек должны работать, пока группа доставки ещё показывает Access denied · API 403. Этот частичный результат — полезное свидетельство границы пространства имён.
Если Read as всё ещё показывает прежнюю идентичность сразу после развёртывания, снова используйте Refresh view. Для подтверждения текущего Pod переключитесь на Workspace, повторите ./tools/board-test identity, затем вернитесь на Board и обновите. Маршрутизации Service может потребоваться немного времени, чтобы догнать развёртывание; не предоставляйте доступ старой идентичности для сокрытия перехода.
Сравните фактического читателя, успешные карточки торговых точек и всё ещё запрещённую группу доставки с этим работающим примером:
При тайм-ауте развёртывания вернитесь в Workspace и изучите тот же Deployment и Pod уже показанными командами describe и get. При неожиданном отказе чтения сравните Role, пространство имён субъекта RoleBinding и выбранную идентичность нагрузки. Исправьте только файл выпуска, примените его и повторите соответствующее ожидание развёртывания или запрос. Не копируйте учётные данные оператора, не меняйте приложение и не перезапускайте VM.
roleRef у RoleBinding неизменяем. Если прежняя опечатка создала новую привязку этого курса board-reader с неверной ссылкой на Role, Kubernetes откажется менять ссылку на месте. После её изучения и исправления release/first-access.yaml пересоздайте только собственную именованную привязку, затем примените исправленный сохранённый файл:
kubectl --context=labex-v135 delete rolebinding board-reader -n market-stalls
kubectl --context=labex-v135 apply -f release/first-access.yaml
Это условные команды восстановления, а не обязательное удаление при обычном успешном пути. Не удаляйте привязки по умолчанию или платформы и не удаляйте исходный Deployment панели или целевые нагрузки.
Расширьте панель, сохранив пределы её задачи
На этом шаге вы предоставите той же идентичности те же две операции чтения в пространстве имён доставки, затем проверите полезный вывод и защищённые границы.
Начните в Workspace, в /home/labex/project/status-board. Второму пространству имён нужны собственные Role и RoleBinding. Повторно используйте там имя Role, но оставьте субъект в market-board; идентичность никуда не перемещалась:
cat > release/second-access.yaml <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: market-delivery
rules:
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: board-reader
namespace: market-delivery
subjects:
- kind: ServiceAccount
name: market-reader
namespace: market-board
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployment-reader
YAML
cat release/second-access.yaml
kubectl --context=labex-v135 apply -f release/second-access.yaml
kubectl --context=labex-v135 describe rolebinding board-reader -n market-delivery
Привязка предоставляет эту целевую Role существующей идентичности панели. Дополнительное развёртывание панели не нужно, поскольку текущий Pod уже использует эту идентичность. Разрешения RBAC складываются; изменение порядка файлов не вводит правило запрета и не убирает постороннее разрешение.
Прочитайте обе утверждённые коллекции и подробности доставки через фактические учётные данные панели:
./tools/board-test list market-stalls
./tools/board-test list market-delivery
./tools/board-test get market-delivery pickup
Ожидается API 200 с исходными объектами и образами. Коллекция доставки включает pickup с 1 желаемой/1 доступной репликой и receipts с 0/0. Deployment с нулевым желаемым числом остаётся настоящим объектом, хотя у него нет работающих Pod. Сохраните эту объявленную настройку.
Теперь проверьте исключённые данные. Secret Kubernetes хранит именованные значения данных. Подготовленный staff-note — синтетический учебный объект; панели незачем его читать. Оператор может подтвердить существование объекта, не показывая его значения:
kubectl --context=labex-v135 get secret staff-note -n market-stalls
Собственные учётные данные панели должны по-прежнему получать API 403 для третьего пространства имён и этого Secret. Обе следующие команды должны завершиться с ненулевым статусом:
./tools/board-test list market-office
./tools/board-test secret market-stalls staff-note
Отсутствующий объект, сбой соединения или снимок ошибки не эквивалентны этому настоящему отказу в авторизации. Тот же клиент успешно читает утверждённые цели, а существующие исключённые объекты остаются нетронутыми. Файл проецируемых учётных данных не даёт ему доступа к API Secret.
Операция инструмента permission спрашивает API, могут ли эти фактические учётные данные выполнить действие. Она не выполняет действие. Аргументы — пространство имён, глагол и, когда применимо, имя Deployment. Несохраняемая проверка возвращает http_status: 201 с allowed: false для каждой запрещённой операции; инструмент возвращает ненулевой статус для этого отказа:
./tools/board-test permission market-stalls patch catalogue
./tools/board-test permission market-delivery delete pickup
./tools/board-test permission market-stalls create
Панели нужны только get и list; поток watch и изменение нагрузки не разрешены. Оставьте идентичность по умолчанию и исходный RBAC платформы без изменений. Не добавляйте ClusterRole, ClusterRoleBinding, подстановочный знак, дополнительный субъект или разрешение другого ресурса.
Переключитесь на Board и используйте Refresh view. Обе группы теперь показывают исходные Deployment. Откройте Inspect pickup, прочитайте числа и образ, затем используйте Back to status board. Прочитайте карточку receipts: Scaled to zero, 0 доступных, 0 желаемых. Это не пустая подстановка вместо неудавшегося запроса.
Сравните фактического читателя, все четыре карточки Deployment и видимый архив с нулевым желаемым числом с этим готовым примером:
Выберите Download CSV и откройте настоящий скачанный orchard-market-deployments.csv. В нём четыре строки данных, по одной для каждого исходного Deployment, включая архив чеков. Сопоставьте пространство имён, имя Deployment, желаемое/доступное число, образ шаблона и статус API со страницей. Это свежая выгрузка API, а не сохранённый успешный образец. Браузерные загрузки и рабочий каталог терминала — разные места; копировать загрузку в рабочий каталог не требуется.
Выберите Access details, подтвердите фактическое значение Read as и обе предполагаемые области пространств имён, затем используйте Back to status board. Сохраните каждый исходный целевой Deployment, идентичность Pod/контейнера, исходный код, образ, данные и метку пространства имён. Сохраните исходные Deployment и Service панели; меняется только выбранный ServiceAccount. Повторно используемый выпуск содержит identity.yaml, first-access.yaml, second-access.yaml и board.yaml, соответствующие фактической идентичности и работающим разрешениям.
Если второе пространство имён остаётся недоступным, вернитесь в Workspace, изучите его привязку показанной командой describe, сравните пространство имён субъекта и ссылку на Role, исправьте сохранённый файл и примените снова. При неверном неизменяемом roleRef используйте то же ранее изученное узко ограниченное восстановление, теперь только для своей новой привязки доставки:
kubectl --context=labex-v135 delete rolebinding board-reader -n market-delivery
kubectl --context=labex-v135 apply -f release/second-access.yaml
Выполняйте их только для этого конкретного восстановления. Если исключённый доступ неожиданно успешен, изучите две сохранённые Role и их привязки, уберите непреднамеренное разрешение внутри этих объектов и примените снова. Широкое разрешение не отменяется другой более узкой Role. Не редактируйте разрешения платформы или приложение для сокрытия ошибки. Ошибки пути и YAML исправляются уже изученным способом, без сброса VM.
Готовый инструмент читает состояние Deployment, сообщаемое контроллером, в этом подготовленном одноузловом кластере. Он не аутентифицирует посетителей панели, не читает логи Pod или метрики и не доказывает производственную непрерывность работы. Его readiness-точка подтверждает лишь способность процесса панели обслуживать запросы; доступность данных приложений устанавливают настоящие результаты API.
Резюме
Вы предоставили настоящему потребителю внутри кластера собственный ServiceAccount, связали Role и RoleBinding в рамках пространства имён и заставили новый Pod действительно использовать эту идентичность. Затем вы расширили ту же задачу чтения на второе утверждённое пространство имён, не предоставляя доступа к исключённым данным или изменениям нагрузки.
Пригодная к использованию панель, текущий CSV и сохранённые манифесты связывают идентичность, разрешения и фактический вывод API. Желаемое число реплик, доступность по данным контроллера и образы шаблонов остаются разными наблюдениями. При отказе API данные остаются недоступными, а намеренный Deployment с нулевым желаемым числом остаётся видимым настоящим объектом.
