<p>First of all, I'd like to say that I'm new to Kubernetes, so forgive me if what I want to do is a bad idea :)</p>
<p>Here's my context :
I've got a very large application which is composed of lots of micro-services according to their domains :</p>
<pre><code>Domain 1
    domain1-microservice1-app expose port 8080
    domain1-microservice2-app expose port 8081
    domain1-microservice3-app expose port 8082

Domain 2
    domain2-microservice1-app expose port 9080
    domain2-microservice2-app expose port 9081
    domain2-microservice3-app expose port 9082

Domain 3
    domain3-microservice1-app expose port 9180
    domain3-microservice2-app expose port 9181
    domain3-microservice3-app expose port 9182
</code></pre>
<p>... and so on.</p>
<p>So, in my example, I have 9 applications. Each application is registered in Kubernetes using <strong>kind:Deployment</strong></p>
<h2>Now I want to choose the best way to manage services.</h2>
<h3>First solution</h3>
<p>Each deployment has its own service</p>
<p>=&gt; It works, it seems to be the classical way of doing things in Kubernetes. But in reality, I have far more than 9 applications, so I have lots of services</p>
<h3>Second solution</h3>
<p>Create a service by domain. Each service contains all its related apps</p>
<p>=&gt; I've tried it and it seems to work (as far as I could test in my local dev environment)</p>
<p>I'd like to know what do you think of my second solution, and what may be its caveat?</p>
<p>I also take all your advice on what could be the best Kubernetes structure.</p>
<p>Thanks a lot,</p>
<p>Julien</p>
<h1>Edit: add sample configuration files for approach 2</h1>
<p>Deployment file for microservice1 of domain1 :</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
    name: domain1-app1
    labels: 
        domain: domain1  
spec:
    selector:
        matchLabels:
            app: domain1-app1
    replicas: 3
    template:
        metadata:
            labels:
                app: domain1-app1
                domain: domain1
        spec:
            containers:
                - name: XXX
                image: YYY
                ports:
                - containerPort: 8080
</code></pre>
<p>Service file for service related to domain 1 :</p>
<pre><code>kind: Service
apiVersion: v1
metadata:
    name: domain1-service
spec:
    type: LoadBalancer
    selector:
        domain: domain1
    ports:
        - name: port8080
        protocol: TCP
        port: 8080
        targetPort: 8080
        - name: port8081
        protocol: TCP
        port: 8081
        targetPort: 8081
        - name: port8082
        protocol: TCP
        port: 8082
        targetPort: 8082
</code></pre>

<p>It's subjective.</p>

<p>I would go with Approach 1 to keep the Service specifications simple. It will also be possible to have different Pods for different Services. With the Approach 2, the same set of Pods (based on the selector) should provide all the Services for a particular domain. It would be not possible to scale the Pods based on the Services.</p>

<p>Domain is more like metadata and not much with the functionality of the service. So, I would remove domain from service name and start using <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/" rel="nofollow noreferrer">labels</a> for it. This will allow to apply Selectors on Labels.</p>
