When I install the router in the minikube cluster, I cannot connect to the controller. The error is as follows:
This is my etc/hosts file：
This is my etc/hosts file：
Welcome to the OpenZiti community, @songt!
That's cool that you're playing with Ziti in Minikube. Before we go too far, I want to ensure you are aware of the most relevant resources
To me, it looks like you have a router deployed in K8s that can't reach the controller to enroll. Is the controller also in K8s? Will your router in K8s be the only router? Is your router in K8s also published to the cluster edge, and if so, with what type of K8s service or ingress?
With Minikube there are several approaches covered in the Minikube quickstart, one for each major OS. Are you running Minikube directly on Linux with the Docker driver, or in a Docker Desktop VM on Windows or macOS, or something else?
Here's my best guess: you need to configure your controller's advertised address with a domain name that is reachable inside and outside of the cluster if you want to use it from both sides of the cluster edge horizon.
Your pods inside the Minikube cluster are using CoreDNS, potentially augmented by the ingress-dns plugin, in case you have that enabled.
You can simplify things somewhat by trying the K3D example I linked. That one separates the Ziti servers by TCP port instead of DNS name, and uses the built-in Traefik LoadBalancer instead of ingress-nginx. It's slightly less complex since there's no Ingress Controller in the mix.
Thank you very much. I have already resolved this issue. But I have a new requirement now. We want to deploy a private router in k8s through helm, but we don't want to enable persistence. So, do I just need to extract the certificate file (/etc/ziti/configure/router. cas;/etc/ziti/configure/router. cer;/etc/ziti/configure/router. server. chain. cer) after starting the private router with jwt for the first time, and map these four files to the corresponding location the next time I start using help?, There was no problem when I used the certificate to start the private router for the second time, but when I deleted the router again and used the certificate to start the private router for the third time, an error occurred
I think you want to manage the router's identity files outside of Kubernetes instead of letting the router manage them automatically in a storage volume.
Normally, the router will manage its identity files through the enrollment process. This includes renewing the certificate before it expires and writing the new certificate file to the same path.
The router will keep running if it can't save the new certificate, but will be unable to restart if the saved certificate is expired. If that occurs your only option is to re-enroll the expired router or create a new one.
The router chart has some flexibility that may allow you to accomplish your goal without a Kubernetes storage volume. You can set the input value persistence.enabled=false and the first run will succeed using an ephemeral emptyDir to store the identity files. The router will operate normally until the pod is destroyed, and fail subsequent runs because the identity files were not persisted.
Theoretically, after I get the certificate related to the router container, destroy the router container, and map the certificate to the same location when starting the router container, I can start the router normally and communicate with the controller, but I have a problem here.
Yes, but your router's certs will expire if it can't write the renewals to its configured path.
I'm able to fetch your controller's server certificate on port 8440, so it's online. I'm guessing there a problem with the router's client certificate, since that's the part we're working to configure.
The underlying problem might be more clear if you increase log verbosity. In the router chart, you can set input value image.additionalArgs: ["--verbose"].
If you see a problem with the client cert, you can check its contents by referencing the router's config YAML to find the file path to the client cert, server cert, key, and root CA trust bundle.
This is the router started by mounting the certificate. The relevant logs printed are as follows
[image]
Were you able to overcome the two problems you reported? If there's still an unsolved issue, will you share the text log instead of an image?
The forum will let you post a text log as a code block by enclosing the paste with triple backticks like this
```
log messages
```
A post was split to a new topic: A question about BrowZer and the example