why ask run docker container in VC doc?

[jichenjc]

What steps did you take and what happened: [A clear and concise description on how to REPRODUCE the bug.]

What did you expect to happen:

https://github.com/kubernetes-sigs/cluster-api-provider-nested/blob/main/virtualcluster/doc/demo.md

# Remove the container if there is any
#$ docker rm -f ${CLUSTER_NAME}-kind-proxy-${VC_SVC_PORT} || true
# Create this sidecar container
$ docker run -d --restart always \
    --name ${CLUSTER_NAME}-kind-proxy-${VC_SVC_PORT} \
    --publish 127.0.0.1:${VC_SVC_PORT}:${VC_SVC_PORT} \
    --link ${CLUSTER_NAME}-control-plane:target \
    --network kind \
    alpine/socat -dd \
    tcp-listen:${VC_SVC_PORT},fork,reuseaddr tcp-connect:target:${VC_SVC_PORT}

# And update the vc-1.kubeconfig
$ sed -i".bak" "s|.*server:.*|    server: https://127.0.0.1:${VC_SVC_PORT}|" vc-1.kubeconfig

ask me to run this command but seems without those steps I still can access cluster by using previous generated vc-1.kubeconfig file , so what's the purpose of those steps?

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-nested version:
• Minikube/KIND version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

/kind bug [One or more /area label. See https://github.com/kubernetes-sigs/cluster-api-provider-nested/labels?q=area for the list of labels]

[christopherhein]

For macOS and Windows machines Kind networking isn't properly setup for you to expose the clusters endpoint to the local host, (they both run the kind cluster in a nested virtual machine) for linux machines this shouldn't be necessary. If you look at the CAPN docs we get around this by asking you to kubectl port-forward. Which is inessence doing the same thing but it uses a docker image running socat to create the "proxy" from local into the docker based kind cluster.

Did you happen to use kind with a non-default name? this can cause that command to not work… for example if you did kind create cluster --name capn the values in that docker run command aren't correct anymore.

[jichenjc]

ok, I missed this line

Please note that if you're working on kind cluster which, by default, exposes one random host port pointing to Kubernetes' default API Server port 6443. In this case, we need to work around it and the simplest way is to deploy a "sidecar" container as the proxy to route management traffic to the service:

so I will re-structure the doc to make it clearer