-
Notifications
You must be signed in to change notification settings - Fork 8
kubelet isn't running. #7
Comments
Hello @rohitsakala . To maybe reproduce that issue please let me know:
Thanks! |
Hi @hoegaarden,
[0] https://github.com/cloudfoundry-incubator/cf-operator-ci/blob/master/docs/concourse-deployment-steps.md |
Mh ... One thing I found was that running a cluster inside a task requires quite some resources, so when the workers are not quite beefy enough and other pipelines were running on the same concourse I saw some flakes similar to that. Could you maybe test with a single node cluster? You could do that by either setting the cat <<'EOF' > /tmp/kind.yml
kind: Cluster
apiVersion: kind.sigs.k8s.io/v1alpha3
nodes:
- role: control-plane
EOF
KIND_CONFIG="$(</tmp/kind.yml)" KIND_TESTS='kubectl get nodes -o wide' \
fly -t <flyTarget> execute \
--config kind.yaml \
--privileged \
--inputs-from 'kind-test/kind' Currently, we run kind-on-c tests only on k8s (here) and it seems pretty stable (all of the recent failed & aborted runs are either fixed in kind-on-c or where infrastructure flakes). We also ran the same pipeline on a BOSH deployed concourse for a while, but we didn't see any fundamental difference and decommissioned that recently. So I am not sure where your issue comes from. In the logs you provided I don't see anything standing out, but it might be useful to inspect the kubelet logs (something like: |
Hi @hoegaarden, I have also encountered this same issue in my concourse deployment. To jump start this discussion again, some additional context and logging are provided from my environment. Issue
Troubleshooting
Also indicated by the kubelet
Full log can be found here: https://publicly-exposed.s3-us-west-2.amazonaws.com/exit ConclusionIt appears that the none of the supported container runtimes including Reproducekind version:
git branch: https://github.com/fyangd/kind-on-c/tree/etcd_failure_repro |
@fyangd -- sorry for the late reply. One thing I found, is that kind-on-c / kind had issues with on btrfs. A workaround has been implemented in be0268d, with that kind-on-c generally works on runway. However, especially compared to hush-house, kind-on-c is veeeerry falky on runway. I didn't get around digging deeper on why exactly that is. If you are still interested, can you try to run your test with a recent version of kind-on-c? |
hey @hoegaarden, thanks for getting back to me. yes, I have seen the btrfs fix, and tried it on runway. It appears to be failing for some other reason. good to know that it's very flaky on runway. |
I installed concourse and then used the example job in the readme. Seems like the kubelet is not running.
The text was updated successfully, but these errors were encountered: