mirror of
https://github.com/etcd-io/etcd.git
synced 2024-09-27 06:25:44 +00:00
Adding weights and descriptions to Documentation files' frontmatter.
Updating for new TOC as per issue https://github.com/etcd-io/website/issues/81 Signed-off-by: Nate W <4453979+nate-double-u@users.noreply.github.com>
This commit is contained in:
parent
4726911ea5
commit
6c08437ec3
@ -1,4 +1,5 @@
|
||||
---
|
||||
title: Benchmarks
|
||||
weight: 5000
|
||||
description: Performance measures for etcd
|
||||
---
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Benchmarking etcd v2.1.0
|
||||
weight: 5875
|
||||
description: Performance measures for etcd v2.1.0
|
||||
---
|
||||
|
||||
## Physical machines
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Benchmarking etcd v2.2.0
|
||||
weight: 5750
|
||||
description: Performance measures for etcd v2.2.0
|
||||
---
|
||||
|
||||
## Physical Machines
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Benchmarking etcd v2.2.0-rc
|
||||
weight: 5625
|
||||
description: Performance measures for etcd v2.2.0-rc
|
||||
---
|
||||
|
||||
## Physical machine
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Benchmarking etcd v2.2.0-rc-memory
|
||||
weight: 5500
|
||||
description: Performance measures for etcd v2.2.0-rc-memory
|
||||
---
|
||||
|
||||
## Physical machine
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Benchmarking etcd v3
|
||||
weight: 5375
|
||||
description: Performance measures for etcd v3
|
||||
---
|
||||
|
||||
## Physical machines
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Watch Memory Usage Benchmark
|
||||
weight: 5250
|
||||
description: Performance measures for etcd watchers
|
||||
---
|
||||
|
||||
*NOTE*: The watch features are under active development, and their memory usage may change as that development progresses. We do not expect it to significantly increase beyond the figures stated below.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Storage Memory Usage Benchmark
|
||||
weight: 5125
|
||||
description: Performance measures for etcd storage (in-memory index & page cache)
|
||||
---
|
||||
|
||||
<!---todo: link storage to storage design doc-->
|
||||
|
@ -1,6 +1,7 @@
|
||||
---
|
||||
title: Branch management
|
||||
weight: 1
|
||||
weight: 1250
|
||||
description: etcd branch management
|
||||
---
|
||||
|
||||
## Guide
|
||||
|
@ -1,6 +1,7 @@
|
||||
---
|
||||
title: Demo
|
||||
weight: 1
|
||||
weight: 1100
|
||||
description: Procedures for working with an etcd cluster
|
||||
---
|
||||
|
||||
This series of examples shows the basic procedures for working with an etcd cluster.
|
||||
|
@ -1,4 +1,5 @@
|
||||
---
|
||||
title: Developer guide
|
||||
weight: 3000
|
||||
description: Guides for developers using ectd
|
||||
---
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Why gRPC gateway
|
||||
weight: 3375
|
||||
description: Why you should consider using the gRPC gateway
|
||||
---
|
||||
|
||||
etcd v3 uses [gRPC][grpc] for its messaging protocol. The etcd project includes a gRPC-based [Go client][go-client] and a command line utility, [etcdctl][etcdctl], for communicating with an etcd cluster through gRPC. For languages with no gRPC support, etcd provides a JSON [gRPC gateway][grpc-gateway]. This gateway serves a RESTful proxy that translates HTTP/JSON requests into gRPC messages.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Experimental APIs and features
|
||||
weight: 3750
|
||||
description: New (and potentially unstable) APIs and features in etcd
|
||||
---
|
||||
|
||||
For the most part, the etcd project is stable, but we are still moving fast! We believe in the release fast philosophy. We want to get early feedback on features still in development and stabilizing. Thus, there are, and will be more, experimental features and APIs. We plan to improve these features based on the early feedback from the community, or abandon them if there is little interest, in the next few releases. Please do not rely on any experimental features or APIs in production environment.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: gRPC naming and discovery
|
||||
weight: 3500
|
||||
description: "go-grpc: for resolving gRPC endpoints with an etcd backend"
|
||||
---
|
||||
|
||||
etcd provides a gRPC resolver to support an alternative name system that fetches endpoints from etcd for discovering gRPC services. The underlying mechanism is based on watching updates to keys prefixed with the service name.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Interacting with etcd
|
||||
weight: 3250
|
||||
description: "etcdctl: a command line tool for interacting with the etcd server"
|
||||
---
|
||||
|
||||
Users mostly interact with etcd by putting or getting the value of a key. This section describes how to do that by using etcdctl, a command line tool for interacting with etcd server. The concepts described here should apply to the gRPC APIs or client library APIs.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: System limits
|
||||
weight: 3625
|
||||
description: "etcd limits: requests and storage"
|
||||
---
|
||||
|
||||
## Request size limit
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Set up a local cluster
|
||||
weight: 3125
|
||||
description: Configuring local clusters for testing and development
|
||||
---
|
||||
|
||||
For testing and development deployments, the quickest and easiest way is to configure a local cluster. For a production deployment, refer to the [clustering][clustering] section.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Discovery service protocol
|
||||
weight: 1500
|
||||
description: Discover other etcd members in a cluster bootstrap phase
|
||||
---
|
||||
|
||||
Discovery service protocol helps new etcd member to discover all other members in cluster bootstrap phase using a shared discovery URL.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Logging conventions
|
||||
weight: 1600
|
||||
description: Logging level categories
|
||||
---
|
||||
|
||||
etcd uses the [capnslog][capnslog] library for logging application output categorized into *levels*. A log message's level is determined according to these conventions:
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Golang modules
|
||||
weight: 1650
|
||||
description: Organization of the etcd project's golang modules
|
||||
---
|
||||
|
||||
The etcd project (since version 3.5) is organized into multiple
|
||||
@ -92,4 +94,4 @@ This assumes:
|
||||
etcd storage files.
|
||||
- Splitting etcd-proxy out of ./etcd binary, as it contains more experimental code
|
||||
so carries additional risk & dependencies.
|
||||
- Deprecation of support for v2 protocol.
|
||||
- Deprecation of support for v2 protocol.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: etcd release guide
|
||||
weight: 1550
|
||||
description: How to release a new version of etcd
|
||||
---
|
||||
|
||||
The guide talks about how to release a new version of etcd.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Download and build
|
||||
weight: 1150
|
||||
description: Instructions for downloading and building different versions of etcd
|
||||
---
|
||||
|
||||
## System requirements
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Frequently Asked Questions (FAQ)
|
||||
title: FAQ
|
||||
weight: 1200
|
||||
description: Frequently asked questions
|
||||
---
|
||||
|
||||
## etcd, general
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Libraries and tools
|
||||
weight: 1300
|
||||
description: A listing of etcd tools and client libraries
|
||||
---
|
||||
|
||||
## Tools
|
||||
|
@ -1,4 +1,5 @@
|
||||
---
|
||||
title: Learning
|
||||
weight: 2000
|
||||
description: Learning resources
|
||||
---
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: etcd3 API
|
||||
weight: 2625
|
||||
description: etcd3 API central design overview
|
||||
---
|
||||
|
||||
This document is meant to give an overview of the etcd3 API's central design. It is by no means all encompassing, but intended to focus on the basic ideas needed to understand etcd without the distraction of less common API calls. All etcd3 API's are defined in [gRPC services][grpc-service], which categorize remote procedure calls (RPCs) understood by the etcd server. A full listing of all etcd RPCs are documented in markdown in the [gRPC API listing][grpc-api].
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: KV API guarantees
|
||||
weight: 2750
|
||||
description: KV API guarantees made by etcd
|
||||
---
|
||||
|
||||
etcd is a consistent and durable key value store with [mini-transaction][txn] support. The key value store is exposed through the KV APIs. etcd tries to ensure the strongest consistency and durability guarantees for a distributed system. This specification enumerates the KV API guarantees made by etcd.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Data model
|
||||
weight: 2125
|
||||
description: etcd data storage methodologies
|
||||
---
|
||||
|
||||
etcd is designed to reliably store infrequently updated data and provide reliable watch queries. etcd exposes previous versions of key-value pairs to support inexpensive snapshots and watch history events (“time travel queries”). A persistent, multi-version, concurrency-control data model is a good fit for these use cases.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: etcd v3 authentication design
|
||||
weight: 2500
|
||||
description: etcd v3 authentication
|
||||
---
|
||||
|
||||
## Why not reuse the v2 auth system?
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: etcd client design
|
||||
weight: 2250
|
||||
description: Client architectural decisions & their implementation details
|
||||
---
|
||||
|
||||
etcd Client Design
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: etcd learner design
|
||||
weight: 2375
|
||||
description: Mitigating common challenges with membership reconfiguration
|
||||
---
|
||||
|
||||
etcd Learner
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Glossary
|
||||
weight: 2900
|
||||
description: Terms used in etcd documentation, command line, and source code
|
||||
---
|
||||
|
||||
This document defines the various terms used in etcd documentation, command line and source code.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: etcd versus other key-value stores
|
||||
weight: 2875
|
||||
description: History and use of etcd & comparison with other tools
|
||||
---
|
||||
|
||||
The name "etcd" originated from two ideas, the unix "/etc" folder and "d"istributed systems. The "/etc" folder is a place to store configuration data for a single system whereas etcd stores configuration information for large scale distributed systems. Hence, a "d"istributed "/etc" is "etcd".
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Metrics
|
||||
weight: 1350
|
||||
description: Metrics for real-time monitoring and debugging
|
||||
---
|
||||
|
||||
etcd uses [Prometheus][prometheus] for metrics reporting. The metrics can be used for real-time monitoring and debugging. etcd does not persist its metrics; if a member restarts, the metrics will be reset.
|
||||
|
@ -1,4 +1,5 @@
|
||||
---
|
||||
title: Operations guide
|
||||
weight: 4000
|
||||
description: etcd installation, maintenance, and troubleshooting guides
|
||||
---
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Role-based access control
|
||||
weight: 4100
|
||||
description: A basic authentication and role-based access control guide
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Clustering Guide
|
||||
weight: 4150
|
||||
description: "Bootstrapping an etcd cluster: Static, etcd Discovery, and DNS Discovery"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Configuration flags
|
||||
weight: 4050
|
||||
description: "etcd configuration: files, flags, and environment variables"
|
||||
---
|
||||
|
||||
etcd is configurable through a configuration file, various command-line flags, and environment variables.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Run etcd clusters inside containers
|
||||
weight: 4200
|
||||
description: Running etcd with rkt and Docker using static bootstrapping
|
||||
---
|
||||
|
||||
The following guide shows how to run etcd with rkt and Docker using the [static bootstrap process](clustering.md#static).
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Failure modes
|
||||
weight: 4250
|
||||
description: Kinds of failures and ectd's tolerance for them
|
||||
---
|
||||
|
||||
Failures are common in a large deployment of machines. A machine fails when its hardware or software malfunctions. Multiple machines fail together when there are power failures or network issues. Multiple kinds of failures can also happen at once; it is almost impossible to enumerate all possible failure cases.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: etcd gateway
|
||||
weight: 4300
|
||||
description: etcd gateway, when to use it, and how to set it up
|
||||
---
|
||||
|
||||
## What is etcd gateway
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: gRPC proxy
|
||||
weight: 4350
|
||||
description: A stateless etcd reverse proxy operating at the gRPC layer
|
||||
---
|
||||
|
||||
The gRPC proxy is a stateless etcd reverse proxy operating at the gRPC layer (L7). The proxy is designed to reduce the total processing load on the core etcd cluster. For horizontal scalability, it coalesces watch and lease API requests. To protect the cluster against abusive clients, it caches key range requests.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Hardware recommendations
|
||||
weight: 4400
|
||||
description: Hardware guidelines for administering etcd clusters
|
||||
---
|
||||
|
||||
etcd usually runs well with limited resources for development or testing purposes; it’s common to develop with etcd on a laptop or a cheap cloud machine. However, when running etcd clusters in production, some hardware guidelines are useful for proper administration. These suggestions are not hard rules; they serve as a good starting point for a robust production deployment. As always, deployments should be tested with simulated workloads before running in production.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Maintenance
|
||||
weight: 4450
|
||||
description: Periodic etcd cluster maintenance guide
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Monitoring etcd
|
||||
weight: 4500
|
||||
description: Monitoring etcd for system health & cluster debugging
|
||||
---
|
||||
|
||||
Each etcd server provides local monitoring information on its client port through http endpoints. The monitoring data is useful for both system health checking and cluster debugging.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Performance
|
||||
weight: 4550
|
||||
description: "Understanding performance: latency & throughput"
|
||||
---
|
||||
|
||||
## Understanding performance
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Disaster recovery
|
||||
weight: 4275
|
||||
description: etcd v3 snapshot & restore facilities
|
||||
---
|
||||
|
||||
etcd is designed to withstand machine failures. An etcd cluster automatically recovers from temporary failures (e.g., machine reboots) and tolerates up to *(N-1)/2* permanent failures for a cluster of N members. When a member permanently fails, whether due to hardware failure or disk corruption, it loses access to the cluster. If the cluster permanently loses more than *(N-1)/2* members then it disastrously fails, irrevocably losing quorum. Once quorum is lost, the cluster cannot reach consensus and therefore cannot continue accepting updates.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Runtime reconfiguration
|
||||
weight: 4700
|
||||
description: etcd incremental runtime reconfiguration support
|
||||
---
|
||||
|
||||
etcd comes with support for incremental runtime reconfiguration, which allows users to update the membership of the cluster at run time.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Design of runtime reconfiguration
|
||||
weight: 4650
|
||||
description: The design of etcd’s runtime reconfiguration commands
|
||||
---
|
||||
|
||||
Runtime reconfiguration is one of the hardest and most error prone features in a distributed system, especially in a consensus based system like etcd.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Transport security model
|
||||
weight: 4125
|
||||
description: Securing data in transit
|
||||
---
|
||||
|
||||
etcd supports automatic TLS as well as authentication through client certificates for both clients to server as well as peer (server to server / cluster) communication. **Note that etcd doesn't enable [RBAC based authentication][auth] or the authentication feature in the transport layer by default to reduce friction for users getting started with the database. Further, changing this default would be a breaking change for the project which was established since 2013. An etcd cluster which doesn't enable security features can expose its data to any clients.**
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Supported systems
|
||||
weight: 4800
|
||||
description: etcd support status for common architectures & operating systems
|
||||
---
|
||||
|
||||
## Current support
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Migrate applications from using API v2 to API v3
|
||||
weight: 4850
|
||||
description: A guide for migrating from API v2 to API v3
|
||||
---
|
||||
|
||||
The data store v2 is still accessible from the API v2 after upgrading to etcd3. Thus, it will work as before and require no application changes. With etcd 3, applications use the new grpc API v3 to access the mvcc store, which provides more features and improved performance. The mvcc store and the old store v2 are separate and isolated; writes to the store v2 will not affect the mvcc store and, similarly, writes to the mvcc store will not affect the store v2.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Versioning
|
||||
weight: 4900
|
||||
description: Semantic versioning with etcd
|
||||
---
|
||||
|
||||
## Service versioning
|
||||
|
@ -1,4 +1,5 @@
|
||||
---
|
||||
title: Platforms
|
||||
weight: 7000
|
||||
description: etcd deployments on various platform services
|
||||
---
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Amazon Web Services
|
||||
weight: 7100
|
||||
description: etcd deployments on AWS EC2
|
||||
---
|
||||
|
||||
This guide assumes operational knowledge of Amazon Web Services (AWS), specifically Amazon Elastic Compute Cloud (EC2). This guide provides an introduction to design considerations when designing an etcd deployment on AWS EC2 and how AWS specific features may be utilized in that context.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Container Linux with systemd
|
||||
weight: 7200
|
||||
description: etcd deployments with systemd under Container Linux
|
||||
---
|
||||
|
||||
The following guide shows how to run etcd with [systemd][systemd-docs] under [Container Linux][container-linux-docs].
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: FreeBSD
|
||||
weight: 7300
|
||||
description: etcd deployments using FreeBSD
|
||||
---
|
||||
|
||||
Starting with version 0.1.2 both etcd and etcdctl have been ported to FreeBSD and can be installed either via packages or ports system. Their versions have been recently updated to 0.2.0 so now etcd and etcdctl can be enjoyed on FreeBSD 10.0 (RC4 as of now) and 9.x, where they have been tested. They might also work when installed from ports on earlier versions of FreeBSD, but it is untested; caveat emptor.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Reporting bugs
|
||||
weight: 1400
|
||||
description: How to file issue reports for the etcd project
|
||||
---
|
||||
|
||||
If any part of the etcd project has bugs or documentation mistakes, please let us know by [opening an issue][etcd-issue]. We treat bugs and mistakes very seriously and believe no issue is too small. Before creating a bug report, please check that an issue reporting the same problem does not already exist.
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Overview
|
||||
weight: 1050
|
||||
description: etcd API design principles
|
||||
---
|
||||
|
||||
The etcd v3 API is designed to give users a more efficient and cleaner abstraction compared to etcd v2. There are a number of semantic and protocol changes in this new API.
|
||||
|
@ -1,4 +1,5 @@
|
||||
---
|
||||
title: Triage
|
||||
weight: 8000
|
||||
description: Managing changes in etcd
|
||||
---
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Issue Triage Guidelines
|
||||
weight: 8100
|
||||
description: Managing incoming issues
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Tuning
|
||||
weight: 1450
|
||||
description: When to update the heartbeat interval and election timeout settings
|
||||
---
|
||||
|
||||
The default settings in etcd should work well for installations on a local network where the average network latency is low. However, when using etcd across multiple data centers or over networks with high latency, the heartbeat interval and election timeout settings may need tuning.
|
||||
|
@ -1,4 +1,5 @@
|
||||
---
|
||||
title: Upgrading
|
||||
weight: 6000
|
||||
description: Upgrading etcd clusters and applications
|
||||
---
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Upgrade etcd from 2.3 to 3.0
|
||||
weight: 6900
|
||||
description: Processes, checklists, and notes on upgrading etcd from 2.3 to 3.0
|
||||
---
|
||||
|
||||
In the general case, upgrading from etcd 2.3 to 3.0 can be a zero-downtime, rolling upgrade:
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Upgrade etcd from 3.0 to 3.1
|
||||
weight: 6850
|
||||
description: Processes, checklists, and notes on upgrading etcd from 3.0 to 3.1
|
||||
---
|
||||
|
||||
In the general case, upgrading from etcd 3.0 to 3.1 can be a zero-downtime, rolling upgrade:
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Upgrade etcd from 3.1 to 3.2
|
||||
weight: 6800
|
||||
description: Processes, checklists, and notes on upgrading etcd from 3.1 to 3.2
|
||||
---
|
||||
|
||||
In the general case, upgrading from etcd 3.1 to 3.2 can be a zero-downtime, rolling upgrade:
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Upgrade etcd from 3.2 to 3.3
|
||||
weight: 6750
|
||||
description: Processes, checklists, and notes on upgrading etcd from 3.2 to 3.3
|
||||
---
|
||||
|
||||
In the general case, upgrading from etcd 3.2 to 3.3 can be a zero-downtime, rolling upgrade:
|
||||
@ -541,4 +543,4 @@ localhost:22379 is healthy: successfully committed proposal: took = 2.553476ms
|
||||
localhost:32379 is healthy: successfully committed proposal: took = 2.517902ms
|
||||
```
|
||||
|
||||
[etcd-contact]: https://groups.google.com/forum/#!forum/etcd-dev
|
||||
[etcd-contact]: https://groups.google.com/forum/#!forum/etcd-dev
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Upgrade etcd from 3.3 to 3.4
|
||||
weight: 6700
|
||||
description: Processes, checklists, and notes on upgrading etcd from 3.3 to 3.4
|
||||
---
|
||||
|
||||
In the general case, upgrading from etcd 3.3 to 3.4 can be a zero-downtime, rolling upgrade:
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Upgrade etcd from 3.4 to 3.5
|
||||
weight: 6650
|
||||
description: Processes, checklists, and notes on upgrading etcd from 3.4 to 3.5
|
||||
---
|
||||
|
||||
In the general case, upgrading from etcd 3.4 to 3.5 can be a zero-downtime, rolling upgrade:
|
||||
|
@ -1,5 +1,7 @@
|
||||
---
|
||||
title: Upgrading etcd clusters and applications
|
||||
weight: 6500
|
||||
description: Documentation list for upgrading etcd clusters and applications
|
||||
---
|
||||
|
||||
This section contains documents specific to upgrading etcd clusters and applications.
|
||||
|
Loading…
x
Reference in New Issue
Block a user