DOCSEARCHbyAlgolia
Submit Docs

NeonForge Documentation

website·Indexed 31 days ago

https://docs.neonforge.com/docs/neonkube/

Documentation for NeonForge products, including NeonKUBE for deploying and managing Kubernetes clusters on AWS, Azure, and on-premise hypervisors; the OperatorSDK for building, testing, and packaging Kubernetes Operators in .NET; and NeonSDK, an open-source collection of general-purpose libraries.

Tokens
23.3K
Snippets
102
Records
164
Agent score
49%

What's inside NeonForge

  1. Overview of NeonKUBE Kubernetes Distribution

    NeonKUBE is a full-stack, production-ready Kubernetes distribution designed to provide a consistent developer experience across laptops, on-premise servers, and the cloud. Unlike basic Kubernetes, NeonKUBE layers curated open-source components onto the core to handle cluster deployment and management. It supports deployment to Windows workstations, XenServer, and XCP-ng.

  2. Overview of the OperatorSDK for .NET

    The OperatorSDK is a toolkit designed for developers to build, test, and package Kubernetes Operators using the .NET framework. It allows for the creation of application-specific controllers that extend the Kubernetes API to automate the deployment, configuration, and management of complex applications, replacing manual human operational tasks.

  3. Overview of NeonCLI (neon)

    neon is a command-line tool used to configure and manage the nodes of a NeonKUBE cluster. It is included with NeonDESKTOP. The CLI provides a unified interface for cluster life-cycle management, utility tools, and acts as a wrapper for standard kubectl and helm commands.
    neon

  4. Overview of NeonSDK and Neon libraries

    NeonSDK is an open-source project licensed under Apache 2.0. It provides a collection of general-purpose class libraries distributed as NuGet packages, collectively referred to as the Neon libraries.

  5. Deploy Kubernetes clusters using Neon Cluster Definitions

    NeonDESKTOP and NeonCLI use Cluster Definitions—YAML files that describe nodes, networking, hosting credentials, and configuration—to deploy Kubernetes clusters. While NeonDESKTOP has a built-in definition for local desktop clusters, any other deployment (Hyper-V, XenServer, XCP-ng, AWS, or Azure) requires a custom YAML cluster definition.

  6. Manage cluster security and certificates with neon-cluster-operator

    The neon-cluster-operator is a core service in every NeonKUBE cluster responsible for maintaining security and lifecycle management. It automates two critical security functions:

    1. Certificate Rotation: Periodically generates new cryptographic keys and certificates for the API server, etcd database, and kubelet agents to ensure secure, authenticated communication and replace expired or compromised credentials.
    2. Security Updates: Monitors for and applies patches or fixes to address vulnerabilities in the cluster software or operating system across all nodes, either automatically or on demand.

  7. Access default operator performance metrics

    Neon Forge operators automatically emit a collection of performance metrics for each controller by default. A sample Grafana dashboard configuration is available to visualize these metrics via the operator-dashboard.json asset.

  8. Prerequisites for NeonKUBE deployment on XenServer/XCP-ng

    To deploy NeonKUBE, you need a machine running XenServer or XCP-ng (v8.2+ required) on AMD64 architecture.

    Minimum hardware requirements:

    • CPU: 4 cores
    • Memory: 16+ GB
    • Disk: 500GB SSD

    Ensure you have the IP address of the machine and the root password available.

  9. Choose a persistence type in NeonKUBE

    NeonKUBE provides several storage options depending on the application's performance and access requirements:

    • Network File System (NFS): Supports ReadWriteMany. Best for small applications requiring shared file access. Note that NFS is relatively slow and unsuitable for high-performance operations.
    • Block Storage: Dynamically provisioned volumes where each pod receives a separate Persistent Volume. Available engines include:
      • OpenEBS cStor: Enterprise-grade storage featuring synchronous replication, snapshots, clones, thin provisioning, and high resiliency.
      • OpenEBS Jiva: A lightweight distributed storage engine suitable for smaller clusters.
      • OpenEBS LocalPV: Provisions Kubernetes Local Volumes. Offers the highest performance but reduced availability; ideal for distributed databases.
    • Object Storage: High-performance, S3-compatible storage provided by Minio.

  12. Define Dependent Resources for Reconciliation

    Dependent resources are Kubernetes objects created by the operator as a result of reconciling a primary resource. Watching these dependents allows the operator to re-reconcile the primary resource if a dependent object changes.

    Dependents can be defined using the [DependentResource<T>] attribute or via ResourceManagerOptions.DependentResources in Startup.cs (which requires [Controller(Ignore = true)]).

    // Attribute-based definition
[DependentResource<V1Pod>]
[DependentResource<V1Service>]
public class EtcdController : ResourceControllerBase<V1EtcdCluster> { }

// Manual configuration in Startup.cs
services.AddKubernetesOperator()
    .AddController<EtcdController>(
        options: new ResourceManagerOptions()
        {
            DependentResources = new List<IDependentResource>()
            {
                new DependentResource<V1Pod>(),
                new DependentResource<V1Service>()
            }
        });