kubernates no gateway prem 502 inválido

kubernates no gateway prem 502 inválido

Olá, instalei e configurei kubernates, tentei com minikube e kubeadm O que instalei: flannel, nginx-ingress-controller, metalLB e depois configurei o serviço ngix-ingress-controller como loadBalancer

Eu sempre recebo 502 gateway inválido ao tentar expor um aplicativo wordpress simples (usando clusterIp ou mesmo com nodePort)

SO: ubuntu 20.04 LTS instalado docker-ce, kubeadm e kubelt (tutorial oficial do site kubernates)

Procedimento de instalaçãoeu segui: Kube init:

kubeadm init --pod-network-cidr=10.244.0.0/16

kubectl taint nodes --all node-role.kubernetes.io/master-

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

flanela:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

nginx

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/baremetal/deploy.yaml

metallb: tutorial no local seguido

Tentei alterar o serviço ingress-nginx-controller para LoadBalancer e adicionar o externalIP, mas nada muda

aqui estão meus yamls: serviço

apiVersion: v1
kind: Service
metadata:
  labels:
    appcluster: kubernetes
    app: wordpress
  name: wordpress-service
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http-port
  selector:
    app: wordpress
  type: ClusterIP

entrada

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: wordpress-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
    - host: ethernial.com
      http:
        paths:
          - path: /?(.*)
            backend:
              serviceName: wordpress-service
              servicePort: 80

Responder1

Graças a @Jakub, deixei de configurar o metalLB (criar um mapa de configuração), então configurei o ingress-nginx-controller para que o loadBalancer funcione perfeitamente

Responder2

Apenas para esclarecer o que estava errado aqui.

Conforme mencionado no MetalLBdocumentação:

MetalLB permanece inativo até ser configurado. Isso é feito criando e implantando um configmap no mesmo namespace (metallb-system) da implantação.

Há um exemploConfiguração da camada 2.

O modo Camada 2 é o mais simples de configurar: em muitos casos, não é necessária nenhuma configuração específica de protocolo, apenas endereços IP.

O modo Camada 2 não exige que os IPs estejam vinculados às interfaces de rede dos nós do trabalhador. Ele funciona respondendo diretamente às solicitações ARP na sua rede local, para fornecer o endereço MAC da máquina aos clientes.

Por exemplo, a configuração a seguir dá ao MetalLB controle sobre IPs de 192.168.1.240 a 192.168.1.250 e configura o modo Camada 2:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.240-192.168.1.250

Além disso, há um ótimo tutorial sobremédioque explica como configurá-lo do zero no minikube.

MetalLB contém duas informações, um protocolo e um intervalo de endereços IP. Nesta configuração o MetalLB é instruído a distribuir endereços de 192.168.99.95/105, que é nosso intervalo predefinido em relação ao IP do nó. No nosso caso, para obter o IP do nosso minikube, usamos o comando minikube ip e definimos o intervalo de acordo no arquivo de configuração.

insira a descrição da imagem aqui insira a descrição da imagem aqui

informação relacionada