Архив метки: Kubernetes

Обзор k9s — продвинутого терминального интерфейса для Kubernetes

K9s предоставляет пользовательский интерфейс терминала для взаимодействия с кластерами Kubernetes. Цель этого Open Source-проекта — облегчить удобную навигацию по приложениям в K8s, наблюдение за ними и управление ими. K9s постоянно следит за изменениями в Kubernetes и предлагает быстрые команды для работы с наблюдаемыми ресурсами.

Проект написан на Go, существует уже более полутора лет: первый коммит был сделан 1 февраля 2019 года. На момент написания статьи насчитывается 9000+ звезд на GitHub и около 80 контрибьюторов. Посмотрим, что умеет k9s?

Установка и запуск

Это клиентское (по отношению к кластеру Kubernetes) приложение, которое проще всего запустить как Docker-образ:

docker run --rm -it -v $KUBECONFIG:/root/.kube/config quay.io/derailed/k9s

Для некоторых Linux-дистрибутивов и других ОС также есть готовые для установки пакеты. В общем случае для Linux-систем можно установить бинарный файл:

sudo wget -qO- https://github.com/derailed/k9s/releases/download/v0.22.0/k9s_Linux_x86_64.tar.gz | tar zxvf -  -C /tmp/
sudo mv /tmp/k9s /usr/local/bin

Каких-то специфических требований к самому кластеру K8s нет. Судя по отзывам, приложение работает и с такими старыми версиями Kubernetes, как 1.12.

Приложение запускается, используя стандартный конфиг .kube/config — аналогичному тому, как это делает kubectl.

По умолчанию открывается окно со стандартным namespace, который указан для контекста. То есть, если вы прописали kubectl config set-context --current --namespace=test, то и откроется namespace test. (О смене контекстов/пространств имён см. ниже.)

Переход в режим команд осуществляется нажатием на «:». После этого можно управлять работой k9s с помощью команд — например, для просмотра списка StatefulSets (в текущем пространстве имен) можно ввести :sts.

Для некоторых других ресурсов Kubernetes:

:ns — Namespaces;
:deploy — Deployments;
:ing — Ingresses;
:svc — Services.

Чтобы вывести полный список типов ресурсов, доступных для просмотра, есть команда :aliases.

Удобно просматривать и список команд, доступных по горячим комбинациям клавиш в рамках текущего окна: для этого достаточно нажать на «?».

Также в k9s есть режим поиска, для перехода в который достаточно ввести «/». С ним осуществляется поиск по содержимому текущего «окна». Допустим, если вы до этого ввели :ns, у вас открыт список пространств имён. Если их слишком много, то, чтобы не скроллить долго вниз, достаточно в окне с namespaces ввести /mynamespace.

Для поиска по лейблам можно выбрать все pod’ы в нужном пространстве имён, после чего ввести, например, / -l app=whoami. Мы получим список pod’ов с этим лейблом:

Поиск работает во всех видах окон, включая логи, просмотр YAML-манифестов и describe для ресурсов — подробнее об этих возможностях см. ниже.

Как в целом выглядит последовательность действий для навигации?

С помощью команды :ctx можно выбрать контекст:

Для выбора namespace’а есть уже упоминавшаяся команда :ns, а далее можно воспользоваться поиском для нужного пространства: /test.

Если теперь выбрать интересующий нас ресурс (например, всё тот же StatefulSet), для него покажется соответствующая информация: сколько запущено pod’ов с краткими сведениями о них.

Могут быть интересны только pod’ы — тогда достаточно ввести :pod. В случае с ConfigMap’ами (:cm — для списка этих ресурсов) можно выбрать интересующий объект и нажать на «u», после чего K9s подскажет, кто конкретно его (этот CM) использует.

Ещё одна удобная фича для просмотра ресурсов — их «рентген» (XRay view). Такой режим вызывается командой :xray RESOURCE и… проще показать, как он работает, чем объяснять. Вот иллюстрация для StatefulSets:

(Каждый из этих ресурсов можно редактировать, изменять, делать describe.)

А вот Deployment с Ingress:

Работа с ресурсами

О каждом ресурсе можно получить информацию в YAML или его describe нажатием на соответствующие клавиатурные сочетания («y» и «d» соответственно). Базовых операций, конечно, ещё больше: их список и клавиатурные сочетания всегда на виду благодаря удобной «шапке» в интерфейсе (скрывается нажатием на Ctrl + e).

При редактировании любого ресурса («e» после его выбора) открывается текстовый редактор, определённый в переменных окружения (export EDITOR=vim).

А вот как выглядит подробное описание ресурса (describe):

Такой вывод (или вывод просмотр YAML-манифеста ресурса) можно сохранить с помощью привычного сочетания клавиш Ctrl + s. Куда он сохранится, будет известно из сообщения K9s:

Log /tmp/k9s-screens-root/kubernetes/Describe-1601244920104133900.yml saved successfully!

Из созданных файлов-бэкапов можно и восстанавливать ресурсы, предварительно убрав системные лейблы и аннотации. Для этого потребуется перейти в директорию с ними (:dir /tmp), после чего выбрать нужный файл и применить apply.

К слову, в любой момент можно откатиться и на прошлый ReplicaSet, если с текущим есть проблемы. Для этого надо выбрать нужный RS (:rs для их списка):

… и выполнить rollback с помощью Ctrl + l. Мы должны получить уведомление, что все прошло успешно:

k9s/whoami-5cfbdbb469 successfully rolled back

А чтобы масштабировать реплики, достаточно нажать на «s» (scale) и выбрать нужное количество экземпляров:

В любой из контейнеров можно зайти с помощью shell: для этого перейдите к нужному pod’у, нажмите на «s» (shell) и выберите контейнер.

Другие возможности

Конечно, поддерживается и просмотр логов («l» для выбранного ресурса). А чтобы смотреть новые логи, нет необходимости постоянно нажимать Enter: достаточно сделать маркировку («m»), после чего отслеживать только новые сообщения.

Также в этом же окне можно выбрать временной диапазон для вывода логов:

клавиша «1» — за 1 минуту;
«2» — 5 минут;
«3» — 15 минут;
«4» — 30 минут;
«5» — 1 час;
«0» — за все время жизни pod’а.

Специальный режим работы Pulse (команда :pulse) показывает общие сведения о Kubernetes-кластере:

В нем можно увидеть количество ресурсов и их состояние (зеленым показываются те, что имеют статус Running).

Еще одна интересная функция K9s называется Popeye. Она проверяет все ресурсы на определённые критерии корректности и выводит получившийся «рейтинг» с пояснениями. Например, можно увидеть, что не хватает проб или лимитов, а какой-то контейнер может запускаться под root…

Имеется базовая поддержка Helm. Например, так можно посмотреть релизы, задеплоенные в кластер:

:helm all # все
:helm $namespace # в конкретном пространстве имен

Benchmark

В K9s встроили даже hey — это простой генератор нагрузки на HTTP-сервер, альтернатива более известному ab (ApacheBench).

Чтобы включить его, потребуется активация port-forward в pod’е. Для этого выбираем pod и нажимаем на Shift + f, переходим в подменю port-forward с помощью алиаса «pf».

После выбора порта и нажатия на Ctrl + b запустится сам benchmark. Результаты его работы сохраняются в /tmp и доступны для последующего просмотра в K9s.

Для изменения конфигурации benchmark’а нужно создать файл $HOME/.k9s/bench-<my_context>.yml (определяется для каждого кластера).

NB: Важно, чтобы расширение всех YAML-файлов в директории .k9s было именно .yml (.yaml не работает корректно).

Пример конфигурации:

benchmarks:
  defaults:
    # Количество потоков
    concurrency: 2
    # Количество запросов
    requests: 1000
  containers:
    # Настройки для контейнера с бенчмарком
    # Контейнер определяется как namespace/pod-name:container-name
    default/nginx:nginx:
      concurrency: 2
      requests: 10000
      http:
        path: /
        method: POST
        body:
          {"foo":"bar"}
        header:
          Accept:
            - text/html
          Content-Type:
            - application/json
 services:
    # Можно проводить бенчмарк на сервисах типа NodePort и LoadBalancer
    # Синтаксис: namespace/service-name
    default/nginx:
      concurrency: 5
      requests: 500
      http:
        method: GET
        path: /auth
      auth:
        user: flant
        password: s3cr3tp455w0rd

Интерфейс

Вид столбцов для списков ресурсов модифицируется созданием файла $HOME/.k9s/views.yml. Пример его содержимого:

k9s:
 views:
   v1/pods:
     columns:
       - AGE
       - NAMESPACE
       - NAME
       - IP
       - NODE
       - STATUS
       - READY
   v1/services:
     columns:
       - AGE
       - NAMESPACE
       - NAME
       - TYPE
       - CLUSTER-IP

Правда, не хватает колонки по лейблам, на что есть issue в проекте.

Сортировка по столбцам осуществляется клавиатурными сочетаниями:

Shift + n — по имени;
Shift + o — по узлам;
Shift + i — по IP;
Shift + a — по времени жизни контейнера;
Shift + t — по количеству рестартов;
Shift + r — по статусу готовности;
Shift + c — по потреблению CPU;
Shift + m — по потреблению памяти.

Если же кому-то не нравится цветовое оформление по умолчанию, в K9s даже поддерживаются скины. Готовые примеры (7 штук) доступны здесь. Вот пример одного из таких скинов (in the navy):

Плагины

Наконец, плагины позволяют расширять возможности K9s. Сам я в работе использовал только один из них — kubectl get all -n $namespace.

Выглядит это следующим образом. Создаем файл $HOME/.k9s/plugin.yml с таким содержимым:

plugin:
 get-all:
   shortCut: g    
   confirm: false    
   description: get all
   scopes:
   - all
   command: sh
   background: false
   args:
   - -c
   - "kubectl -n $NAMESPACE get all -o wide | less"

Теперь можно перейти в пространство имён и нажать на «g» для выполнения с соответствующей команды:

Среди плагинов есть, например, интеграции с kubectl-jq и утилитой для просмотра логов stern.

Заключение

На мой вкус, K9s оказалась очень удобна в работе: с ней довольно быстро привыкнуть искать всё нужное без использования kubectl. Порадовал просмотр логов и их сохранение, быстрое редактирование ресурсов, скорость работы в целом*, оказался полезным режим Popeye. Отдельного упоминания стоят возможности создавать плагины и дорабатывать приложение под свои нужды.

* Хотя при большом объеме логов замечал также медленную работу K9s. В такие моменты утилита «съедала» 2 ядра у Intel Xeon E312xx и могла даже зависать.

Чего не хватает в настоящий момент? Быстрого отката на предыдущую версию (речь не про RS) без перехода в директорию. К тому же, восстановление происходит только для всего ресурса: если вы удалили аннотацию или лейбл, придется удалить и восстановить весь ресурс (здесь и понадобится переходить в директорию). Другая мелочь — не хватает даты таких сохраненных «бэкапов».

Источник: https://habr.com/ru/company/flant/blog/524196/

2022-07-28T23:48:08

DevOps

Принудительное удаление зависших подов в Kubernetes

В этом коротком руководстве мы рассмотрим, как удалить удаленные или завершенные поды в кластере Kubernetes.Есть много причин, по которым вы можете обнаружить, что некоторые поды находятся в состоянии Evicted и Terminated.В случае eviction это часто происходит в результате нехватки ресурсов на рабочих нодах или ошибки приложения.Terminated может быть результатом уменьшения масштаба приложения или развертывания новой версии приложения, после которой прекращается работа старых подов.Служба kubelet, которая работает на каждом узле кластера, отвечает за состояние eviction подов.Вы можете получить список подов в пространстве имен, застрявших в состоянии Evicted и Terminated, выполнив следующую команду:

kubectl get pods -n namespace | egrep -i 'Terminated|Evicted'

Как удалить поды в Kubernetes

Вы можете удалить эти поды разными способами.

Использование собственных команд kubectl и Bash

Это команды bash с фильтрацией, которые вы можете запустить для принудительного удаления подов в пространстве имен, которые застряли в завершенном состоянии.

# Определение неймспейса
namespace="mynamespace"

# Получаем поды
epods=$(kubectl get pods -n ${namespace} | egrep -i 'Terminated|Evicted' | awk '{print $1 }')

# Удаляем их
for i in ${epods[@]}; do
  kubectl delete pod --force=true --wait=false --grace-period=0 $i -n ${namespace}
done

Подтвердите, есть ли еще контейнеры в этом состоянии.

kubectl get pods -n ${namespace} | egrep -i 'Terminated|Evicted'

Удаление всех исключенных и завершенных модулей из всех пространств имен:

kubectl get pods --all-namespaces | egrep -i  'Evicted|Terminated' | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod --force=true --wait=false --grace-period=0

Удалите все контейнеры в состоянии ImagePullBackOff из всех пространств имен – Бонус:

kubectl get pods --all-namespaces | grep -E 'ImagePullBackOff|ErrImagePull|Evicted' | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod

Использование фильтров kubectl и jq

Вы также можете отфильтровать вывод команды kubectl и перенаправить в jq для получения определенных столбцов.

Сначала установите команду jq:

--- Ubuntu / Debian ---
$ sudo apt update && sudo apt install jq

--- CentOS/Fedora ---
$ sudo yum -y install epel-release
$ sudo yum -y install jq

--- RHEL ---
wget https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64 -O jq
chmod +x jq
sudo mv jq /usr/local/bin

Затем удалите застрявшие поды с помощью команды:

kubectl get pods --all-namespaces -o json | jq '.items[] | select(.status.reason!=null) | select(.status.reason | contains("Evicted")) | "kubectl delete pods (.metadata.name) -n (.metadata.namespace)"' | xargs -n 1 bash -c

Оставайтесь на связи, чтобы прочитать еще больще интересных руководств по контейнерам.

2022-04-14T17:43:08

DevOps

Установка и настройка кластера Kubernetes на Ubuntu Server

Есть различные готовые реализации кластера Kubernetes, например:

Minikube — готовый кластер, который разворачивается на один компьютер. Хороший способ познакомиться с Kubernetes.
Kubespray — набор Ansible ролей.
Готовые кластеры в облаке, например AWS, Google Cloud, Yandex Cloud и так далее.

Использовать одну из готовых реализаций — быстрый и надежный способ развертывания системы оркестрации контейнеров Docker. Однако, мы рассмотрим ручное создание кластера Kubernetes из 3-х нод — один мастер (управление) и две рабочие ноды (запуск контейнеров).

Подготовка системы

Данные действия выполняем на всех узлах будущего кластера. Это необходимо, чтобы удовлетворить программные системные требования для нашего кластера.

Настройка системы

1. Задаем имена узлам. Для этого выполняем команды на соответствующих серверах:

hostnamectl set-hostname k8s-master1.dmosk.local

hostnamectl set-hostname k8s-worker1.dmosk.local

hostnamectl set-hostname k8s-worker2.dmosk.local

* в данном примере мы зададим имя k8s-master1 для мастера и, соответственно, k8s-worker1 и k8s-worker2 — для первого и второго рабочих нод. Каждая команда выполняется на своем сервере.

Необходимо, чтобы наши серверы были доступны по заданным именам. Для этого необходимо на сервере DNS добавить соответствующие А-записи. Или на каждом сервере открываем hosts:

vi /etc/hosts

И добавляем записи на подобие:

192.168.0.15     k8s-master1.dmosk.local k8s-master1
192.168.0.20     k8s-worker1.dmosk.local k8s-worker1
192.168.0.25     k8s-worker2.dmosk.local k8s-worker2

* где, 192.168.0.15, 192.168.0.20, 192.168.0.25 — IP-адреса наших серверов, k8s-master1, k8s-worker1, k8s-worker2 — имена серверов, dmosk.local — наш внутренний домен.

2. Устанавливаем необходимые компоненты — дополнительные пакеты и утилиты. Для начала, обновим список пакетов и саму систему:

apt-get update && apt-get upgrade

Выполняем установку пакетов:

apt-get install curl apt-transport-https git iptables-persistent

* где:

git — утилита для работы с GIT. Понадобиться для загрузки файлов из репозитория git.
curl — утилита для отправки GET, POST и других запросов на http-сервер. Понадобиться для загрузки ключа репозитория Kubernetes.
apt-transport-https — позволяет получить доступ к APT-репозиториям по протоколу https.
iptables-persistent — утилита для сохранения правил, созданных в iptables (не обязательна, но повышает удобство).

В процессе установки iptables-persistent может запросить подтверждение сохранить правила брандмауэра — отказываемся.

3. Отключаем файл подкачки. С ним Kubernetes не запустится.

Выполняем команду для разового отключения:

swapoff -a

Чтобы swap не появился после перезагрузки сервера, открываем на редактирование файл:

vi /etc/fstab

И комментируем строку:

#/swap.img      none    swap    sw      0       0

4. Загружаем дополнительные модули ядра.

vi /etc/modules-load.d/k8s.conf

br_netfilter
overlay

* модуль br_netfilter расширяет возможности netfilter (подробнее); overlay необходим для Docker.

Загрузим модули в ядро:

modprobe br_netfilter

modprobe overlay

Проверяем, что данные модули работают:

lsmod | egrep "br_netfilter|overlay"

Мы должны увидеть что-то на подобие:

overlay               114688  10
br_netfilter           28672  0
bridge                176128  1 br_netfilter

5. Изменим параметры ядра.

Создаем конфигурационный файл:

vi /etc/sysctl.d/k8s.conf

net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1

* net.bridge.bridge-nf-call-iptables контролирует возможность обработки трафика через bridge в netfilter. В нашем примере мы разрешаем данную обработку для IPv4 и IPv6.

Применяем параметры командой:

sysctl --system

Брандмауэр

Для мастер-ноды и рабочей создаем разные наборы правил.

По умолчанию, в Ubuntu брандмауэр настроен на разрешение любого трафика. Если мы настраиваем наш кластер в тестовой среде, настройка брандмауэра не обязательна.

1. На мастер-ноде (Control-plane)

Выполняем команду:

iptables -I INPUT 1 -p tcp --match multiport --dports 6443,2379:2380,10250:10252 -j ACCEPT

* в данном примере мы открываем следующие порты:

6443 — подключение для управления (Kubernetes API).
2379:2380 — порты для взаимодействия мастера с воркерами (etcd server client API).
10250:10252 — работа с kubelet (соответственно API, scheduler, controller-manager).

Для сохранения правил выполняем команду:

netfilter-persistent save

2. На рабочей ноде (Worker):

На нодах для контейнеров открываем такие порты:

iptables -I INPUT 1 -p tcp --match multiport --dports 10250,30000:32767 -j ACCEPT

* где:

10250 — подключение к kubelet API.
30000:32767 — рабочие порты по умолчанию для подключения к подам (NodePort Services).

Сохраняем правила командой:

netfilter-persistent save

Установка и настройка Docker

На все узлы кластера выполняем установку Docker следующей командой:

apt-get install docker docker.io

После установки разрешаем автозапуск сервиса docker:

systemctl enable docker

Создаем файл:

vi /etc/docker/daemon.json

{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2",
  "storage-opts": [
    "overlay2.override_kernel_check=true"
  ]
}

* для нас является важной настройкой cgroupdriver — она должна быть выставлена в значение systemd. В противном случае, при создании кластера Kubernetes выдаст предупреждение. Хоть на возможность работы последнего это не влияет, но мы постараемся выполнить развертывание без ошибок и предупреждений со стороны системы.

И перезапускаем docker:

systemctl restart docker

Установка Kubernetes

Установку необходимых компонентов выполним из репозитория. Добавим его ключ для цифровой подписи:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

Создадим файл с настройкой репозитория:

vi /etc/apt/sources.list.d/kubernetes.list

deb https://apt.kubernetes.io/ kubernetes-xenial main

Обновим список пакетов:

apt-get update

Устанавливаем пакеты:

apt-get install kubelet kubeadm kubectl

* где:

kubelet — сервис, который запускается и работает на каждом узле кластера. Следит за работоспособностью подов.
kubeadm — утилита для управления кластером Kubernetes.
kubectl — утилита для отправки команд кластеру Kubernetes.

Нормальная работа кластера сильно зависит от версии установленных пакетов. Поэтому бесконтрольное их обновление может привести к потере работоспособности всей системы. Чтобы этого не произошло, запрещаем обновление установленных компонентов:

apt-mark hold kubelet kubeadm kubectl

Установка завершена — можно запустить команду:

kubectl version --client

… и увидеть установленную версию программы:

Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", GitCommit:"faecb196815e248d3ecfb03c680a4507229c2a56", GitTreeState:"clean", BuildDate:"2021-01-13T13:28:09Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

Наши серверы готовы к созданию кластера.

Создание кластера

По-отдельности, рассмотрим процесс настройки мастер ноды (control-plane) и присоединения к ней двух рабочих нод (worker).

Настройка control-plane (мастер ноды)

Выполняем команду на мастер ноде:

kubeadm init --pod-network-cidr=10.244.0.0/16

* данная команда выполнит начальную настройку и подготовку основного узла кластера. Ключ —pod-network-cidr задает адрес внутренней подсети для нашего кластера.

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

...
Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.0.15:6443 --token f7sihu.wmgzwxkvbr8500al 
    --discovery-token-ca-cert-hash sha256:6746f66b2197ef496192c9e240b31275747734cf74057e04409c33b1ad280321

* данную команду нужно вводить на worker нодах, чтобы присоединить их к нашему кластеру. Можно ее скопировать, но позже мы будем генерировать данную команду по новой.

В окружении пользователя создаем переменную KUBECONFIG, с помощью которой будет указан путь до файла конфигурации kubernetes:

export KUBECONFIG=/etc/kubernetes/admin.conf

Чтобы каждый раз при входе в систему не приходилось повторять данную команду, открываем файл:

vi /etc/environment

И добавляем в него строку:

export KUBECONFIG=/etc/kubernetes/admin.conf

Посмотреть список узлов кластера можно командой:

kubectl get nodes

На данном этапе мы должны увидеть только мастер ноду:

NAME                      STATUS     ROLES                  AGE   VERSION
k8s-master.dmosk.local    NotReady   <none>                 10m   v1.20.2

Чтобы завершить настройку, необходимо установить CNI (Container Networking Interface) — в моем примере это flannel:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

* краткий обзор и сравнение производительности CNI можно почитать в статье на хабре.

Узел управления кластером готов к работе.

Настройка worker (рабочей ноды)

Мы можем использовать команду для присоединения рабочего узла, которую мы получили после инициализации мастер ноды или вводим (на первом узле):

kubeadm token create --print-join-command

Данная команда покажет нам запрос на присоединения новой ноды к кластеру, например:

kubeadm join 192.168.0.15:6443 --token f7sihu.wmgzwxkvbr8500al 
    --discovery-token-ca-cert-hash sha256:6746f66b2197ef496192c9e240b31275747734cf74057e04409c33b1ad280321

Копируем его и используем на двух наших узлах. После завершения работы команды, мы должны увидеть:

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

На мастер ноде вводим:

kubectl get nodes

Мы должны увидеть:

NAME                      STATUS   ROLES                  AGE   VERSION
k8s-master1.dmosk.local   Ready    control-plane,master   18m   v1.20.2
k8s-worker1.dmosk.local   Ready    <none>                 79s   v1.20.2
k8s-worker2.dmosk.local   Ready    <none>                 77s   v1.20.2

Наш кластер готов к работе. Теперь можно создавать поды, развертывания и службы. Рассмотрим эти процессы подробнее.

Pods

Поды — неделимая сущность объекта в Kubernetes. Каждый Pod может включать в себя несколько контейнеров (минимум, 1). Рассмотрим несколько примеров, как работать с подами. Все команды выполняем на мастере.

Создание

Поды создаются командой kubectl, например:

kubectl run nginx --image=nginx:latest --port=80

* в данном примере мы создаем под с названием nginx, который в качестве образа Docker будет использовать nginx (последнюю версию); также наш под будет слушать запросы на порту 80.

Чтобы получить сетевой доступ к созданному поду, создаем port-forward следующей командой:

kubectl port-forward nginx --address 0.0.0.0 8888:80

* в данном примере запросы к кластеру kubernetes на порт 8888 будут вести на порт 80 (который мы использовали для нашего пода).

Команда kubectl port-forward является интерактивной. Ее мы используем только для тестирования. Чтобы пробросить нужные порты в Kubernetes используются Services — об этом будет сказано ниже.

Можно открыть браузер и ввести адрес http://<IP-адрес мастера>:8888 — должна открыться страница приветствия для NGINX.

Просмотр

Получить список всех подов в кластере можно командой:

kubectl get pods

Например, в нашем примере мы должны увидеть что-то на подобие:

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          3m26s

Посмотреть подробную информацию о конкретном поде можно командой:

kubectl describe pods nginx

Запуск команд внутри контейнера

Мы можем запустить одну команду в контейнере, например, такой командой:

kubectl exec nginx -- date

* в данном примере будет запущена команда date внутри контейнера nginx.

Также мы можем подключиться к командной строке контейнера командой:

kubectl exec --tty --stdin nginx -- /bin/bash

Удаление

Для удаления пода вводим:

kubectl delete pods nginx

Использование манифестов

В продуктивной среде управление подами выполняется с помощью специальных файлов с описанием того, как должен создаваться и настраиваться под — манифестов. Рассмотрим пример создания и применения такого манифеста.

Создадим файл формата yml:

vi manifest_pod.yaml

apiVersion: v1
kind: Pod
metadata: 
  name: web-srv
  labels:
    app: web_server
    owner: dmosk
    description: web_server_for_site
spec:
  containers: 
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80
        - containerPort: 443

    - name: php-fpm
      image: php-fpm:latest
      ports:
        - containerPort: 9000

    - name: mariadb
      image: mariadb:latest
      ports:
        - containerPort: 3306

* в данном примере будет создан под с названием web-srv; в данном поде будет развернуто 3 контейнера — nginx, php-fpm и mariadb на основе одноименных образов.

Для объектов Kubernetes очень важное значение имеют метки или labels. Необходимо всегда их описывать. Далее, данные метки могут использоваться для настройки сервисов и развертываний.

Чтобы применить манифест выполняем команду:

kubectl apply -f manifest_pod.yaml

Мы должны увидеть ответ:

pod/web-srv created

Смотрим поды командой:

kubectl get pods

Мы должны увидеть:

NAME      READY   STATUS    RESTARTS   AGE
web-srv   3/3     Ready     0          3m11s

* для Ready мы можем увидеть 0/3 или 1/3 — это значит, что контейнеры внутри пода еще создаются и нужно подождать.

Deployments

Развертывания позволяют управлять экземплярами подов. С их помощью контролируется их восстановление, а также балансировка нагрузки. Рассмотрим пример использования Deployments в Kubernetes.

Создание

Deployment создаем командой со следующим синтаксисом:

kubectl create deploy <название для развертывания> --image <образ, который должен использоваться>

Например:

kubectl create deploy web-set --image nginx:latest

* данной командой мы создадим deployment с именем web-set; в качестве образа будем использовать nginx:latest.

Просмотр

Посмотреть список развертываний можно командой:

kubectl get deploy

Подробное описание для конкретного развертывания мы можем посмотреть так:

kubectl describe deploy web-set

* в данном примере мы посмотрим описание deployment с названием web-set.

Scaling

Как было написано выше, deployment может балансировать нагрузкой. Это контролируется параметром scaling:

kubectl scale deploy web-set --replicas 3

* в данном примере мы указываем для нашего созданного ранее deployment использовать 3 реплики — то есть Kubernetes создаст 3 экземпляра контейнеров.

Также мы можем настроить автоматическую балансировку:

kubectl autoscale deploy web-set --min=5 --max=10 --cpu-percent=75

В данном примере Kubernetes будет создавать от 5 до 10 экземпляров контейнеров — добавление нового экземпляра будет происходить при превышении нагрузки на процессор до 75% и более.

Посмотреть созданные параметры балансировки можно командой:

kubectl get hpa

Редактирование

Для нашего развертывания мы можем изменить используемый образ, например:

kubectl set image deploy/web-set nginx=httpd:latest --record

* данной командой для deployment web-set мы заменим образ nginx на httpd; ключ record позволит нам записать действие в историю изменений.

Если мы использовали ключ record, то историю изменений можно посмотреть командой:

kubectl rollout history deploy/web-set

Перезапустить deployment можно командой:

kubectl rollout restart deploy web-set

Манифест

Как в случае с подами, для создания развертываний мы можем использовать манифесты. Попробуем рассмотреть конкретный пример.

Создаем новый файл:

vi manifest_deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deploy
  labels:
    app: web_server
    owner: dmosk
    description: web_server_for_site
spec:
  replicas: 5
  selector:
    matchLabels:
      project: myweb
  template:
    metadata:
      labels:
        project: myweb
        owner: dmosk
        description: web_server_pod
    spec:
      containers:
        - name: myweb-httpd
          image: httpd:latest
          ports:
            - containerPort: 80
            - containerPort: 443
            
---
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: web-deploy-autoscaling
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myweb-autoscaling
  minReplicas: 5
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 75
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

* в данном манифесте мы создадим deployment и autoscaling. Итого, мы получим 5 экземпляров подов для развертывания web-deploy, которые могут быть расширены до 10 экземпляров. Добавление нового будет происходить при превышении нагрузки на процессор более чем на 75% или потреблением оперативной памяти более чем на 80%.

Чтобы создать объекты с помощью нашего манифеста вводим:

kubectl apply -f manifest_deploy.yaml

Мы должны увидеть:

deployment.apps/web-deploy created
horizontalpodautoscaler.autoscaling/web-deploy-autoscaling created

Объекты web-deploy и web-deploy-autoscaling созданы.

Удаление

Для удаления конкретного развертывания используем команду:

kubectl delete deploy web-set

Для удаления всех развертываний вместо названия deployment указываем ключ —all:

kubectl delete deploy --all

Удалить критерии autoscaling для конкретного развертывания можно командой:

kubectl delete hpa web-set

Удалить все критерии autoscaling можно командой:

kubectl delete hpa --all

Удалить объекты, созданные с помощью манифеста можно командой:

kubectl delete -f manifest_deploy.yaml

Services

Службы позволяют обеспечить сетевую доступность для развертываний. Существует несколько типов сервисов:

ClusterIP — сопоставление адреса с deployments для подключений внутри кластера Kubernetes.
NodePort — для внешней публикации развертывания.
LoadBalancer — сопоставление через внешний балансировщик.
ExternalName — сопоставляет службу по имени (возвращает значение записи CNAME).

Мы рассмотрим первые два варианта.

Привязка к Deployments

Попробуем создать сопоставления для ранее созданного развертывания:

kubectl expose deploy web-deploy --type=ClusterIP --port=80

* где web-deploy — deployment, который мы развернули с помощью манифеста. Публикация ресурса происходит на внутреннем порту 80. Обращаться к контейнерам можно внутри кластера Kubernetes.

Для создания сопоставления, с помощью которого можно будет подключиться к контейнерам из внешней сети выполняется командой:

kubectl expose deploy web-deploy --type=NodePort --port=80

* данная команда отличается от команды выше только типом NodePort — для данному deployment будет сопоставлен порт для внешнего подключения, который будет вести на внутренний (в нашем примере, 80).

Просмотр

Чтобы посмотреть созданные нами службы, вводим:

kubectl get services

Мы можем увидеть что-то на подобие:

NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
web-deploy   NodePort    10.111.229.132   <none>        80:30929/TCP   21s

* в данном примере указано, что у нас есть служба типа NodePort, а к сервису можно подключиться по порту 30929.

Можно попробовать открыть браузер и ввести http://<IP-адрес мастера>:30929 — мы должны увидеть нужную нам страницу (в наших примерах, либо NGINX, либо Apache).

Посмотреть список сервисов с указанием селектором можно командой:

kubectl get services -o wide

Удаление

Удаляем созданную службу командой:

kubectl delete services web-deploy

* в данном примере будет удалена служба для развертывания web-deploy.

Удалить все службы можно командой:

kubectl delete services --all

Манифест

Как в случае с подами и развертываниями, мы можем использовать манифест-файлы. Рассмотрим небольшой пример.

vi manifest_service.yaml

apiVersion: v1
kind: Service
metadata:
  name: web-service
  labels:
    app: web_server
    owner: dmosk
    description: web_server_for_site
spec:
  selector:
    project: myweb
  type: NodePort
  ports:
    - name: app-http
      protocol: TCP
      port: 80
      targetPort: 80

    - name: app-smtp
      protocol: TCP
      port: 25
      targetPort: 25

* в данном примере мы создадим службу, которая будем связываться с развертыванием по лейболу project: myweb.

Ingress Controller

В данной инструкции не будет рассказано о работе с Ingress Controller. Оставляем данный пункт для самостоятельного изучения.

Данное приложение позволяет создать балансировщик, распределяющий сетевые запросы между нашими сервисами. Порядок обработки сетевого трафика определяем с помощью Ingress Rules.

Существует не маленькое количество реализаций Ingress Controller — их сравнение можно найти в документе по ссылке в Google Docs.

Для установки Ingress Controller Contour (среди множества контроллеров, он легко устанавливается и на момент обновления данной инструкции полностью поддерживает последнюю версию кластера Kubernetes) вводим:

kubectl apply -f https://projectcontour.io/quickstart/contour.yaml

Установка веб-интерфейса

Веб-интерфейс позволяет получить информацию о работе кластера в удобном для просмотра виде.

В большинстве инструкций рассказано, как получить доступ к веб-интерфейсу с того же компьютера, на котором находится кластер (по адресу 127.0.0.1 или localhost). Но мы рассмотрим настройку для удаленного подключения, так как это более актуально для серверной инфраструктуры.

Переходим на страницу веб-интерфейса в GitHub и копируем ссылку на последнюю версию файла yaml:

Копируем ссылку на конфигурационный файл для создания панели управления Kubernetes

* на момент обновления инструкции, последняя версия интерфейса была 2.1.0.

Скачиваем yaml-файл командой:

wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.1.0/aio/deploy/recommended.yaml

* где https://raw.githubusercontent.com/kubernetes/dashboard/v2.1.0/aio/deploy/recommended.yaml — ссылка, которую мы скопировали на портале GitHub.

Открываем на редактирование скачанный файл:

vi recommended.yaml

Комментируем строки для kind: Namespace и kind: Secret (в файле несколько блоков с kind: Secret — нам нужен тот, что с name: kubernetes-dashboard-certs):

...
#apiVersion: v1
#kind: Namespace
#metadata:
#  name: kubernetes-dashboard
...
#apiVersion: v1
#kind: Secret
#metadata:
#  labels:
#    k8s-app: kubernetes-dashboard
#  name: kubernetes-dashboard-certs
#  namespace: kubernetes-dashboard
#type: Opaque

* нам необходимо закомментировать эти блоки, так как данные настройки в Kubernetes мы должны будем сделать вручную.

Теперь в том же файле находим kind: Service (который с name: kubernetes-dashboard) и добавляем строки type: NodePort и nodePort: 30001 (выделены красным):

kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
spec:
  type: NodePort
  ports:
    - port: 443
      targetPort: 8443
      nodePort: 30001
  selector:
    k8s-app: kubernetes-dashboard

* таким образом, мы публикуем наш сервис на внешнем адресе и порту 30001.

Для подключения к веб-интерфейсу не через локальный адрес, начиная с версии 1.17, обязательно необходимо использовать зашифрованное подключение (https). Для этого нужен сертификат. В данной инструкции мы сгенерируем самоподписанный сертификат — данный подход удобен для тестовой среды, но в продуктивной среде необходимо купить сертификат или получить его бесплатно в Let’s Encrypt.

И так, создаем каталог, куда разместим наши сертификаты:

mkdir -p /etc/ssl/kubernetes

Сгенерируем сертификаты командой:

openssl req -new -x509 -days 1461 -nodes -out /etc/ssl/kubernetes/cert.pem -keyout /etc/ssl/kubernetes/cert.key -subj "/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=kubernetes.dmosk.local/CN=kubernetes"

* можно не менять параметры команды, а так их и оставить. Браузер все-равно будет выдавать предупреждение о неправильном сертификате, так как он самоподписанный.

Создаем namespace:

kubectl create namespace kubernetes-dashboard

* это та первая настройка, которую мы комментировали в скачанном файле recommended.yaml.

Теперь создаем настройку для secret с использованием наших сертификатов:

kubectl create secret generic kubernetes-dashboard-certs --from-file=/etc/ssl/kubernetes/cert.key --from-file=/etc/ssl/kubernetes/cert.pem -n kubernetes-dashboard

* собственно, мы не использовали настройку в скачанном файле, так как создаем ее с включением в параметры пути до созданных нами сертификатов.

Теперь создаем остальные настройки с помощью скачанного файла:

kubectl create -f recommended.yaml

Мы увидим что-то на подобие:

serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created

Создадим настройку для админского подключения:

vi dashboard-admin.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: dashboard-admin
  namespace: kubernetes-dashboard

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dashboard-admin-bind-cluster-role
  labels:
    k8s-app: kubernetes-dashboard
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: dashboard-admin
  namespace: kubernetes-dashboard

Создаем настройку с применением созданного файла:

kubectl create -f dashboard-admin.yaml

Теперь открываем браузер и переходим по ссылке https://<IP-адрес мастера>:30001 — браузер покажет ошибку сертификата (если мы настраиваем по инструкции и сгенерировали самоподписанный сертификат). Игнорируем ошибку и продолжаем загрузку.

Kubernetes Dashboard потребует пройти проверку подлинности. Для этого можно использовать токен или конфигурационный файл:

На сервере вводим команду для создания сервисной учетной записи:

kubectl create serviceaccount dashboard-admin -n kube-system

Создадим привязку нашего сервисного аккаунта с Kubernetes Dashboard:

kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin

Теперь камандой:

kubectl describe secrets -n kube-system $(kubectl -n kube-system get secret | awk '/dashboard-admin/{print $1}')

… получаем токен для подключения (выделен красным):

Data
====
ca.crt:     1066 bytes
namespace:  11 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IkpCT0J5TWF2VWxWQUotdHZYclFUaWwza2NfTW1IZVNuSlZSN3hWUzFrNTAifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkYXNoYm9hcmQtYWRtaW4tdG9rZW4tbnRqNmYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGFzaGJvYXJkLWFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiMzIwNjVhYmQtNzAwYy00Yzk5LThmZjktZjc0YjM5MTU0Y2VhIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmRhc2hib2FyZC1hZG1pbiJ9.wvDGeNiTCRBakDplO6PbdqvPH_W2EsBgJjZnTDflneP3cdXQv6VgBkI8NalplXDRF-lF36KbbC2hpRjbkblrLW7BemIVWYOznmc8kmrgCSxO2FVi93NK3biE9TkDlj1BbdiyfOO86L56vteXGP20X0Xs1h3cjAshs-70bsnJl6z3MY5GbRVejOyVzq_PWMVYsqvQhssExsJM2tKJWG0DnXCW687XHistbYUolhxSRoRpMZk-JrguuwgLH5FYIIU-ZdTZA6mz-_hqrx8PoDvqEfWrsniM6Q0k8U3TMaDLlduzA7rwLRJBQt3C0aD6XfR9wHUqUWd5y953u67wpFPrSA

Используя полученный токен, вводим его в панели авторизации:

Мы должны увидеть стартовое окно системы управления:

Удаление нод

При необходимости удалить ноду из нашего кластера, вводим 2 команды:

kubectl drain k8s-worker2.dmosk.local --ignore-daemonsets

kubectl delete node k8s-worker2.dmosk.local

* в данном примере мы удаляем ноду k8s-worker2.dmosk.local.

Источник: https://www.dmosk.ru/instruktions.php?object=kubernetes-ubuntu

2021-06-16T00:10:08

Software

📚 Осваиваем Kubernetes. Оркестрация контейнерных архитектур

В книге рассмотрена новейшая версия Kubernetes 1.10.

Kubernetes – это система с открытым кодом, предназначенная для работы с контейнерными приложениями, их развертывания, масштабирования, управления ими.

Если вы хотите запустить дополнительные контейнеры или автоматизировать управление, то вам не обойтись без Kubernetes.

Книга начинается с изучения основ Kubernetes, архитектуры и компоновки этой системы. Читать →

Навигация

Работа с ресурсами

Другие возможности

Benchmark

Интерфейс

Плагины

Заключение

Как удалить поды в Kubernetes

Использование собственных команд kubectl и Bash

Использование фильтров kubectl и jq

Подготовка системы

Настройка системы

Брандмауэр

Установка и настройка Docker

Установка Kubernetes

Создание кластера

Настройка control-plane (мастер ноды)

Настройка worker (рабочей ноды)

Pods

Создание

Просмотр

Запуск команд внутри контейнера

Удаление

Использование манифестов

Deployments

Создание

Просмотр

Scaling

Редактирование

Манифест

Удаление

Services

Привязка к Deployments

Просмотр

Удаление

Манифест

Ingress Controller

Установка веб-интерфейса

Удаление нод