Kind cluster inside gitlab seems unreachable

[TheErk]

What happened:

Use kind inside a gitlab CI runner.
The cluster is created fine but I cannot use it after creation

kubectl cluster-info

spit out

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
The connection to the server localhost:40819 was refused - did you specify the right host or port?

What you expected to happen:

Create an in-CI cluster and populate the k8s cluster as usual.

How to reproduce it (as minimally and precisely as possible):

Start a gitlab CI job with kind inside.
Create a kind cluster:

kind create cluster --config=kind-config.yaml --name kind39f9b9
Creating cluster "kind39f9b9" ...
 • Ensuring node image (kindest/node:v1.14.2) 🖼  ...
 ✓ Ensuring node image (kindest/node:v1.14.2) 🖼
 • Preparing nodes 📦📦  ...
 ✓ Preparing nodes 📦📦
 • Creating kubeadm config 📜  ...
 ✓ Creating kubeadm config 📜
 • Starting control-plane 🕹️  ...
 ✓ Starting control-plane 🕹️
 • Installing CNI 🔌  ...
 ✓ Installing CNI 🔌
 • Installing StorageClass 💾  ...
 ✓ Installing StorageClass 💾
 • Joining worker nodes 🚜  ...
 ✓ Joining worker nodes 🚜
Cluster creation complete. You can now use the cluster with:

export KUBECONFIG="$(kind get kubeconfig-path --name="kind39f9b9")"
kubectl cluster-info

Then try

kubectl cluster-info

and you'll get

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
The connection to the server localhost:40819 was refused - did you specify the right host or port?

Anything else we need to know?:

This behavior really looks like the one described in #52 but I don't know how to properly apply the VOLUME trick. At least I tried with no success.

Environment:

• kind version: v0.3.0
• Kubernetes version: v1.14.3
• Docker version: 18.09.6
• OS : Debian Jessie

[BenTheElder]

What gitlab CI runner?

This is almost definitely because the cluster binds to localhost by default (for security reasons) and the localhost is somewhere other than where your kubectl binary is running.

The solution to this is to either change your setup so that this is not true, or to configure the kind apiServerListenAddress in the config

[TheErk]

Currently we use: gitlab/gitlab-runner:alpine-v10.7.0.
I think I see, let's suppose I find the context in which kubectl is running.
Where can I find documentation on how to specify apiServerListenAddress in my yaml config for kind?

[aojea]

just Ben replied in slack to this 😄

apiVersion: kind.sigs.k8s.io/v1alpha3
networking:
   apiServerAddress: 0.0.0.0

to obtain the kubeconfig using the internal ip address , to use per example from other internal containers, we just merged a new command
#478

[TheErk]

Thanks @aojea I've just joined k8s slack, I'll try to find my way in all those channels.
Nice for #478 how can I monitor the next kind release that will ship this?

[BenTheElder]

we are currently tracking release efforts with github milestones. the next release is tentatively slated to be by the 24th but we have a little flexibility. In particular still aiming to land the initial ipv6 support.

https://github.com/kubernetes-sigs/kind/milestone/6

[TheErk]

I did update my config with:

• kind version: v0.4.0
• Kubernetes version: v1.15.0

and follow: https://github.com/kind-ci/examples/blob/master/.gitlab-ci.yml
I still have issue as explained here:
#620 (comment)

I'll come back here when I find my solution. Since this may be very gitlab configuration specific, feel free to close this ticket and I'll propose some explanation/solution (when I find them) in https://github.com/kind-ci/examples/

[BenTheElder]

SGTM, it would be very helpful to document there and post a link back to here then.

I'm hoping to direct more of the CI specific config etc. there, we're starting to link out to it in https://kind.sigs.k8s.io/docs/user/resources/#using-kind-in-ci