Then you will need to add allow rules to three stages: the control plane, Replicated, and your app.
After following these steps, if you continue to experience networking failures, use dmesg to easily discover traffic that is still being blocked by UFW.

Kubernetes Control Plane

The first rule you should add is to allow traffic to the Kubernetes API server. Although it runs in a pod, the kube API server uses host networking, so allowing traffic to the host port 6443 will allow external clients such as kubectl and kubelet to access the Kubernets API.

sudo ufw allow 6443

Services in the kube-system namespace should still be failing at this point. You may notice that the coreDNS pods are being restarted. If you run kubectl describe on those pods, the kubelet will be reporting that it failed to run liveness checks, but if you check the logs of the coreDNS pod there is no record of having ever received a health check. The kubelet in the host network needs to be able to send packets “out” via the weave interface to communicate with pods.

sudo ufw allow out on weave to 10.32.0.0/12

At this point, the coreDNS pod will begin receiving liveness probes from kubelet and will in turn probe the Kubernetes API server to ensure it can retrieve a list of Endpoints. The pod will use the kubernetes service cluster address, 10.96.0.1:443, but will experience i/o timeouts attempting to reach the Kubernetes API server in the host namespace.

sudo ufw allow in on weave from 10.32.0.0/12

Clusters

For multi-node installs open up the tcp and udp ports required for Weave’s control plane and data plane traffic.