Unlike Docker, Kubernetes requires specifying the port in the yaml, and the entire corpus of documentation has not been updated to reflect this. First, make sure you include the port (example below). Second, for whatever reason, we are seeing variation in behavior across Kubernetes offerings (Digital Ocean vs EKS vs GKE vs Minikube). I am unable to reproduce any issues with services on Digital Ocean or Minikube.
It is possible you are experiencing cluster-specific issues. We are unable to test every different provider for conformance, so we generally ask community members to get their hands dirty when triaging these sort of issues, and report their findings back to us. We do provide a guide to assist with debugging. See http://discuss.harness.io/t/contributing-to-drone-for-kubernetes/3159
It is also possible that it takes Kubernetes more than 5 seconds to schedule and start the container, and for Redis to begin accepting connections. All of our existing documentation is optimized for Docker and may need to be tweaked for Kubernetes. The Kubernetes scheduler is significantly slower and, because of scheduling differences, you may also need to account for image download times. So try adding more time to the sleep operation as well.
kind: pipeline
name: default
steps:
- name: test
image: redis
commands:
- sleep 5
- redis-cli -h $REDIS_SERVICE_HOST ping
- redis-cli -h redis ping
services:
- name: redis
image: redis
ports:
- 6379
Note that the above example uses REDIS_SERVICE_HOST
, however, in my testing I am able to use the hostname as expected.
on the chance that the services are running in the same pod as the other steps, I tried localhost, which didn’t work either. Were are the services running
Each service is run in its own pod, with a Service resource also created.
have you thought about using the HEALTHCHECK in docker images to test if a service is ready
There is an open issue for exploring the use of healthcheck, see GitHub · Where software is built. This feature was considered more of a nice-to-have for our Docker implementation, since our Docker scheduler was very predictable and Drone had a lot of control over the scheduling process. Drone has limited control over the Kubernetes schedule, which also appears to be a bit less predictable, and may therefore benefit from such a feature.