Code change:
To destroy the cluster: ``` <del> vagrant destroy -f </del> <ins> vagrant destroy </ins> ``` <del> You can also use the cluster/kube-*.sh scripts to interact with vagrant based providers just like any other hosting platform for kubernetes. </del> <ins> Once your Vagrant machines are up and provisioned, the first thing to do is to check that you can use the `kubecfg.sh` script. Set the `KUBERNETS_PROVIDER` environment variable and try to list the minions: </ins> ``` <del> cd kubernetes modify cluster/kube-env.sh: KUBERNETES_PROVIDER="vagrant" </del> <ins> $ export KUBERNETES_PROVIDER=vagrant $ ./cluster/kubecfg.sh list /minions Minion identifier ---------- 10.245.2.4 10.245.2.3 10.245.2.2 ``` ### Interacting with your Kubernetes cluster with the `kube-*` scripts. Alternatively to using the vagrant commands, you can also use the `cluster/kube-*.sh` scripts to interact with the vagrant based provider just like any other hosting platform for kubernetes. </ins> <del> ## build the binary required by kubecfg.sh </del> <ins> You need to build the binary required by `kube*` scripts: ``` </ins> hack/build-go.sh <ins> ``` Then bring up a vagrant cluster </ins> <del> cluster/kube-up.sh => brings up a vagrant cluster cluster/kube-down.sh => destroys a vagrant cluster cluster/kube-push.sh => updates a vagrant cluster cluster/kubecfg.sh => interact with the cluster </del> <ins> ``` cluster/kube-up.sh ``` Destroy the vagrant cluster ``` cluster/kube-down.sh ``` Update the vagrant cluster ``` cluster/kube-push.sh ``` Interact with the cluster ``` cluster/kubecfg.sh </ins> ``` ### Authenticating with your master <del> To interact with the cluster, you must authenticate with the master when running cluster/kubecfg.sh commands. </del> <ins> When using the vagrant provider in Kubernetes, the `cluster/kubecfg.sh` script will cache your credentials in a `~/.kubernetes_auth_vagrant` file so you will not be prompted for them in the future. </ins> <del> If it's your first time using the cluster, your first invocation of cluster/kubecfg.sh will prompt you for credentials: </del> <ins> ``` cat ~/.kubernetes_auth_vagrant { "User": "vagrant", "Password": "vagrant"} ``` You should now be set to use the `cluster/kubecfg.sh` script. For example try to list the minions that you have started with: </ins> ``` <del> cd kubernetes </del> cluster/kubecfg.sh list minions <del> Please enter Username: vagrant Please enter Password: vagrant </del> <ins> ``` ### Running containers Your cluster is running, you can list the minions in your cluster: ``` $ cluster/kubecfg.sh list /minions </ins> Minion identifier ---------- <ins> 10.245.2.4 10.245.2.3 10.245.2.2 </ins> ``` <del> The kubecfg.sh command will cache your credentials in a .kubernetes_auth file so you will not be prompted in the future. </del> <ins> Now start running some containers! You can now use any of the cluster/kube-*.sh commands to interact with your VM machines. Before starting a container there will be no pods, services and replication controllers. </ins> ``` <del> cat ~/.kubernetes_auth {"User":"vagrant","Password":"vagrant"} </del> <ins> $ cluster/kubecfg.sh list /pods ID                  Image(s)            Host                Labels              Status ----------          ----------          ----------          ----------          ---------- $ cluster/kubecfg.sh list /services ID                  Labels              Selector            Port ----------          ----------          ----------          ---------- $ cluster/kubecfg.sh list /replicationControllers ID                  Image(s)            Selector            Replicas ----------          ----------          ----------          ---------- </ins> ``` <del> If you try Kubernetes against multiple cloud providers, make sure this file is correct for your target environment. </del> <ins> Start a container running nginx with a replication controller and three replicas: ``` $cluster/kubecfg.sh -p 8080:80 run dockerfile/nginx 3 myNginx ``` </ins> <del> ### Running a container </del> <ins> When listing the pods, you will see that three containers have been started and are in Waiting state: </ins> <del> Your cluster is running, and you want to start running containers! </del> <ins> ``` $ cluster/kubecfg.sh list /pods ID                                     Image(s)            Host                    Labels                          Status ----------                             ----------          ----------              ----------                      ---------- 781191ff-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.4/10.245.2.4   replicationController=myNginx   Waiting 7813c8bd-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.2/10.245.2.2   replicationController=myNginx   Waiting 78140853-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.3/10.245.2.3   replicationController=myNginx   Waiting ``` </ins> <del> You can now use any of the cluster/kube-*.sh commands to interact with your VM machines. </del> <ins> You need to wait for the provisioning to complete, you can monitor the minions by doing ``` $ vagrant ssh minion-1 $ sudo docker images REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE <none>              <none>              96864a7d2df3        26 hours ago        204.4 MB google/cadvisor     latest              e0575e677c50        13 days ago         12.64 MB kubernetes/pause    latest              6c4579af347b        8 weeks ago         239.8 kB ``` Once the docker image for nginx has been downloaded, the container will start and you can list it: ``` $ sudo docker ps CONTAINER ID        IMAGE                     COMMAND                CREATED             STATUS              PORTS                    NAMES dbe79bf6e25b        dockerfile/nginx:latest   "nginx"                21 seconds ago      Up 19 seconds                                k8s--mynginx.8c5b8a3a--7813c8bd_-_3ffe_-_11e4_-_9036_-_0800279696e1.etcd--7813c8bd_-_3ffe_-_11e4_-_9036_-_0800279696e1--fcfa837f fa0e29c94501        kubernetes/pause:latest   "/pause"               8 minutes ago       Up 8 minutes        0.0.0.0:8080->80/tcp     k8s--net.a90e7ce4--7813c8bd_-_3ffe_-_11e4_-_9036_-_0800279696e1.etcd--7813c8bd_-_3ffe_-_11e4_-_9036_-_0800279696e1--baf5b21b aa2ee3ed844a        google/cadvisor:latest    "/usr/bin/cadvisor -   38 minutes ago      Up 38 minutes                                k8s--cadvisor.9e90d182--cadvisor_-_agent.file--4626b3a2 65a3a926f357        kubernetes/pause:latest   "/pause"               39 minutes ago      Up 39 minutes       0.0.0.0:4194->8080/tcp   k8s--net.c5ba7f0e--cadvisor_-_agent.file--342fd561 ``` Going back to listing the pods, services and replicationControllers, you now have: ``` $ cluster/kubecfg.sh list /pods ID                                     Image(s)            Host                    Labels                          Status ----------                             ----------          ----------              ----------                      ---------- 781191ff-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.4/10.245.2.4   replicationController=myNginx   Running 7813c8bd-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.2/10.245.2.2   replicationController=myNginx   Running 78140853-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.3/10.245.2.3   replicationController=myNginx   Running $ cluster/kubecfg.sh list /services ID                  Labels              Selector            Port ----------          ----------          ----------          ---------- $ cluster/kubecfg.sh list r/eplicationControllers ID                  Image(s)            Selector                        Replicas ----------          ----------          ----------                      ---------- myNginx             dockerfile/nginx    replicationController=myNginx   3 </ins> ``` <del> cluster/kubecfg.sh list /pods cluster/kubecfg.sh list /services cluster/kubecfg.sh list /replicationControllers cluster/kubecfg.sh -p 8080:80 run dockerfile/nginx 3 myNginx ## begin wait for provision to complete, you can monitor the minions by doing vagrant ssh minion-1 sudo docker images ## you should see it pulling the dockerfile/nginx image, once the above command returns it sudo docker ps ## you should see your container running! exit ## end wait </del> <ins> We did not start any services, hence there is none listed. But we see three replicas displayed properly. Check the [guestbook](examples/guestbook/README.md) application to learn how to create a service. You can already play with resizing the replicas with: </ins> <del> ## back on the host, introspect kubernetes! cluster/kubecfg.sh list /pods cluster/kubecfg.sh list /services cluster/kubecfg.sh list /replicationControllers </del> <ins> ``` $ cluster/kubecfg.sh resize myNginx 2 $ cluster/kubecfg.sh list /pods ID                                     Image(s)            Host                    Labels                          Status ----------                             ----------          ----------              ----------                      ---------- 7813c8bd-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.2/10.245.2.2   replicationController=myNginx   Running 78140853-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.3/10.245.2.3   replicationController=myNginx   Running </ins> ``` Congratulations!

Related discussion:
text: Which jobs are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /priority important-soon /cc /cc /milestone v1.18 /sig release
/assign
This is failing because a 1.18 release for CRI tools doesn't exist yet. I can tweak the test job arguments to skip this later.
(As a note, this job is important, but not ) /remove-priority critical-urgent /priority important-soon
Do we need to remove the job from dashboard?
-- No. I'll work on fixing the job later today.
I've started to investigate, but I haven't yet reproduced the new error locally: This is likely related to a recent refactor of the package that handles interpreting deb/rpm package versions. As is not currently in use, I'm moving this to the milestone. /milestone v1.19
the version issue is fixed via The test is now failing because it tries to download cri-tools v1.18.0: which I think is related to this code part:
Updating testgrid link here: Any updates here /retitle [Flaky Test] build-packages-debs (ci-release-build-packages-debs) /kind flaky-test
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Updating testgrid link here: /kind flaky-test Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind flake
I was assuming that is working on this issue. I can jump in if you want and do not find the time to work on it. :)
/assign /unassign Sascha -- Can you take this? I thought I was going to have time to look at this, but it's been a while.
Sure, the reason for the failing test seems to have changed, I'm on it.
Fix is incoming in