Merge remote-tracking branch 'upstream/main' into 2025/add/fluentd

Author: mrnicegyu11

.github/PULL_REQUEST_TEMPLATE.md

@@ -18,8 +18,16 @@
 - [ ] Service has placement constraints or is global
 - [ ] Service is restartable
 - [ ] Service restart is zero-downtime
+- [ ] Service has >1 replicas in PROD
+- [ ] Service has docker heathlcheck enabled
 - [ ] Service is monitored (via prometheus and grafana)
 - [ ] Service is not bound to one specific node (e.g. via files or volumes)
 - [ ] Relevant OPS E2E Test are added
+
+If exposed via traefik
 - [ ] Service's Public URL is included in maintenance mode
-- [ ] Service's Public URL is included in testing mode -->
+- [ ] Service's Public URL is included in testing mode
+- [ ] Service's has Traefik (Service Loadbalancer) Healthcheck enabled
+- [ ] Credentials page is updated
+- [ ] Url added to e2e test services (e2e test checking that URL can be accessed)
+-->

.gitignore

@@ -142,7 +142,7 @@ yq
 **/.env-devel
 **/.stack.*.yml
 **/.stack.*.yaml
-docker-compose.yml
+
 stack.yml
 stack_with_prefix.yml
 docker-compose.simcore.yml

.pre-commit-config.yaml

@@ -122,3 +122,10 @@ repos:
         always_run: true
         language: script
         files: '^(.*\/Makefile.*)|(.*\.deploy_everything_locally.bash)|(.*\/services/.*\/.*\.((sh)|(bash)))$'
+      - id: helm-update-dependencies
+        name: Helm Dependency Update
+        description: Make sure all Chart.lock files are up-to-date
+        entry: bash -c 'find . -name Chart.yaml -exec dirname {} \; | xargs -t -I% helm dependency update %'
+        language: system
+        files: ^charts/
+        pass_filenames: false

Makefile

@@ -26,7 +26,7 @@ certificates/domain.key:
 	# Done: Creating docker secrets
 
 .PHONY: up-local
-up-local: .init .venv .install-fqdn certificates/domain.crt certificates/domain.key .create-secrets ## deploy osparc ops stacks and simcore, use minio_disabled=1 if minio s3 should not be started (if you have custom S3 set up)
+up-local: .init venv .install-fqdn certificates/domain.crt certificates/domain.key .create-secrets ## deploy osparc ops stacks and simcore, use minio_disabled=1 if minio s3 should not be started (if you have custom S3 set up)
 	@bash scripts/deployments/deploy_everything_locally.bash --stack_target=local --minio_enabled=0 --vcs_check=1
 	@$(MAKE) info-local
 

charts/SECURITY.md

@@ -0,0 +1,17 @@
+# Security
+
+This file documents security measures and their configuration in current code base
+
+## Application developer
+
+Full list: https://kubernetes.io/docs/concepts/security/application-security-checklist/
+
+#### Pod-level securityContext recommendations
+
+Enable pod security standard on namespace level:
+* create namespace with labels (examples and explanations https://aro-labs.com/pod-security-standards/)
+* configure pod and container security context to satisfy security standards (read more https://medium.com/dynatrace-engineering/kubernetes-security-part-3-security-context-7d44862c4cfa)
+
+## Cluster / OPS developers
+
+Full list: https://kubernetes.io/docs/concepts/security/security-checklist/

charts/aws-ebs-csi-driver/README.md

@@ -0,0 +1,28 @@
+## How to delete volumes with `recalimPolicy: retain`
+1. Delete pvc:
+```
+kubectl delete pvc <pvc-name>
+```
+
+2. Verify PV is `released`
+```
+kubectl get pv <pv-name>
+```
+
+3. Manually remove EBS in AWS
+    1. Go to AWS GUI and List EBS Volumes
+    1. Filter by tag `ebs.csi.aws.com/cluster=true`
+    1. Identify the volume associated with your PV (check `kubernetes.io/created-for/pv/name` tag of the EBS Volume)
+    1. Verify that EBS Volume is `Available`
+    1. Delete EBS Volume
+
+4. Delete the PV
+```
+kubectl delete pv <pv-name>
+```
+
+5. Remove Finalizers (if necessary)
+If the PV remains in a Terminating state, remove its finalizers:
+```
+kubectl patch pv <pv-name> -p '{"metadata":{"finalizers":null}}'
+```

charts/aws-ebs-csi-driver/values.yaml.gotmpl

@@ -5,7 +5,7 @@ image:
     tag: "v1.38.1"
 
 storageClasses:
-  - name: "ebs-sc"
+  - name: "{{ .Values.ebsStorageClassName }}"
     parameters:
         type: "gp3"
     allowVolumeExpansion: true

charts/longhorn/README.md

@@ -2,7 +2,7 @@
 
 ### Can LH be used for critical services (e.g., Databases)?
 
-No (as of now). , we should not use it for volumes of critical services.
+No. We should not use it for volumes of critical services.
 
 As of now, we should avoid using LH for critical services. Instead, we should rely on easier-to-maintain solutions (e.g., application-level replication [Postgres Operators], S3, etc.). Once we get hands-on experience, extensive monitoring and ability to scale LH, we can consider using it for critical services.
 
@@ -25,6 +25,20 @@ Source:
 * https://longhorn.io/kb/tip-only-use-storage-on-a-set-of-nodes/
 * https://longhorn.io/docs/1.8.1/nodes-and-volumes/nodes/default-disk-and-node-config/#customizing-default-disks-for-new-nodes
 
+### How to configure disks for LH
+
+Manual configuration performed (to be moved to ansible)
+1. Create partition on the disk
+    * e.g. via using `fdisk` https://phoenixnap.com/kb/linux-create-partition
+2. Format partition as XFS
+    * `sudo mkfs.xfs -f /dev/sda1`
+3. Mount partition `sudo mount -t xfs /dev/sda1 /longhorn`
+4. Persist mount in `/etc/fstab` by adding line
+    * `UUID=<partition's uuid> /longhorn xfs pquota 0 0`
+    * UUID can be received from `lsblk -f`
+
+Issue asking LH to clearly document requirements: https://github.com/longhorn/longhorn/issues/11125
+
 ### Can workloads be run on nodes where LH is not installed?
 
 Workloads can run on nodes without LH as long as LH is not restricted to specific nodes via the `nodeSelector` or `systemManagedComponentsNodeSelector` settings. If LH is configured to run on specific nodes, workloads can only run on those nodes.
@@ -48,3 +62,22 @@ Insights into LH's performance:
 
 Resource requirements:
 * https://github.com/longhorn/longhorn/issues/1691
+
+### (Kubernetes) Node maintenance
+
+https://longhorn.io/docs/1.8.1/maintenance/maintenance/
+
+Note: you can use Longhorn GUI to perform some operations
+
+### Zero downtime updating longhorn disks (procedure)
+Notes:
+* Update one node at a time so that other nodes can still serve data
+
+1. Go to LH GUI and select a Node
+    1. Disable scheduling
+    2. Request eviction
+1. Remove disk from the node
+    * If remove icon is disabled, disable eviction on disk to enable the remove button
+2. Perform disks updates on the node
+3. Make sure LH didn't pick up wrongly configured disk in the meantime and remove the wrong disk if it did so
+4. Wait till LH automatically adds the disk to the Node

charts/portainer/values.ebs-pv.yaml.gotmpl

@@ -1,4 +1,4 @@
 persistence:
   enabled: true
   size: "1Gi"  # minimal size for gp3 is 1Gi
-  storageClass: "ebs-sc"
+  storageClass: "{{ .Values.ebsStorageClassName }}"

charts/portainer/values.longhorn-pv.yaml.gotmpl

@@ -1,4 +1,4 @@
 persistence:
   enabled: true
   size: "300Mi" # cannot be lower https://github.com/longhorn/longhorn/issues/8488
-  storageClass: "{{.Values.longhornStorageClassName}}"
+  storageClass: "{{ .Values.longhornStorageClassName }}"