kerberos-io/deployment
1
0
Fork 0
mirror of https://github.com/kerberos-io/deployment.git synced 2026-08-23 15:18:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

Refactor Factory references and update deployment configurations

Browse Source
This commit is contained in:
cedricve
2026-06-22 12:36:57 +00:00
parent 0c1520c936
commit 8f41e9c375
8 changed files with 157 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
README.k8s.md
View File

@@ -351,7 +351,7 @@ With the Kerberos Vault installed, we can proceed to configure the various compo
### Create a Kerberos Agent
After deploying the Kerberos Vault and configuring the necessary services for storage, database, and integration, you can proceed to deploy the Kerberos Agent with the appropriate configuration. Review the `kerberos-agent-deployment.yaml` file and adjust the relevant settings, such as the RTSP URL, to ensure proper functionality. As mentioned below note that you can opt for the [Kerberos Factory](https://github.com/kerberos-io/factory/tree/master/kubernetes) which gives you a UI to manage the creation of Kerberos Agents. **_(Please note if you generated new the keys in the previous Kerberos Vault account creation, you need to update those in the Kerberos Agent deployment)_**
After deploying the Kerberos Vault and configuring the necessary services for storage, database, and integration, you can proceed to deploy the Kerberos Agent with the appropriate configuration. Review the `kerberos-agent-deployment.yaml` file and adjust the relevant settings, such as the RTSP URL, to ensure proper functionality. As mentioned below note that you can opt for the [Factory](https://github.com/kerberos-io/factory/tree/master/kubernetes) which gives you a UI to manage the creation of Kerberos Agents. **_(Please note if you generated new the keys in the previous Kerberos Vault account creation, you need to update those in the Kerberos Agent deployment)_**
```bash
kubectl apply -f kerberos-agent-deployment.yaml
@@ -366,11 +366,11 @@ kubectl logs -f kerberos-agent...
To validate the Kerberos Vault and review any stored recordings, access the user interface at `http://localhost:30080` (after establishing the reverse tunnel).
### Create Kerberos Agents through Kerberos Factory
### Create Kerberos Agents through Factory
Managing Kerberos Agents through seperate configuration files might feel cumbersome, especially for non-technical users. This is where Kerberos Factory comes into the picture. Kerberos Factory provides a visual view that allows you to rapidly connect cameras through a user interface, which allows users without any technical background about cameras and kubernetes create Kerberos Agents.
Managing Kerberos Agents through seperate configuration files might feel cumbersome, especially for non-technical users. This is where Factory comes into the picture. Factory provides a visual view that allows you to rapidly connect cameras through a user interface, which allows users without any technical background about cameras and kubernetes create Kerberos Agents.
Kerberos Factory also requires a mongodb, just like Kerberos Vault. Luckily you can reuse the mongodb installation we have deployed earlier, the only thing we'll need to do is to create another `configmap.yaml` in the `kerberos-factory` namespace.
Factory also requires a mongodb, just like Kerberos Vault. Luckily you can reuse the mongodb installation we have deployed earlier, the only thing we'll need to do is to create another `configmap.yaml` in the `kerberos-factory` namespace.
Create the `kerberos-factory` namespace.
@@ -378,7 +378,7 @@ Create the `kerberos-factory` namespace.
kubectl create namespace kerberos-factory
```
Apply the manifests, so the Kerberos Factory application is deployed and knows how to connect to the MongoDB.
Apply the manifests, so the Factory application is deployed and knows how to connect to the MongoDB.
```bash
kubectl apply -f ./mongodb-configmap.yaml -n kerberos-factory
@@ -386,7 +386,7 @@ kubectl apply -f ./kerberos-factory-deployment.yaml -n kerberos-factory
kubectl apply -f ./kerberos-factory-service.yaml -n kerberos-factory
```
To allow our Kerberos Factory to create Kubernetes resources we will need to apply an additional cluster role. This will allow our Kerberos Factory deployment to read and write resources to our Kubernetes cluster.
To allow our Factory to create Kubernetes resources we will need to apply an additional cluster role. This will allow our Factory deployment to read and write resources to our Kubernetes cluster.
```bash
kubectl apply -f ./kerberos-factory-clusterrole.yaml -n kerberos-factory

2
README.md
View File

@@ -7,7 +7,7 @@ Deploying the Kerberos.io stack may initially appear to be a complex task due to
The Kerberos.io stack offers flexible installation options, supporting deployment in hybrid environments, fully in the cloud, or entirely at the edge. This deployment guide covers the installation of various Kerberos.io components. For detailed information on each component, please refer to their respective repositories.
- [Kerberos Agent](https://github.com/kerberos-io/agent)
- [Kerberos Factory](https://github.com/kerberos-io/factory)
- [Factory](https://github.com/kerberos-io/factory)
- [Kerberos Vault](https://github.com/kerberos-io/vault)
- [Kerberos Hub](https://github.com/kerberos-io/hub)

2
README.microk8s.md
View File

@@ -334,7 +334,7 @@ With the Vault installed, we can proceed to configure the various components. Cu
### Create a Agent
After deploying the Vault and configuring the necessary services for storage, database, and integration, you can proceed to deploy the Agent with the appropriate configuration. Review the `kerberos-agent-deployment.yaml` file and adjust the relevant settings, such as the RTSP URL, to ensure proper functionality. Please note that you can allow opt for the [Kerberos Factory](https://github.com/kerberos-io/factory/tree/master/kubernetes) which gives you a UI to manage the creation of Agents. Also please note if you generated new the keys in the previous Vault account creation, you need to update those in the Agent deployment.
After deploying the Vault and configuring the necessary services for storage, database, and integration, you can proceed to deploy the Agent with the appropriate configuration. Review the `kerberos-agent-deployment.yaml` file and adjust the relevant settings, such as the RTSP URL, to ensure proper functionality. Please note that you can allow opt for the [Factory](https://github.com/kerberos-io/factory/tree/master/kubernetes) which gives you a UI to manage the creation of Agents. Also please note if you generated new the keys in the previous Vault account creation, you need to update those in the Agent deployment.
```bash
kubectl apply -f kerberos-agent-deployment.yaml

142
base/factory/README.md Normal file
View File

@@ -0,0 +1,142 @@
# Factory — base manifests
This directory holds the raw Kubernetes manifests for **Factory**. Factory
is a web application that runs *inside* your cluster and uses the Kubernetes API to
deploy, configure and observe Kerberos Agents (one Deployment + Service per camera).
> **Scope of this README.** At the top level of this repository Factory is normally
> installed through **Kustomize** (see [`overlays/`](../../overlays) and the
> [`README.kustomize.md`](../../README.kustomize.md)). This README documents the
> alternative: applying the manifests in this folder **directly with `kubectl`**,
> without Kustomize. Use it when you want to install only Factory, understand each
> object in isolation, or integrate these manifests into your own tooling.
## What gets deployed
| File | Kind | Purpose |
| ---- | ---- | ------- |
| [`kerberos-factory-deployment.yaml`](./kerberos-factory-deployment.yaml) | `Deployment` | The Factory web app/API (`uugai/factory`), container port `80`. |
| [`kerberos-factory-service.yaml`](./kerberos-factory-service.yaml) | `Service` | Exposes Factory on `NodePort` **30079** (a `LoadBalancer` variant is included, commented out). |
| [`kerberos-factory-clusterrole.yaml`](./kerberos-factory-clusterrole.yaml) | `ClusterRole` + `ClusterRoleBinding` | Grants the `default` ServiceAccount in `kerberos-factory` the API access Factory needs to manage Agents. |
The matching namespace (`kerberos-factory`) is defined one level up in
[`../namespaces/kerberos-factory.yaml`](../namespaces/kerberos-factory.yaml).
## Configuration (ConfigMap store + Kubernetes engine)
These manifests are configured to run Factory **without MongoDB**. Factory keeps its
own (global/template) configuration and delivers each Agent's configuration through
Kubernetes **ConfigMaps**, and schedules Agents with the **Kubernetes** engine. This
is controlled by two environment variables on the Deployment:
```yaml
- name: FACTORY_CONFIGURATION
value: "configmap" # store config in ConfigMaps (json | configmap | secret | mongodb)
- name: FACTORY_ENGINE
value: "kubernetes" # schedule agents as Deployments (kubernetes | docker | host)
```
On start-up Factory bootstraps two cluster ConfigMaps — `agent-global-config`
(settings every Agent inherits) and `agent-template-config` (the base used for new
Agents) — and creates a per-agent `<name>-config` ConfigMap for each Agent it
provisions. **This is why the ClusterRole includes `configmaps`** — without that
permission the bootstrap fails.
Other relevant environment variables:
| Variable | Default here | Meaning |
| -------- | ------------ | ------- |
| `KERBEROS_LOGIN_USERNAME` / `KERBEROS_LOGIN_PASSWORD` | `root` / `kerberos` | Factory UI login. **Change these for anything but a demo.** |
| `KERBEROS_AGENT_IMAGE` | `kerberos/agent:latest` | Image used when Factory creates an Agent. |
| `KERBEROS_AGENT_MEMORY_LIMIT` | `256Mi` | Default memory limit for created Agents. |
| `NAMESPACE` | `kerberos-factory` | Namespace Factory schedules Agents into. |
| `K8S_PROXY` | `http://localhost:80` | Internal proxy address Factory calls for the `/kubernetes` API. |
## Prerequisites
- A running Kubernetes cluster and a `kubectl` configured to reach it.
- Permission to create `ClusterRole`/`ClusterRoleBinding` (cluster-admin or equivalent).
## Deploy with `kubectl` (without Kustomize)
The manifest files do **not** hard-code a namespace (Kustomize injects it at the upper
level). When applying directly, target the namespace explicitly with `-n`.
```bash
# 1. Create the namespace (only needed if it does not exist yet)
kubectl apply -f ../namespaces/kerberos-factory.yaml
# 2. Create the RBAC. The ClusterRole/ClusterRoleBinding are cluster-scoped;
# the binding's subject already references the kerberos-factory namespace.
kubectl apply -f ./kerberos-factory-clusterrole.yaml
# 3. Deploy Factory and its service into the namespace
kubectl apply -n kerberos-factory -f ./kerberos-factory-deployment.yaml
kubectl apply -n kerberos-factory -f ./kerberos-factory-service.yaml
```
Or apply the whole folder at once (RBAC is cluster-scoped, the rest lands in the
namespace):
```bash
kubectl apply -f ../namespaces/kerberos-factory.yaml
kubectl apply -n kerberos-factory -f ./
```
Verify the rollout:
```bash
kubectl get pods,svc -n kerberos-factory
kubectl rollout status deployment/factory -n kerberos-factory
kubectl logs -n kerberos-factory deploy/factory
```
You should see log lines confirming the global and template Agent ConfigMaps were
bootstrapped.
## Access the UI
With the `NodePort` service, Factory is reachable on port **30079** of any node:
```bash
# Example: open http://<node-ip>:30079
kubectl get nodes -o wide # find a node IP
# Or port-forward without exposing a node port
kubectl port-forward -n kerberos-factory svc/factory-nodeport 8080:80
# then browse http://localhost:8080
```
Log in with the `KERBEROS_LOGIN_USERNAME` / `KERBEROS_LOGIN_PASSWORD` values above
(default `root` / `kerberos`).
To use a cloud `LoadBalancer` instead of a `NodePort`, uncomment the `factory-lb`
service at the bottom of [`kerberos-factory-service.yaml`](./kerberos-factory-service.yaml)
and comment out the `NodePort` service.
## Switching the configuration store
ConfigMap storage is recommended for a clean, database-free install, but Factory
supports other stores via `FACTORY_CONFIGURATION`:
- `configmap` *(default here)* — config in ConfigMaps, no MongoDB.
- `secret` — same as `configmap` but sensitive values are kept in Kubernetes Secrets
(add `secrets` to the ClusterRole resources for this mode).
- `json` — config in local JSON files on the pod, no MongoDB.
- `mongodb` — legacy behaviour: Factory and Agents read config from MongoDB. For this
you also need a reachable MongoDB and the corresponding `MONGODB_*` environment
variables (e.g. via a `mongodb` ConfigMap mounted with `envFrom`).
See the [Configuration & engines documentation](https://github.com/uug-ai/factory)
for the full model.
## Uninstall
```bash
kubectl delete -n kerberos-factory -f ./kerberos-factory-service.yaml
kubectl delete -n kerberos-factory -f ./kerberos-factory-deployment.yaml
kubectl delete -f ./kerberos-factory-clusterrole.yaml
# Optionally remove the agent ConfigMaps Factory created and the namespace
kubectl delete configmap -n kerberos-factory agent-global-config agent-template-config --ignore-not-found
kubectl delete -f ../namespaces/kerberos-factory.yaml
```

2
base/factory/kerberos-factory-clusterrole.yaml
View File

@@ -4,7 +4,7 @@ metadata:
name: pods-list
rules:
- apiGroups: ["", "apps"]
resources: ["pods", "pods/log", "deployments", "services", "services/proxy", "endpoints", "nodes"]
resources: ["pods", "pods/log", "deployments", "services", "services/proxy", "endpoints", "nodes", "configmaps"]
verbs: ["get", "list", "create", "update", "delete", "watch"]
---
kind: ClusterRoleBinding

15
base/factory/kerberos-factory-deployment.yaml
View File

@@ -18,13 +18,9 @@ spec:
labels:
app: factory
spec:
initContainers:
- name: wait-for-mongodb-before-starup
image: busybox
command: ["sh", "-c", "until nc -z mongodb.mongodb 27017 > /dev/null; do echo Waiting for master.; sleep 2; done;"]
containers:
- name: factory
image: "uugai/factory:v1.0.5"
image: "uugai/factory:v2.0.1"
resources:
requests:
memory: 128Mi
@@ -34,9 +30,6 @@ spec:
cpu: 100m
ports:
- containerPort: 80
envFrom:
- configMapRef:
name: mongodb
env:
- name: GIN_MODE
value: release
@@ -53,7 +46,11 @@ spec:
# Do not touch this, unless you know what you are doing.
- name: NAMESPACE
value: "kerberos-factory"
- name: FACTORY_ENVIRONMENT
# Store the factory and agent configuration in Kubernetes ConfigMaps
# (no MongoDB required) and schedule agents with the Kubernetes engine.
- name: FACTORY_CONFIGURATION
value: "configmap"
- name: FACTORY_ENGINE
value: "kubernetes"
- name: K8S_PROXY
value: http://localhost:80

1
base/factory/kustomization.yaml
View File

@@ -1,6 +1,5 @@
namespace: kerberos-factory
resources:
- mongodb-configmap.yaml
- kerberos-factory-deployment.yaml
- kerberos-factory-service.yaml
- kerberos-factory-clusterrole.yaml

18
base/factory/mongodb-configmap.yaml
View File

@@ -1,18 +0,0 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: mongodb
data:
# This is the mongodb database where data will be stored, you might use a different name if you want.
MONGODB_DATABASE_STORAGE: "KerberosStorage"
MONGODB_DATABASE_FACTORY: "KerberosFactory"
MONGODB_DATABASE_HUB: "Kerberos"
# MongoDB URI (for example for a SaaS service like MongoDB Atlas)
# If uri is set, the below properties are not used (host, adminDatabase, username, password)
#MONGODB_URI: "mongodb+srv://xx:xx@kerberos-hub.xxx.mongodb.net/?retryWrites=true&w=majority&appName=xxx"
# If you do not wish to use the URI, you can specify the individual values.
MONGODB_HOST: "mongodb.mongodb"
MONGODB_DATABASE_CREDENTIALS: "admin"
MONGODB_USERNAME: "root"
MONGODB_PASSWORD: "yourpassword"