An ECD Patch is meant to provide a flexible option to define and provision Kubernetes objects that suit your system architecture, or to tailor the ECD to their preferred flavor.
...
The ECD patch functionality enables you to add, change, and remove certain fields and functionality that might not be supported directly in the ECD specification, from the different Kubernetes objects created by the Operator through the ECD specification. The patch and patchType fields are part of the ECD CRD structure.
...
The ECD patch functionality can be used either from Desktop Online or directly in the ECD specification YAML.
...
Patch Format
The Patch comprises format consists of 2 fields - Patch and Patch Type; patch and patchType, embedded under different K8S objects. Patch The patch field is the payload itself, which will be used to patch into the ECD Kubernetes objects. Patch Type patchType is the field where users can define the patching strategies used to patch the payload.
Current Currently, the following objects that can be patched through ECD are:
ECD (Deployments and Pods)
Services
HPA/autoscaling
Ingress
Below is an example of the structure example under ECD (spec.patch and spec.patchType) :
| Code Block |
|---|
apiVersion: mz.digitalroute.com/v1alpha1
kind: ECDeployment
metadata:
name: anyECDeployment
namespace: anyNamespace
spec:
...
...
patchType: "application/merge-patch+json"
patch: |
...
... |
Below is an example of the structure example under HPA (spec.autoscale.patch and spec.autoscale.patchType):
| Code Block |
|---|
apiVersion: mz.digitalroute.com/v1alpha1
kind: ECDeployment
metadata:
...
spec:
autoscale:
...
...
patchType: "application/merge-patch+json"
patch: |
spec:
... |
Note!
There is a pipe “|” right after Patch, to indicate that the lines below
...
are multi-lines YAML
In Desktop Online you can find the corresponding patch for Services, HPA/autoscaling and Ingress (Ingress also being under networking) under their respective ECD sections:
Patching Strategies
There are 3 types of strategies supported by MZ Operator Patch feature:
...
As defined in RFC6902, a JSON Patch is a sequence of operations that are executed on the resource, e.g. {"op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ]}. For more details on how to use the JSON Patch, see the RFC.
Example The example below shows how to you annotate an Ingress resource , so that it could can be managed by Istio:
| Code Block |
|---|
apiVersion: mz.digitalroute.com/v1alpha1
kind: ECDeployment
metadata:
...
spec:
...
ingress:
patchType: "application/json-patch+json"
patch: |
- op: replace
path: /metadata/annotations/kubernetes.io~1ingress.class
value: istio |
...
As defined in RFC7386, a Merge Patch is essentially a partial representation of the resource. The submitted JSON is "merged" with the current resource to create a new one, then the new one is saved. For more details on how to use Merge Patch, see the RFC.
Example The example below shows how to you add a node selector to restrict this deployment (pod) to only run on nodes with a label where the disk type is SSD:
| Code Block |
|---|
apiVersion: mz.digitalroute.com/v1alpha1
kind: ECDeployment
metadata:
...
spec:
...
...
patchType: "application/merge-patch+json"
patch: |
spec:
template:
spec:
nodeSelector:
disktype: ssd |
...
Strategic Merge Patch is a custom implementation of Merge Patch for Kubernetes. For a detailed explanation of how it works and why it needed to be introduced, see API Conventions on Patch - Strategic Merge. In general, Strategic Merge Patch works better when it comes to merging Kubernetes objects in a list.
In this ECD Services, a port 9092 is already defined. Using Strategic Merge Patch, we you can add two more ports 9093 and 9094. On a side note, if we were If you want to change the type from a Strategic Merge Patch to a Merge Patch, the port 9092 would have been removed after patch.
...