Sealos Cloud Operating System

repository·main·Indexed 12 days ago

https://github.com/labring/sealos

An AI-native Cloud Operating System built on Kubernetes designed to unify the entire application lifecycle, from cloud-based development to production deployment and scaling. Includes documentation for deploying and configuring the Account Controller, App Controller, and Job-Heartbeat Controller using the `sealos run` command and Helm.

Tokens
197.9K
Snippets
627
Records
816
Agent score
96%

What's inside Sealos

  1. Overview of Sealos core features

    main

    Sealos is an AI-native Cloud Operating System built on Kubernetes that unifies the application lifecycle. Key capabilities include:

    • Integrated Cloud IDEs: Zero-setup development via DevBox.
    • Managed Databases & Storage: Support for PostgreSQL, MySQL, MongoDB, Redis, and S3-compatible Object Storage.
    • Extensive App Store: One-click deployment of complex applications without manual YAML configuration.
    • Full Kubernetes Power: K8s-native infrastructure accessible without high complexity.
    • Enterprise Multi-Tenancy: Workspace-based isolation with granular RBAC and per-workspace resource quotas.
    • AI-Native Infrastructure: Ability to build and scale AI applications by describing requirements.
  2. Overview of Sealos Cloud Terminal

    main
    Sealos Cloud Terminal is a terminal management tool built on Kubernetes. It allows you to deploy a terminal management service within a Kubernetes cluster. Users can access this service via a web browser to open a terminal session, which provides direct access to the Kubernetes API server.
  3. What is Sealos?

    main

    Sealos is a cloud operating system distribution with a Kubernetes kernel. Unlike traditional cloud architectures, Sealos uses a cloud-native approach where Kubernetes serves as the cloud kernel, allowing enterprises to use cloud resources as simply as using a personal computer.

    Key features include:

    • App Management: Easily manage and quickly publish distributed applications that are accessible via the public internet using a template market.
    • Database Management: Create high-availability databases in seconds, supporting MySQL, PostgreSQL, MongoDB, and Redis.
    • Public/Private Consistency: Supports seamless migration of traditional applications to the cloud, functioning as both a public and private cloud.
  4. Overview of LVScare

    main

    LVScare is a lightweight LVS (Linux Virtual Server) management tool designed for health checking. It is primarily used by Sealos to maintain High Availability (HA) for Kubernetes masters.

    Core Behavior: When a real server (RS) becomes unavailable, LVScare first sets its weight to 0 (to allow for TCP graceful termination) and then removes it from the backends during the next health check. Once the server becomes available again, LVScare adds it back to the pool.

  5. Overview of Sealos CostCenter features

    main

    Sealos CostCenter is a cost management center for the Sealos cloud operating system. It provides the following capabilities:

    • Cost monitoring and analysis: Track and analyze cloud spending.
    • Multi-payment support: Integration with WeChat, Alipay, and Stripe.
    • Resource billing: Granular billing for CPU, Memory, Storage, Network, and GPU resources.
    • Multi-currency support: Support for ShellCoin, CNY, and USD.
  6. Understand the Sealos App Launchpad project structure

    main

    The Sealos App Launchpad is a frontend project built with Next.js. Key directories include:

    • src/pages: Defines the application routes.
      • src/pages/app/detail: The application detail page.
      • src/pages/app/edit: The page for creating and editing applications.
      • src/pages/apps: The application list page.
      • src/pages/api: Server-side API routes.
    • src/services: Contains core logic for interacting with the backend, including auth.ts, kubernetes.ts, and request handling (request.ts, streamFetch.ts).
    • src/components: Reusable UI components.
    • src/hooks: Custom React hooks.
    • src/store: State management.
    • data/: Contains optional configuration files like form_slider_config.json.
  7. Overview of Sealos Boot components

    main

    Sealos Boot consists of several core components for managing clusters and container runtimes:

    • Sealos Container: The core component responsible for deploying and managing Kubernetes clusters and distributed applications. It includes various CLI tools.
    • lvscare Container: Supports load balancing management within Kubernetes clusters by monitoring node status in real-time to ensure traffic is routed to available nodes.
    • sealctl Binary: A command-line tool used to simplify cluster management tasks such as certificate management, IPVS, and host management.
    • image-cri-shim Binary: A CRI (Container Runtime Interface) adapter that allows Sealos to integrate with different runtimes like Docker and containerd.
  8. Overview of Sealos Cloud services

    main

    Sealos Cloud provides a suite of services for managing cloud-native applications. The main components include:

    • Auth-Service: Authentication via Casdoor.
    • Image Hub: Image repository management.
    • Desktop: The public cloud frontend user interface.
    • User: User and user group permission management.
    • Account & Metering: Billing and cost control.
    • App: Desktop application for managing cloud services.
    • Infra: Basic settings (supports AWS and Alibaba Cloud).
    • Cluster: One-click cluster startup.
    • Terminal: Terminal services for cloud service access.
  9. What is VictoriaMetrics in Sealos?

    main

    Sealos utilizes VictoriaMetrics for data collection instead of standard Prometheus. This is done to prevent performance degradation or abnormal behavior that can occur when Prometheus handles excessive data sizes.

    By default, the system uses kb-prometheus-server for the data collection service.

  10. Overview of Sealos Cloud components

    main

    Sealos Cloud's architecture is divided into several functional services:

    • Auth-Service: Handles authentication via Casdoor.
    • Image Hub: Manages image repositories.
    • Desktop: The public cloud frontend interface.
    • User: Manages users and user group permissions.
    • Account & Metering: Handles billing and cost control.
    • App: The desktop application for managing cloud services.
    • Infra: Manages basic settings (supports AWS and Alibaba Cloud).
    • Cluster: Enables one-click cluster startup.
    • Terminal: Provides terminal access to cloud services.
  11. What is image-cri-shim and how does it work?

    main

    image-cri-shim is a binary proxy service deployed on every Kubernetes node. It acts as a middleware between the kubelet and the container runtime (like containerd), intercepting and transforming image requests.

    Core Functionalities

    • Intelligent Image Name Processing: Intercepts and transforms kubelet image requests.
    • Multi-Registry Unified Authentication: Manages authentication across multiple image registries.
    • Dynamic Configuration Loading: (Available in v5.1.0-rc3+) Supports hot-reloading configuration via Kubernetes ConfigMaps without service restarts.

    Deployment Architecture

    To function correctly, the service must follow a specific startup and network order:

    Startup Order: containerdimage-cri-shimkubelet

    Network Flow: kubeletimage-cri-shimcontainerdImage Registry

  12. Understand the image-cri-shim ConfigMap merging strategy

    main

    When image-cri-shim synchronizes the ConfigMap with the local configuration file, it uses different strategies depending on the field:

    Configuration ItemIf ConfigMap is NOT setIf ConfigMap IS set
    sealos.addressRetain local valueUse ConfigMap value
    sealos.authRetain local valueUse ConfigMap value
    registriesRetain local valueREPLACE local value
    debugRetain local valueUse ConfigMap value
    timeoutRetain local valueUse ConfigMap value
    reloadIntervalRetain local valueUse ConfigMap value
    cache.*Retain local valueUse ConfigMap value

    CRITICAL: The registries field performs a complete replacement, not a merge. If you only define one registry in the ConfigMap, all other registries defined in the local configuration will be lost. You must include all desired registries in the ConfigMap to maintain them.