TKEStack (Tencent Kubernetes Engine Stack)

repository·master·Indexed 23 days ago

https://github.com/tkestack/tke

An open-source container management platform for production-grade Kubernetes deployments. TKEStack provides unified cluster management, workload orchestration, and advanced O&M capabilities via a web console and CLI. The documentation includes guides for integrating Ceph storage using the ceph-csi-cephfs and ceph-csi-rbd Helm charts.

Tokens
151.6K
Snippets
229
Records
685
Agent score
81%

What's inside TKEStack

  1. Overview of TKEStack Common

    master
    TKEStack Common is the foundational library for the TKEStack frontend console. It manages core dependencies, including routing, business configurations, and stylesheets. The framework primarily supports the configuration of business routes and the dynamic loading of business modules.
  2. TKEStack Core Features Overview

    master

    TKEStack is a container management platform designed for production environments. Key capabilities include:

    • Unified Cluster Management: Centralized management of multiple Kubernetes clusters via Web console or CLI. Supports authentication via LDAP, OIDC, front proxy, and OAuth (e.g., GitHub). Provides unified authorization at both cluster and Kubernetes resource levels.
    • Application Workload Management: Visual UI for resource creation/editing and YAML import. Includes an abstract project-level resource container for managing multiple namespaces and deployments across clusters.
    • Operation and Maintenance: Integrated system/application monitoring, persistent Kubernetes events, and audit logs. Includes tools to track and manage developers and teams.
    • Plugin System: Extensible architecture via plugins for:
      • Authentication identity providers
      • Authorization providers
      • Event persistence storage
      • Log persistence storage
    • Integrated Ecosystem: Supports specialized plugins like Galaxy (Network), TApp (Workload), GPUManage (GPU), CronHPA (HPA), and LBCF (LoadBalance).
  3. Harbor Preheat API Overview

    master

    The Harbor Preheat API allows for managing P2P (Peer-to-Peer) provider instances and preheat policies within Harbor projects. All URIs are relative to http://localhost/api/v2.0.

    Available Methods

    MethodHTTP RequestDescription
    CreateInstancePost /p2p/preheat/instancesCreate p2p provider instances
    CreatePolicyPost /projects/{project_name}/preheat/policiesCreate a preheat policy under a project
    DeleteInstanceDelete /p2p/preheat/instances/{preheat_instance_name}Delete the specified P2P provider instance
    DeletePolicyDelete /projects/{project_name}/preheat/policies/{preheat_policy_name}Delete a preheat policy
    GetExecutionGet /projects/{project_name}/preheat/policies/{preheat_policy_name}/executions/{execution_id}Get an execution detail by id
    GetInstanceGet /p2p/preheat/instances/{preheat_instance_name}Get a P2P provider instance
    GetPolicyGet /projects/{project_name}/preheat/policies/{preheat_policy_name}Get a preheat policy
    GetPreheatLogGet /projects/{project_name}/preheat/policies/{preheat_policy_name}/executions/{execution_id}/tasks/{task_id}/logsGet the log text stream of the specified task
    ListExecutionsGet /projects/{project_name}/preheat/policies/{preheat_policy_name}/executionsList executions for the given policy
    ListInstancesGet /p2p/preheat/instancesList P2P provider instances
    ListPoliciesGet /projects/{project_name}/preheat/policiesList preheat policies
    ListProvidersGet /p2p/preheat/providersList P2P providers
    ListProvidersUnderProjectGet /projects/{project_name}/preheat/providersGet all providers at project level
    ListTasksGet /projects/{project_name}/preheat/policies/{preheat_policy_name}/executions/{execution_id}/tasksList all related tasks for an execution
    ManualPreheatPost /projects/{project_name}/preheat/policies/{preheat_policy_name}Manual preheat
    PingInstancesPost /p2p/preheat/instances/pingPing status of an instance
    StopExecutionPatch /projects/{project_name}/preheat/policies/{preheat_policy_name}/executions/{execution_id}Stop an execution
    UpdateInstancePut /p2p/preheat/instances/{preheat_instance_name}Update the specified P2P provider instance
    UpdatePolicyPut /projects/{project_name}/preheat/policies/{preheat_policy_name}Update preheat policy
  4. Harbor Artifact API Overview

    master

    The Harbor Artifact API provides endpoints for managing artifacts within projects and repositories. All URIs are relative to http://localhost/api/v2.0. Common operations include adding/removing labels, creating/deleting tags, copying artifacts, and retrieving artifact details.

    Note on Repository Names: If a repositoryName contains a slash (e.g., a/b), it must be URL encoded (e.g., a%252Fb).

  5. What is PersistentEvent and when to use it

    master

    Overview

    Kubernetes events record cluster operations, resource scheduling, and lifecycle changes. By default, Kubernetes only retains these events in ETCD for approximately one hour.

    PersistentEvent is a TKEStack feature that enables real-time export of Kubernetes cluster events to a specified ElasticSearch index for long-term storage and troubleshooting.

    Use Cases

    • Deeply understanding cluster internal activities (e.g., scheduler decisions).
    • Investigating why Pods were evicted from nodes.
    • Maintaining a historical record of resource changes and abnormal alerts beyond the default one-hour window.

    Limitations and Requirements

    • ElasticSearch Version: Only supports ElasticSearch version 5.
    • Authentication: Only supports ElasticSearch clusters where user authentication is not enabled.
    • Kubernetes Version: Requires Kubernetes version 1.8 or higher.
    • Resource Consumption: Installing the PersistentEvent add-on consumes approximately 0.2 CPU cores and 100MB of memory.

    Deployed Kubernetes Objects

    When installed, the following object is deployed to your cluster:

    Object NameTypeDefault ResourcesNamespace
    tke-persistent-eventdeployment0.2 CPU, 100MB RAMkube-system
  6. What is CronHPA and how does it work?

    master

    Cron Horizontal Pod Autoscaler (CronHPA) allows users to perform scheduled automatic scaling for supported workload objects (such as Deployment, StatefulSet, and TApp) using CronTab syntax.

    It works by introducing a new Custom Resource Definition (CRD) called cronhpas.extensions.tkestack.io. The cron-hpa-controller (an operator) monitors this CRD and parses the configuration to execute scaling operations based on the system time.

  7. What is TApp and when to use it

    master

    TApp is a custom Kubernetes Workload type (based on CRDs) designed for complex, non-microservice applications that standard Kubernetes workloads like Deployment or StatefulSet cannot easily manage.

    Key Use Cases:

    • Applications requiring control over specific Pods (e.g., stopping or upgrading a single instance).
    • Applications supporting multiple versions of Pods simultaneously.
    • Workloads that need fixed identities (IDs) to maintain stable connections to storage (like Ceph) or fixed IPs.
    • Batch jobs that require specific restart policies.

    Conceptually, TApp ≈ Deployment + StatefulSet + Job, providing a unified workload type that supports both service-oriented and batch-oriented tasks.

  8. Overview of LogAgent for Log Collection

    master

    LogAgent is a TKEStack add-on that provides cluster-wide log collection. It replaces the older LogCollector component. Once enabled, it runs as a DaemonSet in the kube-system namespace to collect logs and send them to consumers like Kafka or Elasticsearch.

    Supported Collection Types:

    • Container Standard Output: Collects Stderr and Stdout from containers. Logs are output in JSON format with Kubernetes metadata (labels, annotations, etc.).
    • Container File Path: Collects logs from specific file paths inside a container. Logs are output in JSON format with Kubernetes metadata. Note: Files must be saved in a volume for collection to work.
    • Node File Path: Collects logs from specific paths on all cluster nodes. It tracks file offsets to ensure only incremental data is collected. Logs include the file path and user-defined metadata.

    Resource Usage (per node):

    • CPU: 0.3 cores
    • Memory: 250MB