Run KinD (Kubernetes in Docker) as part of Gitlab CI job

.gitlab-ci.yml

#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

@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

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.