DOCSEARCHbyAlgolia
Submit Docs

OpenYurt Documentation

repository·master·Indexed 24 days ago

https://github.com/openyurtio/openyurt

A CNCF incubating project that extends Kubernetes for edge computing using a cloud-edge architecture. It features core components including yurt-manager for controller and webhook management, YurtHub for node autonomy and APIServer object caching, Raven-Agent for edge communication, and yurt-iot-dock for EdgeX Foundry integration and IoT device management.

Tokens
70.6K
Snippets
83
Records
347
Agent score
80%

What's inside OpenYurt

  1. Overview of OpenYurt Charts components

    master

    OpenYurt Charts provides Helm charts for three core OpenYurt components:

    • yurt-manager: The central management component for OpenYurt.
    • yurthub: The communication hub for edge nodes.
    • yurt-iot-dock: The IoT docking component for edge device connectivity.

  2. Overview of yurt-manager

    master

    The yurt-manager is a component designed to manage all controllers and webhooks within OpenYurt. It provides a framework that reduces development complexity by automating several repetitive tasks when adding new Custom Resource Definitions (CRDs).

    Key features of the yurt-manager framework include:

    • CRD definition management
    • Controller logic implementation
    • Webhook logic implementation
    • Automatic issuance of webhook certificates
    • Helm chart generation
    • Client-API generation

  3. What is OpenYurt

    master

    OpenYurt is a CNCF incubating project built on top of upstream Kubernetes, designed to meet DevOps requirements for typical edge infrastructure. It provides a consistent user experience for managing edge applications, similar to centralized cloud computing.

    OpenYurt addresses key challenges in cloud-edge integrated scenarios, including:

    • Unreliable or disconnected cloud-edge networks
    • Edge node autonomy
    • Edge device management
    • Cross-region business deployment

    It maintains full compatibility with the Kubernetes API and is vendor-neutral.

  4. Goals of the Edge Load Balancing Implementation

    master

    The edge load balancing implementation aims to achieve the following:

    • Edge LB Controllers: Design controllers to monitor and distribute Virtual IPs (VIPs).
    • Nodepool-level VIP Management: Enable the management of VIPs at the level of the nodepool rather than individual nodes.
    • Keepalived-based HA: Implement VIP generation and service high availability using Keepalived.
    • IPVS Traffic Forwarding: Use the ipvs module to implement a round-robin traffic forwarding strategy.

  5. Core goals of the YurtAppOverrider rendering engine

    master

    The YurtAppOverrider implementation aims to achieve the following:

    1. Customize workloads in different regions: Handle heterogeneous environment requirements (resource configs, network topologies).
    2. Implement Gray Release: Facilitate controlled, phased deployments.
    3. Specify image registries: Adapt to edge network environments by allowing region-specific registry configurations.

  6. Goals of the Edgex Auto-collector

    master

    The Edgex Auto-collector aims to achieve the following:

    • Design a standardized YAML structure for EdgeX component configuration.
    • Implement a tool to automatically collect EdgeX information and periodically synchronize/update YAML configurations.
    • Implement a tool to collect EdgeX version and image information and push it to the OpenYurt repository.
    • Provide user permissions to customize EdgeX configurations.
    • Add a security switch within the EdgeX field.
    • Automatically collect configurations specifically for the arm architecture.

  7. What is YurtHub and how does it work?

    master

    YurtHub is a node daemon designed to support node autonomy at the edge. It functions by caching the states of necessary APIServer objects in local storage whenever cluster-edge networking is established.

    When an edge node goes offline, YurtHub ensures that all registered components can still access these cached APIServer object states, effectively allowing them to interact with the APIServer as if it were still reachable.

  8. What is OpenYurt and its core architecture

    master

    OpenYurt is a CNCF Incubating project built on top of upstream Kubernetes, designed for cloud-edge orchestration. It provides a consistent user experience for managing edge applications as if they were running in a standard cloud environment, specifically addressing challenges like unreliable networking, edge autonomy, and region-aware deployment.

    Architecture Model

    OpenYurt uses a cloud-edge architecture:

    • Cloud Site: Hosts a centralized Kubernetes control plane.
    • Edge Sites: Host multiple edge nodes. These nodes can span multiple physical regions, which OpenYurt refers to as Pools.

    Core Components

    • YurtHub: A static pod running on worker nodes as a node sidecar. It intercepts requests from local components (like Kubelet or KubeProxy) intended for the kube-apiserver.
    • Yurt-Manager: Contains all controllers and webhooks specifically designed for edge operations.
    • Raven-Agent: Manages edge-to-edge and edge-to-cloud communication. It provides Layer 3 network connectivity between pods in different regions and Layer 7 reverse proxying for native Kubernetes commands like kubectl exec and kubectl logs (replacing Yurt-Tunnel).
    • YurtIoTDock: Deployed in every edge NodePool to bridge the EdgeX Foundry platform and manage edge devices via Kubernetes CRDs.
    • Node resource manager: An auxiliary controller for managing additional edge resources like LVM, QuotaPath, and Persistent Memory.

  9. Overview of Yurt-Express data transmission system

    master

    Yurt-Express is an OpenYurt data transmission system designed to solve edge-to-cloud data upload challenges, specifically in environments with weak or unidirectional networks, limited bandwidth, or high connection counts. It provides a data tunnel that supports:

    • Data encryption
    • Wave delivery (batching data based on timeliness)
    • Data compression
    • Resuming broken transfers

    Architecture Components

    • yurt-express-agent: Deployed per node pool using YurtAppSet at the edge.
    • yurt-express-server: Deployed in the cloud using a Kubernetes Deployment.
    • Redis (Optional): Deployed in the cloud to facilitate synchronization when using yurt-iot-dock.

  10. Overview of Raven networking enhancement

    master
    Raven is a networking project for OpenYurt designed to enhance cluster networking capabilities, specifically focusing on edge-edge and edge-cloud communication. It provides Layer 3 network connectivity among pods in different physical regions, allowing them to communicate using pod IP, service IP, or service domain names, mimicking the behavior of a vanilla Kubernetes cluster. This solution is intended to replace YurtTunnel for broader networking needs.

  11. Overview of the Edgex Auto-collector Proposal

    master

    The Edgex Auto-collector is a proposed mechanism to automate the collection and synchronization of EdgeX Foundry component information into a standardized YAML format. This automation is intended to improve the adaptation capabilities of yurt-edgex-manager (which is planned to be integrated into yurt-iot-manager).

    Key functions include:

    • Automated Synchronization: Periodically collecting EdgeX component configurations and updating YAML files to support new versions without manual intervention.
    • Image Management: Automatically collecting EdgeX version and image information, pulling them, and pushing them to the OpenYurt repository.
    • Standardized Configuration: Using a standardized YAML structure to define EdgeX components, which yurt-edgex-manager then uses for deployment.
    • User Customization: Providing permissions for users to modify specific EdgeX component configurations.

  12. What is YurtAppOverrider?

    master

    YurtAppOverrider is a Custom Resource Definition (CRD) designed to serve as a configuration rendering engine for multi-region workloads. It allows users to customize the configuration of workloads managed by YurtAppSet or YurtAppDaemon on a per-nodepool basis.

    It provides a mechanism to override fields in workloads (such as Deployment or StatefulSet) to account for heterogeneous environments, such as differences in resource configurations, network topologies, or image registries across different geographic regions.