User Tools

Site Tools


Sidebar

Me
Здравствуйте!

Меня зовут Михаил Усик!
Я системный администратор
и наполняю эту wiki,
решая разнообразные IT-задачки.

Я всегда готов помочь Вам
наладить IT-инфраструктуру
за скромное вознаграждение!

mike@autosys.tk
+7 (977) 887-96-23

linux_faq:kubernetes

Table of Contents

Материалов про kubernetes очень много. В процессе обучения просто я фиксирую для себя то что считаю важным. Это не тутораил и не гайд. Это просто мои заметки.

Docker

Сборка контейнера docker

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

FROM node:7
ADD app.js /app.js
ENTRYPOINT ["node", "app.js"]

В одной директории с Dockerfile размещаем файл приложения app.js и собираем:

docker build -t kubia .

Смотрим что контейнер собрался:

docker images

Запуск контейнера вручную в локальном Docker

docker run --name kubia-container -p 8080:8080 -d kubia

В результате будет запущен новый контейнер с именем kubia-container из образа kubia. Контейнер будет отсоединен от консоли (флаг -d), а порт 8080 на локальной машине будет увязан с портом 8080 внутри контейнера.

Список всех запущенных контейнеров

docker ps

Получение дополнительной информации о контейнере

docker inspect kubia-container

Запуск bash shell внутри существующего контейнера

docker exec -it kubia-container bash  
* **-i** убеждается, что STDIN держится открытым для ввода команд в оболочку;
* **-t** выделяет псевдотерминал (TTY).

Остановка и удаление контейнера

docker stop kubia-container
docker rm kubia-container

Тегирование образа тегом

Образ контейнера может иметь несколько тегов:

docker tag kubia luksa/kubia

Передача образа в хранилище docker hub

docker push luksa/kubia

Запуск образа на другой машине

docker run -p 8080:8080 -d luksa/kubia

Просмотр журналов контейнера docker

docker logs <container_ID>

Запуск приложения в среде kubernetes

kubectl run kubia --image=luksa/kubia --port=8080 --generator=run/v1

kubectl run создаст все необходимые компоненты без необходимости декларировать компоненты с помощью JSON или YAML.
–generator=run/v1 - нужен для того, чтобы текущая версия kubernetes не создавала Deployment, а создала ReplicationController. В результате будет создан Pod с одним контейнером kubia.
При выполнении команды произошло следующее:

  • команда kubectl создала в кластере новый объект контроллера репликации (ReplicationController)
  • контроллер репликации создал новый Pod, который планировщик запланировал для одного из рабочих узлов.
  • Агент Kubelet на этом узле увидел, что модуль был назначен рабочему узлу, и поручил платформе Docker выгрузить указанный образ из хранилища, После скачивания образа платформа Docker создала и запустила контейнер.

Получение списка pods

kubectl get pods

Вывод списка Pod'ов с дополнительной информацией:

kubectl get pods -o wide

Получение доступа к приложению в контейнере

Для доступа к приложению используются объекты Service. Они привязывают динамически разворачиваемые экземпляры приложения к статичным IP-адресам и портам:

kubectl expose rc kubia --type=LoadBalancer --name kubia-http 

В данном случае - создается объект Service с именем kubia-http типа LoadBalancer, который указывает на экземпляры приложения, за которыми следит ReplicatioController (rc) с именем kubia.

Вывод списка Services

kubectl get services 

или

kubectl get svc

Увеличение количества реплик

Увеличить количество запущенных реплик Pod'а на контроллере репликации:

kubectl scale rc kubia --replicas=3

Получение полного описания объекта kubernetes

kubectl describe rc kubia

Создание объекта kubernetes с помощью файла описания

kubectl create -f filename.yml

Сеть

Внутри кластера kubernetes между подами (Pods) сеть плоская. Без шлюзов и трансляциий (nat-snat).

Под - Pod

Базовое описание pod'а

apiVersion: v1                     # Версия API
kind: Pod                          # Тип объекта - pod
metadata:                          # Начало секции метаданных
  name: kubia-manual               # имя Pod'a
spec:                              # начало секции спецификации
  containers:                      # начало секции, описывающей контейнеры pod'а
  – image: luksa/kubia             # начало описания первого контейнера. используется образ luksa/kubia 
    name: kubia                    # Имя контейнера в pod'е
    ports:                         # секция портов, используемых приложением в контейнере
    – containerPort: 8080          # номер порта
      protocol: TCP                # используемый протокол

Создание pod'а с помощью файла описания

kubectl create -f kubia-manual.yaml

Удаление pod'ов

kubectl delete po kubia-gpu

Или с помощью селектора по метке:

kubectl delete po -l creation_method=manual

Просмотр логов pod'а

kubectl logs kubia-manual

Если в pod'е больше одного контейнера, то увидеть логи конкретного контейнера можно так:

kubectl logs kubia-manual -c kubia

Маппинг локального порта на порт в pod'е без использования service

Иногда для отладки нужно просто сделать так, чтобы порт pod'а стал доступен на локальной машине. Без создания service. Это делается так:

kubectl port-forward kubia-manual 8888:8080

В результате приложение pod'а (порт 8080) станет доступно на локальной машине на порте 8888.

Метки

Метки могут быть созданы для многих объектов. В примерах рассматриваются pod'ы.

Создание и изменение меток (labels)

Метки позволяют разделять pod'ы по некоторому признаку и обращаться к ним.

kubectl label po kubia-manual creation_method=manual

Метки могут быть прописаны в секции метаданных:

apiVersion: v1
kind: Pod
metadata:
  name: kubia-manual-v2
  labels:
    creation_method: manual
    env: prod

При изменении существующих меток нужно использовать параметр –overwrite.

kubectl label po kubia-manual-v2 env=debug --overwrite

Список всех pod'ов и их меток

kubectl get po --show-labels

Список pod'ов у которых (не)установлены заданные метки

kubectl get po -l creation_method,env
kubectl get po -l '!env',creation_method

Список pod'ов с заданными значениями меток

kubectl get po -l creation_method=manual

Список pod'ов со значениями меток отличными от заданного

kubectl get po -l creation_method!=manual

Установка метки на узел (node) и привязка pod'а к нему

Устанавливаем метку на узел:

kubectl label node gke-kubia-85f6-node-0rrx gpu=true

Описываем привязку в декларации pod'а:

apiVersion: v1
kind: Pod
metadata:
  name: kubia-gpu
spec:
  nodeSelector:
    gpu: "true"                #селектор узла с меткой gpu
  containers:
  – image: luksa/kubia
    name: kubia

Или к узлу с заданным именем:

apiVersion: v1
kind: Pod
metadata:
  name: kubia-gpu
spec:
  nodeSelector:
    kubernetes.io/hostname: "desired.node.hostname"                #селектор узла по его hostname
  containers:
  – image: luksa/kubia
    name: kubia

Пространства имен (namespaces)

Список доступных пространств имен (неймспейсов)

kubectl get ns

Список pod'ов неймспейса

kubectl get po --namespace kube-syste

Создание неймспейсов

kubectl create namespace custom-namespace

Или декларативно с помощью файла yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: custom-namespace

и затем

kubectl create -f custom-namespace.yaml

Создание объектов в заданном неймспейсе

kubectl create -f kubia-manual.yaml -n custom-namespace

Переключение между неймспейсами

kubectl  config  set-context $(kubectl config currentcontext) --namespace custom-namespace

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

alias  kcd='kubectl  config  set-context $(kubectl config currentcontext) --namespace '

прописать его в ~/.bash.rc и затем переключаться между пространствами имен с помощью

kcd some-namespace

Удаление неймспейса со всем содержимым

kubectl delete ns custom-namespace

Удаление содержимого неймспейса с сохранением неймспейса

Удаление pod'ов

kubectl delete po --all

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

kubectl delete all --all




















Глоссарий

  • Kubernetes - система оркестрации контейнеров docker.
  • Nodes (node.md): Нода это машина в кластере Kubernetes.
  • Pods (pods.md): Pod это группа контейнеров с общими разделами, запускаемых как единое целое.
  • ReplicaSet - набор экземпляров (реплик) какого-то pod'а. ReplicaSet - это более функциональные Replication Controllers. Сейчас они сосуществуют, но в дальнейшем останутся только ReplicaSet.
  • Deployment - набор экземпляров pod'а, для которого можно произвести обновление. При обновлении экземпляры будут по одному замещаться новыми версиями (rolling update). Таким образом реализуется zero downtime при обновлениях. Описывается с помощью yml-файла, содержащего спецификации (spec).
  • Services (services.md): Сервис в Kubernetes это абстракция (описывается yml-файлом) которая определяет логический объединённый набор pod и политику доступа к ним. Например - сервис типа LoadBalancer балансирует нагрузку между подами деплоймента. В простейшем случае - сервис просто пробрасывает порт для доступа к приложению.
  • Volumes (volumes.md): Volume(раздел) это директория, возможно, с данными в ней, которая доступна в контейнере.
  • Labels (labels.md): Label'ы это пары ключ/значение которые прикрепляются к объектам, например pod'ам. Label'ы могут быть использованы для создания и выбора наборов объектов.
  • Kubectl Command Line Interface (kubectl.md): kubectl интерфейс командной строки для управления Kubernetes.
  • Config Map - yml-файлик, содержащий некоторую конфигурационную информацию (например описание сервера nginx). В дальнейшем, содержимое Config Map монтируется в контейнер в файлик в заданную директорию. Инструкции для монтирования содержатся в описании deployment'а.

Архитектура

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

  • kubelet - компоненты, которые работают на нодах кластера и обеспечивают запуск сервисов на них.
  • master components - компоненты, необходимые для управления кластером (APIs, scheduler, etc).

Deployment в кластер kubernetes

Для деплоймента в кластер kubernetes нужно описать в docker-файлах сервисы Pod'а. Порядок такой:

  • создаем docker-файлик.
  • собираем контейнер
  • помещаем (push) контейнер в репозиторий контейнеров docker (cloud.docker.com)

В кластере kubernetes создаем namespace (логичекий контейнер для pod'ов, деплойментов (deployments) и т.д.)

kubectl create namespace _name_

Для деплоймента в kubernetes нужно описать три сущности:

  • Сам deployment, в котором описано какие docker-контейнеры нужно загрузить в pod, сколько таких pod'ов создать, а также какую конфигурацию применить к контейнерам (с помощью ConfigMap'ов).
  • ConfigMap'ы, которые содержат конфигурационные файлы, необходимые для работы приложений контейнерах. Например - конфигурация nginx для контейнера с nginx.
  • Service - способ доступа к приложениям в контейнерах (балансировка и проброс портов).

Ход обновления:

  • клонируем исходник из git.
  • собираем его.
  • собираем docker-контейнер с новым тегом версии, содержащий файлы приложения (docker build)
  • помещаем docker-контейнер в docker registry (docker push)
  • указываем в деплойменте тег новой версии контейнера.
  • применяем deployment (kubectl apply) в результате чего обновятся pod'ы.

Для автоматизации с помощью GitLab:

  • в свойствах проекта создаем Runner
  • по инструкци устанавливаем gitlab-runner и добавляем пользователя gitlab-runner в группу докера, для того, чтобы раннер мог запускать деплоймент.
  • после установки gitlab-runner его нужно зарегистрировать (gitlab-runner register)
  • В конфиге раннера прописываются стадии: build и deploy. build включает в себя создание докерконтейнера, пригодного для деплоя.

Ссылки

DevOps

Мониторинг веб-приложения - graphana

Discussion

Enter your comment. Wiki syntax is allowed:
Q A​ E T T
 
linux_faq/kubernetes.txt · Last modified: 2019/05/29 12:39 by admin