Deprecated Cortex chunks storage (#4268)

Deprecate Cortex chunks storage

Remove k8s example config which is chunks-based

Signed-off-by: Marco Pracucci <[email protected]>

Author: pracucci

CHANGELOG.md

@@ -2,6 +2,8 @@
 
 ## master / unreleased
 
+* [CHANGE] Cortex chunks storage has been deprecated and it's now in maintenance mode: all Cortex users are encouraged to migrate to the blocks storage. No new features will be added to the chunks storage. The default Cortex configuration still runs the chunks engine; please check out the [blocks storage doc](https://cortexmetrics.io/docs/blocks-storage/) on how to configure Cortex to run with the blocks storage.  #4268
+* [CHANGE] The example Kubernetes manifests (stored at `k8s/`) have been removed due to a lack of proper support and maintenance. #4268
 * [CHANGE] Querier / ruler: deprecated `-store.query-chunk-limit` CLI flag (and its respective YAML config option `max_chunks_per_query`) in favour of `-querier.max-fetched-chunks-per-query` (and its respective YAML config option `max_fetched_chunks_per_query`). The new limit specifies the maximum number of chunks that can be fetched in a single query from ingesters and long-term storage: the total number of actual fetched chunks could be 2x the limit, being independently applied when querying ingesters and long-term storage. #4125
 * [CHANGE] Alertmanager: allowed to configure the experimental receivers firewall on a per-tenant basis. The following CLI flags (and their respective YAML config options) have been changed and moved to the limits config section: #4143
   - `-alertmanager.receivers-firewall.block.cidr-networks` renamed to `-alertmanager.receivers-firewall-block-cidr-networks`

Makefile

@@ -213,10 +213,6 @@ lint:
 		./pkg/querier/... \
 		./pkg/ruler/...
 
-	# Validate Kubernetes spec files. Requires:
-	# https://kubeval.instrumenta.dev
-	kubeval ./k8s/*
-
 test:
 	go test -tags netgo -timeout 30m -race -count 1 ./...
 

README.md

@@ -14,7 +14,7 @@ Cortex provides horizontally scalable, highly available, multi-tenant, long term
 - **Highly available:** When run in a cluster, Cortex can replicate data between machines. This allows you to survive machine failure without gaps in your graphs.
 - **Multi-tenant:** Cortex can isolate data and queries from multiple different independent
 Prometheus sources in a single cluster, allowing untrusted parties to share the same cluster.
-- **Long term storage:** Cortex supports Amazon DynamoDB, Google Bigtable, Cassandra, S3, GCS and Microsoft Azure for long term storage of metric data.  This allows you to durably store data for longer than the lifetime of any single machine, and use this data for long term capacity planning.
+- **Long term storage:** Cortex supports S3, GCS, Swift and Microsoft Azure for long term storage of metric data. This allows you to durably store data for longer than the lifetime of any single machine, and use this data for long term capacity planning.
 
 Cortex is a [CNCF](https://cncf.io) incubation project used in several production systems including [Weave Cloud](https://cloud.weave.works) and [Grafana Cloud](https://grafana.com/cloud).
 Cortex is primarily used as a [remote write](https://prometheus.io/docs/operating/configuration/#remote_write) destination for Prometheus, with a Prometheus-compatible query API.
@@ -25,9 +25,8 @@ Read the [getting started guide](https://cortexmetrics.io/docs/getting-started)
 project. Before deploying Cortex with a permanent storage backend you
 should read:
 1. [An overview of Cortex's architecture](https://cortexmetrics.io/docs/architecture/)
-1. [A guide to running Cortex](https://cortexmetrics.io/docs/chunks-storage/running-chunks-storage-in-production/)
-1. [Information regarding configuring Cortex](https://cortexmetrics.io/docs/configuration/arguments/)
-1. [Steps to run Cortex with Cassandra](https://cortexmetrics.io/docs/chunks-storage/running-chunks-storage-with-cassandra/)
+1. [Getting started with Cortex](https://cortexmetrics.io/docs/getting-started/)
+1. [Information regarding configuring Cortex](https://cortexmetrics.io/docs/configuration/)
 
 For a guide to contributing to Cortex, see the [contributor guidelines](https://cortexmetrics.io/docs/contributing/).
 

build-image/Dockerfile

@@ -40,11 +40,6 @@ RUN GO111MODULE=on go get \
 		github.com/campoy/[email protected] \
 	&& rm -rf /go/pkg /go/src /root/.cache
 
-# Cannot get it to run together in above go get.
-RUN GO111MODULE=on go get  \
-		github.com/instrumenta/[email protected] \
-	&& rm -rf /go/pkg /go/src /root/.cache
-
 ENV NODE_PATH=/usr/lib/node_modules
 COPY build.sh /
 ENV GOCACHE=/go/cache

docs/_index.md

@@ -21,7 +21,7 @@ Cortex provides horizontally scalable, highly available, multi-tenant, long term
 - **Highly available:** When run in a cluster, Cortex can replicate data between machines. This allows you to survive machine failure without gaps in your graphs.
 - **Multi-tenant:** Cortex can isolate data and queries from multiple different independent
 Prometheus sources in a single cluster, allowing untrusted parties to share the same cluster.
-- **Long term storage:** Cortex supports Amazon DynamoDB, Google Bigtable, Cassandra, S3 and GCS for long term storage of metric data.  This allows you to durably store data for longer than the lifetime of any single machine, and use this data for long term capacity planning.
+- **Long term storage:** Cortex supports S3, GCS, Swift and Microsoft Azure for long term storage of metric data. This allows you to durably store data for longer than the lifetime of any single machine, and use this data for long term capacity planning.
 
 Cortex is a [CNCF](https://cncf.io) incubation project used in several production systems including [Weave Cloud](https://cloud.weave.works) and [Grafana Cloud](https://grafana.com/cloud).
 Cortex is primarily used as a [remote write](https://prometheus.io/docs/operating/configuration/#remote_write) destination for Prometheus, exposing a Prometheus-compatible query API.
@@ -33,7 +33,7 @@ project. Before deploying Cortex with a permanent storage backend you
 should read:
 
 1. [An overview of Cortex's architecture](architecture.md)
-1. [A guide to running Cortex chunks storage](chunks-storage/running-chunks-storage-in-production.md)
+1. [Getting started with Cortex](getting-started/_index.md)
 1. [Information regarding configuring Cortex](configuration/_index.md)
 
 For a guide to contributing to Cortex, see the [contributor guidelines](contributing/).

docs/architecture.md

@@ -21,12 +21,12 @@ Incoming samples (writes from Prometheus) are handled by the [distributor](#dist
 
 Cortex currently supports two storage engines to store and query the time series:
 
-- Chunks (default)
+- Chunks (deprecated)
 - Blocks
 
 The two engines mostly share the same Cortex architecture with few differences outlined in the rest of the document.
 
-### Chunks storage (default)
+### Chunks storage (deprecated)
 
 The chunks storage stores each single time series into a separate object called _Chunk_. Each Chunk contains the samples for a given period (defaults to 12 hours). Chunks are then indexed by time range and labels, in order to provide a fast lookup across many (over millions) Chunks.
 

docs/chunks-storage/_index.md

@@ -1,10 +1,12 @@
 ---
-title: "Chunks Storage"
-linkTitle: "Chunks Storage"
+title: "Chunks Storage (deprecated)"
+linkTitle: "Chunks Storage (deprecated)"
 weight: 4
 menu:
 ---
 
+**Warning: the chunks storage is deprecated. You're encouraged to use the [blocks storage](../blocks-storage/_index.md).**
+
 The chunks storage is a Cortex storage engine which stores each single time series into a separate object called _chunk_. Each chunk contains the samples for a given period (defaults to 12 hours). Chunks are then indexed by time range and labels, in order to provide a fast lookup across many (over millions) chunks. For this reason, the Cortex chunks storage requires two backend storages: a key-value store for the index and an object store for the chunks.
 
 The supported backends for the **index store** are:

docs/chunks-storage/aws-tips.md

@@ -5,6 +5,8 @@ weight: 10
 slug: aws-tips
 ---
 
+**Warning: the chunks storage is deprecated. You're encouraged to use the [blocks storage](../blocks-storage/_index.md).**
+
 This page shares some tips and things to take in consideration when running Cortex chunks storage on AWS.
 
 ## AWS Credentials

docs/chunks-storage/caching.md

@@ -5,6 +5,8 @@ weight: 4
 slug: caching
 ---
 
+**Warning: the chunks storage is deprecated. You're encouraged to use the [blocks storage](../blocks-storage/_index.md).**
+
 Correctly configured caching is important for a production-ready Cortex cluster.
 Cortex has many opportunities for using caching to accelerate queries and reduce cost.  Cortex can use a cache for:
 

docs/chunks-storage/chunks-storage-getting-started.md

@@ -5,6 +5,8 @@ weight: 1
 slug: getting-started-chunks-storage
 ---
 
+**Warning: the chunks storage is deprecated. You're encouraged to use the [blocks storage](../blocks-storage/_index.md).**
+
 Cortex can be run as a single binary or as multiple independent microservices.
 The single-binary mode is easier to deploy and is aimed mainly at users wanting to try out Cortex or develop on it.
 The microservices mode is intended for production usage, as it allows you to independently scale different services and isolate failures.

docs/chunks-storage/ingesters-with-wal.md

@@ -5,6 +5,8 @@ weight: 5
 slug: ingesters-with-wal
 ---
 
+**Warning: the chunks storage is deprecated. You're encouraged to use the [blocks storage](../blocks-storage/_index.md).**
+
 By default, ingesters running with the chunks storage, store all their data in memory. If there is a crash, there could be loss of data. The Write-Ahead Log (WAL) helps fill this gap in reliability.
 
 To use WAL, there are some changes that needs to be made in the deployment.

docs/chunks-storage/running-chunks-storage-in-production.md

@@ -5,6 +5,8 @@ weight: 1
 slug: running-chunks-storage-in-production
 ---
 
+**Warning: the chunks storage is deprecated. You're encouraged to use the [blocks storage](../blocks-storage/_index.md).**
+
 This document builds on the [getting started guide](../getting-started/_index.md) and specifies the steps needed to get Cortex [**chunks storage**](../chunks-storage/_index.md) into production.
 Ensure you have completed all the steps in the [getting started guide](../getting-started/_index.md) and read about [the Cortex architecture](../architecture.md) before you start this one.
 

docs/chunks-storage/running-chunks-storage-with-cassandra.md

@@ -5,6 +5,8 @@ weight: 2
 slug: running-chunks-storage-with-cassandra
 ---
 
+**Warning: the chunks storage is deprecated. You're encouraged to use the [blocks storage](../blocks-storage/_index.md).**
+
 This guide covers how to run a single local Cortex instance - with the [**chunks storage**](../chunks-storage/_index.md) engine - storing time series chunks and index in Cassandra.
 
 In this guide we're going to:

docs/chunks-storage/schema-config.md

@@ -5,6 +5,8 @@ weight: 2
 slug: schema-configuration
 ---
 
+**Warning: the chunks storage is deprecated. You're encouraged to use the [blocks storage](../blocks-storage/_index.md).**
+
 Cortex chunks storage stores indexes and chunks in table-based data storages. When such a storage type is used, multiple tables are created over the time: each table - also called periodic table - contains the data for a specific time range. The table-based storage layout is configured through a configuration file called **schema config**.
 
 _The schema config is used only by the chunks storage, while it's **not** used by the [blocks storage](../blocks-storage/_index.md) engine._

docs/chunks-storage/table-manager.md

@@ -5,6 +5,8 @@ weight: 3
 slug: table-manager
 ---
 
+**Warning: the chunks storage is deprecated. You're encouraged to use the [blocks storage](../blocks-storage/_index.md).**
+
 The table-manager is the Cortex service responsible for creating the [periodic tables](./schema-config.md) used to store index and chunks, and deleting them once their data time range exceeds the retention period (if retention is enabled).
 
 _For more information about the schema config and periodic tables, please refer to the [Schema config](./schema-config.md) documentation._

docs/configuration/arguments.md

@@ -20,7 +20,7 @@ Duration arguments should be specified with a unit like `5s` or `3h`. Valid time
 
 - `-querier.query-parallelism`
 
-   This refers to database queries against the store (e.g. Bigtable or DynamoDB).  This is the max subqueries run in parallel per higher-level query.
+   This refers to database queries against the store when running the deprecated Cortex chunks storage (e.g. Bigtable or DynamoDB).  This is the max subqueries run in parallel per higher-level query.
 
 - `-querier.timeout`
 

docs/guides/deleting-series.md

@@ -5,7 +5,7 @@ weight: 10
 slug: deleting-series
 ---
 
-_This feature is currently experimental and is only supported for Chunks storage._
+_This feature is currently experimental and is only supported for Chunks storage (deprecated)._
 
 Cortex supports deletion of series using [Prometheus compatible API](https://prometheus.io/docs/prometheus/latest/querying/api/#delete-series).
 It however does not support [Prometheuses Clean Tombstones](https://prometheus.io/docs/prometheus/latest/querying/api/#clean-tombstones) API because Cortex uses a different mechanism to manage deletions.

docs/guides/encryption-at-rest.md

@@ -38,7 +38,7 @@ sse:
   [kms_encryption_context: <string> | default = ""]
 ```
 
-### Chunks storage
+### Chunks storage (deprecated)
 
 The [chunks storage](../chunks-storage/_index.md) S3 server-side encryption can be configured similarly to the blocks storage, but **per-tenant overrides are not supported**.
 

docs/guides/encryption-at-rest.template

@@ -20,7 +20,7 @@ The [blocks storage](../blocks-storage/_index.md) S3 server-side encryption can
 
 {{ .S3SSEConfigBlock }}
 
-### Chunks storage
+### Chunks storage (deprecated)
 
 The [chunks storage](../chunks-storage/_index.md) S3 server-side encryption can be configured similarly to the blocks storage, but **per-tenant overrides are not supported**.
 

docs/guides/glossary.md

@@ -11,10 +11,12 @@ The blocks storage is a Cortex storage engine based on Prometheus TSDB, which on
 
 For more information, please refer to the [Cortex blocks storage](../blocks-storage/_index.md) documentation.
 
-### Chunks storage
+### Chunks storage (deprecated)
 
 The chunks storage is a Cortex storage engine which requires both an index store (eg. AWS DynamoDB, Google BigTable, Cassandra, ...) and an object store (eg. AWS S3, Google GCS, ...) as backend storage.
 
+The chunks storage is deprecated. You're encouraged to use the [blocks storage](#blocks-storage) instead.
+
 ### Chunk
 
 A chunk is an object containing compressed timestamp-value pairs.

docs/guides/grpc-storage-plugin.md

@@ -5,7 +5,7 @@ weight: 10
 slug: grpc-based-plugin
 ---
 
-_This feature is currently experimental and is only supported for Chunks storage._
+_This feature is currently experimental and is only supported for Chunks storage (deprecated)._
 
 Cortex chunks storage supports a **gRPC-based plugin system** to use alternative backends for the index and chunks store.
 A store plugin is a gRPC-based server which implements the methods required by the index and chunks store. Cortex chunks storage schema is then configured to use the plugin as backend system and gRPC will be used to communicate between Cortex and the plugin.

docs/guides/ingesters-rolling-updates.md

@@ -26,7 +26,7 @@ The new ingester, which is expected to reuse the same disk of the leaving one, w
 
 _The blocks storage doesn't support the series [hand-over](#chunks-storage-with-wal-disabled-hand-over)._
 
-## Chunks storage
+## Chunks storage (deprecated)
 
 The Cortex chunks storage optionally supports a write-ahead log (WAL).
 The rolling update procedure for a Cortex cluster running the chunks storage depends whether the WAL is enabled or not.