Проект «SnakeProject» Михаила КозловаРегистрация

Навигация
⇒FreeBSD and Nix⇒

⇐CISCO
⇐Voice(Asterisk\Cisco)
⇐Microsoft
⇐Powershell
⇐Python
⇐SQL\T-SQL
⇐1С
⇐Общая
⇐WEB Разработка
⇐ORACLE SQL \ JAVA
⇐Мото

Щупаем Kubernetes за всякое часть 2


 

Щупаем Kubernetes за всякое часть 2


Предыдущая часть:
http://snakeproject.ru/rubric/article.php?art=kubernetes_1_01062020


Из предыдущей части мы имеем развернутый mynginx:
kubectl run создала объект развертывания в пространстве имен deployment

Разберемся, как развертывание запускает образ контейнера


Будут рассмотрены:
Развертывания
Манифесты развертываний
ReplicaSet
Pod-оболочки
Палнировщик
Сервисы
Утилита kubectl


Развертывания

kubectl run из 1й части лишь добавляет в бд новую запись о развертывании

Мы видели данный функционал в 1й части:
$ kubectl run mynginx --image=nginx --port=8888 --labels app=mynginx

Вывести все активные развертывания в текущем пространстве имен:
$ kubectl get pods --namespace default
NAME      READY   STATUS    RESTARTS   AGE
mynginx   1/1     Running   0          45h

Более подробно о конкретном развертывании указывайте его название:
$ kubectl describe pod mynginx

Развертывания управляют объектами ReplicaSet
Контролируют поведение реплик в момент обновления
Например когда выкатывается новая версия приложения

При обновлении развертывания, для управления Pod-оболочками
Создается новый объект ReplicaSet

После завершения обновления, старый объект ReplicaSet уничтожается
При этом вместе с ним уничтожатся Pod-оболочки


Манифесты развертываний (спецификации желаемого состояния)

Если необходимо изменить данные в спецификации развертывания, можно:
1. Удалить существующий объект в Deployment с помощью kubectl delete
2. Создать новый с необходимыми полями

Однако для этого лучше подходят манифесты

Стандартный формат манифеста - YAML, поддерживается JSON

Убейте, если остались остатки от mynginx:
$ kubectl delete pod mynginx
$ kubectl delete all --selector app=mynginx
$ kubectl delete pod mynginx --grace-period=0 --force
pod "mynginx" deleted

Запустим снова развертывание:
$ kubectl run mynginx --image nginx --port=8888 --labels app=mynginx

Сгенерируем автоматически файл манифеста:
$ kubectl get pods --selector app=mynginx -o yaml > mynginx.yaml

Пример файла mynginx.yaml:

Манифесты можно изменять

kubectl apply умеет применять манифесты Kubernetes:
$ kubectl apply -f mynginx.yaml
Warning: 
kubectl apply should be used on resource created by either 
kubectl create --save-config or kubectl apply
pod/mynginx configured

Через несколько секунд увидим Running Pod-оболочку mynginx:
$ kubectl get pods --selector app=mynginx

NAME      READY   STATUS    RESTARTS   AGE
mynginx   1/1     Running   0          5m12s


ReplicaSet

Объект ReplicaSet отвечает за группу идентичных Pod-оболочек

Отслеживается количество Pod-оболочек

Если их станет мало или много в отличии от спецификации то ReplicaSet
Запустит или остановит копии оболочек до необходимого числа


Pod-оболочки

Pod-оболочка - объект, представляет группу из одного или многих контейнеров

Из вывода Pod Template мы видели один контейнер mynginx

kubectl run создала развертывание, которое запусктило Pod-оболочку

Развертывания управляют Pod-оболочками через объект ReplicaSet
С объектом ReplicaSet не взаимодействуют напрямую


Разберем предыдущую часть, создание развертывания mynginx 

При создании развертывания mynginx запускается одноименная Pod-оболочка

!!! После предыдущих команд выключил виртуалку аварийно
!!! Вылезла ошибка:
!!! Node had taints that the pod didn't tolerate 
!!! error when deploying to Kubernetes cluster

Решение
$ kubectl get nodes
NAME                STATUS     ROLES    AGE    VERSION
kubernetes-master   NotReady   master   2d3h   v1.18.2
kubernetes-slave    NotReady   <none>   2d1h   v1.18.2

Вам нужно установить провайдера сетевой политики
Это один из поддерживаемых провайдеров: Weave Net for NetworkPolicy
$ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

$ kubectl get nodes
NAME                STATUS     ROLES    AGE    VERSION
kubernetes-master   Ready      master   2d3h   v1.18.2
kubernetes-slave    NotReady   <none>   2d2h   v1.18.2

Убедимся, что Pod-оболочка запущена:
$ kubectl get pods --selector app=mynginx
NAME      READY   STATUS    RESTARTS   AGE
mynginx   1/1     Running   0          4m53s

Убьем Pod-оболочку:
$ kubectl delete pod mynginx
pod "mynginx" deleted

Снова выведите список Pod-оболочек:
$ kubectl get pods --selector app=mynginx
NAME      READY   STATUS        RESTARTS   AGE
mynginx   1/1     Terminating   0          5m48s

В выводе Pod-оболочка останавливается (статус Terminating)

Снова выведите список Pod-оболочек:
$ kubectl get pods --selector app=mynginx
No resources found in default namespace.

Полная остановка и уничтожение приложения mynginx:
$ kubectl delete all --selector app=mynginx


Палнировщик

Развертывание создает Pod-оболочки, за их запуск отвечает компонент Палнировщик

Если развертывание решит, что необходима новая реплика, то создаст ресурс Pod в бд

Одновременно с этим этот ресурс добавляется в очередь планировщика

Планировщик отслеживает очередь
Берет из нее запланированную к созданию Pod-оболочку
Находит узел, на котором ее можно запустить и запускает
Программа kubelet, работающая на выбранном узле производит запуск контейнера

По удалении Pod-оболочки в примере выше 
Программа kubelet это отследила и инициировала ее замену
Т.к. она знает, что на этом узле должна работать Pod-оболочка mynginx
И если ее нет, то ее следует запустить

Если выключить сервер, то его Pod-оболочки уйдут в очередь планировщика
В последствии они будут назначены другим узлам кластера


Сервисы

Как происходит сетевое взаимодействие с Pod-оболочками?

IP-адрес может измениться при перезапуске, что неудобно для обращения

Объект данного типа предоставляет несменяемый IP-адрес или доменное имя
Которые автоматически перенаправляются на нужную Pod-оболочку

Сервис по сути аналог веб-прокси или балансировщика сетевой нагрузки
Направляет запросы к группам внутренних Pod-оболочек

Умеет направлять трафик на порты в соответствии с разделом ports спецификации

Параметр selector из манифеста указывает сервису
Как перенаправлять запросы к Pod-оболочкам

Чтоб получать запросы, Pod-оболочка должна иметь подходящий набор меток
В манифесте это - app: mynginx 

В примере манифеста указана лишь одна Pod-оболочка, соответствующая этому критерию
Pod-оболочек может быть указано много
Тогда сервис отправлял бы Pod-оболочкам запросы случайным образом
Т.е. мы имеем своеобразный функционал балансировщика сетевой нагрузки

Развертывание управляет группой Pod-оболочек приложения
Cервис же предоставляет запросам единую точку входа в Pod-оболочки

Удаление, ресурсы, описанные в файле манифеста будут удалены:
$ kubectl delete -f mynginx.yaml
pod "mynginx" deleted


Утилита kubectl

Умеет:
Работать с конфигурацией
Создавать, модифицировать, уничтожать ресурсы
Позволяет делать запросы кластеру за информацией его ресурсов и их состоянии

С некоторым функционалом мы знакомы из 1й части

Вывести ресурсы всех типов:
$ kubectl get all

Вывести информацию о Pod-оболочках и развертываниях:
$ kubectl get nodes

Вывести информацию указанной Pod-оболочки или любого другого ресурса:
$ kubectl describe pod/mynginx

 


Комментарии пользователей

Эту новость ещё не комментировалиНаписать комментарий
Анонимам нельзя оставоять комментарии, зарегистрируйтесь!

© Snakeproject.ru создан в 2013 году. При копировании материала с сайта - оставьте ссылку.


Яндекс.Метрика

Goon Каталог сайтов Рейтинг@Mail.ru