Remove 1-node zero downtime instructions

With only Puma carried in GitLab 14.0 onwards
there is no possibility of minimizing any downtime
in single-node upgrades.

When the migration is run while leaving
the previous version's puma running, the
database changes are picked up in Rails
dynamically and UI errors begin to be
thrown to users.

Given the disruption of features is essentially
the same to users as a downtime when it
affects critical features such as merge requests
the section is false in indicating that
downtime is minimized.

Additionally this section is often discovered
by users and blindly followed even for
multiple version jumps that leads to
broken upgrades.

This change removes all sections related to zero
downtime upgrade instructions of single nodes.

doc/administration/reference_architectures/index.md

@@ -430,7 +430,7 @@ to any of the [available reference architectures](#available-reference-architect
 > - Required domain knowledge: PostgreSQL, HAProxy, shared storage, distributed systems
 
 GitLab supports [zero-downtime upgrades](../../update/zero_downtime.md).
-Single GitLab nodes can be updated with only a [few minutes of downtime](../../update/zero_downtime.md#single-node-deployment).
+Single GitLab nodes can be updated with only a [few minutes of downtime](../../update/index.md#upgrade-based-on-installation-method).
 To avoid this, we recommend to separate GitLab into several application nodes.
 As long as at least one of each component is online and capable of handling the instance's usage load, your team's productivity will not be interrupted during the update.
 

doc/update/zero_downtime.md

@@ -15,14 +15,12 @@ there are the following requirements:
    sequence [and leave the database schema in a broken state](https://gitlab.com/gitlab-org/gitlab/-/issues/321542).
 - You have to use [post-deployment migrations](../development/database/post_deployment_migrations.md).
 - You are using PostgreSQL. Starting from GitLab 12.1, MySQL is not supported.
-- Multi-node GitLab instance. Single-node instances may experience brief interruptions
-  [as services restart (Puma in particular)](#single-node-deployment).
+- You have set up a multi-node GitLab instance. Single-node instances do not support zero-downtime upgrades.
 
 If you meet all the requirements above, follow these instructions in order. There are three sets of steps, depending on your deployment type:
 
 | Deployment type                                                 | Description                                       |
 | --------------------------------------------------------------- | ------------------------------------------------  |
-| [Single-node](#single-node-deployment)                          | GitLab CE/EE on a single node                     |
 | [Gitaly Cluster](#gitaly-cluster)                               | GitLab CE/EE using HA architecture for Gitaly Cluster             |
 | [Multi-node / PostgreSQL HA](#use-postgresql-ha)                | GitLab CE/EE using HA architecture for PostgreSQL |
 | [Multi-node / Redis HA](#use-redis-ha-using-sentinel)           | GitLab CE/EE using HA architecture for Redis |
@@ -87,80 +85,6 @@ migrations this could potentially lead to hours of downtime, depending on the
 size of your database. To work around this you must use PostgreSQL and
 meet the other online upgrade requirements mentioned above.
 
-## Single-node deployment
-
-WARNING:
-You can only upgrade one minor release at a time.
-
-Before following these instructions, note the following **important** information:
-
-- You can only upgrade one minor release at a time. So from 13.6 to 13.7, not to 13.8.
-  If you attempt more than one minor release, the upgrade may fail.
-- On single-node Omnibus deployments, updates with no downtime are not possible when
-  using Puma because Puma always requires a complete restart. This is because the
-  [phased restart](https://github.com/puma/puma/blob/master/README.md#clustered-mode)
-  feature of Puma does not work with the way it is configured in GitLab all-in-one
-  packages (cluster-mode with app preloading).
-- While it is possible to minimize downtime on a single-node instance by following
-  these instructions, **it is not possible to always achieve true zero downtime
-  updates**. Users may see some connections timeout or be refused for a few minutes,
-  depending on which services need to restart.
-- On Omnibus deployments, the `/etc/gitlab/gitlab.rb` configuration file must **not** have
-  `gitlab_rails['auto_migrate'] = true`.
-
-1. Create an empty file at `/etc/gitlab/skip-auto-reconfigure`. This prevents upgrades from running `gitlab-ctl reconfigure`, which by default automatically stops GitLab, runs all database migrations, and restarts GitLab.
-
-   ```shell
-   sudo touch /etc/gitlab/skip-auto-reconfigure
-   ```
-
-1. Update the GitLab package:
-
-   - For GitLab [Enterprise Edition](https://about.gitlab.com/pricing/):
-
-     ```shell
-     # Debian/Ubuntu
-     sudo apt-get update
-     sudo apt-get install gitlab-ee
-
-     # Centos/RHEL
-     sudo yum install gitlab-ee
-     ```
-
-   - For GitLab Community Edition:
-
-     ```shell
-     # Debian/Ubuntu
-     sudo apt-get update
-     sudo apt-get install gitlab-ce
-
-     # Centos/RHEL
-     sudo yum install gitlab-ce
-     ```
-
-1. To get the regular migrations and latest code in place, run
-
-   ```shell
-   sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure
-   ```
-
-1. Once the node is updated and `reconfigure` finished successfully, run post-deployment migrations with
-
-   ```shell
-   sudo gitlab-rake db:migrate
-   ```
-
-1. Hot reload `puma` and `sidekiq` services
-
-   ```shell
-   sudo gitlab-ctl hup puma
-   sudo gitlab-ctl restart sidekiq
-   ```
-
-If you do not want to run zero downtime upgrades in the future, make
-sure you remove `/etc/gitlab/skip-auto-reconfigure` after
-you've completed these steps.
-
 ## Multi-node / HA deployment
 
 WARNING: