[cncf-toc] Continued InfraKit Discussion
david.chung at docker.com
Tue Jun 6 23:14:46 UTC 2017
Thanks for starting the thread. In a nutshell, InfraKit focuses on being
lightweight and embeddable while enabling self-management and capacity
scaling features for the entire, higher-level system. There are also
differences in terms of state management and deployment when compared to
these larger, established tools. Brief summaries of how InfraKit compares
to Terraform, BOSH and Digital Rebar are included here. Feedback, comments
and questions are most welcome.
InfraKit vs Terraform
Terraform and InfraKit share the features of declarative infrastructure.
Terraform can provision infrastructure resources and reconcile differences
between infrastructure and user specification. InfraKit builds on the same
concepts and adds continuously running microservices or controllers, so
that the reconciliation is continuous rather than on-demand. InfraKit also
provides features such as node scaling group so that cluster capacity
scaling can be triggered directly from higher-level orchestration systems.
In this use case, InfraKit and terraform can be complementary, with
terraform being the ‘execution backend’ for InfraKit. As an example, there
is a terraform plugin in the project which can be leveraged to provision
resource types currently not natively supported by InfraKit.
Terraform and InfraKit differ in terms of state management and deployment.
InfraKit can leverage the system it is embedded into, such as Docker Swarm
or etcd, for leader election and persistence of user specs. Unlike
Terraform which has its own schema and different backend plugins for
storing infrastructure state, InfraKit derives the infrastructure state via
introspection and queries supported by the lower-level platform (tags and
metadata). The infrastructure itself is the master of records, rather than
a representation of it which can be corrupted or go out of sync. InfraKit
can be a part of the control plane of a higher-level orchestration system
without additional resource requirements. In this use case, InfraKit also
readily integrates with the higher level system as service containers,
while Terraform is primarily a CLI tool for ops and not meant to be run as
a service for higher level systems.
InfraKit is designed as an active system continuously monitoring your
infrastructure and reconciling its reality with a specification provided
either by a user or a higher level orchestration system, with an immutable
infrastructure approach, while Terraform is designed as a tool to automate
existing ops workflows using a declarative description of infrastructure,
without the active monitoring and reconciliation approach.
InfraKit vs BOSH
BOSH is much more vertically integrated than InfraKit in that it is itself
a full-fledged distributed application with its own datastore (Postgres)
and server components. In terms of workflow, BOSH also covers areas
outside of infrastructure provisioning and management -- it has opinionated
workflows for application definition and software releases which reaches
into the upper layers of the CNCF model. The full system serves as part of
control plane of a much larger platform and thus requires its own
provisioning and management.
InfraKit takes a lighter weight approach. As a set of pluggable
microservices, it is meant to be embedded into a larger system to minimize
additional operational burdens. With InfraKit embedded in the same control
plane, these systems can self-install and self-manage. InfraKit also does
not require a database such as Postgres to store state. Instead, InfraKit
inspects the infrastructure and reconstructs what is in the environment for
reconciliation with user specification. This means the only thing that can
diverge from user spec is the true infrastructure state. If divergence is
detected, InfraKit will attempt to correct it. InfraKit also can play the
role of a cloud-provider for a node group autoscaler for a container
orchestrator like k8s or Docker Swarm, thereby bringing the elasticity
common in the public cloud to on-prem bare-metal or virtualized
InfraKit vs Digital Rebar
Digital Rebar compares similarly to RackHD <https://rackhd.github.io/> or
MaaS <https://maas.io/>. Currently there is community integration with
RackHD <https://github.com/codedellemc/infrakit.rackhd>, and there is a
MaaS plugin in the InfraKit repo. At a high-level, Digital Rebar and
InfraKit are complementary in that InfraKit can leverage Digital Rebar for
bare-metal provisioning via DR’s PXE/DHCP/TFTP infrastructure, while
InfraKit provides the orchestration capabilities such as scaling up/down
clusters and rolling updates.
Digital Rebar is itself a full-fledged distributed application of many
components, including a Postgres database where it stores infrastructure
state. In terms of deployment, it has its own control plane that needs to
be provisioned and maintained. InfraKit can be embedded inside the control
plane of a higher-level orchestration system such as Kubernetes and Docker
Swarm. InfraKit leverages these systems for persistence of user
infrastructure specification and for leader election (to provide high
availability), and infrastructure state is reconstructed by introspecting
the infrastructure. This means that InfraKit is more a ‘kit’ then another
platform and higher-level systems can incorporate InfraKit to provide
self-managing and self-provisioning capabilities.
On Tue, Jun 6, 2017 at 8:41 AM, Chris Aniszczyk <
caniszczyk at linuxfoundation.org> wrote:
> From today's CNCF TOC call, there was some discussion on how InfraKit
> compares to Terraform, BOSH and Digital Rebar. Thanks again to David for
> taking the time to present.
> Let's use this thread to have that discussion.
> Chris Aniszczyk (@cra) | +1-512-961-6719 <(512)%20961-6719>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cncf-toc