Kubernetes cronJob to call REST API using CURL with headers is failing with curl(6) : could not resolve host

Question

How can I trigger the restAPI[POST with header having authentication and parameter] in cronJob using kubernetes. When I create the cron and try to run it I am getting the following error

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

When i replace the host with the actual rather than localhost it still gives me the error as

 curl: (6) Could not resolve host : xxxHostName

I am able to hit the curl using the command prompt as well as in the POSTMAN

Following is the cronJob which i am trying to run

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: e2em-rule-violation-job  
spec:
  schedule: "*/3 * * * *"
  concurrencyPolicy: Allow
  failedJobsHistoryLimit: 1
  successfulJobsHistoryLimit: 3
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: e2em-rule-violation-job 
            image: curlimages/curl:7.72.0
            args:
            - /bin/sh
            - -ec
            - "curl -H \"Authorization: Basic c3lzdGVtOm1hbmFnZQ==\" -H \"InternalUser: true\" -X POST  \"http://localhost:8080/myIntegration/rest/executeScheduledTask\""
          restartPolicy: OnFailure

Following is the dry run which is successful but Jobs fails when its created

W1006 13:35:34.443357   18304 helpers.go:535] --dry-run is deprecated and can be replaced with --dry-run=client.
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"batch/v1beta1","kind":"CronJob","metadata":{"annotations":{},"name":"e2em-rule-violation-job","namespace":"default"},"spec":{"concurrencyPolicy":"Allow","failedJobsHistoryLimit":1,"jobTemplate":{"spec":{"template":{"spec":{"containers":[{"args":["/bin/sh","-ec","curl -H \"Authorization: Basic c3lzdGVtOm1hbmFnZQ==\" -H \"InternalUser: true\" -X POST  \"http://localhost:8080/myIntegration/rest/executeScheduledTask\""],"image":"curlimages/curl:7.72.0","name":"e2em-rule-violation-job"}],"restartPolicy":"OnFailure"}}}},"schedule":"*/3 * * * *","successfulJobsHistoryLimit":3}}
  name: e2em-rule-violation-job
  namespace: default
spec:
  concurrencyPolicy: Allow
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - args:
            - /bin/sh
            - -ec
            - 'curl -H "Authorization: Basic c3lzdGVtOm1hbmFnZQ==" -H "InternalUser:
              true" -X POST  "http://localhost:8080/myIntegration/rest/executeScheduledTask"'
            image: curlimages/curl:7.72.0
            name: e2em-rule-violation-job
          restartPolicy: OnFailure
  schedule: '*/3 * * * *'
  successfulJobsHistoryLimit: 3

Answer 1

"curl -H \"Authorization: Basic c3lzdGVtOm1hbmFnZQ==\" -H \"InternalUser: true\" -X POST  \"http://localhost:8080/myIntegration/rest/executeScheduledTask\""

The problem in your case is in the above curl. Look, you are trying to curl non-existent address. Whats happening once you run cronjob?

1. k8s creates cronjob e2em-rule-violation-job
2. cronjob e2em-rule-violation-job CREATES POD
3. curl command is trying to run exactly inside from this POD

You POD doesnt know what the localhost:8080 is. You pod has absolutelly another localcost comparing to where your app is running...This address is not exposed, you pod cant have access to it. Plus image: curlimages/curl:7.72.0 dockerfile doesnt have port 8080 exposed..

What you can do for test is to

1. create normal deployment with the curl pod, lets say NEWCURLPOD
2. connect to NEWCURLPOD and execute your initial command you wanted to run. Example: kubectl exec -ti {NEWCURLPOD} -n {PROPER_NAMESPACE} -- curl blablabla

If that will not work - check dns. If your app is running inside the same cluster - you should properly expose its service to reach the target, but for sure this is not localhost:8080

Dry run..

Following is the dry run which is successful but Jobs fails when its created

While running dry-run - it only check and preview the object, it should not execute curl there - as a result you see it completes successfully.