0

** disclaimer: I am very shallow in infra topic, but hope my explanation of the case is understandable. Sorry for a possible inaccuracy in terminology.

I have an application working in k8s which is represented by a pod (Pod#1) with a single container (main-container). Also there is k8s-service created inside that pod. In the “main-container” there is working app and a working service (not k8s-service) on localhost:8082 (yellow block on the picture).

During the run time, the app from Pod#1 “main-container” creates k8s-job which is represented by another pod (Pod#2) with another container (job-container).

Here the problem: Pod#2 job-container has a need to communicate with a working service (not k8s-service) which is running in main-container (on port 8082).

I know that this communication can be established through the service (like ServiceName:Port).

But are there any other options to establish this connection? Is it possible for main-container and job-container have a single option for communication with service (like https://localhost:8082 which won't definitely work for job-container)

enter image description here

Petukhou Mikita
  • 49
  • 6
  • how about putting both maincontroller & job-container in single pod so that they can communicate on localhost interface ? – confused genius Nov 19 '21 at 15:28
  • @confusedgenius, Pod#2 with job-container is created as a k8s-job. By the definition k8s-job is a separate Pod to do a defined task and after the completion it should be destroyed. So it is designed here in my case. Unfortunately currently it doesn't look like an option – Petukhou Mikita Nov 19 '21 at 15:52
  • then headless service might be an option (it will not work like localhost), where you can directly access the podip:port. https://kubernetes.io/docs/concepts/services-networking/service/#headless-services – confused genius Nov 19 '21 at 16:57
  • 1
    Even main container can call itself using `serviceName:local-service-port` right? So you can use the same `serviceName:local-service-port` from both main-container and job-container? Having said that, better to use usual kubernetes communication patterns and not workaround it. Eventually it will be easier to monitor traffic using standard tools if you do it standard way. Good Luck! – Narain Nov 19 '21 at 17:40
  • 1
    You can also pass the `http://service-name.namespace-name:port` location in a ConfigMap, an environment variable, or a command-line parameter to the Job. It doesn't need to be a fixed location. Calls between Pods almost always pass through (Kubernetes) Services and that's not usually a problem. – David Maze Nov 20 '21 at 12:10
  • @Narain, Thank you for the proposal! Yes, looks like something that I am looking for (single way of connection that I can use from both pods). Am I right, that if we do it from the main-container “call itself using serviceName:local-service-port” there could be some kind of round-trip? Could such approach cause any consequences or bad effects? – Petukhou Mikita Nov 20 '21 at 13:26
  • @DavidMaze, Thank you for the idea. it seems to me that it is kind of the same approach as Narin's. Could you please share also your thoughts on my question above regarding the round-trip? – Petukhou Mikita Nov 20 '21 at 13:27
  • 1
    A Pod calling itself through a Service will be slower than a direct function call, and it might reach one of the other replicas of the same Deployment, but there's otherwise not anything technically wrong with it. – David Maze Nov 20 '21 at 14:05
  • @petukho Overhead is in process communication VS ip routing, most dangerous will be infinite loop, based on how you want to use it. By the way I am still not sure why you want to call them in exact way, why not use them as they are supposed to be. – Narain Nov 20 '21 at 16:39
  • @Narain, This working service in the main-container is responsible for creating a data pipeline. Both app in the main-container and the app in job are using this service. I wanted to have a single connection-configuration file which is configured before the deployment and mounted into both main-container and job-container (simple way ) and used during their run. But I am still not sure if it is a good idea because of all these workarounds. – Petukhou Mikita Nov 20 '21 at 17:27
  • Hello @PetukhouMikita, any updates here? Have you tried both of the above ideas? – kkopczak Nov 22 '21 at 12:59
  • Hi @ PetukhouMikita, I would suggest to keep configuration different, as these are different containers. Eventually in future you will want to evolve them separately, so pls dont hard couple them – Narain Nov 23 '21 at 12:29

2 Answers2

0

...communication can be established through the service (like ServiceName:Port). But are there any other options to establish this connection?

You can use Statefulset to create the "main-container" pod where spawned (eg. job) pods can resolved the "main-container" pod name thru pod DNS and connect back. Here's a quick example:

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx
spec:
  serviceName: nginx
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx  # Presume this is the container that expose 8082 in your diagram
        image: nginx:alpine
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80
EOF

Presume your "main-container" create job:

cat << EOF | kubectl apply -f -
apiVersion: batch/v1
kind: Job
metadata:
  name: nginx
spec:
  template:
    metadata:
      name: nginx
    spec:
      restartPolicy: Never
      containers:
      - name: nginx
        image: busybox
        imagePullPolicy: IfNotPresent
        command:  # Simulate the line from Pod#2 to Pod#1 in your diagram
        - wget
        - -qO-
        - nginx-0.nginx

 EOF

The job can always reach the nginx pod (not the service) using the DNS name nginx-0.nginx. Check with kubectl logs <job pod>.

gohm'c
  • 13,492
  • 1
  • 9
  • 16
0

Relaying on the discussion in comments I have established the communication via Service by replacing localhost:port call to service-name:call in job-container. Thank you all!

Petukhou Mikita
  • 49
  • 6