looks like v1.12.2 is being installed. bump to v1.12.3 or v1.13?
```
root@kind-1-control-plane:/# kubectl --kubeconfig /etc/kubernetes/admin.conf get pods,deployments,services,replicasets,nodes --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system pod/coredns-576cbf47c7-2c48t 1/1 Running 0 8m4s
kube-system pod/coredns-576cbf47c7-krfsv 1/1 Running 0 8m4s
kube-system pod/etcd-kind-1-control-plane 1/1 Running 0 8m58s
kube-system pod/kube-apiserver-kind-1-control-plane 1/1 Running 0 8m34s
kube-system pod/kube-controller-manager-kind-1-control-plane 1/1 Running 1 9m
kube-system pod/kube-proxy-ksxf9 1/1 Running 0 8m5s
kube-system pod/kube-scheduler-kind-1-control-plane 1/1 Running 0 8m50s
kube-system pod/weave-net-ncs9s 2/2 Running 0 8m5s
NAMESPACE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
kube-system deployment.extensions/coredns 2 2 2 2 8m47s
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default service/kubernetes ClusterIP 10.96.0.1
kube-system service/kube-dns ClusterIP 10.96.0.10
NAMESPACE NAME DESIRED CURRENT READY AGE
kube-system replicaset.extensions/coredns-576cbf47c7 2 2 2 8m5s
NAMESPACE NAME STATUS ROLES AGE VERSION
node/kind-1-control-plane Ready master 9m42s v1.12.2
roo```
/assign
kind is also intended to be used with locally built images against arbitrary v1.11+ Kubernetes, and the default images provided were initially meant to be a convenience, but with emerging use cases besides the local development of Kubernetes itself mean we should be on top of this better!
working on an image update now.
/cc @munnerz - I think this is our first use case for release branches and a cherry pick - just the image bump
fixed with a Kubernetes v1.12.3 upgrade in #179, I also updated the release notes for 0.0.1 with instructions for using the new image rather than the default. we will look into an 0.0.2 in #180
Thank you for reporting this!
wow, that was _fast_, thanks!
I figured it's for internals and hard to get to, so gave a 30% chance this issue would get accepted and upgraded (but figured I might as well report just in case).
I, um, think while trying to use a work VM (instead of laptop) - which doesnt have go - that I might have just fired up "kind" inside "dind" (!) (uh... kindindind?)
Mostly just to poke the tires and see kind in action.
Thanks for the fix and this amazing little project. It blew my mind when I saw it in the Tues evening lightning talks at KubeCon in Seattle.
We try 馃槄
I figured it's for internals and hard to get to, so gave a 30% chance this issue would get accepted and upgraded (but figured I might as well report just in case).
Everything* is in a "node image" snapshot so upgrading to arbitrary versions is pretty straightforward if you have a Kubernetes dev environment. We build (but don't push yet) new ones against Kubernetes in CI.
* Not the overlay network yet.
I, um, think while trying to use a work VM (instead of laptop) - which doesnt have go - that I might have just fired up "kind" inside "dind" (!) (uh... kindindind?)
We actually do this (roughly speaking) regularly to run kind on Kubernetes's (the project's) own Kubernetes based CI :-)
I touched on that a little in my talk if you're curious: https://twitter.com/BenTheElder/status/1073336247794323457
Really glad to hear the feedback 馃槃
Most helpful comment
wow, that was _fast_, thanks!
I figured it's for internals and hard to get to, so gave a 30% chance this issue would get accepted and upgraded (but figured I might as well report just in case).
I, um, think while trying to use a work VM (instead of laptop) - which doesnt have go - that I might have just fired up "kind" inside "dind" (!) (uh... kindindind?)
Mostly just to poke the tires and see kind in action.
Thanks for the fix and this amazing little project. It blew my mind when I saw it in the Tues evening lightning talks at KubeCon in Seattle.