Run KinD (Kubernetes in Docker) as part of Gitlab CI job
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#Spin up Kubernetes control plane as part of before_script, and destroys it using after_script | |
#Some custom logic to get to the right ip address | |
#Requres the gitlab docker runner, with "pass-thru" to the host docker socket. | |
stages: | |
- test | |
image: python:3.6.6 #the docker image you run in needs Docker installed, and access to the host docker socket. | |
test_integration_k8s: | |
tags: | |
- linux-docker | |
stage: test | |
before_script: | |
- curl -Lo kubectl https://storage.googleapis.com/kubernetes-release/release/v1.12.0/bin/linux/amd64/kubectl | |
- chmod +x kubectl | |
- mv kubectl /usr/local/bin/ | |
- curl -Lo kind https://github.com/kubernetes-sigs/kind/releases/download/0.1.0/kind-linux-amd64 | |
- chmod +x kind | |
- mv kind /usr/local/bin/ | |
- kind create cluster --name $CI_PIPELINE_ID --wait 180s | |
- export KUBECONFIG="$(kind get kubeconfig-path --name $CI_PIPELINE_ID)" | |
- REAL_IP=$(ip route|awk '/default/ { print $3 }') | |
- sed -i -e "s/localhost/$REAL_IP/g" $KUBECONFIG | |
script: | |
- kubectl get nodes --insecure-skip-tls-verify=true | |
after_script: | |
- kind delete cluster --name $CI_PIPELINE_ID |
you're probably right. It's been a long time since I've looked at this, so I don't remember I'm afraid.
@trondhindenes is there a specific reason why you manually delete the cluster in the
after_script
? Since this is ran inside a container I would expect it to be cleaned up anyways after the job finished
If you don't do that, a container running kind will be running forever in the Gitlab runner host.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@trondhindenes is there a specific reason why you manually delete the cluster in the
after_script
? Since this is ran inside a container I would expect it to be cleaned up anyways after the job finished