Expor as portas 80 e 443 no Google Container Engine sem balanceador de carga

Question

Atualmente, estou trabalhando em um pequeno projeto de passatempo que tornarei o código aberto quando estiver pronto. Este serviço está sendo executado no Google Container Engine. Eu escolhi o GCE para evitar problemas de configuração, os custos são acessíveis e para aprender coisas novas.

Meus pods estão funcionando bem e eu criei um serviço com o tipo LoadBalancer para expor o serviço nas portas 80 e 443. Isso funciona perfeitamente.

No entanto, descobri que, para cada serviço LoadBalancer , é criado um novo balanceador de carga do Google Compute Engine. Este balanceador de carga é muito caro e muito mais feito para um projeto de hobby em uma única instância.

Para reduzir os custos, estou procurando uma maneira de expor as portas sem o balanceador de carga.

O que eu tentei até agora:

• Implemente um serviço NodePort . Infelizmente, não é permitido expor um porta abaixo de 30000.

• Implante um Ingress, mas isso também cria um balanceador de carga.

• Tentou desativar HttpLoadBalancing ( link ), mas ainda cria um balanceador de carga.

Existe uma maneira de expor as portas 80 e 443 para uma única instância no Google Container Engine sem um balanceador de carga?

    

Answer 1

Sim, através de IPs externos no serviço. Exemplo de serviço que usei:

apiVersion: v1
kind: Service
metadata:
  name: bind
  labels:
    app: bind
    version: 3.0.0
spec:
  ports:
    - port: 53
      protocol: UDP
  selector:
    app: bind
    version: 3.0.0
  externalIPs:
    - a.b.c.d
    - a.b.c.e

Por favor, esteja ciente de que os IPs listados no arquivo de configuração devem ser o IP interno no GCE.

    

Answer 2

Além da excelente solução de trabalho do ConnorJC: A mesma solução também é descrita nesta pergunta: Kubernetes - posso evitar o uso do balanceador de carga GCE para reduzir custos?

O "internalIp" refere-se ao ip interno da instância de computação (a.k.a. do nó) (como visto no Google Cloud Platform - > Google Compute Engine - > Instâncias de VM)

Este comentário dá uma dica de por que o ip interno e não o externo deve ser configurado .

Além disso, depois de ter configurado o serviço para as portas 80 e 443, tive que criar uma regra de firewall que permitisse o tráfego para o meu nó de instância:

gcloud compute firewall-rules create your-name-for-this-fw-rule --allow tcp:80,tcp:443 --source-ranges=0.0.0.0/0

Após essa configuração, pude acessar meu serviço por meio de http (s): // externalIp

    

Answer 3

Se você tiver exatamente um pod, use hostNetwork: true para conseguir isso:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: caddy
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: caddy
    spec:
      hostNetwork: true # <---------
      containers:
      - name: caddy
        image: your_image
        env:
        - name: STATIC_BACKEND # example env in my custom image
          value: $(STATIC_SERVICE_HOST):80

Note que, ao fazer isso , seu pod herdará o resolvedor de DNS do host e não o Kubernetes '. Isso significa que você não pode mais resolver serviços de cluster por nome DNS. Por exemplo, no exemplo acima, você não pode acessar o serviço static no link . Você ainda pode acessar os serviços pelo IP do cluster, que é injetado pelas variáveis de ambiente .

Esta solução é melhor do que usar o externalIP do serviço quando ele ignora o kube-proxy, e você receberá o IP de origem correto.