score-spec / schema Goto Github PK

It looks like CronJob is not supported kind.
Any plans to add it?

Detailed description

It would be ideal to support the command, tcpSocket and grpc methods for livenessProbe and readinessProbe.

Context

Today, only the httpGet method for livenessProbe and readinessProbe is supported.

command is another very popular method, like illustrated here with grpc apps: https://github.com/GoogleCloudPlatform/microservices-demo/blob/main/release/kubernetes-manifests.yaml#L61.

So for example, today, this below is not supported:

apiVersion: score.dev/v1b1
metadata:
  name: adservice
containers:
  adservice:
    image: gcr.io/google-samples/microservices-demo/adservice:v0.6.0
    variables:
      PORT: "9555"
    livenessProbe:
      exec:
        command:
          - /bin/grpc_health_probe
          - '-addr=:9555'
    readinessProbe:
      exec:
        command:
          - /bin/grpc_health_probe
          - '-addr=:9555'

Possible implementation

Humanitec already supports tcpSocket and command in addition to httpGet.

Note: gRPC (only supported since Kubernetes 1.24+) is not yet supported in Humanitec. The alternative is to use the command method by using the grpc_health_probe binary.

Additional information

Configure Liveness, Readiness and Startup Probes in Kubernetes.

All implementations of score Service assume the port is required, and will default the targetPort if not provided. This is the same as both Humanitec and the underlying K8s implementation. Score-compose and score-humanitec do the same.

The score documentation also lists port as required and target port as optional.

However the spec lists this the other way around. To avoid breaking customers that have workloads defined with just port right now, we need to fix this in the spec.

Just like resources have metadata.annotations today, there is need to support the same concept formally on the workload metadata as well. This will allow us to pass kubernetes-style annotations through to the destination runtime.

For score-compose, these would be labels, while for score-helm and score-humanitec these would be annotations on the final deployment objects. Since this is just metadata it can also be ignored without affecting the functionality of the workload.

metadata:
  name: my workload
  annotations:
    example.com/my-annotation: value

This should carry the same specification as resource.metadata.annotations.

The score website indicates

However the API spec does not support these fields.

"ports": {
  "description": "List of network ports published by the service.",
  "type": "object",
  "minProperties": 1,
  "additionalProperties": {
    "description": "The network port description.",
    "type": "object",
    "required": [
      "targetPort"
    ],
    "additionalProperties": false,
    "properties": {
      "port": {
        "description": "The public service port.",
        "type": "number"
      },
      <--- missing --->
      "targetPort": {
        "description": "The internal service port.",
        "type": "number"
      }
    }
  }
}

This means validators may reject these fields if provided, and implementation behavior or failure may be unpredictable. However hostIP is also not a real field used by any score implementations just yet so that should be removed.

I'd like to propose we fix this by adding protocol to the spec, and removing hostIP from the docs.

There are a number of locations in the schema where 'number' is used rather than 'integer' in the port bindings:

• service.ports.port
• service.ports.targetPort
• $defs.httpProbe.port

This usually doesn't show up as a problem but it might when validation allows port numbers like 33.3333 to pass validation, but may cause failures when converted into docker compose, helm, or other destination container types.

I'd like to propose that we change these to integers!