kubernates on prem 502 bad gateway

Question

Hi I have installed and configured kubernates I have tried with both minikube and kubeadm What I have installed: flannel, nginx-ingress-controller, metalLB then setted ngix-ingress-controller service to be loadBalancer

I always get 502 bad gateway when trying to expose a simple wordpress app (using clusterIp or even with nodePort)

OS: ubuntu 20.04 LTS installed docker-ce, kubeadm and kubelt (official kubernates site tutorial)

Installation procedure i have followed: 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

flannel:

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: followed onsite tutorial

I have tryed to change ingress-nginx-controller service to be LoadBalancer and add the externalIP but nothing changes

here are my yamls: service

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

ingress

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

Answer 1

Thanks to @Jakub I have missed to configure metalLB (create a config map) then I have setted ingress-nginx-controller to be loadBalancer works perfectly

Answer 2

Just to clarify what was wrong here.

As mentioned in MetalLB documentation:

MetalLB remains idle until configured. This is accomplished by creating and deploying a configmap into the same namespace (metallb-system) as the deployment.

There is an example Layer 2 configuration.

Layer 2 mode is the simplest to configure: in many cases, you don’t need any protocol-specific configuration, only IP addresses.

Layer 2 mode does not require the IPs to be bound to the network interfaces of your worker nodes. It works by responding to ARP requests on your local network directly, to give the machine’s MAC address to clients.

For example, the following configuration gives MetalLB control over IPs from 192.168.1.240 to 192.168.1.250, and configures Layer 2 mode:

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

---

Additionally there is great tutorial on medium which explains how to set it up from scratch on minikube.

MetalLB contains two pieces of information, a protocol and range of IP addresses. In this configuration MetalLB is instructed to handout addresses from the 192.168.99.95/105, its our predefined range with respect to node IP. In our case to get IP of our minikube we use minikube ip command and set range accordingly in config file.