Skip to content

Containers scheduling

The kubernetes-config.yaml script is a manifest that describes how the workload container(s) should be scheduled (to the machine cluster described by cluster-config.yaml.) This is the standard Kubernetes script.

Templating possibilities

You can choose to write kubernetes-config.yaml in any of the following formats: - kubernetes-config.yaml: For simple workloads, you can directly write the Kubernetes deployment scripts.
- kubernetes-config.yaml.m4: Use the .m4 template to add conditional statements in the Kuberentes deployment scripts.
- kuberentes-config.yaml.j2: Use the .j2 template to add conditional statements in the Kubernetes deployment scripts.
- helm charts: For complex deployment scripts, you can use any helm charts under the helm directory.

Image Name

The container image in kubernetes-config.yaml should use the full name in the format of <REGISTRY><image-name><IMAGESUFFIX><RELEASE>, where <REGISTRY> is the docker registry URL (if any), <IMAGESUFFIX> is the platform suffix, and the <RELEASE> is the release version, (or :latest if not defined.)

If you use the .m4 template, the IMAGENAME macro can expand an image name to include the registry and release information:

include(config.m4)
...
spec:
...
    spec:
      containers:
      - name: database
        image: IMAGENAME(wordpress5mt-defn(`DATABASE'))
...

If you use the .j2 template or helm charts, you must write the image name as follows:

...
spec:
...
    spec:
      containers:
      - name: database
        image: "{{ REGISTRY }}wordpress5mt-{{ DATABASE }}{{ IMAGESUFFIX }}{{ RELEASE }}"
...

About imagePullPolicy

To ensure that the validation runs always on the latest code, it is recommended to use imagePullPolicy: Always.

Not all docker images are built equally. Some are less frequently updated and less sensitive to performance. Thus it is preferrable to use imagePullPolicy: IfNotPresent.

About podAntiAffinity

To spread the pods onto different nodes, use podAntiAffinity as follows: 

...
    metadata:
      labels:
        app: foo
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - foo
              topologyKey: "kubernetes.io/hostname"
...

If you use the .m4 template, you can use the PODANTIAFFINITY macro:

...
    metadata:
      labels:
        app: foo
    spec:
       PODANTIAFFINITY(preferred,app,foo)
...

If you use the .j2 template or helm charts, there is no convenient function for above. You have to write the podAntiAffinity terms in explicit.

See Also