Noah Watkins f034f000e1 ceph: schedule mons across failure domains
this patch introduces failure-domain aware scheduling for monitor pods.
previously the only policy was to avoid scheduling monitors on the same
nodes. the new policy tries to spread monitors across zones and nodes.

   NOTE: this patch only enforces the well-known k8s "zone"
   failure-domain label (i.e. it does not look for region labels). this
   decision is made for two reasons. first, eliminating explicit
   scheduling is an important goal and will be done as part of upcoming
   work. this will enable all supported failure-domain labels to be
   handled. second, the "zone" domain is likely more appropriate for a
   larger portion of users (as opposed to the geographical distinction
   made with region), and supporting multiple failure domain types would
   add significant complexity for a temporary resolution to failure
   domain scheduling.

at a high-level this patch introduces a data structure `NodeUsage` that
is a pairing of a v1.Node and metadata relevant to scheduling: number of
monitor pods on the node, and its status w.r.t. to being scheduable for
new monitor pods.

each scheduling event computes a unified data structure that organizes
for each node a `NodeUsage` structure into per-failure-zone groups.
subsequent algorithms rely soley on this unified structure to make
scheduling decisions.

there are two entry points to the changes made:

1) during orchestration mon:Cluster:assignMons is invoked to make a
place new monitor pods onto nodes. the core scheduling logic is now
self-contained in mon:scheduleMonitor which implements node and zone
aware scheduling policies.

2) periodic health checks resolve any conflicts that may occur due to
changes to the cluster (e.g. new nodes, configuration changes, etc...).
the two existing checks: mons on invalid nodes, and overloaded nodes are
both handled.

fixes: #2603

Signed-off-by: Noah Watkins <noahwatkins@gmail.com>
2019-07-11 14:23:15 -07:00
2019-05-16 22:53:30 +02:00
2019-02-20 19:07:29 +05:30
2018-01-29 20:38:41 -08:00
2016-11-07 17:13:39 -08:00
2016-11-07 17:13:39 -08:00
2019-05-31 11:09:23 +02:00
2019-05-22 13:51:44 +01:00

Rook

Build Status GitHub release Docker Pulls Go Report Card CII Best Practices FOSSA Status Slack Twitter Follow

What is Rook?

Rook is an open source cloud-native storage orchestrator for Kubernetes, providing the platform, framework, and support for a diverse set of storage solutions to natively integrate with cloud-native environments.

Rook turns storage software into self-managing, self-scaling, and self-healing storage services. It does this by automating deployment, bootstrapping, configuration, provisioning, scaling, upgrading, migration, disaster recovery, monitoring, and resource management. Rook uses the facilities provided by the underlying cloud-native container management, scheduling and orchestration platform to perform its duties.

Rook integrates deeply into cloud native environments leveraging extension points and providing a seamless experience for scheduling, lifecycle management, resource management, security, monitoring, and user experience.

For more details about the storage solutions currently supported by Rook, please refer to the project status section below. We plan to continue adding support for other storage systems and environments based on community demand and engagement in future releases. See our roadmap for more details.

Rook is hosted by the Cloud Native Computing Foundation (CNCF) as an incubating level project. If you are a company that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details about who's involved and how Rook plays a role, read the CNCF announcement.

Getting Started and Documentation

For installation, deployment, and administration, see our Documentation.

Contributing

We welcome contributions. See Contributing to get started.

Report a Bug

For filing bugs, suggesting improvements, or requesting new features, please open an issue.

Contact

Please use the following to reach members of the community:

Community Meeting

A regular community meeting takes place every other Tuesday at 9:00 AM PT (Pacific Time). Convert to your local timezone.

Any changes to the meeting schedule will be added to the agenda doc and posted to Slack #announcements and the rook-dev mailing list.

Anyone who wants to discuss the direction of the project, design and implementation reviews, or general questions with the broader community is welcome and encouraged to join.

Project Status

The status of each storage provider supported by Rook can be found in the table below. Each API group is assigned its own individual status to reflect their varying maturity and stability. More details about API versioning and status in Kubernetes can be found on the Kubernetes API versioning page, but the key difference between the statuses are summarized below:

  • Alpha: The API may change in incompatible ways in a later software release without notice, recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.
  • Beta: Support for the overall features will not be dropped, though details may change. Support for upgrading or migrating between versions will be provided, either through automation or manual steps.
  • Stable: Features will appear in released software for many subsequent versions and support for upgrading between versions will be provided with software automation in the vast majority of scenarios.
Name Details API Group Status
Rook Framework The framework for common storage specs and logic used to support other storage providers. rook.io/v1alpha2 Alpha
Ceph Ceph is a distributed storage system that provides file, block and object storage and is deployed in large scale production clusters. ceph.rook.io/v1 Stable
CockroachDB CockroachDB is a cloud-native SQL database for building global, scalable cloud services that survive disasters. cockroachdb.rook.io/v1alpha1 Alpha
Cassandra Cassandra is a highly available NoSQL database featuring lightning fast performance, tunable consistency and massive scalability. Scylla is a close-to-the-hardware rewrite of Cassandra in C++, which enables much lower latencies and higher throughput. cassandra.rook.io/v1alpha1 Alpha
EdgeFS EdgeFS is high-performance and fault-tolerant object storage system with Geo-Transparent data access to file, block or object. edgefs.rook.io/v1beta1 Beta
Minio Minio is a high performance distributed object storage server, designed for large-scale private cloud infrastructure. minio.rook.io/v1alpha1 Alpha
NFS Network File System (NFS) allows remote hosts to mount file systems over a network and interact with those file systems as though they are mounted locally. nfs.rook.io/v1alpha1 Alpha

Official Releases

Official releases of Rook can be found on the releases page. Please note that it is strongly recommended that you use official releases of Rook, as unreleased versions from the master branch are subject to changes and incompatibilities that will not be supported in the official releases. Builds from the master branch can have functionality changed and even removed at any time without compatibility support and without prior notice.

Licensing

Rook is under the Apache 2.0 license.

FOSSA Status

S
Description
This fork holds my modifications to the rook example configs as they are applied to my cluster
Readme Apache-2.0
175 MiB
Languages
Go 93.9%
Shell 3.2%
Python 1.8%
Makefile 0.8%
Go Template 0.2%