central-operator

Description

The central-operator deploys central's instances and performs monitoring and management of them.

The functions of the operator include:

• Deploying instances of Central
• Performing database migrations
• Detecting Flussonics in the cluster and automatically adding them to Central

Getting Started

Steps to launch a cluster with multiple instances of Central and Flussonic.

Apply the Central and Media Server operators so that Kubernetes recognizes the CRDs and runs operator instances waiting for the corresponding resources to appear in the cluster:

kubectl apply -f https://flussonic.github.io/media-server-operator/latest/operator.yaml
kubectl apply -f https://flussonic.github.io/central-operator/latest/operator.yaml

Next, label the nodes accordingly and add the necessary secrets:

kubectl label nodes node_name flussonic.com/streamer=true
kubectl create secret generic flussonic-license \
    --from-literal=license_key="${LICENSE_KEY}" \
    --from-literal=edit_auth="root:password"

* node_name - the name of the node where Flussonic should run. Flussonic instances will be deployed on each node labeled accordingly.

Then, add the required custom resources so that the operators can deploy and provision the corresponding standard Kubernetes resources:

kubectl apply -f https://raw.githubusercontent.com/flussonic/central-operator/master/config/samples/ingress.yaml
kubectl apply -f https://raw.githubusercontent.com/flussonic/central-operator/master/config/samples/media_v1alpha1_mediaserver.yaml
kubectl apply -f https://raw.githubusercontent.com/flussonic/central-operator/master/config/samples/media_v1alpha1_central.yaml
kubectl apply -f https://raw.githubusercontent.com/flussonic/central-operator/master/config/samples/postgres.yaml
kubectl apply -f https://raw.githubusercontent.com/flussonic/central-operator/master/config/samples/redis.yaml

Note: Currently, Central works correctly only with Nginx as the ingress controller (required by the agent). If another controller is used by default, remove it from Kubernetes and apply the ingress-nginx manifests:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
kubectl apply -f https://raw.githubusercontent.com/flussonic/central-operator/master/config/samples/nginx_ingress_class.yaml

If all the above steps are completed successfully, the cluster should include PostgreSQL, Redis, two Central instances, and one Flussonic instance per each labeled node.

For developers

The project is based on operator-sdk. Versioning is handled automatically via Git tags.

Local Development

To run the operator against your current Kubernetes context (сheck your kubeconfig, use only the test cluster!), execute:

make install
make run

Generating Manifests

To generate the final operator.yaml with the version derived from the current Git state:

make operator.yaml

Local Cluster (Multipass + k3s)

To deploy a complete local test environment. Requires LICENSE_KEY environment variable.

make mp-start

This command uses the manifest from docs/latest/operator.yaml, deploying the latest version from the master branch, not your local code changes. To stop the environment, run make mp-stop.

Environment Variables Configuration

The operator configures components using environment variables with a clear order of precedence. A source with a higher number in the list below will always override a source with a lower number.

Precedence Rules (from highest to lowest)

1. Unit-Specific env

   • Defined in spec.central.env, spec.layouter.env, etc.
   • Purpose: Fine-tune or override settings for a single component.

2. Required Fields in spec

   • Defined via spec.database, spec.redis, spec.apiKey.
   • Purpose: The primary and required way to configure critical settings for all components.

3. Common env

   • Defined in spec.commonEnv.
   • Purpose: Set non-critical, user-defined variables for all components at once.

4. envFrom sources

   • Defined in spec.commonEnvFrom or unit-specific envFrom.
   • Purpose: Load variables in bulk from ConfigMaps or Secrets.

Important: To ensure stability, attempts to set critical variables (like CENTRAL_DATABASE_URL) via commonEnv are ignored. You must use the dedicated spec.database field. However, you can override it in a unit-specific env for advanced use cases.

Deployment Workflow

We use a semi-automated GitOps workflow.

Testing a Branch

1. To test changes from a feature branch, go to your Merge Request in GitLab and manually trigger the dockerhub-rolling CI job. This will build a Docker image.
2. Run make operator.yaml locally. This will generate a manifest with a unique version in a docs/version-name/ directory.
3. Apply this temporary manifest to your test cluster: kubectl apply -f docs/version-name/operator.yaml.

Creating a Release

The release process requires two commits and is based on Git tags.

1. Merge your dev branch into master.

2. Create and push a Git tag. This will trigger a CI pipeline that builds and publishes the final Docker image.

   # Example:
   git tag -a v26.1.6 -m 'version 26.1.6' && git push --tags

3. Generate and commit the final manifest. After the tag is pushed, run make operator.yaml locally. This will update docs/latest/ and create docs/v26.1.6/. Commit these changes to the master branch and push.

4. Publish documentation. The final push to master will trigger another CI pipeline. Manually run the push-docs-to-github job to publish the manifests.

Deploy to vsaas.io Cluster

To apply the new version to the cluster (Stage or Prod), you need to update the GitOps repository (peeklio_cluster).

1. Update Kustomization:
   • For Stage: Edit central-operator/overlays/stage/kustomization.yaml.
   • For Prod: Edit central-operator/base/kustomization.yaml
2. Change Resource URL: Update the link to point to the new version
3. Commit and Push: Commit and push the change.
4. Sync: ArgoCD detects the configuration change, you may need to manually trigger the Sync to apply the update.

License

Copyright 2024.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.