I am running a microk8s instance on Ubuntu server as a vanilla install, configured with MetalLB to dynamically allocate 10.0.2.1 to 10.0.2.200 and the Nginx ingress controller enabled. I've installed the wordpress helm chart on this instance () with the following command:
helm install wordpress \ --set wordpressUsername=admin \ --set wordpressPassword=password \ --set mariadb.mariadbRootPassword=secretpassword \ --set ingress.enabled=true \ --set ingress.hostname=wordpress.internal \ bitnami/wordpressService is up and running successfully, and when I run
kubectl describe services wordpressI get the following:
Name: wordpress
Namespace: default
Labels:
Annotations: wordpress default
Selector:
Type: LoadBalancer
IP: 10.152.183.73
LoadBalancer Ingress: 10.0.2.1
Port: http 80/TCP
TargetPort: http/TCP
NodePort: http 31799/TCP
Endpoints: 10.1.70.14:8080
Port: https 443/TCP
TargetPort: https/TCP
NodePort: https 30087/TCP
Endpoints: 10.1.70.14:8443
Session Affinity: None
External Traffic Policy: Cluster
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal IPAllocated 32m metallb-controller Assigned IP "10.0.2.1" Normal nodeAssigned 6m41s (x3 over 31m) metallb-speaker announcing from node "k8s"When I am SSH'ed onto the node where microk8s is installed, the instance responds as I would expect:
curl 10.0.2.1
<!DOCTYPE html>
<html lang="en-US"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0" > <link rel="profile" href=""> <title>User's Blog! – Just another WordPress site</title>However, when I run the same command over my networked Macbook, I'm unable to get a response:
curl 10.0.2.1
curl: (7) Failed to connect to 10.0.2.1 port 80: Operation timed out1 Answer
After noting that the following two methodologies worked:
- Access via portforward (navigate to localhost:8080 in browser with below command)
kubectl port-forward *podname-here* 8080:8080 - NodePort (navigating to browser at k8s-master-ip:31799)
I isolated the issue to the IP range I had allocated to metallb. The problem was that I had allocated an IP range to metallb (10.0.2.1-10.0.2.200) that was outside of the subnet mask configured in my consumer router (Apple Airport Extreme). Once I changed the IP range to one within the subnet allowed by the router (10.0.1.100-10.0.1.150), navigation to the service IP worked as expected.
