Add latest changes from gitlab-org/gitlab@master

2 files changed, 23 insertions, 8 deletions

diff --git a/doc/administration/high_availability/README.md b/doc/administration/high_availability/README.md
index dad83b633a2..d411fb7f20f 100644
--- a/doc/administration/high_availability/README.md
+++ b/doc/administration/high_availability/README.md
@@ -4,18 +4,19 @@ type: reference, concepts
 
 # Scaling and High Availability
 
-GitLab supports several different types of clustering and high-availability.
+GitLab supports a number of options for scaling your self-managed instance and configuring high availability (HA).
 The solution you choose will be based on the level of scalability and
 availability you require. The easiest solutions are scalable, but not necessarily
 highly available.
 
-GitLab provides a service that is usually essential to most organizations: it
+GitLab provides a service that is essential to most organizations: it
 enables people to collaborate on code in a timely fashion. Any downtime should
-therefore be short and planned. Luckily, GitLab provides a solid setup even on
-a single server without special measures. Due to the distributed nature
-of Git, developers can still commit code locally even when GitLab is not
+therefore be short and planned. Due to the distributed nature
+of Git, developers can continue to commit code locally even when GitLab is not
 available. However, some GitLab features such as the issue tracker and
-Continuous Integration are not available when GitLab is down.
+continuous integration are not available when GitLab is down.
+If you require all GitLab functionality to be highly available,
+consider the options outlined below.
 
 **Keep in mind that all highly-available solutions come with a trade-off between
 cost/complexity and uptime**. The more uptime you want, the more complex the
@@ -25,8 +26,8 @@ solution should balance the costs against the benefits.
 
 There are many options when choosing a highly-available GitLab architecture. We
 recommend engaging with GitLab Support to choose the best architecture for your
-use case. This page contains some various options and guidelines based on
-experience with GitLab.com and Enterprise Edition on-premises customers.
+use case. This page contains recommendations based on
+experience with GitLab.com and internal scale testing.
 
 For detailed insight into how GitLab scales and configures GitLab.com, you can
 watch [this 1 hour Q&A](https://www.youtube.com/watch?v=uCU8jdYzpac)
diff --git a/doc/administration/restart_gitlab.md b/doc/administration/restart_gitlab.md
index 9f95080654f..6f3c6028f71 100644
--- a/doc/administration/restart_gitlab.md
+++ b/doc/administration/restart_gitlab.md
@@ -8,6 +8,7 @@ If you want the TL;DR versions, jump to:
 - [Omnibus GitLab restart](#omnibus-gitlab-restart)
 - [Omnibus GitLab reconfigure](#omnibus-gitlab-reconfigure)
 - [Source installation restart](#installations-from-source)
+- [Helm chart installation restart](#helm-chart-installations)
 
 ## Omnibus installations
 
@@ -143,3 +144,16 @@ If you are using other init systems, like systemd, you can check the
 [chef]: https://www.chef.io/products/chef-infra/ "Chef official website"
 [src-service]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/init.d/gitlab "GitLab init service file"
 [gl-recipes]: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/init "GitLab Recipes repository"
+
+## Helm chart installations
+
+There is no single command to restart the entire GitLab application installed via
+the [cloud native Helm Chart](https://docs.gitlab.com/charts/). Usually, it should be
+enough to restart a specific component separately (`gitaly`, `unicorn`,
+`workhorse`, `gitlab-shell`, etc.) by deleting all the pods related to it:
+
+```bash
+kubectl delete pods -l release=<helm release name>,app=<component name>
+```
+
+The release name can be obtained from the output of the `helm list` command.