Skip to content

Add raven deployment configuration for Kubernetes #253

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Aravinda-HWK wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add raven deployment configuration for Kubernetes #253

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 47 additions & 0 deletions infa/k8s/raven/raven-deployment.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: raven-server
spec:
replicas: 1
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The deployment is configured with only one replica. This creates a single point of failure. If the node running the pod goes down or the pod crashes, the service will be unavailable until it's rescheduled and started. For better availability, consider increasing the number of replicas to at least 2.

  replicas: 2

selector:
matchLabels:
app: raven
template:
metadata:
labels:
app: raven
spec:
containers:
- name: raven
image: ghcr.io/lsflk/raven:latest
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Using the :latest image tag is not recommended for production deployments as it makes them non-deterministic. If the latest tag is updated, subsequent deployments or pod restarts could pull a new, potentially breaking version of the image. Please use a specific, immutable tag like a semantic version or a git SHA to ensure predictable deployments.

          image: ghcr.io/lsflk/raven:v1.0.0

ports:
- containerPort: 143
- containerPort: 993
- containerPort: 24
- containerPort: 12345
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The container definition is missing resource requests and limits for CPU and memory. This can lead to performance issues and instability in the cluster. Without resource requests, the scheduler can't make informed decisions, and without limits, the container can consume all available resources on a node. Setting these values is critical for ensuring application reliability and fair resource sharing. The values in the suggestion are examples and should be adjusted based on performance testing.

            - containerPort: 12345
          resources:
            requests:
              memory: "128Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"

env:
- name: DB_FILE
value: /app/data/databases/shared.db
volumeMounts:
- name: raven-data
mountPath: /app/data
- name: raven-config
mountPath: /etc/raven
- name: raven-certs
mountPath: /certs
securityContext:
runAsUser: 0
runAsGroup: 0
Comment on lines +33 to +35
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

Running containers as the root user (runAsUser: 0) is a significant security risk. A vulnerability in the application could be exploited to gain root access within the container, and potentially escalate privileges to the host node. It is a security best practice to run processes as a non-privileged user. Please update your Docker image to use a non-root user and set runAsUser and runAsGroup to a non-zero value (e.g., 1001, depending on the user defined in your image).

          securityContext:
            runAsUser: 1001
            runAsGroup: 1001

volumes:
- name: raven-data
persistentVolumeClaim:
claimName: raven-data-pvc
- name: raven-config
hostPath:
path: /root/mail/silver/services/silver-config/raven/conf
type: Directory
- name: raven-certs
hostPath:
path: /root/mail/silver/services/silver-config/raven/certs
type: Directory
Comment on lines +40 to +47
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Using hostPath volumes makes the deployment dependent on a specific node's filesystem structure and poses a security risk by exposing the host filesystem to the container. The paths under /root are especially concerning. The standard and more portable approach in Kubernetes is to use ConfigMap for configuration files and Secret for sensitive data like certificates. This decouples your application from the underlying nodes. You would need to create the corresponding ConfigMap and Secret resources in your cluster.

        - name: raven-config
          configMap:
            name: raven-config-map
        - name: raven-certs
          secret:
            secretName: raven-certs-secret

Loading