Keepalived nu va redirecționa traficul către nodul BACKUP după configurarea clusterului Kubernetes

Structura sistemului:

• 10.10.1.86: nodul principal Kubernetes
• 10.10.1.87: nodul 1 lucrător Kubernetes; mentine viata nod MASTER
• 10.10.1.88: nodul Kubernetes worker 2; mentine viata Nodul BACKUP
• 10.10.1.90: VIP, ar încărca echilibrul la .87 & .88; implementat de mentine viata.

Acest cluster Kubernetes este un mediu de dezvoltare, care testează jurnal netflow de colectare.

Ce vreau să obțin este:

1. Toate router-ul / comutatorul netflow jurnalul primului ieșire la .90
2. Apoi folosiți mentine viata a echilibra sarcina (lb_kind: NAT) la .87 & .88, care sunt doi lucrători Kubernetes.
3. Există NodePort Serviciu pentru a capta acest trafic în clusterul Kubernetes și pentru a face restul lucrărilor de analiză a datelor.

• Ceva asemănător cu:

        | {OS Network} | {Rețeaua Kubernetes}

                                K8s Worker -> filebeat -> logstash (implementari)
                              /
<date> -> [VIP] echilibru de încărcare
                              \ 
                                K8s Worker -> filebeat -> logstash (implementari)

• filebeat.yml (am testat că toate traficurile sunt bune după filebeat, așa că folosesc fişier ieșire la cauza principală restrânsă.)

# cat filebeat.yml
filebeat.inputs:

- tip: tcp
  dimensiune_max_mesaj: 10 MiB
  gazdă: „0.0.0.0:5100”

- tip: udp
  dimensiune_max_mesaj: 10 KiB
  gazdă: „0.0.0.0:5150”




#output.logstash:
# gazde: ["10.10.1.87:30044", "10.10.1.88:30044"]
fisier de iesire:
  cale: "/tmp/"
  nume de fișier: tmp-filebeat.out

Kubernetes

• Maestrul și Lucrătorii sunt 3 VM-uri în mediul meu privat; nu oricare dintre furnizorii GCP sau AWS.
• Versiune:

# versiune kubectl
Versiune client: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", 203e613a121a:04:028:04:02:04 21Z", GoVersion:"go1.16.1", Compiler:"gc", Platforma:"linux/amd64"}
Versiune server: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", 2028:04:04:028:04 06Z", GoVersion:"go1.16.1", Compiler:"gc", Platformă:"linux/amd64"}

• Servicii

# cat logstash.service.yaml
apiVersion: v1
fel: Serviciu
metadate:
  nume: serviciul-logstash
specificație:
  tip: NodePort
  selector:
    aplicație: logstash
  porturi:
    - port: 9514
      nume: tcp-port
      targetPort: 9514
      nodePort: 30044

• Odată ce datele ajung în Kubernetes, totul funcționează bine.
• A fost soldul de încărcare VIP care nu a fost redirecționat.

Keeplivered conf

!Fișier de configurare pentru keepalived
global_defs {
  router_id proxy1 # `proxy 2` la celălalt nod
}


vrrp_instance VI_1 {
  arătați MASTER # `BACKUP` la celălalt nod
  interfata ens160
  virtual_router_id 41
  prioritate 100 # `50` la celălalt nod
  advert_int 1
  adresa_virtuală {
    10.10.1.90/23
  }
}

virtual_server 10.10.1.90 5100 {
  bucla_întârziere 30
  lb_algo rr
  lb_kind NAT
  protocolul TCP
  persistence_timeout 0

  real_server 10.10.1.87 5100 {
    greutate 1
  }
  real_server 10.10.1.88 5100 {
    greutate 1
  }
}
virtual_server 10.10.1.90 5150 {
  bucla_întârziere 30
  lb_algo rr
  lb_kind NAT
  protocolul UDP
  persistence_timeout 0

  real_server 10.10.1.87 5150 {
    greutate 1
  }
  real_server 10.10.1.88 5150 {
    greutate 1
  }

Funcționează înainte de configurarea clusterului Kubernetes

• Ambii .87 & .88 au instalat mentine viata, și rr Echilibrul de încărcare (RoundRobin) funcționează bine (TCP și UDP).
• Stop mentine viata serviciu (systemctl stop keeplivered) când mergi la configurarea clusterului kubernetes, pentru orice eventualitate.

Problemă a apărut după configurarea clusterului Kubernetes

• Am găsit doar acel nod MASTER .87 poate redirecționa traficul, VIP-ul nu poate redirecționa către nodul BACKUP .88.
• Datele transmise de la MASTER sunt capturate cu succes de kubernetes NodePort și implementări.

Testarea problemei de către nc:

• nc: numai cine deține VIP (nodul MASTER) poate redirecționa trafic, când rr înaintează BACKUP, arată doar timeout.
• testat de asemenea de nc -l 5100 pe ambele servere, numai nodul MASTER a primit rezultate.

# echo „test” | nc 10.10.1.90 5100
# echo „test” | nc 10.10.1.90 5100
Ncat: Conexiunea a expirat.
# echo „test” | nc 10.10.1.90 5100
# echo „test” | nc 10.10.1.90 5100
Ncat: Conexiunea a expirat.

Câteva informații

• Versiuni de pachete

# rpm -qa |grep keepalived
keepalived-1.3.5-19.el7.x86_64

• Kubernetes CNI: Stambă

# kubectl get pod -n kube-system
STAREA NUMELE GATA REINCEPE VARSTA
calico-kube-controllers-b656ddcfc-wnkcj 1/1 Running 2 78d
calico-node-vnf4d 1/1 Running 8 78d
calico-node-xgzd5 1/1 Running 1 78d
calico-node-zt25t 1/1 Running 8 78d
coredns-558bd4d5db-n6hnn 1/1 Running 2 78d
coredns-558bd4d5db-zz2rb 1/1 Running 2 78d
etcd-a86.axv.bz 1/1 Running 2 78d
kube-apiserver-a86.axv.bz 1/1 Running 2 78d
kube-controller-manager-a86.axv.bz 1/1 Running 2 78d
kube-proxy-ddwsr 1/1 Running 2 78d
kube-proxy-hs4dx 1/1 Running 3 78d
kube-proxy-qg2nq 1/1 Running 1 78d
kube-scheduler-a86.axv.bz 1/1 Running 2 78d

• ipvsadm (același rezultat pe .87, .88)

# ipvsadm -ln
IP Virtual Server versiunea 1.2.1 (dimensiune=4096)
Adresă locală prot: Indicatori de planificare porturi
  -> RemoteAddress: Port Forward Weight ActiveConn InActConn
TCP 10.10.1.90:5100 rr
  -> 10.10.1.87:5100 Masq 1 0 0
  -> 10.10.1.88:5100 Masq 1 0 0
UDP 10.10.1.90:5150 rr
  -> 10.10.1.87:5150 Masq 1 0 0
  -> 10.10.1.88:5150 Masq 1 0 0

• Selinux este întotdeauna Permisiv
• Dacă opriți firewalld, inca nu functioneaza.
• sysctl diferență:

# inainte de:
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

# după
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

Nu sunt sigur dacă vreo verificare suplimentară se poate face acum, vă rugăm să sfătuiți, vă mulțumesc!