Структура системы:
10.10.1.86: главный узел Kubernetes10.10.1.87: рабочий узел Kubernetes 1; поддерживать активность ГЛАВНЫЙ узел10.10.1.88: рабочий узел Kubernetes 2; поддерживать активность РЕЗЕРВНЫЙ узел10.10.1.90: VIP, загрузит баланс на .87 & .88; осуществляется поддерживать активность.
Этот кластер Kubernetes представляет собой среду разработки, которая тестирует сбор журнала сетевого потока.
Чего я хочу добиться, так это:
- Все журналы сетевого потока маршрутизатора/коммутатора сначала выводятся на
.90
- Затем используйте
поддерживать активность загрузить баланс (lb_kind: NAT) к .87 & .88, которые являются двумя рабочими процессами Kubernetes.
- Есть
NodePort Сервис для перехвата этого трафика в кластер Kubernetes и выполнения остальных заданий по разбору данных.
| {Сеть ОС} | {Сеть Кубернетес}
K8s Worker -> filebeat -> logstash (развертывания)
/
<data> -> [VIP] баланс нагрузки
\
K8s Worker -> filebeat -> logstash (развертывания)
- filebeat.yml (проверил, что после filebeat с трафиком все в порядке, поэтому я использую
файл выход к узкой первопричине.)
# кот filebeat.yml
filebeat.inputs:
- тип: TCP
max_message_size: 10МиБ
хост: "0.0.0.0:5100"
- тип: удп
max_message_size: 10 КБ
хост: "0.0.0.0:5150"
#output.logstash:
# хосты: ["10.10.1.87:30044", "10.10.1.88:30044"]
выходной файл:
путь: "/tmp/"
имя файла: tmp-filebeat.out
Кубернетес
- Master и Workers — это 3 виртуальные машины в моей частной среде; ни один из поставщиков GCP или AWS.
- Версия:
# версия кубектла
Версия клиента: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T16:31: 21Z", версия Go: "go1.16.1", компилятор: "gc", платформа: "linux/amd64"}
Версия сервера: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T16:25: 06Z", версия Go: "go1.16.1", компилятор: "gc", платформа: "linux/amd64"}
# кот logstash.service.yaml
апиВерсия: v1
вид: сервис
метаданные:
имя: logstash-сервис
спецификация:
тип: NodePort
селектор:
приложение: логсташ
порты:
- порт: 9514
имя: tcp-порт
целевой порт: 9514
порт узла: 30044
- Как только данные попадают в Kubernetes, все работает нормально.
- Это был баланс нагрузки VIP, который не пересылался.
Keepalived conf
!Файл конфигурации для поддержки активности
global_defs {
router_id proxy1 # `прокси 2` на другом узле
}
vrrp_instance VI_1 {
состояние MASTER # `BACKUP` на другом узле
интерфейс ens160
виртуальный_маршрутизатор_id 41
приоритет 100 # `50` на другом узле
advert_int 1
виртуальный_ipaddress {
10.10.1.90/23
}
}
виртуальный_сервер 10.10.1.90 5100 {
delay_loop 30
lb_algo rr
lb_kind NAT
протокол TCP
persistence_timeout 0
реальный_сервер 10.10.1.87 5100 {
вес 1
}
реальный_сервер 10.10.1.88 5100 {
вес 1
}
}
виртуальный_сервер 10.10.1.90 5150 {
delay_loop 30
lb_algo rr
lb_kind NAT
протокол UDP
persistence_timeout 0
реальный_сервер 10.10.1.87 5150 {
вес 1
}
реальный_сервер 10.10.1.88 5150 {
вес 1
}
Работает до настройки кластера Kubernetes
- Обе
.87 & .88 установили поддерживать активность, и рр (RoundRobin) баланс нагрузки работает нормально (TCP и UDP).
- Останавливаться
поддерживать активность оказание услуг (systemctl остановить поддержку активности) при настройке кластера kubernetes, на всякий случай.
Проблема возникла после настройки кластера Kubernetes
- Обнаружено, что только ГЛАВНЫЙ узел
.87 может перенаправлять трафик, VIP не может пересылать на резервный узел .88.
- Перенаправленные данные от MASTER успешно перехватываются kubernetes
NodePort и развертывания.
Проверка проблемы нк:
нк: только тот, у кого есть VIP (ГЛАВНЫЙ узел), может пересылать трафик, когда рр вперед в BACKUP, он просто показывает тайм-аут.- также протестировано
нк -л 5100 на обоих серверах результаты получил только ГЛАВНЫЙ узел.
# эхо "тест" | нк 10.10.1.90 5100
# эхо "тест" | нк 10.10.1.90 5100
Ncat: Время ожидания соединения истекло.
# эхо "тест" | нк 10.10.1.90 5100
# эхо "тест" | нк 10.10.1.90 5100
Ncat: Время ожидания соединения истекло.
Некоторая информация
# rpm -qa |подтверждение активности grep
поддержка активности-1.3.5-19.el7.x86_64
# kubectl get pod -n kube-system
ИМЯ ГОТОВ СТАТУС ПЕРЕЗАПУСКА ВОЗРАСТ
calico-kube-controllers-b656ddcfc-wnkcj 1/1 Работает 2 78d
calico-node-vnf4d 1/1 Работает 8 78д
calico-node-xgzd5 1/1 Работает 1 78d
calico-node-zt25t 1/1 Ход 8 78d
coredns-558bd4d5db-n6hnn 1/1 Работает 2 78д
coredns-558bd4d5db-zz2rb 1/1 Бег 2 78д
etcd-a86.axv.bz 1/1 Работает 2 78d
kube-apiserver-a86.axv.bz 1/1 работает 2 78d
kube-controller-manager-a86.axv.bz 1/1 Работает 2 78d
kube-proxy-ddwsr 1/1 Работает 2 78д
kube-proxy-hs4dx 1/1 Работает 3 78 дней
kube-proxy-qg2nq 1/1 Работает 1 78d
kube-scheduler-a86.axv.bz 1/1 Работает 2 78d
ipvsadm (тот же результат на .87, .88)
# ipvsadm -ln
Виртуальный IP-сервер версии 1.2.1 (размер = 4096)
Prot LocalAddress: флаги планировщика портов
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.10.1.90:5100 рр
-> 10.10.1.87:5100 Маск 1 0 0
-> 10.10.1.88:5100 Маск 1 0 0
УДП 10.10.1.90:5150рр
-> 10.10.1.87:5150 Маск 1 0 0
-> 10.10.1.88:5150 Маск 1 0 0
- Селинукс всегда
Разрешительный
- Если остановить
брандмауэр, тоже не работает.
sysctl разница:
# перед:
net.ipv4.conf.all.accept_redirects = 1
net.ipv4.conf.all.forwarding = 0
net.ipv4.conf.all.route_localnet = 0
net.ipv4.conf.default.forwarding = 0
net.ipv4.conf.lo.forwarding = 0
net.ipv4.ip_forward = 0
# после
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.route_localnet = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.ip_forward = 1
Не уверен, что можно сделать дальнейшую проверку сейчас, пожалуйста, сообщите, спасибо!
