Requirements Overview

Previously, some services hosted on Kubernetes at home, such as portal, emby, weave scope, etc., were accessed using service ip, which was slightly troublesome to access, mainly because the ip had to be remembered.

Kubernetes provides Ingress to solve the problem of load balancer type service (vip consumption, L7 load feature, etc.).

For this requirement, you can set up pan domain on godaddy with type A, for example *.lab.ieevee.com, and resolve it to the service ip of ingress; for the new web site, just create ingress and set its host from *.lab.ieevee.com and then you can resolve to the corresponding service directly at home.

The following is an example of emby.

Deploying the ingress controller

The ingress controller used this time is traefik, which is easy to deploy using helm.

1
2

$ git clone https://github.com/containous/traefik-helm-chart
$ helm install --namespace=traefik-v2 ./traefik-helm-chart/traefik

After deployment: traefik does not have the ingress controller capability, you still need to modify the deployment and add parameters.

1

--providers.kubernetesingress=true

Create ingress

Create ingress for emby: host is emby.lab.ieevee.com; serviceName is emby’s service, not required to be load balancer type.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: emby
  namespace: default
spec:
  rules:
  - host: emby.lab.ieevee.com
    http:
      paths:
      - backend:
          serviceName: emby
          servicePort: 80
        path: /

Local hosts test

Configure the hosts file locally and test that it should work.

Configure pan-domain

I have my own domain name and don’t need something more primitive like hosts.

Godaddy supports configuring pan-domains, considering that there are other ingress needs behind, so instead of creating a separate A record for emby, I configure pan-domains *.lab.ieevee.com on Godaddy, emby is just one of them, the real triage is achieved on the ingress controller.

pan-domains

Thus, whether it is a.lab.ieevee.com or b.lab.ieevee.com, it will resolve to 192.168.9.1, and this ip, is the service traefix load balancer ip.

1
2
3

$ kubectl get svc
NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
virtuous-gibbon-traefik   LoadBalancer   10.100.135.27   192.168.9.1   80:30182/TCP,443:31831/TCP   7h29m

openwrt configuration DNS Rebinding whitelist

After configuration, I found that I can resolve emby.lab.ieevee.com on the host of aws and other hosts in my home network, but none of the hosts hanging under openwrt can resolve.

After checking the logs of openwrt, I saw the following line.

1

Fri Jan 31 23:38:01 2020 daemon.warn dnsmasq[11062]: possible DNS-rebind attack detected: emby.lab.ieevee.com

It turns out that openwrt has detected DNS Rebinding and filtered it out. According to openwrt’s detection mechanism, if Rebind protection is enabled, openwrt will filter out the return result of the request as long as the returned IP address is a LAN IP.

DNS Rebinding is a kind of attack means, the purpose is to resolve IP address through DNS re-request, bypassing the browser detection of cross-domain attacks. You can refer to Ref-1/Ref-2 for details.

My approach here is to add a whitelist to lab.ieevee.com.

whitelist

Summary

By configuring the pan-domain on Godaddy, the domain request from *.lab.ieevee.com will be resolved to the vip of ingress traefik; traefik, as the ingress controller, will forward the http request to the corresponding pod according to the vhost, so that you can use various services at home through the domain name so that you can use various services at home through the domain name, without having to remember the IP address.