You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The dictionary files can be uploaded after the chart installation, but the `dictionaries.localPath`
100
-
folder has to exist on the node beforehand.
101
-
Dictionaries can be uploaded to the node VM either the usual way (`scp`, `rsync`, `FTP` etc), or
102
-
using`kubectl cp` command. With `kubectl cp` we have to use one of pods of the deployment.
103
-
Once the files are uploaded, they will appear on all the pods automatically, and will persist
104
-
if any or all the pods are restarted. The workflow for this would look something like this:
105
-
1. Get the name of one of the pods. For the Helm release named `wsc-app-5-25-0` installed in the `wsc` namespace, we can use
103
+
folder must exist on the node beforehand.
104
+
Dictionaries can be uploaded to the node VM using standard methods (`scp`, `rsync`, `FTP` etc) or
105
+
the`kubectl cp` command. With `kubectl cp`, you need to use one of the deployment's pods.
106
+
Once uploaded, the files will automatically appear on all pods and persist
107
+
even if the pods are restarted. Follow these steps:
108
+
1. Get the name of one of the pods. For the Helm release named `wproofreader-app`in the `wsc` namespace, use
106
109
```shell
107
-
POD=$(kubectl get pods -n wsc -l app.kubernetes.io/instance=wsc-app-5-25-0 -o jsonpath="{.items[0].metadata.name}")
110
+
POD=$(kubectl get pods -n wsc -l app.kubernetes.io/instance=wproofreader-app -o jsonpath="{.items[0].metadata.name}")
108
111
```
109
112
2. Upload the files to the pod
110
113
```shell
111
114
kubectl cp -n wsc <local path to files>$POD:/dictionaries
112
115
```
113
-
where`/dictionaries`should be changed to whatever non-default `dictionaries.mountPath` value was used if applicable.
116
+
Replace`/dictionaries`with your custom `dictionaries.mountPath` value if applicable.
114
117
118
+
There is also a way in the Chart to specify an already existing Persistent Volume Claim (PVC) with dictionaries that can be configured to operate on multiple nodes (e.g., NFS). To do this, enable the custom dictionary feature by setting the `dictionaries.enabled` parameter to `true` and specifying the name of the existing PVC in the `dictionaries.existingClaim` parameter.
119
+
120
+
**Recommended approach:** Using an existing PVC is the recommended way because it ensures that your data will persist even if the Chart is uninstalled. This approach offers a reliable method to maintain data integrity and availability across deployments.
121
+
122
+
However, please note that provisioning the Persistent Volume (PV) and PVC for storage backends like NFS is outside the scope of this Chart. You will need to provision the PV and PVC separately according to your storage backend's documentation before using the `dictionaries.existingClaim` parameter.
123
+
124
+
## Use in production
125
+
126
+
For production deployments, it is highly recommended **to specify resource requests and limits for your Kubernetes pods**. This helps ensure that your applications have the necessary resources to run efficiently while preventing them from consuming excessive resources on the cluster which can impact other applications.
127
+
This can be configured in the `values.yaml` file under the `resources` section.
128
+
129
+
### Recommended resource requests and limits
130
+
131
+
Below are the recommended resource requests and limits for deploying WProofreader Server v5.34.x with enabled English dialects (en_US, en_GB, en_CA, and en_AU) for spelling & grammar check using the English AI language model for enhanced and more accurate proofreading. It also includes such features as a style guide, spelling autocorrect, named-entity recognition (NER), and text autocomplete suggestions (text prediction). These values represent the minimum requirements for running WProofreader Server in a production environment.
132
+
133
+
**Note:** Depending on your specific needs and usage patterns, especially when deploying AI language models for enhanced proofreading in other languages, you may need to adjust these values to ensure optimal performance and resource utilization. Alternatively, you can choose the bare-minimum configuration without AI language models. In this case, only algorithmic engines will be used to provide basic spelling and grammar checks.
134
+
135
+
```yaml
136
+
resources:
137
+
requests:
138
+
memory: "4Gi"
139
+
cpu: "1"
140
+
limits:
141
+
memory: "8Gi"
142
+
cpu: "4"
143
+
```
144
+
145
+
### Readiness and liveness probes
146
+
147
+
The Helm chart includes readiness and liveness probes to help Kubernetes manage the lifecycle of the WProofreader Server pods. These probes are used to determine when the pod is ready to accept traffic and when it should be restarted if it becomes unresponsive.
148
+
149
+
You may thoughtfully modify the Chart default values based on your environment's resources and application needs in the `values.yaml` file under the `readinessProbeOptions` and `livenessProbeOptions` sections.
150
+
Example:
151
+
```yaml
152
+
readinessProbeOptions:
153
+
initialDelaySeconds: 10
154
+
periodSeconds: 10
155
+
timeoutSeconds: 5
156
+
successThreshold: 1
157
+
failureThreshold: 3
158
+
```
159
+
160
+
### Application scaling
161
+
WProofreader Server can be scaled horizontally by changing the number of replicas.
162
+
This can be done by setting the `replicaCount` parameter in the `values.yaml` file.
163
+
The default value is `1`. For example, to scale the application to 3 replicas, set the `--set replicaCount=3` flag when installing the Helm chart.
164
+
165
+
For dynamic scaling based on resource utilization, you can use Kubernetes Horizontal Pod Autoscaler (HPA).
166
+
To use the HPA, you need to turn on the metrics server in your Kubernetes cluster. The HPA will then automatically change the number of pods in a deployment based on how much CPU is being used.
167
+
The HPA is not enabled by default in the Helm chart. To enable it, set the `autoscaling.enabled` parameter to `true` in the `values.yaml` file.
168
+
169
+
**Important Note:** WProofreader Server can be scaled only based on CPU usage metric. The `targetMemoryUtilizationPercentage` is not supported.
170
+
115
171
## Common issues
116
172
### Readiness probe failed
117
173
@@ -141,7 +197,7 @@ Otherwise, they are overwritten with the contents of `values.yaml`.
141
197
For illustration purposes, please find exported Kubernetes manifests in the `manifests` folder.
142
198
If you need to export the manifest files from this sample Helm Chart, please use the following command:
The service might fail to start up properly if misconfigured. For troubleshooting, it can be beneficial to get the full configuration you attempted to deploy. If needed, later it can be shared with the support team for further investigation.
156
212
157
-
There are several options for how to gather needed details:
213
+
There are several ways to gather necessary details:
158
214
1. Get the values (user-configurable options) used by Help to generate Kubernetes manifests:
159
215
```shell
160
-
helm get values --all --namespace wsc wsc-app-5-25-0>wsc-app-5-25-0-values.yaml
216
+
helm get values --all --namespace wsc wproofreader-app > wproofreader-app-values.yaml
161
217
```
162
-
where `wsc` is the namespace and `wsc-app-5-25-0` – the name of your release,
163
-
and `wsc-app-5-25-0-values.yaml` – name of the file the data will be written to.
218
+
where `wsc` is the namespace and `wproofreader-app` – the name of your release,
219
+
and `wproofreader-app-values.yaml` – name of the file the data will be written to.
164
220
165
221
2. Extract the full Kubernetes manifest(s) as follows:
166
222
```shell
167
-
helm get manifest --namespace wsc wsc-app-5-25-0> manifests.yaml
223
+
helm get manifest --namespace wsc wproofreader-app > manifests.yaml
168
224
```
169
225
170
-
If, for any reason, you do not have access to `helm`, same can be accomplished using
171
-
`kubectl`. To get manifests for all resources in `wsc` namespace, use:
226
+
If you do not have access to `helm`, same can be accomplished using
227
+
`kubectl`. To get manifests for all resources in the `wsc` namespace, run:
172
228
```shell
173
229
kubectl get all --namespace wsc -o yaml > manifests.yaml
230
+
```
231
+
3. Retrieve the logs of all `wsproofreader-app` pods in the `wsc` namespace:
0 commit comments