Perguntas[load-balancing](server)

Eu estava passando por este tutorial e diz que precisamos definir NodePortquando usar o tipo de serviço LoadBalancer.

Mas já vi implementação de LoadBalancertipos de serviço sem fornecer arquivos nodePort. Como isso funciona e o que é correto?

captura de tela:

Situação: Um site que gerenciamos foi migrado para uma nova solução hospedada e também terá um novo nome de domínio. Os clientes desejam manter o nome de domínio antigo e redirecioná-lo para o novo nome de domínio na solução hospedada (sobre a qual basicamente não temos controle).

Adicionei um redirecionamento 301 no nível do AWS Application Load Balancer. Ele desvia perfeitamente o tráfego do URL antigo para o novo. O problema, porém, é que o pessoal da segurança determina que o URL antigo - para continuar - precise responder com um cabeçalho HSTS. Isso está um pouco fora da minha área e não estou encontrando uma solução excelente para isso.

A única solução viável que consigo pensar - ainda não testei, porque espero que haja algo melhor - é manter o servidor no back-end e fornecer um cabeçalho HSTS antes de fornecer o redirecionamento. Parece um pouco demais manter um servidor apenas para adicionar um cabeçalho.

Lendo a documentação e outros tópicos aqui, não parece que posso adicionar um cabeçalho HSTS diretamente à resposta do ALB.

Acho que as opções como as vejo agora são:

1. Convença o cliente a abandonar o domínio antigo
2. Convença o pessoal da segurança de que a falta de HSTS no domínio antigo é aceitável
3. Mantenha um servidor rodando apenas para fornecer o HSTS (se isso funcionar)
4. Algo mais?

Para aprender um pouco mais sobre o K8S, comecei a executar um cluster K3S de servidor/nó único como um laboratório doméstico. Mas acredito que cheguei a um impasse na minha compreensão do modelo de rede, talvez específico do K3S.

Até aí tudo bem, exceto que eu queria aplicar um certificado TLS a alguns serviços + entradas que configurei.

Em um deles configurei um certificado TLS como segredo e apliquei no Ingress associado ao serviço, porém sempre consigo o TRAEFIK DEFAULT CERT, que você pode ver aqui .

Pelo que entendi, o K3S vem com Traefik e ServiceLB pré-empacotados para não depender de balanceadores de carga externos de serviços em nuvem (AWS etc). Meu primeiro palpite foi que o Traefik iria "descobrir" as rotas configuradas em meu Ingress e fazer proxy do tráfego TLS, usando assim o certificado que configurei. Claramente, este não é o caso, então suponho que preciso configurar um certificado TLS para a própria instância do Traefik.

Minhas perguntas são então

• Como posso configurar este certificado no K3S e preciso de um certificado curinga se pretendo ter vários projetos/domínios atingindo este cluster? (Eu preferiria gerenciar os certificados por projeto)
• Quais são as funções do ServiceLB e do Traefik no modelo de rede K3S? Se o Traefik estiver obtendo o tráfego 80 e 443, ele está apenas encaminhando o tráfego para o ServiceLB, que o encaminhará para o recurso Ingress?

Caso seja necessário, aqui está minha configuração de entrada/serviço

resource kubernetes_service_v1 snitch_service {
  metadata {
    name = "snitch"
    namespace = module.namespace.name
  }


  spec {
    selector = {
      app = "snitch"
    }

    type = "LoadBalancer"

    port {
      name = "main"
      port = 3010
      target_port = 3000
      node_port = 30003
    }
  }
}



resource kubernetes_secret_v1 tls_secret {
  metadata {
    name = "snitch-tls-cert"
    namespace = "my-namespace"
  }

  type = "kubernetes.io/tls"

  data = {
    "tls.crt" = base64encode(my_certificate)
    "tls.key" = base64encode(my_certificate_private_key)
  }
}


resource kubernetes_ingress_v1 snitch_ingress {
  metadata {
    name = "snitch"
    namespace = "my-namespace"

    annotations = {
      "ingress.kubernetes.io/ssl-redirect" = "false"
    }
  }

  spec {
    tls {
      hosts = [local.subdomain]
      secret_name = "snitch-tls-cert"
    }

    rule {
      host = local.subdomain

      http {
        path {
          path = "/"
          path_type = "Prefix"

          backend {
            service {
              name = "snitch"
              port {
                number = 3010
              }
            }
          }
        }
      }
    }
  }
}

Obrigado!

Estou tentando configurar um Network Load Balancer que direciona o tráfego para servidores íntegros com base em dados da Camada 3/Camada 4 (protocolo IP).

Question: Isso funciona para LDAP sobre SSL (LDAPS)? (Estou ciente de que a camada 7 executa a descriptografia TLS/SSL conforme necessário)

Eu tenho um Network Load Balancer e meus dois servidores back-end estão executando o serviço LDAP.
É possível executar ldapsearchcom o seguinte resultado:

Alguma sugestão de como resolver isso?

EDIT: Ao executar ldapsearch -x -H ldaps://<NLB>recebo o seguinte erro:

ldap_sasl_interactive_bind: Can't contact LDAP server (-1)
        additional info: (unknown error code)

Adicionando a -d1opção:

ldap_url_parse_ext(ldaps://ipa.example.com)
ldap_create
ldap_url_parse_ext(ldaps://ipa.example.com:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ipa.example.com:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.141.4.23:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
TLS: hostname (ipa.example.com) does not match common name in certificate (ipa2.exmaple.com).
TLS: can't connect: (unknown error code).
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Então... Parece que preciso anexar um certificado ao NLB contendo ipa1 e ipa2 no certificado? Não tenho certeza se isso é compatível com o provedor de nuvem.

Observação: não consigo fazer SSH no NLB porque é um serviço gerenciado.

Suponha que enfrentamos xsolicitações por segundos, onde xé o número mágico de solicitações que um único balanceador de carga não pode manipular.

Portanto, temos que usar vários balanceadores de carga para lidar com todas as solicitações, sim? Mas como? Preciso balancear a carga do farm de balanceadores de carga? Má ideia, no final também ocorre que um único balanceador de carga deve lidar com todas as solicitações.

Então, como usar vários balanceadores de carga para lidar com um grande número de solicitações?

a configuração

Eu administro o back-end de um site que existe atualmente em um único nó usando Nginx (webserver), Neo4J (banco de dados) e Wildfly (servidor de aplicativos). O site está recebendo tráfego suficiente para que tenhamos recursos de armazenamento e memória limitados no nó 'all-in-one' atual, então instanciei mais dois nós VPS (3 no total) que executarão apenas o WildFly.

Eu configurei o Nginx com sucesso para usar o recurso de balanceamento de carga 'hash' nos 3 nós com base em um ID de usuário contido no URI do site para garantir que os usuários sejam roteados consistentemente para o mesmo nó VPS executando o Wildfly para otimizar o armazenamento em cache.

Cada um dos 3 nós tem seu próprio bloco de armazenamento de alta disponibilidade de 150 GB (mantido pelo provedor VPS) que contém um único /imagesdiretório montado no qual o aplicativo Wildfly estará lendo/gravando arquivos de imagem de/para seu respectivo nó.

Atualizar

Os arquivos de imagem devem ser escritos uma vez/ler muitos (pelo menos para o caso nominal) para que novas imagens sejam criadas o tempo todo, mas as imagens existentes raramente são atualizadas. Além disso, devido ao balanceamento de carga de hash do Nginx, cada nó do Wildfly deve ter todas as imagens necessárias para os clientes que são roteados para ele. A necessidade de replicação é realmente dupla:

1. Ele torna a adição ou remoção de nós do Wildfly transparente, pois cada nó possui todos os dados dos outros nós
2. Facilita o backup, pois tudo é consolidado em um só lugar

Além disso, cada um dos nós VPS faz parte de uma VLAN gigabit privada que o provedor VPS habilita para todos os nós no mesmo datacenter (dos quais estão todos os meus nós). Será esse link que os dados de replicação percorrerão.

O problema

Como o aplicativo agora está distribuído, desejo que cada um dos /imagesdiretórios nos 3 nós seja totalmente replicado. Embora o balanceamento de carga 'hash' do Nginx garanta o uso consistente do nó por usuário, quero que o conteúdo do /imagesdiretório seja uma união de todos os três nós no caso de um dos nós cair e os usuários precisarem ser redistribuídos entre os outros nós disponíveis.

A questão

Qual é a melhor maneira de resolver o problema acima? Pelo que entendi, rsyncnão é a ferramenta apropriada para este trabalho. Há esta pergunta de falha do servidor que é de natureza semelhante, mas tem 12 anos e tenho certeza de que houve alguns avanços na replicação de dados desde então.

Em minha pesquisa, encontrei o GlusterFS , que parece promissor, mas não está claro como configurar isso para resolver meu problema. Eu tornaria cada um dos dispositivos de armazenamento em bloco de alta disponibilidade em cada nó um único 'tijolo' e então combinaria isso em um único volume Gluster? Presumo que criei o /imagesdiretório neste único volume Gluster e o montei em cada um dos nós por meio do cliente FUSE nativo? Meu instinto diz que isso não está correto porque cada um dos nós são clientes e servidores simultaneamente, pois ambos estão contribuindo com um 'tijolo' e lendo/gravando no volume Gluster, o que parece não convencional.

(Abaixo está um cenário hipotético e essa pergunta me veio à mente quando descobri as complexidades do balanceamento de carga do gRPC e como ele não é eficiente devido à conexão TCP de longa duração)

Imagine que há um cliente HTTP que mantém uma única conexão TCP de longa duração para fazer solicitações HTTP 1.1 para um serviço de API localizado atrás do proxy HA. Existem vários servidores redundantes como parte do serviço e desejo equilibrar todas as solicitações na mesma conexão TCP em diferentes servidores upstream. Algo assim é possível?

Entendo que o cliente pode ter várias conexões abertas ao LB o que ajudará a causa.

Mas eu estou querendo saber se é possível fazer isso diretamente usando alguma configuração de proxy HA. Se não, por que esse recurso está faltando? É devido a algum tipo de limitação de protocolo de rede/HTTP? Ou esse recurso nunca foi necessário porque existem outras soluções alternativas?

Vamos supor que o TLS seja encerrado no proxy HA para que ele possa fazer o roteamento L7. Além disso, o HAProxy é apenas um exemplo, qualquer outro LB / Proxies como Envoy, Nginx que seja capaz desse recurso?

Então, eventualmente, quero configurar um balanceador de carga clássico na AWS e tenho uma VPC com 2 sub-redes públicas, mas agora não tenho certeza se posso usar essas duas sub-redes para essa instância do EC2 ou preciso de duas instâncias do ec2?

Se eu tiver um ALB em minha infraestrutura com grupos de destino do ECS downstream, o SSL/TLS sempre será encerrado no ALB?

Em caso afirmativo, minhas únicas opções são ELB/NLB para preservar o contexto SSL/TLS?

Temos dois servidores em nuvem da Hetzner. O servidor web é o Nginx. Ambos os servidores são idênticos (hardware, software e nossa aplicação web).

O certificado LetsEncrypt está instalado em ambos os servidores. Nginx está configurado para redirecionar httppara https.

O servidor DNS é Cloudflare. Mudamos o endereço IP do registro A do nosso domínio manualmente do Servidor A para o Servidor B ou vice-versa.

Agora criamos um Load Balancer na Hetzer com nossos dois servidores e um serviço: https 443 -> 443.

Assim que alteramos o endereço IP do registro A do nosso domínio para o endereço IP do LB, recebemos 503 service unavailable.

Por favor, ajude.