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.
...
Note!
An ECD Patch is NOT the same as using the kubectl patch
command. Although they are conceptually similar, they do not necessarily behave in the same way.
Introduction
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.
...
In Desktop Online you can find the corresponding patch for ECD (deployment and pods), 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 the ECD Patch feature:
JSON Patch (RFC6902)
Merge Patch (RFC7386)
Strategic Merge Patch (Kubernetes custom implementation of Merge Patch)
...
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 |
Merge Patch
...
Changing an item in a list
In order to change an item in a list you can do this conveniently with JSON Patch. In the example below we change the service port from 1234 to 1235. The zero in the path (/spec/ports/0/port) specifies that the first item in the list should be changed.
...
Merge Patch
As defined in RFC7386, a Merge Patch is 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.
...
Strategic Merge Patch is a custom implementation of Merge Patch for Kubernetes. For a detailed explanation of how it works and why it needed had to be introduced, see API Conventions on Patch - Strategic Merge. In general, Strategic Merge Patch works better when merging Kubernetes objects in a list.
In this ECD Services, port 9092 is already defined. Using Strategic Merge Patch, you can add two more ports 9093 and 9094. If you want were to change the type from a Strategic Merge Patch to a Merge Patch in this case, port 9092 would have been removed after the patch.
Code Block |
---|
services: - spec: type: ClusterIP ports: - port: 9092 protocol: TCP targetPort: 9092 ... ... patchType: "application/strategic-merge-patch+json" patch: | spec: ports: - name: "port-1" port: 9093 protocol: TCP targetPort: 9093 - name: "port-2" port: 9094 protocol: UDP targetPort: 9094 ... |
Samples
Below are samples that can help users getting started with ECD patch. Do note that “Before” is based on the ECD - Here is an example changing multiple (sub-)paths in the same deployment/pod patch (also using Strategic Merge Patch):
Code Block |
---|
patchType: "application/strategic-merge-patch+json"
patch: |
spec:
template:
spec:
hostAliases:
- ip: 34.88.208.176
hostnames:
- "client"
- "client-simulator"
- ip: 35.228.46.60
hostnames:
- "proxy"
- "proxy2"
containers:
- name: ec1
resources:
limits:
memory: 1536Mi
requests:
memory: 1024Mi |
Samples
Below are samples that can help you get started with an ECD patch. The “Before” section is based on the ECD, which is the definition file for the desired state. while the “After” section is based on the conversion and logic processing done by Operator - which is the actual objects provisioning yaml to be applied to the cluster. As you might noticecan see, there are a lot more several objects that will be provisioned and handled by the Operator itself.
Changing Rollout Strategy
Basically, Creating an ECD will result in creating the creation of different Kubernetes objects, where one of them is a Deployment object. The rollout strategy defaults to RollingUpdate, but through an ECD patch we can change it to another strategy such as Recreate. The change can be seen on the spec.strategy.typein the Deployment object After ECD Patch.
Before ECD Patch | After ECD Patch | ||||
---|---|---|---|---|---|
|
|
Setting Toleration
In the example below, assuming with a 3 nodes node implementation of a Kubernetes cluster, 2 nodes are tainted color=blue and 1 node is tainted color=red, the . The test is to add toleration to ECD so that it will get deployed into node tainted with color=red.
Code Block |
---|
$ kkubectl taint nodes kl-kube-node01.digitalroute.com kl-kube-node02.digitalroute.com color=blue:NoSchedule node/kl-kube-node01.digitalroute.com tainted node/kl-kube-node02.digitalroute.com tainted $kubectl k taint nodes kl-kube-node03.digitalroute.com color=red:NoSchedule node/kl-kube-node03.digitalroute.com tainted |
Observe how toleration is being added and it gets scheduled to the node tainted with color=red.
Before ECD Patch | After ECD Patch | ||||||
---|---|---|---|---|---|---|---|
|
|
Setting Environment Variable
There might be a case where you would like to You can also add in an environment environmental variable. In the example below, we will add one calls ENV where the environmental variable ENV is added with the value will be “dev”.
Before ECD Patch | After ECD Patch | ||||||
---|---|---|---|---|---|---|---|
|
|
Removing an Object
We may You can also use this functionality to remove a provisioned Kubernetes object. We can use In the example below, the directive marker ($patch: delete) is used to remove a volume and volumeMount.
Before ECD Patch | After ECD Patch | ||||
---|---|---|---|---|---|
|
|