DOCSEARCHbyAlgolia
Submit Docs

kcp

repository·main·Indexed 25 days ago

https://github.com/kcp-dev/kcp

A Kubernetes-like control plane designed to manage isolated, multi-tenant workspaces, allowing service providers to offer Kubernetes-native APIs centrally to numerous tenants. It includes tools for CRD compatibility checking, APIExport and APIBinding for cross-workspace validation via admission webhooks, and support for OIDC authentication using Dex.

Tokens
81.3K
Snippets
143
Records
386
Agent score
83%

What's inside kcp

  2. Overview of kcp

    main

    kcp is a Kubernetes-like control plane designed for massively multi-tenant platforms. It provides a central control plane for many independent, isolated "clusters" called workspaces.

    Key capabilities include:

    • Centralized API Offering: API service providers can offer APIs centrally using multi-tenant operators.
    • Isolated Workspaces: Users consume APIs within their own isolated workspaces.
    • Advanced Deployment: Supports complex deployment strategies such as affinity/anti-affinity, geographic replication, and cross-cloud replication.

    kcp is intended for SaaS providers needing to offer services to large numbers of isolated tenants using Kubernetes-native APIs, as well as for enterprise IT departments.

  3. Understand Virtual Workspaces

    main

    Virtual workspaces act as proxy-like apiservers hosted under custom URLs. They provide a computed, aggregated, or filtered view of real workspaces.

    Key characteristics:

    • Access Control: They allow controllers to access specific objects across multiple workspaces without having direct access to the underlying customer workspaces. This is useful for implementing cross-workspace data access using a single service account.
    • Mutability: Virtual workspaces can be read-only or writable (e.g., controller view and syncer virtual workspaces are writable).
    • Discovery: Developers discover virtual workspace URLs by inspecting the status field of specific API objects, such as APIExport.status or WorkspaceType.status.
    • Scalability: As sharding is introduced, a single controller may need to watch multiple virtual workspace URLs provided in a list within an object's status.

  4. Understand Logical Clusters

    main

    A Logical Cluster is a subdivision of a kcp server and its etcd datastore. It allows for creating a large number of isolated clusters with near-zero memory and storage overhead (similar to a Kubernetes namespace).

    Key features:

    • Isolation: Each logical cluster has its own set of installed APIs, objects, and RBAC policies.
    • Identifier Enrichment: Objects are identified in etcd using an enriched identifier: (group, version, resource, logical cluster name, optional namespace, name).
    • Interface: They provide Kubernetes-cluster-like HTTPS/CRUD endpoints. A user can run kubectl get <resource> -A within a specific logical cluster.
    • Creation: While they can be created directly, they are typically provisioned via the Workspace abstraction.

  5. Understand the kcp server architecture

    main

    The kcp server is a Kubernetes-like API server designed for multi-tenancy. It extends the Kubernetes API to provide capabilities for building platforms.

    Key characteristics:

    • Resource Model: It provides resources like LogicalCluster, Workspace, APIBinding, and APIExport on top of core Kubernetes resources (e.g., ConfigMap, Secret). It does not manage workloads like Pods or Deployments.
    • API Semantics: It follows Kubernetes API semantics. To define custom resources usable across different logical clusters, use the APIResourceSchema resource instead of standard Kubernetes CustomResourceDefinition (CRD).
    • Tooling Compatibility: You can access the kcp server and its logical clusters using standard Kubernetes tools like kubectl and client-go via appropriate kubeconfig files.
    • Controller Note: Standard Kubernetes controller-runtime does not support reconciling objects across multiple logical clusters. For multi-cluster reconciliation, use the kcp-specific fork of controller-runtime.

  6. Understand Logical Clusters in kcp

    main
    kcp supports up to 1 million logical clusters. A logical cluster acts as a Kubernetes endpoint, meaning standard Kubernetes client tooling (such as client-go, controller-runtime) and user interfaces (such as kubectl, helm, or web consoles) can interact with it exactly like a regular Kubernetes cluster. Logical clusters are designed to be efficient in terms of storage and compute while providing isolation.

  7. Understand kcp Authorization mechanisms

    main

    kcp uses an RBAC-based (Role-Based Access Control) authorization mechanism within workspaces, following the same principles as Kubernetes. It uses (cluster) roles and (cluster) role bindings. Note that ABAC (Attribute-Based Access Control) is not supported.

    Beyond standard Kubernetes RBAC, kcp implements additional cross-workspace semantics:

    • Workspace Content Access: To access content within a workspace, a user must have access permissions for that workspace or hold an admin role.
    • Workspace Creation: Creating a workspace requires membership in the relevant organization and the use verb on the WorkspaceType resource.
    • API Binding: When using APIBinding objects, the user must have the bind verb access to the corresponding APIExport resource.
    • System Workspaces: Workspaces prefixed with system: are reserved for system use and are not accessible by users.

  8. Understand kcp Workspace Types

    main

    Workspace types define which sub-workspace types can be created under them. Common types include:

    • universal: The base workspace type that most others inherit from. They can contain other universal workspaces and have a "default" namespace.
    • root: Primarily contains organization workspaces.
    • organization: Can contain universal workspaces or be subdivided into team workspaces.

    Workspace behaviors are defined by the WorkspaceType resource. You can list available types using:

    kubectl get workspacetypes

  9. Understand CachedResources and CachedObject replication

    main

    The CachedResources controller replicates objects from a configured GroupVersionKind (GVK) into a cache server. To perform this replication, the controller wraps the original object into a CachedObject resource.

    When an object is replicated, its name in the cache server is derived from its original GroupVersionResource (GVR). For example, an Instance object with name web-server-1 in machines.svm.io/v1alpha1 is replicated as a CachedObject named v1alpha1.instances.machines.svm.io.web-server-1.

    Replicated objects are identified and filtered using specific labels:

    apiVersion: cache.kcp.io/v1alpha1
Kind: CachedObject
metadata:
  name: v1alpha1.instances.machines.svm.io.web-server-1
  labels:
    cache.kcp.io/object-schema: v1alpha1.instances.machines.svm.io
    cache.kcp.io/object-group: machines.svm.io
    cache.kcp.io/object-version: v1alpha1
    cache.kcp.io/object-resource: instances
    cache.kcp.io/object-original-name: web-server-1
    cache.kcp.io/object-original-namespace: <empty>

  10. Understand the kcp core concept and purpose

    main

    kcp is a cloud-native control plane for APIs designed to resemble IaaS/PaaS/SaaS patterns. It provides a unified platform and resource model to deliver arbitrary services.

    Key characteristics:

    • Foundational Technology: It is intended to be built upon to create SaaS platforms, Internal Developer Platforms (IdP), or multi-cluster scheduling solutions.
    • Declarative Data Store: It provides a Kubernetes-like control plane that services scenarios benefiting from a declarative data store.
    • Decoupling Intent from State: It uses Kubernetes APIs to separate user intent from actual state, allowing for better resiliency and workload isolation across multiple clusters.

    Note: Efforts regarding a transparent multi-cluster (TMC) solution are currently on hold.

  11. Use the Front Proxy for Request Routing

    main

    A front-proxy acts as an entry point that is aware of all logical clusters, their shards, canonical paths, and Workspaces.

    • Routing: Requests to /cluster/<path> are forwarded to the appropriate shard via inverse proxying.
    • Scalability: You can deploy a single front-proxy or multiple front-proxies (e.g., per region or cloud provider) to handle a kcp installation.

  12. Understand the scope of kcp built-in APIs

    main

    kcp provides a subset of Kubernetes APIs focused on control plane and multi-tenancy management. It includes core resource management, admission control, authentication, authorization, and RBAC.

    Important: kcp does not include workload-related APIs (e.g., Pods, Deployments, Jobs, StatefulSets), cluster-related APIs (e.g., Nodes), or storage-related APIs (e.g., PersistentVolumes, PVCs). These functionalities must be provided by the workload clusters connected to kcp.