jetbrains/teamcity-operator pulls statistics

TeamCity Kubernetes Operator

TeamCity Operator is a Kubernetes operator that deploys and manages TeamCity servers using a Custom Resource Definition (CRD).

Installation

Prerequisites

• Kubernetes v1.26.0+ • cert-manager installed in the cluster • Tested with cert-manager v1.14.3 • Install example:

Install the Operator via Helm

Install release 0.0.20 of the chart from GitHub Releases:

Install from source

From the repository root of this project:

Verify installation:

Create a TeamCity server

After installing the operator, apply a TeamCity custom resource. Below are common configurations. You can find additional samples under config/samples/v1beta1.

Note: When setting CPU and memory requests/limits for nodes, consult the official TeamCity Server Requirements to estimate appropriate resources: https://www.jetbrains.com/help/teamcity/system-requirements.html#TeamCity+Server+Requirements.

Standalone TeamCity Main Node with a data directory

Standalone TeamCity Main Node with a pre-configured external database

Standalone TeamCity Main Node with startup properties

Standalone TeamCity Main Node with Ingress and Service

Standalone TeamCity Main Node with a ServiceAccount

Standalone TeamCity Main Node with init containers

Multi-node: Main Node with one Secondary TeamCity Node without responsibilities

Multi-node: Main Node with two Secondary TeamCity Nodes with responsibilities

See TeamCity multi-node responsibilities: https://www.jetbrains.com/help/teamcity/multinode-setup.html#Responsibilities

Zero-downtime upgrades

Note: This is an experimental feature. Behavior and configuration may change between releases. We welcome feedback — please open an issue in this repository with your experience and suggestions.

Enables a safe upgrade flow where the operator restarts or replaces nodes in a way that keeps TeamCity available. In short: it upgrades nodes one at a time and ensures at least one node is serving the UI during the process.

How it works

• Standalone Main Node setup • The operator temporarily creates a Secondary TeamCity Node using the Main Node’s spec. • Traffic keeps going to this temporary node while the Main Node is restarted/upgraded. • After the Main Node is healthy again, the temporary node is removed. • Multi-node setup (Main Node + Secondary TeamCity Nodes) • Nodes are upgraded sequentially (for example, one Secondary TeamCity Node at a time, then the Main Node), so at least one node continues to serve requests. • The operator waits for a node to become healthy before moving on to the next one.

What to keep in mind

• You annotate your TeamCity resource with teamcity.jetbrains.com/update-policy: zero-downtime to turn this on. • This flow assumes your deployment can support multiple nodes briefly running side-by-side (e.g., using a shared database) so the UI remains available during upgrades.

Migration

• Migrating from an existing TeamCity installation? See docs/MIGRATION.md for two approaches: • Approach 1: Move the TeamCity Data Directory to the Operator-managed PVC (simplest). • Approach 2: Full backup and restore into a new, empty database.

Limitations

• Custom volume mounts are not available; this feature is under development. • Mounting custom Secrets as environment variables is currently not supported. • Ingress integration has been tested with the NGINX Ingress Controller only.

Description from the Docker Hub listing.