Шпаргалка по Kubectl для администраторов Kubernetes и подготовка к экзамену CKA
Шпаргалка по Kubectl для администраторов Kubernetes и подготовка к экзамену CKA
Это самоуверенный чит-лист, созданный для использования в качестве ориентира для ежедневных операций Kubernetes и администрирования, выполняемых через интерфейс командной строки с помощью kubectl. Если вы готовитесь к экзаменам CKA или CKAD, шпаргалка содержит команды, которые помогут вам быстро выполнить экзаменационные задания. При подготовке к экзамену не следует полностью полагаться на этот документ, а лучше пройти курс по содержанию с большой практикой.
Если у вас есть команда kubectl для экономии времени, которую мы пропустили в этом посте, не стесняйтесь оставить ее в разделе комментариев. Мы будем рады обновить документ в любое время.
Мы начнем с полезных общих команд, прежде чем рассмотрим команды для конкретных задач, используемые при развертывании администрирования и приложений в Kubernetes или OpenShift Cluster.
Полезные команды для общего использования
Ниже приведены некоторые из наиболее полезных команд общего пользования при работе с Kubernetes.
1. Установите kubectl
Вот как установить kubectl в Linux и macOS:
Linux
macOS:
Подтвердите установку, проверив версию:
2. Включите завершение Bash.
По умолчанию завершение Bash не включено после установки команды kubectl. Включите его с помощью команд ниже.
Bash:
3. Список и переключение контекста
Контекст — это группа параметров доступа. Каждый контекст содержит кластер Kubernetes, пользователя и пространство имен.
Переключайтесь между кластерами, задав текущий контекст в файле kubeconfig :
Установите запись контекста в kubeconfig:
Если вы хотите изменить предпочтение пространства имен, используйте:
См. Текущий контекст:
4. Проверьте синтаксис файла yaml манифеста.
Если вы создали yaml-файл развертывания и хотите проверить синтаксис, используйте команду:
Если есть синтаксические ошибки, вы получите из вывода:
5. О чистите узел при удалении локальных данных.
Узел может быть очищен, а также очищены локальные данные, используемые запущенными контейнерами. Для этого используется синтаксис команды:
Для принудительного слива вы можете добавить —force флаг, хотя это не рекомендуется.
6. Примените файлы и папки yaml.
Вы можете использовать аргумент apply, чтобы применить конфигурацию к ресурсу по имени файла или стандартному вводу. Синтаксис команды:
Для папки с несколькими ямл-филами используйте:
С абсолютным путем:
7. Создавайте псевдонимы для экономии времени.
Вы также можете создать несколько псевдонимов, которые значительно ускорят использование командной строки.
8. Запустите временный модуль, который умирает при выходе.
Вы можете быстро создать временный модуль с сеансом оболочки для целей тестирования, который будет уничтожен при выходе.
9. Создайте пространство имен.
Пространство имен создается с помощью команды:
Чтобы переключиться в пространство имен для всех операций, используйте:
10. Запустите команду оболочки в Pod без tty.
Давайте создадим модуль, работающий в фоновом режиме.
Подтвердите, что Pod запущен:
Запуск сеанса оболочки с модулем:
Запуск команды прямо в контейнере без tty.
11. Проверьте переменные среды в модуле.
Чтобы перечислить все переменные среды в модуле, используйте команду:
12. Получите объяснение использования ресурсов.
13. Сортировка ресурсов по названию.
Чтобы перечислить ресурсы, отсортированные по имени, вы будете использовать.
14. Создайте YAML-файл манифеста модуля.
Вы можете использовать kubectl run для создания файла манифеста yaml для развертывания Pods.
Страница справки по командам.
Следующая команда печатает соответствующие объекты API, не создавая их:
С ограничениями памяти и ЦП:
С запросами и ограничениями как ЦП, так и памяти.
Вы можете направить вывод в файл.
Затем вы можете создать модуль, применив файл.
Подтвердите, что Pod запущен:
15. Создайте файл YAML для развертывания.
Вы можете изменить файл и применить создание ресурсов.
Список модулей, соответствующих Nginx.
16. Предоставление доступа к модулю или развертыванию в службе.
Используйте команду kubectl expose, чтобы сделать развертывание или Pod доступными на ClusterIP или NodePort.
Вы также можете вручную указать порт, предоставляемый контейнером (порт приложения).
17. Масштабирование модулей в развертывании.
Вы можете увеличить количество модулей в развертывании, не редактируя какой-либо файл.
18. Перенесите все модули в узел и сделайте его недоступным для планирования.
Определите узел, над которым нужно действовать:
Затем скажите Kubernetes, чтобы он опустошил узел:
Возможно, вам придется игнорировать наборы демонов и удалить данные локального контейнера.
Скажите Kubernetes, чтобы он прекратил планировать новые поды на ноде:
Чтобы возобновить планирование на узле, используйте команду:
19. Создание нескольких контейнеров в модуле
Отредактируйте файл и добавьте другие контейнеры в названный модуль.
Мы добавили два контейнера — nginx и redis. Чтобы применить конфигурации, выполните команду:
Убедитесь, что в капсуле есть два контейнера.
20. Создание учетной записи службы, роли и привязки ролей
Создайте сервис под названием demo.
Создайте роль с именем demo, которая позволяет пользователю выполнять «получение», «просмотр» и «список» для модулей, развертывания, ds, rs, sts:
Создайте RoleBinding для demo роли.
21. Получение журналов для пакетов
Получить последние журналы на именованном поде:
Следите за потоком логов в реальном времени.
Получите последние журналы из всех модулей в развертывании:
Используйте регулярное выражение для извлечения журналов.
Записать вывод в файл:
Распечатайте журналы для предыдущего экземпляра контейнера в модуле, если он существует.
22. Получите лучшие стручки
Получите лучшие модули использования ресурсов.
Получите лучшие модули с высокой загрузкой ЦП:
Фильтр с помощью меток.
Получите только один модуль с максимальной загрузкой ЦП и запишите вывод в файл.
23. Развернуть и откатить развертывание
Разверните контейнер Nginx.
Обновление развертывания для использования образа nginx версии 1.14.2
Проверить статус внедрения
Просмотрите историю развертывания развертывания:
Откат к предыдущему развертыванию:
Развертывание до конкретной версии
24. Обозначьте узел и назначьте модули узлам.
Как добавить метки к Node.
Затем вы можете назначить модули для узлов.
25. Копирование файлов в модули и из модулей.
В kubectl CP команды могут быть использованы для копирования файлов в стручках или из стручки.
В этом примере мы скопируем файлы из модуля в нашу локальную систему.
Давайте подтвердим, что два скопированных файла доступны локально.
Скопируйте файл в Pod.
Дополнительные примеры см. На странице справки.
26. Отладка DNS.
Запустите модуль DNS Utils:
Подтвердите, что модуль запущен:
Или получить доступ к оболочке
Проверка настроек конфигурации локального DNS:
Проверка того, запущены ли DNS Pods:
Убедитесь, что конечные точки DNS доступны:
Работа с кластером Kubernetes
Цели статьи
Введение
Она формирует конфиг для настройки автодополнения команд в bash. Вывод этой команды нужно добавить в ваш
/.bashrc Можно это сделать автоматически.
Чтобы автодополнение работало, нужен пакет bash-completion.
Запуск контейнера nginx в kubernetes
Создаем файл pod-nginx.yaml следующего содержания:
Внимательно следите за пробелами в начале строк. Нужны именно пробелы, а не табуляция. В Yaml файлах очень важна структура. Запускаем получившийся pod.
Сразу сделаю пояснение насчет команды create. Вместо нее можно, а чаще всего и нужно, так как удобнее, использовать команду apply. Create создает новую абстракцию. Если вы ее измените и снова создадите с тем же именем, то получите ошибку. Вам придется сначала ее удалить, а потом создать заново. Команда apply сначала проверяет наличие абстракции, в данном случае pod-nginx и если ее нет, то создает. А если она уже есть, то просто перезапускает существующую с новыми параметрами.
Проверяем, что получилось.
В настоящий момент мы запустили в кластере kubernetes один контейнер с nginx. Существует команда edit, которая позволяет редактировать сущности кластера kubernetes в режиме реального времени. Применение изменений произойдет сразу же после сохранения изменений. Пример:
Вы увидите полный конфиг пода, который использует кластер. В нем намного больше информации, нежели в вашем yaml файле.
Удалить созданный pod можно следующей командой:
Или сразу все поды:
Отказоустойчивость подов с помощью ReplicaSet
Проверяем, что получилось.
Нам нужно было 2 реплики и мы их получили. С помощью edit мы можем на ходу редактировать replicaset, к примеру, добавляя количество реплик.
Репликасет сама следит за количеством запущенных подов. Если один из них по какой-то причине упадет или будет удален, она поднимет его заново. Можете проверить это сами, вручную удалив один из подов. Спустя некоторое время он появится снова.
Replicaset запускает поды на разных нодах. Проверить это можно, посмотрев расширенную информацию о подах.
Таким образом, если у вас одна нода выйдет из строя, кластер автоматически запустит умершие поды на новых нодах. При этом, если нода вернется обратно с запущенными подами на ней, kubernetes автоматически прибьет лишние поды, чтобы их максимальное количество соответствовало информации из шаблона replicaset.
Удаляются replicaset так же как и поды.
Вместо длинного replicaset я использовал сокращение rs. Это бывает удобно для абстракций с длинными названиями. Для всех них кубернетис поддерживает сокращения.
Deployment как раз и нужен для управления репликасетами, задавая им стратегию обновления. У вас вышла новая версия контейнера, вы заменяете в текущем deployment версию контейнера и он по заранее настроенным правилам начинает перезапуск репликасетов и соответственно подов в них. Покажу на примере nginx, который мы откатим на предыдущую версию. Создаем yaml файл с deployment.
Смотрим список подов и репликасетов.
Проверяем версию nginx в одном из подов.
Теперь откатимся на предыдущую версию nginx 1.15. Для этого вносим изменения в Deployment.
Проверяем список подов и репликасетов.
Название подов и репликасета изменились. Появился новый replicaset, а старый остался с погашенными подами, у него параметр replicas стал 0. Проверяем версию nginx в поде.
Версия nginx изменилась во всех подах. Стратегия обновления описана в шаблоне деплоймента в разделе strategy. В данном случае используется тип RollingUpdate, когда deployment постепенно уменьшает количество реплик старой версии и увеличивает реплики новой версии, пока они все не заменят старые. При этом replicaset с предыдущей версией контейнера осталась. Она не удаляется для того, чтобы можно было потом оперативно вернуться на предыдущую версию, если с новой будет что-то не так. Для этого достаточно будет по очереди погасить поды новой replicaset и запустить старые. Делается это следующим образом.
Проверяем наши replicaset.
Видим, что был снова запущен предыдущий replicaset с прошлой версией контейнера. По-умолчанию хранятся 10 версий прошлых replicaset.
Проверки доступности Probes
С деплоем и перезапуском подов не все так просто. Есть тяжелые приложения, которые стартуют очень долго, либо зависят от других приложений. Прежде чем погасить старую версию, нужно убедиться, что новая уже запущена и готова к работе. Для этого существует liveness и readiness проверки. Покажу на примере. Берем предыдущий deployment и добавляем туда проверки.
В данном примере используется проверка httpGet по корневому урлу на порт 80.
Вот еще один пример liveness проверки, но уже по наличию файла. Проверяется файл /tmp/healthy, если он существует, проверка удачна, если его нет, то ошибка.
Создавать этот файл может само приложение во время работы.
Важно понимать, что реквесты никак не следят за реальным использованием ресурсов. То есть это просто пожелание к ресурсам ноды, где будет размещаться под. При этом после размещения он сможет занять ресурсов больше, чем указано в Requests. Кластер kubernetes за этим не следит. Если реквесты вообще не указать, то под может приехать на ноду, где свободно очень мало ресурсов, а ему для работы надо больше. В итоге он будет падать. Таким образом, requests используются для планирования ресурсов кластера.
Далее пример деплоймента с указанными параметрами ресурсов. Дополняем предыдущие примеры.
Память выделяется в мегабайтах, а вот CPU в милли cpu, что равно 1/1000 от процессоронго ядра. То есть 1000 миллицпу это одно ядро процессора ноды. Запустим наш deployment и посмотрим на один из подов.
Вот они, наши проверки и лимиты с реквестами.
Монтирование конфигов через ConfigMap
В данном случае это простейший конфиг для nginx, который при обращении к серверу будет отдавать 200-й код ответа и имя сервера. Теперь подключаем его к нашему deployment из предыдущих примеров.
Мы создаем монтирование с именем config по пути /etc/nginx/conf.d/ и связываем это монтирование с configmap, который ранее создали. Теперь применяем сначала configmap, а затем deployment.
Проверяем, что получилось. Я подключусь к одному из подов и прочитаю там конфигурацию nginx.
Видим, что применился наш configmap. На втором поде будет то же самое.
Проброс порта в pod
А сейчас пробросим 80-й порт мастера в конкретный под и проверим, что nginx действительно работает в соответствии с установленным конфигом. Делается это следующим обарзом.
Перемещаемся в сосeднюю консоль мастера и там проверяем через curl.
Если сделать проброс в другой под и проверить подключение, вы получите в ответ на запрос curl на 80-й порт мастера имя второго пода. На практике, я не знаю, как можно использовать данную возможность. А вот для тестов в самый раз.
Service в Kubernetes по своей сути это некий балансировщик на уровне L3. С помощью сервисов мы можем попасть в нужные нам поды, обратившись к ним по имени или по ip адресу. Перераспределение запросов идет по алгоритму round-robin. Давайте сделаем сервис к нашему deployment из предыдущих примеров.
И смотрим, что получилось.
Нажимайте enter и попадете в контейнер. А дальше пробуйте пинговать.
После выхода из контейнера, он удалится.
Настройка Ingress
Загружаем конфиг в кластер кубернетиса.
Смотрим, что получилось.
Я просто в локальный hosts машины добавил и проверил.
Если обновлять страничку, имя пода будет меняться в соответствии с настройкой балансировки. Она выполняется по алгоритму least_conn.
Более подробно настройку ingress контроллера я рассмотрел в отдельной статье.
На этом я прерываюсь и заканчиваю текущее повествование по работе с кластером kubernetes. В таком виде в нем уже можно осмысленно что-то запускать и эксплуатировать. Надеюсь, вам было хоть немного понятно и вы сможете начать экспериментировать с кластером и пытаться на нем запускать какую-то полезную нагрузку. В таком виде он уже пригоден к ограниченной эксплуатации.
Deploy реального приложения в кластер
Запускаем деплой всего проекта одной командой.
Наблюдать за поднятием подов можно командой в реальном времени.
После того, как они все станут Running можно проверять работу. В этом проекте не используется ingress, поэтому чтобы понять, как подключиться к магазину, надо провести небольшое расследование. Для начала посмотрим запущенные service.
Этот pod запущен на kub-node-2. Посмотрим ее ip.
Вот он, наш магазин. Для удобства, можем сами доделать доступ через ingress по доменному имени. Настраиваем конфиг ingress.
Не забывайте указывать нужный namespace и правильное имя сервиса, для которого настраиваем ingress. Применяем конфиг.
Смотрим, что получилось.
Редактируем файл hosts и идем в браузер проверять.
Поздравляю, ваш кластер работает, а вы теперь администратор кластера Kubernetes и инженер yaml файлов 🙂 У вас теперь будет большая дружба с лапшеподобным синтаксисом. Идите к руководству и требуйе прибавки к зарплате минимум на 30%.
Заключение
Напоминаю, что подробно, с примерами и практическими заданиями изучить кластер kubernetes можно на обучении Слёрм, которое я прошел лично и могу рекомендовать, как хороший и эффективный курс.
Онлайн курс по Kubernetes
Онлайн-курс по Kubernetes – для разработчиков, администраторов, технических лидеров, которые хотят изучить современную платформу для микросервисов Kubernetes. Самый полный русскоязычный курс по очень востребованным и хорошо оплачиваемым навыкам. Курс не для новичков – нужно пройти вступительный тест.
Помогла статья? Подписывайся на telegram канал автора
Автор Zerox
16 комментариев
Про пробы описаны не правильно
Один момент. Readiness проба исполняется всё время работы пода, а не завершается.
Коллеги, в статье не нашел информации. А как дать доступ для Jenkins? В Yutube вижу подключают secret file, беря в качестве него config. А как обстоит дело в случае kubespray?
Если не ошибаюсь, все необходимое для подключения к кластеру есть в директории /etc/kubernetes/ мастера, с которого была установка. С именем директории могу ошибаться, но она точно в /etc. Там и конфиги и сертификаты для подключения. Точно проверить нет кластера под рукой. Это что касается доступу к кластеру. Как именно jenkins к нему подключать, не знаю. Да и что значит дать доступ для Jenkins? Он что должен в кластере делать? Деплоить приложения?
Спасибо.
>Да и что значит дать доступ для Jenkins? Он что должен в кластере делать? Деплоить приложения?
Именно.
Спасибо за цикл статей про k8s. Пользовался ими при настройке кластера. Есть один вопрос, который пока не удается решить. Может здесь кто подскажет.
Каким образом передать свой домен в контейнер кубера, при деплое пода чтобы в файле /etc/hosts была запись типа такой:
1.2.3.4 test.domain.com test
Сейчас домен автоматом дописывает сам кубер, /etc/hosts:
Спасибо автору за проделанную работу.
Только у меня ingress-nginx почему-то с пустым IP адресом?
и сервис не обслуживается:
# curl kub-ingress-1.cluster.local
curl: (7) Failed connect to kub-ingress-1.cluster.local:80; Connection refused
Оказывается у меня почему-то отсутствует ingress-nginx-controller-xxxx как и сам ingress-nginx namespace.
kube-system coredns-85578f88b8-6rmcm 1/1 Running 0 95s
kube-system coredns-85578f88b8-h9mjr 1/1 Running 0 105s
kube-system dns-autoscaler-7d4cfd5f55-cf2hs 1/1 Running 1 27h
kube-system kube-apiserver-kub-master-1 1/1 Running 224 2d1h
kube-system kube-apiserver-kub-master-2 1/1 Running 3 47h
kube-system kube-apiserver-kub-master-3 1/1 Running 3 47h
kube-system kube-controller-manager-kub-master-1 1/1 Running 0 2d1h
kube-system kube-controller-manager-kub-master-2 1/1 Running 0 47h
kube-system kube-controller-manager-kub-master-3 1/1 Running 0 47h
kube-system kube-flannel-8vr5f 2/2 Running 3 27h
kube-system kube-flannel-b6ktv 2/2 Running 3 27h
kube-system kube-flannel-bnm7s 2/2 Running 3 27h
kube-system kube-flannel-kstqb 2/2 Running 3 27h
kube-system kube-flannel-r57jz 2/2 Running 2 27h
kube-system kube-flannel-wfjrn 2/2 Running 10 27h
kube-system kube-proxy-ch5kc 1/1 Running 0 3m50s
kube-system kube-proxy-ct9b6 1/1 Running 0 3m50s
kube-system kube-proxy-dz7ck 1/1 Running 0 3m50s
kube-system kube-proxy-kkdnd 1/1 Running 0 3m50s
kube-system kube-proxy-rtnth 1/1 Running 0 3m50s
kube-system kube-proxy-zs8cd 1/1 Running 0 3m50s
kube-system kube-scheduler-kub-master-1 1/1 Running 0 2d1h
kube-system kube-scheduler-kub-master-2 1/1 Running 0 47h
kube-system kube-scheduler-kub-master-3 1/1 Running 0 47h
kube-system kubernetes-dashboard-556b9ff8f8-4dtt9 1/1 Running 1 27h
kube-system nginx-proxy-kub-ingress-1 1/1 Running 3 27h
kube-system nginx-proxy-kub-node-1 1/1 Running 1 27h
kube-system nginx-proxy-kub-node-2 1/1 Running 1 27h
kube-system nodelocaldns-26fws 1/1 Running 1 27h
kube-system nodelocaldns-44n9h 1/1 Running 1 27h
kube-system nodelocaldns-5pjst 1/1 Running 3 27h
kube-system nodelocaldns-7k6nq 1/1 Running 1 27h
kube-system nodelocaldns-9xj9k 1/1 Running 1 27h
kube-system nodelocaldns-dw2ll 1/1 Running 1 27h
Странно то, что деплой прошел без ошибок даже после повторного запуска.
kub-ingress-1 : ok=322 changed=10 unreachable=0 failed=0 skipped=531 rescued=0 ignored=0
kub-master-1 : ok=494 changed=29 unreachable=0 failed=0 skipped=976 rescued=0 ignored=0
kub-master-2 : ok=428 changed=26 unreachable=0 failed=0 skipped=847 rescued=0 ignored=0
kub-master-3 : ok=430 changed=26 unreachable=0 failed=0 skipped=845 rescued=0 ignored=0
kub-node-1 : ok=320 changed=10 unreachable=0 failed=0 skipped=535 rescued=0 ignored=0
kub-node-2 : ok=320 changed=10 unreachable=0 failed=0 skipped=533 rescued=0 ignored=0
localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Friday 10 April 2020 13:32:12 +0000 (0:00:00.388) 0:17:06.491 **********
