mirror of https://github.com/crossplane/docs.git
docs snapshot for crossplane version `master`
This commit is contained in:
parent
dfecc41db7
commit
2f245b2901
|
|
@ -43,64 +43,21 @@ With Crossplane you can:
|
||||||
* Deploy application configurations from app delivery pipelines or GitOps
|
* Deploy application configurations from app delivery pipelines or GitOps
|
||||||
workflows, using the proven Kubernetes declarative model.
|
workflows, using the proven Kubernetes declarative model.
|
||||||
|
|
||||||
## Getting Started
|
Separation of concerns is core to Crossplane’s approach to infrastructure and
|
||||||
[Install Crossplane] into any Kubernetes cluster to get started.
|
application management, so team members can deliver value by focusing on what
|
||||||
|
they know best. Crossplane's team-centric approach reflects individuals often
|
||||||
|
specializing in the following roles:
|
||||||
|
|
||||||
## Mission
|
* **Infrastructure Operators** - provide infrastructure and services for apps
|
||||||
|
|
||||||
Crossplane strives to be the best Kubernetes add-on to provision and manage the
|
|
||||||
infrastructure and services your applications need directly from kubectl. A
|
|
||||||
huge part of this mission is arriving at an elegant, flexible way to define,
|
|
||||||
compose, and publish your own infrastructure resources to the Kubernetes API
|
|
||||||
and to model and manage cloud native applications.
|
|
||||||
|
|
||||||
The path of cloud native apps from developer laptop into production requires
|
|
||||||
collaboration across teams to build the app itself, deploy and manage the app
|
|
||||||
and it’s infrastructure, and publishing infrastructure resources that embody
|
|
||||||
organizational best practices and security policies.
|
|
||||||
|
|
||||||
Today, multiple tools and management models must be glued together in
|
|
||||||
deployment pipelines that are often fragile and error prone. Teams can find it
|
|
||||||
difficult to collaborate in an effective way when aspects of an application are
|
|
||||||
blurred, resulting in a lack of clear ownership and conflicts integrating
|
|
||||||
changes. Requiring team members to master multiple tools, languages, and
|
|
||||||
philosophies, while understanding the interactions and failure modes between
|
|
||||||
them can significantly impede an organization’s ability to deliver applications
|
|
||||||
efficiently.
|
|
||||||
|
|
||||||
Crossplane believes that a team-centric approach with a strong separation of
|
|
||||||
concerns combined with the proven Kubernetes declarative model is the best way
|
|
||||||
to provision and manage infrastructure and cloud native applications. Teams
|
|
||||||
should be able to publish infrastructure resources for applications to consume,
|
|
||||||
define application components independent of infrastructure, and compose both
|
|
||||||
into complete application configurations -- all using declarative YAML that can
|
|
||||||
be deployed with kubectl from app delivery pipelines or with GitOps workflows.
|
|
||||||
|
|
||||||
This team-centric approach reflects individuals often specializing in the
|
|
||||||
following roles:
|
|
||||||
|
|
||||||
* **Infrastructure Operators** - provide infrastructure and services for apps
|
|
||||||
to consume
|
to consume
|
||||||
* **Application Developers** - build application components independent of
|
* **Application Developers** - build application components independent of
|
||||||
infrastructure
|
infrastructure
|
||||||
* **Application Operators** - compose, deploy, and run application
|
* **Application Operators** - compose, deploy, and run application
|
||||||
configurations
|
configurations
|
||||||
|
|
||||||
This separation of concerns is core to Crossplane’s approach to infrastructure
|
## Getting Started
|
||||||
and application management, so team members can deliver value by focusing on
|
|
||||||
what they know best.
|
|
||||||
|
|
||||||
With Crossplane, infrastructure operators can define custom infrastructure
|
[Install Crossplane] into any Kubernetes cluster to get started.
|
||||||
resources with declarative YAML and publish them for applications to consume
|
|
||||||
as Kubernetes custom resources or with any tool that works with the Kubernetes
|
|
||||||
API. These infrastructure resources can be used with existing Kubernetes
|
|
||||||
applications (Deployments, Services) and with application definition models
|
|
||||||
like OAM.
|
|
||||||
|
|
||||||
The result is a consistent, integrated, and modular approach to managing
|
|
||||||
infrastructure and application configurations, that can be deployed with the
|
|
||||||
same tooling including kubectl, GitOps, and anything can talk with the
|
|
||||||
Kubernetes API.
|
|
||||||
|
|
||||||
<!-- Named Links -->
|
<!-- Named Links -->
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue