Установка Minikube
При запуске Minikube вам потребуется выделить немного дополнительной мощности, поскольку планируется развернуть многоузловой кластер Elasticsearch.
minikube start --cpus 4 --memory 8192
Вы должны увидеть следующее:
[Output]
Вы должны увидеть следующее:
Starting local Kubernetes v1.10.0 cluster…
Запуск VM…
Получение IP-адреса виртуальной машины…
Перемещение файлов в кластер…
Установка сертификатов…
Подключение к кластеру…
Настройка kubeconfig…
Запуск компонентов кластера…
Kubectl теперь настроен на использование кластера.
Чтобы убедиться, что ваш одноузловой кластер Kubernetes запущен и работает, используйте:
kubectl cluster-info
[Output]
Kubernetes master работает по адресу https:// 192.168.59.102:8443.
CoreDNS запущен по адресу https:// 192.168.59.102:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Для дальнейшей отладки и диагностики проблем кластера используйте:
kubectl cluster-info dump
Развертывание Elasticsearch
Прежде всего, нам нужно развернуть экземпляр Elasticsearch в нашем кластере. Обычно Elasticsearch требует 3 узла для работы в своем собственном кластере.
Однако, поскольку мы используем Minikube в качестве среды разработки, мы настроим Elasticsearch для работы в одноузловом режиме, чтобы он мог работать на нашем единственном симулированном узле Kubernetes в Minikube.
Итак, в терминале введите следующую команду для развертывания Elasticsearch в нашем кластере.
C:Helm>kubectl create -f es-deployment.yaml
[Output]
deployment.apps/es-logging created
C:Helm>kubectl get deployments
[Output]
ИМЯ ГОТОВО АКТУАЛЬНО ДОСТУПНО ВОЗРАСТ
es-logging 1/1 1 1 3m31s
C:Helm>kubectl get pods
[Output]
ИМЯ ГОТОВО СОСТОЯНИЕ ПЕРЕЗАПУСК ВОЗРАСТ
es-logging-5744d89fb9-xhbq7 1/1 Running 0 4m28s
Для получения дополнительной информации о состоянии развертывания или подсистемы используйте команды kubectl describe или kubectl logs:
$ kubectl describe deployment es-logging
$ kubectl describe pod es-logging-5744d89fb9-xhbq7
$ kubectl logs –f deployments/es-logging
Раскрытие Elasticsearch
Теперь, когда Elasticsearch запущен в нашем кластере, нам нужно раскрыть его, чтобы мы могли подключать к нему другие сервисы. Для краткого объяснения, это позволит нам раскрыть наш ресурс развертывания Elasticsearch через службу, которая даст нам возможность получить доступ к нашему Elasticsearch HTTP API из других ресурсов (а именно Logstash и Kibana).
Выполните следующую команду, чтобы открыть наш Deployment:
C:Helm>kubectl create -f es-svc.yaml
[Output]
service/es-service created
В результате будет создан ресурс Kubernetes Service, который открывает порт 9200 из нашего ресурса Elasticsearch Deployment, HTTP-порт Elasticsearch. Теперь этот порт будет доступен через порт, назначенный в кластере. Чтобы увидеть эту службу и внешний порт, который был назначен, выполните следующую команду:
C:Helm>kubectl get svc
[Output]
ИМЯ ТИП КЛАСТЕР-IP ВНЕШНИЙ-IP ПОРТ(Ы) ВОЗРАСТ
es-service NodePort 10.97.114.162 9200:32375/TCP 6s
kubernetes ClusterIP 10.96.0.1 443/TCP 54m
C:Helm>minikube service es-service
[Output]
|———–|————|————-|—————————–|
| NAMESPACE | NAME | TARGET PORT | URL |
|———–|————|————-|—————————–|
| по умолчанию | es-service | 9200 | http://192.168.59.102:32375 | |
|———–|————|————-|—————————–|
- Открываем сервис default/es-service в браузере по умолчанию…
Чтобы получить IP-адрес Minikube:
C:Helm>minikube ip
[Output]
192.168.59.102
Как вы можете видеть, наш HTTP-порт Elasticsearch был сопоставлен с внешним портом 32375. Поскольку мы работаем через Minikube, внешний порт будет предназначен для этой виртуальной машины, поэтому мы будем использовать IP-адрес Minikube и внешний порт, чтобы проверить, что наша настройка работает правильно.
[Browser Output]
{
“name” : “es-logging-5744d89fb9-xhbq7”,
“cluster_name” : “docker-cluster”,
“cluster_uuid” : “XKT9bYwCR1CencccW6JggQ”,
“version” : {
“number” : “7.8.0”,
“build_flavor” : “default”,
“build_type” : “docker”,
“build_hash” : “757314695644ea9a1dc2fecd26d1a43856725e65”,
“build_date” : “2020-06-14T19:35:50.234439Z”,
“build_snapshot” : false,
“lucene_version” : “8.5.1”,
“minimum_wire_compatibility_version” : “6.8.0”,
“minimum_index_compatibility_version” : “6.0.0-beta1”
},
“tagline” : “You Know, for Search”
}
Чтобы проверить настройку точки здоровья для зондов liveness и readyiness, выполните команду Run:
http://192.168.59.102:32375/_cluster/health
[Output]
{ “cluster_name”: “docker-cluster”, “status”: “green”, “timed_out”:false, “number_of_nodes”:1, “number_of_data_nodes”:1, “active_primary_shards”:0, “active_shards”:0, “relocating_shards”:0, “initializing_shards”: 0, “unassigned_shards”:0, “delayed_unassigned_shards”:0, “number_of_pending_tasks”:0, “number_of_in_flight_fetch”:0, “task_max_waiting_in_queue_millis”:0, “active_shards_percent_as_number”:100. 0}
Развертывание Kibana
Теперь, когда у нас есть запущенный экземпляр Elasticsearch, доступный через IP-адрес Minikube и назначенный номер порта, мы запустим экземпляр Kibana и подключим его к Elasticsearch. Мы сделаем это тем же способом, которым настраивали Elasticsearch: создадим еще один ресурс Kubernetes Deployment.
C:Helm>kubectl create -f kibana-deployment.yaml
[Output]
deployment.apps/kibana-logging created
C:Helm>kubectl get deployment kibana-logging
[Output]
ИМЯ ГОТОВО АКТУАЛЬНО ДОСТУПНО ВОЗРАСТ
kibana-logging 1/1 1 1 1 70s
Как и в случае с экземпляром Elasticsearch, наш экземпляр Kibana не будет работать сразу. Причина в том, что он не знает, где запущен экземпляр Elasticsearch. По умолчанию он будет пытаться подключиться, используя URL http://elasticsearch:9200. Вы можете убедиться в этом, проверив журналы Kibana pod.
C:Helm>kubectl get pods
[Output]
ИМЯ ГОТОВЫЙ СТАТУС ПЕРЕЗАПУСК ВОЗРАСТ
es-logging-5744d89fb9-xhbq7 1/1 Running 0 33m
kibana-logging-5dc77584cc-7jfnt 1/1 Running 0 2m13s
C:Helm>kubectl logs kibana-logging-5dc77584cc-7jfnt
[Output]
{“type”:”log”,”@timestamp”:”2022-03-28T10:15:18Z”,”tags”:[“warning”,”elasticsearch”,”admin”],”pid”:11,”message”:”Unable to revive connection: http://elasticsearch:9200/”}
URL экземпляра Elasticsearch определяется через переменную окружения в докер-образе Kibana, как и режим для Elasticsearch. Однако фактический ключ переменной – ELASTICSEARCH_HOSTS, который содержит все допустимые символы для использования команды kubectl для изменения переменной окружения в ресурсе развертывания. Поскольку теперь мы знаем, что можем получить доступ к HTTP-порту Elasticsearch через сопоставленный с хостом порт 32375 на IP Minikube, мы можем обновить Kibana для указания на экземпляр Elasticsearch.
C:Helm>minikube ip
[Output]
192.168.59.102
Затем установите переменную окружения с помощью следующей команды
kubectl set env deployments/kibana-logging ELASTICSEARCH_HOSTS=http://$(minikube ip):elasticsearch-Node-port
например
C:Helm>kubectl set env deployments/kibana-logging ELASTICSEARCH_HOSTS=http://192.168.59.102:32375
[Output]
deployment.apps/kibana-logging env updated
Примечание: Нам не нужно использовать IP Minikube, чтобы наши компоненты могли общаться друг с другом. Поскольку они живут в одном кластере Kubernetes, мы можем использовать кластерный IP, назначенный каждому ресурсу Service (выполните kubectl get services, чтобы узнать IP-адреса кластера). Это особенно полезно, если ваша установка возвращает IP-адрес localhost для вашей установки Minikube. В этом случае вам не нужно будет использовать порт узла, а вместо него использовать фактический порт контейнера.
Это вызовет изменения в развертывании, в результате чего существующий Kibana Pod будет завершен, и будет запущен новый Pod (с новым значением переменной окружения). Если вы снова запустите kubectl get pods, вы должны увидеть этот новый Pod. Опять же, если мы проверим журналы нового Pod, мы увидим, что он успешно подключился к экземпляру Elasticsearch и теперь размещает веб-интерфейс на порту 5601.
C:Helm>kubectl logs -f pod/kibana-logging-59d555748b-mg76x
[Output]
{“type”:”log”,”@timestamp”:”2022-03-28T10:51:14Z”,”tags”:[“listening”,”info”],”pid”:9,”message”:”Server running at http://0:5601″}
{“type”:”log”,”@timestamp”:”2022-03-28T10:51:15Z”,”tags”:[“info”,”http”,”server”,”Kibana”],”pid”:9,”message”:”http server running at http://0:5601″}
Доступ к пользовательскому интерфейсу Kibana
Теперь, когда Kibana запущена и взаимодействует с Elasticsearch, нам нужно получить доступ к веб-интерфейсу, который позволит нам настраивать и просматривать журналы. Мы уже видели, что он работает на порту 5601, но, как и в случае с HTTP-портом Elasticsearch, этот порт является внутренним для контейнера, запущенного внутри Pod. Поэтому нам нужно также открыть этот ресурс развертывания через службу.
C:Helm>kubectl create -f kibana-svc.yaml
[Output]
сервис/kibana-service created
Теперь мы должны иметь возможность просматривать веб-интерфейс, используя тот же IP Minikube, что и раньше, и новый порт. Посмотрите на новый сервис, чтобы получить сопоставленный порт.
C:Helm>kubectl get services
[Output]
ИМЯ ТИП КЛАСТЕР-IP ВНЕШНИЙ-IP ПОРТ(Ы) ВОЗРАСТ
es-service NodePort 10.97.114.162 9200:32375/TCP 32m
kibana-logging NodePort 10.105.131.15 5601:32457/TCP 8s
kubernetes ClusterIP 10.96.0.1 443/TCP 87m
C:Helm>minikube service kibana-service
[Output]
|———–|—————-|————-|—————————–|
| NAMESPACE | NAME | TARGET PORT | URL |
|———–|—————-|————-|—————————–|
| default | kibana-service | 5601 | http://192.168.59.102:32417 | http://192.168.59.102:32417 |
|———–|—————-|————-|—————————–|
- Открываем сервис default/kibana-logging в браузере по умолчанию… Теперь перейдите в браузере на URL: “http://192.168.59.102:32417/status”, чтобы проверить, что веб-интерфейс запущен и Elasticsearch подключен правильно.
Развертывание Logstash
Следующим шагом будет запуск Logstash в нашей установке. Logstash будет работать как инструмент, который будет собирать журналы из нашего приложения и отправлять их в Elasticsearch. Он предоставляет различные преимущества для фильтрации и переформатирования сообщений журнала, а также для сбора из различных источников и вывода в различные места назначения. В данном руководстве мы будем использовать его только в качестве сквозного сборщика и перенаправителя журналов.
На приведенной выше схеме вы можете видеть нашу желаемую установку. Наша цель – развернуть контейнер Logstash в новый Pod. Этот контейнер будет настроен на прослушивание порта 5044 для получения записей журнала, отправляемых приложением Filebeat (подробнее об этом позже). Затем эти сообщения журнала будут перенаправляться прямо на наш экземпляр Elasticsearch, который мы настроили ранее, через HTTP-порт, который мы открыли.
Для достижения этой настройки нам придется использовать YAML-файлы Kubernetes. Это более подробный способ создания развертываний, который можно использовать для описания различных ресурсов (таких как развертывания, службы и т.д.) и их создания с помощью одной команды. Причина, по которой нам нужно использовать этот способ, заключается в том, что нам нужно настроить том для доступа к нему нашего контейнера Logstash, что невозможно с помощью команд CLI. Аналогично, мы могли бы использовать этот подход, чтобы сократить количество шагов, необходимых для предыдущей настройки Elasticsearch и Kibana, а именно конфигурацию переменных окружения и отдельные шаги для создания ресурсов Service для открытия портов в контейнерах.
Создайте файл под названием logstash.conf и введите следующие параметры:
Note: Please update the minikube_ip:elasticsearch-nodeport
input {
beats {
port => "5044"
}
}
output {
elasticsearch {
hosts => ["http://192.168.99.102:30445"]
index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}"
}
stdout {
codec => rubydebug
}
}
Далее нам нужно создать новый файл под названием deployment.yml. Введите следующее содержимое YAML ресурса развертывания Kubernetes для описания нашего развертывания Logstash.
Нам нужно создать этот ConfigMap. Этот том будет содержать созданный нами файл logstash.conf, который будет сопоставлен с папкой конфигурации трубопровода в контейнере Logstash. Он будет использоваться для настройки нашего необходимого сквозного трубопровода. Итак, выполните следующую команду:
C:Helm>kubectl create configmap log-manual-pipeline --from-file ./logstash.conf
[Output]
configmap/log-manual-pipeline created
Теперь мы можем создать ресурс Deployment из нашего файла logstash-deployment.yml.
C:Helm>kubectl create -f logstash-deployment.yml
[Output]
deployment.apps/logstash-logging created
Примечание: Вы можете заметить ошибки, говорящие об отсутствии доступных подключений к конечной точке экземпляра Elasticsearch с URL http://elasticsearch:9200/. Это происходит из-за некоторой конфигурации по умолчанию в образе Docker, но не влияет на наш конвейер, поэтому в данном случае ее можно проигнорировать.
Открыть порт Logstash Filebeats
Теперь, когда Logstash запущен и прослушивает контейнерный порт 5044 для записей сообщений журнала Filebeats, нам нужно убедиться, что этот порт отображен на хост, чтобы мы могли настроить экземпляр Filebeats в следующем разделе. Для этого нам нужен еще один ресурс Service, чтобы открыть порт на хосте Minikube. Мы могли бы сделать это в том же файле deployment.yml, но стоит использовать тот же подход, что и раньше, чтобы показать, как дескриптор ресурса и команды CLI могут использоваться совместно.
C:Helm>kubectl create -f logstash-svc.yml
[Output]
сервис/logstash-service created
C:Helm>kubectl get svc
[Output]
ИМЯ ТИП КЛАСТЕР-IP ВНЕШНИЙ-IP ПОРТ(Ы) ВОЗРАСТ
es-service NodePort 10.97.114.162 9200:32375/TCP 74m
kibana-service NodePort 10.105.131.15 5601:32457/TCP 15m
kubernetes ClusterIP 10.96.0.1 443/TCP 129m
logstash-service NodePort 10.110.161.161 5044:31810/TCP 13с
Как вы можете видеть, порт 5044 контейнера был сопоставлен с портом 31810 на узле. Теперь мы можем перейти к последнему шагу: настройке нашего приложения и контейнера Sidecar Filebeats для отправки сообщений журнала через наш экземпляр Logstash в Elasticsearch.
Развертывание приложения
Существует несколько различных способов структурировать это, но я собираюсь описать подход, при котором мы развертываем наше приложение и экземпляр Filebeat как отдельные контейнеры в одном Pod. Затем мы будем использовать том Kubernetes, известный как Empty Directory, для разделения доступа к файлу журнала, в который приложение будет писать, а Filebeats – читать из него. Причина использования этого типа тома заключается в том, что его жизненный цикл будет напрямую связан с Pod. Если вы хотите сохранить данные журнала вне Pod, чтобы при завершении и повторном создании Pod том оставался, то я бы предложил рассмотреть другой тип тома, например, Local.
Для начала мы создадим конфигурационный файл для экземпляра Filebeats. Создайте файл с именем filebeat.yml и введите в него следующее содержимое.
Note: Please update the minikube_ip:logstash-nodeport
filebeat.inputs:
- type: log
paths:
- /tmp/output.log
output:
logstash:
hosts: [ "192.168.99.102:31010" ]
Это укажет Filebeat отслеживать файл /tmp/output.log (который будет расположен в общем томе) и затем выводить все сообщения журнала в наш экземпляр Logstash (обратите внимание, что здесь мы использовали IP-адрес и номер порта для Minikube).
Теперь нам нужно создать том ConfigMap из этого файла.
C:Helm>kubectl create configmap beat-manual-config --from-file ./filebeat.yml
[Output]
configmap/beat-manual-config created
Далее нам нужно создать наш Pod с настройкой двойного контейнера. Для этого, как и в предыдущем разделе, мы создадим файл app-deployment.yml.
Чтобы создать этот ресурс развертывания, выполните следующую команду:
C:Helm>kubectl create -f app-deployment.yml
[Output]
deployment.apps/logging-app-manual created
Оба контейнера будут иметь общую папку, сопоставленную с путем /tmp, в которую будет записываться и из которой будет считываться файл журнала. Контейнер Filebeat также будет использовать только что созданный том ConfigMap, который мы указали для экземпляра Filebeat для чтения конфигурационного файла, перезаписав конфигурацию по умолчанию.
Вы также заметите, что наш контейнер приложения использует Docker-образ sladesoftware/log-application:latest. Это простой образ Docker, который построен на основе образа Alpine Linux и выполняет команду бесконечного цикла, которая добавляет небольшой объект JSON в выходной файл каждые несколько секунд.
C:Helm>minikube service kibana-service
[Output]
|———–|—————-|————-|—————————–|
| ПРОСТРАНСТВО ИМЕН | ИМЯ | ЦЕЛЕВОЙ ПОРТ | URL |
|———–|—————-|————-|—————————–|
| default | kibana-service | 5601 | http://192.168.59.102:32457 | http://192.168.59.102:32457 |
|———–|—————-|————-|—————————–|
- Открываем сервис default/kibana-service в браузере по умолчанию… Теперь вы должны иметь возможность перейти к панели Kibana в веб-браузере, чтобы просмотреть поступающие журналы. Убедитесь, что вы сначала создали индексный шаблон для чтения этих журналов – вам нужен формат типа filebeat*.
После создания индексного шаблона вы сможете просматривать сообщения журнала по мере их поступления в Elasticsearch на странице Discover в Kibana.