Kubernetes Deployment

RDT provides a one-click Kubernetes deployment workflow powered by Helm. It handles the entire lifecycle — from Helm chart installation to configuration package copying, ConfigMap creation, and service restarts.

Prerequisites

Requirement	Details
Access to SAMO Kubernetes Cluster	You must have access to the SAMO K8s cluster with a valid kubeconfig context. Contact your infrastructure team or the RDT team to get cluster credentials.
kubectl	Installed and configured with the cluster context above
Helm	Version 3.x installed
SAMO License files	License XML file + license file (provided by SAMO licensing)
Secrets YAML	Helm values file with sensitive configuration (database passwords, etc.)
Property files	All 7 environment property files for ConfigMap creation (see ConfigMap settings)
Access to SAMO OCI registry	The Helm chart is pulled from oci://docker.asseco-ce.com/samo/infrastructure/samo-rdt-helm-chart/charts/samo-rdt. You need access to docker.asseco-ce.com with 2FA configured (see below).

Setting up OCI registry access

The SAMO Helm chart is hosted at docker.asseco-ce.com. To pull it, you need to set up external Git/Docker access with 2FA:

1. Set up 2FA on your docker.asseco-ce.com account (if not already done)
2. Log in to the OCI registry via Helm:

helm registry login docker.asseco-ce.com

Enter your docker.asseco-ce.com username and password/access token when prompted.

3. Verify access by pulling the chart:

helm pull oci://docker.asseco-ce.com/samo/infrastructure/samo-rdt-helm-chart/charts/samo-rdt --version 0.1.0

If this downloads the chart successfully, you're ready to deploy.

Verify your setup

Run these commands to confirm everything is ready:

# Cluster access
kubectl cluster-info
kubectl get namespaces

# Helm + OCI registry
helm version
helm pull oci://docker.asseco-ce.com/samo/infrastructure/samo-rdt-helm-chart/charts/samo-rdt --version 0.1.0

Starting a Deployment

Click Deploy to Kubernetes in the RDT Activity Bar panel, or run the command from the Command Palette:

SAMO RDT: Deploy to Kubernetes

Screenshot needed

The "Deploy to Kubernetes" button in the RDT panel

Deployment Flow

Step 1 — Select Subproject

If your workspace contains multiple subprojects, a Quick Pick menu lets you choose which one to deploy.

If only one subproject exists, it is selected automatically.

Screenshot needed

The subproject picker with multiple projects listed

Step 2 — Select Environment

Choose the target environment from the available directories under <subproject>/project/environments/.

Each environment entry shows its status:

• $(check) rdt.json — configuration file exists
• (no rdt.json — will be generated) — first deployment, config will be auto-created

Screenshot needed

The environment picker showing environments with their rdt.json status

Step 3 — Configuration Loading

RDT loads the deployment configuration from two sources, merged together:

If rdt.json doesn't exist for the selected environment, it is created automatically with the current VS Code settings as defaults. See Per-Environment Config for details.

Step 4 — Validation

Before deploying, RDT validates:

• License XML file exists at the configured path
• License file exists at the configured path
• Secrets YAML file exists at the configured path
• All referenced property files exist in the environment directory
• configPackagesPath is safe (no path traversal)

If any validation fails, the deployment is aborted with a clear error message.

Step 5 — Helm Install/Upgrade

RDT runs helm upgrade --install with your SAMO Helm chart:

Helm release naming: The release is named samo-<namespace> to ensure uniqueness across namespaces.

Namespace: Created automatically if it doesn't exist. By default, derived from your OS username (e.g., rdt-john).

You can follow the Helm output in real-time in the Output panel → "SAMO Kubernetes".

Screenshot needed

The Output panel showing live Helm deployment output

Step 6 — Wait for Pod

After Helm succeeds, RDT polls the pod status every 5 seconds until the LIDS pod is running:

Waiting for pod to be ready... (timeout: 5m)
Pod lids-as-0 is now running.

Step 7 — Copy Configuration Packages

Once the pod is ready, RDT copies your local configuration packages to the pod:

1. Clear the remote directory: kubectl exec -- rm -rf /usr/local/configuration/*
2. Copy local files: kubectl cp <configPackagesPath>/ <pod>:/usr/local/configuration/

The source directory defaults to configuration/packages/ relative to the subproject root. This can be customized via the configPackagesPath setting.

Step 8 — Apply ConfigMaps

RDT creates or updates 7 Kubernetes ConfigMaps from your environment's property files:

ConfigMap Name	Source Setting	ConfigMap Key
lidsas-properties	lidsasProperties	environment.properties
samogateway-properties	samogatewayProperties	environment.properties
securityserver-properties	securityserverProperties	environment.properties
userservice-properties	userserviceProperties	environment.properties
licenseserver-properties	licenseserverProperties	environment.properties
datasource-properties	datasourceProperties	environment.properties
lidsas-master-properties	lidsasMasterProperties	environment_master.properties

Property Rewriting

Before creating ConfigMaps, RDT rewrites service URLs in property files to use Kubernetes internal service names:

Original URL pattern	Rewritten to
*localhost*:*/lids-as/*	http://lids-as:8080/lids-as/
*localhost*:*/security-server/*	http://security-server:8080/security-server/
*localhost*:*/samo-gateway/*	http://samo-gateway:8080/samo-gateway/
*localhost*:*/user-service/*	http://user-service:8080/user-service/
*localhost*:*/license-server/*	http://license-server:8080/license-server/
*elasticsearch*	http://elasticsearch:9200

This ensures services can communicate within the Kubernetes cluster.

Currently, all services are rewritten to cluster-internal addresses. In a future version, RDT will support configuring external access for services such as external license servers, external databases, external Elasticsearch instances, etc.

Step 9 — Restart Services

After applying ConfigMaps, RDT restarts the lids-as-master StatefulSet and waits for it to become ready:

kubectl rollout restart statefulset/lids-as-master -n <namespace>

Step 10 — Activate Sync

On successful deployment, RDT automatically activates the Kubernetes Sync feature, which watches your local files for changes and enables incremental syncing without redeployment.

Complete Deployment Flow

Output Channel

All deployment commands and their output are logged to the SAMO Kubernetes output channel:

1. Open the Output panel: Ctrl+Shift+U
2. Select SAMO Kubernetes from the channel dropdown

Screenshot needed

The SAMO Kubernetes output channel showing a complete deployment log

This is your primary tool for diagnosing deployment issues.

Error Handling

Phase	Error	Cause	Solution
Validation	"License file not found"	File doesn't exist at configured path	Check licenseXmlPath / licenseFilePath in settings or rdt.json
Validation	"Secrets YAML not found"	File doesn't exist at configured path	Check secretsYamlPath in settings or rdt.json
Validation	"Property file not found"	Property file missing in environment dir	Ensure all 7 property files exist in the environment directory
Helm	Helm command failure	Chart not found, auth error, timeout	Check Output channel for Helm error details
Pod	Pod startup timeout	Pod crash loop, resource limits, image pull	Inspect pod logs: kubectl logs <pod> -n <ns>
Config	Copy failure	Pod not ready, permission denied	Verify pod status: kubectl get pods -n <ns>
ConfigMap	Creation failure	RBAC permissions, namespace issues	Verify kubectl permissions in the target namespace

Custom Tool Paths

If kubectl or helm are not on your system PATH, configure custom paths in VS Code settings:

{
  "samo-rdt.kubeDeploy.kubectlPath": "/usr/local/bin/kubectl",
  "samo-rdt.kubeDeploy.helmPath": "/usr/local/bin/helm"
}

note

Tool paths (kubectlPath, helmPath, helmTimeout) are machine-specific settings — they are never written to rdt.json and are always read from VS Code settings. This ensures each developer on the team can have their own paths without conflicts.