1

I am currently working with Kubernetes on Google Cloud with a microservice architecture. Where in a cluster I have different Pods and each of them can communicate with the others via curl using a ClusterIp.

My problem is that I need an endpoint of one of these pods to be called from time to time using the ClusterIp. For this I created a CronJob which curls the endpoint of the pod, but it always returns:

curl: (7) Failed to connect to xx.xx.xx.xx port 8080: Connection refused

This is the yaml of the cronJob.

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-test # name of the CronJob
spec:
  schedule: "*/1 * * * *" # run every minute
  concurrencyPolicy: Replace
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: cronjob-test
              image: appropriate/curl
              args:
              - /bin/sh
              - -c
              - curl -X POST http://${CLUSTER_IP}:${CLUSTER_PORT}/api/test/
          restartPolicy: Never
pdsm
  • 101
  • 2
  • 4
  • First of all, you shouldn't use ClusterIP for it, you suppose to use services. – FL3SH Aug 15 '19 at 16:14
  • Maybe include how your service and deployment looks like to determine if there's an issue there. Also, clarify if you're able to cURL other pods hitting the ClusterIP and if so, if you're cURLing them via IP address or FQDN. – yyyyahir Aug 16 '19 at 10:59
  • I can perform a curl among all pods successfully, using the ip address and port generated by the Service of type ClusterIp created. – pdsm Aug 16 '19 at 11:30
  • What are the CLUSTER_IP and CLUSTER_PORT (8080) values? Is it possible that CLUSTER_IP is the cluster IP of the CronJob's pod itself? In any case, unless fixed (https://kubernetes.io/docs/concepts/services-networking/service/#choosing-your-own-ip-address), Service-s cluster IPs change when the Service objects are recreated for some reason so using Service names is usually preferable. – apisim Aug 16 '19 at 20:15
  • It works if I put a delay (sleep 10) before de curl, why could this be happening – pdsm Aug 16 '19 at 22:13
  • It might have something to do with your image, have you tried switching it? Additionally, it might also be related to the container not being completely ready, you can try [adding probes to the pod spec](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) generated by the CronJob. – yyyyahir Aug 26 '19 at 11:23

3 Answers3

7

istio-proxy sidecar is VERY slow to start up in comparison to your workload, in which only alpine is included.

This will lead to problems when your workload is already sending out requests, whereas istio-proxy is not yet ready, or even not yet registered in Pilot. This is why it works if you sleep 10 before actually sending out the requests.

FizzyTidus
  • 127
  • 2
  • 10
0

In my opinion, dns-pod-service contains the solution what you need.

Here, you can find the FQDN for services if you want to use services. You can also find the FQDN name for pods (with/without headless service), if you use pods.

Shudipta Sharma
  • 5,178
  • 3
  • 19
  • 33
0

I met the same problem. After I disabled the istio sidecar injection by adding label istio-injection=disabled to the namespace. It all works fine.

user2536977
  • 1