DOCSEARCHbyAlgolia
Submit Docs

Nephio Automation Platform

repository·main·Indexed 41 days ago

https://github.com/nephio-project/nephio

A Kubernetes-based automation platform for deploying and managing distributed workloads, such as 5G Network Functions and their underlying infrastructure. Features include a GitHub client for managing repositories and installation tokens, an Approval controller for PackageRevision lifecycles, and controllers for bootstrapping packages and secrets onto remote clusters using Cluster API.

Tokens
103.8K
Snippets
255
Records
382
Agent score
51%

What's inside Nephio

  1. Overview of FOCOM SMO Service

    main

    The FOCOM SMO Service is a starting point implementation designed to reconcile FOCOM provisioning requests into ORAN provisioning requests.

    Reconciliation Logic:

    1. Template Validation: It verifies that the referenced TemplateInfo exists with the correct name and version. (Note: Template parameter validation is planned for future updates).
    2. OCloud Verification: It identifies the OCloudId in the request and ensures it exists.
    3. Remote Interaction: It reads a secret from the OCloud (currently containing a kubeconfig) to build a client and interact with the remote cluster to produce ORAN provisioning requests. Future versions plan to support a REST-like interface using an endpoint and bearer token.

    Key Components:

    • ORAN Provisioning CRD: Located in the oran-provisioning-crd folder.
    • FOCOM CRDs: Generated from Go structs in the api folder; YAML files are found in config/crd/bases.

  2. Overview of nf-deploy-fn

    main

    The nf-deploy-fn is a KRM (Kubernetes Resource Model) function that uses the cond sdk. It operates on the workload.nephio.org/v1alpha1.NFDeployment resource as its primary target (for resource).

    The function populates the NFDeployment specification by watching and consuming data from several other resources:

    • req.nephio.org/v1alpha1.Interface: Uses status.ipAllocationStatus and status.vlanAllocationStatus to populate spec.interfaces.
    • req.nephio.org/v1alpha1.DataNetwork: Uses status.pools.ipAllocation to populate spec.networkInstances.
    • req.nephio.org/v1alpha1.Capacity: Acts as the source of truth for capacity details in the NFDeployment spec.
    • req.nephio.org/v1alpha1.Dependency: Appends injected configurations to spec.parametersRefs for every dependency resource in the package.

    Note: The function is designed to be resilient; it will not panic or error if status fields are missing for any resource, instead generating the NFDeployment using only the available data.

  3. Overview of ipam-fn

    main

    The ipam-fn is a KRM (Kubernetes Resource Model) function built using the cond fn sdk. Its primary purpose is to claim IP addresses from an IP backend based on the specifications provided in an ipam.resource.nephio.org/v1alpha1.IPClaim resource.

    Key characteristics:

    • It is designed to work within a kpt pipeline without requiring porch.
    • For testing within kpt pipelines, a stub backend can be deployed.

  4. Overview of Flux CD configuration files

    main

    The Flux CD configuration for syncing FOCOM resources from Git to Kubernetes consists of the following key files:

    • focom-resources-gitrepository.yaml: Defines the Git source for the resources.
    • focom-resources-kustomization.yaml: Specifies which resources from the Git repository should be applied to the cluster.
    • focom-resources-receiver.yaml: (Optional) Configures the Webhook receiver for Git events.
    • kustomization.yaml: The Kustomize configuration used to manage the Flux resources.

  5. Overview of vlan-fn

    main

    The vlan-fn is a KRM (Kubernetes Resource Model) function built using the cond fn sdk. Its primary purpose is to claim VLANs from a VLAN backend by processing vlan.resource.nephio.org/v1alpha1.VLANClaim resources.

    Key characteristics:

    • It is designed to work within a kpt pipeline without requiring porch.
    • For testing within kpt pipelines, a stub backend can be deployed.

  6. Overview of kpt-argocd-cmp plugins

    main

    The kpt-argocd-cmp project provides two ArgoCD Config Management Plugins (CMPs) designed to enable the use of kpt pipelines within ArgoCD. Because ArgoCD lacks built-in support for kpt package pipelines, these plugins allow for the proper rendering of Kubernetes objects, handling both the creation of package applications and the management of local configurations.

    The two core plugins are:

    1. kpt-repo: Implements an "app-of-apps" pattern to discover and create ArgoCD Applications from Kptfiles within a source repository.
    2. kpt-render: A rendering plugin used by applications created by kpt-repo. It filters out KRM files annotated with config.kubernetes.io/local-config: "true" or Kustomize files to prevent ArgoCD from attempting to install local configuration manifests into the destination cluster.

  7. FOCOM Operator Documentation Overview

    main

    The FOCOM (Fabric O-Cloud Manager) Operator documentation is organized into several key areas:

    • Getting Started: Includes a 10-minute QUICK_START.md and detailed DEPLOYMENT.md covering ConfigSync, kpt, kubectl, and Flux CD.
    • Configuration: Specific setup instructions for Porch in PORCH_SETUP.md.
    • Architecture & Design: Detailed system architecture, resource models, and user workflows in ARCHITECTURE.md and USER_GUIDE.md (which covers the FOCOM NBI API).
    • Testing & Operations: Guides for testing (TESTING.md) and troubleshooting (TROUBLESHOOTING.md).
    • API Reference: OpenAPI specifications are available in ../api/openapi/focom-nbi-api.yaml.

  8. What is the nad-fn KRM function?

    main

    The nad-fn (Network Attachment Definition function) is a KRM function designed for Nephio NF kpt packages.

    Its primary purpose is to scan a package for IPClaim, VLANClaim, WorkloadCluster, and Interface resources and expand them into NetworkAttachmentDefinition (NAD) resources. These NAD resources are used by Container Network Interface (CNI) plugins like Multus to configure networking.

    As part of the "Condition choreography," the function also adds Conditions to the Status of the Kptfile object to indicate the fulfillment status of the NetworkAttachmentDefinition requests.

  10. Design principles of the KRM functions library

    main

    The KRM functions library is designed to facilitate CRUD operations on KRM (Kubernetes Resource Model) resources within Nephio packages. It is intended to be used by functions and controllers that perform specialization tasks, such as claiming IPs/VLANs or actuating specific resource attributes.

    Key design requirements include:

    • Comment Preservation: Comments MUST be retained when updating KRM resource content.
    • Resource Generation: Ability to generate new KRM resources within a package.
    • Actuation: Ability to update existing KRM resources with newly obtained parameters.
    • Attribute Access: Ability to read any attribute of a KRM resource in the package.
    • Type Safety: The library must provide type-safe operations.
    • Validation: New inputs must be validated before being applied to KRM object attributes.

  11. Correct removal order for FOCOM Operator undeployment

    main

    When undeploying the FOCOM Operator, you must follow a specific order to prevent orphaned Custom Resources (CRs) and stuck finalizers.

    Critical Rule: Always remove ConfigSync BEFORE the operator.

    If you remove the operator (via kpt live destroy) first, the Custom Resource Definitions (CRDs) are deleted while the Custom Resources (CRs) still exist. This leaves the CRs orphaned because ConfigSync can no longer use the CRDs to clean them up, often resulting in CRs stuck in a Terminating state.

    Correct Workflow:

    1. Remove ConfigSync resources (e.g., RootSync).
    2. Wait for ConfigSync to clean up managed CRs.
    3. Remove the operator and CRDs using kpt live destroy.
    ```bash
# DO THIS
kubectl delete -k config/configsync  # ConfigSync removes CRs it manages
sleep 10  # Wait for cleanup
kpt live destroy  # Then remove operator and CRDs
```埋

  12. Known limitations of the FOCOM Operator

    main

    Be aware of the following constraints when using the FOCOM operator:

    • CR Creation Delay: Custom Resources (CRs) are not created immediately; they are created within the ConfigSync poll interval (up to 15 seconds).
    • Async Errors: Sync errors are not returned in the API response. You must check the RootSync status to identify synchronization issues.
    • No Webhook Notifications: The system cannot send notifications when ConfigSync creates CRs.
    • Single Repository: Each operator instance currently supports only one Git repository.
    • No Caching: All operations interact directly with the Kubernetes API; there is no local caching mechanism.