Thoughts on refactoring Services in the spec

[concaf]

Okay, so this is the data that the ServiceSpec in Kubernetes contains -

• Name
• Ports
• Selector
• ClusterIP
• Type - one of ExternalName, ClusterIP, NodePort, and LoadBalancer
• ExternalIPs
• SessionAffinity
• LoadBalancerIP
• LoadBalancerSourceRanges
• ExternalName

Now, I understand that a service will be applied to the pods with the given selector, and yes, this needs to be defined outside containers:, so I think that the service spec should be defined at the root level.

• We get rid of Selector, because well, we are defining the service with a given pod, so the selected happens to be that automatically.
• We get rid of Name because we don't need it anywhere, and we can name it ourselves, like we used to do with containers in OpenCompose.
• Rename Type to something more generic like ExposeType or AccessPolicy or AccessType, or something better than this which can be understood without the context of Kubernetes.

An example file would look like -

name: web
replicas: 1
containers:
- image: wordpress:4
  env:
  - name: WORDPRESS_DB_PASSWORD
    value: wordpress
  - name: WORDPRESS_DB_USER
    value: wordpress
accessType: NodePort
ports:
- port: 8080
  targetPort: 80

[kadel]

we can't rename anything, it has to be still possible to use the kubernetes way. You still have to be able to write full ServiceSpec if you want (you=creator of application)

[kadel]

The first think we should figure out is where we will put ServiceSpec. Top level, or somewhere in PodSpec?

[concaf]

@kadel what do you mean by top level, here? The top level is the PodSpec right now, and a more things.

IMO, if we do not want to rename the fields in the ServiceSpec, then we should merge it with the PodSpec, like -

type App struct {
        ...
        ...
	api_v1.PodSpec
       	api_v1.ServiceSpec
}

[kadel]

yes by top level I meant in PodSpec, not embedded but as it is right now. By somewhere in PodSpec I meant somewhere deeper (like port level in container)

I don't think that merging PodSpec and ServiceSpac is good way to go.

[concaf]

yes by top level I meant in PodSpec, not embedded but as it is right now. By somewhere in PodSpec I meant somewhere deeper (like port level in container)

If we put this somewhere with ports with containers, then that means that we are defining services on a per container level, which means that if container 1 says that it needs to have a NodePort, then container 2 also gets a NodePort, but when we will look at the spec, this will not be the case, because NodePort will be mentioned in only container 1.
This brings inconsistency.

I don't think that merging PodSpec and ServiceSpac is good way to go.

Why? A Service is applied at the Pod level, what looks wrong with merging 2 concepts that apply to the same level?

[kadel]

Why? A Service is applied at the Pod level, what looks wrong with merging 2 concepts that apply to the same level?

It looks logically inconsistent. It will be much more cleaner and clearer to have it in seperate level.

And more importantly how would you create multiple services if you merge podspec with servicespec?

[concaf]

And more importantly how would you create multiple services if you merge podspec with servicespec?

Whoops, yep, makes sense.

[concaf]

For now, let's keep it like the way it is