<p>As far as I understand kubernetes services, that trick is not possible.</p>

<p>What could help you to have preserved hostnames is a StatefulSet.
<a href="https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/" rel="nofollow noreferrer">See more here</a></p>

<blockquote>
  <p>The Pods’ ordinals, hostnames, SRV records, and A record names have
  not changed, but the IP addresses associated with the Pods may have
  changed. In the cluster used for this tutorial, they have. This is why
  it is important not to configure other applications to connect to Pods
  in a StatefulSet by IP address.</p>
</blockquote>

CC BY-SA 4.0
2019-08-19T21:17:50.247Z
Thanks! I ended up with StatefulSet with replicas and a multiple services looking for the predictable pod name of each replica: myapp-0, myapp-1, myapp-2, etc
Daniel
CC BY-SA 4.0
2019-08-16T10:54:34.053Z
2019-08-16T10:54:34.053Z
profesor79
<p>If the pods (quote) "...should not be load balanced", each pod is to be accessed on different NodePort ports, the order of starting them up doesn't matter...you can:</p>

<ul>
<li>Create 5 identical Deployment-s, say, myapp-1 thru myapp-5, with 1 replica each.</li>
<li>Create a Service for each Deployment making sure the selector is correct for each myapp-1 thru myapp-5 Deployment-s. Configure each Service with the concrete nodePort-s for ssh and telnet as you wish.</li>
</ul>

<p>It is to note that this way each pod will be independent of the rest and pods cannot be scaled by simply adding a replica. Still, if configured, the pods will be rescheduled and restarted in case of pod or node failure.</p>

CC BY-SA 4.0
2019-08-16T18:09:26.503Z
2019-08-16T18:09:26.503Z
apisim
<p>I have a Deployment with 5 replicas. All have ssh and telnet. They should not be load balanced. I would like each to select from a predictable list of 5.</p>

<p>Here is my Deployment</p>

<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  replicas: 5
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        ports:
        - name: ssh
          protocol: TCP
          containerPort: 22
        - name: telnet
          protocol: TCP
          containerPort: 23
</code></pre>

<p>This is my Service with invalid nodePort values for illustrative purposes.</p>

<pre><code>apiVersion: v1
kind: Service
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  type: NodePort
  ports:
  - name: ssh
    port: 22
    nodePort: [30022, 30122, 30222, 30322, 30422, 30522]
  - name: telnet
    port: 23
    nodePort: [30023, 30123, 30223, 30323, 30423, 30523]
</code></pre>

<p>I am hoping to be able to accomplish 2 things:</p>

<ol>
<li>Each pod replica instance will only get an ssh port from [30022, 30122, 30222, 30322, 30422, 30522] and a telnet port from [30023, 30123, 30223, 30323, 30423, 30523]</li>
<li>A pod replica instance that gets an ssh port of 30022 also gets the telnet port 30023. A pod replica instance that gets an ssh port of 30122 gets a telnet port of 30123 and so on.</li>
</ol>

<p>Thank you!</p>

<kubernetes>
How do I get more control over the NodePorts my Service assigns to my Deployment?
Daniel
# How do I get more control over the NodePorts my Service assigns to my Deployment?

(Asked by: username_0 on 2019-08-15)

I have a Deployment with 5 replicas. All have ssh and telnet. They should not be load balanced. I would like each to select from a predictable list of 5.
Here is my Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  replicas: 5
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        ports:
        - name: ssh
          protocol: TCP
          containerPort: 22
        - name: telnet
          protocol: TCP
          containerPort: 23

This is my Service with invalid nodePort values for illustrative purposes.
apiVersion: v1
kind: Service
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  type: NodePort
  ports:
  - name: ssh
    port: 22
    nodePort: [30022, 30122, 30222, 30322, 30422, 30522]
  - name: telnet
    port: 23
    nodePort: [30023, 30123, 30223, 30323, 30423, 30523]

I am hoping to be able to accomplish 2 things:

Each pod replica instance will only get an ssh port from [30022, 30122, 30222, 30322, 30422, 30522] and a telnet port from [30023, 30123, 30223, 30323, 30423, 30523]
A pod replica instance that gets an ssh port of 30022 also gets the telnet port 30023. A pod replica instance that gets an ssh port of 30122 gets a telnet port of 30123 and so on.

Thank you!

**Tags:** kubernetes


---

## 2 answers

### Answer by username_1 on 2019-08-16. Score: 1 | Accepted answer

As far as I understand kubernetes services, that trick is not possible.

What could help you to have preserved hostnames is a StatefulSet.
[See more here](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/)

> The Pods’ ordinals, hostnames, SRV records, and A record names have
> not changed, but the IP addresses associated with the Pods may have
> changed. In the cluster used for this tutorial, they have. This is why
> it is important not to configure other applications to connect to Pods
> in a StatefulSet by IP address.

> **Comments:**
> **username_0**: Thanks! I ended up with StatefulSet with replicas and a multiple services looking for the predictable pod name of each replica: myapp-0, myapp-1, myapp-2, etc  

---

### Answer by username_2 on 2019-08-16. Score: 0

If the pods (quote) "...should not be load balanced", each pod is to be accessed on different NodePort ports, the order of starting them up doesn't matter...you can:

* Create 5 identical Deployment-s, say, myapp-1 thru myapp-5, with 1 replica each.
* Create a Service for each Deployment making sure the selector is correct for each myapp-1 thru myapp-5 Deployment-s. Configure each Service with the concrete nodePort-s for ssh and telnet as you wish.

It is to note that this way each pod will be independent of the rest and pods cannot be scaled by simply adding a replica. Still, if configured, the pods will be rescheduled and restarted in case of pod or node failure.


---

