<p>I want to expose 2 ports on one service:</p>

<pre><code>apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: etools
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: etools
    spec:
      containers:
      - name: etools
        image: eregistry.azurecr.io/etools:latest
        ports:
        - containerPort: 8080
        - containerPort: 3100
---
apiVersion: v1
kind: Service
metadata:
  name: etools
spec:
  ports:
  - port: 8080
  selector:
    app: etools
  ports:
  - port: 3100
  selector:
    app: etools
</code></pre>

<p>How can I achieve it?</p>

<p>Your <code>Service</code> is very close, but in the <a href="https://kubernetes.io/docs/api-reference/v1.8/#serviceport-v1-core" rel="nofollow noreferrer">ports:</a> array, the ports need to be named if there is more than one (they ideally would always have names), and the <code>selector:</code> is just once per <code>Service</code>, not per-port:</p>

<pre><code>spec:
  selector:
    app: etools
  ports:
  - name: web
    port: 8080
    targetPort: 8080
  - name: other-port-something
    port: 3100
    targetPort: 3100
</code></pre>

<p>Be aware that while you will often see <code>port:</code> and <code>targetPort:</code> equal to the same number, they don't have to be. So your container could listen on 8080, because docker image says it will, but your <code>Service</code> could expose that to other members of your cluster as <code>port: 80</code> to be closer to what one would expect.</p>

<p>It's also possible to name the ports in your <code>PodSpec</code> with natural language names, and then point the <code>Service</code> at <em>that</em> value:</p>

<pre><code>ports:
- name: http
  port: 80
  targetPort: http-in-my-pod
</code></pre>

<p>which I recommend because it decouples your <code>Service</code> from having to change just because the <code>containerPort</code> changed in your <code>PodSpec</code>, but at your discretion.</p>

<p>I'm a little surprised that <code>kubectl</code> didn't offer helpful feedback when you provided it that malformed yaml, but either way, I believe the snippet above is correct. As the docs specify, the names must be both unique within the Service, and also "DNS-compatible" names, so no underscores, spaces, crazy characters</p>
