I am trying to setup node proxy so that I dont have to manually add sidecar tunnelers and everything should be proxied to the tunnel if the query contains ziti domain
I am currently in a private eks cluster with 2 nodes
I am following Kubernetes Node Daemonset | OpenZiti
for adding node-local-dns I followed the helm chart referred in that guide
helm install coredns-custom k8s-nodelocaldns-helm/node-local-dns
helm install ziti-edge-tunnel openziti/ziti-edge-tunnel --set-file zitiIdentity=vault-client2.json
which will connect to one of my ziti domain
I am sure the .json identity is correct since I tested with linux service tunnel and i get response .
The logs of service tunnel and the pod tunnel deployed by that helm-chart are same so I think the tunnel is fine .
I edited configmap coredns-custom to add
root@ip-10-0-7-22:/home/ubuntu# k describe cm/cordens-custom -n kube-system
Name: coredns-custom
Namespace: kube-system
Labels: <none>
Annotations: <none>
ziti.server:
----
vault1.ziti.internal {
forward . 100.64.0.2
}
BinaryData
====
Events: <none>
I am expecting all the pods in my cluster should be able to tunnel to vault1.ziti.internal and reach the service but they don't seem to resolve
I wonder where is is the 100.64.0.2 coming from as I just followed the doc ..
This is how the domain fails
root@ip-10-0-7-22:/home/ubuntu# k exec -it dnsutils -- sh
# nslookup vault1.ziti.internal
Server: 172.20.0.10
Address: 172.20.0.10#53
** server can't find vault1.ziti.internal: NXDOMAIN
Here are the tunnel pod logs
Tried with single node cluster with just deploying the tunnel pod and edit coredns configmap to ziti domain entry facing same issue
Here are the tunnel logs
It seems like the pod traffic is not going over that tunnel pod since I see the tunnel pod itself can resolve it
root@ip-10-0-7-22:/home/ubuntu# k exec -it ziti-edge-tunnel-bscs9 -- sh
sh-4.4# curl vault1.ziti.internal:8203/ui
<a href="/ui/">Temporary Redirect</a>.
Also please give a bit more detailing around Deploy a Hosting Tunneler in Kubernetes | OpenZiti .
I thought if we deploy tunnel in host mode then all pods should be able to reach ziti services naturally but even the tunnel pods cant resolve the ziti domains
using vault1.ziti.internal:53 at coredns configmap works ,
the coredns deployement does not seem to pick the coredns-custom config
After patching the Corefile, you must delete the CoreDNS pod so that a new one will be deployed, loading the changed Corefile. Then, you must wait for the CoreDNS deployment to be ready.
kubectl delete pods \
--namespace kube-system \
--selector k8s-app=kube-dns
kubectl wait deployments "coredns" \
--namespace kube-system \
--for condition=Available=True \
--timeout 240s
You found the correct guide. A hosting tunneler is like an exit point from Ziti to the normal network. It does not provide DNS or IP routes to clients. You can use a hosting tunneler as a reverse proxy for servers on the normal network for Ziti clients.
That's cool that you're using the Ziti daemonset to grant access to Vault. It seems like a powerful way to use it.
I understand the non-Ziti pod isn't finding the Ziti service address in DNS. It's likely because the your changes to the Corefile were not yet loaded.
ya later it works , when I deployed that local dns cache agent , the coredns I think does not consider that and it uses the original configmap itself I had to modify that to add ziti url with port 53
since the dns queries are listened at port 53 . Maybe you should update the doc for this please
I'm so happy to hear it's working. Will you please clarify that needs to be documented?
Are you saying that you had to add the forwarding rule for the ziti TLD in the Corefile?
yes ziti url had to be under the Corefile with a port 53 , the configmap name is coredns
Thank you for clarifying. What would you like to add to the section about configuring CoreDNS?
I think it should be modified to add this in configmap (change the configmap name to coredns instead of coredns-custom)
ziti.server: |
your.ziti.domain:53 {
forward . 100.64.0.2
}
