DOCSEARCHbyAlgolia
Submit Docs

cowboysysop Helm Charts

repository·master·Indexed 41 days ago

https://github.com/cowboysysop/charts

A collection of Helm charts for deploying Kubernetes-native applications, including LLM frameworks, observability tools, and database management interfaces. Includes detailed installation, upgrade, and configuration guides for Katib (supporting version 2.0.0) and KFServing (supporting controller v0.6.1), with specific parameters for controllers, UI components, and MariaDB integration.

Tokens
245.2K
Snippets
372
Records
616
Agent score
100%

What's inside cowboysysop charts

  2. Overview of Cowboy Sysop Charts

    master
    Cowboy Sysop Charts is a collection of Helm charts for deploying various applications and tools on Kubernetes. The repository includes charts for LLM tools (Ollama, Flowise, Local-AI), observability (Grafana MCP, Kubeview), databases (Qdrant, Mongo-Express), and Kubernetes utilities (Vertical Pod Autoscaler, Kubebox).

  3. Use global variables for credentials in complex deployments

    master

    In deployments with multiple dependent sub-charts that all need to connect to the same PostgreSQL instance, instead of repeating credentials for every sub-chart (e.g., subchart1.postgresql.auth.username), use global variables.

    Setting credentials under the global. key makes them available to all sub-charts automatically.

    global.postgresql.auth.username=testuser
global.postgresql.auth.password=testpass
global.postgresql.auth.database=testdb

  4. Run Flowise in queue mode

    master

    To enable queue mode in Flowise, you must configure the following parameters to ensure the architecture supports distributed task processing:

    1. Set config.mode to queue.
    2. Enable the worker by setting worker.enabled to true.
    3. Enable a database. You must set one of the following to true:
      • mariadb.enabled or externalMariadb.enabled
      • postgresql.enabled or externalPostgresql.enabled
    4. Enable Redis by setting redis.enabled or externalRedis.enabled to true.
    config:
  mode: queue
worker:
  enabled: true
redis:
  enabled: true
postgresql:
  enabled: true

  5. Chart Quality and Testing Standards

    master
    All charts in this repository undergo quality testing using ct (helm-chart-testing) across multiple Kubernetes versions (v1.24 to v1.27) using kind (Kubernetes in Docker) as the test environment.

  6. Understand Redis Cluster Topologies

    master

    The chart supports several deployment architectures via the architecture parameter:

    1. Master-Replicas (architecture=replication): Deploys a Redis master StatefulSet and a replicas StatefulSet. Two services are exposed: a Master service (read-write) and a Replicas service (read-only).
    2. Standalone (architecture=standalone): Deploys a single Redis StatefulSet with one Master service (read-write).
    3. Master-Replicas with Sentinel (architecture=replication + sentinel.enabled=true): Deploys a master and replicas, but each pod includes a Redis Sentinel container. Sentinel handles automatic failover. Only one service is exposed (port 6379 for Redis, 26379 for Sentinel). To find the current master, use: SENTINEL get-master-addr-by-name <name>.
    4. Multiple Masters (Experimental): Setting master.count > 1. This is not designed for use with sentinel.enabled=true. To use this safely, it is recommended to set master.service.internalTrafficPolicy=Local and use pod anti-affinity to ensure no more than one master is deployed per node.

  7. Choose between Redis Helm Chart and Redis Cluster Helm Chart

    master

    Depending on your data requirements and scaling needs, you should choose one of two different Helm charts:

    Redis Helm Chart

    • Topology: Master-replica cluster.
    • High Availability: Supports enabling Redis Sentinel.
    • Databases: Supports multiple databases.
    • Writes: Single write point (single master).
    • Best for: General purpose use cases where multiple databases are required.

    Redis Cluster Helm Chart

    • Topology: Redis Cluster topology with sharding.
    • Databases: Supports only one database.
    • Writes: Multiple write points (multiple masters).
    • Best for: Large datasets that require horizontal scaling through sharding.

  8. Configure Kroki sub-module parameters (BPMN, Diagrams.net, Excalidraw, Mermaid)

    master

    Kroki allows enabling or disabling specific diagramming engines. Each engine can be configured independently with its own image, ports, and security settings.

    Available Modules

    • BPMN: bpmn.enabled (Default: true), Port: 8003
    • Diagrams.net: diagramsnet.enabled (Default: true), Port: 8005
    • Excalidraw: excalidraw.enabled (Default: true), Port: 8004
    • Mermaid: mermaid.enabled (Default: true), Port: 8002

    Module Configuration Pattern

    Each module follows a similar configuration schema:

    • [module].enabled: Boolean to toggle the module.
    • [module].image.*: Settings for the specific engine image.
    • [module].containerPorts.http: The HTTP port for that specific engine.
    • [module].securityContext: Specific security settings for the engine container.
    • [module].extraEnvVars: Additional environment variables for the engine.

  9. Choose between Standalone and Replicaset architectures

    master

    The MongoDB chart supports two primary deployment architectures, which you can select using the architecture parameter:

    1. standalone: Installs a single MongoDB server (via a Deployment or StatefulSet). This instance cannot be scaled.
    2. replicaset: Deploys a set of MongoDB servers (one primary and N-1 secondaries) for high availability.

    Replicaset Variations:

    • Without Arbiter: Deploys a single StatefulSet containing N MongoDB servers. Each node has its own service for individual access; there is no service load balancing between nodes.
    • With Arbiter: Deploys two StatefulSets: one for the N MongoDB servers and one for a single, non-scalable Arbiter node. This is useful for maintaining quorum in environments where a third full MongoDB instance cannot be hosted.
    architecture="standalone"
architecture="replicaset"

  10. Use existing secrets with ExistingSecret

    master

    The ExistingSecret schema allows you to use pre-existing Kubernetes secrets instead of having the chart create a new one. This is useful for sensitive data managed outside the chart.

    Key fields:

    • name: The name of the existing secret.
    • keyMapping: An object that maps the expected key name used by the application to the actual key name inside the existing secret.

    Implementation Example

    To use this in your templates, you can leverage the common.secrets.name and common.secrets.key helpers.

    values.yaml

    existingSecret:
  name: mySecret
  keyMapping:
    password: myPasswordKey

    Deployment Template Snippet

    env:
  - name: PASSWORD
    valueFrom:
      secretKeyRef:
        name: {{ include "common.secrets.name" (dict "existingSecret" .Values.existingSecret "context" $) }}
        key: {{ include "common.secrets.key" (dict "existingSecret" .Values.existingSecret "key" "password") }}
    # values.yaml
name: mySecret
keyMapping:
  password: myPasswordKey

  11. Customize primary and read replica services

    master

    In a replicated configuration, you can customize services at different levels:

    1. Top-level service object: Defines services for both primary and readReplicas.
    2. Specific service objects: Use primary.service or readReplicas.service for deeper customization.

    Specific objects take precedence over the top-level object. This allows the primary and read replicas to have different service types or different clusterIPs/nodePorts. If using type: nodePort for both, ensure you set different nodePorts to avoid collisions.