Kubernetes - Краткое руководство

Kubernetes в инструменте управления контейнерами с открытым исходным кодом, размещенном Cloud Native Computing Foundation (CNCF). Это также известно как расширенная версия Borg, которая была разработана в Google для управления как длительными процессами, так и пакетными заданиями, которые ранее обрабатывались отдельными системами.

Kubernetes позволяет автоматизировать развертывание, масштабирование приложения и операции с контейнерами приложений в кластерах. Он способен создавать инфраструктуру, ориентированную на контейнер.

Особенности Kubernetes

Ниже приведены некоторые из важных особенностей Kubernetes.

• Продолжает разработку, интеграцию и развертывание

• Контейнерная инфраструктура

• Управление, ориентированное на приложения

• Автоматически масштабируемая инфраструктура

• Согласованность среды при разработке, тестировании и производстве

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

• Более высокая плотность использования ресурсов

• Предсказуемая инфраструктура, которая будет создана

Одним из ключевых компонентов Kubernetes является то, что он может запускать приложения в кластерах инфраструктуры физических и виртуальных машин. Он также имеет возможность запускать приложения в облаке.It helps in moving from host-centric infrastructure to container-centric infrastructure.

В этой главе мы обсудим базовую архитектуру Kubernetes.

Kubernetes - кластерная архитектура

Как видно на следующей диаграмме, Kubernetes следует архитектуре клиент-сервер. При этом мастер установлен на одной машине, а узел - на разных машинах Linux.

Ключевые компоненты мастера и узла определены в следующем разделе.

Kubernetes - основные компоненты машины

Ниже приведены компоненты Kubernetes Master Machine.

etcd

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

API-сервер

Kubernetes - это сервер API, который обеспечивает все операции в кластере с помощью API. Сервер API реализует интерфейс, что означает, что различные инструменты и библиотеки могут легко взаимодействовать с ним.Kubeconfigпредставляет собой пакет вместе с инструментами на стороне сервера, которые можно использовать для связи. Он предоставляет Kubernetes API.

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

Этот компонент отвечает за большинство коллекторов, которые регулируют состояние кластера и выполняют задачу. В общем, его можно рассматривать как демон, который работает в непрерывном цикле и отвечает за сбор и отправку информации на сервер API. Он работает для получения общего состояния кластера, а затем вносит изменения, чтобы привести текущий статус сервера в желаемое состояние. Ключевыми контроллерами являются контроллер репликации, контроллер конечной точки, контроллер пространства имен и контроллер учетной записи службы. Диспетчер контроллеров запускает различные типы контроллеров для обработки узлов, конечных точек и т. Д.

Планировщик

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

Kubernetes - Компоненты узла

Ниже приведены ключевые компоненты сервера Node, которые необходимы для связи с мастером Kubernetes.

Докер

Первое требование к каждому узлу - это Docker, который помогает запускать инкапсулированные контейнеры приложений в относительно изолированной, но легкой операционной среде.

Кубелет Сервис

Это небольшая служба в каждом узле, отвечающая за передачу информации в службу уровня управления и обратно. Он взаимодействует сetcdstore для чтения деталей конфигурации и значений параметров. Он взаимодействует с главным компонентом для получения команд и работы. ВkubeletЗатем процесс берет на себя ответственность за поддержание состояния работы и сервера узла. Он управляет сетевыми правилами, переадресацией портов и т. Д.

Прокси-сервис Kubernetes

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

Kubernetes - Мастер и структура узла

На следующих иллюстрациях показана структура Kubernetes Master и Node.

Перед настройкой Kubernetes важно настроить Virtual Datacenter (vDC). Это можно рассматривать как набор машин, на которых они могут связываться друг с другом через сеть. Для практического использования вы можете настроить vDC наPROFITBRICKS если у вас не настроена физическая или облачная инфраструктура.

После завершения настройки IaaS в любом облаке вам необходимо настроить Master и Node.

Note- Настройка показана для машин с Ubuntu. То же самое можно настроить и на других машинах Linux.

Предпосылки

Installing Docker- Docker требуется на всех экземплярах Kubernetes. Ниже приведены шаги по установке Docker.

Step 1 - Войдите в систему с учетной записью пользователя root.

Step 2- Обновите информацию о пакете. Убедитесь, что пакет apt работает.

Step 3 - Выполните следующие команды.

$ sudo apt-get update $ sudo apt-get install apt-transport-https ca-certificates

Step 4 - Добавьте новый ключ GPG.

$ sudo apt-key adv \ --keyserver hkp://ha.pool.sks-keyservers.net:80 \ --recv-keys 58118E89F3A912897C070ADBF76221572C52609D $ echo "deb https://apt.dockerproject.org/repo ubuntu-trusty main" | sudo tee
/etc/apt/sources.list.d/docker.list

Step 5 - Обновите образ пакета API.

$ sudo apt-get update

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

Установить Docker Engine

Выполните следующие команды, чтобы установить ядро ​​Docker.

Step 1 - Войдите в систему.

Step 2 - Обновите индекс пакета.

$ sudo apt-get update

Step 3 - Установите Docker Engine с помощью следующей команды.

$ sudo apt-get install docker-engine

Step 4 - Запустите демон Docker.

$ sudo apt-get install docker-engine

Step 5 - Чтобы установить Docker, используйте следующую команду.

$ sudo docker run hello-world

Установить etcd 2.0

Его необходимо установить на Kubernetes Master Machine. Чтобы установить его, выполните следующие команды.

$ curl -L https://github.com/coreos/etcd/releases/download/v2.0.0/etcd
-v2.0.0-linux-amd64.tar.gz -o etcd-v2.0.0-linux-amd64.tar.gz ->1
$ tar xzvf etcd-v2.0.0-linux-amd64.tar.gz ------>2 $ cd etcd-v2.0.0-linux-amd64 ------------>3
$ mkdir /opt/bin ------------->4 $ cp etcd* /opt/bin ----------->5

В приведенном выше наборе команд -

• Сначала мы загружаем etcd. Сохраните это с указанным именем.
• Затем нам нужно разархивировать tar-пакет.
• Делаем реж. внутри / opt с именем bin.
• Скопируйте извлеченный файл в целевое расположение.

Теперь мы готовы построить Kubernetes. Нам нужно установить Kubernetes на все машины кластера.

$ git clone https://github.com/GoogleCloudPlatform/kubernetes.git $ cd kubernetes
$ make release

Приведенная выше команда создаст _outputdir в корне папки kubernetes. Затем мы можем извлечь каталог в любой из выбранных нами каталогов / opt / bin и т. Д.

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

$ echo "<IP address of master machine> kube-master
< IP address of Node Machine>" >> /etc/hosts

Ниже будет вывод вышеуказанной команды.

Теперь мы начнем с реальной конфигурации Kubernetes Master.

Сначала мы начнем копировать все файлы конфигурации в их правильное место.

$ cp <Current dir. location>/kube-apiserver /opt/bin/ $ cp <Current dir. location>/kube-controller-manager /opt/bin/
$ cp <Current dir. location>/kube-kube-scheduler /opt/bin/ $ cp <Current dir. location>/kubecfg /opt/bin/
$ cp <Current dir. location>/kubectl /opt/bin/ $ cp <Current dir. location>/kubernetes /opt/bin/

Приведенная выше команда скопирует все файлы конфигурации в необходимое место. Теперь мы вернемся в тот же каталог, где мы создали папку Kubernetes.

$ cp kubernetes/cluster/ubuntu/init_conf/kube-apiserver.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/init_conf/kube-controller-manager.conf /etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-kube-scheduler.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kube-apiserver /etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-controller-manager /etc/init.d/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kube-kube-scheduler /etc/init.d/

$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/ $ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy /etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/

Следующим шагом будет обновление скопированного файла конфигурации в / etc. реж.

Настройте etcd на главном сервере, используя следующую команду.

$ ETCD_OPTS = "-listen-client-urls = http://kube-master:4001"

Настроить kube-apiserver

Для этого на мастере нам нужно отредактировать /etc/default/kube-apiserver файл, который мы скопировали ранее.

$ KUBE_APISERVER_OPTS = "--address = 0.0.0.0 \
--port = 8080 \
--etcd_servers = <The path that is configured in ETCD_OPTS> \
--portal_net = 11.1.1.0/24 \
--allow_privileged = false \
--kubelet_port = < Port you want to configure> \
--v = 0"

Настроить kube Controller Manager

Нам нужно добавить следующий контент в /etc/default/kube-controller-manager.

$ KUBE_CONTROLLER_MANAGER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--machines = kube-minion \ -----> #this is the kubernatics node
--v = 0

Затем настройте планировщик kube в соответствующем файле.

$ KUBE_SCHEDULER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--v = 0"

После того, как все вышеперечисленные задачи будут выполнены, мы можем продолжить и запустить Kubernetes Master. Для этого мы перезапустим Docker.

$ service docker restart

Конфигурация узла Kubernetes

Узел Kubernetes будет запускать две службы: kubelet and the kube-proxy. Прежде чем двигаться дальше, нам нужно скопировать загруженные двоичные файлы в соответствующие папки, где мы хотим настроить узел kubernetes.

Используйте тот же метод копирования файлов, который мы использовали для мастера kubernetes. Поскольку он будет запускать только kubelet и kube-proxy, мы настроим их.

$ cp <Path of the extracted file>/kubelet /opt/bin/ $ cp <Path of the extracted file>/kube-proxy /opt/bin/
$ cp <Path of the extracted file>/kubecfg /opt/bin/ $ cp <Path of the extracted file>/kubectl /opt/bin/
$ cp <Path of the extracted file>/kubernetes /opt/bin/

Теперь мы скопируем содержимое в соответствующий каталог.

$ cp kubernetes/cluster/ubuntu/init_conf/kubelet.conf /etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-proxy.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kubelet /etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-proxy /etc/init.d/ $ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy /etc/default/

Мы настроим kubelet и kube-proxy conf файлы.

Мы настроим /etc/init/kubelet.conf.

$ KUBELET_OPTS = "--address = 0.0.0.0 \
--port = 10250 \
--hostname_override = kube-minion \
--etcd_servers = http://kube-master:4001 \
--enable_server = true
--v = 0"
/

Для kube-proxy мы настроим с помощью следующей команды.

$ KUBE_PROXY_OPTS = "--etcd_servers = http://kube-master:4001 \
--v = 0"
/etc/init/kube-proxy.conf

Наконец, мы перезапустим службу Docker.

$ service docker restart

Теперь мы закончили настройку. Вы можете проверить это, выполнив следующие команды.

$ /opt/bin/kubectl get minions

Образы Kubernetes (Docker) являются ключевыми строительными блоками контейнерной инфраструктуры. На данный момент мы поддерживаем Kubernetes только для поддержки образов Docker. У каждого контейнера в модуле есть свой образ Docker, работающий внутри него.

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

Ниже приводится общая структура конфигурации, которая извлекает образ из реестра Docker и развертывает его в контейнере Kubernetes.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
      containers:
         - name: neo4j-server ------------------------> 2
         image: <Name of the Docker image>----------> 3
         imagePullPolicy: Always ------------->4
         command: ["echo", "SUCCESS"] ------------------->

В приведенном выше коде мы определили -

• name: Tesing_for_Image_pull - Это имя дается для идентификации и проверки имени контейнера, который будет создан после извлечения образов из реестра Docker.

• name: neo4j-server- Это имя, данное контейнеру, который мы пытаемся создать. Вроде мы дали neo4j-server.

• image: <Name of the Docker image>- Это имя образа, который мы пытаемся извлечь из Docker или внутреннего реестра образов. Нам нужно определить полный путь к реестру вместе с именем образа, который мы пытаемся извлечь.

• imagePullPolicy - Всегда - эта политика извлечения изображений определяет, что всякий раз, когда мы запускаем этот файл для создания контейнера, он снова будет извлекать то же имя.

• command: [“echo”, “SUCCESS”] - При этом, когда мы создаем контейнер, и если все пойдет хорошо, он отобразит сообщение, когда мы получим доступ к контейнеру.

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

$ kubectl create –f Tesing_for_Image_pull

Как только мы получим журнал, мы получим результат как успешный.

$ kubectl log Tesing_for_Image_pull

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

Note - Рекомендуется попробовать все команды самостоятельно.

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

Создание работы

Используйте следующую команду для создания работы -

apiVersion: v1
kind: Job ------------------------> 1
metadata:
   name: py
   spec:
   template:
      metadata
      name: py -------> 2
      spec:
         containers:
            - name: py ------------------------> 3
            image: python----------> 4
            command: ["python", "SUCCESS"]
            restartPocliy: Never --------> 5

В приведенном выше коде мы определили -

• kind: Job → Мы определили вид как Иов, который скажет kubectl что yaml файл используется для создания модуля типа задания.

• Name:py → Это имя шаблона, который мы используем, и спецификация определяет шаблон.

• name: py → мы дали имя как py в соответствии со спецификацией контейнера, которая помогает идентифицировать под, который будет создан из него.

• Image: python → изображение, которое мы собираемся использовать для создания контейнера, который будет работать внутри модуля.

• restartPolicy: Never →Это условие перезапуска образа задано как никогда, что означает, что если контейнер убит или если оно ложно, то он не перезапустится сам.

Мы создадим задание, используя следующую команду с yaml, которая сохраняется под именем py.yaml.

$ kubectl create –f py.yaml

Приведенная выше команда создаст задание. Если вы хотите проверить статус задания, используйте следующую команду.

$ kubectl describe jobs/py

Приведенная выше команда создаст задание. Если вы хотите проверить статус задания, используйте следующую команду.

Запланированная работа

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

• Планирование задания запускает модуль в указанный момент времени.
• Для него создается пародийное задание, которое запускается автоматически.

Note - Функция запланированного задания поддерживается версией 1.4, а API betch / v2alpha 1 включается путем передачи –runtime-config=batch/v2alpha1 при вызове сервера API.

Мы будем использовать тот же yaml, который мы использовали для создания задания, и сделаем его запланированным.

apiVersion: v1
kind: Job
metadata:
   name: py
spec:
   schedule: h/30 * * * * ? -------------------> 1
   template:
      metadata
         name: py
      spec:
         containers:
         - name: py
         image: python
         args:
/bin/sh -------> 2
-c
ps –eaf ------------> 3
restartPocliy: OnFailure

В приведенном выше коде мы определили -

• schedule: h/30 * * * * ? → Чтобы запланировать запуск задания каждые 30 минут.

• /bin/sh: Это войдет в контейнер с / bin / sh

• ps –eaf → Запустит команду ps -eaf на машине и выведет список всех запущенных процессов внутри контейнера.

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

Этикетки

Ярлыки - это пары ключ-значение, которые прикрепляются к модулям, контроллеру репликации и службам. Они используются в качестве идентифицирующих атрибутов для таких объектов, как модули и контроллер репликации. Они могут быть добавлены к объекту во время создания и могут быть добавлены или изменены во время выполнения.

Селекторы

Этикетки не обеспечивают уникальности. В общем, можно сказать, что многие объекты могут иметь одинаковые метки. Селектор меток - это основной примитив группировки в Kubernetes. Они используются пользователями для выбора набора объектов.

Kubernetes API в настоящее время поддерживает два типа селекторов:

• Селекторы на основе равенства
• Селекторы на основе набора

Селекторы на основе равенства

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

Селекторы на основе наборов

Селекторы на основе набора позволяют фильтровать ключи в соответствии с набором значений.

apiVersion: v1
kind: Service
metadata:
   name: sp-neo4j-standalone
spec:
   ports:
      - port: 7474
      name: neo4j
   type: NodePort
   selector:
      app: salesplatform ---------> 1
      component: neo4j -----------> 2

В приведенном выше коде мы используем селектор меток как app: salesplatform и компонент как component: neo4j.

Как только мы запустим файл с помощью kubectl команда, она создаст службу с именем sp-neo4j-standalone который будет связываться через порт 7474. Тип NodePort с новым селектором меток как app: salesplatform и component: neo4j.

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

Функциональность пространства имен

Ниже приведены некоторые из важных функций пространства имен в Kubernetes.

• Пространства имен помогают взаимодействовать между модулями, используя одно и то же пространство имен.

• Пространства имен - это виртуальные кластеры, которые могут располагаться на вершине одного физического кластера.

• Они обеспечивают логическое разделение между командами и их средой.

Создать пространство имен

Следующая команда используется для создания пространства имен.

apiVersion: v1
kind: Namespce
metadata
   name: elk

Управляйте пространством имен

Следующая команда используется для управления пространством имен.

$ kubectl create –f namespace.yml ---------> 1
$ kubectl get namespace -----------------> 2 $ kubectl get namespace <Namespace name> ------->3
$ kubectl describe namespace <Namespace name> ---->4 $ kubectl delete namespace <Namespace name>

В приведенном выше коде

• Мы используем команду для создания пространства имен.
• Это перечислит все доступное пространство имен.
• Это получит конкретное пространство имен, имя которого указано в команде.
• Здесь будут описаны все подробности об услуге.
• Это приведет к удалению определенного пространства имен, присутствующего в кластере.

Использование пространства имен в службе - пример

Ниже приведен пример файла-образца для использования пространства имен в службе.

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

В приведенном выше коде мы используем то же пространство имен в метаданных службы с именем elk.

Узел - это рабочая машина в кластере Kubernetes, также известная как миньон. Это рабочие единицы, которые могут быть физическими, виртуальными или облачными.

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

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

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

Сервис с селектором

apiVersion: v1
kind: node
metadata:
   name: < ip address of the node>
   labels:
      name: <lable name>

В формате JSON создается фактический объект, который выглядит следующим образом:

{
   Kind: node
   apiVersion: v1
   "metadata": 
   {
      "name": "10.01.1.10",
      "labels"
      {
         "name": "cluster 1 node"
      }
   }
}

Контроллер узла

Они представляют собой набор сервисов, которые выполняются в мастере Kubernetes и непрерывно контролируют узел в кластере на основе metadata.name. Если все необходимые службы запущены, то узел проверяется, и вновь созданный модуль будет назначен этому узлу контроллером. Если он недействителен, мастер не назначит ему ни одного модуля и будет ждать, пока он не станет действительным.

Мастер Kubernetes регистрирует узел автоматически, если –register-node флаг верен.

–register-node = true

Однако, если администратор кластера хочет управлять им вручную, это можно сделать, повернув квартиру -

–register-node = false

Сервис можно определить как логический набор модулей. Его можно определить как абстракцию в верхней части модуля, которая предоставляет единственный IP-адрес и DNS-имя, по которому можно получить доступ к модулям. С помощью службы очень легко управлять конфигурацией балансировки нагрузки. Это помогает легко масштабировать стручки.

Служба - это объект REST в Kubernetes, определение которого можно опубликовать в Kubernetes apiServer на главном сервере Kubernetes для создания нового экземпляра.

Сервис без селектора

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
   targetPort: 31999

Приведенная выше конфигурация создаст службу с именем Tutorial_point_service.

Файл конфигурации службы с селектором

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: "My Application" -------------------> (Selector)
   ports:
   - port: 8080
   targetPort: 31999

В этом примере у нас есть селектор; поэтому для передачи трафика нам нужно создать конечную точку вручную.

apiVersion: v1
kind: Endpoints
metadata:
   name: Tutorial_point_service
subnets:
   address:
      "ip": "192.168.168.40" -------------------> (Selector)
   ports:
      - port: 8080

В приведенном выше коде мы создали конечную точку, которая будет направлять трафик к конечной точке, определенной как «192.168.168.40:8080».

Создание многопортовой службы

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: “My Application” -------------------> (Selector)
   ClusterIP: 10.3.0.12
   ports:
      -name: http
      protocol: TCP
      port: 80
      targetPort: 31999
   -name:https
      Protocol: TCP
      Port: 443
      targetPort: 31998

Виды услуг

ClusterIP- Это помогает ограничить обслуживание в кластере. Он предоставляет сервис в рамках определенного кластера Kubernetes.

spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService

NodePort- Служба будет доступна на статическом порту развернутого узла. АClusterIP сервис, которому NodePortсервис будет маршрутизировать, создается автоматически. Доступ к сервису можно получить извне кластера с помощьюNodeIP:nodePort.

spec:
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService
      clusterIP: 10.20.30.40

Load Balancer - Использует балансировщик нагрузки облачных провайдеров. NodePort и ClusterIP службы создаются автоматически, к которым будет маршрутизироваться внешний балансировщик нагрузки.

Полный сервис yamlфайл с типом службы как Node Port. Попробуйте создать его самостоятельно.

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: env_name

Pod - это набор контейнеров и их хранилище внутри узла кластера Kubernetes. Можно создать контейнер с несколькими контейнерами внутри. Например, хранение контейнера базы данных и контейнера данных в одном модуле.

Типы капсул

Есть два типа стручков -

• Единая контейнерная капсула
• Многоконтейнерная капсула

Одноконтейнерная капсула

Их можно просто создать с помощью команды kubctl run, где у вас есть определенный образ в реестре Docker, который мы извлечем при создании модуля.

$ kubectl run <name of pod> --image=<name of the image from registry>

Example - Мы создадим модуль с изображением tomcat, который доступен в концентраторе Docker.

$ kubectl run tomcat --image = tomcat:8.0

Это также можно сделать, создав yaml файл, а затем запустите kubectl create команда.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always

Как только выше yaml файл создан, мы сохраним файл с именем tomcat.yml и запустите команду create, чтобы запустить документ.

$ kubectl create –f tomcat.yml

Будет создан модуль с именем tomcat. Мы можем использовать команду описать вместе сkubectl для описания стручка.

Многоконтейнерная капсула

Модули с несколькими контейнерами создаются с использованием yaml mail с определением контейнеров.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
containerPort: 7501
   imagePullPolicy: Always

В приведенном выше коде мы создали один модуль с двумя контейнерами внутри него: один для tomcat, а другой для MongoDB.

Контроллер репликации - одна из ключевых функций Kubernetes, которая отвечает за управление жизненным циклом пода. Он отвечает за обеспечение того, чтобы указанное количество реплик модуля было запущено в любой момент времени. Он используется вовремя, когда нужно убедиться, что указанное количество модулей или хотя бы один модуль работает. Он может поднимать или опускать указанное количество модулей.

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

apiVersion: v1
kind: ReplicationController --------------------------> 1
metadata:
   name: Tomcat-ReplicationController --------------------------> 2
spec:
   replicas: 3 ------------------------> 3
   template:
      metadata:
         name: Tomcat-ReplicationController
      labels:
         app: App
         component: neo4j
      spec:
         containers:
         - name: Tomcat- -----------------------> 4
         image: tomcat: 8.0
         ports:
            - containerPort: 7474 ------------------------> 5

Детали установки

• Kind: ReplicationController → В приведенном выше коде мы определили тип контроллера репликации, который сообщает kubectl что yaml файл будет использоваться для создания контроллера репликации.

• name: Tomcat-ReplicationController→ Это помогает определить имя, с которым будет создан контроллер репликации. Если мы запустим kubctl, получимrc < Tomcat-ReplicationController > он покажет детали контроллера репликации.

• replicas: 3 → Это помогает контроллеру репликации понять, что ему необходимо поддерживать три реплики модуля в любой момент жизненного цикла модуля.

• name: Tomcat → В разделе спецификации мы определили имя как tomcat, которое сообщит контроллеру репликации, что контейнер, присутствующий внутри подов, - это tomcat.

• containerPort: 7474 → Это помогает убедиться, что все узлы в кластере, где модуль запускает контейнер внутри модуля, будут доступны через один и тот же порт 7474.

Здесь служба Kubernetes работает как балансировщик нагрузки для трех реплик tomcat.

Replica Set гарантирует, сколько реплик модуля должно быть запущено. Это можно рассматривать как замену контроллера репликации. Ключевое различие между набором реплик и контроллером репликации заключается в том, что контроллер репликации поддерживает только селектор на основе равенства, тогда как набор реплик поддерживает селектор на основе набора.

apiVersion: extensions/v1beta1 --------------------->1
kind: ReplicaSet --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
         tier: Backend ------------------> 3
      matchExpression:
{ key: tier, operation: In, values: [Backend]} --------------> 4
template:
   metadata:
      lables:
         app: Tomcat-ReplicaSet
         tier: Backend
      labels:
         app: App
         component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

Детали установки

• apiVersion: extensions/v1beta1 → В приведенном выше коде версия API - это расширенная бета-версия Kubernetes, которая поддерживает концепцию набора реплик.

• kind: ReplicaSet → Мы определили тип как набор реплик, который помогает kubectl понять, что файл используется для создания набора реплик.

• tier: Backend → Мы определили уровень меток как бэкэнд, который создает соответствующий селектор.

• {key: tier, operation: In, values: [Backend]} → Это поможет matchExpression чтобы понять условие соответствия, которое мы определили, и в операции, которая используется matchlabel чтобы узнать подробности.

Запустите указанный выше файл, используя kubectl и создайте набор реплик серверной части с указанным определением в yaml файл.

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

Они предоставляют множество обновленных функций matchLabels и selectors. У нас есть новый контроллер в мастере Kubernetes, который называется контроллером развертывания. У него есть возможность изменить развертывание на полпути.

Изменение развертывания

Updating- Пользователь может обновить текущее развертывание до его завершения. При этом будет урегулировано существующее развертывание и будет создано новое развертывание.

Deleting- Пользователь может приостановить / отменить развертывание, удалив его до его завершения. Повторное создание того же развертывания возобновит его.

Rollback- Мы можем откатить развертывание или развертывание в процессе. Пользователь может создать или обновить развертывание, используяDeploymentSpec.PodTemplateSpec = oldRC.PodTemplateSpec.

Стратегии развертывания

Стратегии развертывания помогают определить, как новый RC должен заменить существующий RC.

Recreate- Эта функция убьет все существующие RC, а затем вызовет новые. Это приводит к быстрому развертыванию, однако это приведет к простою, когда старые модули не работают, а новые не подходят.

Rolling Update- Эта функция постепенно отключает старый RC и вызывает новый. Это приводит к медленному развертыванию, однако развертывание не происходит. В этом процессе всегда доступно несколько старых модулей и несколько новых модулей.

Конфигурационный файл Deployment выглядит так.

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
         lables:
            app: Tomcat-ReplicaSet
            tier: Backend
   spec:
      containers:
         - name: Tomcatimage:
            tomcat: 8.0
            ports:
               - containerPort: 7474

В приведенном выше коде единственное, что отличается от набора реплик, это то, что мы определили тип как развертывание.

Создать развертывание

$ kubectl create –f Deployment.yaml -–record
deployment "Deployment" created Successfully.

Получить развертывание

$ kubectl get deployments
NAME           DESIRED     CURRENT     UP-TO-DATE     AVILABLE    AGE
Deployment        3           3           3              3        20s

Проверить статус развертывания

$ kubectl rollout status deployment/Deployment

Обновление развертывания

$ kubectl set image deployment/Deployment tomcat=tomcat:6.0

Откат к предыдущему развертыванию

$ kubectl rollout undo deployment/Deployment –to-revision=2

В Kubernetes том можно рассматривать как каталог, доступный для контейнеров в модуле. В Kubernetes есть разные типы томов, и тип определяет, как создается том и его содержимое.

Концепция объема присутствовала в Docker, однако единственная проблема заключалась в том, что объем очень сильно ограничивался конкретным модулем. Как только закончилась жизнь капсулы, пропала и громкость.

С другой стороны, тома, созданные с помощью Kubernetes, не ограничиваются каким-либо контейнером. Он поддерживает любой или все контейнеры, развернутые внутри модуля Kubernetes. Ключевым преимуществом объема Kubernetes является то, что он поддерживает разные типы хранилищ, в которых модуль может использовать несколько из них одновременно.

Типы объема Kubernetes

Вот список некоторых популярных томов Kubernetes -

• emptyDir- Это тип тома, который создается, когда модуль впервые назначается узлу. Он остается активным, пока модуль работает на этом узле. Том изначально пуст, и контейнеры в модуле могут читать и записывать файлы в том emptyDir. После удаления модуля из узла данные в emptyDir стираются.

• hostPath - Этот тип тома монтирует файл или каталог из файловой системы хост-узла в ваш модуль.

• gcePersistentDisk- Этот тип тома подключает постоянный диск Google Compute Engine (GCE) к вашему модулю. Данные вgcePersistentDisk остается нетронутым, когда Pod удаляется из узла.

• awsElasticBlockStore- Этот тип тома монтирует хранилище эластичных блоков Amazon Web Services (AWS) в ваш Pod. КакgcePersistentDisk, данные в awsElasticBlockStore остается нетронутым, когда Pod удаляется из узла.

• nfs - An nfsvolume позволяет монтировать существующую NFS (сетевая файловая система) в ваш модуль. Данные вnfsтом не стирается, когда Pod удаляется из узла. Том только размонтирован.

• iscsi - An iscsi Volume позволяет подключить существующий том iSCSI (SCSI через IP) к модулю.

• flocker- Это диспетчер томов кластерных контейнерных данных с открытым исходным кодом. Он используется для управления объемами данных. Аflockervolume позволяет монтировать набор данных Flocker в модуль. Если набора данных не существует во Flocker, вам сначала необходимо создать его с помощью Flocker API.

• glusterfs- Glusterfs - сетевая файловая система с открытым исходным кодом. Том glusterfs позволяет вмонтировать том glusterfs в ваш под.

• rbd- RBD расшифровывается как Rados Block Device. AnrbdVolume позволяет установить том Rados Block Device в ваш модуль. Данные остаются неизменными после удаления модуля из узла.

• cephfs - А cephfsvolume позволяет монтировать существующий том CephFS в ваш модуль. Данные остаются нетронутыми после удаления модуля из узла.

• gitRepo - А gitRepo том монтирует пустой каталог и клонирует git репозиторий в него для использования вашим модулем.

• secret - А secret Volume используется для передачи конфиденциальной информации, такой как пароли, в модули.

• persistentVolumeClaim - А persistentVolumeClaimvolume используется для монтирования PersistentVolume в модуль. PersistentVolumes - это способ, с помощью которого пользователи могут «потребовать» надежное хранилище (например, GCE PersistentDisk или том iSCSI), не зная подробностей конкретной облачной среды.

• downwardAPI - А downwardAPIVolume используется для предоставления приложениям доступа к нисходящим данным API. Он монтирует каталог и записывает запрошенные данные в текстовые файлы.

• azureDiskVolume - An AzureDiskVolume используется для подключения диска данных Microsoft Azure к модулю.

Заявка на постоянный том и постоянный том

Persistent Volume (PV)- Это часть сетевого хранилища, предоставленная администратором. Это ресурс в кластере, который не зависит от какого-либо отдельного модуля, использующего PV.

Persistent Volume Claim (PVC)- Хранилище, запрошенное Kubernetes для своих подов, известно как PVC. Пользователю не нужно знать базовую подготовку. Утверждения должны быть созданы в том же пространстве имен, где создается модуль.

Создание постоянного тома

kind: PersistentVolume ---------> 1
apiVersion: v1
metadata:
   name: pv0001 ------------------> 2
   labels:
      type: local
spec:
   capacity: -----------------------> 3
      storage: 10Gi ----------------------> 4
   accessModes:
      - ReadWriteOnce -------------------> 5
      hostPath:
         path: "/tmp/data01" --------------------------> 6

В приведенном выше коде мы определили -

• kind: PersistentVolume → Мы определили тип как PersistentVolume, который сообщает Kubernetes, что файл yaml используется для создания постоянного тома.

• name: pv0001 → Название PersistentVolume, который мы создаем.

• capacity: → Эта спецификация будет определять мощность PV, которую мы пытаемся создать.

• storage: 10Gi → Это сообщает базовой инфраструктуре, что мы пытаемся занять пространство 10Gi на определенном пути.

• ReadWriteOnce → Это говорит о правах доступа к создаваемому нами тому.

• path: "/tmp/data01" → Это определение сообщает машине, что мы пытаемся создать том по этому пути в базовой инфраструктуре.

Создание PV

$ kubectl create –f local-01.yaml
persistentvolume "pv0001" created

Проверка PV

$ kubectl get pv
NAME        CAPACITY      ACCESSMODES       STATUS       CLAIM      REASON     AGE
pv0001        10Gi            RWO         Available                            14s

Описание PV

$ kubectl describe pv pv0001

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

kind: PersistentVolumeClaim --------------> 1
apiVersion: v1
metadata:
   name: myclaim-1 --------------------> 2
spec:
   accessModes:
      - ReadWriteOnce ------------------------> 3
   resources:
      requests:
         storage: 3Gi ---------------------> 4

В приведенном выше коде мы определили -

• kind: PersistentVolumeClaim → Он сообщает базовой инфраструктуре, что мы пытаемся потребовать определенный объем пространства.

• name: myclaim-1 → Название заявки, которую мы пытаемся создать.

• ReadWriteOnce → Это определяет режим заявки, которую мы пытаемся создать.

• storage: 3Gi → Это сообщит кубернетам, сколько места мы пытаемся занять.

Создание ПВХ

$ kubectl create –f myclaim-1
persistentvolumeclaim "myclaim-1" created

Получение подробной информации о ПВХ

$ kubectl get pvc
NAME        STATUS   VOLUME   CAPACITY   ACCESSMODES   AGE
myclaim-1   Bound    pv0001     10Gi         RWO       7s

Опишите ПВХ

$ kubectl describe pv pv0001

Использование PV и PVC с POD

kind: Pod
apiVersion: v1
metadata:
   name: mypod
   labels:
      name: frontendhttp
spec:
   containers:
   - name: myfrontend
      image: nginx
      ports:
      - containerPort: 80
         name: "http-server"
      volumeMounts: ----------------------------> 1
      - mountPath: "/usr/share/tomcat/html"
         name: mypd
   volumes: -----------------------> 2
      - name: mypd
         persistentVolumeClaim: ------------------------->3
         claimName: myclaim-1

В приведенном выше коде мы определили -

• volumeMounts: → Это путь в контейнере, на котором будет производиться установка.

• Volume: → Это определение определяет определение объема, которое мы собираемся потребовать.

• persistentVolumeClaim: → Под этим мы определяем имя тома, которое мы собираемся использовать в определенном модуле.

Секреты можно определить как объекты Kubernetes, используемые для хранения конфиденциальных данных, таких как имя пользователя и пароли, с шифрованием.

В Kubernetes есть несколько способов создания секретов.

• Создание из файлов txt.
• Создание из файла yaml.

Создание из текстового файла

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

$ kubectl create secret generic tomcat-passwd –-from-file = ./username.txt –fromfile = ./.
password.txt

Создание из файла Yaml

apiVersion: v1
kind: Secret
metadata:
name: tomcat-pass
type: Opaque
data:
   password: <User Password>
   username: <User Name>

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

$ kubectl create –f Secret.yaml
secrets/tomcat-pass

Использование секретов

После того, как мы создали секреты, их можно использовать в модуле или контроллере репликации как -

• Переменная среды
• Volume

Как переменная среды

Чтобы использовать секрет в качестве переменной среды, мы будем использовать env в разделе spec файла pod yaml.

env:
- name: SECRET_USERNAME
   valueFrom:
      secretKeyRef:
         name: mysecret
         key: tomcat-pass

Как объем

spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat:7.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

Секретная конфигурация как переменная среды

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
replicas: replica_count
template:
   metadata:
      name: appname
   spec:
      nodeSelector:
         resource-group:
      containers:
         - name: appname
            image:
            imagePullPolicy: Always
            ports:
            - containerPort: 3000
            env: -----------------------------> 1
               - name: ENV
                  valueFrom:
                     configMapKeyRef:
                        name: appname
                        key: tomcat-secrets

В приведенном выше коде под env По определению, мы используем секреты как переменную среды в контроллере репликации.

Секреты крепления тома

apiVersion: v1
kind: pod
metadata:
   name: appname
spec:
   metadata:
      name: appname
   spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat: 8.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

Сетевая политика определяет, как модули в одном пространстве имен будут взаимодействовать друг с другом и с конечной точкой сети. Это требуетextensions/v1beta1/networkpoliciesдля включения в конфигурации среды выполнения на сервере API. Его ресурсы используют метки для выбора модулей и определения правил, разрешающих трафик к конкретному модулю, в дополнение к тому, который определен в пространстве имен.

Во-первых, нам нужно настроить политику изоляции пространства имен. Обычно такие сетевые политики требуются для балансировщиков нагрузки.

kind: Namespace
apiVersion: v1
metadata:
   annotations:
      net.beta.kubernetes.io/network-policy: |
      {
         "ingress": 
         {
            "isolation": "DefaultDeny"
         }
      }

$ kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy = 
{\"ingress\": {\"isolation\": \"DefaultDeny\"}}"

После создания пространства имен нам нужно создать сетевую политику.

Сетевая политика Yaml

kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
   name: allow-frontend
   namespace: myns
spec:
   podSelector:
      matchLabels:
         role: backend
   ingress:
   - from:
      - podSelector:
         matchLabels:
            role: frontend
   ports:
      - protocol: TCP
         port: 6379

Kubernetes API служит основой для декларативной схемы конфигурации системы. KubectlИнструмент командной строки может использоваться для создания, обновления, удаления и получения объекта API. Kubernetes API выступает в качестве коммуникатора между различными компонентами Kubernetes.

Добавление API в Kubernetes

Добавление нового API в Kubernetes добавит новые функции в Kubernetes, что повысит функциональность Kubernetes. Однако наряду с этим повысится стоимость и ремонтопригодность системы. Для достижения баланса между стоимостью и сложностью для него определено несколько наборов.

Добавляемый API должен быть полезен более чем 50% пользователей. Другого способа реализовать функционал в Kubernetes нет. Исключительные обстоятельства обсуждаются на собрании сообщества Kubernetes, а затем добавляется API.

Изменения API

Чтобы увеличить возможности Kubernetes, в систему постоянно вносятся изменения. Команда Kubernetes делает это для добавления функциональности в Kubernetes, не удаляя и не влияя на существующие функциональные возможности системы.

Чтобы продемонстрировать общий процесс, вот (гипотетический) пример -

• Пользователь отправляет POST объект в /api/v7beta1/...

• JSON неупорядочен в v7beta1.Pod структура

• Значения по умолчанию применяются к v7beta1.Pod

• В v7beta1.Pod преобразуется в api.Pod структура

• В api.Pod проверяется, и все ошибки возвращаются пользователю

• В api.Pod преобразован в v6.Pod (поскольку v6 - последняя стабильная версия)

• В v6.Pod маршалируется в JSON и записывается в etcd

Теперь, когда у нас есть сохраненный объект Pod, пользователь может ПОЛУЧИТЬ этот объект в любой поддерживаемой версии API. Например -

• Пользователь ПОЛУЧАЕТ Pod из /api/v5/...

• JSON читается из etcd и unmarshalled в v6.Pod структура

• Значения по умолчанию применяются к v6.Pod

• В v6.Pod преобразуется в структуру api.Pod

• В api.Pod преобразуется в v5.Pod структура

• В v5.Pod маршалируется в JSON и отправляется пользователю

Смысл этого процесса заключается в том, что изменения API должны выполняться осторожно и с соблюдением обратной совместимости.

Управление версиями API

Чтобы упростить поддержку нескольких структур, Kubernetes поддерживает несколько версий API, каждая из которых имеет свой путь к API, например /api/v1 или же /apsi/extensions/v1beta1

Стандарты управления версиями в Kubernetes определены в нескольких стандартах.

Альфа-уровень

• Эта версия содержит альфа-версию (например, v1alpha1)

• Эта версия может содержать ошибки; включенная версия может иметь ошибки

• Поддержка ошибок может быть прекращена в любой момент.

• Рекомендуется использовать только для краткосрочного тестирования, так как поддержка может отсутствовать постоянно.

Бета-уровень

• Название версии содержит бета (например, v2beta3)

• Код полностью протестирован, и включенная версия должна быть стабильной.

• Поддержка функции не будет прекращена; возможны небольшие изменения.

• Рекомендуется только для некритичных для бизнеса применений из-за возможности несовместимых изменений в последующих выпусках.

Стабильный уровень

• Название версии vX где X целое число.

• Стабильные версии функций появятся в выпущенном программном обеспечении для многих последующих версий.

Kubectl - это утилита командной строки для взаимодействия с Kubernetes API. Это интерфейс, который используется для связи и управления модулями в кластере Kubernetes.

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

Настройка Kubectl

Загрузите исполняемый файл на локальную рабочую станцию ​​с помощью команды curl.

В Linux

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/linux/amd64/kubectl

На рабочей станции OS X

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/darwin/amd64/kubectl

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

$ chmod +x kubectl
$ mv kubectl /usr/local/bin/kubectl

Настройка Kubectl

Ниже приведены шаги для выполнения операции настройки.

$ kubectl config set-cluster default-cluster --server = https://${MASTER_HOST} -- certificate-authority = ${CA_CERT}

$ kubectl config set-credentials default-admin --certificateauthority = ${
CA_CERT} --client-key = ${ADMIN_KEY} --clientcertificate = ${
ADMIN_CERT}

$ kubectl config set-context default-system --cluster = default-cluster -- user = default-admin $ kubectl config use-context default-system

• Заменить ${MASTER_HOST} с адресом или именем главного узла, которые использовались на предыдущих шагах.

• Заменить ${CA_CERT} с абсолютным путем к ca.pem созданный на предыдущих шагах.

• Заменить ${ADMIN_KEY} с абсолютным путем к admin-key.pem созданный на предыдущих шагах.

• Заменить ${ADMIN_CERT} с абсолютным путем к admin.pem созданный на предыдущих шагах.

Проверка настройки

Чтобы убедиться, что kubectl работает нормально или нет, проверьте, правильно ли настроен клиент Kubernetes.

$ kubectl get nodes

NAME       LABELS                                     STATUS
Vipin.com  Kubernetes.io/hostname = vipin.mishra.com    Ready

Kubectlконтролирует кластер Kubernetes. Это один из ключевых компонентов Kubernetes, который запускается на рабочей станции на любом компьютере после завершения настройки. Он имеет возможность управлять узлами в кластере.

Kubectlкоманды используются для взаимодействия и управления объектами Kubernetes и кластером. В этой главе мы обсудим несколько команд, используемых в Kubernetes через kubectl.

kubectl annotate - Обновляет аннотацию к ресурсу.

$kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ...
KEY_N = VAL_N [--resource-version = version]

Например,

kubectl annotate pods tomcat description = 'my frontend'

kubectl api-versions - Распечатывает поддерживаемые версии API в кластере.

$ kubectl api-version;

kubectl apply - Он имеет возможность настраивать ресурс по файлу или стандартному вводу.

$ kubectl apply –f <filename>

kubectl attach - Это прикрепляет вещи к работающему контейнеру.

$ kubectl attach <pod> –c <container> $ kubectl attach 123456-7890 -c tomcat-conatiner

kubectl autoscale - Это используется для автоматического масштабирования модулей, которые определены, например, для развертывания, набора реплик, контроллера репликации.

$ kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min = MINPODS] -- max = MAXPODS [--cpu-percent = CPU] [flags] $ kubectl autoscale deployment foo --min = 2 --max = 10

kubectl cluster-info - Отображает информацию о кластере.

$ kubectl cluster-info

kubectl cluster-info dump - Выводит актуальную информацию о кластере для отладки и диагностики.

$ kubectl cluster-info dump
$ kubectl cluster-info dump --output-directory = /path/to/cluster-state

kubectl config - Изменяет файл kubeconfig.

$ kubectl config <SUBCOMMAD>
$ kubectl config –-kubeconfig <String of File name>

kubectl config current-context - Отображает текущий контекст.

$ kubectl config current-context
#deploys the current context

kubectl config delete-cluster - Удаляет указанный кластер из kubeconfig.

$ kubectl config delete-cluster <Cluster Name>

kubectl config delete-context - Удаляет указанный контекст из kubeconfig.

$ kubectl config delete-context <Context Name>

kubectl config get-clusters - Отображает кластер, определенный в файле kubeconfig.

$ kubectl config get-cluster $ kubectl config get-cluster <Cluser Name>

kubectl config get-contexts - Описывает один или несколько контекстов.

$ kubectl config get-context <Context Name>

kubectl config set-cluster - Устанавливает запись кластера в Kubernetes.

$ kubectl config set-cluster NAME [--server = server] [--certificateauthority =
path/to/certificate/authority] [--insecure-skip-tls-verify = true]

kubectl config set-context - Устанавливает контекстную запись в точке входа kubernetes.

$ kubectl config set-context NAME [--cluster = cluster_nickname] [-- user = user_nickname] [--namespace = namespace] $ kubectl config set-context prod –user = vipin-mishra

kubectl config set-credentials - Устанавливает запись пользователя в kubeconfig.

$ kubectl config set-credentials cluster-admin --username = vipin --
password = uXFGweU9l35qcif

kubectl config set - Устанавливает индивидуальное значение в файле kubeconfig.

$ kubectl config set PROPERTY_NAME PROPERTY_VALUE

kubectl config unset - Отключение определенного компонента в kubectl.

$ kubectl config unset PROPERTY_NAME PROPERTY_VALUE

kubectl config use-context - Устанавливает текущий контекст в файле kubectl.

$ kubectl config use-context <Context Name>

kubectl config view

$ kubectl config view $ kubectl config view –o jsonpath='{.users[?(@.name == "e2e")].user.password}'

kubectl cp - Копирование файлов и каталогов в контейнеры и из них.

$ kubectl cp <Files from source> <Files to Destinatiion> $ kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>

kubectl create- Создать ресурс по имени файла или стандартному вводу. Для этого принимаются форматы JSON или YAML.

$ kubectl create –f <File Name> $ cat <file name> | kubectl create –f -

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

• deployment
• namespace
• quota
• секретный докер-реестр
• secret
• секретный родовой
• секрет tls
• serviceaccount
• сервисный кластер
• балансировщик нагрузки службы
• сервисный узел

kubectl delete - Удаляет ресурсы по имени файла, стандартному вводу, ресурсу и именам.

$ kubectl delete –f ([-f FILENAME] | TYPE [(NAME | -l label | --all)])

kubectl describe- Описывает любой конкретный ресурс в кубернетах. Показывает подробную информацию о ресурсе или группе ресурсов.

$ kubectl describe <type> <type name>
$ kubectl describe pod tomcat

kubectl drain- Это используется для слива узла в целях обслуживания. Он подготавливает узел к обслуживанию. Это пометит узел как недоступный, поэтому ему не следует назначать новый контейнер, который будет создан.

$ kubectl drain tomcat –force

kubectl edit- Он используется для завершения ресурсов на сервере. Это позволяет напрямую редактировать ресурс, который можно получить через инструмент командной строки.

$ kubectl edit <Resource/Name | File Name) Ex. $ kubectl edit rc/tomcat

kubectl exec - Это помогает выполнить команду в контейнере.

$ kubectl exec POD <-c CONTAINER > -- COMMAND < args...> $ kubectl exec tomcat 123-5-456 date

kubectl expose- Это используется для предоставления объектов Kubernetes, таких как модуль, контроллер репликации и служба, в качестве новой службы Kubernetes. У этого есть возможность открыть его через работающий контейнер или изyaml файл.

$ kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol = TCP|UDP] [--target-port = number-or-name] [--name = name] [--external-ip = external-ip-ofservice] [--type = type] $ kubectl expose rc tomcat –-port=80 –target-port = 30000
$ kubectl expose –f tomcat.yaml –port = 80 –target-port =

kubectl get - Эта команда может получать данные о ресурсах Kubernetes в кластере.

$ kubectl get [(-o|--output=)json|yaml|wide|custom-columns=...|custom-columnsfile=...|
go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...]
(TYPE [NAME | -l label] | TYPE/NAME ...) [flags]

Например,

$ kubectl get pod <pod name> $ kubectl get service <Service name>

kubectl logs- Они используются для получения журналов контейнера в контейнере. Печать журналов может быть определением имени контейнера в модуле. Если POD имеет только один контейнер, нет необходимости определять его имя.

$ kubectl logs [-f] [-p] POD [-c CONTAINER] Example $ kubectl logs tomcat.
$ kubectl logs –p –c tomcat.8

kubectl port-forward - Они используются для перенаправления одного или нескольких локальных портов на модули.

$ kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT
[...[LOCAL_PORT_N:]REMOTE_PORT_N]
$ kubectl port-forward tomcat 3000 4000 $ kubectl port-forward tomcat 3000:5000

kubectl replace - Возможность замены ресурса по имени файла или stdin.

$ kubectl replace -f FILENAME $ kubectl replace –f tomcat.yml
$ cat tomcat.yml | kubectl replace –f -

kubectl rolling-update- Выполняет скользящее обновление на контроллере репликации. Заменяет указанный контроллер репликации новым контроллером репликации, обновляя POD за раз.

$ kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --
image = NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC)
$ kubectl rolling-update frontend-v1 –f freontend-v2.yaml

kubectl rollout - Он способен управлять развертыванием развертывания.

$ Kubectl rollout <Sub Command>
$ kubectl rollout undo deployment/tomcat

Помимо вышеперечисленного, мы можем выполнять несколько задач с помощью развертывания, таких как -

• история развертывания
• пауза в развертывании
• развернуть резюме
• статус развертывания
• откат отменить

kubectl run - Команда Run может запускать образ в кластере Kubernetes.

$ kubectl run NAME --image = image [--env = "key = value"] [--port = port] [--
replicas = replicas] [--dry-run = bool] [--overrides = inline-json] [--command] --
[COMMAND] [args...]
$ kubectl run tomcat --image = tomcat:7.0 $ kubectl run tomcat –-image = tomcat:7.0 –port = 5000

kubectl scale - Он будет масштабировать размер Kubernetes Deployments, ReplicaSet, Replication Controller или задания.

$ kubectl scale [--resource-version = version] [--current-replicas = count] -- replicas = COUNT (-f FILENAME | TYPE NAME ) $ kubectl scale –-replica = 3 rs/tomcat
$ kubectl scale –replica = 3 tomcat.yaml

kubectl set image - Обновляет изображение шаблона стручка.

$ kubectl set image (-f FILENAME | TYPE NAME)
CONTAINER_NAME_1 = CONTAINER_IMAGE_1 ... CONTAINER_NAME_N = CONTAINER_IMAGE_N
$ kubectl set image deployment/tomcat busybox = busybox ngnix = ngnix:1.9.1 $ kubectl set image deployments, rc tomcat = tomcat6.0 --all

kubectl set resources- Используется для установки содержания ресурса. Он обновляет ресурсы / ограничения на объект с помощью шаблона модуля.

$ kubectl set resources (-f FILENAME | TYPE NAME) ([--limits = LIMITS & -- requests = REQUESTS] $ kubectl set resources deployment tomcat -c = tomcat --
limits = cpu = 200m,memory = 512Mi

kubectl top node- Отображает использование ЦП / памяти / хранилища. Команда top позволяет увидеть потребление ресурсов узлами.

$ kubectl top node [node Name]

Эту же команду можно использовать и с модулем.

Чтобы создать приложение для развертывания Kubernetes, нам нужно сначала создать приложение в Docker. Это можно сделать двумя способами -

• Скачивая
• Из файла Docker

Скачивая

Существующий образ можно загрузить из концентратора Docker и сохранить в локальном реестре Docker.

Для этого запустите Docker pull команда.

$ docker pull --help
Usage: docker pull [OPTIONS] NAME[:TAG|@DIGEST]
Pull an image or a repository from the registry
   -a, --all-tags = false     Download all tagged images in the repository
   --help = false             Print usage

Ниже будет вывод вышеуказанного кода.

На приведенном выше снимке экрана показан набор изображений, которые хранятся в нашем локальном реестре Docker.

Если мы хотим создать контейнер из образа, который состоит из тестируемого приложения, мы можем сделать это с помощью команды Docker run.

$ docker run –i –t unbunt /bin/bash

Из файла Docker

Чтобы создать приложение из файла Docker, нам нужно сначала создать файл Docker.

Ниже приведен пример файла Jenkins Docker.

FROM ubuntu:14.04
MAINTAINER [email protected]
ENV REFRESHED_AT 2017-01-15
RUN apt-get update -qq && apt-get install -qqy curl
RUN curl https://get.docker.io/gpg | apt-key add -
RUN echo deb http://get.docker.io/ubuntu docker main > /etc/apt/↩
sources.list.d/docker.list
RUN apt-get update -qq && apt-get install -qqy iptables ca-↩
certificates lxc openjdk-6-jdk git-core lxc-docker
ENV JENKINS_HOME /opt/jenkins/data
ENV JENKINS_MIRROR http://mirrors.jenkins-ci.org
RUN mkdir -p $JENKINS_HOME/plugins
RUN curl -sf -o /opt/jenkins/jenkins.war -L $JENKINS_MIRROR/war-↩ stable/latest/jenkins.war RUN for plugin in chucknorris greenballs scm-api git-client git ↩ ws-cleanup ;\ do curl -sf -o $JENKINS_HOME/plugins/${plugin}.hpi \ -L $JENKINS_MIRROR/plugins/${plugin}/latest/${plugin}.hpi ↩
; done
ADD ./dockerjenkins.sh /usr/local/bin/dockerjenkins.sh
RUN chmod +x /usr/local/bin/dockerjenkins.sh
VOLUME /var/lib/docker
EXPOSE 8080
ENTRYPOINT [ "/usr/local/bin/dockerjenkins.sh" ]

После создания указанного выше файла сохраните его с именем Dockerfile и cd по пути к файлу. Затем выполните следующую команду.

$ sudo docker build -t jamtur01/Jenkins .

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

$ docker run –i –t jamtur01/Jenkins /bin/bash

Развертывание - это метод преобразования изображений в контейнеры с последующим распределением этих изображений по подам в кластере Kubernetes. Это также помогает в настройке кластера приложений, который включает развертывание службы, модуля, контроллера репликации и набора реплик. Кластер можно настроить таким образом, чтобы приложения, развернутые в модуле, могли взаимодействовать друг с другом.

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

Ngnix Load Balancer Yaml-файл

apiVersion: v1
kind: Service
metadata:
   name: oppv-dev-nginx
      labels:
         k8s-app: omni-ppv-api
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: dev

Контроллер репликации Ngnix Yaml

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
   replicas: replica_count
   template:
      metadata:
         name: appname
         labels:
            k8s-app: appname
            component: nginx
               env: env_name
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
      image: IMAGE_TEMPLATE
      imagePullPolicy: Always
      ports:
         - containerPort: 8080
         resources:
            requests:
               memory: "request_mem"
               cpu: "request_cpu"
            limits:
               memory: "limit_mem"
               cpu: "limit_cpu"
            env:
            - name: BACKEND_HOST
               value: oppv-env_name-node:3000

Ямл-файл Frontend Service

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - name: http
      port: 3000
      protocol: TCP
      targetPort: 3000
   selector:
      k8s-app: appname
      component: nodejs
      env: dev

Yaml-файл Frontend Replication Controller

apiVersion: v1
kind: ReplicationController
metadata:
   name: Frontend
spec:
   replicas: 3
   template:
      metadata:
         name: frontend
         labels:
            k8s-app: Frontend
            component: nodejs
            env: Dev
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
         image: IMAGE_TEMPLATE
         imagePullPolicy: Always
         ports:
            - containerPort: 3000
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "limit_cpu"
                  limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            env:
               - name: ENV
               valueFrom:
               configMapKeyRef:
               name: appname
               key: config-env

Yaml-файл серверной службы

apiVersion: v1
kind: Service
metadata:
   name: backend
   labels:
      k8s-app: backend
spec:
   type: NodePort
   ports:
   - name: http
      port: 9010
      protocol: TCP
      targetPort: 9000
   selector:
      k8s-app: appname
      component: play
      env: dev

Резервный файл Yaml контроллера репликации

apiVersion: v1
kind: ReplicationController
metadata:
   name: backend
spec:
   replicas: 3
   template:
      metadata:
         name: backend
      labels:
         k8s-app: beckend
         component: play
         env: dev
spec:
   nodeSelector:
      resource-group: oppv
      containers:
         - name: appname
            image: IMAGE_TEMPLATE
            imagePullPolicy: Always
            ports:
            - containerPort: 9000
            command: [ "./docker-entrypoint.sh" ]
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "request_cpu"
               limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            volumeMounts:
               - name: config-volume
               mountPath: /app/vipin/play/conf
         volumes:
            - name: config-volume
            configMap:
            name: appname

Autoscaling- одна из ключевых особенностей кластера Kubernetes. Это функция, в которой кластер может увеличивать количество узлов по мере увеличения потребности в ответе на услуги и уменьшать количество узлов по мере уменьшения потребности. Эта функция автоматического масштабирования в настоящее время поддерживается в Google Cloud Engine (GCE) и Google Container Engine (GKE) и скоро будет запущена в AWS.

Чтобы настроить масштабируемую инфраструктуру в GCE, нам сначала нужно иметь активный проект GCE с функциями облачного мониторинга Google, ведения журналов в облаке Google и включенного stackdriver.

Сначала мы настроим кластер с несколькими запущенными в нем узлами. После этого нам нужно настроить следующую переменную среды.

Переменная среды

export NUM_NODES = 2
export KUBE_AUTOSCALER_MIN_NODES = 2
export KUBE_AUTOSCALER_MAX_NODES = 5
export KUBE_ENABLE_CLUSTER_AUTOSCALER = true

После этого мы запустим кластер, запустив kube-up.sh. Это создаст кластер вместе с автоматическим скалярным добавлением кластера.

./cluster/kube-up.sh

После создания кластера мы можем проверить наш кластер с помощью следующей команды kubectl.

$ kubectl get nodes
NAME                             STATUS                       AGE
kubernetes-master                Ready,SchedulingDisabled     10m
kubernetes-minion-group-de5q     Ready                        10m
kubernetes-minion-group-yhdx     Ready                        8m

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

$ kubectl autoscale deployment <Application Name> --cpu-percent = 50 --min = 1 --
max = 10

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

Мы можем проверить состояние автомасштабирования, запустив $kubclt get hpaкоманда. Мы увеличим нагрузку на контейнеры с помощью следующей команды.

$ kubectl run -i --tty load-generator --image = busybox /bin/sh
$ while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

Мы можем проверить hpa бегом $ kubectl get hpa команда.

$ kubectl get hpa NAME REFERENCE TARGET CURRENT php-apache Deployment/php-apache/scale 50% 310% MINPODS MAXPODS AGE 1 20 2m $ kubectl get deployment php-apache
NAME         DESIRED    CURRENT    UP-TO-DATE    AVAILABLE   AGE
php-apache      7          7           7            3        4m

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

jsz@jsz-desk2:~/k8s-src$ kubectl get pods
php-apache-2046965998-3ewo6 0/1        Pending 0         1m
php-apache-2046965998-8m03k 1/1        Running 0         1m
php-apache-2046965998-ddpgp 1/1        Running 0         5m
php-apache-2046965998-lrik6 1/1        Running 0         1m
php-apache-2046965998-nj465 0/1        Pending 0         1m
php-apache-2046965998-tmwg1 1/1        Running 0         1m
php-apache-2046965998-xkbw1 0/1        Pending 0         1m

И наконец, мы можем получить статус узла.

$ kubectl get nodes
NAME                             STATUS                        AGE
kubernetes-master                Ready,SchedulingDisabled      9m
kubernetes-minion-group-6z5i     Ready                         43s
kubernetes-minion-group-de5q     Ready                         9m
kubernetes-minion-group-yhdx     Ready                         9m

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

• Докер (1.3+)
• идти (1.5+)
• nodejs (4.2.2+)
• npm (1.3+)
• Java (7+)
• глоток (3.9+)
• Kubernetes (1.1.2+)

Настройка приборной панели

$ sudo apt-get update && sudo apt-get upgrade Installing Python $ sudo apt-get install python
$ sudo apt-get install python3 Installing GCC $ sudo apt-get install gcc-4.8 g++-4.8

Installing make
$ sudo apt-get install make Installing Java $ sudo apt-get install openjdk-7-jdk

Installing Node.js
$ wget https://nodejs.org/dist/v4.2.2/node-v4.2.2.tar.gz $ tar -xzf node-v4.2.2.tar.gz
$ cd node-v4.2.2 $ ./configure
$ make $ sudo make install

Installing gulp
$ npm install -g gulp $ npm install gulp

Проверка версий

Java Version
$ java –version java version "1.7.0_91" OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-1~deb8u1+rpi1) OpenJDK Zero VM (build 24.91-b01, mixed mode) $ node –v
V4.2.2

$ npn -v 2.14.7 $ gulp -v
[09:51:28] CLI version 3.9.0

$ sudo gcc --version
gcc (Raspbian 4.8.4-1) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc. This is free software; 
see the source for copying conditions. There is NO warranty; not even for 
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Установка GO

$ git clone https://go.googlesource.com/go
$ cd go $ git checkout go1.4.3
$ cd src Building GO $ ./all.bash
$ vi /root/.bashrc In the .bashrc export GOROOT = $HOME/go
   export PATH = $PATH:$GOROOT/bin
   
$ go version
go version go1.4.3 linux/arm

Установка Kubernetes Dashboard

$ git clone https://github.com/kubernetes/dashboard.git
$ cd dashboard $ npm install -g bower

Запуск панели управления

$ git clone https://github.com/kubernetes/dashboard.git $ cd dashboard
$ npm install -g bower $ gulp serve
[11:19:12] Requiring external module babel-core/register
[11:20:50] Using gulpfile ~/dashboard/gulpfile.babel.js
[11:20:50] Starting 'package-backend-source'...
[11:20:50] Starting 'kill-backend'...
[11:20:50] Finished 'kill-backend' after 1.39 ms
[11:20:50] Starting 'scripts'...
[11:20:53] Starting 'styles'...
[11:21:41] Finished 'scripts' after 50 s
[11:21:42] Finished 'package-backend-source' after 52 s
[11:21:42] Starting 'backend'...
[11:21:43] Finished 'styles' after 49 s
[11:21:43] Starting 'index'...
[11:21:44] Finished 'index' after 1.43 s
[11:21:44] Starting 'watch'...
[11:21:45] Finished 'watch' after 1.41 s
[11:23:27] Finished 'backend' after 1.73 min
[11:23:27] Starting 'spawn-backend'...
[11:23:27] Finished 'spawn-backend' after 88 ms
[11:23:27] Starting 'serve'...
2016/02/01 11:23:27 Starting HTTP server on port 9091
2016/02/01 11:23:27 Creating API client for
2016/02/01 11:23:27 Creating Heapster REST client for http://localhost:8082
[11:23:27] Finished 'serve' after 312 ms
[BS] [BrowserSync SPA] Running...
[BS] Access URLs:
--------------------------------------
Local: http://localhost:9090/
External: http://192.168.1.21:9090/
--------------------------------------
UI: http://localhost:3001
UI External: http://192.168.1.21:3001
--------------------------------------
[BS] Serving files from: /root/dashboard/.tmp/serve
[BS] Serving files from: /root/dashboard/src/app/frontend
[BS] Serving files from: /root/dashboard/src/app

Панель управления Kubernetes

Мониторинг - один из ключевых компонентов управления большими кластерами. Для этого у нас есть ряд инструментов.

Мониторинг с Prometheus

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

У Prometheus есть несколько компонентов для участия в мониторинге -

• Prometheus - Это основной компонент, который собирает и хранит данные.

• Prometheus node explore - Получает матрицы уровня хоста и предоставляет их Prometheus.

• Ranch-eye - это haproxy и разоблачает cAdvisor статистика для Прометея.

• Grafana - Визуализация данных.

• InfuxDB - База данных временных рядов, специально используемая для хранения данных от владельца ранчо.

• Prom-ranch-exporter - Это простое приложение node.js, которое помогает запрашивать сервер Rancher о состоянии стека обслуживания.

Агент Sematext Docker

Это современный агент сбора данных, событий и журналов с поддержкой Docker. Он работает как крошечный контейнер на каждом хосте Docker и собирает журналы, метрики и события для всех узлов и контейнеров кластера. Он обнаруживает все контейнеры (один модуль может содержать несколько контейнеров), включая контейнеры для базовых сервисов Kubernetes, если базовые сервисы развернуты в контейнерах Docker. После его развертывания все журналы и метрики сразу же доступны из коробки.

Развертывание агентов на узлах

Kubernetes предоставляет DeamonSets, который обеспечивает добавление модулей в кластер.

Настройка SemaText Docker Agent

Он настраивается через переменные среды.

• Получите бесплатную учетную запись на apps.sematext.com , если у вас ее еще нет.

• Создайте приложение SPM типа «Docker», чтобы получить токен приложения SPM. Приложение SPM будет содержать ваши метрики производительности и события Kubernetes.

• Создайте приложение Logsene, чтобы получить токен приложения Logsene. Приложение Logsene будет хранить ваши журналы Kubernetes.

• Измените значения LOGSENE_TOKEN и SPM_TOKEN в определении DaemonSet, как показано ниже.

• Возьмите последний шаблон sematext-agent-daemonset.yml (необработанный текст) (также показанный ниже).

• Сохраните его где-нибудь на диске.

• Замените заполнители SPM_TOKEN и LOGSENE_TOKEN вашими токенами SPM и Logsene App.

Создать объект DaemonSet

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
   name: sematext-agent
spec:
   template:
      metadata:
         labels:
            app: sematext-agent
      spec:
         selector: {}
         dnsPolicy: "ClusterFirst"
         restartPolicy: "Always"
         containers:
         - name: sematext-agent
            image: sematext/sematext-agent-docker:latest
            imagePullPolicy: "Always"
            env:
            - name: SPM_TOKEN
               value: "REPLACE THIS WITH YOUR SPM TOKEN"
            - name: LOGSENE_TOKEN
               value: "REPLACE THIS WITH YOUR LOGSENE TOKEN"
            - name: KUBERNETES
               value: "1"
            volumeMounts:
               - mountPath: /var/run/docker.sock
                  name: docker-sock
               - mountPath: /etc/localtime
                  name: localtime
            volumes:
               - name: docker-sock
                  hostPath:
                     path: /var/run/docker.sock
               - name: localtime
                  hostPath:
                     path: /etc/localtime

Запуск Docker-агента Sematext с помощью kubectl

$ kubectl create -f sematext-agent-daemonset.yml
daemonset "sematext-agent-daemonset" created

Журнал Kubernetes

Журналы контейнеров Kubernetes мало чем отличаются от журналов контейнеров Docker. Однако пользователям Kubernetes необходимо просматривать журналы для развернутых модулей. Следовательно, очень полезно иметь доступную информацию о Kubernetes для поиска по журналам, например:

• Пространство имен Kubernetes
• Имя модуля Kubernetes
• Имя контейнера Kubernetes
• Имя образа Docker
• Kubernetes UID

Использование ELK Stack и LogSpout

Стек ELK включает Elasticsearch, Logstash и Kibana. Для сбора и пересылки журналов на платформу ведения журналов мы будем использовать LogSpout (хотя есть и другие варианты, такие как FluentD).

В следующем коде показано, как настроить кластер ELK в Kubernetes и создать службу для ElasticSearch.

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

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

apiVersion: v1
kind: ReplicationController
metadata:
   name: es
   namespace: elk
   labels:
      component: elasticsearch
spec:
   replicas: 1
   template:
      metadata:
         labels:
            component: elasticsearch
spec:
serviceAccount: elasticsearch
containers:
   - name: es
      securityContext:
      capabilities:
      add:
      - IPC_LOCK
   image: quay.io/pires/docker-elasticsearch-kubernetes:1.7.1-4
   env:
   - name: KUBERNETES_CA_CERTIFICATE_FILE
   value: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
   - name: NAMESPACE
   valueFrom:
      fieldRef:
         fieldPath: metadata.namespace
   - name: "CLUSTER_NAME"
      value: "myesdb"
   - name: "DISCOVERY_SERVICE"
      value: "elasticsearch"
   - name: NODE_MASTER
      value: "true"
   - name: NODE_DATA
      value: "true"
   - name: HTTP_ENABLE
      value: "true"
ports:
- containerPort: 9200
   name: http
   protocol: TCP
- containerPort: 9300
volumeMounts:
- mountPath: /data
   name: storage
volumes:
   - name: storage
      emptyDir: {}

Kibana URL

Для Kibana мы предоставляем URL-адрес Elasticsearch в качестве переменной среды.

- name: KIBANA_ES_URL
value: "http://elasticsearch.elk.svc.cluster.local:9200"
- name: KUBERNETES_TRUST_CERT
value: "true"

Пользовательский интерфейс Kibana будет доступен через порт контейнера 5601 и соответствующую комбинацию порта хоста / узла. Когда вы начнете, в Kibana не будет никаких данных (что ожидается, поскольку вы не отправили никаких данных).