mirror of https://github.com/crossplane/docs.git
73 lines
3.6 KiB
Markdown
73 lines
3.6 KiB
Markdown
---
|
|
title: Concepts
|
|
weight: 50
|
|
description: Understand Crossplane's core components
|
|
---
|
|
|
|
Crossplane extends Kubernetes allowing it to create and manage
|
|
resources external to the Kubernetes cluster. Crossplane enables platform
|
|
engineers to create custom APIs and abstractions combining both native
|
|
Kubernetes resources and cloud resources under a single control plane.
|
|
|
|
With custom APIs, the platform users, like developers, don't need to know
|
|
any details about the underlying resources or requirements.
|
|
|
|
The platform users only need to know the details exposed by the platform, like
|
|
`big` or `small` or `US` or `EU`. Platform users don't need to know any details
|
|
about the underlying provider like instance type or region names.
|
|
|
|
Crossplane uses multiple core components to manage the various elements of
|
|
building and managing external resources through Kubernetes.
|
|
|
|
* [**The Crossplane pods**]({{<ref "./pods">}}) include the core Crossplane pod and
|
|
Crossplane RBAC manager pod. Together these pods manage all Crossplane
|
|
components and resources.
|
|
|
|
* [**Providers**]({{<ref "./providers">}}) connect Kubernetes to any external
|
|
provider, like AWS, Azure or GCP. Providers translate Kubernetes native
|
|
manifests and API calls into external API calls. Providers are responsible for
|
|
creating, deleting and managing the lifecycle of their resources.
|
|
|
|
* [**Managed resources**]({{<ref "./managed-resources">}}) are Kubernetes objects
|
|
representing things the Provider created outside of Kubernetes. Creating a
|
|
managed resource in Kubernetes requires a Provider to create a resource.
|
|
Deleting a managed resource requires a Provider to delete the associated
|
|
external resource.
|
|
|
|
* [**Compositions**]({{<ref "./compositions">}}) are a template of managed
|
|
resources. Compositions describe more complex deployments, combining multiple
|
|
managed resources and any resource customizations, like the size of a database
|
|
or the cloud provider region.
|
|
|
|
* [**Composite Resource Definitions**]({{<ref "./composite-resource-definitions">}})
|
|
represent a custom API, created by platform engineers and consumed by
|
|
developers or end users. Composite resource definitions use an OpenAPIv3
|
|
schema to further extend Kubernetes with custom API endpoints, revisions and
|
|
more.
|
|
|
|
* [**Composite Resources**]({{<ref "./composite-resources">}}) represent all the
|
|
objects created by a user calling the custom API. Every time a user access the
|
|
custom API Crossplane creates a single Composite Resource and links all
|
|
the related managed resources to it.
|
|
|
|
* [**Claims**]({{<ref "./claims">}}) are like Composite Resources, but exist
|
|
in a Kubernetes namespace. Every Claim links to a single cluster scoped
|
|
Composite Resource. Platform users create Claims in their unique namespace,
|
|
isolating their resources from other teams in other namespaces.
|
|
|
|
* [**EnvironmentConfigs**]({{<ref "./environment-configs">}}) are an in-memory
|
|
data store, like a Kubernetes ConfigMap. EnvironmentConfigs are useful for
|
|
custom resource mapping or storing and retrieving data across Claims and
|
|
Composite Resources.
|
|
|
|
* [**Usages**]({{<ref "./usages">}}) defining critical resources or custom
|
|
dependency mappings. Usages can prevent Crossplane from deleting or can
|
|
ensure that a parent resource waits for Crossplane to delete all child
|
|
resources first.
|
|
|
|
* [**Packages**]({{<ref "./packages">}}) are a convenient way to package up an
|
|
entire custom platform and define any other Crossplane related requirements.
|
|
Packages define how to install Providers, custom APIs or composition functions.
|
|
|
|
* [**ImageConfigs**]({{<ref "./image-configs">}}) are for centralized control
|
|
of the configuration of Crossplane package images. |