Establish principles for running spring apps on k8s

[scothis]

DRAFT:

The Spring Framework defined it's design philosophy early on laying a foundation for success. Spring Boot builds on top of the Spring Framework by applying conventions and sensible defaults while preserving the flexibility and power Spring developers expect.

As Spring supports running applications on many platforms, more and more knowledge of the platform is being baked into the framework. While Spring practices Inversion of Control, this platform knowledge is inverting the inversion of control.

Now, we have the opportunity to apply the same principles to running apps on Kubernetes. Not by making Spring more Kubernetes aware, but by making Kubernetes Spring aware. The platform can configure itself with meaningful defaults to optimally run a Spring application, without the application being coupled to the platform. Following the Boot philosophy, we can bake in sensible defaults while exposing platform idioms to be overridden for developers who need an extra degree of control.

[nebhale]

One of the things I like to see focused on is what it means to make a choice that is different than one of these opinions. It must be possible to make minor choices without completely abandoning all of the rest of the value given by this project.

[scothis]

One of the things I like to see focused on is what it means to make a choice that is different than one of these opinions.

A pattern we've been using in riff is to include a PodTemplateSpec within our CRDs. This gives the user full access to define anything on the eventual Pod the same way they would on a Deployment. When the controller reconciles the resource, it merges the user provided PodTemplateSpec with the custom behavior that controller wants to inject before creating the downstream resource (e.g. Deployment).

While a PodTemplateSpec is by no means the most user friendly object, it will be immediately understood by anyone familiar with k8s, and will automatically pick up new k8s capabilities.

For example, if you wanted to set a custom environment variable that we wouldn't expose as a first class concept:

apiVersion: apps.mononoke.local/v1alpha1
kind: SpringBootApplication
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - env:
        # not approved by Josh Long
        name: SPRING_MAIN_BANNER-MODE
        value: off

[nebhale]

Love it! I'd also like to see how you might go about reverting an opinion. Say, to not use actuators for health, but rather the standard configuration.

[scothis]

I'd also like to see how you might go about reverting an opinion. Say, to not use actuators for health, but rather the standard configuration.

The probes are also defined within the PodTemplateSpec, so if you wanted to define a custom http probe:

apiVersion: apps.mononoke.local/v1alpha1
kind: SpringBootApplication
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            httpHeaders:
            - name: Custom-Header
              value: Awesome
          initialDelaySeconds: 3
          periodSeconds: 3